Documente Academic
Documente Profesional
Documente Cultură
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.
04/22/02 Page 1
Table of Contents
1. Introduction
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
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
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
Hardware
Software
BTS
XCEM
NBSS10.1.x
BSC
SCI-S
NBSS10.1.x
ESEL
MSC
MTX10
PC
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:
04/22/02 Page 6
In addition to the above OM groups, the following OM groups have been modified for
1xRTT in the MSC:
04/22/02 Page 7
MCTA OMs:
The MSC has another set of OMs available under the MCTA reports. The MCTA
performance reflects how well the system is allocating resources across multiple frequencies
for new originations, terminations, and hard handoff attempts from other CDMA cells. The
performance is determined on a per frequency basis. MCTA OMs do not replace the normal
call processing OMs but are pegged in addition to the normal call processing OMs.
Consequently there is some duplicate information.
BSC OMs:
BSC OMs are collected by the following two managed objects (MOs):
The Packet Control Unit (PCU)
PCU OMs help in evaluating the R-P link between the SBS and the PDSN and in the
setup of packet data sessions over the L2TP tunnel.
The Enhanced Selector Card (ESEL)
ESEL OMs help in evaluating the performance of the RLP, the setup of supplemental
channels, and the setup of data session elements on the selector card.
Both of these MOs are new for 1xRTT; and are collected in the subsystems and forwarded to
the base station subsystem manager (BSSM) every 30 minutes in the form of a
ConsolidatedOM Event Report, using the mechanism developed for the CDMA-LTX
product.
BTS OMs:
The RF-related BTS OMs are collected by the following five managed objects (MOs):
BTSCallProcessing
These OMs are pegged on a per-BTS basis. Each of these pegs is the sum of all events in
every frequency and every sector hosted by the BTS.
Advanced FA MO
Advanced Frequency Assignment (FA) OMs deal with the status of XCEM resources on
the fundamental as well as the supplemental channels.
CBCM MO
The CBCM provides management of the entire MCBTS, communications over the T1/E1
and to the mate DCG. The CBCM hardware is composed of the BTS controller and the
BTS Interface.
Power Management MO
These are pegged on a per CDMA frequency, per-sector basis for all the supported
frequencies.
Sprint PCS Proprietary & Confidential
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.
04/22/02 Page 10
04/22/02 Page 11
Day 1: 92.28 %
Day 2: 91.95 %
Day 3: 92.09 %
Day 4: 94.49 %
04/22/02 Page 12
CAUSCT3V.CAUHBLKS
Total calls attempted
CAUSCT3V.CAUOATTS +
CAUSCT3V.CAUPGRES +
CAUSCT3V.CAUHATTS
FchOriginationNonBlocking3GDowngrade2G
OMs
CAU Origination BLocKS
CAUOBLKS
Pegged any time a mobile-originated call setup fails due to resource shortage. It
represents the total number of origination setup failures in a sector, regardless of
resource. The same failure reasons that are pegged for CAUTBLKS can be pegged
in conjunction with CAUOBLKS.
CAU Termination BLocKS
CAUTBLKS
Pegged any time a mobile-terminated call setup fails due to resource shortage. It
represents all of the termination setup failures in a sector, regardless of resource.
One or more of the following call setup failure reasons is pegged in conjunction
with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,
CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and
CAUESWFL.
CAU hard Handoff BLocKS
CAUHBLKS
Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource
shortage. It represents all of the hard handoff setup failures into a sector,
regardless of resource. This OM is pegged for both inter- and intra-system hard
handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it
merely represents the number of times that a hard handoff could not be completed
due to resource shortages in the target cell/sectorthe call in the source cell is
still up. The same failure reasons that are pegged for CAUOBLKS (see previous
page) can be pegged in conjunction with CAUHBLKS.
CAU Origination ATTemptS
CAUOATTS
Pegged when the CAU receives an origination message from the BTS. Test call
originations are pegged in a separate OM.
CAU PaGe RESponse
CAUPGRES
04/22/02 Page 13
Day 1: 0.02 %
Day 2: 0.01 %
Day 3: 0.07 %
Day 4: 0.13 %
04/22/02 Page 14
04/22/02 Page 15
04/22/02 Page 16
of the limitation on the number of decoding units (both Viterbi and Turbo) that an
be active on a frame offset (and adjacent frame offsets).
CAU ForWard CAPacity full
CAUFWCAP
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time
a BTS reports forward capacity full via NOIS messages, regardless of origination,
termination or hard handoff.
CAU REverse CAPacity full
CAURECAP
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time
a BTS reports reverse capacity full via NOIS messages, regardless of origination,
termination or hard handoff. However, currently there is no reliable mechanism
for estimating reverse link capacity and so this response is disabled on the BTS.
Consequently, this OM is never pegged.
Resource Manager NO Resources for REQuest
RMNORREQ
Pegged, along with the appropriate CAU*BLKS OM, when Resource Manager
(RM) has no available resources to allocate for a call. In this case, the RM does
not message to any of its SBSs to determine availability, only internal data
structures are checked.
CAU Error case, Radio Setup FaiLure
CAUERSFL
Pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails
due to the fact that some BTS resource is not available. This OM is also pegged
when the BTS does not respond to resource requests. It is also pegged when the
Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA
enabled sector (that is, no available capacity on all co-located carriers).
MCTA REQuest Failure
MCTAREQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for origination or termination call setup. It is pegged on a per-sector
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA Handoff ReQuest Failure
MCTAHRQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
04/22/02 Page 17
04/22/02 Page 18
FchOriginationNonBlocking3GDowngrade2G
Number of successful BTS resource allocations for fundamental channel 2G calls
which were downgraded from 3G calls attempts. This metric does not include
non-reference pilot links setup for CASHO. 2G links, other than the reference
pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G.
Field Results: TCE
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
04/22/02 Page 19
OMs
CAU Error Radio Link FaiLure
CAUERLFL
Pegged if the origination or termination fails because the mobile never arrived on
the traffic channel (similar to SAT timeout). CAUERLFL is not pegged in cases
where the CAUOBLKS or CAUTBLKS OMs are pegged.
CAU hard Handoff Radio Link FaiLure
CAUHRLFL
Pegged if the hard handoff attempt fails because the mobile never arrived on the
target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not
pegged in cases where CAUHBLKS is pegged.
CAU Origination ATTemptS
CAUOATTS
Pegged when the CAU receives an origination message from the BTS. Test call
originations are pegged in a separate OM.
CAU PaGe RESponse
CAUPGRES
For mobile-terminated calls, attempts are recorded in CAUPGRES, which
indicates that a page response was received from a CDMA sector in response to a
page request (irrespective of whether it was in response to an initial page request
or a retry by the CM).
CAU hard Handoff ATTemptS
CAUHATTS
Pegged when the CAU receives a ReadyNewCell message from the CM,
indicating that a hard handoff attempt sequence in a (CDMA) target sector should
begin.
FchOriginationNonBlocking3GDowngrade2G
Number of successful BTS resource allocations for fundamental channel 2G calls
which were downgraded from 3G calls attempts. This metric does not include
non-reference pilot links setup for CASHO. 2G links, other than the reference
pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G.
Field Results
Day 1: 2.17 %
Day 2: 2.26 %
04/22/02 Page 20
Day 3: 2.07 %
Day 4: 1.97 %
04/22/02 Page 21
Orig&Term
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
Hard Handoff
04/22/02 Page 22
Day 1: 2.05 %
Day 2: 2.29 %
Day 3: 1.91 %
04/22/02 Page 23
Day 4: 1.84 %
04/22/02 Page 24
RF-related
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
Network-related
04/22/02 Page 25
NOTE: CAUFRQ3V refers to the sum of the register for all frequencies on the
sector.
OMs
MCTA REQuest Failure
MCTAREQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for origination or termination call setup. It is pegged on a per-sector
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA Handoff ReQuest Failure
MCTAHRQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA ORIGination
MCTAORIG
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
MCTA PaGe RESponse
MCTAPGRES
For mobile-terminated calls, attempts are recorded in MCTPGRES, which
indicates that a page response was received from an MCTA enabled CDMA
sector in response to a page request. This OM is pegged irrespective of whether it
was the first or the second attempt to page the mobile. CAUPGRES is also pegged
whenever MCTPGRES is pegged.
MCTA Handoff Call ATTempts
MCTHCATT
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin.
Field Results
Day 1: 0.97 %
04/22/02 Page 26
Day 2: 0.97 %
Day 3: 1.28 %
Day 4: 0.98 %
04/22/02 Page 27
04/22/02 Page 28
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin.
Field Results
Day 1: 0.00 %
Day 2: 0.00 %
Day 3: 0.00 %
Day 4: 0.00 %
04/22/02 Page 29
CAUFRQ3V.MCTHCATT)] * 100
Case 2: Failures NOT leading to overall MCTA frequency selection failure
No Rsrc% = [CAURFQ3V.MCTAREQN
/
(CAUFRQ3V.MCTORIGS +
CAUFRQ3V.MCTPGRES +
CAUFRQ3V.MCTHCATT)] * 100
The following set of formulas deal with the percentage of MCTA frequency
resource allocation failures resulting due to time-outs before the Carrier
Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to time-outs:
Time Out% = [(CAUSCT3V.MCTALLTO +
(CAUSCT3V.MCTAMIXF
CAURFQ3V.MCTARQFN) +
CAUFRQ3V.MCTAREQT)
/
(CAUFRQ3V.MCTORIGS +
CAUFRQ3V.MCTPGRES +
CAUFRQ3V.MCTHCATT)] * 100
04/22/02 Page 30
is pegged against the carrier(s) that respond with a resource full or not available
response. MCTAREQN may not always be pegged under low load conditions.
MCTA REQuest Timeout
MCTAREQT
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs never responded to a capacity request. MCTAREQT is pegged against
the carrier(s) that did not respond to the capacity request. MCTAREQT may not
always be pegged under low traffic load conditions.
MCTA All frequencies Full
MCTALLFU
Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when
NO frequency was successfully selected by MCTA because none of the BTSs had
resources available. It is pegged on a per-sector basis.
MCTA ReQuest response Failed (full or Not available)
MCTARQFN
Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or
MCTAHRQF), when no frequency was successfully selected by MCTA because
some BTSs timed out, while some responded with a resource full or not available
response. MCTARQFN is pegged against the carrier(s) that respond with a
resource full or not available response.
MCTA ALL frequencies Timed-Out
MCTALLTO
Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when
NO frequency was successfully selected by MCTA because none of the BTSs
responded to the capacity request query. It is pegged on a per-sector basis.
MCTA MIXed Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or
MCTAHRQF), when NO frequency was successfully selected by MCTA because
some BTSs
timed-out while some responded with a resource full or not available response. It
is pegged on a per-sector basis.
MCTA ORIGination
MCTORIGS
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
04/22/02 Page 31
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 32
Freq1
Freq2
Freq3
Day 1:
44 %
38 %
17 %
Day 2:
44 %
59 %
15%
Day 3:
37 %
50 %
13 %
Day 4:
40 %
42 %
17 %
04/22/02 Page 33
04/22/02 Page 34
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 %
04/22/02 Page 35
OMs
MCTA Error case Radio link Setup FaiLure
MCTERSFL
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever
a call setup fails due to the fact that the BTS could not allocate resources due to
any of the BTS failure reasons. This OM is also pegged when the BTS does not
respond at all to resource requests. MCTERSFL is pegged only after an MCTA
frequency is selected. MCTERSFL is pegged against the selected frequency.
MCTA Origination ATTemptS
MCTOATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile origination in a sector with MCTA
enabled. Please note that the MCTA frequency for MCTOATTS may be different
from the MCTA frequency on which the call originated (MCTORIGS).
MCTA Termination ATTemptS
MCTTATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile termination in a sector with MCTA
enabled.
MCTA Handoff ATTemptS
MCTHATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile hard handoff attempt into a target
sector with MCTA enabled.
Field Results:
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
04/22/02 Page 37
04/22/02 Page 38
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 39
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 %
04/22/02 Page 41
Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the
mobile never arrived on the target sectors traffic channel (similar to
SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is
pegged.
MCTA Origination ATTemptS
MCTOATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile origination in a sector with MCTA
enabled. Please note that the MCTA frequency for MCTOATTS may be different
from the MCTA frequency on which the call originated (MCTORIGS).
MCTA Termination ATTemptS
MCTTATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile termination in a sector with MCTA
enabled.
MCTA Handoff ATTemptS
MCTHATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile hard handoff attempt into a target
sector with MCTA enabled.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 42
3.1.11. 3G Voice
frequency)
Post-MCTA
RF
related
Drop
Calls
(per
04/22/02 Page 43
MCTHSUCC
Pegged, along with CAUHSUCC, when a mobile successfully arrives on the
traffic channel after a hard handoff.
Field Results:
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 %
04/22/02 Page 44
Day 1: 81.87 %
Day 2: 70.09 %
Day 3: 84.01 %
Day 4: 82.78 %
04/22/02 Page 45
04/22/02 Page 46
still up. The same failure reasons that are pegged for CAUOBLKS (see previous
page) can be pegged in conjunction with CAUHBLKS.
CAU Origination ATTemptS
CAUOATTS
Pegged when the CAU receives an origination message from the BTS. Test call
originations are pegged in a separate OM.
CAU PaGe RESponse
CAUPGRES
For mobile-terminated calls, attempts are recorded in CAUPGRES, which
indicates that a page response was received from a CDMA sector in response to a
page request (irrespective of whether it was in response to an initial page request
or a retry by the CM).
CAU hard Handoff ATTemptS
CAUHATTS
Pegged when the CAU receives a ReadyNewCell message from the CM,
indicating that a hard handoff attempt sequence in a (CDMA) target sector should
begin.
Field Results
Day 1: 3.72 %
Day 2: 0.00 %
Day 3: 0.08 %
Day 4: 0.00 %
04/22/02 Page 47
04/22/02 Page 48
04/22/02 Page 49
Pegged any time a mobile-terminated call setup fails due to resource shortage. It
represents all of the termination setup failures in a sector, regardless of resource.
One or more of the following call setup failure reasons is pegged in conjunction
with CAUTBLKS: RMNORREQ, RMSRMNAK, RMSRMTO, CAUERSFL,
CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, CAURECAP and
CAUESWFL.
CAU hard Handoff BLocKS
CAUHBLKS
Pegged any time a CDMA-to-CDMA hard handoff setup fails due to resource
shortage. It represents all of the hard handoff setup failures into a sector,
regardless of resource. This OM is pegged for both inter- and intra-system hard
handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it
merely represents the number of times that a hard handoff could not be completed
due to resource shortages in the target cell/sectorthe call in the source cell is
still up. The same failure reasons that are pegged for CAUOBLKS (see previous
page) can be pegged in conjunction with CAUHBLKS.
CAU NO Traffic Channel Element
CAUNOTCE
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a
BTS reports no traffic channel element via NOIS messages, regardless of
origination, termination or hard handoff.
CAU NO Walsh Code
CAUNOWCD
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a
BTS reports no walsh code via NOIS messages, regardless of origination,
termination or hard handoff.
CAU NO Frame Offset
CAUNOFOF
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time
a BTS cannot allocate resources due to some CSM 5000 hardware limitation. The
CSM 5000 is limited in how much traffic it can support on its reverse link because
of the limitation on the number of decoding units (both Viterbi and Turbo) that an
be active on a frame offset (and adjacent frame offsets).
CAU ForWard CAPacity full
CAUFWCAP
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time
a BTS reports forward capacity full via NOIS messages, regardless of origination,
termination or hard handoff.
Sprint PCS Proprietary & Confidential
04/22/02 Page 50
04/22/02 Page 51
Term
Day 1:
example
Day 2:
example
HandO
TCE
WalshC
NframO FwdC
04/22/02 Page 52
Day 3:
example
Day 4:
example
Day 1:
example
Day 2:
example
Day 3:
example
Day 4:
example
BTSt-o
BSCt-o
04/22/02 Page 53
Day 1: 3.19 %
Day 2: 6.49 %
Day 3: 3.57 %
Day 4: 3.39 %
04/22/02 Page 54
04/22/02 Page 55
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Hard Handoff
04/22/02 Page 56
for soft or softer handoff. These are RF-related call failures as detected by the
SBS.
CAU DROPped call Network
CAUDROPN
Pegged by the CAU when any of the other (non-RF) drop indication reasons are
sent from the SBS in the radio link drop indication message.
CAU Origination SUCCess
CAUOSUCC
Pegged when a mobile-originated call successfully arrives on the traffic channel.
This includes all originations placed on the traffic channel to receive treatment.
CAU Termination SUCCess
CAUTSUCC
Pegged when a mobile-terminated call successfully arrives on the traffic channel.
CAU hard Handoff SUCCess
CAUHSUCC
Pegged when a mobile, attempting a hard handoff, successfully arrives on the
traffic channel in the target sector.
Field Results
Day 1: 3.24 %
Day 2: 1.35 %
Day 3: 2.89 %
Day 4: 1.21 %
04/22/02 Page 57
RF% = [CAUSCT3D.CAUDROPR /
(CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC)] * 100
Drops due to network-related reasons:
Ntwk% = [CAUSCT3D.CAUDROPN /
(CAUSCT3D.CAUOSUCC +
CAUSCT3D.CAUTSUCC +
CAUSCT3D.CAUHSUCC)] * 100
OMs
CAU DROPped call Rf
CAUDROPR
Pegged by the CAU against the reference pilot when a call is dropped by the SBS
due to loss of traffic or due to HCM (handoff completion message) timeout
for soft or softer handoff. These are RF-related call failures as detected by the
SBS.
CAU DROPped call Network
CAUDROPN
Pegged by the CAU when any of the other (non-RF) drop indication reasons are
sent from the SBS in the radio link drop indication message.
CAU Origination SUCCess
CAUOSUCC
Pegged when a mobile-originated call successfully arrives on the traffic channel.
This includes all originations placed on the traffic channel to receive treatment.
CAU Termination SUCCess
CAUTSUCC
Pegged when a mobile-terminated call successfully arrives on the traffic channel.
CAU hard Handoff SUCCess
CAUHSUCC
Pegged when a mobile, attempting a hard handoff, successfully arrives on the
traffic channel in the target sector.
Field Results: RF-related
Network-related
Day 1: example
04/22/02 Page 58
Day 2: example
Day 3: example
Day 4: example
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.
CAU Origination ATTemptS
CAUOATTS
04/22/02 Page 59
Pegged when the CAU receives an origination message from the BTS. Test call
originations are pegged in a separate OM.
CAU PaGe RESponse
CAUPGRES
For mobile-terminated calls, attempts are recorded in CAUPGRES, which
indicates that a page response was received from a CDMA sector in response to a
page request (irrespective of whether it was in response to an initial page request
or a retry by the CM).
CAU hard Handoff ATTemptS
CAUHATTS
Pegged when the CAU receives a ReadyNewCell message from the CM,
indicating that a hard handoff attempt sequence in a (CDMA) target sector should
begin.
Field Results
Day 1: 36.56 %
Day 2: 13.33 %
Day 3: 51.95 %
Day 4: 42.23 %
04/22/02 Page 60
CAUSCT3D.MCTAHRQF
Total calls attempts for all freqs =
CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT
NOTE: CAUFRQ3D refers to the sum of the register for all frequencies on the
sector.
OMs
MCTA REQuest Failure
MCTAREQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for origination or termination call setup. It is pegged on a per-sector
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA Handoff ReQuest Failure
MCTAHRQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA ORIGination
MCTAORIG
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
MCTA PaGe RESponse
MCTAPGRES
For mobile-terminated calls, attempts are recorded in MCTPGRES, which
indicates that a page response was received from an MCTA enabled CDMA
sector in response to a page request. This OM is pegged irrespective of whether it
was the first or the second attempt to page the mobile. CAUPGRES is also pegged
whenever MCTPGRES is pegged.
MCTA Handoff Call ATTempts
MCTHCATT
04/22/02 Page 61
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin.
Field Results
Day 1: 1.98 %
Day 2: 0.98 %
Day 3: 0.72 %
Day 4: 1.03 %
04/22/02 Page 62
CAUFRQ3D.MCTHCATT
OMs
MCTA REQuest Failure
MCTAREQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for origination or termination call setup. It is pegged on a per-sector
basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA Handoff ReQuest Failure
MCTAHRQF
Pegged, along with CAUERSFL, when NO frequency was successfully selected
by MCTA for a hard handoff call setup. It is pegged on a per-sector basis on the
target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or
MCTALLFU.
MCTA REQuest response full or Not available
MCTAREQN
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs responded with a resource full or not available response. MCTAREQN
is pegged against the carrier(s) that respond with a resource full or not available
response. MCTAREQN may not always be pegged under low load conditions.
MCTA REQuest Timeout
MCTAREQT
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs never responded to a capacity request. MCTAREQT is pegged against
the carrier(s) that did not respond to the capacity request. MCTAREQT may not
always be pegged under low traffic load conditions.
MCTA ORIGination
MCTAORIG
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
MCTA PaGe RESponse
MCTAPGRES
For mobile-terminated calls, attempts are recorded in MCTPGRES, which
indicates that a page response was received from an MCTA enabled CDMA
sector in response to a page request. This OM is pegged irrespective of whether it
Sprint PCS Proprietary & Confidential
04/22/02 Page 63
was the first or the second attempt to page the mobile. CAUPGRES is also pegged
whenever MCTPGRES is pegged.
MCTA Handoff Call ATTempts
MCTHCATT
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin.
Field Results
Day 1: 0.00 %
Day 2: 0.00 %
Day 3: 0.00 %
Day 4: 0.00 %
04/22/02 Page 64
No Rsrc% = [(CAUSCT3D.MCTALLFU +
CAURFQ3D.MCTARQFN)
/
(CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT)] * 100
Case 2: Failures NOT leading to overall MCTA frequency selection failure
No Rsrc% = [CAURFQ3D.MCTAREQN
/
(CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT)] * 100
The following set of formulas deal with the percentage of MCTA frequency
resource allocation failures resulting due to time-outs before the Carrier
Determination Algorithm CDA is executed.
Resource Allocation Failures (per freq) due to time-outs:
Time Out% = [(CAUSCT3D.MCTALLTO +
(CAUSCT3D.MCTAMIXF
CAURFQ3D.MCTARQFN) +
CAUFRQ3D.MCTAREQT)
/
(CAUFRQ3D.MCTORIGS +
CAUFRQ3D.MCTPGRES +
CAUFRQ3D.MCTHCATT)] * 100
04/22/02 Page 65
OMs
MCTA REQuest response full or Not available
MCTAREQN
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs responded with a resource full or not available response. MCTAREQN
is pegged against the carrier(s) that respond with a resource full or not available
response. MCTAREQN may not always be pegged under low load conditions.
MCTA REQuest Timeout
MCTAREQT
Pegged when a frequency was successfully selected by MCTA but one or more of
the BTSs never responded to a capacity request. MCTAREQT is pegged against
the carrier(s) that did not respond to the capacity request. MCTAREQT may not
always be pegged under low traffic load conditions.
MCTA All frequencies Full
MCTALLFU
Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when
NO frequency was successfully selected by MCTA because none of the BTSs had
resources available. It is pegged on a per-sector basis.
MCTA ReQuest response Failed (full or Not available)
MCTARQFN
Pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or
MCTAHRQF), when no frequency was successfully selected by MCTA because
some BTSs timed out, while some responded with a resource full or not available
response. MCTARQFN is pegged against the carrier(s) that respond with a
resource full or not available response.
MCTA ALL frequencies Timed-Out
MCTALLTO
Pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when
NO frequency was successfully selected by MCTA because none of the BTSs
responded to the capacity request query. It is pegged on a per-sector basis.
MCTA MIXed Failure
MCTAMIXF
Pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or
MCTAHRQF), when NO frequency was successfully selected by MCTA because
some BTSs
timed-out while some responded with a resource full or not available response. It
is pegged on a per-sector basis.
MCTA ORIGination
04/22/02 Page 66
MCTORIGS
Pegged, along with CAUOATTS, when the CAU receives an origination message
from a sector that has MCTA enabled. It is pegged against the originating
frequency. Test call originations are pegged in a separate OM.
MCTA PaGe RESponse
MCTPGRES
For mobile-terminated calls, attempts are recorded in MCTPGRES, which
indicates that a page response was received from an MCTA enabled CDMA
sector in response to a page request. This OM is pegged irrespective of whether it
was the first or the second attempt to page the mobile. CAUPGRES is also pegged
whenever MCTPGRES is pegged.
MCTA Handoff Call ATTempts
MCTHCATT
Pegged, along with CAUHATTS, when the CAU receives a message from the
CM, indicating that a hard handoff attempt sequence in an MCTA enabled CDMA
target sector should begin
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 67
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
04/22/02 Page 69
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 %
04/22/02 Page 70
CAUFRQ3D.MCTERSFL
Total calls attempted =
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
OMs
MCTA Error case Radio link Setup FaiLure
MCTERSFL
Pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever
a call setup fails due to the fact that the BTS could not allocate resources due to
any of the BTS failure reasons. This OM is also pegged when the BTS does not
respond at all to resource requests. MCTERSFL is pegged only after an MCTA
frequency is selected. MCTERSFL is pegged against the selected frequency.
MCTA Origination ATTemptS
MCTOATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile origination in a sector with MCTA
enabled. Please note that the MCTA frequency for MCTOATTS may be different
from the MCTA frequency on which the call originated (MCTORIGS).
MCTA Termination ATTemptS
MCTTATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile termination in a sector with MCTA
enabled.
MCTA Handoff ATTemptS
MCTHATTS
Pegged when an MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile hard handoff attempt into a target
sector with MCTA enabled.
Field Results:
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 %
04/22/02 Page 72
CAUFRQ3D.MCTHATTS)] * 100
OMs
MCTA NO Traffic Channel Element
MCTNOTCE
Pegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element
via NOIS messages, regardless of origination, termination or hard handoff.
MCTNOTCE is pegged only after an MCTA frequency is selected.
MCTNOTCE is pegged against the selected frequency.
MCTA NO Walsh Code
MCTNOWCD
Pegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS
messages, regardless of origination, termination or hard handoff. MCTNOWCD
is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged
against the selected frequency.
MCTA NO Frame Offset
MCTNOFOF
Pegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS cannot allocate resources due to
some CSM 5000 hardware limitation. The CSM 5000 is limited in how much
traffic it can support on its reverse link because of the limitation on the number of
decoding units (both Viterbi and Turbo) that can be active on a frame offset (and
adjacent frame offsets). MCTNOFOF is pegged only after an MCTA
frequency is selected. MCTNOFOF is pegged against the selected frequency
MCTA ForWard CAPacity full
MCTFWCAP
Pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via
NOIS messages, regardless of origination, termination or hard handoff.
MCTFWCAP is pegged only after an MCTA frequency is selected.
MCTFWCAP is pegged against the selected frequency.
MCTA REverse CAPacity full
MCTRECAP
Pegged, along with MCTERSFL and CAURECAP and CAUERSFL and the
appropriate CAU*BLKS OM, any time a BTS reports reverse capacity full via
NOIS messages, regardless of origination, termination or hard handoff. However,
04/22/02 Page 73
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 74
Formula
Acc Fails% = [Number of MCTA access failures / Total calls attempted] *
100
Number of MCTA access failures =
CAURFQ3D.MCTERLFL +
CAUFRQ3D.MCTHRLFL
Total calls attempted =
CAUFRQ3D.MCTOATTS +
CAUFRQ3D.MCTTATTS +
CAUFRQ3D.MCTHATTS
OMs
MCTA Error case, Radio Link FaiLure
MCTERLFL
Pegged, along with CAUERLFL, if the origination or termination fails because
the mobile never arrived on the traffic channel (similar to SAT timeout).
MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs
are pegged.
MCTA hard Handoff Radio Link FaiLure
MCTHRLFL
Pegged, along with CAUHRLFL, if the hard handoff attempt fails because the
mobile never arrived on the target sectors traffic channel (similar to
SAT timeout). MCTHRLFL is not pegged in cases where the CAUHBLKS OM is
pegged.
MCTA Origination ATTemptS
MCTOATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile origination in a sector with MCTA
enabled. Please note that the MCTA frequency for MCTOATTS may be different
from the MCTA frequency on which the call originated (MCTORIGS).
MCTA Termination ATTemptS
MCTTATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile termination in a sector with MCTA
enabled.
MCTA Handoff ATTemptS
04/22/02 Page 75
MCTHATTS
Pegged when a MCTA frequency is successfully selected by the Carrier
Determination Algorithm (CDA) for a mobile hard handoff attempt into a target
sector with MCTA enabled.
Field Results:
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 %
04/22/02 Page 76
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 77
04/22/02 Page 78
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 %
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
(min and max will be defined where applicable)
3.2.13.2. 3G Data R-P Interface Packet Session Failures
This Formula relates to the Packet Control Unit (PCU) Managed Object at the
BSC level. This is the percentage of R-P interface packet session setup failures
including both initial and reconnect setups.
Formula
% Setup Failures = [TotalSessionSetupFailures
/
(TotalSessionSetupInitialAttempts
TotalSessionSetupReconnectAttempts)] * 100
OMs
TotalSessionSetupFailures
Number of failed packet session setups.
TotalSessionSetupInitialAttempts
Number of packet session setups attempted during initial session setup.
TotalSessionSetupReconnectAttempts
Number of packet session setups attempted when reconnecting to an existing PPP
session
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 81
NumberOfTunnelFailures
= 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
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
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
04/22/02 Page 85
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 86
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 87
Day 1: example
Day 2: example
Day 3: example
04/22/02 Page 88
Day 4: example
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 89
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 90
FSCHLinkSetupAttempts
Number of forward supplemental channel (FSCH) setup attempts
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 91
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 92
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 93
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 94
Day 1: example
Day 2: example
Day 3: example
Day 4: example
04/22/02 Page 95
RSCHLinkSetupAttempts
Number of Reverse supplemental channel (RSCH) setup attempts
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Day 1: example
Day 2: example
04/22/02 Page 96
Day 3: example
Day 4: example
Voice Blocks
Non Blocking
= ADV_SEC[110]
= (FchOriginationNonBlocking3GVoice)
= ADV_SEC[119][0]
= (BlockedFchOriginations3GVoice)
(due to no physical resources)
Block FCH No WC
= ADV_SEC[119][3]
= (BlockedFchOriginations3GVoice)
04/22/02 Page 97
= ADV_SEC[119][1]
= (BlockedFchOriginations3GVoice)
(due to no forward power)
= ADV_SEC[119][4]
= (BlockedFchOriginations3GVoice)
(due to no frame offset)
Data Blocks
Non Blocking
= ADV_SEC[111]
= (FchOriginationNonBlocking3GData)
= ADV_SEC[120][0]
= (BlockedFchOriginations3GData)
(due to no physical resources)
Block FCH No WC
= ADV_SEC[120][3]
= (BlockedFchOriginations3GData)
(due to no Walsh code)
= ADV_SEC[120][1]
= (BlockedFchOriginations3GData)
(due to no forward power)
= ADV_SEC[120][4]
= (BlockedFchOriginations3GData)
(due to no frame offset)
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
FchOriginationNonBlocking3GDowngrade2G
Number of successful BTS resource allocations for fundamental channel 2G calls
which were downgraded from 3G calls attempts. This metric does not include
non-reference pilot links setup for CASHO. 2G links, other than the reference
pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G.
FchOriginationNonBlocking3GVoice
Number of successful BTS resource allocations for 3G voice calls on the
fundamental channel. This is not an indication of successful call attempts. This
metric does not include non-reference pilot links setup for CASHO. 3G voice
links, other than the reference pilots link, setup for CASHO are pegged under
FchHandoffNonBlocking3GVoice.
BlockedFchOriginations3GVoice
04/22/02 Page 99
Array indicating the number of 3G voice call attempts blocked on the fundamental
channel. Each array element corresponds to a different blocking reason as
explained above.
FchOriginationNonBlocking3GData
Number of successful BTS resource allocations for 3G data calls on the
fundamental channel. This is not an indication of successful call attempts.
This metric does not include non-reference pilot links setup for CASHO. 3G data
links, other than the reference pilots link, setup for CASHO are pegged under
FchHandoffNonBlocking3GData.
BlockedFchOriginations3GData
Array indicating the number of 3G data sessions blocked on the fundamental
channel. Each array element corresponds to a different blocking reason as
explained above.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
Voice Blocks
Non Blocking
= ADV_SEC[113]
= (FchHandoffNonBlocking3GVoice)
= ADV_SEC[121][0]
= (BlockedFchHandoffs3GVoice)
= ADV_SEC[121][3]
= (BlockedFchHandoffs3GVoice)
(due to no Walsh code)
= ADV_SEC[121][1]
= (BlockedFchHandoffs3GVoice)
(due to no forward power)
= ADV_SEC[121][4]
= (BlockedFchHandoffs3GVoice)
(due to no frame offset)
Data Blocks
Non Blocking
= ADV_SEC[114]
= (FchHandoffNonBlocking3GData)
= ADV_SEC[122][0]
= (BlockedFchHandoffs3GData)
(due to no physical resources)
Block FCH No WC
= ADV_SEC[122][3]
= (BlockedFchHandoffs3GData)
(due to no Walsh code)
= ADV_SEC[122][1]
= (BlockedFchHandoffs3GData)
(due to no forward power)
= ADV_SEC[122][4]
= (BlockedFchHandoffs3GData)
(due to no frame offset)
Blocking Reasons
No Physical Resources
In this case, the CCEMs and XCEMs in the sector could not support additional
calls. More CCEMs or XCEMs may be needed.
No Walsh Code
Blocking occurred because all Walsh codes had been allocated. This includes
scenarios where Walsh codes are regulated by MaxVoiceResources (or voice
calls) or MaxDataResources (for data calls). If this blocking reason is consistently
higher than No forward capacity, the system may be Walsh code limited. In that
case, the operator should consider setting RC4_Preferred to increase Walsh code
availability at the expense of forward power.
No Forward Capacity
The BTS forward power level surpassed the level defined by the call blocking
threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data
calls).
No Frame Offset
The XCEM supports a fixed number of calls per frame offset. This metric
corresponds to blocks that were a result of an XCEMs inability to support the
needed frame offset. This metric is not applicable to CCEMs.
No CFDS Radio Config State
Blocking occurred because the CFDS RadioConfigState attribute is configured in
such a way that does not allow the specific type of call requested to be setup.
Reconfiguration of this attribute may be needed.
OMs
FchHandoffNonBlocking3GVoice
Number of successful BTS resource allocations for 3G voice handoffs on the
fundamental channel. Note that this is not an indication of successful handoffs.
BlockedFchHandoffs3GVoice
Array indicating the number of 3G voice handoffs blocked on the fundamental
channel. Each array element corresponds to a different blocking reason as
explained above.
FchHandoffNonBlocking3GData
Day 1: example
Day 2: example
Day 3: example
Day 4: example
The average number of all handoff links for the FCH in any sector in particular
can be expressed by the following ratio:
(FrameCntFCH / PrimaryFrameCntFCH)
OMs
FrameCntFCH
Array indicating the total number of frames sent on the forward link for every user
on the fundamental channel. Each element in the array represents one radio
configuration from RC1 through RC5. The array begins with RC1.
CEFrameCntFCH
Equivalent to FrameCntFCH with each frame being divided by the number of
softer handoff links.
PrimaryFrameCntFCH
Equivalent to FrameCntFCH with each frame being divided by the product of the
number of softer handoff links and the number of soft handoff links.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
= ADV_SEC[115]
= (SchBurstNonBlocking3G)
= ADV_SEC[123][0]
= (BlockedSchBursts)
(due to no physical resources)
Block SCH No WC
= ADV_SEC[123][3]
= (BlockedSchBursts)
(due to no Walsh code)
= ADV_SEC[123][1]
= (BlockedSchBursts)
(due to no forward power)
= ADV_SEC[123][4]
= (BlockedSchBursts)
(due to no frame offset)
= ADV_SEC[123][6]
= (BlockedSchBursts)
(due to CFDS radio config state)
Screened
= ADV_SEC[123][7]
= (BlockedSchBursts)
(due to CFDS HS RSCH)
Blocking Reasons
No Physical Resources
In this case, the CCEMs and XCEMs in the sector could not support additional
calls. More CCEMs or XCEMs may be needed.
No Walsh Code
Blocking occurred because all Walsh codes had been allocated. This includes
scenarios where Walsh codes are regulated by MaxVoiceResources (or voice
calls) or MaxDataResources (for data calls). If this blocking reason is consistently
higher than No forward capacity, the system may be Walsh code limited. In that
case, the operator should consider setting RC4_Preferred to increase Walsh code
availability at the expense of forward power.
No Forward Capacity
The BTS forward power level surpassed the level defined by the call blocking
threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data
calls).
No Frame Offset
The XCEM supports a fixed number of calls per frame offset. This metric
corresponds to blocks that were a result of an XCEMs inability to support the
needed frame offset. This metric is not applicable to CCEMs.
No CFDS Radio Config State
Blocking occurred because the CFDS RadioConfigState attribute is configured in
such a way that does not allow the specific type of call requested to be setup.
Reconfiguration of this attribute may be needed.
No CFDS HS RSCH
This element in the array is valid only for BlockedSchBursts and
BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature
attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH
bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).
Reconfiguration of this attribute may need to be considered.
OMs
SchBurstNonBlocking3G
Number of successful BTS resource allocations for 3G data bursts on the
supplemental channel. This is not an indication of successful data bursts.
BlockedSchBursts
Array indicating the number of 3G data bursts blocked on the supplemental
channel. Each array element corresponds to a different blocking reason as
explained above.
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
N/A
3.5.2.2. 3G SCH Handoff Blocks
Formulas
Non Blocking
= ADV_SEC[116]
= (SchHandoffNonBlocking3G)
= ADV_SEC[124][0]
= (BlockedSchHandoffs)
(due to no physical resources)
Block SCH No WC
= ADV_SEC[124][3]
= (BlockedSchHandoffs)
(due to no Walsh code)
= ADV_SEC[124][1]
= (BlockedSchHandoffs)
(due to no forward power)
= ADV_SEC[124][4]
= (BlockedSchHandoffs)
(due to no frame offset)
= ADV_SEC[124][6]
= (BlockedSchHandoffs)
(due to CFDS radio config state)
Screened
= ADV_SEC[124][7]
= (BlockedSchHandoffs)
(due to CFDS HS RSCH)
Blocking Reasons
No Physical Resources
In this case, the CCEMs and XCEMs in the sector could not support additional
calls. More CCEMs or XCEMs may be needed.
No Walsh Code
Blocking occurred because all Walsh codes had been allocated. This includes
scenarios where Walsh codes are regulated by MaxVoiceResources (or voice
calls) or MaxDataResources (for data calls). If this blocking reason is consistently
higher than No forward capacity, the system may be Walsh code limited. In that
case, the operator should consider setting RC4_Preferred to increase Walsh code
availability at the expense of forward power.
No Forward Capacity
The BTS forward power level surpassed the level defined by the call blocking
threshold or MaxVoiceResources (for voice calls) or MaxDataResources (for data
calls).
No Frame Offset
The XCEM supports a fixed number of calls per frame offset. This metric
corresponds to blocks that were a result of an XCEMs inability to support the
needed frame offset. This metric is not applicable to CCEMs.
No CFDS Radio Config State
Blocking occurred because the CFDS RadioConfigState attribute is configured in
such a way that does not allow the specific type of call requested to be setup.
Reconfiguration of this attribute may be needed.
No CFDS HS RSCH
This element in the array is valid only for BlockedSchBursts and
BlockedSchHandoffs. It is pegged when the EnableHSReverseSchFeature
attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH
bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed).
Reconfiguration of this attribute may need to be considered.
OMs
SchHandoffNonBlocking3G
Number of successful BTS resource allocations for 3G data handoffs on the
supplemental channel. Note that This is not an indication of successful handoffs.
BlockedSchHandoffs
Array indicating the number of 3G data handoffs blocked on the supplemental
channel. Each array element corresponds to a different blocking reason as
explained above.
Sprint PCS Proprietary & Confidential
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
can be expressed by the following ratio:
(FrameCntSCH / CEFrameCntSCH)
Average number of SCH soft handoff links (no including softer)
The average number of soft handoff links for the SCH in any sector in particular
can be expressed by the following ratio:
(CEFrameCntSCH / PrimaryFrameCntSCH)
Average number of SCH handoff links (including both soft and softer)
The average number of all handoff links for the SCH in any sector in particular
can be expressed by the following ratio:
(FrameCntSCH / PrimaryFrameCntSCH)
OMs
FrameCntSCH
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
= ADV_FA[72]
Total ForwardPhysicalResources
= ADV_FA[74]
SchMaximumForwardPhysicalResourcesUsed
= 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
Field Results
Day 1: example
Day 2: example
Day 3: example
Day 4: example
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
Date
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.
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
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.
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
Date
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
Figures 4-2A and 4-2B above show 3G voice and 3G data total blocks percentages
respectively. This data is collected from test calls performed in the Kansas City market,
specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the
blocking rate is relatively higher in the case of 3G data calls. However, this high failure rate
does not reflect a typical network behavior because: 1) the number of attempts is
significantly less for the data calls as compared to the voice call attempts. 2) Approximately
90% of data calls were attempted from only two sectors out of a total of about 90 sectors.
The total number of call blocks or call setup failures is calculated by adding the following
OMs counts:
CAUOBLKS + CAUTBLKS + CAUHBLKS
For a more detailed analysis, we can break this information down into specific areas, as
follows:
4.2.1. Blocking due to lack of BTS channel elements: (CAUNOTCE)
A higher count on this peg reflects that blocking due to lack of BTS channel
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
codes. NOTE: It is possible that more than one carrier is facing the Walsh codes
limitation.
Recommendations:
Addition of a new site is recommended once the Walsh codes have reached the
limit.
NOTE: Data users with higher traffic rates would be the major contributors for
such failures.
4.2.3. Blocking due to lack of forward capacity: (CAUFWCAP)
A higher count on this peg reflects that the sector is running out of capacity on the
forward link.
The next step would be go to the MCTA report and figure out which carrier(s) on
this sector is running out of forward capacity. To do this, we will check the count
for MCTFWCAP for all carriers, and identify the carrier(s) that is lacking forward
capacity. NOTE: It is possible that more than one carrier is facing the forward
capacity limitation.
Recommendations:
Deployment of an additional carrier is recommended for such blocks.
If adding a carrier is not an option then additional site would be required.
reverse link.
The next step would be go to the MCTA report and figure out which carrier(s) on
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
sector.
The next step would be go to the MCTA report and figure out which carrier(s) on
this sector has no frame offset availability. To do this, we will check the count for
MCTNOFOF for all carriers, and identify the carrier(s) that has no frame 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.
4.3. Drops
The percentage of total drops is expressed by the following relation:
Drop Call% = [Number of drop calls / Number of successful calls] * 100
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
Date
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
respectively. This data is collected from test calls performed in the Kansas City market,
specifically the K1B1 and K2B2 test clusters that include 30 sites. Please note that the call
drop rate is relatively higher in the case of 3G data calls. However, this high failure rate
does not reflect a typical network behavior because: 1) the number of attempts is
Sprint PCS Proprietary & Confidential
significantly less for the data calls as compared to the voice call attempts. 2) Approximately
90% of data calls were attempted from only two sectors out of a total of about 90 sectors.
The total number of call drops is calculated by adding the following OMs counts:
CAUDROPR + CAUDROPN
For a more detailed analysis, we can break this information down into specific areas, as
follows:
4.3.1. Drops due to RF-related reasons: (CAUDROPR)
A higher count on this peg reflects that the number of calls dropped due to loss of
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.
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.
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 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.
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAU Origination
ATTemptS
CAU Origination
SUCCess
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
CAUERSFL Pegged, along with the appropriate CAU*BLKS OM, MSC V+D perwhenever a call setup fails due to the fact that some
sector
BTS resource is not available. This OM is also
basis
pegged when the BTS does not respond to resource
requests. It is also pegged when the Carrier
Determination Algorithm (CDA) fails to select a
carrier in an MCTA enabled sector (that is, no
available capacity on all co-located carriers).
Pegged 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.
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
CAU hard
CAUHBLKS Pegged any time a CDMA-to-CDMA hard handoff
MSC V+D perHandoff BLocKS
setup fails due to resource shortage. It represents all
sector
of the hard handoff setup failures into a sector,
basis
regardless of resource. This OM is pegged for both
inter- and intra-system hard handoff attempts.
CAUHBLKS is not the number of dropped hard
handoffs, it merely represents the number of times
that a hard handoff could not be completed due to
resource shortages in the target cell/sectorthe call
in the source cell is still up. The same failure
reasons that are pegged for CAUOBLKS (see
previous page) can be pegged in conjunction with
CAUHBLKS.
CAU hard
Handoff
SUCCess
CAU hard
Handoff
ReLeaSed
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
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
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
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
termination or hard handoff.
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
origination, termination or hard handoff.
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
MCTA REQuest
Failure
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.
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
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
MSC V+D perfreq
basis
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
MCTA
Termination
SUCCess
MCTTSUCC Pegged, along with CAUTSUCC, when a mobileterminated call successfully arrives on the traffic
channel.
MCTA Handoff
Call ATTempts
MCTA Handoff
ATTemptS
MCTA Hardhandoff
SUCCess
MCTA Handoff
Radio Link
FaiLure
OM Register
(Name)
Description
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
and CAUERSFL and the appropriate CAU*BLKS
freq
OM, any time a BTS reports no walsh code via NOIS
basis
messages, regardless of origination, termination or
hard handoff. MCTNOWCD is pegged only after an
MCTA frequency is selected.
MCTNOWCD is pegged against the selected
frequency.
MCTA NO Frame MCTNOFOF Pegged, along with MCTERSFL and CAUNOFOF
MSC V+D perOFfset
and CAUERSFL and the appropriate CAU*BLKS
freq
OM, any time a BTS cannot allocate resources due
basis
to some CSM 5000 hardware limitation. The CSM
5000 is limited in how much traffic it can support on
its reverse link because of the limitation on the
number of decoding units (both Viterbi and Turbo)
that can be active on a frame offset (and adjacent
frame offsets). MCTNOFOF is pegged only after an
MCTA frequency is selected. MCTNOFOF is pegged
against the selected frequency
MCTA ForWard
CAPacity full
MCTA REverse
CAPacity full
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)
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
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
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
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 fails to allocate resources for MSC V+D pera 3G Voice call based on a resource request from
RMU
CAU.
basis
SUCcess for
153K data rate
data-call
SUC153K
Pegged when the RMU fails to allocate resources for MSC V+D pera 153K data rate data-call attempt based on a
RMU
resource request from CAU.
basis
Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 76K data rate data-call
RMU
attempt based on a resource request from CAU.
basis
Note that rate data-call attempt based on a resource
request from CAU. Note that REQ76K counts
include downgraded attempts from 153K to 76K due
to no resources available for the 153K attempts. The
downgraded attempts (from 153K to 76K) count is
equal to NORS153K.
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Pegged when the RMU fails to allocate resources for MSC V+D pera 76K data rate data-call attempt based on a
RMU
resource request from CAU.
basis
Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 38K data rate data-call
RMU
attempt based on a resource request from CAU.
basis
Note that internally, the RMU does not make a
distinction between the 38K and the 76K data rates,
and therefore a 76K data rate call attempt can never
be downgraded to a 38K data rate call attempt. Thus
REQ38K counts do not include any downgraded
attempts from a higher data rate to 38K data rate.
Pegged when the RMU fails to allocate resources for MSC V+D pera 38K data rate data-call attempt based on a
RMU
resource request from the CAU.
basis
Pegged when there is an attempt made by the RMU MSC V+D perto allocate resources for a 19K data rate data-call
RMU
attempt based on a resource request from the CAU.
basis
Note that REQ19K counts include downgraded
attempts from 76K to 19K and downgraded attempts
from 38K to 19K due to no resources available for
the 76K and 38K data rates attempts. The
downgraded attempts (from 76K to 19K) count is
equal to NORS76K and the downgraded attempts
(from 38K to 19K) count is equal to NORS38K.
Pegged when the RMU fails to allocate resources for MSC V+D pera 19K data rate data-call attempt based on a
RMU
resource request from the CAU.
basis
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
syste
mwide
basis
Mobile-Initiated
Dormant To
Active FaiLures
MIDTOAFL
syste
mwide
basis
Network-Initiated NIDTOAAT
Dormant To
Active ATtempts
MSC D
syste
mwide
basis
Network-Initiated NIDTOASU
Dormant To
Active SUccess
syste
mwide
basis
Network-Initiated NIDTOAFL
Dormant To
Active FaiLures
syste
mwide
basis
OM Register
(Name)
ATINPPP
Description
MSC
/ BSC V/D Basis
/ BTS
perRMU
basis
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
SUccessful
resource
allocation for
CDMA2000
INternet PPP
Data service
option
SUINPPP
perRMU
basis
HCINPPP
perRMU
basis
Resource
allocation
FaiLures for
CDMA2000
INternet PPP
Data service
option
FLINPPP
perRMU
basis
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
pegge
d by
the
RMU
SRM Time-Out
SRMTO3D
for 3G Data calls
pegge
d by
the
RMU
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
pegge
d by
the
RMU
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Network-Initiated NISDBATT
Short Data Burst
ATTempts
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
MSC V+D
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
Description
Reliable Packet
Sent Success
BSC
pernode
basis
Reliable Packet
ReTransmitted
pernode
basis
Reliable Packet
Received
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
BSC
pernode
basis
Total Unreliable
Bytes Received
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
Description
DCR Buffer
Overflows
BSC
percall
basis
RR Buffer
Overflows
BSC
percall
basis
Total Session
Setup Initial
Attempts
BSC
percall
basis
BSC
percall
basis
Total Session
Setup Success
percall
basis
Total Session
Setup Failures
BSC
percall
basis
Reliable Packet
Sent Success
Overflow
BSC
pernode
basis
Reliable Packet
ReTransmitted
Overflow
BSC
pernode
basis
Reliable Packet
Received
Overflow
BSC
pernode
basis
Total Unreliable
Bytes
Transmitted
Overflow
BSC
pernode
basis
Total Unreliable
Bytes Received
Overflow
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
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
RLP Setup
Attempts
BSC
RLP
perfor
manc
e
RLP Setup
Successes
BSC
RLP
perfor
manc
e
RLP Setup
Failures
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
BSC
data
sessi
on
setup
BSC
data
sessi
on
setup
OM Register
(Name)
Description
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
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
BSC
SCH
setup
FSCH CFDS
Radio Config
BSC
SCH
setup
FSCH Timeout
SCH
setup
BSC
SCH
setup
SCH
setup
RSCH Link
Downgrade
SCH
setup
BSC
OM Register
(Name)
Description
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
BSC
SCH
setup
RSCH CFDS
Radio Config
BSC
SCH
setup
RSCH CFDS
High Speed
BSC
SCH
setup
RSCH Timeout
SCH
setup
SCHDrop
SCHDrop
SCH
setup
BSC
OM Register
(Name)
Description
MSC
/ BSC V/D Basis
/ BTS
Paging Channel
Message Count
BTS
V+D perBTS
basis
Paging Channel
Messages
Dropped
BTS
V+D perBTS
basis
Description
Num Of TC
Available
BTS
V+D
TCE Util
Maximum
BTS
V+D perfreq
basis
Total Forward
Physical
Resources
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
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
SchReverse
PhysicalRes
ourceReserv
ed
Description
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
BTS
V+D perfreq
basis
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
persector
basis
Description
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
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
Description
persector
basis
BTS
persector
basis
Fch Origination
FchOriginati Number of successful BTS resource allocations for
Non Blocking 3G onNonBlocki 3G data calls on the fundamental channel. This is
Data
ng3GData
not an indication of successful call attempts.
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
that This is not an indication of successful handoffs.
persector
basis
persector
basis
Description
Sch Handoff Non SchHandoff Number of successful BTS resource allocations for BTS
Blocking 3G
NonBlocking 3G data handoffs on the supplemental channel. Note
3G
that This is not an indication of successful handoffs.
persector
basis
Blocked Fch
Originations 2G
persector
basis
Blocked Fch
Handoffs 2G
persector
basis
Blocked Fch
Originations 3G
Voice
persector
basis
Blocked Fch
Originations 3G
Data
persector
basis
Blocked Fch
Handoffs 3G
Voice
persector
basis
Blocked Fch
Handoffs 3G
Data
persector
basis
Blocked Sch
Bursts
persector
basis
Blocked Sch
Handoffs
persector
basis
BTS
V+D persector
basis
BTS
CE Frame Cnt
FCH
BTS
V+D persector
basis
persector
basis
Description
CE Frame Cnt
SCH
BTS
Primary Frame
Cnt FCH
BTS
V+D persector
basis
Primary Frame
SCH
BTS
persector
basis
persector
basis
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.
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
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.
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
Paging Channel
Peak Paging Channel Occupancy
L L
L L
S S
L
S
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
S S
L L
Registrations
Time Based Registration
Zone Based Registration
Distance Based Registration
Power Up Registration
L L
MM
L L
MM
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
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
L L
S S
L
S
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
L
L
M
L
M L
N
N
N
s
L L
L
L
M
L
M L
N
N
N
s
L L
M
N
N
MM
S S
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
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
MM
S S
MM
IS-95B Features
Access Handoff
Access Handoff Original Sector
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
L L
CAMSHO Denied
L L
L L
L L
L L
L L
L L
L
L
MM M
M
M
N N
N
L
L
M
Soft Handoff
Soft Handoff Request
L
L
L
M
L
M
M
S
L
L
L
M
L
M
M
S
L
L
L
M
L
M
M
S
L
N
N
N N
MM
N N
S S
S
N
N M
Hard Handoff
Hard Handoff Request
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
MMM
MMM
ML
Soft Handoff
M
N
M
M
N
N M
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
Hard Handoff Request
m
l
m
l
m
l
L L
N N
L
N
L L
L L
L L
N N
L
N
L L
N N
N
N
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
L
M
L
M
L
M
M
M
S
N
N
M
N
M
N
N
l
m
l
m
l
m
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
N
N
M
N
MM
L L L L
M
M
S
N
N
M
N
L L
L
L
MM M
M
M
N N
N
L
M
L
M
Soft Handoff
Soft Handoff Request
Soft Handoff Denied
Soft Handoff Failure
M
S
M
S
MM
N N
N N
N N
Hard Handoff
Hard Handoff Request
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
N
M
N
M
Peak Duration
N
M
Average Duration
N
M
Buffer Overflow
L
M
L
N
L
M
NM
m
L
M
M
N
N
M
N
L
M
M
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
L
N
L
N
L
M
S
L
L
M
N
M
L L
L L
MM
L
M
Data Throughput
Forward Link Peak Data Throughput
N
l
m
s
Packet Success
Packet Submits
L
N
m
s
L
N
l
m
s
l
m
s
N
l
m
s
m
s
N
l
m
s
N
l
m
s
N
l
m
s
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
N
l
m
s
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
L
M
N
l
m
s
l
m
s
l
m
s
l
m
s
l
m
s
s
N
m
s
RRBuffer Overflows
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
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
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