Nortel KPI Formula s Desc Detail 2

3G 1xRTT Nortel Operational Measurements

Sprint PCS � Proprietary & Confidential 04/22/02 � Page 1

3G 1xRTT Nortel OperationalMeasurements

Prepared byCore RF Engineering04/22/02

Your input is important. If you have questions, comments, or suggestionsregarding this document, contact the person listed above by e-mail or phone.You may also contact Standards Development. (Address your e-mail messageto Standards Development or check the Standards Development web pageunder TS&NO on Connected.) Your knowledge and insight are invaluableresources for improving Sprint PCS documentation.



Table of Contents

1. Introduction 5

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

3. Performance Formulas 103.1. Performance Formulas for 3G Voice 10

3.1.1. 3G Voice Call Success .................................................................................... 103.1.2. 3G Voice Total Blocks.................................................................................... 12

3.1.2.1. Detailed 3G Voice Blocks......................................................................... 143.1.3. 3G Voice Access Failures ............................................................................... 19

3.1.3.1. Detailed 3G Voice Access Failures........................................................... 213.1.4. 3G Voice Drop Calls ....................................................................................... 22

3.1.4.1. Detailed 3G Voice Drops .......................................................................... 243.1.5. 3G Voice Pre-MCTA Frequency Selection Failures....................................... 253.1.6. 3G Voice Pre-MCTA Resource Allocation Failures (per frequency) ............. 27

3.1.6.1. Detailed 3G Voice Pre-MCTA Resource Allocation Failures (perfrequency).................................................................................................. 29

3.1.7. 3G Voice Post-MCTA Traffic Distribution (per frequency)........................... 323.1.8. 3G Voice Post-MCTA Call Success (per frequency)...................................... 343.1.9. 3G Voice Post-MCTA Call Blocks (per frequency) ....................................... 35

3.1.9.1. Detailed 3G Voice Post-MCTA Call Blocks (per frequency)................... 373.1.10. 3G Voice Post-MCTA Access Failures (per frequency) ................................. 39

3.1.10.1. Detailed 3G Voice Post-MCTA Access Failures (per frequency) ............ 413.1.11. 3G Voice Post-MCTA RF related Drop Calls (per frequency) ....................... 43

3.2. Performance Formulas for 3G Fundamental Channel Data 443.2.1. 3G Packet Data Call Success .......................................................................... 443.2.2. 3G Packet Data Total Blocks .......................................................................... 46

3.2.2.1. Detailed 3G Packet Data Blocks ............................................................... 473.2.3. 3G Packet Data Access Failure ....................................................................... 53

3.2.3.1. Detailed 3G Packet Data Access Failures ................................................. 553.2.4. 3G Packet Data Drop Calls ............................................................................. 56

3.2.4.1. Detailed 3G Packet Data Drop Calls......................................................... 573.2.5. 3G Packet Data Calls Dormant to Active Transition Average Rate ............... 593.2.6. 3G Data Pre-MCTA Frequency Selection Failures......................................... 603.2.7. 3G Data Pre-MCTA Resource Allocation Failures (per frequency) ............... 62

3.2.7.1. Detailed 3G Data Pre-MCTA Resource Allocation Failures (perfrequency).................................................................................................. 64

3.2.8. 3G Data Post-MCTA Traffic Distribution (per frequency)............................. 673.2.9. 3G Data Post-MCTA Call Success (per frequency)........................................ 69



3.2.10. 3G Data Post-MCTA Call Blocks (per frequency) ......................................... 703.2.10.1. Detailed 3G Data Post-MCTA Call Blocks (per frequency)..................... 72

3.2.11. 3G Data Post-MCTA Access Failures (per frequency) ................................... 743.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) ......................... 783.2.13. PCU MO: 3G Data R-P Interface Packet Sessions ......................................... 79

3.2.13.1. 3G Data R-P Interface Packet Session Successes ..................................... 803.2.13.2. 3G Data R-P Interface Packet Session Failures ........................................ 813.2.13.3. 3G Data R-P Interface Performance Formulas.......................................... 82

3.2.14. ESEL MO: 3G Data RLP Sessions ................................................................. 833.2.14.1. 3G Data RLP Session Successes ............................................................... 843.2.14.2. 3G Data RLP Session Failures .................................................................. 84

3.3. Performance Formulas for 3G Forward Supplemental ChannelData (ESEL MO) 85

3.3.1. Forward Burst Setup Success .......................................................................... 853.3.2. Forward Burst Setup Failures.......................................................................... 863.3.3. Forward SCH Blocks ...................................................................................... 87

3.3.3.1. Detailed Forward SCH Blocks .................................................................. 873.3.4. Forward SCH Access Failures ........................................................................ 893.3.5. Forward SCH Time Out .................................................................................. 903.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........................................................................... 913.4.2. Reverse Burst Setup Failures .......................................................................... 923.4.3. Reverse SCH Blocks ....................................................................................... 93

3.4.3.1. Detailed Reverse SCH Blocks................................................................... 933.4.4. Reverse SCH Access Failures ......................................................................... 953.4.5. Reverse SCH Time Out................................................................................... 953.4.6. Reverse SCH Data Rate Downgrades ............................................................. 96

3.5. Performance Formulas for BTS Managed Objects (MOs) 973.5.1. Advanced Sector 3G Fundamental Channel Formulas ................................... 97

3.5.1.1. 3G FCH Originations ................................................................................ 973.5.1.2. 3G FCH Soft Handoff Blocks ................................................................. 1003.5.1.3. 3G Average number of FCH Handoff Links ........................................... 103

3.5.2. Advanced Sector 3G Supplemental Channel Formulas ................................ 1043.5.2.1. 3G SCH Burst 1053.5.2.2. 3G SCH Handoff Blocks 1073.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



4.1. Access Failures 1134.1.1. Access failures during originations and terminations: (CAUERLFL) .......... 1154.1.2. Access failures during hard handoffs: (CAUHRLFL) .................................. 115

4.2. Blocks 1164.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE).................. 1174.2.2. Blocking due to lack of Walsh codes: (CAUNOWCD)................................ 1174.2.3. Blocking due to lack of forward capacity: (CAUFWCAP)........................... 1184.2.4. Blocking due to lack of reverse capacity: (CAURECAP)............................. 1184.2.5. Blocking due to lack of physical resources: .................................................. 1194.2.6. Blocking due to no frame offset availability: (CAUNOFOF)....................... 1194.2.7. Blocking due to BTS time-outs:.................................................................... 1204.2.8. Blocking due to BSC time-outs and software faults: .................................... 120

4.3. Drops 1214.3.1. Drops due to RF-related reasons: (CAUDROPR)......................................... 1224.3.2. Drops due to network-related reasons: (CAUDROPN) ................................ 122

5. New Operational Measurements in 3G 1xRTT 1245.1. OM Groups: CAUSCT3V, CAUSCT3D 1245.2. OM Groups: CAURFQ3V, CAUFRQ3D 1285.3. OM Group: CAUDAT3G 1315.4. OM Group: RMU3G (RMU OMs for 3G calls) 1325.5. OM Group: CDMAPDOM (CDMA Packet Data) 1335.6. OM Group: CDMAPDSO (CDMA Packet Data Service Option) 1345.7. OM Group: CAURM 1355.8. OM Group: CAUCPSYS 1365.9. OM Group: CDMAPGZN 1365.10. OM Group: PCU 1375.11. OM Group: ESEL 1395.12. OM Group: BTSCallProcessing MO 1415.13. OM Group: Advanced Frequency Assignment (FA) MO 1425.14. OM Group: Advanced Sector MO 143

6. List Of Operational Measurements (OMs) Requested BySprint From Nortel And Other Vendors 148

7. References 165



1. Introduction1xRTT, also known as cdma2000, is a wideband, spread-spectrum radio interface that usescode 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 Nortel’s new 3G 1xRTTOperational Measurements and related 3G 1xRTT Performance Formulas that should bemonitored in the field. The audience for this document is RF engineers that are working withthe 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 inSection 3.

Nortel plans to add more Operational Measurements in the future and for that reason thisdocument will need to be updated. List of all requested Operational Measurements as wellas current Operational Measurements availability for all vendors can be found in Section 6

Operational Measurements (OMs) are counts of call processing events that provide theoperating company with performance data for the DMS-MTX system. System engineers useOM records to ensure that the DMS-MTX switch operates efficiently. OMs provideinformation regarding system performance, grade of service being offered, connectingfacilities, performance, and traffic levels of various elements internal to and connected to thesystem.

This document is based on Nortel Networks documentation (see references in Section 7), 3GFMA test results and 2G experience.

It is assumed that the reader has basic technical knowledge of 1xRTT standard and 2GOperational Measurements experience.



2. Overview of 3G Voice and Data in NortelImplementationThe following table provides the list of additional hardware and software that is required forthe 1xRTT networks:

Table 2-1: 1xRTT Hardware/Software RequirementsDevice Hardware Software

BTS XCEM NBSS10.1.x

SCI-SBSC

ESEL

NBSS10.1.x

MSC MTX10

PC CDF Editor v1.1

MTX10/NBSS10.1.x is the baseline software that is used to provide the 3G capability in theexisting 2G networks. There are many new parameters that are added in this softwarerelease; however, we will concentrate our efforts on the RF related parameters. Morespecifically, 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 tothe 3G calls. Additionally, some existing OMs are enhanced to capture the 3G call-relatedevents. The detailed description of all the 3G OMs is provided in Section 5 of thisdocument. Nortel OMs are categorized based on the location where these OMs are gettingpegged, as follows:

MSC OMs:Eight new OM groups have been added in the MSC that are pegged at the CM and CAUand/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)



In addition to the above OM groups, the following OM groups have been modified for1xRTT 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 byindexing 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 theOMs 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 3Gvoice and 3G data OM counts for a particular sector only if OM3G Bool is set to “Y”. If aparticular sector is 3G capable but OM3G is set to “N”, then the 3G voice and 3G data OMcounts are lumped together with the 2G OMs in the CAUCPSCT and CAUCPFRQ OMgroups. 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 BoolOM3GBool

Impact on CAUCPSCT andCAUCPFRQ OM groups

Impact on CAUSCT3V andCAUFRQ3V OM groups

Impact on CAUSCT3D andCAUFRQ3D OM groups

Y The registers in these two OMgroups get pegged only for eventsrelated to 2G calls

The registers in these two OMgroups get pegged only for eventsrelated to 3G Voice calls

The registers in these two OMgroups get pegged only for eventsrelated to 3G Data calls

N The registers in these two OMgroups get pegged only for all call-related events (3G Voice, 3GData, and 2G calls)

The registers in these two OMgroups do not get pegged. Therelated 3G voice call-specificevents will be captured inCAUCPSCT and CAUCPFRQOM groups along with 3G Dataand 2G call-related events

The registers in these two OMgroups do not get pegged. Therelated 3G Data call-specificevents will be captured inCAUCPSCT and CAUCPFRQOM groups along with 3G voiceand 2G call-related events



MCTA OMs:The MSC has another set of OMs available under the MCTA reports. The MCTAperformance reflects how well the system is allocating resources across multiple frequenciesfor new originations, terminations, and hard handoff attempts from other CDMA cells. Theperformance is determined on a per frequency basis. MCTA OMs do not replace the normalcall 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 thesetup 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 supplementalchannels, 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 tothe base station subsystem manager (BSSM) every 30 minutes in the form of aConsolidatedOM Event Report, using the mechanism developed for the CDMA-LTXproduct.

BTS OMs:The RF-related BTS OMs are collected by the following five managed objects (MOs):

• BTSCallProcessingThese OMs are pegged on a per-BTS basis. Each of these pegs is the sum of all events inevery frequency and every sector hosted by the BTS.

• Advanced FA MOAdvanced Frequency Assignment (FA) OMs deal with the status of XCEM resources onthe fundamental as well as the supplemental channels.

• CBCM MOThe CBCM provides management of the entire MCBTS, communications over the T1/E1and to the mate DCG. The CBCM hardware is composed of the BTS controller and theBTS Interface.

• Power Management MOThese are pegged on a per CDMA frequency, per-sector basis for all the supportedfrequencies.



• Advanced Sector MOThese are pegged on a per-sector basis for all of the supported frequencies. Eventspegged in these OMs include BTS resource allocations, call attempts blocks and handoffblocks.



3. Performance Formulas

This section lists the 1xRTT performance formulas for 3G voice, 3G data, and 3G forwardand 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 arecurrently being used on a daily basis for performance monitoring. For these formulas, wehave the field data available.

2. Formulas for which no reports are available in the ePerformance tool: These are detailedformulas with specific information. For example, 3G voice call blocks due to lack ofWalsh codes. For this type of formulas, no reports or plots are currently provided in thetool. However, the OMs relating to these formulas are pegged; and are available in theraw format. The field result values for these can be calculated by post processing the rawdata.

3. Formulas not supported by the ePerformance tool: For these formulas, the relevant OMsare 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 manyperformance formulas. This is because the data calls are mostly collected from a very smallset of sectors. Additionally, the number of data users (data call attempts) are not sufficientto validate test results. Therefore, it is not possible to provide field result ranges that arestatistically valid at this point in time. However, as more field results become availablefrom 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



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 callattempts downgraded to 2G. The FchOriginationNonBlocking3Gdowngrade2G isa BTS OM which is pegged when the BTS runs out of XCEM resources but stillhas CEM resources and all other needed resources to be set up for the call as a 2Gvoice call rather than a 3G voice call as requested.

OMsCAU Origination SUCCessCAUOSUCCPegged 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 SUCCessCAUTSUCCPegged when a mobile-terminated call successfully arrives on the traffic channel.

CAU hard Handoff SUCCessCAUHSUCCPegged when a mobile, attempting a hard handoff, successfully arrives on thetraffic channel in the target sector.

CAU Origination ATTemptSCAUOATTSPegged when the CAU receives an origination message from the BTS. Test calloriginations are pegged in a separate OM.

CAU PaGe RESponseCAUPGRESFor mobile-terminated calls, attempts are recorded in CAUPGRES, whichindicates that a page response was received from a CDMA sector in response to apage request (irrespective of whether it was in response to an initial page requestor a retry by the CM).



CAU hard Handoff ATTemptSCAUHATTSPegged when the CAU receives a ReadyNewCell message from the CM,indicating that a hard handoff attempt sequence in a (CDMA) target sector shouldbegin.

FchOriginationNonBlocking3GDowngrade2GNumber of successful BTS resource allocations for fundamental channel 2G callswhich were downgraded from 3G calls attempts. This metric does not includenon-reference pilot links setup for CASHO. 2G links, other than the referencepilot’s 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 ePerformancetool does not take into account 3G call attempts downgraded to 2G. TheFchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged whenthe BTS runs out of XCEM resources but still has CEM resources and all otherneeded resources to be set up for the call as a 2G voice call rather than a 3G voicecall as requested.

Formula

Total Blocks% = [Total number of blocked calls / Total calls attempted] * 100

Total number of blocked calls =CAUSCT3V.CAUOBLKS +CAUSCT3V.CAUTBLKS +



CAUSCT3V.CAUHBLKSTotal calls attempted

CAUSCT3V.CAUOATTS +CAUSCT3V.CAUPGRES +CAUSCT3V.CAUHATTS –FchOriginationNonBlocking3GDowngrade2G

OMsCAU Origination BLocKSCAUOBLKSPegged any time a mobile-originated call setup fails due to resource shortage. Itrepresents the total number of origination setup failures in a sector, regardless ofresource. The same failure reasons that are pegged for CAUTBLKS can be peggedin conjunction with CAUOBLKS.

CAU Termination BLocKSCAUTBLKSPegged any time a mobile-terminated call setup fails due to resource shortage. Itrepresents 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 conjunctionwith CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP andCAUESWFL.

CAU hard Handoff BLocKSCAUHBLKSPegged any time a CDMA-to-CDMA hard handoff setup fails due to resourceshortage. 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 hardhandoff attempts. CAUHBLKS is not the number of dropped hard handoffs, itmerely represents the number of times that a hard handoff could not be completeddue to resource shortages in the target cell/sector—the call in the source cell isstill up. The same failure reasons that are pegged for CAUOBLKS (see previouspage) can be pegged in conjunction with CAUHBLKS.


CAU PaGe RESponseCAUPGRES



For mobile-terminated calls, attempts are recorded in CAUPGRES, whichindicates that a page response was received from a CDMA sector in response to apage request (irrespective of whether it was in response to an initial page requestor a retry by the CM).



Field Results

• Day 1: 0.02 %

• Day 2: 0.01 %

• Day 3: 0.07 %

• Day 4: 0.13 %


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. Forfrequency 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 +



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



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

OMsCAU NO Traffic Channel ElementCAUNOTCEPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time aBTS reports no traffic channel element via NOIS messages, regardless oforigination, termination or hard handoff.

CAU NO Walsh CodeCAUNOWCDPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time aBTS reports no walsh code via NOIS messages, regardless of origination,termination or hard handoff.

CAU NO Frame OffsetCAUNOFOFPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS cannot allocate resources due to some CSM 5000 hardware limitation. TheCSM 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 anbe active on a frame offset (and adjacent frame offsets).

CAU ForWard CAPacity fullCAUFWCAPPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS reports forward capacity full via NOIS messages, regardless of origination,termination or hard handoff.

CAU REverse CAPacity fullCAURECAPPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS reports reverse capacity full via NOIS messages, regardless of origination,termination or hard handoff. However, currently there is no reliable mechanismfor estimating reverse link capacity and so this response is disabled on the BTS.Consequently, this OM is never pegged.

Resource Manager NO Resources for REQuestRMNORREQPegged, 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 doesnot message to any of its SBSs to determine availability, only internal datastructures are checked.

CAU Error case, Radio Setup FaiLureCAUERSFLPegged, along with the appropriate CAU*BLKS OM, whenever a call setup failsdue to the fact that some BTS resource is not available. This OM is also peggedwhen the BTS does not respond to resource requests. It is also pegged when theCarrier Determination Algorithm (CDA) fails to select a carrier in an MCTAenabled sector (that is, no available capacity on all co-located carriers).

MCTA REQuest FailureMCTAREQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby MCTA for origination or termination call setup. It is pegged on a per-sectorbasis. The failure reasons are pegged by MCTAMIXF, MCTALLTO orMCTALLFU.

MCTA Handoff ReQuest FailureMCTAHRQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby 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 orMCTALLFU.

RM SRM Time-OutRMSRMTOPegged, along with the appropriate CAU*BLKS OM, when the ResourceManager times out waiting on a request for call resources from the SRM.

RM Service Resource Manager Negative AcKRMSRMNAKPegged, along with the appropriate CAU*BLKS OM, when the ResourceManager (RM) receives a resource allocation failure indication from SRMs. Thisis an error condition, indicating mismatches between the RM and the SBS SRM.

BlockedFchOriginations 3GvoiceArray indicating the number of 3G voice call attempts blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason.

CAU Error case, SoftWare FauLtCAUESWFLPegged, along with the appropriate CAU*BLKS OM, whenever a call setup failsdue to time outs between software entities that should not occur (for example, noresponse from the CM, failure message received from SBS, etc.).







Field Results: TCE WalshC NframO FwdC RevC PhyR BTSt-o BSCt-o

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


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 ePerformancetool does not take into account 3G call attempts downgraded to 2G. TheFchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is peggedwhen the BTS runs out of XCEM resources but still has CEM resources and allother needed resources to be set up for the call as a 2G voice call rather than a 3Gvoice 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



OMsCAU Error Radio Link FaiLureCAUERLFLPegged if the origination or termination fails because the mobile never arrived onthe traffic channel (similar to SAT timeout). CAUERLFL is not pegged in caseswhere the CAUOBLKS or CAUTBLKS OMs are pegged.

CAU hard Handoff Radio Link FaiLureCAUHRLFLPegged if the hard handoff attempt fails because the mobile never arrived on thetarget sector’s traffic channel (similar to SAT timeout). CAUHRLFL is notpegged in cases where CAUHBLKS is pegged.





Field Results

• Day 1: 2.17 %

• Day 2: 2.26 %



• Day 3: 2.07 %

• Day 4: 1.97 %


It should match the 2G Voice Access Failures.

3.1.3.1. Detailed 3G Voice Access Failures


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









Field Results: Orig&Term Hard Handoff

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


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



Number of drop calls =CAUSCT3V.CAUDROPR +CAUSCT3V.CAUDROPN

Number of successful calls =CAUSCT3V.CAUOSUCC +CAUSCT3V.CAUTSUCC +CAUSCT3V.CAUHSUCC

OMsCAU DROPped call RfCAUDROPRPegged by the CAU against the reference pilot when a call is dropped by the SBSdue 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 theSBS.

CAU DROPped call NetworkCAUDROPNPegged by the CAU when any of the other (non-RF) drop indication reasons aresent from the SBS in the radio link drop indication message.

CAU Origination SUCCessCAUOSUCCPegged when a mobile-originated call successfully arrives on the traffic channel.This includes all originations placed on the traffic channel to receive treatment.



Field Results

• Day 1: 2.05 %

• Day 2: 2.29 %

• Day 3: 1.91 %



• Day 4: 1.84 %



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








Field Results: RF-related Network-related

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



3.1.5. 3G Voice Pre-MCTA Frequency Selection FailuresThis section deals with failures that occur before the Carrier DeterminationAlgorithm (CDA) has selected a frequency. The following formula captures callfailures 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



NOTE: ΣCAUFRQ3V refers to the sum of the register for all frequencies on thesector.

OMsMCTA REQuest FailureMCTAREQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby MCTA for origination or termination call setup. It is pegged on a per-sectorbasis. The failure reasons are pegged by MCTAMIXF, MCTALLTO orMCTALLFU.

MCTA Handoff ReQuest FailureMCTAHRQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby MCTA for a hard handoff call setup. It is pegged on a per-sector basis on thetarget side. The failure reasons are pegged by MCTAMIXF, MCTALLTO orMCTALLFU.

MCTA ORIGinationMCTAORIGPegged, along with CAUOATTS, when the CAU receives an origination messagefrom a sector that has MCTA enabled. It is pegged against the originatingfrequency. Test call originations are pegged in a separate OM.

MCTA PaGe RESponseMCTAPGRESFor mobile-terminated calls, attempts are recorded in MCTPGRES, whichindicates that a page response was received from an MCTA enabled CDMAsector in response to a page request. This OM is pegged irrespective of whether itwas the first or the second attempt to page the mobile. CAUPGRES is also peggedwhenever MCTPGRES is pegged.

MCTA Handoff Call ATTemptsMCTHCATTPegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin.

Field Results

• Day 1: 0.97 %



• Day 2: 0.97 %

• Day 3: 1.28 %

• Day 4: 0.98 %


It should match the 2G Voice Pre-MCTA Frequency Selection Failures

3.1.6. 3G Voice Pre-MCTA Resource Allocation Failures (perfrequency)

This section deals with the events where a particular frequency responds with aresource full response or times out in response to a capacity query request beforethe Carrier Determination Algorithm (CDA) is executed. Note that this event mayor may not lead to overall MCTA frequency selection failure depending onwhether all other frequencies respond with a similar response or not. If at least onefrequency responds with a resource available response then the CDA willsuccessfully 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

OMsMCTA REQuest FailureMCTAREQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby MCTA for origination or termination call setup. It is pegged on a per-sector



basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO orMCTALLFU.


MCTA REQuest response full or Not availableMCTAREQNPegged when a frequency was successfully selected by MCTA but one or more ofthe BTSs responded with a resource full or not available response. MCTAREQNis pegged against the carrier(s) that respond with a resource full or not availableresponse. MCTAREQN may not always be pegged under low load conditions.

MCTA REQuest TimeoutMCTAREQTPegged when a frequency was successfully selected by MCTA but one or more ofthe BTSs never responded to a capacity request. MCTAREQT is pegged againstthe carrier(s) that did not respond to the capacity request. MCTAREQT may notalways be pegged under low traffic load conditions.



MCTA Handoff Call ATTemptsMCTHCATT



Pegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin.

Field Results

• Day 1: 0.00 %

• Day 2: 0.00 %

• Day 3: 0.00 %

• Day 4: 0.00 %


It should match the 2G Voice Pre-MCTA Resource Allocation Failures.

3.1.6.1. Detailed 3G Voice Pre-MCTA Resource Allocation Failures (perfrequency)

Formulas

The following set of formulas deal with the percentage of MCTA frequencyresource allocation failures resulting due to lack of physical resources before theCarrier 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 +



CAUFRQ3V.MCTHCATT)] * 100

Case 2: Failures NOT leading to overall MCTA frequency selection failureNo Rsrc% = [CAURFQ3V.MCTAREQN

/(CAUFRQ3V.MCTORIGS +CAUFRQ3V.MCTPGRES +CAUFRQ3V.MCTHCATT)] * 100

The following set of formulas deal with the percentage of MCTA frequencyresource allocation failures resulting due to time-outs before the CarrierDetermination 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 failureTime Out% = [CAUFRQ3V.MCTAREQT

/(CAUFRQ3V.MCTORIGS +CAUFRQ3V.MCTPGRES +CAUFRQ3V.MCTHCATT)] * 100

OMsMCTA REQuest response full or Not availableMCTAREQNPegged when a frequency was successfully selected by MCTA but one or more ofthe 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 availableresponse. MCTAREQN may not always be pegged under low load conditions.


MCTA All frequencies FullMCTALLFUPegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), whenNO frequency was successfully selected by MCTA because none of the BTSs hadresources available. It is pegged on a per-sector basis.

MCTA ReQuest response Failed (full or Not available)MCTARQFNPegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF orMCTAHRQF), when no frequency was successfully selected by MCTA becausesome BTSs timed out, while some responded with a resource full or not availableresponse. MCTARQFN is pegged against the carrier(s) that respond with aresource full or not available response.

MCTA ALL frequencies Timed-OutMCTALLTOPegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), whenNO frequency was successfully selected by MCTA because none of the BTSsresponded to the capacity request query. It is pegged on a per-sector basis.

MCTA MIXed FailureMCTAMIXFPegged, along with CAUERSFL and MCTARQFN and (MCTAREQF orMCTAHRQF), when NO frequency was successfully selected by MCTA becausesome BTSstimed-out while some responded with a resource full or not available response. Itis pegged on a per-sector basis.

MCTA ORIGinationMCTORIGSPegged, along with CAUOATTS, when the CAU receives an origination messagefrom a sector that has MCTA enabled. It is pegged against the originatingfrequency. Test call originations are pegged in a separate OM.



MCTA PaGe RESponseMCTPGRESFor mobile-terminated calls, attempts are recorded in MCTPGRES, whichindicates that a page response was received from an MCTA enabled CDMAsector in response to a page request. This OM is pegged irrespective of whether itwas the first or the second attempt to page the mobile. CAUPGRES is also peggedwhenever MCTPGRES is pegged.

MCTA Handoff Call ATTemptsMCTHCATTPegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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 whencompared 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



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 thesector.

OMsMCTA Origination ATTemptSMCTOATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).

MCTA Termination ATTemptSMCTTATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile termination in a sector with MCTAenabled.

MCTA Handoff ATTemptSMCTHATTSPegged when an MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile hard handoff attempt into a targetsector with MCTA enabled.

Field Results: Freq1 Freq2 Freq3

• Day 1: 44 % 38 % 17 %

• Day 2: 44 % 59 % 15%

• Day 3: 37 % 50 % 13 %

• Day 4: 40 % 42 % 17 %


It should match the 2G Voice Post-MCTA Traffic Distribution.



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 aparticular 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

OMsMCTA Origination SUCCessMCTOSUCCPegged, along with CAUOSUCC, when a mobile-originated call successfullyarrives on the traffic channel. This includes all originations placed on the trafficchannel to receive treatment.

MCTA Termination SUCCessMCTTSUCCPegged, along with CAUTSUCC, when a mobile-terminated call successfullyarrives on the traffic channel.

MCTA Hard-handoff SUCCessMCTHSUCCPegged, along with CAUHSUCC, when a mobile successfully arrives on thetraffic channel after a hard handoff.

MCTA Origination ATTemptSMCTOATTSPegged when an MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).



MCTA Termination ATTemptSMCTTATTSPegged when an MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile termination in a sector with MCTAenabled.



• Day 1: 95 % 93 % 96 %

• Day 2: 94.48 % 94.57 % 94.75 %

• Day 3: 94.49 % 94.67 % 95.33 %

• Day 4: 94.00 % 95.00 % 94.50 %


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 beenselected 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




OMsMCTA Error case Radio link Setup FaiLureMCTERSFLPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenevera call setup fails due to the fact that the BTS could not allocate resources due toany of the BTS failure reasons. This OM is also pegged when the BTS does notrespond at all to resource requests. MCTERSFL is pegged only after an MCTAfrequency is selected. MCTERSFL is pegged against the selected frequency.





• Day 1: 0.00 % 0.00 % 0.00 %

• Day 2: 0.00 % 0.00 % 0.00 %

• Day 3: 0.00 % 0.00 % 0.00 %

• Day 4: 0.00 % 0.00 % 0.00 %




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 MCTAfrequency has been selected and the call setup is attempted on the selectedfrequency.

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 /


Blocks due to no frame offset availability:Frame Offset% = [CAUFRQ3V.MCTNOFOF /


Blocks due to lack of forward capacity:FWDCAP% = [CAUFRQ3V.MCTFWCAP /


Blocks due to lack of reverse capacity:REVCAP% = [CAUFRQ3V.MCTRECAP /


OMs



MCTA NO Traffic Channel ElementMCTNOTCEPegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports no traffic channel elementvia 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 CodeMCTNOWCDPegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOISmessages, regardless of origination, termination or hard handoff. MCTNOWCDis pegged only after an MCTA frequency is selected. MCTNOWCD is peggedagainst the selected frequency.

MCTA NO Frame OffsetMCTNOFOFPegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS cannot allocate resources due tosome CSM 5000 hardware limitation. The CSM 5000 is limited in how muchtraffic it can support on its reverse link because of the limitation on the number ofdecoding units (both Viterbi and Turbo) that can be active on a frame offset (andadjacent frame offsets). MCTNOFOF is pegged only after an MCTAfrequency is selected. MCTNOFOF is pegged against the selected frequency

MCTA ForWard CAPacity fullMCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports forward capacity full viaNOIS 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 fullMCTRECAPPegged, along with MCTERSFL and CAURECAP and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports reverse capacity full viaNOIS 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 ATTemptSMCTOATTS



Pegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).


MCTA Handoff ATTemptSMCTHATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile hard handoff attempt into a targetsector with MCTA enabled.

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



3.1.10. 3G Voice Post-MCTA Access Failures (per frequency)

This is the percentage of access failures after the MCTA frequency has beenselected and resources are successfully setup on the selected frequency.

Formula

Acc Fails% = [Number of MCTA access failures / Total calls attempted] * 100



Number of MCTA access failures =CAURFQ3V.MCTERLFL +CAUFRQ3V.MCTHRLFL


OMsMCTA Error case, Radio Link FaiLureMCTERLFLPegged, along with CAUERLFL, if the origination or termination fails becausethe mobile never arrived on the traffic channel (similar to SAT timeout).MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMsare pegged.

MCTA hard Handoff Radio Link FaiLureMCTHRLFLPegged, along with CAUHRLFL, if the hard handoff attempt fails because themobile never arrived on the target sector’s traffic channel (similar toSAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM ispegged.

MCTA Origination ATTemptSMCTOATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).






• Day 1: 1.44 % 2.71 % 1.39 %

• Day 2: 1.84 % 2.50 % 2.12 %

• Day 3: 1.78 % 1.95 % 2.33 %

• Day 4: 1.53 % 1.74 % 1.85 %


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 theMCTA frequency has been selected and resources are successfully setup on theselected frequency.

Formulas

Access failures during originations or terminations:Orig & Term% = [CAURFQ3V.MCTERLFL

/(CAUFRQ3V.MCTOATTS +CAUFRQ3V.MCTTATTS)] * 100


Handoff% = [CAURFQ3V.MCTHRLFL / CAUFRQ3V.MCTHATTS] *100


MCTA hard Handoff Radio Link FaiLureMCTHRLFL



Pegged, along with CAUHRLFL, if the hard handoff attempt fails because themobile never arrived on the target sector’s traffic channel (similar toSAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM ispegged.




Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A




3.1.11. 3G Voice Post-MCTA RF related Drop Calls (perfrequency)

This is the percentage of established calls on each frequency in MCTA enabledsectors 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

OMsMCTA DROPped call RfMCTDROPRPegged, along with CAUDROPR, when a call is dropped by the SBS due to “lossof traffic” or due to “HCM (handoff completion message) timeout” for soft orsofter handoff. These are RF-related call failures as detected by the SBS.


MCTA Origination SUCCessMCTOSUCCPegged, along with CAUOSUCC, when a mobile-originated call successfullyarrives on the traffic channel. This includes all originations placed on the trafficchannel to receive treatment.


MCTA Hard-handoff SUCCess



MCTHSUCCPegged, along with CAUHSUCC, when a mobile successfully arrives on thetraffic channel after a hard handoff.


• Day 1: 2.98 % 1.49 % 1.03 %

• Day 2: 3.24 % 1.43 % 1.31 %

• Day 3: 2.87 % 1.21 % 1.08 %

• Day 4: 2.01 % 1.34 % 1.03 %


It should match the 2G Voice Post-MCTA RF related Drop Calls

3.2. Performance Formulas for 3G Fundamental ChannelData

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

OMsCAU Origination SUCCessCAUOSUCCPegged when a mobile-originated call successfully arrives on the traffic channel.This includes all originations placed on the traffic channel to receive treatment.








Field Results

• Day 1: 81.87 %

• Day 2: 70.09 %

• Day 3: 84.01 %

• Day 4: 82.78 %


It should match the 3G Voice Call Success.



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 attemptedCAUSCT3D.CAUOATTS +CAUSCT3D.CAUPGRES +CAUSCT3D.CAUHATTS


CAU Termination BLocKSCAUTBLKSPegged any time a mobile-terminated call setup fails due to resource shortage. Itrepresents 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 conjunctionwith CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP andCAUESWFL.

CAU hard Handoff BLocKSCAUHBLKSPegged any time a CDMA-to-CDMA hard handoff setup fails due to resourceshortage. 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 hardhandoff attempts. CAUHBLKS is not the number of dropped hard handoffs, itmerely represents the number of times that a hard handoff could not be completeddue to resource shortages in the target cell/sector—the call in the source cell is



still up. The same failure reasons that are pegged for CAUOBLKS (see previouspage) can be pegged in conjunction with CAUHBLKS.




Field Results

• Day 1: 3.72 %

• Day 2: 0.00 %

• Day 3: 0.08 %

• Day 4: 0.00 %


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. Forfrequency level information, please refer Section 3.2.10.1

Formulas



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 /


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 /




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


CAU Termination BLocKSCAUTBLKS



Pegged any time a mobile-terminated call setup fails due to resource shortage. Itrepresents 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 conjunctionwith CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP andCAUESWFL.

CAU hard Handoff BLocKSCAUHBLKSPegged any time a CDMA-to-CDMA hard handoff setup fails due to resourceshortage. 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 hardhandoff attempts. CAUHBLKS is not the number of dropped hard handoffs, itmerely represents the number of times that a hard handoff could not be completeddue to resource shortages in the target cell/sector—the call in the source cell isstill up. The same failure reasons that are pegged for CAUOBLKS (see previouspage) can be pegged in conjunction with CAUHBLKS.

CAU NO Traffic Channel ElementCAUNOTCEPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time aBTS reports no traffic channel element via NOIS messages, regardless oforigination, termination or hard handoff.

CAU NO Walsh CodeCAUNOWCDPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time aBTS reports no walsh code via NOIS messages, regardless of origination,termination or hard handoff.

CAU NO Frame OffsetCAUNOFOFPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS cannot allocate resources due to some CSM 5000 hardware limitation. TheCSM 5000 is limited in how much traffic it can support on its reverse link becauseof the limitation on the number of decoding units (both Viterbi and Turbo) that anbe active on a frame offset (and adjacent frame offsets).

CAU ForWard CAPacity fullCAUFWCAPPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS reports forward capacity full via NOIS messages, regardless of origination,termination or hard handoff.



CAU REverse CAPacity fullCAURECAPPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any timea BTS reports reverse capacity full via NOIS messages, regardless of origination,termination or hard handoff. However, currently there is no reliable mechanismfor 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 callsNORREQ3DPegged only in cases of 3G Packet Data calls. NORREQ3D is pegged, along withthe appropriate CAU*BLKS OM, when Resource Manager (RM) has no availableresources to allocate for a call. In this case, the RM does not message to any of itsSBSs to determine availability, only internal data structures are checked.

CAU Error case, Radio Setup FaiLureCAUERSFLPegged, along with the appropriate CAU*BLKS OM, whenever a call setup failsdue to the fact that some BTS resource is not available. This OM is also peggedwhen the BTS does not respond to resource requests. It is also pegged when theCarrier Determination Algorithm (CDA) fails to select a carrier in an MCTAenabled sector (that is, no available capacity on all co-located carriers).

MCTA REQuest FailureMCTAREQFPegged, along with CAUERSFL, when NO frequency was successfully selectedby MCTA for origination or termination call setup. It is pegged on a per-sectorbasis. The failure reasons are pegged by MCTAMIXF, MCTALLTO orMCTALLFU.


Blocked Fch Originations 3G DataBlockedFchOriginations3GDataArray indicating the number of 3G data sessions blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason.



SRM Time-Out for 3G Data callsSRMTO3DPegged only in cases of 3G Packet Data calls. SRMTO3D is pegged, along withthe appropriate CAU*BLKS OM, when Resource Manager times out waiting on arequest for call resources from the SRM.

Service Resource Manager Negative AcK for 3G Data callsSRMNAK3DPegged only in cases of 3G Packet Data calls. SRMNAK3D is pegged, along withthe appropriate CAU*BLKS OM, when Resource Manager (RM) receives aresource allocation failure indication from SRMs. This is an error condition,indicating mismatches between the RM and the SBS SRM.

CAU Error case, SoftWare FauLtCAUESWFLPegged, along with the appropriate CAU*BLKS OM, whenever a call setup failsdue to time outs between software entities that should not occur (for example, noresponse from the CM, failure message received from SBS, etc.).




Field Results: Orig Term HandO TCE WalshC NframO FwdC

• Day 1: example

• Day 2: example



• Day 3: example

• Day 4: example

Field Results: RevC PhyR BTSt-o BSCt-o

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



3.2.3. 3G Packet Data Access Failure

Formula


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 mobilearrives on the traffic channel but before sending the service connect message outto the mobile. Thus if the R-P packet session setup fails, it will still be pegged asan access failure. The TotalSessionSetupFailures (Number of failed packetsession setups) count can be subtracted from the numerator in the above formulawhen measuring the RF Access Failure rate on a system wide basis.

OMs



CAU Error Radio Link FaiLureCAUERLFLPegged if the origination or termination fails because the mobile never arrived onthe traffic channel (similar to SAT timeout). CAUERLFL is not pegged in caseswhere the CAUOBLKS or CAUTBLKS OMs are pegged.





Field Results

• Day 1: 3.19 %

• Day 2: 6.49 %

• Day 3: 3.57 %

• Day 4: 3.39 %





3.2.3.1. Detailed 3G Packet Data Access Failures


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








Field Results: Orig&Term Hard Handoff

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A


3.2.4. 3G Packet Data Drop Calls

Formula


Number of drop calls =CAUSCT3D.CAUDROPR +CAUSCT3D.CAUDROPN

Number of successful calls =CAUSCT3D.CAUOSUCC +CAUSCT3D.CAUTSUCC +CAUSCT3D.CAUHSUCC

OMsCAU DROPped call RfCAUDROPRPegged by the CAU against the reference pilot when a call is dropped by the SBSdue 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 theSBS.





Field Results

• Day 1: 3.24 %

• Day 2: 1.35 %

• Day 3: 2.89 %

• Day 4: 1.21 %


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)

FormulasDrops due to RF-related reasons:



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






Field Results: RF-related Network-related

• Day 1: example



• Day 2: example

• Day 3: example

• Day 4: example



3.2.5. 3G Packet Data Calls Dormant to Active TransitionAverage 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

OMsMobile-Initiated Dormant To Active ATtemptsMIDTOAATPegged when the MSC receives an origination message from a mobile which is ina dormant data call state.

Network-Initiated Dormant To Active ATtemptsNIDTOAATPegged when the MSC receives a PCU_Page_Request after the network DCRPLICF decides to make the transition to active state.

CAU Origination ATTemptSCAUOATTS



Pegged when the CAU receives an origination message from the BTS. Test calloriginations are pegged in a separate OM.



Field Results

• Day 1: 36.56 %

• Day 2: 13.33 %

• Day 3: 51.95 %

• Day 4: 42.23 %


N/A

3.2.6. 3G Data Pre-MCTA Frequency Selection FailuresThis section deals with failures that occur before the Carrier DeterminationAlgorithm (CDA) has selected a frequency. The following formula captures callfailures 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 +



CAUSCT3D.MCTAHRQFTotal calls attempts for all freqs =

ΣΣΣΣCAUFRQ3D.MCTORIGS +ΣΣΣΣCAUFRQ3D.MCTPGRES +ΣΣΣΣCAUFRQ3D.MCTHCATT

NOTE: ΣCAUFRQ3D refers to the sum of the register for all frequencies on thesector.





MCTA Handoff Call ATTemptsMCTHCATT



Pegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin.

Field Results

• Day 1: 1.98 %

• Day 2: 0.98 %

• Day 3: 0.72 %

• Day 4: 1.03 %


It should match the 3G Voice Pre-MCTA Frequency Selection Failures

3.2.7. 3G Data Pre-MCTA Resource Allocation Failures (perfrequency)

This section deals with the events where a particular frequency responds with aresource full response or times out in response to a capacity query request beforethe Carrier Determination Algorithm (CDA) is executed. Note that this event mayor may not lead to overall MCTA frequency selection failure depending onwhether all other frequencies respond with a similar response or not. If at least onefrequency responds with a resource available response then the CDA willsuccessfully 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 +



CAUFRQ3D.MCTHCATT



MCTA REQuest response full or Not availableMCTAREQNPegged when a frequency was successfully selected by MCTA but one or more ofthe BTSs responded with a resource full or not available response. MCTAREQNis pegged against the carrier(s) that respond with a resource full or not availableresponse. MCTAREQN may not always be pegged under low load conditions.



MCTA PaGe RESponseMCTAPGRESFor mobile-terminated calls, attempts are recorded in MCTPGRES, whichindicates that a page response was received from an MCTA enabled CDMAsector 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 peggedwhenever MCTPGRES is pegged.

MCTA Handoff Call ATTemptsMCTHCATTPegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin.

Field Results

• Day 1: 0.00 %

• Day 2: 0.00 %

• Day 3: 0.00 %

• Day 4: 0.00 %


It should match the 3G Voice Pre-MCTA Resource Allocation Failures

3.2.7.1. Detailed 3G Data Pre-MCTA Resource Allocation Failures (perfrequency)

Formulas

The following set of formulas deal with the percentage of MCTA frequencyresource allocation failures resulting due to lack of physical resources before theCarrier 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)



No Rsrc% = [(CAUSCT3D.MCTALLFU +CAURFQ3D.MCTARQFN)/(CAUFRQ3D.MCTORIGS +CAUFRQ3D.MCTPGRES +CAUFRQ3D.MCTHCATT)] * 100

Case 2: Failures NOT leading to overall MCTA frequency selection failureNo Rsrc% = [CAURFQ3D.MCTAREQN

/(CAUFRQ3D.MCTORIGS +CAUFRQ3D.MCTPGRES +CAUFRQ3D.MCTHCATT)] * 100

The following set of formulas deal with the percentage of MCTA frequencyresource allocation failures resulting due to time-outs before the CarrierDetermination 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 failureTime Out% = [CAUFRQ3D.MCTAREQT

/(CAUFRQ3D.MCTORIGS +CAUFRQ3D.MCTPGRES +CAUFRQ3D.MCTHCATT)] * 100



OMsMCTA REQuest response full or Not availableMCTAREQNPegged when a frequency was successfully selected by MCTA but one or more ofthe BTSs responded with a resource full or not available response. MCTAREQNis pegged against the carrier(s) that respond with a resource full or not availableresponse. MCTAREQN may not always be pegged under low load conditions.


MCTA All frequencies FullMCTALLFUPegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), whenNO frequency was successfully selected by MCTA because none of the BTSs hadresources available. It is pegged on a per-sector basis.

MCTA ReQuest response Failed (full or Not available)MCTARQFNPegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF orMCTAHRQF), when no frequency was successfully selected by MCTA becausesome BTSs timed out, while some responded with a resource full or not availableresponse. MCTARQFN is pegged against the carrier(s) that respond with aresource full or not available response.

MCTA ALL frequencies Timed-OutMCTALLTOPegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), whenNO frequency was successfully selected by MCTA because none of the BTSsresponded to the capacity request query. It is pegged on a per-sector basis.

MCTA MIXed FailureMCTAMIXFPegged, along with CAUERSFL and MCTARQFN and (MCTAREQF orMCTAHRQF), when NO frequency was successfully selected by MCTA becausesome BTSstimed-out while some responded with a resource full or not available response. Itis pegged on a per-sector basis.

MCTA ORIGination



MCTORIGSPegged, along with CAUOATTS, when the CAU receives an origination messagefrom a sector that has MCTA enabled. It is pegged against the originatingfrequency. Test call originations are pegged in a separate OM.

MCTA PaGe RESponseMCTPGRESFor mobile-terminated calls, attempts are recorded in MCTPGRES, whichindicates that a page response was received from an MCTA enabled CDMAsector in response to a page request. This OM is pegged irrespective of whether itwas the first or the second attempt to page the mobile. CAUPGRES is also peggedwhenever MCTPGRES is pegged.

MCTA Handoff Call ATTemptsMCTHCATTPegged, along with CAUHATTS, when the CAU receives a message from theCM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMAtarget sector should begin

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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 whencompared 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 =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 thesector.

OMsMCTA Origination ATTemptSMCTOATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).




• Day 1: 35.14 % 36.82 % 28.04 %

• Day 2: 26.52 % 43.86 % 32.43 %

• Day 3: 39.03 % 31.59 % 29.38 %

• Day 4: 36.00 % 38.00 % 24.00 %




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 aparticular 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

OMsMCTA Origination SUCCessMCTOSUCCPegged, along with CAUOSUCC, when a mobile-originated call successfullyarrives on the traffic channel. This includes all originations placed on the trafficchannel to receive treatment.



MCTA Origination ATTemptSMCTOATTS



Pegged when an MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency for MCTOATTS may be differentfrom the MCTA frequency on which the call originated (MCTORIGS).




• Day 1: 93.82 % 94.37 % 92.96 %

• Day 2: 98.09 % 97.94 % 77.08 %

• Day 3: 96.94 % 96.76 % 91.86 %

• Day 4: 97.25 % 96.25 % 92.37 %


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 beenselected 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 =



CAUFRQ3D.MCTERSFLTotal calls attempted =

CAUFRQ3D.MCTOATTS +CAUFRQ3D.MCTTATTS +CAUFRQ3D.MCTHATTS

OMsMCTA Error case Radio link Setup FaiLureMCTERSFLPegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenevera call setup fails due to the fact that the BTS could not allocate resources due toany of the BTS failure reasons. This OM is also pegged when the BTS does notrespond at all to resource requests. MCTERSFL is pegged only after an MCTAfrequency is selected. MCTERSFL is pegged against the selected frequency.





• Day 1: 0.00 % 0.00 % 0.00 %

• Day 2: 0.00 % 0.00 % 0.00 %

• Day 3: 0.00 % 0.00 % 0.00 %



• Day 4: 0.00 % 0.00 % 0.00 %


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 MCTAfrequency has been selected and the call setup is attempted on the selectedfrequency.

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 /


Blocks due to no frame offset availability:Frame Offset% = [CAUFRQ3D.MCTNOFOF /


Blocks due to lack of forward capacity:FWDCAP% = [CAUFRQ3D.MCTFWCAP /


Blocks due to lack of reverse capacity:REVCAP% = [CAUFRQ3D.MCTRECAP /

(CAUFRQ3D.MCTOATTS +CAUFRQ3D.MCTTATTS +



CAUFRQ3D.MCTHATTS)] * 100

OMsMCTA NO Traffic Channel ElementMCTNOTCEPegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports no traffic channel elementvia 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 CodeMCTNOWCDPegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOISmessages, regardless of origination, termination or hard handoff. MCTNOWCDis pegged only after an MCTA frequency is selected. MCTNOWCD is peggedagainst the selected frequency.

MCTA NO Frame OffsetMCTNOFOFPegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS cannot allocate resources due tosome CSM 5000 hardware limitation. The CSM 5000 is limited in how muchtraffic it can support on its reverse link because of the limitation on the number ofdecoding units (both Viterbi and Turbo) that can be active on a frame offset (andadjacent frame offsets). MCTNOFOF is pegged only after an MCTAfrequency is selected. MCTNOFOF is pegged against the selected frequency

MCTA ForWard CAPacity fullMCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports forward capacity full viaNOIS 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 fullMCTRECAPPegged, along with MCTERSFL and CAURECAP and CAUERSFL and theappropriate CAU*BLKS OM, any time a BTS reports reverse capacity full viaNOIS 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.




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 beenselected and resources are successfully setup on the selected frequency.



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





MCTA Handoff ATTemptS



MCTHATTSPegged when a MCTA frequency is successfully selected by the CarrierDetermination Algorithm (CDA) for a mobile hard handoff attempt into a targetsector with MCTA enabled.


• Day 1: 3.93 % 2.14 % N/A %

• Day 2: 1.91 % 1.65 % N/A %

• Day 3: 1.94 % 1.68 % N/A %

• Day 4: 1.89 % 1.75 % N/A %


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 theMCTA frequency has been selected and resources are successfully setup on theselected frequency.

Formulas

Access failures during originations or terminations:Orig & Term% = [CAURFQ3D.MCTERLFL

/(CAUFRQ3D.MCTOATTS +CAUFRQ3D.MCTTATTS)] * 100


Handoff% = [CAURFQ3D.MCTHRLFL / CAUFRQ3D.MCTHATTS] *100

OMsMCTA Error case, Radio Link FaiLureMCTERLFLPegged, along with CAUERLFL, if the origination or termination fails becausethe mobile never arrived on the traffic channel (similar to SAT timeout).



MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMsare pegged.





Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A




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 enabledsectors 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

OMsMCTA DROPped call RfMCTDROPRPegged, along with CAUDROPR, when a call is dropped by the SBS due to “lossof traffic” or due to “HCM (handoff completion message) timeout” for soft orsofter handoff. These are RF-related call failures as detected by the SBS.


MCTA Origination SUCCessMCTOSUCCPegged, along with CAUOSUCC, when a mobile-originated call successfullyarrives on the traffic channel. This includes all originations placed on the trafficchannel to receive treatment.






• Day 1: 5.09 % 4.83 % 0.38 %

• Day 2: 1.95 % 1.26 % 0.68 %

• Day 3: 2.71 % 3.91 % 1.27 %

• Day 4: 1.89 % 2.06 % 0.97 %


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 L2TPand PPP processing. L2TP is an Internet protocol defined in RFC 2661 thatprovides a method of encapsulating PPP packets so that they can be transportedacross an intervening IP network. This “tunneling” of PPP is transparent to end-users and applications. The purpose of the protocol is to allow the layer 2endpoint and the PPP endpoint to be located on separate devices that areconnected 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, whereas unreliable are not. Reliable packets are used for establishment and control ofthe L2TP tunnel and of the packet sessions established within that tunnel. Thebearer data packets that are sent during the session are sent using unreliabletransmission, the quality of service responsibility having been passed to upperlayer protocols (for example, TCP).

For 3G packet data calls, even after the SBS and BTS resources are successfullysetup for the call, and even after the mobile successfully arrives on the trafficchannel, 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 arriveson the traffic channel. The attempt to establish the RLP is only done after the R-Ppacket 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 theBSC level. This is the percentage of R-P interface packet session setup successesincluding both initial and reconnect setups.

Formula

% Setup Succ = [TotalSessionSetupSuccess/(TotalSessionSetupInitialAttempts +TotalSessionSetupReconnectAttempts)] * 100

OMsTotalSessionSetupSuccessNumber of successful packet session setups, either by initial or reconnect attempts

TotalSessionSetupInitialAttemptsNumber of packet session setups attempted during initial session setup.

TotalSessionSetupReconnectAttemptsNumber of packet session setups attempted when reconnecting to an existing PPPsession

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example





3.2.13.2. 3G Data R-P Interface Packet Session Failures

This Formula relates to the Packet Control Unit (PCU) Managed Object at theBSC level. This is the percentage of R-P interface packet session setup failuresincluding both initial and reconnect setups.

Formula

% Setup Failures = [TotalSessionSetupFailures/(TotalSessionSetupInitialAttempts +TotalSessionSetupReconnectAttempts)] * 100

OMsTotalSessionSetupFailuresNumber of failed packet session setups.

TotalSessionSetupInitialAttemptsNumber of packet session setups attempted during initial session setup.

TotalSessionSetupReconnectAttemptsNumber of packet session setups attempted when reconnecting to an existing PPPsession

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example





3.2.13.3. 3G Data R-P Interface Performance Formulas

These Formulas relates to the Packet Control Unit (PCU) Managed Object at theBSC 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 = DCRBufferOverflows

RR Overflow = RRBufferOverflows

StopTxMsgsSent = DCR_NumOfStopTransmitMsgsSent

OMsNumberOfTunnelFailuresCounts the number of times a L2TP tunnel was torn down due to failure ofreliable packet transmission per L2TP tunnel

TotalUnreliableBytesTransmittedCounts the cumulative number of bytes each session in the PCU transmitted toPDSN per L2TP tunnel

TotalUnreliableBytesTransmittedOverflowRegister allows values greater than 65535 for TotalUnreliableBytesTransmitted.

TotalUnreliableBytesReceivedCounts the cumulative number of bytes each session in the PCU received fromPDSN per L2TP tunnel



TotalUnreliableBytesReceivedOverflowRegister allows values greater than 65535 for TotalUnreliableBytesReceived.

TotalFwdPacketsDroppedNumber of PPP packets dropped in the forward direction per PCU

TotalRevPacketsDroppedNumber of PPP packets dropped in the reverse direction per PCU

DCRBufferOverflowsNumber of DCR buffer overflows per PCU

RRBufferOverflowsNumber of RR buffer overflows

StopTxMsgsSentNumber of Stop Transmit messages sent from RLPQ per PCU

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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 successfullysetup for the call, and even after the mobile successfully arrives on the trafficchannel, the call can still fail (that is, no data transfer would take place) due to afailure 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 arriveson the traffic channel. The attempt to establish the RLP is only done after the R-Ppacket 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

OMsRLPSetupSuccessesNumber of successful RLP setups.

RLPSetupAttemptsNumber of RLP setups attempted.

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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



OMsRLPSetupFailuresNumber of failed RLP setups

RLPSetupAttemptsNumber 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 SupplementalChannel 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

OMsFwdBurstSetupSuccessesPegged when a forward data burst is successfully 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



3.3.2. Forward Burst Setup Failures

Formula

F-SCH Burst %Fail = [FwdBurstSetupFailures / FwdBurstSetupAttemps] *100

OMsFwdBurstSetupFailuresPegged when a forward data burst could not be set up

FwdBurstSetupAttemptsPegged when a forward data burst needs to be set up

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example





3.3.3. Forward SCH Blocks

Formula

F-SCH %Blocks = [FSCHLinkSetupBlock / FSCHLinkSetupAttempts] * 100

OMsFSCHLinkSetupBlockNumber of FSCH setup attempts that are blocked for lack of resources

FSCHLinkSetupAttemptsNumber of forward supplemental channel (FSCH) setup attempts

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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:



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

OMsFSCHNoFwdPowerPegged if the FSCHBlock reason indicates a lack of available forward power

FSCHNoWalshCodePegged if the FSCHBlock reason indicates a lack of available Walsh codes

FSCHNoPhysResPegged if the FSCHBlock reason indicates there are no available channel elements

FSCHNoFrameOffsetPegged if the FSCHBlock reason indicates there is no available frame offset

FSCHCFDSRadioConfigPegged if the FSCHBlock reason indicates SCH burst functionality has not beenenabled through CFDS


Field Results

• Day 1: example

• Day 2: example

• Day 3: example



• Day 4: example


N/A


3.3.4. Forward SCH Access Failures

Formula

F-SCH %Access Failures =[FSCHRadioLinkAccessFailure / FSCHLinkSetupAttempts] * 100

OMsFSCHRadioLinkAccessFailureThis OM is pegged in the event the resources for the FSCH are set upsuccessfully, but the mobile does not arrive on the FSCH. It is pegged againsteach link in the SCH active set.


Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A




3.3.5. Forward SCH Time Out

Formula

F-SCH %TimeOuts = [FSCHTimeout / FSCHLinkSetupAttempts] * 100

OMsFSCHTimeoutPegged if a response to the BTS resource request is never received.


Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A


3.3.6. Forward SCH Data Rate Downgrades

Formula

F-SCH %Downgrades = [FSCHLinkDowngrade / FSCHLinkSetupAttempts]* 100

OMsFSCHLinkDowngradeNumber of FSCH setup attempts that are not granted the requested data rate due tolack of resources, but are granted a lower data rate. Pegged against the primarypilot in the SCH active set.




Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A


3.4. Performance Formulas for 3G Reverse SupplementalChannel 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

OMsRevBurstSetupSuccessesPegged when a Reverse data burst is successfully set up

RevBurstSetupAttemptsPegged when a Reverse data burst needs to be set up

Field Results



• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



3.4.2. Reverse Burst Setup Failures

Formula

R-SCH Burst %Rail = [RevBurstSetupFailures / RevBurstSetupAttemps] *100

OMsRevBurstSetupFailuresPegged when a Reverse data burst could not be set up

RevBurstSetupAttemptsPegged when a Reverse data burst needs to be set up

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A



3.4.3. Reverse SCH Blocks

Formula

R-SCH %Blocks = [RSCHLinkSetupBlock / RSCHLinkSetupAttempts] *100

OMsRSCHLinkSetupBlockNumber of RSCH setup attempts that are blocked for lack of resources

RSCHLinkSetupAttemptsNumber of Reverse supplemental channel (RSCH) setup attempts

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example



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:



R-SCH %Block CFDSConfig =[RSCHCFDSRadioConfig / RSCHLinkSetupAttempts] * 100

Blocks due to Reverse High Speed CFDS Configuration:R-SCH %Block HighSpeedCFDSConfig =[RSCHCFDSHighSpeed / RSCHLinkSetupAttempts] * 100

OMsRSCHNoPhysResPegged if the RSCHBlock reason indicates there are no available channelelements

RSCHNoFrameOffsetPegged if the RSCHBlock reason indicates there is no available frame offset

RSCHCFDSRadioConfigPegged if the RSCHBlock reason indicates SCH burst functionality has not beenenabled through CFDS

RSCHCFDSHighSpeedPegged if the RSCHBlock reason indicates high speed RSCH has not beenenabled through CFDS


Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A



3.4.4. Reverse SCH Access Failures

Formula

R-SCH %Access Failures =[RSCHRadioLinkAccessFailure / RSCHLinkSetupAttempts] * 100

OMsRSCHRadioLinkAccessFailureThis OM is pegged in the event the resources for the RSCH are set upsuccessfully, but the mobile does not arrive on the RSCH. It is pegged againsteach link in the SCH active set.


Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A


3.4.5. Reverse SCH Time Out

Formula

R-SCH %TimeOuts = [RSCHTimeout / RSCHLinkSetupAttempts] * 100

OMsRSCHTimeoutPegged if a response to the BTS resource request is never received.




Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A


3.4.6. Reverse SCH Data Rate Downgrades

Formula

R-SCH %Downgrades = [RSCHLinkDowngrade / RSCHLinkSetupAttempts]* 100

OMsRSCHLinkDowngradeNumber of RSCH setup attempts that are not granted the requested data rate dueto lack of resources, but are granted a lower data rate. Pegged against the primarypilot in the SCH active set.


Field Results

• Day 1: example

• Day 2: example



• Day 3: example

• Day 4: example


N/A

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 allof the supported frequencies.

NOTE: Σ indicates summing the pegs for the time period appropriate for thereport 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)

Block FCH No TCE = Σ ADV_SEC[119][0]= Σ (BlockedFchOriginations3GVoice)

(due to no physical resources)

Block FCH No WC = Σ ADV_SEC[119][3]= Σ (BlockedFchOriginations3GVoice)



(due to no Walsh code)

Block FCH No Fwd Power = Σ ADV_SEC[119][1]= Σ (BlockedFchOriginations3GVoice)

(due to no forward power)

Block FCH No Frame Offset = Σ ADV_SEC[119][4]= Σ (BlockedFchOriginations3GVoice)

(due to 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)

Block FCH No TCE = Σ ADV_SEC[120][0]= Σ (BlockedFchOriginations3GData)


Block FCH No WC = Σ ADV_SEC[120][3]= Σ (BlockedFchOriginations3GData)


Block FCH No Fwd Power = Σ ADV_SEC[120][1]= Σ (BlockedFchOriginations3GData)


Block FCH No Frame Offset = Σ ADV_SEC[120][4]= Σ (BlockedFchOriginations3GData)


Block CFDS Radio Config State = Σ ADV_SEC[120][6]= Σ (BlockedFchOriginations3GData)


Blocking Reasons



No Physical ResourcesIn this case, the CCEMs and XCEMs in the sector could not support additionalcalls. More CCEMs or XCEMs may be needed.

No Walsh CodeBlocking occurred because all Walsh codes had been allocated. This includesscenarios where Walsh codes are regulated by MaxVoiceResources (or voicecalls) or MaxDataResources (for data calls). If this blocking reason is consistentlyhigher than “No forward capacity”, the system may be Walsh code limited. In thatcase, the operator should consider setting RC4_Preferred to increase Walsh codeavailability at the expense of forward power.

No Forward CapacityThe BTS forward power level surpassed the level defined by the call blockingthreshold or MaxVoiceResources (for voice calls) or MaxDataResources (for datacalls).

No Frame OffsetThe XCEM supports a fixed number of calls per frame offset. This metriccorresponds to blocks that were a result of an XCEM’s inability to support theneeded frame offset. This metric is not applicable to CCEMs.

No CFDS Radio Config StateBlocking occurred because the CFDS RadioConfigState attribute is configured insuch a way that does not allow the specific type of call requested to be setup.Reconfiguration of this attribute may be needed.

OMsFchOriginationNonBlocking3GDowngrade2GNumber of successful BTS resource allocations for fundamental channel 2G callswhich were downgraded from 3G calls attempts. This metric does not includenon-reference pilot links setup for CASHO. 2G links, other than the referencepilot’s link, setup for CASHO are pegged under FchHandoffNonBlocking2G.

FchOriginationNonBlocking3GVoiceNumber of successful BTS resource allocations for 3G voice calls on thefundamental channel. This is not an indication of successful call attempts. Thismetric does not include non-reference pilot links setup for CASHO. 3G voicelinks, other than the reference pilot’s link, setup for CASHO are pegged underFchHandoffNonBlocking3GVoice.

BlockedFchOriginations3GVoice



Array indicating the number of 3G voice call attempts blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason asexplained above.

FchOriginationNonBlocking3GDataNumber of successful BTS resource allocations for 3G data calls on thefundamental channel. This is not an indication of successful call attempts.This metric does not include non-reference pilot links setup for CASHO. 3G datalinks, other than the reference pilot’s link, setup for CASHO are pegged underFchHandoffNonBlocking3GData.

BlockedFchOriginations3GDataArray indicating the number of 3G data sessions blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason asexplained above.

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A

3.5.1.2. 3G FCH Soft Handoff Blocks

Formulas

Voice Blocks

Non Blocking = Σ ADV_SEC[113]= Σ (FchHandoffNonBlocking3GVoice)

Block FCH No TCE = Σ ADV_SEC[121][0]= Σ (BlockedFchHandoffs3GVoice)




Block FCH No WC = Σ ADV_SEC[121][3]= Σ (BlockedFchHandoffs3GVoice)


Block FCH No Fwd Power = Σ ADV_SEC[121][1]= Σ (BlockedFchHandoffs3GVoice)


Block FCH No Frame Offset = Σ ADV_SEC[121][4]= Σ (BlockedFchHandoffs3GVoice)


Block CFDS Radio Config State = Σ ADV_SEC[121][6]= Σ (BlockedFchHandoffs3GVoice)


Data Blocks

Non Blocking = Σ ADV_SEC[114]= Σ (FchHandoffNonBlocking3GData)

Block FCH No TCE = Σ ADV_SEC[122][0]= Σ (BlockedFchHandoffs3GData)


Block FCH No WC = Σ ADV_SEC[122][3]= Σ (BlockedFchHandoffs3GData)


Block FCH No Fwd Power = Σ ADV_SEC[122][1]= Σ (BlockedFchHandoffs3GData)


Block FCH No Frame Offset = Σ ADV_SEC[122][4]= Σ (BlockedFchHandoffs3GData)


Block CFDS Radio Config State = Σ ADV_SEC[122][6]= Σ (BlockedFchHandoffs3GData)




Blocking Reasons






OMsFchHandoffNonBlocking3GVoiceNumber of successful BTS resource allocations for 3G voice handoffs on thefundamental channel. Note that this is not an indication of successful handoffs.

BlockedFchHandoffs3GVoiceArray indicating the number of 3G voice handoffs blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason asexplained above.

FchHandoffNonBlocking3GData



Number of successful BTS resource allocations for 3G data handoffs on thefundamental channel. Note that this is not an indication of successful handoffs.

BlockedFchHandoffs3GDataArray indicating the number of 3G data handoffs blocked on the fundamentalchannel. Each array element corresponds to a different blocking reason asexplained above.

Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


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 ofsectors or for the whole system by simply replacing each OM below with the sumof the same OM over all sectors in the cluster or in the whole system.

Formulas

Average number of FCH softer handoff linksThe average number of softer handoff links for the FCH in any sector in particularcan 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 particularcan be expressed by the following ratio:

(CEFrameCntFCH / PrimaryFrameCntFCH)

Average number of FCH handoff links (including both soft and softer)



The average number of all handoff links for the FCH in any sector in particularcan be expressed by the following ratio:

(FrameCntFCH / PrimaryFrameCntFCH)

OMsFrameCntFCHArray indicating the total number of frames sent on the forward link for every useron the fundamental channel. Each element in the array represents one radioconfiguration from RC1 through RC5. The array begins with RC1.

CEFrameCntFCHEquivalent to FrameCntFCH with each frame being divided by the number ofsofter handoff links.

PrimaryFrameCntFCHEquivalent to FrameCntFCH with each frame being divided by the product of thenumber 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


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 allof the supported frequencies.

NOTE: Σ indicates summing the pegs for the time period appropriate for thereport under discussion.



3.5.2.1. 3G SCH Burst

Formulas

Non Blocking = Σ ADV_SEC[115]= Σ (SchBurstNonBlocking3G)

Block SCH No TCE = Σ ADV_SEC[123][0]= Σ (BlockedSchBursts)


Block SCH No WC = Σ ADV_SEC[123][3]= Σ (BlockedSchBursts)


Block SCH No Fwd Power = Σ ADV_SEC[123][1]= Σ (BlockedSchBursts)


Block SCH No Frame Offset = Σ ADV_SEC[123][4]= Σ (BlockedSchBursts)


Blocked Radio Config State = Σ ADV_SEC[123][6]= Σ (BlockedSchBursts)


Screened = Σ ADV_SEC[123][7]= Σ (BlockedSchBursts)

(due to CFDS HS RSCH)

Blocking Reasons


No Walsh CodeBlocking occurred because all Walsh codes had been allocated. This includesscenarios where Walsh codes are regulated by MaxVoiceResources (or voicecalls) or MaxDataResources (for data calls). If this blocking reason is consistentlyhigher than “No forward capacity”, the system may be Walsh code limited. In that



case, the operator should consider setting RC4_Preferred to increase Walsh codeavailability at the expense of forward power.




No CFDS HS RSCHThis element in the array is valid only for BlockedSchBursts andBlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeatureattribute is set to FALSE. This attribute is used to screen for high data rate R-SCHbursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).Reconfiguration of this attribute may need to be considered.

OMsSchBurstNonBlocking3GNumber of successful BTS resource allocations for 3G data bursts on thesupplemental channel. This is not an indication of successful data bursts.

BlockedSchBurstsArray indicating the number of 3G data bursts blocked on the supplementalchannel. Each array element corresponds to a different blocking reason asexplained above.

Field Results

• Day 1: example

• Day 2: example



• Day 3: example

• Day 4: example


N/A

3.5.2.2. 3G SCH Handoff Blocks

Formulas

Non Blocking = Σ ADV_SEC[116]= Σ (SchHandoffNonBlocking3G)

Block SCH No TCE = Σ ADV_SEC[124][0]= Σ (BlockedSchHandoffs)


Block SCH No WC = Σ ADV_SEC[124][3]= Σ (BlockedSchHandoffs)


Block SCH No Fwd Power = Σ ADV_SEC[124][1]= Σ (BlockedSchHandoffs)


Block SCH No Frame Offset = Σ ADV_SEC[124][4]= Σ (BlockedSchHandoffs)


Blocked Radio Config State = Σ ADV_SEC[124][6]= Σ (BlockedSchHandoffs)


Screened = Σ ADV_SEC[124][7]= Σ (BlockedSchHandoffs)

(due to CFDS HS RSCH)

Blocking Reasons








No CFDS HS RSCHThis element in the array is valid only for BlockedSchBursts andBlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeatureattribute is set to FALSE. This attribute is used to screen for high data rate R-SCHbursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).Reconfiguration of this attribute may need to be considered.

OMsSchHandoffNonBlocking3GNumber of successful BTS resource allocations for 3G data handoffs on thesupplemental channel. Note that This is not an indication of successful handoffs.

BlockedSchHandoffsArray indicating the number of 3G data handoffs blocked on the supplementalchannel. Each array element corresponds to a different blocking reason asexplained above.



Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


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 ofsectors or for the whole system by simply replacing each OM below with the sumof the same OM over all sectors in the cluster or in the whole system.

Formulas

Average number of SCH softer handoff linksThe average number of softer handoff links for the SCH in any sector in particularcan 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 particularcan 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 particularcan be expressed by the following ratio:

(FrameCntSCH / PrimaryFrameCntSCH)

OMsFrameCntSCH



Array indicating the total number of forward frames for every user on thesupplemental channel. Each element in the array represents one radioconfiguration from RC3 through RC5. The array begins with RC3.

CEFrameCntSCHEquivalent to FrameCntSCH with each frame being divided by the number ofsofter handoff links.

PrimaryFrameCntSCHEquivalent to FrameCntSCH with each frame being divided by the product of thenumber 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


N/A

3.5.3. Advanced Frequency Assignment (FA) Managed ObjectFormulas

Advanced Frequency Assignment (FA) formulas deal with the status of XCEMresources on the fundamental as well as the supplemental channels.

Formulas

Forward Total = ADV_FA[72]Total ForwardPhysicalResources

Max SCH Forward = ADV_FA[74]SchMaximumForwardPhysicalResourcesUsed



Max 3G FCH Forward = ADV_FA[76]Fch3GMaximumForwardPhysicalResourcesUsed

Reverse Total = ADV_FA[77]TotalReversePhysicalResources

Max TCE = ADV_FA[24]TCEUtilMaximum

TCE Available = ADV_FA[23]NumOfTCAvailable

OMsTotal ForwardPhysicalResourcesThe number of 3G XCEM resources provisioned for the BTS’s forward link. Thisexcludes all CCEM resources and faulty XCEM resources. This OM is a snapshottaken at the time of reporting. It does not represent how many resources areactually in use.

SchMaximumForwardPhysicalResourcesUsedThis OM is a high water mark for the number of XCEM resources being used forthe forward supplemental channel at any time during the reporting period.

Fch3GMaximumForwardPhysicalResourcesUsedThis OM is a high water mark for the number of XCEM resources being used for3G calls on the forward fundamental channel at any time during the reportingperiod.

TotalReversePhysicalResourcesThe number of 3G XCEM resources provisioned for the BTS’s reverse link. Thisexcludes all CCEM resources and faulty XCEM resources. This OM is a snapshottaken at the time of reporting. It does not represent how many resources areactually in use.

TCEUtilMaximumThe peak number of channel elements in use, simultaneously, during a given time.

NumOfTCAvailableTotal number of channel elements available for traffic across all channel cardsafter overhead channels have been subtracted



Field Results

• Day 1: example

• Day 2: example

• Day 3: example

• Day 4: example


N/A



4. Field Results AnalysisThis section discusses various approaches that can be considered by the RF engineers whileanalyzing the field results. The performance formulas discussed in this section are providedon a as-needed basis. For a complete list of performance formulas, please refer Section 3 ofthis 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, failurepercentages in the range of 1 to 2 percent are pretty typical for a given network. If thenetwork statistics reflect a failure trend that is exceeding the desired range then thefollowing procedures can be considered to troubleshoot the problem. It is important toverify that the field results in hand are reflecting a relatively large number of users beforeproceeding with the analysis.

These procedures apply to both 3G voice and 3G data calls. For 3G voice calls, the OMs aretaken 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, suchas CAUSCT3D, CAUFRQ3D.

4.1. Access Failures

The percentage of access failures is expressed by the following relation:


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 doneafter the mobile arrives on the traffic channel but before sending the service connectmessage out to the mobile. Thus if the R-P packet session setup fails, it will still be peggedas an access failure. The TotalSessionSetupFailures count can be subtracted from theabove sum when measuring the RF Access Failure rate on a system wide basis.



Figure 4-1A: 3G Voice Access Failures Percentage

02000400060008000

100001200014000160001800020000

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Date

Num

ber o

f atte

mpt

s

012345678910

Attempts%_AF

Figure 4-1B: 3G Data Access Failures Percentage

0200400600800

100012001400

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Data

Num

ber o

f Atte

mpt

s

012345678910

Attempts%_AF

Figures 4-1A and 4-1B above show 3G voice and 3G data access failures percentagesrespectively. 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 theaccess failure rate is much higher in the case of 3G data calls. However, this high failurerate does not reflect a typical network behavior because: 1) the number of attempts issignificantly less for the data calls as compared to the voice call attempts. 2) Approximately90% of data calls were attempted from only two sectors out of a total of about 90 sectors.



For a more detailed analysis, we can break this information down into specific areas, asfollows:

4.1.1. Access failures during originations and terminations:(CAUERLFL)

• A higher count on this peg reflects that the number of access failures taking placeduring originations or terminations is high.

• The next step would be go to the MCTA report and figure out which carrier(s) isexperiencing access failures. To do this, we will check the count for MCTERLFLfor 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 pinpoint the problem. The best option for such failure is to send a drive test team outto try to duplicate failed origination/termination attempts, and analyze the drivetest data to identify the problem. Also, “cell trouble” logs can be printed inconjunction with the drive test results to provide information about the mobilewhose call attempt was unsuccessful. The following can be a reason for thiscount:

• The Mobile cannot hear the BTS acknowledgment, chances are that the Ec/Io islow. Low Ec/Io could be because of:

1. Poor coverage, received signal strength is low.2. Pilot pollution, many available pilots with no dominant server.3. 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 placeduring hard handoffs is high.

• The next step would be go to the MCTA report and figure out which carrier(s) atthe target sector is experiencing access failures. To do this, we will check thecount for MCTHRLFL for all carriers, and identify the carrier(s) that has highnumber of access failures. NOTE: It is possible that more than one carrier isfacing high access failure rate.



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 takingplace 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

02000400060008000

100001200014000160001800020000

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Date

Num

ber o

f Atte

mpt

s

012345678910

Attempts%_T_BLK

Figure 4-2B: 3G Data Total Blocks Percentage

0200400600800

100012001400

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Date

Num

ber o

f Atte

mpt

s

012345678910

Attempts%_T_BLK



Figures 4-2A and 4-2B above show 3G voice and 3G data total blocks percentagesrespectively. 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 theblocking rate is relatively higher in the case of 3G data calls. However, this high failure ratedoes not reflect a typical network behavior because: 1) the number of attempts issignificantly less for the data calls as compared to the voice call attempts. 2) Approximately90% 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 followingOMs counts:

CAUOBLKS + CAUTBLKS + CAUHBLKS


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 channelelements (TCEs) on a particular sector is high.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector is running out of TCEs. To do this, we will check the count forMCTNOTCE for all carriers, and identify the carrier(s) that is lacking channelelements. NOTE: It is possible that more than one carrier is facing the channelelements limitation.

• Verify the TCE limitation by comparing the number of TCEs in use with the totalnumber of TCEs provisioned for this carrier(s) at the BTS.

Recommendations:

• Provision additional TCE at the BTS. More TCEs can be added as required untilthe 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 aparticular sector is high.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector is running out of Walsh codes. To do this, we will check the count forMCTNOWCD for all carriers, and identify the carrier(s) that is lacking Walsh



codes. NOTE: It is possible that more than one carrier is facing the Walsh codeslimitation.

Recommendations:

• Addition of a new site is recommended once the Walsh codes have reached thelimit.

NOTE: Data users with higher traffic rates would be the major contributors forsuch 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 theforward link.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector is running out of forward capacity. To do this, we will check the countfor MCTFWCAP for all carriers, and identify the carrier(s) that is lacking forwardcapacity. NOTE: It is possible that more than one carrier is facing the forwardcapacity 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 thereverse link.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector is running out of reverse capacity. To do this, we will check the countfor MCTRECAP for all carriers, and identify the carrier(s) that is lacking reversecapacity. NOTE: It is possible that more than one carrier is facing the reversecapacity limitation.

Recommendations:

• A drive test would be required to analyze blocks that are possibly resulting due tothe reverse link capacity.



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 shortageproblem. Typically, more SBS selector elements are needed to be provisioned insuch 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/networkteam 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 toresource requests during call setup

Recommendations:

• Depending on which resource is not available at the BTS, the followinginformation might be of help:

1. No channel elements (CAUNOTCE): refer section 4.1.12. No Walsh codes (CAUNOWCD): refer section 4.1.23. No forward capacity (CAUFWCAP): refer section 4.1.34. No reverse capacity (CAURECAP): refer section 4.1.45. BTS does not respond at all.6. 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 givensector.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector has no frame offset availability. To do this, we will check the count for



MCTNOFOF for all carriers, and identify the carrier(s) that has no frame offsetavailability. NOTE: It is possible that more than one carrier is facing the frameoffset availability limitation.

Recommendations:

This type of failures reflects software or hardware limitations; and are not becauseof 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-OutRMSRMNAK - RM Service Resource Manager Negative AcKCAUESWFL - CAU Error case, SoftWare FauLt

Recommendations:

These are hardware/software related problems, reasons to be investigated.



4.3. Drops

The percentage of total drops is expressed by the following relation:


Figure 4-3A: 3G Voice Call Drops Percentage

02000400060008000

100001200014000160001800020000

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Date

Num

ber o

f Atte

mpt

s

012345678910

Attempts%_Drop

Figure 4-3B: 3G Data Call Drops Percentage

0200400600800

100012001400

4/8/02

4/9/02

4/10/0

2

4/11/0

2

4/12/0

2

4/13/0

2

4/14/0

2

Date

Num

ber o

f Atte

mpt

s

012345678910

Attempts%_Drop

Figures 4-3A and 4-3B above show 3G voice and 3G data call drops percentagesrespectively. 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 calldrop rate is relatively higher in the case of 3G data calls. However, this high failure ratedoes 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) Approximately90% 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


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 oftraffic or due to HCM (handoff completion message) timeout on a particularsector is high.

• The next step would be go to the MCTA report and figure out which carrier(s) onthis sector is dropping calls. To do this, we will check the count for MCTDROPRfor all carriers, and identify the carrier(s) that is facing a high number of drop callsdue to RF-related reasons. NOTE: It is possible that more than one carrier isexperiencing such drops.

Recommendations:

• As mentioned above this count includes failures resulting during soft and softerhandoffs as well. Therefore, the first step is to identify the exact reason for thiscount. This task can be accomplished by organizing a drive test to capture thesedrops, and then analyze the layer 3 messages.

• The main reason for RF-related drop calls is higher values of FER, i.e., when theFER is above the threshold. Factors contributing in bringing the FER highinclude high noise, weak signal, pilot pollution. In some cases, intermittenthardware problems have also resulted in such drops. Drops occurring due to poorcoverage conditions would require additional sites. For handoff related drops, it isimportant 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 anyother, 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) onthis sector is dropping calls. To do this, we will check the count for MCTDROPNfor all carriers, and identify the carrier(s) that is facing a high number of drop calls



due to non RF-related reasons. NOTE: It is possible that more than one carrier isexperiencing such drops.

Recommendations:

• These are not RF-related failures.



5. New Operational Measurements in 3G 1xRTTThis section outlines the new OMs available in 3G 1xRTT. These OMs are listed in tablesthat are divided on a per OM group basis.

5.1. OM Groups: CAUSCT3V, CAUSCT3DCAUSCT3V (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 OM Register(Name) Description

MSC/ BSC/ BTS

V/D Basis

CAU PaGeRESponse

CAUPGRES For mobile-terminated calls, attempts are recordedin CAUPGRES, which indicates that a pageresponse was received from a CDMA sector inresponse to a page request (irrespective of whetherit was in response to an initial page request or a retryby the CM).

MSC V+D per-sectorbasis

CAU TerminationSUCCess

CAUTSUCC Pegged when a mobile-terminated call successfullyarrives on the traffic channel.


CAU TerminationBLocKS

CAUTBLKS Pegged any time a mobile-terminated call setup failsdue to resource shortage. It represents all of thetermination setup failures in a sector, regardless ofresource. One or more of the following call setupfailure reasons is pegged in conjunction withCAUTBLKS: RMNORREQ, RMSRMNAK,RMSRMTO, CAUERSFL, CAUNOTCE,CAUNOWCD, CAUNOFOF, CAUFWCAP,CAURECAP and CAUESWFL.


CAU Error case,Dropped due toLoss Of Traffic

CAUEDLOT Pegged when the mobile drops off the traffic channelafter the “Radio Link Setup Rsp” message isreceived but before the “Service Connect Rsp”message is received. This scenario is considered anaccess failure. The register CAUERLFL is alsopegged in conjunction with this register.


CAU TerminationReLeaSed

CAUTRLS Pegged when a mobile-terminated call is releasedbefore the mobile arrives on the traffic channel. Itshould be noted that this OM will only get pegged ifthe originating party disconnects between the timethat the terminating mobile’s page response hasbeen received by the CM and before the mobileactually arrives on the traffic channel.






MSC/ BSC/ BTS

V/D Basis

CAU OriginationATTemptS

CAUOATTS Pegged when the CAU receives an originationmessage from the BTS. Test call originations arepegged in a separate OM.


CAU OriginationSUCCess

CAUOSUCC Pegged when a mobile-originated call successfullyarrives on the traffic channel. This includes alloriginations placed on the traffic channel to receivetreatment.


CAU OriginationBLocKS

CAUOBLKS Pegged any time a mobile-originated call setup failsdue to resource shortage. It represents the totalnumber of origination setup failures in a sector,regardless of resource. The same failure reasonsthat are pegged for CAUTBLKS can be pegged inconjunction with CAUOBLKS.


CAU OriginationReOrDeR

CAUORODR The CM can send reorder commands to the mobileoriginators whose calls will not be set up. Thesesituations can occur by datafilling a treatment withthe MOBRODR or MOBICPT CLLI instead of anannouncement or tone CLLI in table TMTCNTL.CAUORODR is pegged when the CAU receives areorder or intercept message from the CM indicatingthat the origination is intentionally stopped withoutputting the mobile on the traffic channel.


CAU OriginationReLeaSed

CAUORLS Pegged when a mobile-originated call is released bythe mobile station or the CM before the mobilesends a service completion message.


CAU Error case,Radio SetupFaiLure

CAUERSFL Pegged, along with the appropriate CAU*BLKS OM,whenever a call setup fails due to the fact that someBTS resource is not available. This OM is alsopegged when the BTS does not respond to resourcerequests. It is also pegged when the CarrierDetermination Algorithm (CDA) fails to select acarrier in an MCTA enabled sector (that is, noavailable capacity on all co-located carriers).


CAU Error RadioLink FaiLure

CAUERLFL Pegged if the origination or termination fails becausethe mobile never arrived on the traffic channel(similar to SAT timeout). CAUERLFL is not peggedin cases where the CAUOBLKS or CAUTBLKS OMsare pegged.


SLoTted modePaGe RESponse

SLTPGRES This OM is the equivalent of CAUPGRES, exceptthat it is pegged by the CAU only in response to aslotted mode page request. Slotted mode paging ismeasured separately so that performancedifferences can be determined. SLTPGRES is asubset of the CAUPGRES.






MSC/ BSC/ BTS

V/D Basis

CAU hardHandoffATTemptS

CAUHATTS Pegged when the CAU receives a ReadyNewCellmessage from the CM, indicating that a hard handoffattempt sequence in a (CDMA) target sector shouldbegin.


CAU hardHandoff BLocKS

CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoffsetup fails due to resource shortage. It represents allof the hard handoff setup failures into a sector,regardless of resource. This OM is pegged for bothinter- and intra-system hard handoff attempts.CAUHBLKS is not the number of dropped hardhandoffs, it merely represents the number of timesthat a hard handoff could not be completed due toresource shortages in the target cell/sector—the callin the source cell is still up. The same failurereasons that are pegged for CAUOBLKS (seeprevious page) can be pegged in conjunction withCAUHBLKS.


CAU hardHandoffSUCCess

CAUHSUCC Pegged when a mobile, attempting a hard handoff,successfully arrives on the traffic channel in thetarget sector.


CAU hardHandoffReLeaSed

CAUHRLS Pegged when a call setup in a target cell is releasedby the source system before the mobile arrives onthe traffic channel.


CAU hardHandoff RadioLink FaiLure

CAUHRLFL Pegged if the hard handoff attempt fails because themobile never arrived on the target sector’s trafficchannel (similar to SAT timeout). CAUHRLFL

is not pegged in cases where CAUHBLKS ispegged.


CAU DROPpedcall Rf

CAUDROPR Pegged by the CAU against the reference pilot whena call is dropped by the SBS due to “loss of traffic” ordue to “HCM (handoff completion message) timeout”for soft or softer handoff. These are RF-related callfailures as detected by the SBS.


CAU DROPpedcall Network

CAUDROPN Pegged by the CAU when any of the other (non-RF)drop indication reasons are sent from the SBS in theradio link drop indication message.


CAU Error case,SoftWare FauLt

CAUESWFL Pegged, along with the appropriate CAU*BLKS OM,whenever a call setup fails due to time outs betweensoftware entities that should not occur (for example,no response from the CM, failure message receivedfrom SBS, etc.).


CAU NO TrafficChannel Element

CAUNOTCE Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, any time a BTS reports no trafficchannel element via NOIS messages, regardless of






MSC/ BSC/ BTS

V/D Basis

origination, termination or hard handoff.

CAU NO WalshCode

CAUNOWCD

Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, any time a BTS reports no walshcode via NOIS messages, regardless of origination,termination or hard handoff.


CAU NO FrameOFfset

CAUNOFOF Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, any time a BTS cannot allocateresources due to some CSM 5000 hardwarelimitation. The CSM 5000 is limited in how muchtraffic it can support on its reverse link because ofthe limitation on the number of decoding units (bothViterbi and Turbo) that can be active on a frameoffset (and adjacent frame offsets).


CAU ForWardCAPacity full

CAUFWCAP Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, any time a BTS reports forwardcapacity full via NOIS messages, regardless oforigination, termination or hard handoff.


CAU REverseCAPacity full

CAURECAP Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, any time a BTS reports reversecapacity full via NOIS messages, regardless oforigination, termination or hard handoff. However,currently there is no reliable mechanism forestimating reverse link capacity and so this responseis disabled on the BTS. Consequently, this OM isnever pegged.


MCTA HandoffReQuest Failure

MCTAHRQF Pegged, along with CAUERSFL, when NOfrequency was successfully selected by MCTA for ahard handoff call setup. It is pegged on a per-sectorbasis on the target side. The failure reasons arepegged by MCTAMIXF, MCTALLTO or MCTALLFU.


MCTA REQuestFailure

MCTAREQF Pegged, along with CAUERSFL, when NOfrequency was successfully selected by MCTA fororigination or termination call setup. It is pegged ona per-sector basis. The failure reasons are peggedby MCTAMIXF, MCTALLTO or MCTALLFU.


MCTA Allfrequencies FUll

MCTALLFU Pegged, along with CAUERSFL and (MCTAREQFor MCTAHRQF), when NO frequency wassuccessfully selected by MCTA because none of theBTSs had resources available. It is pegged on a per-sector basis.






MSC/ BSC/ BTS

V/D Basis

MCTA ALLfrequenciesTimed-Out

MCTALLTO Pegged, along with CAUERSFL and (MCTAREQFor MCTAHRQF), when NO frequency wassuccessfully selected by MCTA because none of the

BTSs responded to the capacity request query. It ispegged on a per-sector basis.


MCTA MIXedFailure

MCTAMIXF Pegged, along with CAUERSFL and MCTARQFNand (MCTAREQF or MCTAHRQF), when NOfrequency was successfully selected by MCTAbecause some BTSs timed-out while someresponded with a resource full or not availableresponse. It is pegged on a per-sector basis.


5.2. OM Groups: CAURFQ3V, CAUFRQ3DCAUFRQ3V (CAU FReQuency based OMs for 3G Voice calls)CAUFRQ3D (CAU FReQuency based OMs for 3G Data calls)

Table 5-2: OM Groups: CAURFQ3V, CAUFRQ3D


MSC/ BSC/ BTS

V/D Basis

MCTAORIGination

MCTORIGS Pegged, along with CAUOATTS, when the CAUreceives an origination message from a sector thathas MCTA enabled. It is pegged against theoriginating frequency. Test call originations arepegged in a separate OM.

MSC V+D per-freqbasis

MCTA OriginationATTemptS

MCTOATTS Pegged when an MCTA frequency is successfullyselected by the Carrier Determination Algorithm(CDA) for a mobile origination in a sector with MCTAenabled. Please note that the MCTA frequency forMCTOATTS may be different from the MCTAfrequency on which the call originated (MCTORIGS).


MCTA OriginationSUCCess

MCTOSUCC Pegged, along with CAUOSUCC, when a mobile-originated call successfully arrives on the trafficchannel. This includes all originations placed on thetraffic channel to receive treatment.






MSC/ BSC/ BTS

V/D Basis

MCTA PaGeRESponse

MCTPGRES For mobile-terminated calls, attempts are recordedin MCTPGRES, which indicates that a pageresponse was received from an MCTA enabledCDMA sector in response to a page request. ThisOM is pegged irrespective of whether it was the firstor the second attempt to page the mobile.CAUPGRES is also pegged whenever MCTPGRESis pegged.


MCTATerminationATTemptS

MCTTATTS Pegged when an MCTA frequency is successfullyselected by the Carrier Determination Algorithm(CDA) for a mobile termination in a sector withMCTA enabled.


MCTATerminationSUCCess

MCTTSUCC Pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the trafficchannel.


MCTA HandoffCall ATTempts

MCTHCATT Pegged, along with CAUHATTS, when the CAUreceives a message from the CM, indicating that ahard handoff attempt sequence in an MCTA enabledCDMA target sector should begin.


MCTA HandoffATTemptS

MCTHATTS Pegged when an MCTA frequency is successfullyselected by the Carrier Determination Algorithm(CDA) for a mobile hard handoff attempt into a targetsector with MCTA enabled.


MCTA Hard-handoffSUCCess

MCTHSUCC Pegged, along with CAUHSUCC, when a mobilesuccessfully arrives on the traffic channel after ahard handoff.


MCTA HandoffRadio LinkFaiLure

MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoffattempt fails because the mobile never arrived onthe target sector’s traffic channel (similar to

SAT timeout). MCTHRLFL is not pegged in caseswhere the CAUHBLKS OM is pegged.


MCTA Error caseRadio link SetupFaiLure

MCTERSFL Pegged, along with CAUERSFL and the appropriateCAU*BLKS OM, whenever a call setup fails due tothe 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 notrespond at all to resource requests. MCTERSFL ispegged only after an MCTA frequency is selected.MCTERSFL is pegged against the selectedfrequency.






MSC/ BSC/ BTS

V/D Basis

MCTA NO TrafficChannel Element

MCTNOTCE Pegged, along with MCTERSFL and CAUNOTCEand CAUERSFL and the appropriate CAU*BLKSOM, any time a BTS reports no traffic channelelement via NOIS messages, regardless oforigination, termination or hard handoff.MCTNOTCE is pegged only after an MCTAfrequency is selected. MCTNOTCE is peggedagainst the selected frequency.


MCTA NO WalshCode

MCTNOWCD

Pegged, along with MCTERSFL and CAUNOWCDand CAUERSFL and the appropriate CAU*BLKSOM, any time a BTS reports no walsh code via NOISmessages, regardless of origination, termination orhard handoff. MCTNOWCD is pegged only after anMCTA frequency is selected.

MCTNOWCD is pegged against the selectedfrequency.


MCTA NO FrameOFfset

MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOFand CAUERSFL and the appropriate CAU*BLKSOM, any time a BTS cannot allocate resources dueto some CSM 5000 hardware limitation. The CSM5000 is limited in how much traffic it can support onits reverse link because of the limitation on thenumber of decoding units (both Viterbi and Turbo)that can be active on a frame offset (and adjacentframe offsets). MCTNOFOF is pegged only after anMCTA frequency is selected. MCTNOFOF is peggedagainst the selected frequency


MCTA ForWardCAPacity full

MCTFWCAP Pegged, along with MCTERSFL and CAUFWCAPand CAUERSFL and the appropriate CAU*BLKSOM, any time a BTS reports forward capacity full viaNOIS messages, regardless of origination,termination or hard handoff. MCTFWCAP is peggedonly after an MCTA frequency is selected.

MCTFWCAP is pegged against the selectedfrequency.


MCTA REverseCAPacity full

MCTRECAP Pegged, along with MCTERSFL and CAURECAPand CAUERSFL and the appropriate CAU*BLKSOM, any time a BTS reports reverse capacity full viaNOIS messages, regardless of origination,termination or hard handoff. However, currentlythere is no reliable mechanism for estimatingreverse link capacity. Consequently, this OM shouldnever be pegged.






MSC/ BSC/ BTS

V/D Basis

MCTA Errorcase, Radio LinkFaiLure

MCTERLFL Pegged, along with CAUERLFL, if the origination ortermination fails because the mobile never arrivedon the traffic channel (similar to SAT timeout).MCTERLFL is not pegged in cases where theCAUOBLKS or CAUTBLKS OMs are pegged.


MCTA REQuestTimeout

MCTAREQT pegged when a frequency was successfully selectedby MCTA but one or more of the BTSs neverresponded to a capacity request. MCTAREQT ispegged against the carrier(s) that did not respond tothe capacity request. MCTAREQT may not alwaysbe pegged under low traffic load conditions.


MCTA REQuestresponse full orNot available

MCTAREQN Pegged when a frequency was successfully selectedby MCTA but one or more of the BTSs respondedwith a resource full or not available response.MCTAREQN is pegged against the carrier(s) thatrespond with a resource full or not availableresponse. MCTAREQN may not always be peggedunder low load conditions.


MCTA ReQuestresponse Failed(full or Notavailable)

MCTARQFN Pegged, along with CAUERSFL and MCTAMIXFand (MCTAREQF or MCTAHRQF), when nofrequency was successfully selected by MCTAbecause some BTSs timed out, while someresponded with a resource full or not availableresponse. MCTARQFN is pegged against thecarrier(s) that respond with a resource full or notavailable response.


MCTA DROPpedRadio link

MCTDROPR Pegged, along with CAUDROPR, when a call isdropped by the SBS due to “loss of traffic” or due to“HCM (handoff completion message) timeout” forsoft or softer handoff. These are RF-related callfailures as detected by the SBS.


5.3. OM Group: CAUDAT3GCAU sector based OMs for short DATa bursts initiated by 3G mobiles

Table 5-3: OM Group: CAUDAT3G


MSC/ BSC/ BTS

V/D Basis



Short Data burstPCU LooKupRequests

SDPCULKR Pegged when the CAU receives a Short Data Burstmessage from the mobile in a dormant data call.SDB is being considered for future release, and thusthis register will not get pegged in the initial releaseof 1XRTT.

MSC D per-sectorbasis

Short Data burstPCU LooKupFailures

SDPCULKF Pegged when the CAU does not get the address ofthe PCU to forward the SDB message (this is due toa PCU address lookup failure at the MU). SDB isbeing considered for future release, and thus thisregister will not get pegged in the initial release of1XRTT.

MSC D per-sectorbasis

5.4. OM Group: RMU3G (RMU OMs for 3G calls)

Table 5-4: OM Group: RMU3G


MSC/ BSC/ BTS

V/D Basis

Request for 3GVoice call

REQ3GV Pegged when there is an attempt made by RMU toallocate resources for a 3G Voice call attempt basedon a resource request from CAU.

MSC V+D per-RMUbasis

SUCcess for 3GVoice call

SUC3GV Pegged when the RMU successfully allocatesresources for a 3G Voice call based on a resourcerequest from CAU.


NO ReSource for3G Voice call

NORS3GV Pegged when the RMU fails to allocate resources fora 3G Voice call based on a resource request fromCAU.


Request for 153Kdata rate data-call

REQ153K Pegged when there is an attempt made by RMU toallocate resources for a 153K data rate data-callattempt based on a resource request from CAU.


SUCcess for153K data ratedata-call

SUC153K Pegged when the RMU successfully allocatesresources for a 153K data rate data-call attemptbased on a resource request from CAU.


NO ReSource for153K data ratedata-call

NORS153K Pegged when the RMU fails to allocate resources fora 153K data rate data-call attempt based on aresource request from CAU.



REQ76K Pegged when there is an attempt made by the RMUto allocate resources for a 76K data rate data-callattempt based on a resource request from CAU.Note that rate data-call attempt based on a resourcerequest from CAU. Note that REQ76K countsinclude downgraded attempts from 153K to 76K dueto no resources available for the 153K attempts. Thedowngraded attempts (from 153K to 76K) count isequal to NORS153K.




Table 5-4: OM Group: RMU3G


MSC/ BSC/ BTS

V/D Basis

SUCcess for 76Kdata rate data-call

SUC76K Pegged when the RMU successfully allocatesresources for a 76K data rate data-call attemptbased on a resource request from CAU.



NORS76K Pegged when the RMU fails to allocate resources fora 76K data rate data-call attempt based on aresource request from CAU.



REQ38K Pegged when there is an attempt made by the RMUto allocate resources for a 38K data rate data-callattempt based on a resource request from CAU.Note that internally, the RMU does not make adistinction between the 38K and the 76K data rates,and therefore a 76K data rate call attempt can neverbe downgraded to a 38K data rate call attempt. ThusREQ38K counts do not include any downgradedattempts from a higher data rate to 38K data rate.



SUC38K Pegged when the RMU successfully allocatesresources for a 38K data rate data-call attemptbased on a resource request from the CAU.



NORS38K Pegged when the RMU fails to allocate resources fora 38K data rate data-call attempt based on aresource request from the CAU.



REQ19K Pegged when there is an attempt made by the RMUto allocate resources for a 19K data rate data-callattempt based on a resource request from the CAU.Note that REQ19K counts include downgradedattempts from 76K to 19K and downgraded attemptsfrom 38K to 19K due to no resources available forthe 76K and 38K data rates attempts. Thedowngraded attempts (from 76K to 19K) count isequal to NORS76K and the downgraded attempts(from 38K to 19K) count is equal to NORS38K.



SUC19K Pegged when the RMU successfully allocatesresources for a 19K data rate data-call attemptbased on a resource request from the CAU.



NORS19K Pegged when the RMU fails to allocate resources fora 19K data rate data-call attempt based on aresource request from the CAU.


5.5. OM Group: CDMAPDOM (CDMA Packet Data)

Table 5-5: OM Group: CDMAPDOM




MSC/ BSC/ BTS

V/D Basis

Mobile-InitiatedDormant ToActive ATtempts

MIDTOAAT Pegged when the MSC receives an originationmessage from a mobile which is in a dormant datacall state.

MSC D system-widebasis

Mobile-InitiatedDormant ToActive SUccess

MIDTOASU Pegged when the mobile-initiated dormant to activetransition is successful “mobile arrives on the trafficchannel”.


Mobile-InitiatedDormant ToActive FaiLures

MIDTOAFL Pegged when the mobile-initiated dormant to activetransition fails due to lack of resources or the mobilefail to arrive on the traffic channel.


Network-InitiatedDormant ToActive ATtempts

NIDTOAAT Pegged when the MSC receives aPCU_Page_Request after the network DCR PLICFdecides to make the transition to active state.


Network-InitiatedDormant ToActive SUccess

NIDTOASU Pegged when the network-initiated dormant to activetransition is successful “mobile arrives on the trafficchannel”.


Network-InitiatedDormant ToActive FaiLures

NIDTOAFL Pegged when the network-initiated dormant to activetransition fails due to lack of resources or the mobilefail to arrive on the traffic channel.


5.6. OM Group: CDMAPDSO (CDMA Packet Data Service Option)

Table 5-6: OM Group: CDMAPDSO


MSC/ BSC/ BTS

V/D Basis

ResourceAllocationAttempts forCDMA2000INternet PPPData serviceoption

ATINPPP Pegged when there is an attempt made by the RMUfor a resource request from the CAU to allocate aresource for a CDMA2000_INT_PPP_DATA serviceoption.

MSC D per-RMUbasis



Table 5-6: OM Group: CDMAPDSO


MSC/ BSC/ BTS

V/D Basis

SUccessfulresourceallocation forCDMA2000INternet PPPData serviceoption

SUINPPP Pegged when a resource for aCDMA2000_INT_PPP_DATA service option requesthas been successfully allocated.

MSC D per-RMUbasis

Hop Count forCDMA2000INternet PPPData serviceoption

HCINPPP Pegged for each pool, including the first pool, theRMU searches through from the list to find aresource for a CDMA2000_INT_PPP_DATA serviceoption.

MSC D per-RMUbasis

ResourceallocationFaiLures forCDMA2000INternet PPPData serviceoption

FLINPPP Pegged when an attempt to allocate resource for aCDMA2000_INT_PPP_DATA service option fails. Itis due to no resources available in any pool from thelist

MSC D per-RMUbasis

5.7. OM Group: CAURMThree new OMs are added in this group for 1XRTT.

Table 5-7: OM Group: CAURM


MSC/ BSC/ BTS

V/D Basis

Service ResourceManagerNegative AcK for3G Data calls

SRMNAK3D pegged only in cases of 3G Packet Data calls.SRMNAK3D is pegged, along with the appropriateCAU*BLKS OM, when Resource Manager (RM)receives a resource allocation failure indication fromSRMs. This is an error condition, indicatingmismatches between the RM and the SBS SRM.

MSC D pegged bytheRMU

SRM Time-Outfor 3G Data calls

SRMTO3D pegged only in cases of 3G Packet Data calls.SRMTO3D is pegged, along with the appropriateCAU*BLKS OM, when Resource Manager times outwaiting on a request for call resources from theSRM.




Table 5-7: OM Group: CAURM


MSC/ BSC/ BTS

V/D Basis

NO Resourcesfor REQuest for3G Data calls

NORREQ3D pegged only in cases of 3G Packet Data calls.NORREQ3D is pegged, along with the appropriateCAU*BLKS OM, when Resource Manager (RM) hasno available resources to allocate for a call. In thiscase, the RM does not message to any of its SBSsto determine availability, only internal data structuresare checked.


5.8. OM Group: CAUCPSYSThree new OMs are added in this group for1XRTT.

Table 5-8: OM Group: CAUCPSYS


MSC/ BSC/ BTS

V/D Basis

Network-InitiatedShort Data BurstATTempts

NISDBATT Pegged when the CAU receives a Short Data Burstmessage from the PCU to send to the mobile. SDBis being considered for future release, and thus thisregister will not get pegged in the initial release of1XRTT.

MSC V+D

Network-InitiatedShort Data BurstSuCcess

NISDBSC Pegged when the CAU receives a response from themobile to the SDB message sent. SDB is beingconsidered for future release, and thus this registerwill not get pegged in the initial release of 1XRTT.

MSC V+D

Network-InitiatedShort Data BurstFaiLure

NISDBFL Pegged when the CAU times out waiting for aresponse from the mobile to the SDB message sent.SDB is being considered for future release, and thusthis register will not get pegged in the initial releaseof 1XRTT.

MSC V+D

5.9. OM Group: CDMAPGZNOne new OM is added in this group for 1XRTT.

Table 5-9: OM Group: CDMAPGZN




MSC/ BSC/ BTS

V/D Basis

Paging Zonenetwork-initiatedShort Data Burstattempts during a3G dormant datacall

PGZSDB3G pegged when the MSC receives a Short Data Burstdelivery message from the CAU. PGZSDB3G isfound in the CDMAPGZN group. SDB is beingconsidered for future release, and thus this registerwill not get pegged in the initial release of 1XRTT.

MSC D perpagingzone

5.10. OM Group: PCU

Table 5-10: OM Group: PCUOM Full Name OM Register

(Name)Description MSC /

BSC /BTS

V/D Basis

Reliable PacketSent Success

ReliablePacketSentSuccess

Counts the number of ACKs received as a result ofreliable packets being sent to any given PDSN.

BSC D per-nodebasis

Reliable PacketReTransmitted

ReliablePacketReTransmitted

Counts the number of reliable packets that had to beretransmitted because no ACK was received.

BSC D per-nodebasis

Reliable PacketReceived

ReliablePacketReceived

Counts the number of messages the PCU receivedwith reliable delivery acknowledgement requestedper L2TP tunnel

BSC D per-nodebasis

Number OfTunnel Failures

NumberOfTunnelFailures

Counts the number of times a L2TP tunnel was torndown due to failure of reliable packet transmissionper L2TP tunnel

BSC D per-nodebasis

Total UnreliableBytesTransmitted

TotalUnreliableBytesTransmitted

Counts the cumulative number of bytes eachsession in the PCU transmitted to PDSN per L2TPtunnel

BSC D per-nodebasis

Total UnreliableBytes Received

TotalUnreliableBytesReceived

Counts the cumulative number of bytes eachsession in the PCU received from PDSN per L2TPtunnel

BSC D per-nodebasis

Total FwdPackets Dropped

TotalFwdPacketsDropped

Number of PPP packets dropped in the forwarddirection per PCU

BSC D per-callbasis

Total RevPackets Dropped

TotalRevPacketsDropped

Number of PPP packets dropped in the reversedirection per PCU

BSC D per-callbasis



Table 5-10: OM Group: PCUOM Full Name OM Register


BSC /BTS

V/D Basis

DCR BufferOverflows

DCRBufferOverflows

Number of DCR buffer overflows per PCU BSC D per-callbasis

RR BufferOverflows

RRBufferOverflows

Number of RR buffer overflows BSC D per-callbasis

Total SessionSetup InitialAttempts

TotalSessionSetupInitialAttempts

Number of packet session setups attempted duringinitial session setup

BSC D per-callbasis

Total SessionSetup ReconnectAttempts

TotalSessionSetupReconnectAttempts

Number of packet session setups attempted whenreconnecting to an existing PPP session

BSC D per-callbasis

Total SessionSetup Success

TotalSessionSetupSuccess

Number of successful packet session setups, eitherby initial or reconnect attempts

BSC D per-callbasis

Total SessionSetup Failures

TotalSessionSetupFailures

Number of failed packet session setups BSC D per-callbasis

Reliable PacketSent SuccessOverflow

ReliablePacketSentSuccessOverflow

Register allows values greater than 65535 forReliablePacketSentSuccess.

BSC D per-nodebasis

Reliable PacketReTransmittedOverflow

ReliablePacketReTransmittedOverflow

Register allows values greater than 65535 forReliablePacketReTransmitted.

BSC D per-nodebasis

Reliable PacketReceivedOverflow

ReliablePacketReceivedOverflow

Register allows values greater than 65535 forReliablePacketReceived.

BSC D per-nodebasis

Total UnreliableBytesTransmittedOverflow

TotalUnreliableBytesTransmittedOverflow

Register allows values greater than 65535 forTotalUnreliableBytesTransmitted.

BSC D per-nodebasis

Total UnreliableBytes ReceivedOverflow

TotalUnreliableBytesReceivedOverflow

Register allows values greater than 65535 forTotalUnreliableBytesReceived.

BSC D per-nodebasis

Total FwdPackets DroppedOverflow

TotalFwdPacketsDroppedOverflow

Register allows values greater than 65535 forTotalFwdPacketsDropped.

BSC D per-callbasis

Total RevPackets DroppedOverflow

TotalRevPacketsDroppedOverflow

Register allows values greater than 65535 forTotalRevPacketsDropped.

BSC D per-callbasis



5.11. OM Group: ESEL

Table 5-11: OM Group: ESEL


MSC/ BSC/ BTS

V/D Basis

RLP SetupAttempts

RLPSetupAttempts

Number of RLP setups attempted BSC D RLPperformance

RLP SetupSuccesses

RLPSetupSuccesses

Number of successful RLP setups BSC D RLPperformance

RLP SetupFailures

RLPSetupFailures

Number of failed RLP setups BSC D RLPperformance

Fwd Burst SetupAttempts

FwdBurstSetupAttempts

Pegged when a forward data burst needs to be setup

BSC D datasessionsetup

Fwd Burst SetupSuccesses

FwdBurstSetupSuccesses

Pegged when a forward data burst is successfullyset up


Fwd Burst SetupFailures

FwdBurstSetupFailures

Pegged when a forward data burst could not be setup


Rev Burst SetupAttempts

RevBurstSetupAttempts

Pegged when a reverse data burst needs to be setup


Rev Burst SetupSuccesses

RevBurstSetupSuccesses

Pegged when a reverse data burst is successfullyset up






MSC/ BSC/ BTS

V/D Basis

Rev Burst SetupFailures

RevBurstSetupFailures

Pegged when a reverse data burst could not be setup


FSCH Link SetupAttempts

FSCHLinkSetupAttempts

Number of forward supplemental channel (FSCH)setup attempts

BSC D SCHsetup

FSCH Link SetupBlock

FSCHLinkSetupBlock

Number of FSCH setup attempts that are blockedfor lack of resources (reason Oms are given below)

BSC D SCHsetup

FSCH LinkDowngrade

FSCHLinkDowngrade

Number of FSCH setup attempts that are notgranted the requested data rate due to lack ofresources, but are granted a lower data rate.Pegged against the primary pilot in the SCH activeset.

BSC D SCHsetup

FSCH Link SetupSuccess

FSCHLinkSetupSuccess

Number of FSCH setup successes BSC D SCHsetup

FSCH Radio LinkAccess Failure

FSCHRadioLinkAccessFailure

This OM is pegged in the event the resources for theFSCH are set up successfully, but the mobile doesnot arrive on the FSCH. It is pegged against eachlink in the SCH active set.

BSC D SCHsetup

FSCH No FwdPower

FSCHNoFwdPower

Pegged if the FSCHBlock reason indicates a lack ofavailable forward power

BSC D SCHsetup

FSCH No WalshCode

FSCHNoWalshCode

Pegged if the FSCHBlock reason indicates a lack ofavailable Walsh codes

BSC D SCHsetup

FSCH No PhysRes

FSCHNoPhysRes

Pegged if the FSCHBlock reason indicates there areno available channel elements

BSC D SCHsetup

FSCH No FrameOffset

FSCHNoFrameOffset

Pegged if the FSCHBlock reason indicates there isno available frame offset

BSC D SCHsetup

FSCH CFDSRadio Config

FSCHCFDSRadioConfig

Pegged if the FSCHBlock reason indicates SCHburst functionality has not been enabled throughCFDS

BSC D SCHsetup

FSCH Timeout FSCHTimeout

Pegged if a response to the BTS resource request isnever received

BSC D SCHsetup

RSCH Link SetupAttempt

RSCHLinkSetupAttempt

Number of reverse supplemental channel (RSCH)setup attempts

BSC D SCHsetup

RSCHLinkSetupBlock

RSCHLinkSetupBlock

Number of RSCH setup attempts that are blockedfor lack of resources (reason Oms are given below)

BSC D SCHsetup

RSCH LinkDowngrade

RSCHLinkDowngrade

Number of RSCH setup attempts that are notgranted the requested data rate due to lack ofresources, but are granted a lower data rate.Pegged against the primary pilot in the SCH activeset.

BSC D SCHsetup





MSC/ BSC/ BTS

V/D Basis

RSCH Link SetupSuccess

RSCHLinkSetupSuccess

Number of RSCH setup successes BSC D SCHsetup

RSCH Radio LinkAccess Failure

RSCHRadioLinkAccessFailure

This OM is pegged in the event the resources for theRSCH are setup successfully, but the mobile doesnot arrive on the RSCH. It is pegged against eachlinkin the SCH active set.

BSC D SCHsetup

RSCH No PhysRes

RSCHNoPhysRes

Pegged if the RSCHBlock reason indicates there areno available channel elements

BSC D SCHsetup

RSCHNoFrameOffset

RSCHNoFrameOffset

Pegged if the RSCHBlock reason indicates there isno available frame offset

BSC D SCHsetup

RSCH CFDSRadio Config

RSCHCFDSRadioConfig

Pegged if the RSCHBlock reason indicates SCHfunctionality has not been enabled through CFDS

BSC D SCHsetup

RSCH CFDSHigh Speed

RSCHCFDSHighSpeed

Pegged if the RSCHBlock reason indicates highspeed RSCH has not been enabled through CFDS

BSC D SCHsetup

RSCH Timeout RSCHTimeout

Pegged if a response to the BTS resource request isnever received

BSC D SCHsetup

SCHDrop SCHDrop Pegged if the forward or reverse supplementalchannel gets abnormally dropped. This OM ispegged against every pilot in the SCH active set.

BSC D SCHsetup

5.12. OM Group: BTSCallProcessing MO

Table 5-12: OM Group: BTSCallProcessing MO


MSC/ BSC/ BTS

V/D Basis

Paging ChannelMessage Count

PagingChannelMessageCount

Number of paging channel messages sent to theBTS by the PAM in the CAU. This includes pages,repages, SMS, etc.

BTS V+D per-BTSbasis

Paging ChannelMessagesDropped

PagingChannelMessagesDropped

Number of paging channel messages dropped bythe BTSC due to BTSC CPU overload.

BTS V+D per-BTSbasis



5.13. OM Group: Advanced Frequency Assignment (FA) MO

Table 5-13: OM Group: Advanced Frequency Assignment (FA) MOOM Full Name OM Register


BSC /BTS

V/D Basis

Num Of TCAvailable

NumOfTCAvailable

Total number of channel elements available fortraffic across all channel cards after overheadchannels have been subtracted.

BTS V+D per-freq

basis

TCE UtilMaximum

TCEUtilMaximum

The peak number of channel elements in use,simultaneously, during a given time.

BTS V+D per-freqbasis

Total ForwardPhysicalResources

TotalForwardPhysicalResources

The number of 3G XCEM resources provisioned forthe BTS’s forward link. This excludes all CCEMresources and faulty XCEM resources. This OM is asnapshot taken at the time of reporting. It does notrepresent how many resources are actually in use.


Sch ForwardPhysicalResourcesReserved

SchForwardPhysicalResourcesReserved

This OM is a subset ofTotalForwardPhysicalResources.SchForwardPhysicalResourcesReserved representsthe number of XCEM resources which are pre-allocated to the forward supplemental channel. Thisincludes resources for active and idle supplementalchannels. Since a short

setup time for data calls is crucial, resources for thesupplemental channel are pre-allocated instead ofbeing allocated at call setup.

BTS D Per-freqbasis

Sch MaximumForward PhysicalResources Used

SchMaximumForwardPhysicalResourcesUsed

This OM is a high water mark for the number ofXCEM resources being used for the forwardsupplemental channel at any time during thereporting period.

BTS D per-freqbasis

Fch 3G MaximumForward PhysicalResources Used

Fch3GMaximumForwardPhysicalResourcesUsed

This OM is a high water mark for the number ofXCEM resources being used for 3G calls on theforward fundamental channel at any time during thereporting period.


Total ReversePhysicalResources

TotalReversePhysicalResources

The number of 3G XCEM resources provisioned forthe BTS’s reverse link. This excludes all CCEMresources and faulty XCEM resources. This OM is asnapshot taken at the time of reporting. It does notrepresent how many resources are actually in use.




Table 5-13: OM Group: Advanced Frequency Assignment (FA) MOOM Full Name OM Register


BSC /BTS

V/D Basis

Sch ReversePhysicalResourceReserved

SchReversePhysicalResourceReserved

This OM is a subset ofTotalReversePhysicalResources.SchReversePhysicalResourcesReserved representsthe number of XCEM resources which are pre-allocated to the reverse supplemental channel. Thisincludes resources for active and idle supplementalchannels. Since a short

setup time for data calls is crucial, resources for thesupplemental channel are pre-allocated instead ofbeing allocated at call setup.

BTS D per-freqbasis

Sch MaximumReverse PhysicalResources Used

SchMaximumReversePhysicalResourcesUsed

This OM is a high water mark for the number ofXCEM resources being used for the reversesupplemental channel at any time during thereporting period.

BTS D per-freqbasis

Fch 3G MaximumReverse PhysicalResources Used

Fch3GMaximumReversePhysicalResourcesUsed

This OM is a high water mark for the number ofXCEM resources being used for 3G calls on thereverse fundamental channel at any time during thereporting period.


5.14. OM Group: Advanced Sector MO

Table 5-14: OM Group: Advanced Sector MOOM Full Name OM Register


BSC /BTS

V/D Basis

Voice FchForward Link UtilAverage

VoiceFchForwardLinkUtilAverage

Array containing the average forward power (i.e.average of sum of digital gain squared) used byRC’s supporting voice or circuit-switched data callson the fundamental channel. Each elementcorresponds to a different RC. The first element isfor RC1 and the last element is for RC5. This

information is useful in evaluating time impact ofvoice, data, and various radio configurations onsystem resources.

BTS V per-sectorbasis





BSC /BTS

V/D Basis

Data FchForward Link UtilAverage

DataFchForwardLinkUtilAverage

Array containing the average forward power (i.e.average of sum of digital gain squared) used byRC’s supporting packet data sessions on thefundamental channel. Each element corresponds toa different RC. The first element is for RC3 and thelast element is for RC5. This information is

useful in evaluating time impact of voice, data, andvarious radio configurations on system resources.

BTS D per-sectorbasis

Sch Forward LinkUtil Average

SchForwardLinkUtilAverage

Array containing the average forward power (i.e.average of sum of digital gain squared) used byRC’s supporting packet data sessions on thesupplemental channel. Each element corresponds toa different RC. The first element is for RC3 and thelast element is for RC5. This information is useful inevaluating time impact of voice, data, and variousradio configurations on system resources.


Percent TimeAbove Fwd DataCall BlockingThreshold

PercentTimeAboveFwdDataCallBlockingThreshold

This represents the percentage of time during the 2-second measurement interval that data calls wouldbe blocked based on the MaxDataResources andMaxDataFCHResources attributes in theAdvancedSector MO.


Configured FwdData CallBlockingThreshold

ConfiguredFwdDataCallBlockingThreshold

This metric represents the amount of poweravailable for data originations, terminations, andhandoffs into the BTS.


Fch OriginationNon Blocking 2G

FchOriginationNonBlocking2G

Number of successful BTS resource allocations for2G calls. This is not an indication of successful callattempts. This metric does not include calls thatwere allocated for 2G after being downgraded from3G. This metric also does not include non- referencepilot links setup for CASHO. 2G links, other than thereference pilot’s link, setup for CASHO are peggedunder FchHandoffNonBlocking2G.






BSC /BTS

V/D Basis

Fch Handoff NonBlocking 2G

FchHandoffNonBlocking2G

Array of 2 elements indicating the number ofsuccessful BTS resource allocations for 2Ghandoffs. The first element in the array (i.e.FchHandoffNonBlocking2G[0]) represents thenumber of successful BTS resource allocations for a2G non VPN-based soft handoff. The secondelement in the array (i.e.FchHandoffNonBlocking2G[1]) represents thenumber of successful BTS resource allocations for a2G VPN-based soft handoffs.

Note: This OM is not an indication of successfulhandoffs. Note that this metric also includes non-reference pilot links setup for CASHO.


Fch OriginationNon Blocking 3GVoice

FchOriginationNonBlocking3GVoice

Number of successful BTS resource allocations for3G voice calls on the fundamental channel. This isnot an indication of successful call attempts. Thismetric does not include non-reference pilot linkssetup for CASHO. 3G voice links, other than thereference pilot’s link, setup for CASHO are peggedunder FchHandoffNonBlocking3GVoice.


Fch OriginationNon Blocking 3GData

FchOriginationNonBlocking3GData

Number of successful BTS resource allocations for3G data calls on the fundamental channel. This isnot an indication of successful call attempts.

This metric does not include non-reference pilot linkssetup for CASHO. 3G data links, other than thereference pilot’s link, setup for CASHO are peggedunder FchHandoffNonBlocking3GData.


Fch OriginationNon Blocking 3GDowngrade 2G

FchOriginationNonBlocking3GDowngrade2G

Number of successful BTS resource allocations forfundamental channel 2G calls which weredowngraded from 3G calls attempts. This metricdoes not include non-reference pilot links setup forCASHO. 2G links, other than the reference pilot’slink, setup for CASHO are pegged under

FchHandoffNonBlocking2G.


Fch Handoff NonBlocking 3GVoice

FchHandoffNonBlocking3GVoice

Number of successful BTS resource allocations for3G voice handoffs on the fundamental channel. Notethat This is not an indication of successful handoffs.


Fch Handoff NonBlocking 3G Data

FchHandoffNonBlocking3GData

Number of successful BTS resource allocations for3G data handoffs on the fundamental channel. Notethat This is not an indication of successful handoffs.


Sch Burst NonBlocking 3G

SchBurstNonBlocking3G

Number of successful BTS resource allocations for3G data bursts on the supplemental channel. This isnot an indication of successful data bursts.






BSC /BTS

V/D Basis

Sch Handoff NonBlocking 3G

SchHandoffNonBlocking3G

Number of successful BTS resource allocations for3G data handoffs on the supplemental channel. Notethat This is not an indication of successful handoffs.


Blocked FchOriginations 2G

BlockedFchOriginations2G

Array indicating the number of 2G call attemptsblocked on the fundamental channel. Each arrayelement corresponds to a different blocking reason.


Blocked FchHandoffs 2G

BlockedFchHandoffs2G

Array indicating the number of 2G handoffs blockedon the fundamental channel. Each array elementcorresponds to a different blocking reason.


Blocked FchOriginations 3GVoice

BlockedFchOriginations3GVoice

Array indicating the number of 3G voice callattempts blocked on the fundamental channel. Eacharray element corresponds to a different blockingreason.


Blocked FchOriginations 3GData

BlockedFchOriginations3GData

Array indicating the number of 3G data sessionsblocked on the fundamental channel. Each arrayelement corresponds to a different blocking reason.


Blocked FchHandoffs 3GVoice

BlockedFchHandoffs3GVoice

Array indicating the number of 3G voice handoffsblocked on the fundamental channel. Each arrayelement corresponds to a different blocking reason.


Blocked FchHandoffs 3GData

BlockedFchHandoffs3GData

Array indicating the number of 3G data handoffsblocked on the fundamental channel. Each arrayelement corresponds to a different blocking reason.


Blocked SchBursts

BlockedSchBursts

Array indicating the number of 3G data burstsblocked on the supplemental channel. Each arrayelement corresponds to a different blocking reason.


Blocked SchHandoffs

BlockedSchHandoffs

Array indicating the number of 3G data handoffsblocked on the supplemental channel. Each arrayelement corresponds to a different blocking reason.


Frame Cnt FCH FrameCntFCH

Array indicating the total number of frames sent onthe forward link for every user on the fundamentalchannel. Each element in the array represents oneradio configuration from RC1 through RC5. Thearray begins with RC1.

BTS V+D per-sectorbasis

Frame Cnt SCH FrameCntSCH

Array indicating the total number of forward framesfor every user on the supplemental channel. Eachelement in the array represents one radioconfiguration from RC3 through RC5. The arraybegins with RC3.


CE Frame CntFCH

CEFrameCntFCH

Equivalent to FrameCntFCH with each frame beingdivided by the number of softer handoff links.






BSC /BTS

V/D Basis

CE Frame CntSCH

CEFrameCntSCH

Equivalent to FrameCntSCH with each frame beingdivided by the number of softer handoff links.


Primary FrameCnt FCH

PrimaryFrameCntFCH

Equivalent to FrameCntFCH with each frame beingdivided by the product of the number of softerhandoff links and the number of soft handoff links.


Primary FrameSCH

PrimaryFrameSCH

Equivalent to FrameCntSCH with each frame beingdivided by the product of the number of softerhandoff links and the number of soft handoff links.




6. List Of Operational Measurements (OMs)Requested By Sprint From Nortel And OtherVendorsTable 6 lists all requested Operational Measurements in FRD (highlighted in gray) whichwas sent to all vendors as well as current Operational Measurements availability for allvendors. 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 providingall the requested OMs. Risks associated with lack of OMs include:

• Inability to monitor Paging and Access channel occupancy and success as well as QuickPaging Channel performance

• Inability to monitor 3G Voice and Data performance, capacity, data rates, and service optionspecific impacts and contributions

• Inability to identify potential misconfigurations, failing network elements or requiredoptimization

• Very few tools for network monitoring and trouble shooting

• Will rely on customer complaints for network information.



To compensate for the lack of OMs, significant amount of drive testing can be required toprovide daily network performance information. Core RF has estimated that this couldrequire millions of dollars. Vendors plan to add more Operational Measurements in thefuture 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 ChannelOccupancy 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, ZoneBased Registration, Distance Based Registration and Forced Based Registration OMs are notavailable from any vendor.

5. Short Message Service – Nortel doesn’t have any OMs in that group. Motorola has just SMSReceived on Access Channel. Lucent and Samsung have some OMs. Average PagingChannel SMS Size, Average Forward Traffic Channel SMS Size, Average Access ChannelSMS Size and Average Reverse Traffic Channel Size OMs are not available from anyvendor.

6. Backhaul – Nortel doesn’t have any OMs in that group. Motorola is the only vendor withavailable Peak Backhaul Occupancy.

7. Originations – All vendors are supporting some OMs in that group with Lucent having thebest granularity. Lucent is the only vendor that has Silent Reorigination available.Origination Total # of 3G Data Unique Users is not available from any vendor. Somerequirements in that group are not applicable for Samsung since all Samsung channelresources are capable of 3G.

8. Terminations - All vendors are supporting some OMs in that group with Lucent having thebest granularity. Motorola is the only vendor that has Termination No Response fromMobile available. Some requirements in that group are not applicable for Samsung since allSamsung channel resources are capable of 3G.

9. IS-95B Features – Neither vendor has any Access Handoff, Access Entry Handoff and AccessProbe Handoff OMs available. Only Lucent has some Channel Assignment Into SoftHandoff OMs available.



10. Active Mode Voice Call - All vendors are supporting some OMs in that group. Nortel is theonly vendor that has Average Channel Elements per call available. Samsung is the onlyvendor that has Hard Handoff Request and Hard Handoff Denied available. Motorola is theonly vendor that has Hard Handoff Failure available and Lucent is the only vendor that hasAverage Long Term Power Required available.

11. Dedicated Control Channel - Neither vendor has OMs.

12. Forward Fundamental Channel Packet Data Call – Samsung doesn’t have any OMs in thatgroup. Lucent doesn’t have any Soft Handoff OMs in that group. Neither vendor hasAverage Soft Handoff Percentage Per Call. Neither vendor has any Hard Handoff OMs inthat group but some of Hard Handoff OMs are not applicable for Motorola and Lucent. Theonly Forward Fundamental Channel Data Burst OM that Motorola has is ForwardFundamental Channel Assignment.

13. Reverse Fundamental Channel Packet Data Call – Neither vendor has OMs.

14. Forward Supplemental Channel Packet Data Call – Motorola doesn’t have any Soft HandoffOMs in that group and requirement for Soft Handoff OMs in that group is not applicable forSamsung. Forward Supplemental Channel RLP Frames Sent, Forward SupplementalChannel RLP Retransmissions and Average Short Term Power Required OMs are notavailable from any vendor. Lucent has only one OM available in that group (ForwardSupplemental Channel Data Burst Assignment). Motorola is the only vendor that hasForward Supplemental Channel Bursts Interrupted available.

15. Reverse Supplemental Channel Packet Data Call - Neither vendor has any Soft HandoffOMs in that group but some of Soft Handoff OMs are not applicable for Motorola andLucent. Reverse Supplemental Channel RLP Retransmissions and Average RetransmissionsPer Data Burst OMs are not available from any vendor. Motorola is the only vendor that hasReverse Supplemental Channel Burst Interrupted available. Lucent is the only vendor thathas Reverse Supplemental Channel RLP Frames Received available but that is the onlyavailable Lucent OM in that group.

16. Active Mode Circuit Data Call - All vendors are supporting some OMs in that group withNortel having the best granularity. Nortel is the only vendor that has Average Soft HandoffPercentage Per Call, Average Channel Elements Per Call and Average Walsh Code LinksPer Call OMs available. The only vendor that has some Hard Handoff OMs in that group isalso Nortel. Some Hard Handoff OMs are not applicable to Motorola since Hard Handoffdoes not exist for circuit data call in Motorola system.

17. Packet Data Session - All vendors except Samsung are supporting some OMs in that groupwith Motorola having the best granularity. Nortel is very similar to Motorola and Lucent



supports just couple of OMs in that group. Neither vendor supports Total # 3G DataFundamental Channel Releases.

18. Circuit Data Session – Samsung doesn’t support any OMs in that group. Nortel onlysupports Forward Power Overload. Lucent and Motorola are only supporting Forward PowerOverload 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 Lucenthaving 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. Lucentsupports 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 theOMs in that group doesn’t have to be supported by Lucent, Motorola or Samsung.

Table 6 : List of Operational Measurements requested by SprintSupported OMs

RF Data Add'l Info

Operational Measurement Description

syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Paging Channel

Peak Paging Channel Occupancy L L L

Average Paging Channel Occupancy LS

LS

LS

Average Paging Channel Occupancy Used toSupport Packet Data Calls

Quick Paging Channel

Peak Quick Paging Channel Occupancy

Average Quick Paging Channel Occupancy




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Access Channel

Peak Access Channel Occupancy L L

Average Access Channel Occupancy S S

Average Access Channel Occupancy Used toSupport Packet Data Calls L L

Registrations

Time Based Registration

Zone Based Registration

Distance Based Registration

Power Up Registration LM

LM M

Power Down Registration LM

LM M

Parameter Based Registration M M M

Forced Registration

Short Message Service

Paging Channel Delivery

SMS Deliveries Over Paging Channel LS

LS

LS

Average Paging Channel SMS Size

Forward Traffic Channel Delivery

SMS Deliveries Over Forward TrafficChannel

LS

LS

LS

Average Forward Traffic Channel SMS Size

Access Channel Reception

SMS Received on Access Channel LMS

LMS

LMS

Average Access Channel SMS Size




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Reverse Traffic Channel Reception

SMS Received on Reverse Traffic Channel LS

LS

LS

Average Reverse Traffic Channel Size

Backhaul

Peak Backhaul Occupancy M M

Average Backhaul Occupancy LMS

LMS

Originations

Origination Attempts LMSN

LMSN

L

LMSN

Origination Blocks LMSN

LMSN

LLSN

LM

LMSN

Silent Reorigination L L L L

3G Origination Assigned 2G Resources LMNs

LMN

L LN L L L

2G Origination Assigned 3G Resources LMNs

LMN

L LN L L L

3G Origination Assigned Lower Data Rate N MN N N

Origination Cross Carrier Assignments MSN

MSN

S

Origination Total # of 3G Data Unique Users




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Total # 3G data call blocks (BSC element) MS M

Terminations

Termination AttemptsN N

LMS

LMS

LMS

Termination Blocks LMSN

LMSN

LMS

L L

3G Termination Assigned 2G Resources LMNs

LMN

L LN L L

2G Termination Assigned 3G Resources LMs

L L L L L

3G Terminations Assigned Lower Data RateN

LMN

LN L L

N L L

Termination Cross Carrier Assignments MS

MS S

Termination No Response from Mobile M M

IS-95B Features

Access Handoff

Access Handoff Original Sector m

Access Handoff Target Sector m

Access Entry Handoff

Access Entry Handoff Original Sector m

Access Entry Handoff Target Sector m

Access Probe Handoff

Access Probe Handoff Original Sector




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Access Probe Handoff Target Sector

Channel Assignment Into Soft Handoff

CAMSHO Request L L

CAMSHO Denied L L

CAMSHO Origination Assignment L L

CAMSHO Termination Assignment L L

CAMSHO Origination Blocks L L

CAMSHO Termination Blocks L L

Active Mode Voice Call

Dropped CallsM

LMN

LMN

LM

LMN

M LM

LM L

Soft Handoff

Soft Handoff Request LMS

LM L L

M L

Soft Handoff Denied LMS

LM L L

M L L

Soft Handoff Failures LMS

LM L L

M L

Average Soft Handoff Percentage Per Call LN N N N

Average Channel Elements Per Call N N N N

Average Code Links Per Call MNS

MNS

SN N M

Hard Handoff

Hard Handoff Request S

Hard Handoff Denied S




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Hard Handoff Failure M M M

Average Long Term Power Required L L L L

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 CallsM

LMN

MN

MN

LM M L

Soft Handoff

Soft Handoff Request M M M M

Soft Handoff Denied M M M M

Soft Handoff Failures M M M M

Average Soft Handoff Percentage Per Call

Average Channel Element Per Call M M

Average Walsh Code Links Per Call N MN N N M




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

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 LN

LN

LN M

Forward Fundamental Channel RLP FramesSent L L L

Forward Fundamental Channel RLPRetransmissions L L L

Average Short Term Power Required LN

LN

LN N

Forward Fundamental Channel Data BurstDenied

LN

LN L N

Reverse Fundamental Channel Packet Data Call

Reverse Fundamental Channel Data Burst

Reverse Fundamental Channel RLP FramesReceived

Reverse Fundamental Channel RLPRetransmissions

Average RLP Retransmissions Required PerData Burst

Forward Supplemental Channel Packet Data Call

Soft Handoff




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Average Soft handoff Percentage Per Call Ns

lN N N

Average Channel Elements Per Call Ns N N N

Average Walsh Code Links Per Call s

Forward Supplemental Channel Data Burst

Forward Supplemental Channel Data BurstAssignment

LMSN

LMN

LLMN

M LM

LM

LM L

Forward Supplemental Channel RLP FramesSent

Forward Supplemental Channel RLPRetransmissions

Forward Supplemental Channel BurstsInterrupted M M

Average Short Term Power Required

Forward Supplemental Channel Data BurstDenied

MSN

MN

MN M M

Forward Supplemental Data Burst Assigned aLower Rate

MN N N M

Reverse Supplemental Channel Packet Data Call

Soft Handoff

Soft Handoff Request l

m

Soft Handoff Request Denied l

m

Soft Handoff Failure l

m




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Average Soft Handoff Percentage Per Call l

Average Channel Elements Per Call

Supplemental Channel Data Burst

Reverse Supplemental Channel Assignments MSN

MN

MN M M M M

Reverse Supplemental Channel RLP FramesReceived L L L L L L L L

Reverse Supplemental Channel RLPRetransmissions

Average Retransmissions Per Data Burst

Reverse Supplemental Channel BurstInterrupted M M M

Supplemental Channel Data Burst Denied MSN

MN

MN M

Active Mode Circuit Data Call

Dropped CallsM

LMN

LMN

LM

LMN

M LM L L

M

Soft Handoff

Soft Handoff Request MMS

Soft Handoff Denied MMS

Soft Handoff Failure M M

Average Soft Handoff Percentage Per Call N N N N

Average Channel Elements Per Call N N N N

Average Walsh Code Links Per Call N N N N

Hard Handoff

Hard Handoff Request m




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Hard Handoff Denied m

Hard Handoff Failure mN N

Average Long Term Power Required N N N N

Packet Data Session

Peak Data Throughput NM

Average Data Throughput NM

Peak Duration NM

Average Duration NM

Buffer Overflow LM

LN

Total Dormant to Active Transitions N LM L

Average Dormant to Active Transitions N M M

Total # 3G Data Fundamental Channel Releases

Circuit Data Session

Peak Data Throughput

Average Data Throughput

Peak Duration

Average Duration

Buffer Overflow m

Forward Power Overload LMN

MN

MN M

Reverse Power Overload LM M M




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Channel Element Usage

Peak Channel Element Usage LN

LN L

Average Channel Element Usage LMS

LN M L

M

Walsh Code Usage

Peak Walsh Code Usage L L L

Average Walsh Code Usage LM

LM

LM

Data Throughput

Forward Link Peak Data Throughput M

Reverse Link Peak Data Throughput M

Forward Link Average Data Throughput M

Reverse Link Average Data Throughput M

Forward Link Peak Data Load

Reverse Link Peak Data Load

Forward Link Average Data Load M

Reverse Link Average Data Load M

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

lms

N




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Packet Success LNms

LN

Packet Submits lms

N

Reliable Packets Sent Success Overflow lms

N

Reliable Packets Re-Transmitted N

lms

N

Reliable Packets Re-Transmitted Overflow N

lms

N

Reliable Packets Received msN

N

Reliable Packets Received Overflow lms

N

Total Unreliable Bytes Transmitted N

lms

N

Total Unreliable Bytes Transmitted Overflow lms

N




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

Total Unreliable Bytes Received N

lms

N

Total Unreliable Bytes Received Overflow Lms

N

Total Fwd Packets Dropped SN

l

m

SN

Total Fwd Packets Dropped Overflow s

LMN

MLMN

Total Rev Packets Dropped lms

N

Total Rev Packets Dropped Overflow lms

N

DCR Buffer Overflows lms

N

DCR_NumOStop Transmit Msgs Sent lms

N

RRBuffer Overflows lms

N

Total Session Setup Initial Attempts sN N

Total Session Setup Reconnect Attempts ms

N




RF Data Add'l Info


syst

emzo

ne/M

Msit

ese

ctor

SOca

rrie

rch

anne

lty

pelin

kR

Cca

llse

ssio

nra

teus

age-

stat

edu

ratio

nPD

SN/IW

U/IW

FH

O S

tate

Rea

son

sour

ce ty

pePC

U/P

CF

N

Total Session Setup Successes mLN

M LN

Total Session Setup Failures mLN

LN

R-P interface mLN

LN

User Information mSN

SN

Tunnels mSN

SN

Tunnel Failures mSN

SN



7. References

1. “3G Data and Capacity Solutions Operational Measurements”, 411-2133-320, NortelNetworks, 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, March2002

5. “CDMA-NBSS Operational Measurements”, 411-2133-535, Nortel Networks, Standard07.07, February 2002

Date post:	23-Oct-2015
Category:	Documents
Upload:	tal-deri
View:	59 times
Download:	15 times

Nortel KPI Formula s Desc Detail 2

Documents