Nortel KPI Formula S Desc Detail 2 PDF

3G 1xRTT Nortel Operational Measurements
3G 1xRTT Nortel Operational

Measurements
Prepared by
Core RF Engineering
04/22/02
Your input is important. If you have questions, comments, or suggestions
regarding this document, contact the person listed above by e-mail or phone.
You may also contact Standards Development. (Address your e-mail message
to Standards Development or check the Standards Development web page
under TS&NO on Connected.) Your knowledge and insight are invaluable
resources for improving Sprint PCS documentation.
Sprint PCS Proprietary & Confidential
04/22/02 Page 1
Table of Contents
1. Introduction
2. Overview of 3G Voice and Data in Nortel Implementation
3. Performance Formulas
10
3.1.
Performance Formulas for 3G Voice
10
3.1.1. 3G Voice Call Success .................................................................................... 10
3.1.2. 3G Voice Total Blocks.................................................................................... 12
3.1.2.1. Detailed 3G Voice Blocks......................................................................... 14
3.1.3. 3G Voice Access Failures ............................................................................... 19
3.1.3.1. Detailed 3G Voice Access Failures........................................................... 21
3.1.4. 3G Voice Drop Calls ....................................................................................... 22
3.1.4.1. Detailed 3G Voice Drops .......................................................................... 24
3.1.5. 3G Voice Pre-MCTA Frequency Selection Failures....................................... 25
3.1.6. 3G Voice Pre-MCTA Resource Allocation Failures (per frequency) ............. 27
3.1.6.1. Detailed 3G Voice Pre-MCTA Resource Allocation Failures (per
frequency).................................................................................................. 29
3.1.7. 3G Voice Post-MCTA Traffic Distribution (per frequency)........................... 32
3.1.8. 3G Voice Post-MCTA Call Success (per frequency)...................................... 34
3.1.9. 3G Voice Post-MCTA Call Blocks (per frequency) ....................................... 35
3.1.9.1. Detailed 3G Voice Post-MCTA Call Blocks (per frequency)................... 37
3.1.10. 3G Voice Post-MCTA Access Failures (per frequency) ................................. 39
3.1.10.1. Detailed 3G Voice Post-MCTA Access Failures (per frequency) ............ 41
3.1.11. 3G Voice Post-MCTA RF related Drop Calls (per frequency) ....................... 43
3.2.
Performance Formulas for 3G Fundamental Channel Data
44
3.2.1. 3G Packet Data Call Success .......................................................................... 44
3.2.2. 3G Packet Data Total Blocks .......................................................................... 46
3.2.2.1. Detailed 3G Packet Data Blocks ............................................................... 47
3.2.3. 3G Packet Data Access Failure ....................................................................... 53
3.2.3.1. Detailed 3G Packet Data Access Failures ................................................. 55
3.2.4. 3G Packet Data Drop Calls ............................................................................. 56
3.2.4.1. Detailed 3G Packet Data Drop Calls......................................................... 57
3.2.5. 3G Packet Data Calls Dormant to Active Transition Average Rate ............... 59
3.2.6. 3G Data Pre-MCTA Frequency Selection Failures......................................... 60
3.2.7. 3G Data Pre-MCTA Resource Allocation Failures (per frequency) ............... 62
3.2.7.1. Detailed 3G Data Pre-MCTA Resource Allocation Failures (per
frequency).................................................................................................. 64
3.2.8. 3G Data Post-MCTA Traffic Distribution (per frequency)............................. 67
3.2.9. 3G Data Post-MCTA Call Success (per frequency)........................................ 69
04/22/02 Page 2
3.2.10. 3G Data Post-MCTA Call Blocks (per frequency) ......................................... 70

3.2.10.1. Detailed 3G Data Post-MCTA Call Blocks (per frequency)..................... 72
3.2.11. 3G Data Post-MCTA Access Failures (per frequency) ................................... 74
3.2.11.1. Detailed 3G Data Post-MCTA Access Failures (per frequency) .............. 76
3.2.12. 3G Data Post-MCTA RF related Drop Calls (per frequency) ......................... 78
3.2.13. PCU MO: 3G Data R-P Interface Packet Sessions ......................................... 79
3.2.13.1. 3G Data R-P Interface Packet Session Successes ..................................... 80
3.2.13.2. 3G Data R-P Interface Packet Session Failures ........................................ 81
3.2.13.3. 3G Data R-P Interface Performance Formulas.......................................... 82
3.2.14. ESEL MO: 3G Data RLP Sessions ................................................................. 83
3.2.14.1. 3G Data RLP Session Successes ............................................................... 84
3.2.14.2. 3G Data RLP Session Failures .................................................................. 84
3.3. Performance Formulas for 3G Forward Supplemental Channel
Data (ESEL MO)
85
3.3.1. Forward Burst Setup Success .......................................................................... 85
3.3.2. Forward Burst Setup Failures.......................................................................... 86
3.3.3. Forward SCH Blocks ...................................................................................... 87
3.3.3.1. Detailed Forward SCH Blocks .................................................................. 87
3.3.4. Forward SCH Access Failures ........................................................................ 89
3.3.5. Forward SCH Time Out .................................................................................. 90
3.3.6. Forward SCH Data Rate Downgrades............................................................. 90
3.4.
Performance Formulas for 3G Reverse Supplemental Channel Data
(ESEL MO)
91
3.4.1. Reverse Burst Setup Success........................................................................... 91
3.4.2. Reverse Burst Setup Failures .......................................................................... 92
3.4.3. Reverse SCH Blocks ....................................................................................... 93
3.4.3.1. Detailed Reverse SCH Blocks................................................................... 93
3.4.4. Reverse SCH Access Failures ......................................................................... 95
3.4.5. Reverse SCH Time Out................................................................................... 95
3.4.6. Reverse SCH Data Rate Downgrades ............................................................. 96
3.5.
Performance Formulas for BTS Managed Objects (MOs)
97
3.5.1. Advanced Sector 3G Fundamental Channel Formulas ................................... 97
3.5.1.1. 3G FCH Originations ................................................................................ 97
3.5.1.2. 3G FCH Soft Handoff Blocks ................................................................. 100
3.5.1.3. 3G Average number of FCH Handoff Links ........................................... 103
3.5.2. Advanced Sector 3G Supplemental Channel Formulas ................................ 104
3.5.2.1. 3G SCH Burst
105
3.5.2.2. 3G SCH Handoff Blocks
107
3.5.2.3. 3G Average number of SCH Handoff Links
109
3.5.3. Advanced Frequency Assignment (FA) Managed Object Formulas............. 110
4. Field Results Analysis
113
04/22/02 Page 3
4.1.
Access Failures
113
4.1.1. Access failures during originations and terminations: (CAUERLFL) .......... 115
4.1.2. Access failures during hard handoffs: (CAUHRLFL) .................................. 115
4.2.
Blocks
116
4.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE).................. 117
4.2.2. Blocking due to lack of Walsh codes: (CAUNOWCD)................................ 117
4.2.3. Blocking due to lack of forward capacity: (CAUFWCAP)........................... 118
4.2.4. Blocking due to lack of reverse capacity: (CAURECAP)............................. 118
4.2.5. Blocking due to lack of physical resources: .................................................. 119
4.2.6. Blocking due to no frame offset availability: (CAUNOFOF)....................... 119
4.2.7. Blocking due to BTS time-outs:.................................................................... 120
4.2.8. Blocking due to BSC time-outs and software faults: .................................... 120
4.3. Drops
121
4.3.1. Drops due to RF-related reasons: (CAUDROPR)......................................... 122
4.3.2. Drops due to network-related reasons: (CAUDROPN) ................................ 122
5. New Operational Measurements in 3G 1xRTT
5.1.
OM Groups: CAUSCT3V, CAUSCT3D
5.2.
OM Groups: CAURFQ3V, CAUFRQ3D
5.3.
OM Group: CAUDAT3G
5.4.
OM Group: RMU3G (RMU OMs for 3G calls)
5.5.
OM Group: CDMAPDOM (CDMA Packet Data)
5.6.
OM Group: CDMAPDSO (CDMA Packet Data Service Option)
5.7.
OM Group: CAURM
5.8.
OM Group: CAUCPSYS
5.9.
OM Group: CDMAPGZN
5.10. OM Group: PCU
5.11. OM Group: ESEL
5.12. OM Group: BTSCallProcessing MO
5.13. OM Group: Advanced Frequency Assignment (FA) MO
5.14. OM Group: Advanced Sector MO
124
124
128
131
132
133
134
135
136
136
137
139
141
142
143
6. List Of Operational Measurements (OMs) Requested By

Sprint From Nortel And Other Vendors
148
7. References
165
04/22/02 Page 4
1. Introduction
1xRTT, also known as cdma2000, is a wideband, spread-spectrum radio interface that uses
code division multiple access (CDMA) technology to satisfy the needs of third-generation
(3G) wireless communication systems. The four main benefits offered by 1xRTT are:
Higher Capacity
Longer Mobile Battery Life in standby mode
High-speed packet data
Backward compatibility
The purpose of this document is to provide information about Nortels new 3G 1xRTT
Operational Measurements and related 3G 1xRTT Performance Formulas that should be
monitored in the field. The audience for this document is RF engineers that are working with
the Nortel equipment. In Section 5 all new 3G Operational Measurements are explained.
Performance formulas that can be used on daily basis and related OMs are explained in
Section 3.
Nortel plans to add more Operational Measurements in the future and for that reason this
document will need to be updated. List of all requested Operational Measurements as well
as current Operational Measurements availability for all vendors can be found in Section 6
Operational Measurements (OMs) are counts of call processing events that provide the
operating company with performance data for the DMS-MTX system. System engineers use
OM records to ensure that the DMS-MTX switch operates efficiently. OMs provide
information regarding system performance, grade of service being offered, connecting
facilities, performance, and traffic levels of various elements internal to and connected to the
system.
This document is based on Nortel Networks documentation (see references in Section 7), 3G
FMA test results and 2G experience.
It is assumed that the reader has basic technical knowledge of 1xRTT standard and 2G
Operational Measurements experience.
04/22/02 Page 5
2. Overview of 3G Voice and Data in Nortel

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

CAUSCT3D (CAU SeCTor based OMs for 3G Data calls)
CAUFRQ3V (CAU FReQuency based OMs for 3G Voice calls)
CAUFRQ3D (CAU FReQuency based OMs for 3G Data calls)
CAUDAT3G (CAU sector based OMs for short DATa bursts initiated by 3G mobiles)
RMU3G (RMU OMs for 3G calls)
CDMAPDOM (CDMA Packet Data OMs)
CDMAPDSO (CDMA Packet Data Service Option OMs)
04/22/02 Page 6
In addition to the above OM groups, the following OM groups have been modified for
1xRTT in the MSC:
CAUCPSCT (CAU SeCTor based OMs for Call Processing)

Enhanced to capture additional BTS resource allocation failures.
CAUCPFRQ (CAU FReQuency based OMs for Call Processing)

Enhanced to capture additional BTS resource allocation failures.
CAURM (CAU OMs relating to the resource manager)

Enhanced to contain both 2G call information and 3G information. This is done by
indexing the current OM structure by way of a new key field CDMA_CALLTYPE.
Three new registers are also added to CAURM OM group (listed in Section 5).
CDMAPGZN (CM OMs relating to the page zone events)

Enhanced to capture network-initiated Short Data Burst (SDB) related events.
CAUCPSYS (CAU OMs relating to the Call Processing System)

Enhanced to capture network-initiated Short Data Burst (SDB) related events.
OM3G Boolean field:

A new Boolean field OM3G is created in the CDMAPART table to indicate whether the
OMs for 3G voice calls and 3G data calls are to be kept separate from the OMs for 2G calls.
The new OM groups CAUSCT3V, CAUSCT3D, CAUFRQ3V, CAUFRQ3D maintain 3G
voice and 3G data OM counts for a particular sector only if OM3G Bool is set to Y. If a
particular sector is 3G capable but OM3G is set to N, then the 3G voice and 3G data OM
counts are lumped together with the 2G OMs in the CAUCPSCT and CAUCPFRQ OM
groups. The following table can be used to understand the functionality of the OM3G Bool:
NOTE: SPCS Core RF recommended value for OM3G is Y.
Table 2-2: OM3G Bool
OM3G Impact on CAUCPSCT and
Bool CAUCPFRQ OM groups
Impact on CAUSCT3V and

CAUFRQ3V OM groups
Impact on CAUSCT3D and

CAUFRQ3D OM groups
The registers in these two OM

groups get pegged only for events groups get pegged only for events groups get pegged only for events
related to 2G calls
related to 3G Voice calls
related to 3G Data calls

groups get pegged only for all call- groups do not get pegged. The
related 3G voice call-specific
related events (3G Voice, 3G
events will be captured in
Data, and 2G calls)
CAUCPSCT and CAUCPFRQ
OM groups along with 3G Data
and 2G call-related events

groups do not get pegged. The
related 3G Data call-specific
events will be captured in
CAUCPSCT and CAUCPFRQ
OM groups along with 3G voice
and 2G call-related events
04/22/02 Page 7
MCTA OMs:
The MSC has another set of OMs available under the MCTA reports. The MCTA
performance reflects how well the system is allocating resources across multiple frequencies
for new originations, terminations, and hard handoff attempts from other CDMA cells. The
performance is determined on a per frequency basis. MCTA OMs do not replace the normal
call processing OMs but are pegged in addition to the normal call processing OMs.
Consequently there is some duplicate information.
BSC OMs:
BSC OMs are collected by the following two managed objects (MOs):
The Packet Control Unit (PCU)
PCU OMs help in evaluating the R-P link between the SBS and the PDSN and in the
setup of packet data sessions over the L2TP tunnel.
The Enhanced Selector Card (ESEL)
ESEL OMs help in evaluating the performance of the RLP, the setup of supplemental
channels, and the setup of data session elements on the selector card.
Both of these MOs are new for 1xRTT; and are collected in the subsystems and forwarded to
the base station subsystem manager (BSSM) every 30 minutes in the form of a
ConsolidatedOM Event Report, using the mechanism developed for the CDMA-LTX
product.
BTS OMs:
The RF-related BTS OMs are collected by the following five managed objects (MOs):
BTSCallProcessing
These OMs are pegged on a per-BTS basis. Each of these pegs is the sum of all events in
every frequency and every sector hosted by the BTS.
Advanced FA MO
Advanced Frequency Assignment (FA) OMs deal with the status of XCEM resources on
the fundamental as well as the supplemental channels.
CBCM MO
The CBCM provides management of the entire MCBTS, communications over the T1/E1
and to the mate DCG. The CBCM hardware is composed of the BTS controller and the
BTS Interface.
Power Management MO
These are pegged on a per CDMA frequency, per-sector basis for all the supported
frequencies.
04/22/02 Page 8
Advanced Sector MO
These are pegged on a per-sector basis for all of the supported frequencies. Events
pegged in these OMs include BTS resource allocations, call attempts blocks and handoff
blocks.
04/22/02 Page 9
3. Performance Formulas
This section lists the 1xRTT performance formulas for 3G voice, 3G data, and 3G forward
and reverse supplemental channel data.
Field results presented in this section are four-days results from Kansas City market,
specifically the K1B1 and K2B2 test clusters which include 30 sites.
Please note that there are three different sets of formulas as follows:
1. Formulas currently supported by the ePerformance tool: These are the formulas that are
currently being used on a daily basis for performance monitoring. For these formulas, we
have the field data available.
2. Formulas for which no reports are available in the ePerformance tool: These are detailed
formulas with specific information. For example, 3G voice call blocks due to lack of
Walsh codes. For this type of formulas, no reports or plots are currently provided in the
tool. However, the OMs relating to these formulas are pegged; and are available in the
raw format. The field result values for these can be calculated by post processing the raw
data.
3. Formulas not supported by the ePerformance tool: For these formulas, the relevant OMs
are not currently pegged.
In this section, all of the above mentioned formula types along with their OMs are listed.
Please note that the results for 3G Data calls are outside the desired ranges for many
performance formulas. This is because the data calls are mostly collected from a very small
set of sectors. Additionally, the number of data users (data call attempts) are not sufficient
to validate test results. Therefore, it is not possible to provide field result ranges that are
statistically valid at this point in time. However, as more field results become available
from several different markets, this document will be updated to reflect those results.
3.1. Performance Formulas for 3G Voice

3.1.1. 3G Voice Call Success
Formula
Call Succ% = [Number of successful calls / Total calls Attempted] * 100
04/22/02 Page 10
Number of successful calls =

CAUSCT3V.CAUOSUCC +
CAUSCT3V.CAUTSUCC +
CAUSCT3V.CAUHSUCC
Total calls Attempted =
CAUSCT3V.CAUOATTS +
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
FchOriginationNonBlocking3GDowngrade2G
NOTE: Currently the ePerformance tool does not take into account 3G call
attempts downgraded to 2G. The FchOriginationNonBlocking3Gdowngrade2G is
a BTS OM which is pegged when the BTS runs out of XCEM resources but still
has CEM resources and all other needed resources to be set up for the call as a 2G
voice call rather than a 3G voice call as requested.
OMs
CAU Origination SUCCess
CAUOSUCC
Pegged when a mobile-originated call successfully arrives on the traffic channel.
This includes all originations placed on the traffic channel to receive treatment.
CAU Termination SUCCess
CAUTSUCC
Pegged when a mobile-terminated call successfully arrives on the traffic channel.
CAU hard Handoff SUCCess
CAUHSUCC
Pegged when a mobile, attempting a hard handoff, successfully arrives on the
traffic channel in the target sector.
CAU Origination ATTemptS
CAUOATTS
Pegged when the CAU receives an origination message from the BTS. Test call
originations are pegged in a separate OM.
CAU PaGe RESponse
CAUPGRES
For mobile-terminated calls, attempts are recorded in CAUPGRES, which
indicates that a page response was received from a CDMA sector in response to a
page request (irrespective of whether it was in response to an initial page request
or a retry by the CM).
04/22/02 Page 11
CAU hard Handoff ATTemptS

CAUHATTS
Pegged when the CAU receives a ReadyNewCell message from the CM,
indicating that a hard handoff attempt sequence in a (CDMA) target sector should
begin.
Number of successful BTS resource allocations for fundamental channel 2G calls
which were downgraded from 3G calls attempts. This metric does not include
non-reference pilot links setup for CASHO. 2G links, other than the reference
pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G.
Field Results
Day 1: 92.28 %
Day 2: 91.95 %
Day 3: 92.09 %
Day 4: 94.49 %
Expected Formula Range:

It should match the 2G Voice Call Success.
3.1.2. 3G Voice Total Blocks
Please note that currently the total blocks percentage given by the ePerformance
tool does not take into account 3G call attempts downgraded to 2G. The
FchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged when
the BTS runs out of XCEM resources but still has CEM resources and all other
needed resources to be set up for the call as a 2G voice call rather than a 3G voice
call as requested.
Formula
Total Blocks% = [Total number of blocked calls / Total calls attempted] * 100
Total number of blocked calls =
CAUSCT3V.CAUOBLKS +
CAUSCT3V.CAUTBLKS +
04/22/02 Page 12
CAUSCT3V.CAUHBLKS
Total calls attempted
CAUSCT3V.CAUOATTS +
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
OMs
CAU Origination BLocKS
CAUOBLKS
Pegged any time a mobile-originated call setup fails due to resource shortage. It
represents the total number of origination setup failures in a sector, regardless of
resource. The same failure reasons that are pegged for CAUTBLKS can be pegged
in conjunction with CAUOBLKS.
CAU Termination BLocKS
CAUTBLKS
Pegged any time a mobile-terminated call setup fails due to resource shortage. It
represents all of the termination setup failures in a sector, regardless of resource.
One or more of the following call setup failure reasons is pegged in conjunction
with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,
CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and
CAUESWFL.
CAU hard Handoff BLocKS
CAUHBLKS
Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource
shortage. It represents all of the hard handoff setup failures into a sector,
regardless of resource. This OM is pegged for both inter- and intra-system hard
handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it
merely represents the number of times that a hard handoff could not be completed
due to resource shortages in the target cell/sectorthe call in the source cell is
still up. The same failure reasons that are pegged for CAUOBLKS (see previous
page) can be pegged in conjunction with CAUHBLKS.
CAUOATTS
CAU PaGe RESponse
CAUPGRES
04/22/02 Page 13

CAUHATTS
begin.
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. For
frequency level information, please refer Section 3.1.9.1.
Formulas
Blocks due to lack of traffic channel elements:
TCE% = [CAUSCT3V.CAUNOTCE /
(CAUSCT3V.CAUOATTS +
CAUSCT3V.CAUPGRES +
04/22/02 Page 14
CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100

Blocks due to lack of walsh codes:
WCD% = [CAUSCT3V.CAUNOWCD /
CAUSCT3V.CAUPGRES +
Blocks due to no frame offset availability:
Frame Offset% = [CAUSCT3V.CAUNOFOF /
CAUSCT3V.CAUPGRES +
Blocks due to lack of forward capacity:
FWDCAP% = [CAUSCT3V.CAUFWCAP /
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
FchOriginationNonBlocking3GDowngrade2G)] * 100
Blocks due to lack of reverse capacity:
REVCAP% = [CAUSCT3V.CAURECAP /
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
Blocks due to lack of physical resources:
Physical Resources% = [(CAURM.RMNORREQ +
CAUSCT3V.CAUERSFL)
/
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
Blocks due to BTS time-outs:
BTS Time-outs% = [(CAUSCT3V.CAUERSFL
04/22/02 Page 15
CAUSCT3V.CAUNOTCE CAUSCT3V.CAUNOWCD CAUSCT3V.CAUFWCAP CAUSCT3V.CAUNOFOF CAUSCT3V.CAURECAP CAUSCT3V.MCTAREQF CAUSCT3V.MCTAHRQF BlockedFchOrigination3Gvoice[6])

/
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
Blocks due to BCS time-outs and software faults:
BSC Time-outs% = [(CAURM.RMSRMTO +
CAURM.RMSRMNAK +
CAUSCT3V.CAUESWFL)
/
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
OMs
CAU NO Traffic Channel Element
CAUNOTCE
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a
BTS reports no traffic channel element via NOIS messages, regardless of
origination, termination or hard handoff.
CAU NO Walsh Code
CAUNOWCD
BTS reports no walsh code via NOIS messages, regardless of origination,
termination or hard handoff.
CAU NO Frame Offset
CAUNOFOF
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time
a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The
CSM 5000 is limited in how much traffic it can support on its reverse link because
04/22/02 Page 16
of the limitation on the number of decoding units (both Viterbi and Turbo) that an
be active on a frame offset (and adjacent frame offsets).
CAU ForWard CAPacity full
CAUFWCAP
a BTS reports forward capacity full via NOIS messages, regardless of origination,
CAU REverse CAPacity full
CAURECAP
a BTS reports reverse capacity full via NOIS messages, regardless of origination,
termination or hard handoff. However, currently there is no reliable mechanism
for estimating reverse link capacity and so this response is disabled on the BTS.
Consequently, this OM is never pegged.
Resource Manager NO Resources for REQuest
RMNORREQ
Pegged, along with the appropriate CAU*BLKS OM, when Resource Manager
(RM) has no available resources to allocate for a call. In this case, the RM does
not message to any of its SBSs to determine availability, only internal data
structures are checked.
CAU Error case, Radio Setup FaiLure
CAUERSFL
Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails
due to the fact that some BTS resource is not available. This OM is also pegged
when the BTS does not respond to resource requests. It is also pegged when the
Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA
enabled sector (that is, no available capacity on all co-located carriers).
MCTA REQuest Failure
MCTAREQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for origination or termination call setup. It is pegged on a per-sector
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA Handoff ReQuest Failure
MCTAHRQF
by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
04/22/02 Page 17
target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or

MCTALLFU.
RM SRM Time-Out
RMSRMTO
Pegged, along with the appropriate CAU*BLKS OM, when the Resource
Manager times out waiting on a request for call resources from the SRM.
RM Service Resource Manager Negative AcK
RMSRMNAK
Pegged, along with the appropriate CAU*BLKS OM, when the Resource
Manager (RM) receives a resource allocation failure indication from SRMs. This
is an error condition, indicating mismatches between the RM and the SBS SRM.
BlockedFchOriginations 3Gvoice
Array indicating the number of 3G voice call attempts blocked on the fundamental
channel. Each array element corresponds to a different blocking reason.
CAU Error case, SoftWare FauLt
CAUESWFL
due to time outs between software entities that should not occur (for example, no
response from the CM, failure message received from SBS, etc.).
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
04/22/02 Page 18
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 ePerformance
tool does not take into account 3G call attempts downgraded to 2G. The
FchOriginationNonBlocking3Gdowngrade2G is a BTS OM which is pegged
when the BTS runs out of XCEM resources but still has CEM resources and all
other needed resources to be set up for the call as a 2G voice call rather than a 3G
voice call as requested.
Formula
Acc Fails% = [Number of access failures / Total calls attempted] * 100
Number of access failures =
CAUSCT3V.CAUERLFL +
CAUSCT3V.CAUHRLFL
Total calls attempted =
CAUSCT3V.CAUOATTS +
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
04/22/02 Page 19
OMs
CAU Error Radio Link FaiLure
CAUERLFL
Pegged if the origination or termination fails because the mobile never arrived on
the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases
where the CAUOBLKS or CAUTBLKS OMs are pegged.
CAU hard Handoff Radio Link FaiLure
CAUHRLFL
Pegged if the hard handoff attempt fails because the mobile never arrived on the
target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not
pegged in cases where CAUHBLKS is pegged.
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
Field Results
Day 1: 2.17 %
Day 2: 2.26 %
04/22/02 Page 20
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.CAUPGRES FchOriginationNonBlocking3GDowngrade2G)] * 100
Access failures during hard handoffs:
Handoff% = [CAUSCT3V.CAUHRLFL / CAUSCT3V.CAUHATTS] *100
OMs
CAUERLFL
CAUHRLFL
CAUOATTS
04/22/02 Page 21
CAU PaGe RESponse

CAUPGRES
CAUHATTS
begin.
Field Results:
Orig&Term
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
Hard Handoff

N/A
3.1.4. 3G Voice Drop Calls
Formula
Drop Call% = [Number of drop calls / Number of successful calls] * 100
04/22/02 Page 22
Number of drop calls =

CAUSCT3V.CAUDROPR +
CAUSCT3V.CAUDROPN
CAUSCT3V.CAUOSUCC +
CAUSCT3V.CAUTSUCC +
CAUSCT3V.CAUHSUCC
OMs
CAU DROPped call Rf
CAUDROPR
Pegged by the CAU against the reference pilot when a call is dropped by the SBS
due to loss of traffic or due to HCM (handoff completion message) timeout
for soft or softer handoff. These are RF-related call failures as detected by the
SBS.
CAU DROPped call Network
CAUDROPN
Pegged by the CAU when any of the other (non-RF) drop indication reasons are
sent from the SBS in the radio link drop indication message.
CAUOSUCC
CAUTSUCC
CAUHSUCC
Field Results
Day 1: 2.05 %
Day 2: 2.29 %
Day 3: 1.91 %
04/22/02 Page 23
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
OMs
CAU DROPped call Rf
CAUDROPR
SBS.
CAUDROPN
CAUOSUCC
04/22/02 Page 24

CAUTSUCC
CAUHSUCC
Field Results:
RF-related
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
Network-related

N/A
3.1.5. 3G Voice Pre-MCTA Frequency Selection Failures
This section deals with failures that occur before the Carrier Determination
Algorithm (CDA) has selected a frequency. The following formula captures call
failures due to failure to select a frequency:
Formula
Freq. Sel. Fail% = [No. of Freq. Sel. Fail / Total calls attempts for all freqs] *
100
No. of Freq. Sel. Fail. =
CAUSCT3V.MCTAREQF +
CAUSCT3V.MCTAHRQF
Total calls attempts for all freqs =
CAUFRQ3V.MCTORIGS +
CAUFRQ3V.MCTPGRES +
CAUFRQ3V.MCTHCATT
04/22/02 Page 25
NOTE: CAUFRQ3V refers to the sum of the register for all frequencies on the
sector.
OMs
MCTAREQF
MCTALLFU.
MCTAHRQF
MCTALLFU.
MCTA ORIGination
MCTAORIG
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
MCTA PaGe RESponse
MCTAPGRES
For mobile-terminated calls, attempts are recorded in MCTPGRES, which
indicates that a page response was received from an MCTA enabled CDMA
sector in response to a page request. This OM is pegged irrespective of whether it
was the first or the second attempt to page the mobile. CAUPGRES is also pegged
whenever MCTPGRES is pegged.
MCTA Handoff Call ATTempts
MCTHCATT
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin.
Field Results
Day 1: 0.97 %
04/22/02 Page 26
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 (per
frequency)
This section deals with the events where a particular frequency responds with a
resource full response or times out in response to a capacity query request before
the Carrier Determination Algorithm (CDA) is executed. Note that this event may
or may not lead to overall MCTA frequency selection failure depending on
whether all other frequencies respond with a similar response or not. If at least one
frequency responds with a resource available response then the CDA will
successfully select a carrier for the call attempt.
Formula
MCTA frequency resource allocation failures (per frequency) % =
[No. of MCTA freq rsrc alloc failures / Total MCTA calls attempted] * 100
No. of MCTA freq resource allocation failures =
CAUSCT3V.MCTAREQF +
CAUSCT3V.MCTAHRQF +
CAUFRQ3V.MCTAREQN +
CAUFRQ3V.MCTAREQT
Total MCTA calls attempted =
CAUFRQ3V.MCTORIGS +
CAUFRQ3V.MCTPGRES +
CAUFRQ3V.MCTHCATT
OMs
MCTAREQF
04/22/02 Page 27

MCTALLFU.
MCTAHRQF
MCTALLFU.
MCTA REQuest response full or Not available
MCTAREQN
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs responded with a resource full or not available response. MCTAREQN
is pegged against the carrier(s) that respond with a resource full or not available
response. MCTAREQN may not always be pegged under low load conditions.
MCTA REQuest Timeout
MCTAREQT
the BTSs never responded to a capacity request. MCTAREQT is pegged against
the carrier(s) that did not respond to the capacity request. MCTAREQT may not
always be pegged under low traffic load conditions.
MCTA ORIGination
MCTAORIG
MCTA PaGe RESponse
MCTAPGRES
MCTHCATT
04/22/02 Page 28
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 (per

frequency)
Formulas
The following set of formulas deal with the percentage of MCTA frequency
resource allocation failures resulting due to lack of physical resources before the
Carrier Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to lack of physical resources:
No Rsrc% = [(CAUSCT3V.MCTALLFU +
CAURFQ3V.MCTARQFN +
CAUFRQ3V.MCTAREQN)
/
(CAUFRQ3V.MCTORIGS +
CAUFRQ3V.MCTPGRES +
CAUFRQ3V.MCTHCATT)] * 100
Case 1: Failures leading to overall MCTA frequency selection failure (BLOCK)
No Rsrc% = [(CAUSCT3V.MCTALLFU +
CAURFQ3V.MCTARQFN)
/
CAUFRQ3V.MCTPGRES +
04/22/02 Page 29
Case 2: Failures NOT leading to overall MCTA frequency selection failure
No Rsrc% = [CAURFQ3V.MCTAREQN
/
CAUFRQ3V.MCTPGRES +
resource allocation failures resulting due to time-outs before the Carrier
Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to time-outs:
Time Out% = [(CAUSCT3V.MCTALLTO +
(CAUSCT3V.MCTAMIXF
CAURFQ3V.MCTARQFN) +
CAUFRQ3V.MCTAREQT)
/
CAUFRQ3V.MCTPGRES +

Time Out% = [(CAUSCT3V.MCTALLTO +
(CAUSCT3V.MCTAMIXF
CAURFQ3V.MCTARQFN)
/
CAUFRQ3V.MCTPGRES +
Time Out% = [CAUFRQ3V.MCTAREQT
/
CAUFRQ3V.MCTPGRES +
OMs
MCTAREQN
04/22/02 Page 30
MCTAREQT
MCTA All frequencies Full
MCTALLFU
Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when
NO frequency was successfully selected by MCTA because none of the BTSs had
resources available. It is pegged on a per-sector basis.
MCTA ReQuest response Failed (full or Not available)
MCTARQFN
Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or
MCTAHRQF), when no frequency was successfully selected by MCTA because
some BTSs timed out, while some responded with a resource full or not available
response. MCTARQFN is pegged against the carrier(s) that respond with a
resource full or not available response.
MCTA ALL frequencies Timed-Out
MCTALLTO
NO frequency was successfully selected by MCTA because none of the BTSs
responded to the capacity request query. It is pegged on a per-sector basis.
MCTA MIXed Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or
MCTAHRQF), when NO frequency was successfully selected by MCTA because
some BTSs
timed-out while some responded with a resource full or not available response. It
is pegged on a per-sector basis.
MCTA ORIGination
MCTORIGS
04/22/02 Page 31
MCTA PaGe RESponse

MCTPGRES
MCTHCATT
target sector should begin
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.1.7. 3G Voice Post-MCTA Traffic Distribution (per frequency)
This is the percentage of traffic carried on a particular frequency on a sector when
compared to the other frequencies on that sector.
Formula
Traf Dist% =
[Calls continued on the given freq / Total number of calls on all freqs] * 100
Calls continued on the given frequency =
CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS
04/22/02 Page 32
Total number of calls on all freqs =

CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS
NOTE: CAUFRQ3V refers to the sum of the register for all frequencies on the
sector.
OMs
MCTA Origination ATTemptS
MCTOATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile origination in a sector with MCTA
enabled. Please note that the MCTA frequency for MCTOATTS may be different
from the MCTA frequency on which the call originated (MCTORIGS).
MCTA Termination ATTemptS
MCTTATTS
Determination Algorithm (CDA) for a mobile termination in a sector with MCTA
enabled.
MCTA Handoff ATTemptS
MCTHATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile hard handoff attempt into a target
sector with MCTA enabled.
Field Results:
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.
04/22/02 Page 33
3.1.8. 3G Voice Post-MCTA Call Success (per frequency)

This is the percentage of calls that successfully arrived on the traffic channel for a
particular frequency.
Formula
Succ% = [No. of successful calls / Total calls attempted] * 100
No. of successful calls =
CAUFRQ3V.MCTOSUCC +
CAUFRQ3V.MCTTSUCC +
CAUFRQ3V.MCTHSUCC
CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS
OMs
MCTA Origination SUCCess
MCTOSUCC
Pegged, along with CAUOSUCC, when a mobile-originated call successfully
arrives on the traffic channel. This includes all originations placed on the traffic
channel to receive treatment.
MCTA Termination SUCCess
MCTTSUCC
Pegged, along with CAUTSUCC, when a mobile-terminated call successfully
arrives on the traffic channel.
MCTA Hard-handoff SUCCess
MCTHSUCC
Pegged, along with CAUHSUCC, when a mobile successfully arrives on the
traffic channel after a hard handoff.
MCTOATTS
04/22/02 Page 34

MCTTATTS
enabled.
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
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 been
selected and the call setup is attempted on the selected frequency.
Formula
Total Blocks% = [Total no. of calls blocked / Total calls attempted] * 100
Total no. of calls blocked =
CAUFRQ3V.MCTERSFL
CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS
04/22/02 Page 35
OMs
MCTA Error case Radio link Setup FaiLure
MCTERSFL
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever
a call setup fails due to the fact that the BTS could not allocate resources due to
any of the BTS failure reasons. This OM is also pegged when the BTS does not
respond at all to resource requests. MCTERSFL is pegged only after an MCTA
frequency is selected. MCTERSFL is pegged against the selected frequency.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
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 %
04/22/02 Page 36
It should match the 2G Voice Post-MCTA Call Blocks

3.1.9.1. Detailed 3G Voice Post-MCTA Call Blocks (per frequency)
The following formulas deal with those calls that are blocked after the MCTA
frequency has been selected and the call setup is attempted on the selected
frequency.
Formulas
TCE% = [CAUFRQ3V.MCTNOTCE /
(CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS)] * 100
Blocks due to lack of Walsh codes:
WCD% = [CAUFRQ3V.MCTNOWCD /
CAUFRQ3V.MCTTATTS +
Frame Offset% = [CAUFRQ3V.MCTNOFOF /
CAUFRQ3V.MCTTATTS +
FWDCAP% = [CAUFRQ3V.MCTFWCAP /
CAUFRQ3V.MCTTATTS +
REVCAP% = [CAUFRQ3V.MCTRECAP /
CAUFRQ3V.MCTTATTS +
OMs
04/22/02 Page 37
MCTA NO Traffic Channel Element

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

MCTTATTS
enabled.
MCTHATTS
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

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

This is the percentage of access failures after the MCTA frequency has been
selected and resources are successfully setup on the selected frequency.
Formula
Acc Fails% = [Number of MCTA access failures / Total calls attempted] * 100
04/22/02 Page 39
Number of MCTA access failures =

CAURFQ3V.MCTERLFL +
CAUFRQ3V.MCTHRLFL
CAUFRQ3V.MCTOATTS +
CAUFRQ3V.MCTTATTS +
CAUFRQ3V.MCTHATTS
OMs
MCTA Error case, Radio Link FaiLure
MCTERLFL
Pegged, along with CAUERLFL, if the origination or termination fails because
the mobile never arrived on the traffic channel (similar to SAT timeout).
MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs
are pegged.
MCTA hard Handoff Radio Link FaiLure
MCTHRLFL
Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the
mobile never arrived on the target sectors traffic channel (similar to
SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is
pegged.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
04/22/02 Page 40
Field Results:
Freq1
Freq2
Freq3
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 the
MCTA frequency has been selected and resources are successfully setup on the
selected frequency.
Formulas
Orig & Term% = [CAURFQ3V.MCTERLFL
/
CAUFRQ3V.MCTTATTS)] * 100
Handoff% = [CAURFQ3V.MCTHRLFL / CAUFRQ3V.MCTHATTS] *100
OMs
MCTERLFL
are pegged.
MCTHRLFL
04/22/02 Page 41
pegged.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 42
3.1.11. 3G Voice
frequency)
Post-MCTA
RF
related
Drop
Calls
(per
This is the percentage of established calls on each frequency in MCTA enabled

sectors that are dropped due to RF related issues.
Formula
Drop Call% = [Number of RF related drop calls / Number of successful calls]
* 100
Number of RF related drop calls =
CAUFRQ3V.MCTDROPR
CAUFRQ3V.MCTOSUCC +
CAUFRQ3V.MCTTSUCC +
CAUFRQ3V.MCTHSUCC
OMs
MCTA DROPped call Rf
MCTDROPR
Pegged, along with CAUDROPR, when a call is dropped by the SBS due to loss
of traffic or due to HCM (handoff completion message) timeout for soft or
softer handoff. These are RF-related call failures as detected by the SBS.
CAUDROPN
MCTOSUCC
MCTTSUCC
04/22/02 Page 43
MCTHSUCC
Field Results:
Freq1
Freq2
Freq3
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 Channel

Data
3.2.1. 3G Packet Data Call Success
Formula
Call Succ% = [Number of successful calls / Total calls Attempted] * 100
CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC
Total calls Attempted =
CAUSCT3D.CAUOATTS +
CAUSCT3D.CAUPGRES +
CAUSCT3D.CAUHATTS
OMs
CAUOSUCC
04/22/02 Page 44

CAUTSUCC
CAUHSUCC
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
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.
04/22/02 Page 45
3.2.2. 3G Packet Data Total Blocks

Formula
Total Blocks% = [Total number of blocked calls / Total calls attempted] *
100
Total number of blocked calls =
CAUSCT3D.CAUOBLKS +
CAUSCT3D.CAUTBLKS +
CAUSCT3D.CAUHBLKS
Total calls attempted
CAUSCT3D.CAUOATTS +
CAUSCT3D.CAUPGRES +
CAUSCT3D.CAUHATTS
OMs
CAUOBLKS
CAUTBLKS
CAUESWFL.
CAUHBLKS
04/22/02 Page 46
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
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
frequency level information, please refer Section 3.2.10.1
Formulas
04/22/02 Page 47
Blocks due to origination setup failures:

Orig% = [CAUSCT3D.CAUOBLKS / CAUSCT3D.CAUOATTS] *
100
Blocks due to termination setup failures:
Term% = [CAUSCT3D.CAUTBLKS / CAUSCT3D.CAUPGRES] *
100
Blocks due to hard handoff setup failures:
Handoff% = [CAUSCT3D.CAUHBLKS / CAUSCT3D.CAUHATTS]
* 100
TCE% = [CAUSCT3D.CAUNOTCE /
(CAUSCT3D.CAUOATTS +
CAUSCT3D.CAUPGRES +
CAUSCT3D.CAUHATTS)] * 100
WCD% = [CAUSCT3D.CAUNOWCD /
CAUSCT3D.CAUPGRES +
Frame Offset% = [CAUSCT3D.CAUNOFOF /
CAUSCT3D.CAUPGRES +
FWDCAP% = [CAUSCT3D.CAUFWCAP /
CAUSCT3D.CAUPGRES +
REVCAP% = [CAUSCT3D.CAURECAP /
CAUSCT3D.CAUPGRES +
04/22/02 Page 48
Blocks due to lack of physical resources:

Physical Resources% = [(CAURM.NORREQ3D +
CAUSCT3D.CAUERSFL)
/
CAUSCT3D.CAUPGRES +
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.CAUPGRES +
Blocks due to BCS time-outs and software faults:
BSC Time-outs% = [(CAURM.SRMTO3D +
CAURM.SRMNAK3D +
CAUSCT3D.CAUESWFL)
/
CAUSCT3D.CAUPGRES +
OMs
CAUOBLKS
CAUTBLKS
04/22/02 Page 49
CAUESWFL.
CAUHBLKS
CAU NO Traffic Channel Element
CAUNOTCE
BTS reports no traffic channel element via NOIS messages, regardless of
CAU NO Walsh Code
CAUNOWCD
BTS reports no walsh code via NOIS messages, regardless of origination,
CAU NO Frame Offset
CAUNOFOF
a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The
CSM 5000 is limited in how much traffic it can support on its reverse link because
of the limitation on the number of decoding units (both Viterbi and Turbo) that an
be active on a frame offset (and adjacent frame offsets).
CAU ForWard CAPacity full
CAUFWCAP
a BTS reports forward capacity full via NOIS messages, regardless of origination,
04/22/02 Page 50
CAU REverse CAPacity full

CAURECAP
a BTS reports reverse capacity full via NOIS messages, regardless of origination,
termination or hard handoff. However, currently there is no reliable mechanism
for estimating reverse link capacity and so this response is disabled on the BTS.
Consequently, this OM is never pegged.
NO Resources for REQuest for 3G Data calls
NORREQ3D
Pegged only in cases of 3G Packet Data calls. NORREQ3D is pegged, along with
the appropriate CAU*BLKS OM, when Resource Manager (RM) has no available
resources to allocate for a call. In this case, the RM does not message to any of its
SBSs to determine availability, only internal data structures are checked.
CAU Error case, Radio Setup FaiLure
CAUERSFL
due to the fact that some BTS resource is not available. This OM is also pegged
when the BTS does not respond to resource requests. It is also pegged when the
Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA
enabled sector (that is, no available capacity on all co-located carriers).
MCTAREQF
MCTALLFU.
MCTAHRQF
MCTALLFU.
Blocked Fch Originations 3G Data
BlockedFchOriginations3GData
Array indicating the number of 3G data sessions blocked on the fundamental
channel. Each array element corresponds to a different blocking reason.
04/22/02 Page 51
SRM Time-Out for 3G Data calls

SRMTO3D
Pegged only in cases of 3G Packet Data calls. SRMTO3D is pegged, along with
the appropriate CAU*BLKS OM, when Resource Manager times out waiting on a
request for call resources from the SRM.
Service Resource Manager Negative AcK for 3G Data calls
SRMNAK3D
Pegged only in cases of 3G Packet Data calls. SRMNAK3D is pegged, along with
the appropriate CAU*BLKS OM, when Resource Manager (RM) receives a
resource allocation failure indication from SRMs. This is an error condition,
indicating mismatches between the RM and the SBS SRM.
CAU Error case, SoftWare FauLt
CAUESWFL
due to time outs between software entities that should not occur (for example, no
response from the CM, failure message received from SBS, etc.).
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
Field Results: Orig
Term
Day 1:
example
Day 2:
example
HandO
TCE
WalshC
NframO FwdC
04/22/02 Page 52
Day 3:
example
Day 4:
example
Field Results: RevC PhyR
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
BTSt-o
BSCt-o

N/A
3.2.3. 3G Packet Data Access Failure
Formula
Number of access failures =
CAUSCT3D.CAUERLFL +
CAUSCT3D.CAUHRLFL
CAUSCT3D.CAUOATTS +
CAUSCT3D.CAUPGRES +
CAUSCT3D.CAUHATTS
NOTE: The attempt to set up the R-P packet session is done after the mobile
arrives on the traffic channel but before sending the service connect message out
to the mobile. Thus if the R-P packet session setup fails, it will still be pegged as
an access failure. The TotalSessionSetupFailures (Number of failed packet
session setups) count can be subtracted from the numerator in the above formula
when measuring the RF Access Failure rate on a system wide basis.
OMs
04/22/02 Page 53

CAUERLFL
CAUHRLFL
CAUOATTS
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
Field Results
Day 1: 3.19 %
Day 2: 6.49 %
Day 3: 3.57 %
Day 4: 3.39 %
04/22/02 Page 54

3.2.3.1. Detailed 3G Packet Data Access Failures
Formulas
Orig & Term% = [CAUSCT3D.CAUERLFL /
CAUSCT3D.CAUPGRES)] * 100
Handoff% = [CAUSCT3D.CAUHRLFL / CAUSCT3D.CAUHATTS)] * 100
OMs
CAUERLFL
CAUHRLFL
CAUOATTS
CAU PaGe RESponse
CAUPGRES
04/22/02 Page 55

CAUHATTS
begin.
Field Results: Orig&Term
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Hard Handoff

N/A
3.2.4. 3G Packet Data Drop Calls
Formula
Number of drop calls =
CAUSCT3D.CAUDROPR +
CAUSCT3D.CAUDROPN
CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC
OMs
CAU DROPped call Rf
CAUDROPR
04/22/02 Page 56
SBS.
CAUDROPN
CAUOSUCC
CAUTSUCC
CAUHSUCC
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)
Formulas
Drops due to RF-related reasons:
04/22/02 Page 57
RF% = [CAUSCT3D.CAUDROPR /
(CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC)] * 100
Drops due to network-related reasons:
Ntwk% = [CAUSCT3D.CAUDROPN /
(CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC)] * 100
OMs
CAU DROPped call Rf
CAUDROPR
SBS.
CAUDROPN
CAUOSUCC
CAUTSUCC
CAUHSUCC
Field Results: RF-related
Network-related
Day 1: example
04/22/02 Page 58
Day 2: example
Day 3: example
Day 4: example

N/A
3.2.5. 3G Packet Data
Average Rate
Calls
Dormant
to
Active
Transition
Formula
Dormant to Active Transition% =
[No. of dormant to active transition
/
Total original 3G packet data call attempts] * 100
No. of dormant to active transition =
CDMAPDOM.MIDTOAAT +
CDMAPDOM.NIDTOAAT
Total original 3G packet data call attempts =
CAUSCT3D.CAUOATTS +
CAUSCT3D.CAUPGRES +
CAUSCT3D.CAUHATTS
OMs
Mobile-Initiated Dormant To Active ATtempts
MIDTOAAT
Pegged when the MSC receives an origination message from a mobile which is in
a dormant data call state.
Network-Initiated Dormant To Active ATtempts
NIDTOAAT
Pegged when the MSC receives a PCU_Page_Request after the network DCR
PLICF decides to make the transition to active state.
CAUOATTS
04/22/02 Page 59
CAU PaGe RESponse
CAUPGRES
CAUHATTS
begin.
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 Failures
This section deals with failures that occur before the Carrier Determination
Algorithm (CDA) has selected a frequency. The following formula captures call
failures due to failure to select a frequency:
Formula
Freq. Sel. Fail% = [No. of Freq. Sel. Fail / Total calls attempts for all freqs] *
100
No. of Freq. Sel. Fail. =
CAUSCT3D.MCTAREQF +
04/22/02 Page 60
CAUSCT3D.MCTAHRQF
Total calls attempts for all freqs =
CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT
NOTE: CAUFRQ3D refers to the sum of the register for all frequencies on the
sector.
OMs
MCTAREQF
MCTALLFU.
MCTAHRQF
MCTALLFU.
MCTA ORIGination
MCTAORIG
MCTA PaGe RESponse
MCTAPGRES
MCTHCATT
04/22/02 Page 61
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 (per
frequency)
This section deals with the events where a particular frequency responds with a
resource full response or times out in response to a capacity query request before
the Carrier Determination Algorithm (CDA) is executed. Note that this event may
or may not lead to overall MCTA frequency selection failure depending on
whether all other frequencies respond with a similar response or not. If at least one
frequency responds with a resource available response then the CDA will
successfully select a carrier for the call attempt.
Formula
MCTA frequency resource allocation failures (per frequency) % =
[No. of MCTA freq rsrc alloc failures / Total MCTA calls attempted] * 100
No. of MCTA freq resource allocation failures =
CAUSCT3D.MCTAREQF +
CAUSCT3D.MCTAHRQF +
CAUFRQ3D.MCTAREQN +
CAUFRQ3D.MCTAREQT
Total MCTA calls attempted =
CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
04/22/02 Page 62
CAUFRQ3D.MCTHCATT
OMs
MCTAREQF
MCTALLFU.
MCTAHRQF
MCTALLFU.
MCTAREQN
MCTAREQT
MCTA ORIGination
MCTAORIG
MCTA PaGe RESponse
MCTAPGRES
04/22/02 Page 63
MCTHCATT
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 (per
frequency)
Formulas
resource allocation failures resulting due to lack of physical resources before the
Carrier Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to lack of physical resources:
No Rsrc% = [(CAUSCT3D.MCTALLFU +
CAURFQ3D.MCTARQFN +
CAUFRQ3D.MCTAREQN)
/
(CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT)] * 100
04/22/02 Page 64
No Rsrc% = [(CAUSCT3D.MCTALLFU +
CAURFQ3D.MCTARQFN)
/
CAUFRQ3D.MCTPGRES +
No Rsrc% = [CAURFQ3D.MCTAREQN
/
CAUFRQ3D.MCTPGRES +
resource allocation failures resulting due to time-outs before the Carrier
Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to time-outs:
Time Out% = [(CAUSCT3D.MCTALLTO +
(CAUSCT3D.MCTAMIXF
CAURFQ3D.MCTARQFN) +
CAUFRQ3D.MCTAREQT)
/
CAUFRQ3D.MCTPGRES +

Time Out% = [(CAUSCT3D.MCTALLTO +
(CAUSCT3D.MCTAMIXF
CAURFQ3D.MCTARQFN)
/
CAUFRQ3D.MCTPGRES +
Time Out% = [CAUFRQ3D.MCTAREQT
/
CAUFRQ3D.MCTPGRES +
04/22/02 Page 65
OMs
MCTAREQN
MCTAREQT
MCTA All frequencies Full
MCTALLFU
NO frequency was successfully selected by MCTA because none of the BTSs had
resources available. It is pegged on a per-sector basis.
MCTA ReQuest response Failed (full or Not available)
MCTARQFN
Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or
MCTAHRQF), when no frequency was successfully selected by MCTA because
some BTSs timed out, while some responded with a resource full or not available
response. MCTARQFN is pegged against the carrier(s) that respond with a
resource full or not available response.
MCTA ALL frequencies Timed-Out
MCTALLTO
NO frequency was successfully selected by MCTA because none of the BTSs
responded to the capacity request query. It is pegged on a per-sector basis.
MCTA MIXed Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or
MCTAHRQF), when NO frequency was successfully selected by MCTA because
some BTSs
timed-out while some responded with a resource full or not available response. It
is pegged on a per-sector basis.
MCTA ORIGination
04/22/02 Page 66
MCTORIGS
MCTA PaGe RESponse
MCTPGRES
MCTHCATT
target sector should begin
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.2.8. 3G Data Post-MCTA Traffic Distribution (per frequency)
This is the percentage of traffic carried on a particular frequency on a sector when
compared to the other frequencies on that sector.
Formula
Traf Dist% =
[Calls continued on the given freq / Total number of calls on all freqs] * 100
04/22/02 Page 67
Calls continued on the given frequency =

CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
Total number of calls on all freqs =
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
NOTE: CAUFRQ3D refers to the sum of the register for all frequencies on the
sector.
OMs
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
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 %
04/22/02 Page 68

It should match the 3G Voice Post-MCTA Traffic Distribution.
3.2.9. 3G Data Post-MCTA Call Success (per frequency)

This is the percentage of calls that successfully arrived on the traffic channel for a
particular frequency.
Formula
Succ% = [No. of successful calls / Total calls attempted] * 100
No. of successful calls =
CAUFRQ3D.MCTOSUCC +
CAUFRQ3D.MCTTSUCC +
CAUFRQ3D.MCTHSUCC
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
OMs
MCTOSUCC
MCTTSUCC
MCTHSUCC
MCTOATTS
04/22/02 Page 69

MCTTATTS
enabled.
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
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 been
selected and the call setup is attempted on the selected frequency.
Formula
Total Blocks% = [Total no. of calls blocked / Total calls attempted] * 100
Total no. of calls blocked =
04/22/02 Page 70
CAUFRQ3D.MCTERSFL
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
OMs
MCTA Error case Radio link Setup FaiLure
MCTERSFL
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever
a call setup fails due to the fact that the BTS could not allocate resources due to
any of the BTS failure reasons. This OM is also pegged when the BTS does not
respond at all to resource requests. MCTERSFL is pegged only after an MCTA
frequency is selected. MCTERSFL is pegged against the selected frequency.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
Day 1:
0.00 %
0.00 %
0.00 %
Day 2:
0.00 %
0.00 %
0.00 %
Day 3:
0.00 %
0.00 %
0.00 %
04/22/02 Page 71
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 MCTA
frequency has been selected and the call setup is attempted on the selected
frequency.
Formulas
TCE% = [CAUFRQ3D.MCTNOTCE /
(CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS)] * 100
WCD% = [CAUFRQ3D.MCTNOWCD /
CAUFRQ3D.MCTTATTS +
Frame Offset% = [CAUFRQ3D.MCTNOFOF /
CAUFRQ3D.MCTTATTS +
FWDCAP% = [CAUFRQ3D.MCTFWCAP /
CAUFRQ3D.MCTTATTS +
REVCAP% = [CAUFRQ3D.MCTRECAP /
CAUFRQ3D.MCTTATTS +
04/22/02 Page 72
OMs
MCTA NO Traffic Channel Element
MCTNOTCE
Pegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element
via NOIS messages, regardless of origination, termination or hard handoff.
MCTNOTCE is pegged only after an MCTA frequency is selected.
MCTNOTCE is pegged against the selected frequency.
MCTA NO Walsh Code
MCTNOWCD
Pegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS
messages, regardless of origination, termination or hard handoff. MCTNOWCD
is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged
MCTA NO Frame Offset
MCTNOFOF
Pegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to
some CSM 5000 hardware limitation. The CSM 5000 is limited in how much
traffic it can support on its reverse link because of the limitation on the number of
decoding units (both Viterbi and Turbo) that can be active on a frame offset (and
adjacent frame offsets). MCTNOFOF is pegged only after an MCTA
frequency is selected. MCTNOFOF is pegged against the selected frequency
MCTA ForWard CAPacity full
MCTFWCAP
Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via
NOIS messages, regardless of origination, termination or hard handoff.
MCTFWCAP is pegged only after an MCTA frequency is selected.
MCTFWCAP is pegged against the selected frequency.
MCTA REverse CAPacity full
MCTRECAP
Pegged, along with MCTERSFL and CAURECAP and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via
NOIS messages, regardless of origination, termination or hard handoff. However,
04/22/02 Page 73
currently there is no reliable mechanism for estimating reverse link capacity.

Consequently, this OM should never be pegged.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.2.11. 3G Data Post-MCTA Access Failures (per frequency)

This is the percentage of access failures after the MCTA frequency has been
selected and resources are successfully setup on the selected frequency.
04/22/02 Page 74
Formula
Acc Fails% = [Number of MCTA access failures / Total calls attempted] *
100
Number of MCTA access failures =
CAURFQ3D.MCTERLFL +
CAUFRQ3D.MCTHRLFL
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
OMs
MCTERLFL
are pegged.
MCTHRLFL
pegged.
MCTOATTS
MCTTATTS
enabled.
04/22/02 Page 75
MCTHATTS
Field Results:
Freq1
Freq2
Freq3
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 the
MCTA frequency has been selected and resources are successfully setup on the
selected frequency.
Formulas
Orig & Term% = [CAURFQ3D.MCTERLFL
/
CAUFRQ3D.MCTTATTS)] * 100
Handoff% = [CAURFQ3D.MCTHRLFL / CAUFRQ3D.MCTHATTS] *100
OMs
MCTERLFL
04/22/02 Page 76

are pegged.
MCTHRLFL
pegged.
MCTOATTS
MCTTATTS
enabled.
MCTHATTS
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 77

3.2.12. 3G Data Post-MCTA RF related Drop Calls (per frequency)
This is the percentage of established calls on each frequency in MCTA enabled
sectors that are dropped due to RF related issues.
Formula
Drop Call% = [Number of RF related drop calls / Number of successful calls]
* 100
Number of RF related drop calls =
CAUFRQ3D.MCTDROPR
CAUFRQ3D.MCTOSUCC +
CAUFRQ3D.MCTTSUCC +
CAUFRQ3D.MCTHSUCC
OMs
MCTA DROPped call Rf
MCTDROPR
Pegged, along with CAUDROPR, when a call is dropped by the SBS due to loss
of traffic or due to HCM (handoff completion message) timeout for soft or
softer handoff. These are RF-related call failures as detected by the SBS.
CAUDROPN
MCTOSUCC
MCTTSUCC
04/22/02 Page 78

MCTHSUCC
Field Results:
Freq1
Freq2
Freq3
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 L2TP
and PPP processing. L2TP is an Internet protocol defined in RFC 2661 that
provides a method of encapsulating PPP packets so that they can be transported
across an intervening IP network. This tunneling of PPP is transparent to endusers and applications. The purpose of the protocol is to allow the layer 2
endpoint and the PPP endpoint to be located on separate devices that are
connected by an IP network.
Packets are sent over the R-P Interface using either reliable or unreliable
transmission, the difference being that reliable packets are acknowledged, where
as unreliable are not. Reliable packets are used for establishment and control of
the L2TP tunnel and of the packet sessions established within that tunnel. The
bearer data packets that are sent during the session are sent using unreliable
transmission, the quality of service responsibility having been passed to upper
layer protocols (for example, TCP).
For 3G packet data calls, even after the SBS and BTS resources are successfully
setup for the call, and even after the mobile successfully arrives on the traffic
channel, the call can still fail (that is, no data transfer would take place) due to a
04/22/02 Page 79
failure to set up the R-P packet session or a failure to establish the RLP session.
The attempt to set up the R-P packet session is only done after the mobile arrives
on the traffic channel. The attempt to establish the RLP is only done after the R-P
packet session is successfully set up.
3.2.13.1. 3G Data R-P Interface Packet Session Successes
This Formula relates to the Packet Control Unit (PCU) Managed Object at the
BSC level. This is the percentage of R-P interface packet session setup successes
including both initial and reconnect setups.
Formula
% Setup Succ = [TotalSessionSetupSuccess
/
(TotalSessionSetupInitialAttempts
TotalSessionSetupReconnectAttempts)] * 100
OMs
TotalSessionSetupSuccess
Number of successful packet session setups, either by initial or reconnect attempts
TotalSessionSetupInitialAttempts
Number of packet session setups attempted during initial session setup.
TotalSessionSetupReconnectAttempts
Number of packet session setups attempted when reconnecting to an existing PPP
session
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 80
N/A
3.2.13.2. 3G Data R-P Interface Packet Session Failures
This Formula relates to the Packet Control Unit (PCU) Managed Object at the
BSC level. This is the percentage of R-P interface packet session setup failures
including both initial and reconnect setups.
Formula
% Setup Failures = [TotalSessionSetupFailures
/
(TotalSessionSetupInitialAttempts
TotalSessionSetupReconnectAttempts)] * 100
OMs
TotalSessionSetupFailures
Number of failed packet session setups.
TotalSessionSetupInitialAttempts
Number of packet session setups attempted during initial session setup.
TotalSessionSetupReconnectAttempts
Number of packet session setups attempted when reconnecting to an existing PPP
session
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 81
3.2.13.3. 3G Data R-P Interface Performance Formulas

These Formulas relates to the Packet Control Unit (PCU) Managed Object at the
BSC level.
Formulas:
Tunnel Failures =
NumberOfTunnelFailures
Unreliable Bytes Tx = (TotalUnreliableBytesTransmittedOverflow * 65535)

+
TotalUnreliableBytesTransmitted
Unreliable Bytes Rx = (TotalUnreliableBytesReceivedOverflow * 65535)
+
TotalUnreliableBytesReceived
Fwd Packets Dropped = TotalFwdPacketsDropped
Rev Packets Dropped = TotalRevPacketsDropped
DCR Overflow
= DCRBufferOverflows
RR Overflow
= RRBufferOverflows
StopTxMsgsSent
= DCR_NumOfStopTransmitMsgsSent
OMs
NumberOfTunnelFailures
Counts the number of times a L2TP tunnel was torn down due to failure of
reliable packet transmission per L2TP tunnel
TotalUnreliableBytesTransmitted
Counts the cumulative number of bytes each session in the PCU transmitted to
PDSN per L2TP tunnel
TotalUnreliableBytesTransmittedOverflow
Register allows values greater than 65535 for TotalUnreliableBytesTransmitted.
TotalUnreliableBytesReceived
Counts the cumulative number of bytes each session in the PCU received from
PDSN per L2TP tunnel
04/22/02 Page 82
TotalUnreliableBytesReceivedOverflow
Register allows values greater than 65535 for TotalUnreliableBytesReceived.
TotalFwdPacketsDropped
Number of PPP packets dropped in the forward direction per PCU
TotalRevPacketsDropped
Number of PPP packets dropped in the reverse direction per PCU
DCRBufferOverflows
Number of DCR buffer overflows per PCU
RRBufferOverflows
Number of RR buffer overflows
StopTxMsgsSent
Number of Stop Transmit messages sent from RLPQ per PCU
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.2.14. ESEL MO: 3G Data RLP Sessions
The Formulas and OMs discussed in this section relate to the EselectorCard
(ESEL) Managed Object at the BSC level.
For 3G packet data calls, even after the SBS and BTS resources are successfully
setup for the call, and even after the mobile successfully arrives on the traffic
channel, the call can still fail (that is, no data transfer would take place) due to a
failure to set up the R-P packet session or a failure to establish the RLP session.
04/22/02 Page 83
The attempt to set up the R-P packet session is only done after the mobile arrives
on the traffic channel. The attempt to establish the RLP is only done after the R-P
packet session is successfully set up.
3.2.14.1. 3G Data RLP Session Successes
The following formula gives us the percentage of RLP session setup successes.
Formula
RLP % Succ = [RLPSetupSuccesses / RLPSetupAttempts)] * 100
OMs
RLPSetupSuccesses
Number of successful RLP setups.
RLPSetupAttempts
Number of RLP setups attempted.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
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
04/22/02 Page 84
OMs
RLPSetupFailures
Number of failed RLP setups
RLPSetupAttempts
Number of RLP setups attempted.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.3. Performance Formulas for 3G Forward Supplemental

Channel Data (ESEL MO)
The OMs used in the following formulas are collected by the Enhanced Selector Card
(ESEL) Managed Object at the BSC level.
3.3.1. Forward Burst Setup Success
Formula
F-SCH Burst %Succ = [FwdBurstSetupSuccesses / FwdBurstSetupAttemps]
* 100
OMs
FwdBurstSetupSuccesses
Pegged when a forward data burst is successfully set up
FwdBurstSetupAttempts
04/22/02 Page 85
Pegged when a forward data burst needs to be set up

Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.3.2. Forward Burst Setup Failures
Formula
F-SCH Burst %Fail = [FwdBurstSetupFailures / FwdBurstSetupAttemps] *
100
OMs
FwdBurstSetupFailures
Pegged when a forward data burst could not be set up
FwdBurstSetupAttempts
Pegged when a forward data burst needs to be set up
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 86

N/A
3.3.3. Forward SCH Blocks
Formula
F-SCH %Blocks = [FSCHLinkSetupBlock / FSCHLinkSetupAttempts] * 100
OMs
FSCHLinkSetupBlock
Number of FSCH setup attempts that are blocked for lack of resources
FSCHLinkSetupAttempts
Number of forward supplemental channel (FSCH) setup attempts
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
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:
04/22/02 Page 87
F-SCH %Block NoWalshCode =

[FSCHNoWalshCode/ FSCHLinkSetupAttempts] * 100
Blocks due to lack of No Physical Resources:
F-SCH %Block NoPhysicalResources =
[FSCHNoPhyRes / FSCHLinkSetupAttempts] * 100
Blocks due to lack of No Frame Offset availability:
F-SCH %Block NoFrameOffset =
[FSCHNoFrameOffset / FSCHLinkSetupAttempts] * 100
Blocks due to CFDS Configuration:
F-SCH %Block CFDSConfig =
[FSCHCFDSRadioConfig / FSCHLinkSetupAttempts] * 100
OMs
FSCHNoFwdPower
Pegged if the FSCHBlock reason indicates a lack of available forward power
FSCHNoWalshCode
Pegged if the FSCHBlock reason indicates a lack of available Walsh codes
FSCHNoPhysRes
Pegged if the FSCHBlock reason indicates there are no available channel elements
FSCHNoFrameOffset
Pegged if the FSCHBlock reason indicates there is no available frame offset
FSCHCFDSRadioConfig
Pegged if the FSCHBlock reason indicates SCH burst functionality has not been
enabled through CFDS
Field Results
Day 1: example
Day 2: example
Day 3: example
04/22/02 Page 88
Day 4: example

N/A
3.3.4. Forward SCH Access Failures
Formula
F-SCH %Access Failures =
[FSCHRadioLinkAccessFailure / FSCHLinkSetupAttempts] * 100
OMs
FSCHRadioLinkAccessFailure
This OM is pegged in the event the resources for the FSCH are set up
successfully, but the mobile does not arrive on the FSCH. It is pegged against
each link in the SCH active set.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 89
3.3.5. Forward SCH Time Out

Formula
F-SCH %TimeOuts = [FSCHTimeout / FSCHLinkSetupAttempts] * 100
OMs
FSCHTimeout
Pegged if a response to the BTS resource request is never received.
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
OMs
FSCHLinkDowngrade
Number of FSCH setup attempts that are not granted the requested data rate due to
lack of resources, but are granted a lower data rate. Pegged against the primary
pilot in the SCH active set.
04/22/02 Page 90
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.4. Performance Formulas for 3G Reverse Supplemental

Channel Data (ESEL MO)
The OMs used in the following formulas are collected by the Enhanced Selector Card
(ESEL) Managed Object at the BSC level
3.4.1. Reverse Burst Setup Success
Formula
R-SCH Burst %Succ = [RevBurstSetupSuccesses / RevBurstSetupAttemps] *
100
OMs
RevBurstSetupSuccesses
Pegged when a Reverse data burst is successfully set up
RevBurstSetupAttempts
Pegged when a Reverse data burst needs to be set up
Field Results
04/22/02 Page 91
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.4.2. Reverse Burst Setup Failures
Formula
R-SCH Burst %Rail = [RevBurstSetupFailures / RevBurstSetupAttemps] *
100
OMs
RevBurstSetupFailures
Pegged when a Reverse data burst could not be set up
RevBurstSetupAttempts
Pegged when a Reverse data burst needs to be set up
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 92
3.4.3. Reverse SCH Blocks

Formula
R-SCH %Blocks = [RSCHLinkSetupBlock / RSCHLinkSetupAttempts] *
100
OMs
RSCHLinkSetupBlock
Number of RSCH setup attempts that are blocked for lack of resources
RSCHLinkSetupAttempts
Number of Reverse supplemental channel (RSCH) setup attempts
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
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:
04/22/02 Page 93
R-SCH %Block CFDSConfig =

[RSCHCFDSRadioConfig / RSCHLinkSetupAttempts] * 100
Blocks due to Reverse High Speed CFDS Configuration:
R-SCH %Block HighSpeedCFDSConfig =
[RSCHCFDSHighSpeed / RSCHLinkSetupAttempts] * 100
OMs
RSCHNoPhysRes
Pegged if the RSCHBlock reason indicates there are no available channel
elements
RSCHNoFrameOffset
Pegged if the RSCHBlock reason indicates there is no available frame offset
RSCHCFDSRadioConfig
Pegged if the RSCHBlock reason indicates SCH burst functionality has not been
RSCHCFDSHighSpeed
Pegged if the RSCHBlock reason indicates high speed RSCH has not been
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 94
3.4.4. Reverse SCH Access Failures

Formula
R-SCH %Access Failures =
[RSCHRadioLinkAccessFailure / RSCHLinkSetupAttempts] * 100
OMs
RSCHRadioLinkAccessFailure
This OM is pegged in the event the resources for the RSCH are set up
successfully, but the mobile does not arrive on the RSCH. It is pegged against
each link in the SCH active set.
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
OMs
RSCHTimeout
Pegged if a response to the BTS resource request is never received.
04/22/02 Page 95
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
OMs
RSCHLinkDowngrade
Number of RSCH setup attempts that are not granted the requested data rate due
to lack of resources, but are granted a lower data rate. Pegged against the primary
pilot in the SCH active set.
Field Results
Day 1: example
Day 2: example
04/22/02 Page 96
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 all
of the supported frequencies.
NOTE: indicates summing the pegs for the time period appropriate for the
report under discussion.
3.5.1.1. 3G FCH Originations
Formulas
3G call attempts downgraded to 2G

3G ->2G (Downgrade) = ADV_SEC[112]
= (FchOriginationNonBlocking3GDowngrade2G)
Voice Blocks
Non Blocking
= ADV_SEC[110]
= (FchOriginationNonBlocking3GVoice)
Block FCH No TCE
= ADV_SEC[119][0]
= (BlockedFchOriginations3GVoice)
(due to no physical resources)
Block FCH No WC
= ADV_SEC[119][3]
04/22/02 Page 97
(due to no Walsh code)

Block FCH No Fwd Power
= ADV_SEC[119][1]
(due to no forward power)
Block FCH No Frame Offset
= ADV_SEC[119][4]
(due to no frame offset)
Block CFDS Radio Config State = ADV_SEC[119][6]

(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]
= ADV_SEC[120][1]
= ADV_SEC[120][4]

Blocking Reasons
04/22/02 Page 98
No Physical Resources
In this case, the CCEMs and XCEMs in the sector could not support additional
calls. More CCEMs or XCEMs may be needed.
No Walsh Code
Blocking occurred because all Walsh codes had been allocated. This includes
scenarios where Walsh codes are regulated by MaxVoiceResources (or voice
calls) or MaxDataResources (for data calls). If this blocking reason is consistently
higher than No forward capacity, the system may be Walsh code limited. In that
case, the operator should consider setting RC4_Preferred to increase Walsh code
availability at the expense of forward power.
No Forward Capacity
The BTS forward power level surpassed the level defined by the call blocking
threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data
calls).
No Frame Offset
The XCEM supports a fixed number of calls per frame offset. This metric
corresponds to blocks that were a result of an XCEMs inability to support the
needed frame offset. This metric is not applicable to CCEMs.
No CFDS Radio Config State
Blocking occurred because the CFDS RadioConfigState attribute is configured in
such a way that does not allow the specific type of call requested to be setup.
Reconfiguration of this attribute may be needed.
OMs
FchOriginationNonBlocking3GVoice
Number of successful BTS resource allocations for 3G voice calls on the
fundamental channel. This is not an indication of successful call attempts. This
metric does not include non-reference pilot links setup for CASHO. 3G voice
links, other than the reference pilots link, setup for CASHO are pegged under
FchHandoffNonBlocking3GVoice.
BlockedFchOriginations3GVoice
04/22/02 Page 99
Array indicating the number of 3G voice call attempts blocked on the fundamental
channel. Each array element corresponds to a different blocking reason as
explained above.
FchOriginationNonBlocking3GData
Number of successful BTS resource allocations for 3G data calls on the
fundamental channel. This is not an indication of successful call attempts.
This metric does not include non-reference pilot links setup for CASHO. 3G data
links, other than the reference pilots link, setup for CASHO are pegged under
FchHandoffNonBlocking3GData.
BlockedFchOriginations3GData
Array indicating the number of 3G data sessions blocked on the fundamental
explained 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)
04/22/02 Page 100

Block FCH No WC
= ADV_SEC[121][3]
= ADV_SEC[121][1]
= ADV_SEC[121][4]

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]
= ADV_SEC[122][1]
= ADV_SEC[122][4]

04/22/02 Page 101
Blocking Reasons
No Walsh Code
No Forward Capacity
calls).
No Frame Offset
OMs
FchHandoffNonBlocking3GVoice
Number of successful BTS resource allocations for 3G voice handoffs on the
fundamental channel. Note that this is not an indication of successful handoffs.
BlockedFchHandoffs3GVoice
Array indicating the number of 3G voice handoffs blocked on the fundamental
explained above.
FchHandoffNonBlocking3GData
04/22/02 Page 102
Number of successful BTS resource allocations for 3G data handoffs on the

fundamental channel. Note that this is not an indication of successful handoffs.
BlockedFchHandoffs3GData
Array indicating the number of 3G data handoffs blocked on the fundamental
explained 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 of
sectors or for the whole system by simply replacing each OM below with the sum
of the same OM over all sectors in the cluster or in the whole system.
Formulas
Average number of FCH softer handoff links
The average number of softer handoff links for the FCH in any sector in particular
can be expressed by the following ratio:
(FrameCntFCH / CEFrameCntFCH)
Average number of FCH soft handoff links (no including softer)
The average number of soft handoff links for the FCH in any sector in particular
(CEFrameCntFCH / PrimaryFrameCntFCH)
Average number of FCH handoff links (including both soft and softer)
04/22/02 Page 103
The average number of all handoff links for the FCH in any sector in particular
(FrameCntFCH / PrimaryFrameCntFCH)
OMs
FrameCntFCH
Array indicating the total number of frames sent on the forward link for every user
on the fundamental channel. Each element in the array represents one radio
configuration from RC1 through RC5. The array begins with RC1.
CEFrameCntFCH
Equivalent to FrameCntFCH with each frame being divided by the number of
softer handoff links.
PrimaryFrameCntFCH
Equivalent to FrameCntFCH with each frame being divided by the product of the
number of softer handoff links and the number of soft handoff links.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.5.2. Advanced Sector 3G Supplemental Channel Formulas
The OMs used in the following formulas are pegged on a per-sector basis for all
of the supported frequencies.
NOTE: indicates summing the pegs for the time period appropriate for the
report under discussion.
04/22/02 Page 104
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]
Block SCH No Fwd Power
= ADV_SEC[123][1]
Block SCH No Frame Offset
= ADV_SEC[123][4]
Blocked Radio Config State
= ADV_SEC[123][6]
Screened
= ADV_SEC[123][7]
(due to CFDS HS RSCH)
Blocking Reasons
No Walsh Code
04/22/02 Page 105
No Forward Capacity
calls).
No Frame Offset
No CFDS HS RSCH
This element in the array is valid only for BlockedSchBursts and
BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature
attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH
bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).
Reconfiguration of this attribute may need to be considered.
OMs
SchBurstNonBlocking3G
Number of successful BTS resource allocations for 3G data bursts on the
supplemental channel. This is not an indication of successful data bursts.
BlockedSchBursts
Array indicating the number of 3G data bursts blocked on the supplemental
explained above.
Field Results
Day 1: example
Day 2: example
04/22/02 Page 106
Day 3: example
Day 4: example
N/A
3.5.2.2. 3G SCH Handoff Blocks
Formulas
Non Blocking
= ADV_SEC[116]
= (SchHandoffNonBlocking3G)
Block SCH No TCE
= ADV_SEC[124][0]
= (BlockedSchHandoffs)
Block SCH No WC
= ADV_SEC[124][3]
Block SCH No Fwd Power
= ADV_SEC[124][1]
Block SCH No Frame Offset
= ADV_SEC[124][4]
Blocked Radio Config State
= ADV_SEC[124][6]
Screened
= ADV_SEC[124][7]
(due to CFDS HS RSCH)
Blocking Reasons
04/22/02 Page 107
No Walsh Code
No Forward Capacity
calls).
No Frame Offset
No CFDS HS RSCH
This element in the array is valid only for BlockedSchBursts and
BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature
attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH
bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).
Reconfiguration of this attribute may need to be considered.
OMs
SchHandoffNonBlocking3G
Number of successful BTS resource allocations for 3G data handoffs on the
supplemental channel. Note that This is not an indication of successful handoffs.
BlockedSchHandoffs
Array indicating the number of 3G data handoffs blocked on the supplemental
explained above.
04/22/02 Page 108
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 of
sectors or for the whole system by simply replacing each OM below with the sum
of the same OM over all sectors in the cluster or in the whole system.
Formulas
Average number of SCH softer handoff links
The average number of softer handoff links for the SCH in any sector in particular
(FrameCntSCH / CEFrameCntSCH)
Average number of SCH soft handoff links (no including softer)
The average number of soft handoff links for the SCH in any sector in particular
(CEFrameCntSCH / PrimaryFrameCntSCH)
Average number of SCH handoff links (including both soft and softer)
The average number of all handoff links for the SCH in any sector in particular
(FrameCntSCH / PrimaryFrameCntSCH)
OMs
FrameCntSCH
04/22/02 Page 109
Array indicating the total number of forward frames for every user on the
supplemental channel. Each element in the array represents one radio
configuration from RC3 through RC5. The array begins with RC3.
CEFrameCntSCH
Equivalent to FrameCntSCH with each frame being divided by the number of
softer handoff links.
PrimaryFrameCntSCH
Equivalent to FrameCntSCH with each frame being divided by the product of the
number of softer handoff links and the number of soft handoff links.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
3.5.3. Advanced Frequency Assignment (FA) Managed Object

Formulas
Advanced Frequency Assignment (FA) formulas deal with the status of XCEM
resources on the fundamental as well as the supplemental channels.
Formulas
Forward Total
= ADV_FA[72]
Total ForwardPhysicalResources
Max SCH Forward
= ADV_FA[74]
SchMaximumForwardPhysicalResourcesUsed
04/22/02 Page 110
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
OMs
Total ForwardPhysicalResources
The number of 3G XCEM resources provisioned for the BTSs forward link. This
excludes all CCEM resources and faulty XCEM resources. This OM is a snapshot
taken at the time of reporting. It does not represent how many resources are
actually in use.
SchMaximumForwardPhysicalResourcesUsed
This OM is a high water mark for the number of XCEM resources being used for
the forward supplemental channel at any time during the reporting period.
Fch3GMaximumForwardPhysicalResourcesUsed
This OM is a high water mark for the number of XCEM resources being used for
3G calls on the forward fundamental channel at any time during the reporting
period.
TotalReversePhysicalResources
The number of 3G XCEM resources provisioned for the BTSs reverse link. This
excludes all CCEM resources and faulty XCEM resources. This OM is a snapshot
taken at the time of reporting. It does not represent how many resources are
actually in use.
TCEUtilMaximum
The peak number of channel elements in use, simultaneously, during a given time.
NumOfTCAvailable
Total number of channel elements available for traffic across all channel cards
after overhead channels have been subtracted
04/22/02 Page 111
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example

N/A
04/22/02 Page 112
4. Field Results Analysis

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

The percentage of access failures is expressed by the following relation:
The number of access failures is calculated by adding the following OMs counts:
CAUERLFL + CAUHRLFL
Please note that for 3G Packet data calls, the attempt to set up the R-P packet session is done
after the mobile arrives on the traffic channel but before sending the service connect
message out to the mobile. Thus if the R-P packet session setup fails, it will still be pegged
as an access failure. The TotalSessionSetupFailures count can be subtracted from the
above sum when measuring the RF Access Failure rate on a system wide basis.
04/22/02 Page 113
Attempts
%_AF
4/
14
/0
13
/0
4/
12
/0
2
4/
4/
11
/0
10
/0
02
4/
9/
4/
8/
4/
10
9
8
7
6
5
4
3
2
1
0
2
20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
02
Number of attempts
Figure 4-1A: 3G Voice Access Failures Percentage
Date
Figure 4-1B: 3G Data Access Failures Percentage
Number of Attempts
1400
10
9
8
7
6
5
4
3
2
1
0
1200
1000
800
600
400
200
%_AF
4/
14
/0
2
13
/0
4/
4/
12
/0
2
4/
11
/0
2
10
/0
4/
02
9/
4/
4/
8/
02
Attempts
Data
Figures 4-1A and 4-1B above show 3G voice and 3G data access failures percentages
respectively. This data is collected from test calls performed in the Kansas City market,
specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the
access failure rate is much higher in the case of 3G data calls. However, this high failure
rate does not reflect a typical network behavior because: 1) the number of attempts is
significantly less for the data calls as compared to the voice call attempts. 2) Approximately
90% of data calls were attempted from only two sectors out of a total of about 90 sectors.
04/22/02 Page 114
For a more detailed analysis, we can break this information down into specific areas, as
follows:
4.1.1. Access failures during originations and terminations:
(CAUERLFL)
A higher count on this peg reflects that the number of access failures taking place
during originations or terminations is high.

The next step would be go to the MCTA report and figure out which carrier(s) is
experiencing access failures. To do this, we will check the count for MCTERLFL
for all carriers, and identify the carrier(s) that has high number of access failures.
NOTE: It is possible that more than one carrier is facing high access failure rate.
Recommendations:
The information available under this OM does not help us significantly to pin
point the problem. The best option for such failure is to send a drive test team out
to try to duplicate failed origination/termination attempts, and analyze the drive
test data to identify the problem. Also, cell trouble logs can be printed in
conjunction with the drive test results to provide information about the mobile
whose call attempt was unsuccessful. The following can be a reason for this
count:
The Mobile cannot hear the BTS acknowledgment, chances are that the Ec/Io is
low.
1.
2.
3.
Low Ec/Io could be because of:

Poor coverage, received signal strength is low.
Pilot pollution, many available pilots with no dominant server.
Fading problem, if the Ec/Io dropped down for a very short period of time
and then came back.
4. Hardware faults, such failures are mostly on a per sector basis.
5. RF environment changes, such as addition of new sites in the area.
4.1.2. Access failures during hard handoffs: (CAUHRLFL)

A higher count on this peg reflects that the number of access failures taking place
during hard handoffs is high.

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

10
9
8
7
6
5
4
3
2
1
0
Number of Attempts
1400
1200
1000
800
600
400
200
%_T_BLK
14
/0
4/
4/
13
/0
2
12
/0
4/
4/
11
/0
2
10
/0
4/
4/
9/
02
4/
8/
02
Attempts
Date
04/22/02 Page 116
Figures 4-2A and 4-2B above show 3G voice and 3G data total blocks percentages
specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the
blocking rate is relatively higher in the case of 3G data calls. However, this high failure rate
does not reflect a typical network behavior because: 1) the number of attempts is
The total number of call blocks or call setup failures is calculated by adding the following
OMs counts:
CAUOBLKS + CAUTBLKS + CAUHBLKS
follows:
4.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE)
A higher count on this peg reflects that blocking due to lack of BTS channel
elements (TCEs) on a particular sector is high.

The next step would be go to the MCTA report and figure out which carrier(s) on
this sector is running out of TCEs. To do this, we will check the count for
MCTNOTCE for all carriers, and identify the carrier(s) that is lacking channel
elements. NOTE: It is possible that more than one carrier is facing the channel
elements limitation.
Verify the TCE limitation by comparing the number of TCEs in use with the total
number of TCEs provisioned for this carrier(s) at the BTS.
Recommendations:
Provision additional TCE at the BTS. More TCEs can be added as required until
the available power is exhausted.

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

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

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

A higher count on this peg reflects that the sector is running out of capacity on the
reverse link.
this sector is running out of reverse capacity. To do this, we will check the count
for MCTRECAP for all carriers, and identify the carrier(s) that is lacking reverse
capacity. NOTE: It is possible that more than one carrier is facing the reverse
capacity limitation.
Recommendations:
A drive test would be required to analyze blocks that are possibly resulting due to
the reverse link capacity.
04/22/02 Page 118
4.2.5. Blocking due to lack of physical resources:

This type of blocks is given by the sum of following two OMs:
RMNORREQ
A higher count on this peg reflects that the Resource Manager (RM) has no
available resources to allocate for a call.
Recommendations:
These are network-related call setup failures. They result due to SBS shortage
problem. Typically, more SBS selector elements are needed to be provisioned in
such cases. It is also possible that one or more selector elements are out-of-service.
In either case, an investigation should be done in coordination with switch/network
team to pin point the problem.
CAUERSFL
A higher count on this peg reflects that some BTS resource is not available. This
OM is also pegged if any of the software entities on the BTS do not respond to
resource requests during call setup
Recommendations:
Depending on which resource is not available at the BTS, the following
information might be of help:

1.
2.
3.
4.
5.
6.
No channel elements (CAUNOTCE): refer section 4.1.1

No Walsh codes (CAUNOWCD): refer section 4.1.2
No forward capacity (CAUFWCAP): refer section 4.1.3
No reverse capacity (CAURECAP): refer section 4.1.4
BTS does not respond at all.
Failed to select a carrier: This reflects no available capacity on any of the
carriers. In this case, the failure reasons are pegged by MCTAMIXF,
MCTALLTO or MCTALLFU.
Addition of a new carrier is recommended for such failures.
4.2.6. Blocking due to no frame offset availability: (CAUNOFOF)

A higher count on this peg reflects that no frame offset is available at the given
sector.
this sector has no frame offset availability. To do this, we will check the count for
04/22/02 Page 119
MCTNOFOF for all carriers, and identify the carrier(s) that has no frame offset
availability. NOTE: It is possible that more than one carrier is facing the frame
offset availability limitation.
Recommendations:
This type of failures reflects software or hardware limitations; and are not because
of RF-related failures.
4.2.7. Blocking due to BTS time-outs:
Blocking resulting due to BTS time-outs is given by the following relation:
= [Blocking due to (Radio link setup error
No channel elements
No Walsh codes
No forward capacity
No reverse capacity
No frame offset availability
No frequency selected for origination or termination
No frequency selected for hard handoff)
/
Total calls attempted] * 100
Recommendations:
These are hardware/software related problems, reasons to be investigated.
4.2.8. Blocking due to BSC time-outs and software faults:
This type of blocks is given by the sum of following OMs:
RMSRMTO -
RM SRM Time-Out
RMSRMNAK - RM Service Resource Manager Negative AcK
CAUESWFL - CAU Error case, SoftWare FauLt
Recommendations:
These are hardware/software related problems, reasons to be investigated.
04/22/02 Page 120
4.3. Drops
The percentage of total drops is expressed by the following relation:
Attempts
14
/0
2
%_Drop
4/
13
/0
2
4/
4/
12
/0
2
11
/0
2
4/
4/
4/
9/
0
4/
8/
0
10
/0
2
10
9
8
7
6
5
4
3
2
1
0
2
20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
2
Number of Attempts
Figure 4-3A: 3G Voice Call Drops Percentage
Date
Figure 4-3B: 3G Data Call Drops Percentage
Number of Attempts
1400
10
9
8
7
6
5
4
3
2
1
0
1200
1000
800
600
400
200
14
/0
2
%_Drop
4/
13
/0
2
4/
12
/0
2
4/
11
/0
2
4/
10
/0
2
4/
4/
9/
0
4/
8/
0
Attempts
Date
Figures 4-3A and 4-3B above show 3G voice and 3G data call drops percentages
specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the call
drop rate is relatively higher in the case of 3G data calls. However, this high failure rate
does not reflect a typical network behavior because: 1) the number of attempts is
04/22/02 Page 121
The total number of call drops is calculated by adding the following OMs counts:
CAUDROPR + CAUDROPN
follows:
4.3.1. Drops due to RF-related reasons: (CAUDROPR)
A higher count on this peg reflects that the number of calls dropped due to loss of
traffic or due to HCM (handoff completion message) timeout on a particular

sector is high.
this sector is dropping calls. To do this, we will check the count for MCTDROPR
for all carriers, and identify the carrier(s) that is facing a high number of drop calls
due to RF-related reasons. NOTE: It is possible that more than one carrier is
experiencing such drops.
Recommendations:
As mentioned above this count includes failures resulting during soft and softer
handoffs as well. Therefore, the first step is to identify the exact reason for this
count. This task can be accomplished by organizing a drive test to capture these
drops, and then analyze the layer 3 messages.
The main reason for RF-related drop calls is higher values of FER, i.e., when the
FER is above the threshold. Factors contributing in bringing the FER high
include high noise, weak signal, pilot pollution. In some cases, intermittent
hardware problems have also resulted in such drops. Drops occurring due to poor
coverage conditions would require additional sites. For handoff related drops, it is
important to verify that all the neighbor lists are correct.
4.3.2. Drops due to network-related reasons: (CAUDROPN)

A higher count on this peg reflects that the number of calls dropped due to any
other, non-RF, reason on a particular sector is high.

this sector is dropping calls. To do this, we will check the count for MCTDROPN
for all carriers, and identify the carrier(s) that is facing a high number of drop calls
04/22/02 Page 122
due to non RF-related reasons. NOTE: It is possible that more than one carrier is
experiencing such drops.
Recommendations:
These are not RF-related failures.
04/22/02 Page 123
5. New Operational Measurements in 3G 1xRTT

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

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

OM Full Name
CAU PaGe
RESponse
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAUPGRES For mobile-terminated calls, attempts are recorded MSC V+D perin CAUPGRES, which indicates that a page
sector
response was received from a CDMA sector in
basis
response to a page request (irrespective of whether
it was in response to an initial page request or a retry
by the CM).
CAU Termination CAUTSUCC Pegged when a mobile-terminated call successfully

SUCCess
MSC V+D persector

basis
CAU Termination CAUTBLKS Pegged any time a mobile-terminated call setup fails MSC V+D perBLocKS
due to resource shortage. It represents all of the
sector
termination setup failures in a sector, regardless of
basis
resource. One or more of the following call setup
failure reasons is pegged in conjunction with
CAUTBLKS: RMNORREQ, RMSRMNAK,
RMSRMTO, CAUERSFL, CAUNOTCE,
CAUNOWCD, CAUNOFOF, CAUFWCAP,
CAURECAP and CAUESWFL.
CAU Error case,
Dropped due to
Loss Of Traffic
CAUEDLOT Pegged when the mobile drops off the traffic channel MSC V+D perafter the Radio Link Setup Rsp message is
sector
received but before the Service Connect Rsp
basis
message is received. This scenario is considered an
access failure. The register CAUERLFL is also
pegged in conjunction with this register.
CAU Termination CAUTRLS

ReLeaSed
Pegged when a mobile-terminated call is released

before the mobile arrives on the traffic channel. It
should be noted that this OM will only get pegged if
the originating party disconnects between the time
that the terminating mobiles page response has
been received by the CM and before the mobile
actually arrives on the traffic channel.
MSC V+D persector

basis
04/22/02 Page 124

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAU Origination
ATTemptS
CAUOATTS Pegged when the CAU receives an origination

message from the BTS. Test call originations are
pegged in a separate OM.
MSC V+D persector

basis
CAU Origination
SUCCess
CAUOSUCC Pegged when a mobile-originated call successfully

arrives on the traffic channel. This includes all
originations placed on the traffic channel to receive
treatment.
MSC V+D persector

basis
CAU Origination
BLocKS
CAUOBLKS Pegged any time a mobile-originated call setup fails MSC V+D perdue to resource shortage. It represents the total
sector
number of origination setup failures in a sector,
basis
regardless of resource. The same failure reasons
that are pegged for CAUTBLKS can be pegged in
conjunction with CAUOBLKS.
CAU Origination
ReOrDeR
CAUORODR The CM can send reorder commands to the mobile MSC V+D peroriginators whose calls will not be set up. These
sector
situations can occur by datafilling a treatment with
basis
the MOBRODR or MOBICPT CLLI instead of an
announcement or tone CLLI in table TMTCNTL.
CAUORODR is pegged when the CAU receives a
reorder or intercept message from the CM indicating
that the origination is intentionally stopped without
putting the mobile on the traffic channel.
CAU Origination
ReLeaSed
CAUORLS
CAU Error case,

Radio Setup
FaiLure
CAUERSFL Pegged, along with the appropriate CAU*BLKS OM, MSC V+D perwhenever a call setup fails due to the fact that some
sector
BTS resource is not available. This OM is also
basis
pegged when the BTS does not respond to resource
requests. It is also pegged when the Carrier
Determination Algorithm (CDA) fails to select a
carrier in an MCTA enabled sector (that is, no
available capacity on all co-located carriers).
CAU Error Radio CAUERLFL

Link FaiLure
Pegged when a mobile-originated call is released by MSC V+D perthe mobile station or the CM before the mobile
sector
sends a service completion message.
basis
Pegged if the origination or termination fails because MSC V+D perthe mobile never arrived on the traffic channel
sector
(similar to SAT timeout). CAUERLFL is not pegged
basis
in cases where the CAUOBLKS or CAUTBLKS OMs
are pegged.
SLoTted mode
SLTPGRES This OM is the equivalent of CAUPGRES, except
PaGe RESponse
that it is pegged by the CAU only in response to a
slotted mode page request. Slotted mode paging is
measured separately so that performance
differences can be determined. SLTPGRES is a
subset of the CAUPGRES.
MSC V+D persector

basis
04/22/02 Page 125

OM Full Name
CAU hard
Handoff
ATTemptS
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAUHATTS Pegged when the CAU receives a ReadyNewCell

MSC V+D permessage from the CM, indicating that a hard handoff
sector
attempt sequence in a (CDMA) target sector should
basis
begin.
CAU hard
CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff
MSC V+D perHandoff BLocKS
setup fails due to resource shortage. It represents all
sector
of the hard handoff setup failures into a sector,
basis
regardless of resource. This OM is pegged for both
inter- and intra-system hard handoff attempts.
CAUHBLKS is not the number of dropped hard
handoffs, it merely represents the number of times
that a hard handoff could not be completed due to
resource shortages in the target cell/sectorthe call
in the source cell is still up. The same failure
reasons that are pegged for CAUOBLKS (see
previous page) can be pegged in conjunction with
CAUHBLKS.
CAU hard
Handoff
SUCCess
CAUHSUCC Pegged when a mobile, attempting a hard handoff,

successfully arrives on the traffic channel in the
target sector.
MSC V+D persector

basis
CAU hard
Handoff
ReLeaSed
CAUHRLS
CAU hard
Handoff Radio
Link FaiLure
CAUHRLFL Pegged if the hard handoff attempt fails because the MSC V+D permobile never arrived on the target sectors traffic
sector
channel (similar to SAT timeout). CAUHRLFL
basis
Pegged when a call setup in a target cell is released MSC V+D perby the source system before the mobile arrives on
sector
the traffic channel.
basis
is not pegged in cases where CAUHBLKS is

pegged.
CAU DROPped
call Rf
CAUDROPR Pegged by the CAU against the reference pilot when MSC V+D pera call is dropped by the SBS due to loss of traffic or
sector
due to HCM (handoff completion message) timeout
basis
for soft or softer handoff. These are RF-related call
failures as detected by the SBS.
CAU DROPped
call Network
CAUDROPN Pegged by the CAU when any of the other (non-RF) MSC V+D perdrop indication reasons are sent from the SBS in the
sector
radio link drop indication message.
basis
CAU Error case,

SoftWare FauLt
CAUESWFL Pegged, along with the appropriate CAU*BLKS OM, MSC V+D perwhenever a call setup fails due to time outs between
sector
software entities that should not occur (for example,
basis
no response from the CM, failure message received
from SBS, etc.).
CAU NO Traffic CAUNOTCE Pegged, along with CAUERSFL and the appropriate MSC V+D perChannel Element
CAU*BLKS OM, any time a BTS reports no traffic
sector
channel element via NOIS messages, regardless of
basis
04/22/02 Page 126

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAU NO Walsh
Code
CAUNOWC Pegged, along with CAUERSFL and the appropriate MSC V+D perD
CAU*BLKS OM, any time a BTS reports no walsh
sector
code via NOIS messages, regardless of origination,
basis
CAU NO Frame
OFfset
CAUNOFOF Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS cannot allocate
sector
resources due to some CSM 5000 hardware
basis
limitation. The CSM 5000 is limited in how much
traffic it can support on its reverse link because of
the limitation on the number of decoding units (both
Viterbi and Turbo) that can be active on a frame
offset (and adjacent frame offsets).
CAU ForWard
CAPacity full
CAUFWCAP Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS reports forward
sector
capacity full via NOIS messages, regardless of
basis
CAU REverse
CAPacity full
CAURECAP Pegged, along with CAUERSFL and the appropriate MSC V+D perCAU*BLKS OM, any time a BTS reports reverse
sector
capacity full via NOIS messages, regardless of
basis
origination, termination or hard handoff. However,
currently there is no reliable mechanism for
estimating reverse link capacity and so this response
is disabled on the BTS. Consequently, this OM is
never pegged.
MCTA Handoff
ReQuest Failure
MCTAHRQF Pegged, along with CAUERSFL, when NO

MSC V+D perfrequency was successfully selected by MCTA for a
sector
hard handoff call setup. It is pegged on a per-sector
basis
basis on the target side. The failure reasons are
pegged by MCTAMIXF, MCTALLTO or MCTALLFU.
MCTA REQuest
Failure
MCTAREQF Pegged, along with CAUERSFL, when NO

MSC V+D perfrequency was successfully selected by MCTA for
sector
origination or termination call setup. It is pegged on
basis
a per-sector basis. The failure reasons are pegged
by MCTAMIXF, MCTALLTO or MCTALLFU.
MCTA All
frequencies FUll
MCTALLFU Pegged, along with CAUERSFL and (MCTAREQF MSC V+D peror MCTAHRQF), when NO frequency was
sector
successfully selected by MCTA because none of the
basis
BTSs had resources available. It is pegged on a persector basis.
04/22/02 Page 127

OM Full Name
MCTA ALL
frequencies
Timed-Out
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
MCTALLTO Pegged, along with CAUERSFL and (MCTAREQF MSC V+D peror MCTAHRQF), when NO frequency was
sector
successfully selected by MCTA because none of the
basis
BTSs responded to the capacity request query. It is
pegged on a per-sector basis.
MCTA MIXed
Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN

and (MCTAREQF or MCTAHRQF), when NO
frequency was successfully selected by MCTA
because some BTSs timed-out while some
responded with a resource full or not available
response. It is pegged on a per-sector basis.
MSC V+D persector

basis
5.2. OM Groups: CAURFQ3V, CAUFRQ3D

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

OM Full Name
MCTA
ORIGination
OM Register
(Name)
Description
MCTORIGS Pegged, along with CAUOATTS, when the CAU

receives an origination message from a sector that
has MCTA enabled. It is pegged against the
originating frequency. Test call originations are
pegged in a separate OM.
MSC
/ BSC V/D Basis
/ BTS
MSC V+D perfreq
basis
MCTA Origination MCTOATTS Pegged when an MCTA frequency is successfully

MSC V+D perATTemptS
selected by the Carrier Determination Algorithm
freq
(CDA) for a mobile origination in a sector with MCTA
basis
enabled. Please note that the MCTA frequency for
MCTOATTS may be different from the MCTA
frequency on which the call originated (MCTORIGS).
MCTA Origination MCTOSUCC Pegged, along with CAUOSUCC, when a mobileMSC V+D perSUCCess
originated call successfully arrives on the traffic
freq
channel. This includes all originations placed on the
basis
traffic channel to receive treatment.
04/22/02 Page 128

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
MCTA PaGe
RESponse
MCTPGRES For mobile-terminated calls, attempts are recorded MSC V+D perin MCTPGRES, which indicates that a page
freq
response was received from an MCTA enabled
basis
CDMA sector in response to a page request. This
OM is pegged irrespective of whether it was the first
or the second attempt to page the mobile.
CAUPGRES is also pegged whenever MCTPGRES
is pegged.
MCTA
Termination
ATTemptS
MCTTATTS Pegged when an MCTA frequency is successfully

selected by the Carrier Determination Algorithm
(CDA) for a mobile termination in a sector with
MCTA enabled.
MSC V+D perfreq

basis
MCTA
Termination
SUCCess
MCTTSUCC Pegged, along with CAUTSUCC, when a mobileterminated call successfully arrives on the traffic
channel.
MSC V+D perfreq

basis
MCTA Handoff
Call ATTempts
MCTHCATT Pegged, along with CAUHATTS, when the CAU

MSC V+D perreceives a message from the CM, indicating that a
freq
hard handoff attempt sequence in an MCTA enabled
basis
CDMA target sector should begin.
MCTA Handoff
ATTemptS
MCTHATTS Pegged when an MCTA frequency is successfully

MSC V+D perselected by the Carrier Determination Algorithm
freq
(CDA) for a mobile hard handoff attempt into a target
basis
MCTA Hardhandoff
SUCCess
MCTHSUCC Pegged, along with CAUHSUCC, when a mobile

successfully arrives on the traffic channel after a
hard handoff.
MSC V+D perfreq

basis
MCTA Handoff
Radio Link
FaiLure
MCTHRLFL Pegged, along with CAUHRLFL, if the hard handoff

attempt fails because the mobile never arrived on
the target sectors traffic channel (similar to
MSC V+D perfreq

basis
SAT timeout). MCTHRLFL is not pegged in cases

where the CAUHBLKS OM is pegged.
MCTA Error case MCTERSFL Pegged, along with CAUERSFL and the appropriate MSC V+D perRadio link Setup
CAU*BLKS OM, whenever a call setup fails due to
freq
FaiLure
the fact that the BTS could not allocate
basis
resources due to any of the BTS failure reasons.
This OM is also pegged when the BTS does not
respond at all to resource requests. MCTERSFL is
pegged only after an MCTA frequency is selected.
MCTERSFL is pegged against the selected
frequency.
04/22/02 Page 129

OM Full Name
OM Register
(Name)
Description
MCTA NO Traffic MCTNOTCE Pegged, along with MCTERSFL and CAUNOTCE

Channel Element
and CAUERSFL and the appropriate CAU*BLKS
OM, any time a BTS reports no traffic channel
element via NOIS messages, regardless of
MCTNOTCE is pegged only after an MCTA
frequency is selected. MCTNOTCE is pegged
MSC
/ BSC V/D Basis
/ BTS
MSC V+D perfreq
basis
MCTA NO Walsh MCTNOWC Pegged, along with MCTERSFL and CAUNOWCD MSC V+D perCode
D
freq
OM, any time a BTS reports no walsh code via NOIS
basis
messages, regardless of origination, termination or
hard handoff. MCTNOWCD is pegged only after an
MCTA frequency is selected.
MCTNOWCD is pegged against the selected
frequency.
MCTA NO Frame MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOF
MSC V+D perOFfset
freq
OM, any time a BTS cannot allocate resources due
basis
to some CSM 5000 hardware limitation. The CSM
5000 is limited in how much traffic it can support on
its reverse link because of the limitation on the
number of decoding units (both Viterbi and Turbo)
that can be active on a frame offset (and adjacent
frame offsets). MCTNOFOF is pegged only after an
MCTA frequency is selected. MCTNOFOF is pegged
against the selected frequency
MCTA ForWard
CAPacity full
MCTFWCAP Pegged, along with MCTERSFL and CAUFWCAP

MSC V+D perand CAUERSFL and the appropriate CAU*BLKS
freq
OM, any time a BTS reports forward capacity full via
basis
NOIS messages, regardless of origination,
termination or hard handoff. MCTFWCAP is pegged
only after an MCTA frequency is selected.
MCTFWCAP is pegged against the selected
frequency.
MCTA REverse
CAPacity full
MCTRECAP Pegged, along with MCTERSFL and CAURECAP

MSC V+D perand CAUERSFL and the appropriate CAU*BLKS
freq
OM, any time a BTS reports reverse capacity full via
basis
NOIS messages, regardless of origination,
termination or hard handoff. However, currently
there is no reliable mechanism for estimating
reverse link capacity. Consequently, this OM should
never be pegged.
04/22/02 Page 130

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
MCTA Error
MCTERLFL Pegged, along with CAUERLFL, if the origination or MSC V+D percase, Radio Link
termination fails because the mobile never arrived
freq
FaiLure
on the traffic channel (similar to SAT timeout).
basis
MCTERLFL is not pegged in cases where the
CAUOBLKS or CAUTBLKS OMs are pegged.
MCTA REQuest
Timeout
MCTAREQT pegged when a frequency was successfully selected MSC V+D perby MCTA but one or more of the BTSs never
freq
responded to a capacity request. MCTAREQT is
basis
pegged against the carrier(s) that did not respond to
the capacity request. MCTAREQT may not always
be pegged under low traffic load conditions.
MCTA REQuest
response full or
Not available
MCTAREQN Pegged when a frequency was successfully selected MSC V+D perby MCTA but one or more of the BTSs responded
freq
with a resource full or not available response.
basis
MCTAREQN is pegged against the carrier(s) that
respond with a resource full or not available
response. MCTAREQN may not always be pegged
under low load conditions.
MCTA ReQuest
response Failed
(full or Not
available)
MCTARQFN Pegged, along with CAUERSFL and MCTAMIXF

and (MCTAREQF or MCTAHRQF), when no
frequency was successfully selected by MCTA
because some BTSs timed out, while some
responded with a resource full or not available
response. MCTARQFN is pegged against the
carrier(s) that respond with a resource full or not
available response.
MSC V+D perfreq

basis
MCTA DROPped MCTDROPR Pegged, along with CAUDROPR, when a call is

MSC V+D perRadio link
dropped by the SBS due to loss of traffic or due to
freq
HCM (handoff completion message) timeout for
basis
soft or softer handoff. These are RF-related call
failures as detected by the SBS.
5.3. OM Group: CAUDAT3G

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

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
04/22/02 Page 131
Short Data burst

PCU LooKup
Requests
SDPCULKR Pegged when the CAU receives a Short Data Burst MSC D
message from the mobile in a dormant data call.
SDB is being considered for future release, and thus
this register will not get pegged in the initial release
of 1XRTT.
persector
basis
Short Data burst

PCU LooKup
Failures
SDPCULKF Pegged when the CAU does not get the address of MSC D
the PCU to forward the SDB message (this is due to
a PCU address lookup failure at the MU). SDB is
being considered for future release, and thus this
register will not get pegged in the initial release of
1XRTT.
persector
basis
5.4. OM Group: RMU3G (RMU OMs for 3G calls)
Table 5-4: OM Group: RMU3G

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Request for 3G
Voice call
REQ3GV
Pegged when there is an attempt made by RMU to MSC V+D perallocate resources for a 3G Voice call attempt based
RMU
on a resource request from CAU.
basis
SUCcess for 3G
Voice call
SUC3GV
Pegged when the RMU successfully allocates

resources for a 3G Voice call based on a resource
request from CAU.
MSC V+D perRMU

basis
NO ReSource for NORS3GV

3G Voice call
Pegged when the RMU fails to allocate resources for MSC V+D pera 3G Voice call based on a resource request from
RMU
CAU.
basis
Request for 153K REQ153K

data rate data-call
Pegged when there is an attempt made by RMU to

allocate resources for a 153K data rate data-call
attempt based on a resource request from CAU.
MSC V+D perRMU

basis
SUCcess for
153K data rate
data-call

resources for a 153K data rate data-call attempt
based on a resource request from CAU.
MSC V+D perRMU

basis
SUC153K
NO ReSource for NORS153K

153K data rate
data-call
Pegged when the RMU fails to allocate resources for MSC V+D pera 153K data rate data-call attempt based on a
RMU
resource request from CAU.
basis

data rate data-call
Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 76K data rate data-call
RMU
basis
Note that rate data-call attempt based on a resource
request from CAU. Note that REQ76K counts
include downgraded attempts from 153K to 76K due
to no resources available for the 153K attempts. The
downgraded attempts (from 153K to 76K) count is
equal to NORS153K.
04/22/02 Page 132
Table 5-4: OM Group: RMU3G

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
SUCcess for 76K SUC76K

data rate data-call

based on a resource request from CAU.
MSC V+D perRMU

basis

76K data rate
data-call
RMU
resource request from CAU.
basis

data rate data-call
RMU
basis
Note that internally, the RMU does not make a
distinction between the 38K and the 76K data rates,
and therefore a 76K data rate call attempt can never
be downgraded to a 38K data rate call attempt. Thus
REQ38K counts do not include any downgraded
attempts from a higher data rate to 38K data rate.

data rate data-call

based on a resource request from the CAU.

38K data rate
data-call
RMU
resource request from the CAU.
basis

data rate data-call
RMU
attempt based on a resource request from the CAU.
basis
Note that REQ19K counts include downgraded
attempts from 76K to 19K and downgraded attempts
from 38K to 19K due to no resources available for
the 76K and 38K data rates attempts. The
downgraded attempts (from 76K to 19K) count is
equal to NORS76K and the downgraded attempts
(from 38K to 19K) count is equal to NORS38K.

data rate data-call

based on a resource request from the CAU.

19K data rate
data-call
RMU
resource request from the CAU.
basis
MSC V+D perRMU

basis
MSC V+D perRMU

basis
5.5. OM Group: CDMAPDOM (CDMA Packet Data)
Table 5-5: OM Group: CDMAPDOM
04/22/02 Page 133
OM Full Name
OM Register
(Name)
Mobile-Initiated
MIDTOAAT
Dormant To
Active ATtempts
Description
Pegged when the MSC receives an origination
message from a mobile which is in a dormant data
call state.
MSC
/ BSC V/D Basis
/ BTS
MSC D
syste
mwide
basis
Mobile-Initiated
Dormant To
Active SUccess
MIDTOASU Pegged when the mobile-initiated dormant to active MSC D

transition is successful mobile arrives on the traffic
channel.
syste
mwide
basis
Mobile-Initiated
Dormant To
Active FaiLures
MIDTOAFL
Pegged when the mobile-initiated dormant to active MSC D

transition fails due to lack of resources or the mobile
fail to arrive on the traffic channel.
syste
mwide
basis
Network-Initiated NIDTOAAT
Dormant To
Active ATtempts
Pegged when the MSC receives a

PCU_Page_Request after the network DCR PLICF
decides to make the transition to active state.
MSC D
syste
mwide
basis
Network-Initiated NIDTOASU
Dormant To
Active SUccess
Pegged when the network-initiated dormant to active MSC D

transition is successful mobile arrives on the traffic
channel.
syste
mwide
basis
Network-Initiated NIDTOAFL
Dormant To
Active FaiLures
Pegged when the network-initiated dormant to active MSC D

transition fails due to lack of resources or the mobile
fail to arrive on the traffic channel.
syste
mwide
basis
5.6. OM Group: CDMAPDSO (CDMA Packet Data Service Option)
Table 5-6: OM Group: CDMAPDSO

OM Full Name
Resource
Allocation
Attempts for
CDMA2000
INternet PPP
Data service
option
OM Register
(Name)
ATINPPP
Description
MSC
/ BSC V/D Basis
/ BTS
Pegged when there is an attempt made by the RMU MSC D

for a resource request from the CAU to allocate a
resource for a CDMA2000_INT_PPP_DATA service
option.
perRMU
basis
04/22/02 Page 134
Table 5-6: OM Group: CDMAPDSO

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
SUccessful
resource
allocation for
CDMA2000
INternet PPP
Data service
option
SUINPPP
Pegged when a resource for a

MSC D
CDMA2000_INT_PPP_DATA service option request
has been successfully allocated.
perRMU
basis
Hop Count for

CDMA2000
INternet PPP
Data service
option
HCINPPP
Pegged for each pool, including the first pool, the

MSC D
RMU searches through from the list to find a
resource for a CDMA2000_INT_PPP_DATA service
option.
perRMU
basis
Resource
allocation
FaiLures for
CDMA2000
INternet PPP
Data service
option
FLINPPP
Pegged when an attempt to allocate resource for a MSC D

CDMA2000_INT_PPP_DATA service option fails. It
is due to no resources available in any pool from the
list
perRMU
basis
5.7. OM Group: CAURM

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

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Service Resource SRMNAK3D pegged only in cases of 3G Packet Data calls.

MSC D
Manager
SRMNAK3D is pegged, along with the appropriate
Negative AcK for
CAU*BLKS OM, when Resource Manager (RM)
3G Data calls
receives a resource allocation failure indication from
SRMs. This is an error condition, indicating
mismatches between the RM and the SBS SRM.
pegge
d by
the
RMU
SRM Time-Out
SRMTO3D
for 3G Data calls
pegge
d by
the
RMU
pegged only in cases of 3G Packet Data calls.

MSC D
SRMTO3D is pegged, along with the appropriate
CAU*BLKS OM, when Resource Manager times out
waiting on a request for call resources from the
SRM.
04/22/02 Page 135
Table 5-7: OM Group: CAURM

OM Full Name
NO Resources
for REQuest for
3G Data calls
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
NORREQ3D pegged only in cases of 3G Packet Data calls.

MSC D
NORREQ3D is pegged, along with the appropriate
CAU*BLKS OM, when Resource Manager (RM) has
no available resources to allocate for a call. In this
case, the RM does not message to any of its SBSs
to determine availability, only internal data structures
are checked.
pegge
d by
the
RMU
5.8. OM Group: CAUCPSYS

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

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Network-Initiated NISDBATT
Short Data Burst
ATTempts
Pegged when the CAU receives a Short Data Burst

message from the PCU to send to the mobile. SDB
is being considered for future release, and thus this
register will not get pegged in the initial release of
1XRTT.
Network-Initiated NISDBSC
Short Data Burst
SuCcess
Pegged when the CAU receives a response from the MSC V+D
mobile to the SDB message sent. SDB is being
considered for future release, and thus this register
will not get pegged in the initial release of 1XRTT.
Network-Initiated NISDBFL
Short Data Burst
FaiLure
Pegged when the CAU times out waiting for a

MSC V+D
response from the mobile to the SDB message sent.
SDB is being considered for future release, and thus
this register will not get pegged in the initial release
of 1XRTT.
MSC V+D
5.9. OM Group: CDMAPGZN

One new OM is added in this group for 1XRTT.
Table 5-9: OM Group: CDMAPGZN
04/22/02 Page 136
OM Full Name OM Register

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

(Name)
Description
MSC / V/D Basis

BSC /
BTS
Reliable Packet
Sent Success
ReliablePack Counts the number of ACKs received as a result of

etSentSucce reliable packets being sent to any given PDSN.
ss
BSC
pernode
basis
Reliable Packet
ReTransmitted
ReliablePack Counts the number of reliable packets that had to be BSC

etReTransmi retransmitted because no ACK was received.
tted
pernode
basis
Reliable Packet
Received
ReliablePack Counts the number of messages the PCU received

etReceived with reliable delivery acknowledgement requested
per L2TP tunnel
BSC
pernode
basis
Number Of
Tunnel Failures
NumberOfTu Counts the number of times a L2TP tunnel was torn BSC
nnelFailures down due to failure of reliable packet transmission
per L2TP tunnel
pernode
basis
Total Unreliable
Bytes
Transmitted
TotalUnrelia Counts the cumulative number of bytes each

bleBytesTran session in the PCU transmitted to PDSN per L2TP
smitted
tunnel
BSC
pernode
basis
Total Unreliable
Bytes Received
TotalUnrelia Counts the cumulative number of bytes each

bleBytesRec session in the PCU received from PDSN per L2TP
eived
tunnel
BSC
pernode
basis
Total Fwd
TotalFwdPac Number of PPP packets dropped in the forward
Packets Dropped ketsDropped direction per PCU
BSC
percall
basis
Total Rev
TotalRevPac Number of PPP packets dropped in the reverse
Packets Dropped ketsDropped direction per PCU
BSC
percall
basis
04/22/02 Page 137
Table 5-10: OM Group: PCU

(Name)
Description
MSC / V/D Basis

BSC /
BTS
DCR Buffer
Overflows
DCRBufferO Number of DCR buffer overflows per PCU

verflows
BSC
percall
basis
RR Buffer
Overflows
RRBufferOv Number of RR buffer overflows

erflows
BSC
percall
basis
Total Session
Setup Initial
Attempts
TotalSession Number of packet session setups attempted during

SetupInitialAt initial session setup
tempts
BSC
percall
basis
BSC
percall
basis
Total Session
Setup Success
TotalSession Number of successful packet session setups, either BSC

SetupSucces by initial or reconnect attempts
s
percall
basis
Total Session
Setup Failures
TotalSession Number of failed packet session setups

SetupFailure
s
BSC
percall
basis
Reliable Packet
Sent Success
Overflow
ReliablePack Register allows values greater than 65535 for

etSentSucce ReliablePacketSentSuccess.
ssOverflow
BSC
pernode
basis
Reliable Packet
ReTransmitted
Overflow

etReTransmi ReliablePacketReTransmitted.
ttedOverflow
BSC
pernode
basis
Reliable Packet
Received
Overflow

etReceivedO ReliablePacketReceived.
verflow
BSC
pernode
basis
Total Unreliable
Bytes
Transmitted
Overflow
TotalUnrelia Register allows values greater than 65535 for

bleBytesTran TotalUnreliableBytesTransmitted.
smittedOverfl
ow
BSC
pernode
basis
Total Unreliable
Bytes Received
Overflow
TotalUnrelia Register allows values greater than 65535 for

bleBytesRec TotalUnreliableBytesReceived.
eivedOverflo
w
BSC
pernode
basis
Total Fwd
TotalFwdPac Register allows values greater than 65535 for
Packets Dropped ketsDropped TotalFwdPacketsDropped.
Overflow
Overflow
BSC
percall
basis
Total Rev
TotalRevPac Register allows values greater than 65535 for
Packets Dropped ketsDropped TotalRevPacketsDropped.
Overflow
Overflow
BSC
percall
basis
Total Session
TotalSession Number of packet session setups attempted when
Setup Reconnect SetupRecon reconnecting to an existing PPP session
Attempts
nectAttempts
04/22/02 Page 138
5.11. OM Group: ESEL
Table 5-11: OM Group: ESEL

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
RLP Setup
Attempts
RLPSetupAtt Number of RLP setups attempted

empts
BSC
RLP
perfor
manc
e
RLP Setup
Successes
RLPSetupSu Number of successful RLP setups

ccesses
BSC
RLP
perfor
manc
e
RLP Setup
Failures
RLPSetupFai Number of failed RLP setups

lures
BSC
RLP
perfor
manc
e
Fwd Burst Setup FwdBurstSet Pegged when a forward data burst needs to be set
Attempts
upAttempts up
BSC
data
sessi
on
setup
Fwd Burst Setup FwdBurstSet Pegged when a forward data burst is successfully
Successes
upSuccesse set up
s
BSC
data
sessi
on
setup
Fwd Burst Setup FwdBurstSet Pegged when a forward data burst could not be set
Failures
upFailures
up
BSC
data
sessi
on
setup
Rev Burst Setup

Attempts
RevBurstSet Pegged when a reverse data burst needs to be set

upAttempts up
BSC
data
sessi
on
setup
Rev Burst Setup

Successes
RevBurstSet Pegged when a reverse data burst is successfully

upSuccesse set up
s
BSC
data
sessi
on
setup
04/22/02 Page 139

OM Full Name
Rev Burst Setup
Failures
OM Register
(Name)
Description
RevBurstSet Pegged when a reverse data burst could not be set

upFailures
up
MSC
/ BSC V/D Basis
/ BTS
BSC
data
sessi
on
setup
BSC
SCH
setup
FSCH Link Setup FSCHLinkSe Number of FSCH setup attempts that are blocked
BSC
Block
tupBlock
for lack of resources (reason Oms are given below)
SCH
setup
FSCH Link
Downgrade
BSC
SCH
setup
BSC
SCH
setup
FSCH Radio Link FSCHRadioL This OM is pegged in the event the resources for the BSC
Access Failure
inkAccessFai FSCH are set up successfully, but the mobile does
lure
not arrive on the FSCH. It is pegged against each
link in the SCH active set.
SCH
setup
FSCH No Fwd
Power
FSCHNoFwd Pegged if the FSCHBlock reason indicates a lack of BSC

Power
available forward power
SCH
setup
FSCH No Walsh FSCHNoWal Pegged if the FSCHBlock reason indicates a lack of BSC
Code
shCode
available Walsh codes
SCH
setup
FSCH No Phys
Res
SCH
setup
FSCH Link Setup FSCHLinkSe Number of forward supplemental channel (FSCH)

Attempts
tupAttempts setup attempts
FSCHLinkDo Number of FSCH setup attempts that are not

wngrade
granted the requested data rate due to lack of
resources, but are granted a lower data rate.
Pegged against the primary pilot in the SCH active
set.
FSCH Link Setup FSCHLinkSe Number of FSCH setup successes

Success
tupSuccess
FSCHNoPhy Pegged if the FSCHBlock reason indicates there are BSC

sRes
no available channel elements
FSCH No Frame FSCHNoFra Pegged if the FSCHBlock reason indicates there is

Offset
meOffset
no available frame offset
BSC
SCH
setup
FSCH CFDS
Radio Config
FSCHCFDS Pegged if the FSCHBlock reason indicates SCH

RadioConfig burst functionality has not been enabled through
CFDS
BSC
SCH
setup
FSCH Timeout
FSCHTimeo Pegged if a response to the BTS resource request is BSC

ut
never received
SCH
setup
BSC
SCH
setup
RSCHLinkSetupB RSCHLinkSe Number of RSCH setup attempts that are blocked

BSC
lock
tupBlock
for lack of resources (reason Oms are given below)
SCH
setup
RSCH Link
Downgrade
SCH
setup
RSCH Link Setup RSCHLinkSe Number of reverse supplemental channel (RSCH)

Attempt
tupAttempt setup attempts
RSCHLinkD Number of RSCH setup attempts that are not

owngrade
granted the requested data rate due to lack of
resources, but are granted a lower data rate.
Pegged against the primary pilot in the SCH active
set.
BSC
04/22/02 Page 140

OM Full Name
OM Register
(Name)
Description
RSCH Link Setup RSCHLinkSe Number of RSCH setup successes

Success
tupSuccess
MSC
/ BSC V/D Basis
/ BTS
BSC
SCH
setup
RSCH Radio Link RSCHRadio This OM is pegged in the event the resources for the BSC
Access Failure
LinkAccessF RSCH are setup successfully, but the mobile does
ailure
not arrive on the RSCH. It is pegged against each
linkin the SCH active set.
SCH
setup
RSCH No Phys
Res
SCH
setup
RSCHNoPhy Pegged if the RSCHBlock reason indicates there are BSC

sRes
no available channel elements
RSCHNoFrameO RSCHNoFra Pegged if the RSCHBlock reason indicates there is

ffset
meOffset
no available frame offset
BSC
SCH
setup
RSCH CFDS
Radio Config
RSCHCFDS Pegged if the RSCHBlock reason indicates SCH

RadioConfig functionality has not been enabled through CFDS
BSC
SCH
setup
RSCH CFDS
High Speed
RSCHCFDS Pegged if the RSCHBlock reason indicates high

HighSpeed speed RSCH has not been enabled through CFDS
BSC
SCH
setup
RSCH Timeout
RSCHTimeo Pegged if a response to the BTS resource request is BSC

ut
never received
SCH
setup
SCHDrop
SCHDrop
SCH
setup
Pegged if the forward or reverse supplemental

channel gets abnormally dropped. This OM is
pegged against every pilot in the SCH active set.
BSC
5.12. OM Group: BTSCallProcessing MO
Table 5-12: OM Group: BTSCallProcessing MO

OM Full Name
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Paging Channel
Message Count
PagingChan Number of paging channel messages sent to the

nelMessage BTS by the PAM in the CAU. This includes pages,
Count
repages, SMS, etc.
BTS
V+D perBTS
basis
Paging Channel
Messages
Dropped
PagingChan Number of paging channel messages dropped by

nelMessages the BTSC due to BTSC CPU overload.
Dropped
BTS
V+D perBTS
basis
04/22/02 Page 141
5.13. OM Group: Advanced Frequency Assignment (FA) MO
Table 5-13: OM Group: Advanced Frequency Assignment (FA) MO

(Name)
Description
MSC / V/D Basis

BSC /
BTS
Num Of TC
Available
NumOfTCAv Total number of channel elements available for

ailable
traffic across all channel cards after overhead
channels have been subtracted.
BTS
V+D
TCE Util
Maximum
TCEUtilMaxi The peak number of channel elements in use,

mum
simultaneously, during a given time.
BTS
V+D perfreq
basis
Total Forward
Physical
Resources
TotalForward The number of 3G XCEM resources provisioned for BTS

PhysicalRes the BTSs forward link. This excludes all CCEM
ources
resources and faulty XCEM resources. This OM is a
snapshot taken at the time of reporting. It does not
represent how many resources are actually in use.
V+D perfreq
basis
Sch Forward
Physical
Resources
Reserved
SchForward
PhysicalRes
ourcesReser
ved
Perfreq
basis
perfreq
basis
This OM is a subset of
BTS
TotalForwardPhysicalResources.
SchForwardPhysicalResourcesReserved represents
the number of XCEM resources which are preallocated to the forward supplemental channel. This
includes resources for active and idle supplemental
channels. Since a short
perfreq
basis
setup time for data calls is crucial, resources for the

supplemental channel are pre-allocated instead of
being allocated at call setup.
Sch Maximum
SchMaximu This OM is a high water mark for the number of
Forward Physical mForwardPh XCEM resources being used for the forward
Resources Used ysicalResour supplemental channel at any time during the
cesUsed
reporting period.
BTS
Fch 3G Maximum Fch3GMaxi This OM is a high water mark for the number of
BTS
Forward Physical mumForward XCEM resources being used for 3G calls on the
Resources Used PhysicalRes forward fundamental channel at any time during the
ourcesUsed reporting period.
V+D perfreq
basis
Total Reverse
Physical
Resources
V+D perfreq
basis
TotalRevers The number of 3G XCEM resources provisioned for BTS

ePhysicalRe the BTSs reverse link. This excludes all CCEM
sources
resources and faulty XCEM resources. This OM is a
snapshot taken at the time of reporting. It does not
represent how many resources are actually in use.
04/22/02 Page 142
Table 5-13: OM Group: Advanced Frequency Assignment (FA) MO

(Name)
Sch Reverse
Physical
Resource
Reserved
SchReverse
PhysicalRes
ourceReserv
ed
Description
MSC / V/D Basis

BSC /
BTS
This OM is a subset of
BTS
TotalReversePhysicalResources.
SchReversePhysicalResourcesReserved represents
the number of XCEM resources which are preallocated to the reverse supplemental channel. This
includes resources for active and idle supplemental
channels. Since a short
perfreq
basis
perfreq
basis
setup time for data calls is crucial, resources for the

supplemental channel are pre-allocated instead of
being allocated at call setup.
Sch Maximum
SchMaximu This OM is a high water mark for the number of
Reverse Physical mReversePh XCEM resources being used for the reverse
Resources Used ysicalResour supplemental channel at any time during the
cesUsed
reporting period.
Fch 3G Maximum Fch3GMaxi
Reverse Physical mumRevers
Resources Used ePhysicalRe
sourcesUsed
BTS
This OM is a high water mark for the number of

BTS
XCEM resources being used for 3G calls on the
reverse fundamental channel at any time during the
reporting period.
V+D perfreq
basis
5.14. OM Group: Advanced Sector MO
Table 5-14: OM Group: Advanced Sector MO

(Name)
Description
Voice Fch
VoiceFchFor Array containing the average forward power (i.e.
Forward Link Util wardLinkUtil average of sum of digital gain squared) used by
Average
Average
RCs supporting voice or circuit-switched data calls
on the fundamental channel. Each element
corresponds to a different RC. The first element is
for RC1 and the last element is for RC5. This
MSC / V/D Basis

BSC /
BTS
BTS
persector
basis
information is useful in evaluating time impact of

voice, data, and various radio configurations on
system resources.
04/22/02 Page 143

(Name)
Description
MSC / V/D Basis

BSC /
BTS
Data Fch
DataFchFor Array containing the average forward power (i.e.
BTS
Forward Link Util wardLinkUtil average of sum of digital gain squared) used by
Average
Average
RCs supporting packet data sessions on the
fundamental channel. Each element corresponds to
a different RC. The first element is for RC3 and the
last element is for RC5. This information is
persector
basis
Sch Forward Link SchForward Array containing the average forward power (i.e.
BTS
Util Average
LinkUtilAvera average of sum of digital gain squared) used by
ge
RCs supporting packet data sessions on the
supplemental channel. Each element corresponds to
a different RC. The first element is for RC3 and the
last element is for RC5. This information is useful in
evaluating time impact of voice, data, and various
radio configurations on system resources.
persector
basis
Percent Time
Above Fwd Data
Call Blocking
Threshold
PercentTime
AboveFwdD
ataCallBlocki
ngThreshold
persector
basis
Configured Fwd
Data Call
Blocking
Threshold
ConfiguredF This metric represents the amount of power

wdDataCallB available for data originations, terminations, and
lockingThres handoffs into the BTS.
hold
BTS
persector
basis
Fch Origination
FchOriginati Number of successful BTS resource allocations for BTS
Non Blocking 2G onNonBlocki 2G calls. This is not an indication of successful call
ng2G
attempts. This metric does not include calls that
were allocated for 2G after being downgraded from
3G. This metric also does not include non- reference
pilot links setup for CASHO. 2G links, other than the
reference pilots link, setup for CASHO are pegged
under FchHandoffNonBlocking2G.
persector
basis
useful in evaluating time impact of voice, data, and

various radio configurations on system resources.
This represents the percentage of time during the 2- BTS

second measurement interval that data calls would
be blocked based on the MaxDataResources and
MaxDataFCHResources attributes in the
AdvancedSector MO.
04/22/02 Page 144

(Name)
Description
MSC / V/D Basis

BSC /
BTS
Fch Handoff Non FchHandoffN Array of 2 elements indicating the number of

BTS
Blocking 2G
onBlocking2 successful BTS resource allocations for 2G
G
handoffs. The first element in the array (i.e.
FchHandoffNonBlocking2G[0]) represents the
number of successful BTS resource allocations for a
2G non VPN-based soft handoff. The second
element in the array (i.e.
FchHandoffNonBlocking2G[1]) represents the
number of successful BTS resource allocations for a
2G VPN-based soft handoffs.
persector
basis
Note: This OM is not an indication of successful

handoffs. Note that this metric also includes nonreference pilot links setup for CASHO.
Fch Origination
FchOriginati Number of successful BTS resource allocations for
Non Blocking 3G onNonBlocki 3G voice calls on the fundamental channel. This is
Voice
ng3GVoice not an indication of successful call attempts. This
metric does not include non-reference pilot links
setup for CASHO. 3G voice links, other than the
under FchHandoffNonBlocking3GVoice.
BTS
persector
basis
Fch Origination
Non Blocking 3G onNonBlocki 3G data calls on the fundamental channel. This is
Data
ng3GData
not an indication of successful call attempts.
BTS
persector
basis
BTS
persector
basis
Fch Handoff Non FchHandoffN Number of successful BTS resource allocations for BTS
Blocking 3G
onBlocking3 3G voice handoffs on the fundamental channel. Note
Voice
GVoice
that This is not an indication of successful handoffs.
persector
basis
Fch Handoff Non FchHandoffN Number of successful BTS resource allocations for BTS
Blocking 3G Data onBlocking3 3G data handoffs on the fundamental channel. Note
GData
persector
basis
Sch Burst Non

Blocking 3G
persector
basis
This metric does not include non-reference pilot links

setup for CASHO. 3G data links, other than the
under FchHandoffNonBlocking3GData.
Fch Origination
Non Blocking 3G onNonBlocki fundamental channel 2G calls which were
Downgrade 2G
ng3GDowngr downgraded from 3G calls attempts. This metric
ade2G
does not include non-reference pilot links setup for
CASHO. 2G links, other than the reference pilots
link, setup for CASHO are pegged under
FchHandoffNonBlocking2G.
SchBurstNon Number of successful BTS resource allocations for BTS

Blocking3G 3G data bursts on the supplemental channel. This is
not an indication of successful data bursts.
04/22/02 Page 145

(Name)
Description
MSC / V/D Basis

BSC /
BTS
Sch Handoff Non SchHandoff Number of successful BTS resource allocations for BTS
Blocking 3G
NonBlocking 3G data handoffs on the supplemental channel. Note
3G
persector
basis
Blocked Fch
Originations 2G
BlockedFch Array indicating the number of 2G call attempts

BTS
Originations2 blocked on the fundamental channel. Each array
G
element corresponds to a different blocking reason.
persector
basis
Blocked Fch
Handoffs 2G
BlockedFch Array indicating the number of 2G handoffs blocked BTS

Handoffs2G on the fundamental channel. Each array element
corresponds to a different blocking reason.
persector
basis
Blocked Fch
Originations 3G
Voice
BlockedFch Array indicating the number of 3G voice call

BTS
Originations3 attempts blocked on the fundamental channel. Each
GVoice
array element corresponds to a different blocking
reason.
persector
basis
Blocked Fch
Originations 3G
Data
BlockedFch Array indicating the number of 3G data sessions

BTS
Originations3 blocked on the fundamental channel. Each array
GData
persector
basis
Blocked Fch
Handoffs 3G
Voice
BlockedFch Array indicating the number of 3G voice handoffs

BTS
Handoffs3G blocked on the fundamental channel. Each array
Voice
persector
basis
Blocked Fch
Handoffs 3G
Data
BlockedFch Array indicating the number of 3G data handoffs

BTS
Handoffs3G blocked on the fundamental channel. Each array
Data
persector
basis
Blocked Sch
Bursts
BlockedSch Array indicating the number of 3G data bursts

BTS
Bursts
blocked on the supplemental channel. Each array
persector
basis
Blocked Sch
Handoffs
BlockedSch Array indicating the number of 3G data handoffs

BTS
Handoffs
blocked on the supplemental channel. Each array
persector
basis
Frame Cnt FCH
FrameCntFC Array indicating the total number of frames sent on

H
the forward link for every user on the fundamental
channel. Each element in the array represents one
radio configuration from RC1 through RC5. The
array begins with RC1.
BTS
V+D persector
basis
Frame Cnt SCH
FrameCntSC Array indicating the total number of forward frames

H
for every user on the supplemental channel. Each
element in the array represents one radio
configuration from RC3 through RC5. The array
begins with RC3.
BTS
CE Frame Cnt
FCH
CEFrameCnt Equivalent to FrameCntFCH with each frame being

FCH
divided by the number of softer handoff links.
BTS
V+D persector
basis
persector
basis
04/22/02 Page 146

(Name)
Description
MSC / V/D Basis

BSC /
BTS
CE Frame Cnt
SCH
CEFrameCnt Equivalent to FrameCntSCH with each frame being

SCH
divided by the number of softer handoff links.
BTS
Primary Frame
Cnt FCH
PrimaryFram Equivalent to FrameCntFCH with each frame being

eCntFCH
divided by the product of the number of softer
handoff links and the number of soft handoff links.
BTS
V+D persector
basis
Primary Frame
SCH
PrimaryFram Equivalent to FrameCntSCH with each frame being

eSCH
divided by the product of the number of softer
handoff links and the number of soft handoff links.
BTS
persector
basis
persector
basis
04/22/02 Page 147
6. List Of Operational Measurements (OMs)

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

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

Support Packet Data Calls
Quick Paging Channel
Peak Quick Paging Channel Occupancy
Average Quick Paging Channel Occupancy
04/22/02 Page 151

Supported OMs
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Access Channel
Peak Access Channel Occupancy
L L
Average Access Channel Occupancy
S S
Average Access Channel Occupancy Used to

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

Supported OMs
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
RC
Data
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Reverse Traffic Channel Reception

SMS Received on Reverse Traffic Channel
L L
S S
L
S
Average Reverse Traffic Channel Size

Backhaul
Peak Backhaul Occupancy
Average Backhaul Occupancy
L
M
S
L
M
S
Originations
Origination Attempts
L L
L
MM
M
L
S S
S
N N
N
Origination Blocks
L L
L
MM
L S
S S
N
N N
L
M
L
M
S
N
Silent Reorigination
L L L L
3G Origination Assigned 2G Resources
L
L
M
L
M L
N
N
N
s
L L
L
L
M
L
M L
N
N
N
s
L L
2G Origination Assigned 3G Resources
3G Origination Assigned Lower Data Rate

Origination Cross Carrier Assignments
M
N
N
MM
S S
N N
Origination Total # of 3G Data Unique Users
04/22/02 Page 153

Supported OMs
Total # 3G data call blocks (BSC element)
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
M
M
S
Terminations
Termination Attempts
L L
N NMM
S S
L
M
S
L L
MM
S S
N N
L
M
S
L
L
M
L
M L
N
N
N
s
L
M L L L
s
L
L
L
M
L
N
N
N
Termination Blocks
3G Termination Assigned 2G Resources
2G Termination Assigned 3G Resources
3G Terminations Assigned Lower Data Rate

N
Termination Cross Carrier Assignments
Termination No Response from Mobile
MM
S S
MM
IS-95B Features
Access Handoff
Access Handoff Original Sector
Access Handoff Target Sector
Access Entry Handoff

Access Entry Handoff Original Sector
Access Entry Handoff Target Sector
Access Probe Handoff

Access Probe Handoff Original Sector
04/22/02 Page 154

Supported OMs
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
L
M

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 Calls
L L
L
L
MM M
M
M
N N
N
L
L
M
Soft Handoff
Soft Handoff Request
Soft Handoff Denied
Soft Handoff Failures
L
L
L
M
L
M
M
S
L
L
L
M
L
M
M
S
L
L
L
M
L
M
M
S
Average Soft Handoff Percentage Per Call
L
N
N
Average Channel Elements Per Call
N N
Average Code Links Per Call
MM
N N
S S
S
N
N M
Hard Handoff
Hard Handoff Request
Hard Handoff Denied
04/22/02 Page 155

Supported OMs
Hard Handoff Failure

Average Long Term Power Required
MM
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
L L
L
M
MM
N
N
M
N
L
M
MMM
Soft Handoff Denied
MMM
Soft Handoff Failures
MMM
Dedicated Control Channel

Dropped Calls
Soft Handoff
Soft Handoff Denied
Soft Handoff Failure
Average Walsh Code Links Per Call
Hard Handoff
Hard Handoff Denied
Forward Fundamental Channel Packet Data Call
Dropped Calls
ML
Soft Handoff

Average Channel Element Per Call
M
N
M
M
N
N M
04/22/02 Page 156

Supported OMs
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Hard Handoff
m
l
Hard Handoff Denied
m
l
m
l

Forward Fundamental Channel Data Burst
Forward Fundamental Channel Assignments
L L
N N
L
N
Forward Fundamental Channel RLP Frames

Sent
L L
Forward Fundamental Channel RLP

Retransmissions
L L
Average Short Term Power Required
L L
N N
L
N
Forward Fundamental Channel Data Burst

Denied
L L
N N
N
N
Reverse Fundamental Channel Packet Data Call

Reverse Fundamental Channel Data Burst
Reverse Fundamental Channel RLP Frames
Received
Reverse Fundamental Channel RLP
Retransmissions
Average RLP Retransmissions Required Per
Data Burst
Forward Supplemental Channel Packet Data Call
Soft Handoff
04/22/02 Page 157

Supported OMs

Average Soft handoff Percentage Per Call
N
s N
l
N
N
s
L
L
L
M
M LM
S
N
N
N
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Forward Supplemental Channel Data Burst

Assignment
L
M
L
M
L
M
Forward Supplemental Channel RLP Frames

Sent
Forward Supplemental Channel RLP
Retransmissions
Forward Supplemental Channel Bursts
Interrupted
Average Short Term Power Required

Denied
M
M
S
N
N
M
N
Forward Supplemental Data Burst Assigned a

Lower Rate
M
N
N
Reverse Supplemental Channel Packet Data Call

Soft Handoff
l
m
Soft Handoff Request Denied
l
m
l
m
04/22/02 Page 158

Supported OMs

Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF

Supplemental Channel Data Burst
Reverse Supplemental Channel Assignments
M
M
S
N
N
Reverse Supplemental Channel RLP Frames

Received
M
N
MM
L L L L
Reverse Supplemental Channel RLP

Retransmissions
Average Retransmissions Per Data Burst
Reverse Supplemental Channel Burst
Interrupted
Supplemental Channel Data Burst Denied
M
M
S
N
N
M
N
Active Mode Circuit Data Call

Dropped Calls
L L
L
L
MM M
M
M
N N
N
L
M
L
M
Soft Handoff
Soft Handoff Denied
M
S
M
S
MM
N N
N N
N N
Hard Handoff
04/22/02 Page 159

Supported OMs

Hard Handoff Denied
m
N
N
N N
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Packet Data Session

Peak Data Throughput
N
M
Average Data Throughput
N
M
Peak Duration
N
M
Average Duration
N
M
Buffer Overflow
L
M
L
N
L
M
NM
Total Dormant to Active Transitions

Average Dormant to Active Transitions
Total # 3G Data Fundamental Channel Releases
Circuit Data Session
Peak Data Throughput
Average Data Throughput
Peak Duration
Average Duration
Buffer Overflow
Forward Power Overload
Reverse Power Overload
m
L
M
M
N
N
M
N
L
M
M
04/22/02 Page 160

Supported OMs
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
RC
Data
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
Channel Element Usage

Peak Channel Element Usage
L
N
L
N
Average Channel Element Usage
L
M
S
L
L
M
N
M
Peak Walsh Code Usage
L L
Average Walsh Code Usage
L L
MM
L
M
Walsh Code Usage
Data Throughput
Forward Link Peak Data Throughput
Reverse Link Peak Data Throughput
Forward Link Average Data Throughput
Reverse Link Average Data Throughput
Forward Link Peak Data Load

Reverse Link Peak Data Load
Forward Link Average Data Load
Reverse Link Average Data Load
Forward Link Peak Data Delay

Reverse Link Peak Data Delay
Forward Link Average Data Delay
Reverse Link Average Data Delay
BSC - PCF Metrics
Reliable Packets Sent Success
N
l
m
s
04/22/02 Page 161

Supported OMs
Packet Success
Packet Submits
Reliable Packets Sent Success Overflow
Reliable Packets Re-Transmitted
L
N
m
s
L
N
l
m
s
l
m
s
N
l
m
s
Reliable Packets Re-Transmitted Overflow
Reliable Packets Received Overflow
Total Unreliable Bytes Transmitted
m
s
N
l
m
s
N
l
m
s
Total Unreliable Bytes Transmitted Overflow
N
l
m
s
Reliable Packets Received
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
l
m
s
04/22/02 Page 162

Supported OMs
Total Unreliable Bytes Received
N
l
m
s
Total Unreliable Bytes Received Overflow
Total Fwd Packets Dropped
Add'l Info
call
session
rate
usage-state
duration
PDSN/IWU/IWF
HO State
Reason
source type
PCU/PCF
Data
RC
system
zone/MM
site
sector
SO
carrier
channel
type
link
RF
L
m
s
S
N
l
S
N
m
Total Fwd Packets Dropped Overflow
s
L M
M
N
Total Rev Packets Dropped
L
M
N
l
m
s
l
m
s
l
m
s
l
m
s
l
m
s
Total Session Setup Initial Attempts
s
N
Total Session Setup Reconnect Attempts
m
s
Total Rev Packets Dropped Overflow
DCR Buffer Overflows
DCR_NumOStop Transmit Msgs Sent
RRBuffer Overflows
04/22/02 Page 163

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

Nortel KPI Formula S Desc Detail 2 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nortel KPI Formula S Desc Detail 2 PDF

Uploaded by

Copyright:

Available Formats

3G 1xRTT Nortel Operational Measurements

3G 1xRTT Nortel Operational

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

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

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

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

3.2.10. 3G Data Post-MCTA Call Blocks (per frequency) ......................................... 70

3G 1xRTT Nortel Operational Measurements

6. List Of Operational Measurements (OMs) Requested By

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

2. Overview of 3G Voice and Data in Nortel

CDF Editor v1.1

CAUSCT3V (CAU SeCTor based OMs for 3G Voice calls)

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

CAUCPSCT (CAU SeCTor based OMs for Call Processing)

CAUCPFRQ (CAU FReQuency based OMs for Call Processing)

CAURM (CAU OMs relating to the resource manager)

CDMAPGZN (CM OMs relating to the page zone events)

CAUCPSYS (CAU OMs relating to the Call Processing System)

OM3G Boolean field:

Impact on CAUSCT3V and

Impact on CAUSCT3D and

The registers in these two OM

The registers in these two OM

Sprint PCS Proprietary & Confidential

The registers in these two OM

3G 1xRTT Nortel Operational Measurements

3G 1xRTT Nortel Operational Measurements

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

3.1. Performance Formulas for 3G Voice

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Number of successful calls =

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

CAU hard Handoff ATTemptS

Expected Formula Range:

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

For mobile-terminated calls, attempts are recorded in CAUPGRES, which

Expected Formula Range:

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

CAUSCT3V.CAUHATTS FchOriginationNonBlocking3GDowngrade2G)] * 100

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

CAUSCT3V.CAUNOTCE CAUSCT3V.CAUNOWCD CAUSCT3V.CAUFWCAP CAUSCT3V.CAUNOFOF CAUSCT3V.CAURECAP CAUSCT3V.MCTAREQF CAUSCT3V.MCTAHRQF BlockedFchOrigination3Gvoice[6])

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

Sprint PCS Proprietary & Confidential

3G 1xRTT Nortel Operational Measurements

target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or

Sprint PCS Proprietary & Confidential