CDMA Ebook

411-2133-004
CDMA
CDMA
RF Optimization Guide
NBSS 10.1 Standard 03.01 December 2001

test
CDMA
CDMA
Document number: 411-2133-004

Product release: NBSS 10.1
Document version: Standard 03.01
Date: December 2001
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright  1996–2001 Nortel Networks, All Rights Reserved

Printed in the United States of America
NORTEL NETWORKS CONFIDENTIAL
The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees
with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree
of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in
writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
* Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are
trademarks of Nortel Networks. Planet is a Trademark of Mobile Systems International (MSI)Surveyor is a Trademark of Grayson
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
iv Nortel Networks Confidential
411-2133-004 Standard 03.01 December 2001

Nortel Networks Confidential v
Publication history
December 2001
Issue 03.01, Standard Release NBSS 10.1
January 2001
Issue no. 02.01.
Updated to new NBSS 9.0 Software revision
July 2000
Issue no. 01.03
NBSS 8.1 standard release
December 1999
Issue no. 01.02
NBSS 8.1 preliminary release
September 1999
Issue no. 01.01
NBSS 8.2 preliminary release
August 1999
Issue no. 01.00
Initial Release
April 1999
Draft Version
Initial release for technical review
CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

vi Publication history Nortel Networks Confidential

vii
Contents 1
About this document xi
Audience for this document xi
Related documents xi
Chapter 1
Optimization Overview and Procedures 1-1
Optimization Overview 1-1
CDMA Power Control Principles 1-2
Traffic Management 1-2
Quick Paging 1-3
Intelligent Paging Planning 1-4
3G-2G Voice Hard Handoff 1-4
1xRTT Link Budget 1-4
1xRTT RC3 Reverse Link RF Performance 1-4
BTS Forward Power Budget Worksheet 1-5
1xRTT Radio Resource Manager 1-5
1xRTT Data 1-5
Optimization Overview (cont) 1-6
Stages of Optimization 1-6
Pre-Commercial 1-6
Commercial Launch 1-7
System Growth and Maturation 1-7
Optimization Procedures 1-8
Entrance Criteria 1-8
Pre-Commercial 1-9
From Commercial Launch to Maturation 1-10
Exit Criteria 1-11
Chapter 2
Initial System Parameters 2-1
New Features Relevant to RF Optimization 2-1
Access Robustness Package 2-1
Intelligent Paging 2-3
Overhead Channel Manager (OCM) Paging Congestion Control 2-5
BTS No Call Processing Alarm Management 2-5
Intelligent Voice Services Negotiation (IVSN) 2-6
Cell ID Expansion, InterSystemCellId 2-7

viii Contents
Types of RF Optimization Parameters 2-7

IS-95/J-STD-008/IS 20000 as compared to Nortel Specific 2-7
Global Parameters as compared to Sector Specific Parameters 2-7
BTS and BSC Datafill Parameters 2-8
Access Mode of Parameters (C, G, S) 2-9
Values in Datafill Tables in this Document 2-10
BSC static datafill 2-10
SelectorBank Subsystem Managed Object (SBS MO) 2-10
Page Zone Table 2-27
Packet Control Unit (PCU) Managed Object (MO) 2-28
BTS static datafill 2-35
Sector (Legacy) and Advanced Sector (MetroCell) Managed Object 2-41
Chapter 3
Data Collection 3-1
RF Performance Indicators 3-1
Frame Error Rate 3-1
Mobile Receive Power 3-1
Pilot Strength (Ec/Io) 3-1
Handset Transmit Power (TXPO) 3-2
Transmit Gain Adjust 3-2
Ew/No Setpoint 3-2
Data Collection Tools 3-2
Simulated Loading 3-3
Forward Link 3-3
Reverse Link 3-8
Drive Testing and SBS Logging 3-9
Drive Testing 3-9
Test Van RF Configuration 3-10
Shakedown 3-10
Drive Routes 3-11
Test Calls 3-12
Mobile Log Mask 3-12
SBS Logging 3-15
Selector Log Mask 3-15
3-16
3-17
Loading Conditional Mobiles in to MTX ICC Tool 3-17
Conditional and Unconditional SBS Logging of Active Users 3-18
Conditional Logging Procedure 3-19
Starting and Suspending the SBS Logs 3-22
BSM Logging Procedure using GUI 3-25
SBS Logfile Format Conversion to ASCII Text File 3-27
Data Management 3-29
BTS Performance Logging 3-29
Advanced Sector MO 3-38
BTS Call Processing MO 3-46
3-46
Power Management MO 3-46
Radio Sector MO 3-47

Contents ix
Advanced FA (Frequency Assignment) MO 3-48

CDSU T1 Port MO 3-48
CEM MO 3-49
MTX Track 3-50
Appendix to Section 3 - Data Collection 3-50
Example of Metrocell parsed BTS Performance Log before filtering: 3-50
Example of partial Metrocell parsed BTS Performance Log after Filtering: 3-70
Chapter 4
Data Analysis Procedures 4-1
Nortel Networks RF Optimizer 4-1
Input Files 4-1
System Level Analysis (Macro) 4-1
File Level Analysis (Micro) 4-3
Datafill Audit and Shakedown 4-4
Datafill Audit 4-4
Shakedown Data Analysis 4-4
System Access 4-4
Access Failure Analysis 4-4
Access Success Rate 4-5
Access Parameter Tuning 4-6
Dropped Calls 4-6
Link Supervision 4-6
Analysis 4-6
Dropped Call Rate 4-7
RF Coverage and Handoff Control 4-8
Soft Handoff Reduction 4-11
Search Windows 4-14
SRCH_WIN_A 4-16
SRCH_WIN_N 4-18
SRCH_WIN_R 4-18
BTS AccessChannelDemodulationSearchWidth,
TrafficChannelDemodulationSearchWidth 4-19
Neighbor Lists 4-19
Performance/Trend Analysis 4-22
Per-Site Analysis 4-23
Capacity 4-24
Capacity Equations for the Reverse Link 4-25
Capacity Equations for the Forward Link 4-27
Optimizing for Forward Link Capacity 4-29
Hard Handoff (HHO) 4-30
Inter-Frequency HHO 4-31
Inter-Frequency Band HHO 4-31
Inter-System/Inter-BSC HHO and Inter-System SHO 4-31
CDMA-AMPS HHO 4-31
HHO Triggers 4-32
HHO Optimization 4-37
HHO Interaction with Traffic Distribution 4-40
Chapter 5 - Dropped Call and Access Failure Reasons and

x Contents
Solutions 5-1
Successful Call 5-1
Indications in Mobile Data 5-1
Analysis with Selector Logs 5-2
Access Failures and Dropped Call Reasons in Single Frequency System 5-5
Hard Handoff 5-8
External Interference 5-12
Indications in Mobile Data 5-12
Appendix A- QCP Tech Mode Screen A-1

Handset Monitor Mode A-1
Appendix B- Calculating Required Power Reduction for Unwanted

PN B-1
List of figures
Figure 2-1 Flexible Power Control Array 2-11
Figure 2-2 New Managed Object Relationships for NBSS 10.1 2-35
Figure 4-1 Neighbor List Tuning 4-20
Figure 4-2 Neighbor List example 4-22
Figure 5-1Messaging Example of Successful Call 5-3
List of tables
Table 2-1 Possible Service Redirections 2-6
Table 2-2 Old (prior to NBSS 9.0) 16 bit InterSystemCellId 2-7
Table 2-3 New NBSS 9.0 and 10.1 InterSystemCellId 2-7
Table 2-4 SelectorSubSystem MO parameters (Legacy and MetroCell
products) 2-12
Table 2-5 Relationship between FPC Parameters and RC 2-26
Table 2-7 Packet Control Unit (PCU) MO 2-28
Table 2-6 Intelligent Zone Paging - Page Zone Table MO 2-28
Table 2-8 Pilot Database MO Parameters (Legacy and MetroCell products) 2-29
Table 2-9 BTSC MO (Legacy), BTSCallProcessing MO (MetroCell), and FA MO
parameters 2-36
Table 2-10 Sector MO (Legacy) and Advanced Sector MO (MetroCell)
Parameters 2-41
Table 2-11 Radio Sector Managed Object 2-49
Table 2-12 TCC/RFU MO (Legacy) and PowerManagement MO (MetroCell)
parameters 2-52
Table 3-1 Metrocell 800MHz and System Information 3-6
Table 3-2 Capacity Assumptions from Field Trials 3-6
Table 3-4 3-7
Table 3-3 Traffic Power per Link 3-7
Table 3-5 Calculation of required OCNS power 3-8
Table 3-6 OCNS power based on entered parameters 3-8
Table 3-7 Attenuation Calculation 3-10
Table 3-8 Mobile Log Mask 3-13
Table 3-9 SBS Loggable Attributes for NBSS 10.1, suggested for

Contents xi
Optimization 3-15
Table 3-10 Call/handoff counts and resource blocking 3-38
Table 3-11 Traffic, throughput and handoff 3-41
Table 3-12 Digital power utilization 3-44
Table 3-13 Paging channel at CEM 3-46
Table 4-1 Acceptable Search Window Combinations 4-15
Table 4-2 Window Size Datafill 4-15
Table 4-3 Histogram Example 4-16
Table 4-4 Neighbor List Tuning Array Example 4-19
Table 4-5 Transmit Gain Adjust Analysis 4-23
Table 5-1 Access Failures 5-5
Table 5-2 Dropped Calls 5-6

xii Contents

xi
About this document 1

This document provides technical reference material to aid in the RF
optimization of Nortel Networks 2G and 3G CDMA wireless systems. It is
not all inclusive and it should not be inferred that the information contained
will produce desired results in all cases. However, it does describe the use of
diagnostic tools and established optimization methods that have been
developed and employed by Nortel Networks engineers and technicians.
Audience for this document

The intended audience for this document are RF engineers and technicians
that are responsible for optimizing new or existing Nortel Networks CDMA
wireless systems.
Related documents
List of other Nortel Networks NTPs related to this document:
• NTP 411-2133-009, CDMA Traffic and Capacity Engineering Guidelines

• NTP 411-2133-506, CDMA Metro Cell System and RF Datafill
• NTP 411-2133-510, 3G Datafill Guide
• NTP 411-2133-130, CDMA MTX Planning Guide
• NTP 411-2133-199, CDMA NBSS 10.1 Delta (vol 1-4)
• NTP 411-2133-320, 3G Operational Measurements
• NTP 411-2133-535, CDMA Operational Measurements
• NTP 411-2133-810, CDMA Logging Guide
• NTP 411-2133-310, CDMA Configuration Management Guide
• NTP 411-2133-101, BSC Theory of Operations
• NTP 411-2133-008, Metro Cell Carrier Growth (vol 1 and 2)

xii About this document

1-1
Chapter 1
Optimization Overview and Procedures1
Optimization Overview
With the advent of new 3rd Generation (3G) networks, more and more
emphasis will be placed on the availability and reliability of wide bandwidth
channels for subscriber packet data transfer in addition to the more familiar
voice and circuit-switched data in current use. CDMA offers an excellent
medium for these applications but to fully realize the benefits spread
spectrum communications offers, particular care must be taken and resources
allocated during the critical ‘optimization stages’ of the network deployment.
One of the most critical elements of this optimization is the control and as
much as possible, containment of RF energy, since CDMA is, in itself, a self-
interfering communications medium. Significant improvements can be made
to the network early on by careful selection of antenna types, antenna heights,
azimuths and downtilts, all in an effort to control and contain the interference.
Also in significant traffic areas, every attempt should be made to create a
dominant server environment which will aid in the accesses of mobiles in to
the network as well as improve the capacity.
An interesting perspective on 2G vs 3G optimization is emerging from Nortel

field trial experiences. Most of the common optimization exercises currently
performed on 2G networks will contribute very effectively to the overall
availability and reliability of the wide bandwidth services planned for the 3G
networks. In short, if the networks are optimized for 2G voice applications
and particular attention is paid to the ‘physical’ optimization described above
then 3G migration becomes an equipment and datafill exercise, since the RF
‘channel’ is already optimized as much as can be realized from the 2G
exercises.
In an effort to reduce the amount of duplicated information, there are several

companion documents to be used as references during optimization. These
are listed below:
• NTP 411-2133-009, CDMA Traffic and Capacity Engineering Guidelines

1-2 Chapter 1 Optimization Overview and Procedures
• NTP 411-2133-506, CDMA Metro Cell System and RF Datafill

• NTP 411-2133-510, 3G Datafill Guide
• NTP 411-2133-130, CDMA MTX Planning Guide
• NTP 411-2133-199, CDMA NBSS 10.1 Delta (vol 1-4)
• NTP 411-2133-320, 3G Operational Measurements
• NTP 411-2133-535, CDMA Operational Measurements
• NTP 411-2133-810, CDMA Logging Guide
• NTP 411-2133-310, CDMA Configuration Management Guide
• NTP 411-2133-101, BSC Theory of Operations
• NTP 411-2133-008, Metro Cell Carrier Growth (vol 1 and 2)
Note: In addition to these NTPs (available on Helmsman) are several
new and very informative publications from Wireless Network
Engineering. Refer to the following summaries. These documents are
available from Nortel Customer Engineering. Please contact your Nortel
representative.
CDMA Power Control Principles

Nortel Network's 1xRTT CDMA system supports Radio Configurations (RC)
1 - 5 for voice services. RC1 is backwards compatible with IS95 Rate Set 1
and RC2 is backwards compatible with Rate Set 2. Power control for RC1/2
operates in the same manner as power control for Rate Set 1, Rate Set 2
respectively. RC3, RC4, RC5 introduce Fast Forward Power Control (FFPC).
FFPC operates at 800 Hz. The goal of FFPC is to track slow fading better
than slow power control of IS95 to reduce the overall forward gain required
to meet the FER target. The 1xRTT mobile is responsible for maintaining the
Eb/Nt set point to ensure the target FER is achieved. Forward maximum,
minimum and initial gains are datafilled via the BSSM to set the range of
power allocated to each user.
Document: CDMA Power Control Principles
Traffic Management
In IS-95 networks, traffic can be balanced across the carriers when the
mobiles are either in idle mode or during call setup. Idle-mode traffic
balancing can be achieved either using IS-95 GlobalServiceRedirection or
CDMAChannelList in conjunction with Hashing function at the mobile
station. Traffic balancing during call setup can be done using Nortel
Networks Multi-Carrier Traffic Allocation (MCTA) feature.
The traffic management has being expanded in IS-2000 (or 1xRTT)

networks. The IS-2000 standard supports 2G and 3G mobiles distribution
among the 2G and/or 3G capable carriers in either system acquisition stage
using IS-2000 Sync channel message or idle stage using IS-2000

GlobalServiceRedirection/Extended GlobalServiceRedirection or
CDMAChannelList/Extended CDMAChannelList. For the traffic
management during the calls setup, Nortel Networks MCTA feature supports
not only 2G/3G voice or 2G circuit-switch data calls traffic balancing among
voice services capable carriers but also intelligently managing the 3G data
calls traffic balancing among data services capable carriers.
This document’s purpose is to discuss several different methods of traffic
management for multi-carrier CDMA systems. The advantages, applications
and limitations of each method are discussed. Deployment recommendations
and possible uses of each method are provided. Finally, the RF capacity of all
methods is discussed and the impact of paging on air-interface capacity is
quantified.
Document: MCTA Gain for Data Calls
For IS-95, we already know how much Erlang gain can be obtained from
MCTA. From this information, we were able to determine through
simulations and measurements a theoretical estimate of the MCTA Erlang
gain that can be obtained for 1xRTT data calls. This document discusses how
much MCTA Erlang gain can be theoretically provided for 1xRTT data calls.
(Not currently available)
Document: 1xRTT Carrier Configuration Implementation
The Nortel Networks IS2000 CDMA network allows multiple RF carriers to
be configured for wireless services. Each carrier can be independently
configured to support a variety of services. Allowed services include 2G
voice or data calls (IS95 based), 3G voice or data calls (IS2000 based), or a
mix of 2G and 3G services.
Document: 1xRTT Traffic Management Implementation
In addition, traffic management accounts for the 2G and 3G services provided
for by the 1xRTT carrier; whether using MCTA, carrier hashing or global
service redirection.
Quick Paging
To extend a mobile's battery life the Quick Paging Channel (QPCH) was
introduced in the IS2000 standard. The QPCH enables the mobile to spend
more time in the "sleep" mode while idle. The mobile monitors the QPCH to
determine the need to transition to the paging channel to receive mobile
bound messages. The time needed for the mobile to monitor the QPCH to
determine the need for the transition is very short. If the mobile determines
there is no need to transition to the paging channel, the mobile goes back to
"sleep" until it is time to monitor the QPCH again. QPCH is an uncoded ,
spread, and On-Off-Keying (OOK) modulated spread spectrum signal sent by
a base station to inform mobile stations operating in the slotted mode during
the idle state whether to receive the Forward Common Control Channel or the
Paging Channel starting in the next Forward Common Control Channel or
Paging Channel Frame. The following documents are available on QPCH:
Document: 1xRTT QPCH Application
Document: 1xRTT QPCH Implementation

Intelligent Paging Planning

Because of the increased voice capacity of the 1xRTT CDMA system the
paging channel will be required to carry more messaging. If the increased
messaging leads to an overload condition, Intelligent Paging (Zone &
Frequency based) will enable the operator to better manage paging resources.
Document: 1xRTT Intelligent Paging Configuration is available. Please
also see NTP 411-2133-907, Paging Zone Configuration Users Guide, NBSS
9.0 v1.01 for a detailed description of Intelligent Paging.
3G-2G Voice Hard Handoff

Until 1xRTT voice service becomes ubiquitous it will be necessary to
transition the 1xRTT voice call to an IS95 voice call at the edge of 1xRTT
coverage to maintain the voice call. The Nortel Network's 1xRTT CDMA
system provides this functionality via 3G-2G Hard Handoffs.
Document: 1xRTT 3G-2G Voice Hard Handoff Implementation
1xRTT Link Budget

The 1xRTT link budget format and procedure for calculating it is very similar
to the IS-95 link budget. Only the numerical values for the receiver sensitivity
are different since power control, signal modulation and coding schemes are
different from those implemented in IS-95. As a result of these changes in the
physical layer, the Eb/No required to achieve a desired quality of service
(e.g., 2% FER) has changed. Also, since 1xRTT introduces data services with
different data rate, the processing gain is different from IS-95 and decreases
as data rate increases.
Document: 1xRTT Link Budget.
1xRTT RC3 Reverse Link RF Performance

Recent drive test measurements from 1xRTT tech trial showed that RC3
delivers coverage performance consistent with previous expectations based
on simulations and lab measurements. The 2.5 dB net coverage gain over
RC1 seems to be attainable in almost all scenarios. This means that RC3
voice should overlay RC1 without a problem. We also observed that eighth
rate performance in RC3 has a noticeable (perhaps unexpected) improvement
in Eb/No over RC1 as compared to full rate. This is apparently due to symbol
repetition and interleaving effect inherent in RC3 eighth rate. This has the
effect of offsetting the huge overhead power being allocated to pilot during
this rate. In other words, the net effect of coherent detection during eighth rate
is about a wash when overhead power is factored out, but full rate has 2 to 4
dB gain over RC1 due to smaller pilot to traffic ratio during this rate.
An attempt was made to optimize the setting of the pilot to traffic ratio. We
found that the suggested value (by Qualcomm and the standards) provided the
best results for the couple of settings we tried in the field. We note that these
results will still be considered preliminary. The reason for that is we
estimated the reverse link performance from a one-mobile test. We are now

aiming at estimating the coverage and capacity performance in a more real-

world environment, where 40 or so calls will be activated to allow measuring
the noise rise in RC1 and RC3 and then comparing them.
Document: 1xRTT RC3 Reverse Link RF Performance
BTS Forward Power Budget Worksheet

Optimizing the BTS forward power is critical to the successful operation of a
CDMA network. The BTSfwdpowerbudget worksheet is a tool used to aid in
the understanding of the effects of changing overhead gains, call blocking,
etc. on the available power for voice traffic. All Nortel BTS products are
included in the worksheet to help in determining proper datafill values.
Worksheet: BTSfwdpowerbudget10.1_1xRTT
Document: BTS Fwd Power Budget Worksheet Explanation Guide
1xRTT Radio Resource Manager

The Nortel Networks IS2000 CDMA network allows multiple RF carriers to
be configured for wireless services. Each carrier can be independently
configured to support a variety of services i.e. IS95 (2G) voice or data calls,
IS2000 (3G) voice or data calls, or a mix of 2G and 3G services. A carrier
may be configured to simultaneously allow both voice (2G/3G) and packet
switched data calls (3G). The Radio Resource Manager Application Guide
relates to the management of shared resources between voice and data
services when in "Mixed and RRM" carrier configuration mode.
Radio resource management (RRM) concerns the management of network
resources: RF power, and Walsh codes. Effective RRM enhances the system
capacity and throughput, while meeting the goal of desired quality of service
(QoS). RRM is an important component of the system design for mixed
voice and data carriers.
Document: 1xRTT RRM Implementation Guide addresses the allocation
of shared resources on a mixed voice and data carrier. Also this document
will discuss how to datafill the basic RRM feature. A method to verify the
configuration is also included.
1xRTT Data
Document: 1xRTT Data Throughput Performance discusses the issues
related to the data performance of the 1xRTT system. It will look and briefly
discuss the behavioral characteristics of the Transport Control Protocol (TCP)
over IS-2000 links and methods to improving data throughput. This document
also deals with the issues related to short and long dormant to active
transitions.
Document: 1xRTT Throughput Determination
The Nortel Networks' IS2000 CDMA network (1xRTT) was developed to
provide increased voice capacity and packet switched data (PSD) for a
cellular network. The 1xRTT Throughput Determination document provides
a high-level description of the procedures for performing 1xRTT CDMA data
throughput testing. It defines the performance metrics for data services that

require field assessment and provides methods for calculating these metrics.
The methods & procedures describe in this document were used during the
Nortel Networks' technical trials conducted to test PSD. These methods &
procedures can be applied for acceptance testing of customer networks.
Document: Data Call Resources Presentation, is a presentation of the
resources involved with setting up data call, which includes elements of the
PDSN, MTX, SBS and BTS. This presentation includes what are the required
resources needed to establish different types of data calls.
Optimization Overview (cont)

RF optimization is the process of engineering a wireless network to reach a
pre-defined level of performance and maintain this level as the system
matures. There is no “right way” of performing RF optimization. There are,
however time tested methods that help the engineer in improving their
network.
There are three primary reasons for optimizing a network. All are related and
as one aspect changes, this change has an effect on others. These reasons
include the following:
Improve Call Performance - This aspect includes reducing dropped calls

while increasing access completion rates.
Handoff Control - This aspect includes making sure enough handoff exists
to take advantage of soft handoff gain, without using excess capacity. This
aspect also includes setting hard hand-off boundaries as to minimize dropped
calls.
Efficient Capacity Management - This aspect includes maintaining enough

network resources to meet the needs of the current customer base with the
least possible blocking.
Stages of Optimization
The RF optimization process occurs in three stages as a network develops.
The optimization stages are (1) pre-commercial, (2) commercial launch, and
(3) system growth and maturation. Each of these stages provide the RF
engineer with a different set of objectives and tests.
Pre-Commercial
This stage of optimization is key to successful future system management.
This stage sets the baseline or benchmark that RF system performance is built
on from commercial launch to network maturity. There is a great deal of both
theoretical and practical applications planned during this phase. The efforts of
this stage apply to the following:
• system or cluster shakedown, de-bug, and datafill audit

Stages of Optimization 1-7
• RF coverage and handoff control

• establish neighbor lists
• minimize dropped calls
• increase access completion
• determine best search window settings
• increase hard handoff completion rate
Note: A simulated load must be applied to the system or cluster for some
period during this stage of optimization.
Commercial Launch
After the benchmark is established during the pre-commercial launch, it must
be noted that this benchmark was set with simulated loading that may or may
not reflect actual system behavior after launch. For this reason, one must
continue the optimization efforts to make sure of new customer approval.
This is the first stage of optimization that reveals the personality of the
network shown as customers are added after launch. This stage is controlled
by analyzing drive test data and call performance OMs. The efforts now apply
to the following:

• decreasing dropped calls
• increasing access completion
• increasing hard handoff completion
• monitoring capacity and traffic growth
System Growth and Maturation
Optimization is an on going process that requires constant attention. As time
passes, customers are added to the network, the topography of the area
changes, and business plans require for footprint expansion. All of these
conditions require additional optimization.
As your system develops and matures, daily monitoring of call performance

metrics is very important in determining the impact of adding more
customers. Control route drive testing will be an important factor in
determining the effect of additional system loading. These practices are key
in determining what actions must be taken. Multiple carrier deployment,
capacity fill in site deployment, footprint expansion, and other decisions are
based on the results of this work.
The work during this stage of optimization look at:

• integrating new sites into the existing network

• monitoring capacity and traffic growth
• minimizing dropped calls
• maximizing access success
• maximizing hard handoff success
Optimization Procedures
This section shows possible procedures that can be used to make sure of
successful completion of optimization.
Entrance Criteria
Before optimization begins there is a list of activities, referred to as entrance
criteria, that must be completed. The successful completion of your effort
depends on the accuracy and logistics of these activities. For example, if the
BTSs have not been correctly commissioned, the optimization effort suffers.
The following items represent the minimum entrance requirements for a

successful optimization exercise:
1. All BTSs must have been correctly installed and commissioned. The
calibration values must be entered in the datafill.
2. The spectrum must be cleared down to a level of -110dBm (800MHz) or -
111dBm (1900MHz) (total power per 1.25MHz) at all locations in the
service area.
3. The network must have stability. In other words, all required sectors are
on the air, can originate calls, and make handoffs into and out of the
sector.
4. Personnel must be available to carry out selector logging, parameter
changes, enabling or disabling OCNS, wilting or blossoming of sectors.
5. An up to date site database must be available in the prediction tool.
(Planet* for example)
6. All test vehicles, tools, maps, etc. should be available; data collection
tools installed; GPS installed and calibrated.
7. A PN plan must have been created and entered in the datafill.
8. Preliminary neighbor lists must have been created and entered in the
datafill.
9. The required results (exit criteria) must have been defined.

Pre-Commercial
Systems that are being optimized for the first time (before launch) require a
great deal of specialized attention. This is the time that allows the
optimization engineer the flexibility to try procedures that they can not try
after the system is in service. The engineer can also see the system respond to
both loaded and unloaded conditions.
Note: The most common method of loading a pre-commercial system is

by enabling OCNS (Orthogonal Channel Noise Simulator) in the BSM.
OCNS is described in greater detail in Chapter 3.
The following is a basic list of items that must be addressed during an

optimization exercise on a pre-commercial system. The post-processing and
analysis of data collected during this stage of optimization is discussed in
greater detail in later chapters of this document.
First Set of Tests on Unloaded System (no OCNS)

Note: Simulated load is NOT applied at this stage (because “stray”
sectors need to be found)
1. Perform datafill audit and shakedown.

2. Perform a full network or cluster drive while running 2 minute Markov
calls and collecting mobile and SBS selector logs.
3. OPTIMIZE SRCH_WIN_A and BTS demodulation windows based on
rake finger offset analysis.
4. OPTIMIZE SRCH_WIN_N/R based on offsets in Pilot Strength
Measurement Messages.
5. Perform the RF coverage analysis; plot handoff state (by sectors), mobile
TX, mobile RX, best finger Ec/Io, per-PN plots as necessary (best finger/
any finger/PSMM occurrence).
6. Perform dropped call analysis; plot locations in the data analysis tool.
7. Perform failed access analysis; plot locations in the data analysis tool.
8. Tune the neighbor lists using an automated neighbor list audit tool,
dropped call or failed access analysis, and candidates that came from the
Remaining Set.
9. Generate the per site Transmit Gain Adjust averages to find site problems.
10. Create baseline data for the performance and trend analysis.
11. Make all the necessary changes to the network.
12. Use “spot check” drives to re-create problems and validate changes.
13. If changes are small, go to second set of tests with system loaded (OCNS
enabled).

14. If important system changes were made, repeat steps 2 through 12 until
required results are reached.
Second Set of Tests on Loaded System (OCNS enabled)

1. Apply simulated load and perform full network or cluster drive while
running 2 minute Markov calls and collecting mobile and selector logs
2. Regenerate the RF coverage analysis plots; plot handoff state (by sectors),
mobile TX, mobile RX, best finger Ec/Io, per-PN plots as necessary (best
finger or any finger or PSMM occurrence).
3. Perform dropped call analysis; plot locations in the data analysis tool.
Note: Pay close attention to coverage related issues.
4. Perform failed access analysis; plot locations in the data analysis tool.
Note: Pay close attention to coverage related issues.
5. Create new dataset for the performance and trend analysis.

6. Perform analysis of special occurrences that are peculiar to the system.
(geographic or traffic "hot spot")
Note: If the coverage control changes are acceptable, the average number
of sectors per user is not excessive, and the dropped call and access failure
rates are acceptable, then initial optimization is complete. If not, make all
the necessary changes to the network and repeat from item 1.
7. Complete the performance and trend analysis.
From Commercial Launch to Maturation

The main difference between the pre-commercial stage of optimization and
the other stages is that after the commercial launch of a network, the
flexibility of experimentation is lost. The changes that are made have an
effect on revenue generating customers. This fact must be kept in mind. It is
also important to remember that any change made in the network will cause a
change, positive or negative, with some other aspect of the network.
Use the following list to determine when and how to perform optimization on
your network after commercial launch.
• Use the MTX OMs and BTSPerformanceData as trend analysis data to

locate problem areas.
• Enable unconditional SBS logging of RTD, NeighborListTuningArray
and VitalData.
• Use unconditional SBS and BTS Diagnostic logging.
• If distinct MINs are suspect, enable a full SBS optimization conditional
logmask for those mobiles.

• Use drive testing as a "last resort" means of describing a problem area.

• Use drive testing to complete the integration of new sites.
Exit Criteria
The required results of optimization are known as exit criteria. These values
can vary from area to area or network to network. For the most part, the exit
criteria that are of main value are:
• achieving a target dropped call rate.

• achieving a target access success rate.
• achieving coverage over a indicated geographic area.
• achieving a target capacity.
After these exit criteria are met, the optimization effort (for the time being)
can stop. Remember, however that optimization is an on going process that
depends on the maturity and performance of the network.


2-1
Chapter 2
Initial System Parameters 2
Because an important part of optimization is devoted to control of system
parameters, every effort must be made to begin with a datafill that includes
the experiences found in other customer markets.
The datafill shown in the spreadsheets available from the Nortel Networks
Technology Applications department provides a solid starting point for
optimizing a new system.
Note: Initial default system parameters provided by Nortel Networks are

continually evolving, based on new field experiences and trials. Always
consult your Nortel technical representative for the latest datafill
spreadsheets and/or parameter guides. The values given in this
document should not be used for system deployment but are intended
to be used for illustrative and instructional purposes only.
New Features Relevant to RF Optimization

Available in the NBSS 10.1 software load are several new features with
corresponding new datafill parameters. Here is a brief summary of these new
features:
Access Robustness Package

The Access Robustness Package contains a number of features designed to
provide the support requirements for IS-95B and improve the radio link
performance of the IS-95B and CDMA 2000 mobile station accessing the
system by origination or page response.
Refer to NTP 411-2133-130, MTX CDMA Planning Guide, Section 9 for a

thorough discussion on ARP.
Prior to IS-95B and NBSS 9.0, mobile accesses to the CDMA system have
been restricted to call set-up on a single pilot. This limitation has led to
increased access failures due to significant interference of ‘other’ pilots to the
current reference pilot where the set-up attempt is being made. The majority

2-2 Chapter 2 Initial System Parameters
of access failures can be attributed to the ineffectiveness of the standard in the

following areas:
i. IS-95A was not designed to allow mobiles to be in soft handoff

during call set-up
ii. Lack of diversity on the forward link in the previous situation
makes messaging vulnerable to RF channel interference and
fading
iii. The mobile may not necessarily originate on the best pilot, or the
best pilot may deteriorate and the access attempt fail.
The following feature improvements in NBSS 10.1 improve the probability of

IS-95B/CDMA 2000 mobile accesses leading to successful call set-up.
1. Channel Assignment Into Soft Handoff

Each IS-95B/CDMA 2000 mobile station keeps a list of up to six (6)
pilots which is used to determine the best pilot to access the network.
When accessing the system on this best pilot (origination or page

response) the mobile reports this list of additional pilots with their
corresponding PN phases and Ec/Io strengths. This list is always a subset
of the serving pilot’s extended neighbor list.
The CDMA system (BSC-MSC) uses the additional pilot strength

measurements reported on the access channel message to allocate
resources (assign traffic channels etc) for use by the mobile to establish a
soft handoff while in the access state.
The list of pilots which the mobile can enter into soft handoff with is
provided in the Extended Channel Assignment Message (ECAM). The
ECAM is sent on the paging channel of the primary pilot (where the
mobile originated the call or response was made).
The parameter MaxNumInitLinks applies to this feature and is further

discussed later in this section.
2. Access Handoff
The Access Handoff feature allows idle-mode handoff from originating
pilot to another more suitable pilot should the originating pilot’s Ec/Io
become too weak during the system access state. This is in effect a hard
handoff from one pilot to another.
The MSC sends the Extended Channel Assignment Message (ECAM) to

the BTSs with the strongest reported pilots that allow access handoffs.

This information is presented to the mobile via the Extended System

Parameters Message.
Access Handoff increases the probability that the mobile will receive the
Extended Channel Assignment Message and consequently move to the
traffic channel.
The parameters of interest for Access Handoff are ACCESS_HO and

ACCESS_HO_ALLOWED_LIST which are further described later in
this section of the document.
3. Access Entry Handoff

This access improvement allows the mobile to respond to a page with any
of the cells identified as a neighbor provided that in each neighbor’s
datafill the Access Entry Handoff feature is enabled.
Access Entry Handoff increases the probability that a base station will
receive the mobile’s page response message which further increases the
chances of successful call completion.
The parameters of interest for Access Entry Handoff are

ACCESS_ENTRY_HO_ORDER and ACCESS_ENTRY_HO_LIST
which are further described later in this section of the document.
In general, other relevant parameters to the Access Robustness Package

include MIN_P_REV and P_REV.
Intelligent Paging
Refer to the NTP 411-2133-130, MTX CDMA Planning Guide, Section 8 for a
thorough discussion on Intelligent Paging.
Previous software releases have been restricted to system-wide paging with

consequently high paging channel usage. The purpose of the new Intelligent
Zone Paging (IZP) feature is to increase Paging Channel capacity by reducing
the number of page messages processed and sent within the CDMA network.
This is accomplished in the following ways:
i. Assigning a Page Zone ID to a set of BTSs

ii. Keeping track of a mobiles current zone using Zone Based
Registration
iii. Sending valid pages only to the BTSs located within the particular
Zone
iv. For MetroCell BTSs; paging only on the frequency the mobile is
currently ‘listening to’

This functionality applies to the following paging related services:
• General Page Message

• Message Waiting Indicator Page Message
• Short Message Service Page Message
• Unique Challenge (Authentication) Page Message
In previous NBSS releases, system-wide paging was adopted followed by a
system-wide page retry for call processing terminations. With NBSS 10.1 and
IZP, the system will perform a ‘zone-based’ page followed by either a system-
wide repage or a zone-based retry for call processing terminations.
Frequency Based Paging

In addition to the functionality described above, Frequency Based Paging is
also available with NBSS 10.1 but only with Metro Cell products. This
feature allows the page message to be transmitted over a single carrier rather
than all carriers. The carrier over which the page message is transmitted is
determined by the same hashing algorithm that was used by the mobile to
originally select the carrier. Frequency Based Paging is supported for the
following messages:
• General Page Message

• Feature Notification
• Data Burst
• Authentication - Unique Challenge
Note: The feature is datafilled on a per MetroCell basis and when
enabled both the page and the repage is frequency-based. When Global
Service Redirect (GSR) is activated, Frequency Based Paging is not
performed. Also, the feature is not performed on MetroCells with V5.2
carriers. Frequency Based Paging is not beneficial when multi-carrier
MetroCells are configured with a single paging channel.
Intelligent Zone Paging Tool

Nortel Networks Network Engineering Tools group have developed an
Intelligent Zone Paging Tool to aid customers in the evaluation of their
paging zones. This is accomplished through characterization of Traffic and
Mobility within and between zones, based on previously collected SBS data.
Contact your Nortel representative for more information on this tool and its
application.
There are several new parameters which have been added to accomodate the
Intelligent Zone Paging feature. These include: NumberofZones,
PageZoneRecord, ZoneNumber, RepageMethod, CellList,

NumberofCells, CellNumber and are configurable via the PageZoneTable

MO. These parameters are futher discussed later in this section.
Overhead Channel Manager (OCM) Paging Congestion Control

The aim of this feature is to protect the base station from overload when
network traffic exceeds the engineering limits of the system. It will perform
this by progressively shedding paging traffic received from the MTX/BSC.
The shedding of this messaging follows a priority rule, with lower priority
messages being shedded first (eg: Feature Notification Messages FNM and
Data Burst Messages DBM). As congestion becomes more severe, higher
priority messages are sequentially shedded. This feature may also be referred
to as the Paging Throttle Mechanism.
OCM Paging Congestion Control utilizes the following parameters in the

BTSC/BTSCallProcessing MO;
OCM_PTM_ThrottleWindow,
OCM_PTM_PageMsgThreshold,
OCM_PTM_CpuThreshold,
OCM_PTM_CpuOverloadPageMsgThreshold,
OCM_PTM_RestorePagingTimeout
These parameters are further highlighted in the BTS Static Datafill later in
this section.
BTS No Call Processing Alarm Management

This new feature provides additional alarm capability on the BTS to detect
and report Call Processing failures and is intended to significantly shorten
problem resolution time. Five new alarms are defined for this feature;
1. Alarm 1: When the BTS detects complete failure of call setups or

complete call handoff failure with complete loss of call processing
resources.
2. Alarm 2: When the BTS detects call setup or handoff failure rates on a
sector equal to or greater than the new settable parameter
NoCallPAlarmThreshold.
3. Alarm 3: When a BTS has partially lost resources on a sector.
4. Alarm 4: When all sectors on a frequency have a critical NoCallP alarm.
5. Alarm 5: When any sector on a frequency has a critical NoCallP alarm.
There are two new parameters defined for this feature;
NoCallPAlarmEnabled and NoCallPAlarmThreshold; both in the BTSC
(Legacy) or BTSCallProcessing (MetroCell) MO. .

Intelligent Voice Services Negotiation (IVSN)

This feature was first introduced in NBSS 8.0 and has been further enhanced
for NBSS 9.0 and NBSS 10.1 . IVSN allows the system operator to specify
the type of voice service option (vocoder type) to be used for a call, based on
a combination of the operator’s and mobile’s preferences. Refer to the NTP
411-2133-130, MTX CDMA Planning Guide Section 7 and 411-2133-303,
IVSN Application Guide for a thorough discussion on this feature.
Table 2-1
Possible Service Redirections
From To
EVRC EVRC, BASIC_8K, BASIC_13K, IS733_13K
BASIC_8K EVRC, BASIC_8K, BASIC_13K, IS733_13K
BASIC_13K EVRC, BASIC_8K, BASIC_13K, IS733_13K
IS733_13K EVRC, BASIC_8K, BASIC_13K, IS733_13K
NIL (Termination only) EVRC, BASIC_8K, BASIC_13K, IS733_13K
Note: The IVSN feature does not allocate resources, then redirect and
set-up new resources. All of the redirection occurs before any SBS
resources are ever allocated for a call. Consequently, once a call is set-up
with a traffic channel, it is not possible to redirect that call to another
service option. Note also that a ‘redirection’ is the term used in IVSN to
indicate when a requested service option has been substituted with a
different service option due to either system preference or unavailable
resources.
The main advantages of IVSN are as follows:
• Offers a service option that is preferred by the system (operator) but

different than the one requested by a mobile.
• Provides for an alternate service option when resources for a desired
service option are not available.
• An overall system capacity increase is possible by redirecting Rate Set 2
(13K) calls to Rate Set 1(eg: EVRC). The primary intended use for this is
to redirect BASIC_13K calls to EVRC.
Most of the datafill for IVSN is accomplished in the MTX and is beyond the
scope of this document. Refer to NTP 411-2133-535, NBSS Operational
Measurements.
The two RF datafill parameters relevant to IVSN are MAX_CAP_SZ

(Sector/AdvancedSector MOs) and MAX_NUM_ALT_SO (BTSC/

BTSCallProcessing MOs). These are discussed in further detail later in this

section.
Cell ID Expansion, InterSystemCellId

As part of the CellId expansion feature, the bit interpretation for the
InterSystemCellId’s has changed as follows:
Table 2-2
Old (prior to NBSS 9.0) 16 bit InterSystemCellId
BC Cell Number Sector
xxx xxxxxxxxx xxxx
Refer to the following table which describes the bit positions for the new
NBSS 9.0 and 10.1 InterSystemCellId:
Table 2-3
New NBSS 9.0 and 10.1 InterSystemCellId
BC Cell Number Sector
xx xxxxxxxxxxx xxx
Types of RF Optimization Parameters

There are a number of parameters that can be controlled to improve the RF
performance of the network. These parameters manage handoffs, call
performance, power control, and capacity. One can note at this point that any
change in parameters has either a positive or negative impact on the network.
IS-95/J-STD-008/IS 20000 as compared to Nortel Specific

Some parameters are defined by the standards and are found in IS-95 or J-
STD-008 and IS 2000. Other parameters are Nortel specific and are found in
the NMIS documents.
Global Parameters as compared to Sector Specific Parameters

The difference between these descriptions is important and not always easy to
see. Global parameters apply to the whole system (one BSC/MTX) and any
changes made effect the operation of the complete system. Sector specific
parameters apply only to specific sectors.
If a mobile is in soft handoff with more than one sector containing different
values for a parameter, there are parameter related rules for which of the
following values are used:
6. For SRCH_WIN_A the SBS sends the widest value
7. For SRCH_WIN_N the SBS sends the widest value

8. For SRCH_WIN_R the SBS sends the widest value

9. For T_ADD, T_DROP the SBS sends the lowest or most negative value
(For example, an option of -12dB and -13dB results in the SBS sending
the more negative -13dB value.)
10. For T_TDROP, the SBS sends the maximum value
11. For T_COMP, the SBS sends the minimum value
BTS and BSC Datafill Parameters

Several parameters are datafilled in both BTS managed objects (MOs) and
BSC MOs. This method of datafill is necessary because the mobile can be in
one of several states when it requires this parameter information. For the most
part, the BTS datafill parameters discussed are used by the mobile while it is
in the idle state and the BSC datafill parameters discussed are used in the
traffic state.
Values in the BTS datafill appear on sync and paging channels. When the
mobile starts a new call, it has the settings that it got from the last sector on
which it was idle.
Values at the BSC apply to the traffic channel. SRCH_WIN_A, T_ADD,

T_DROP, T_TDROP and T_COMP are all sent in the Extended Handoff
Direction Message according to the preceding rules if the SBS detects that the
mobile does not have the current values.
Each time a handoff occurs, the SBS works out the new values according to
the new active set. If these values don't match what was last sent to the
mobile, the SBS sets the "Search Included" flag and sends the new values in
the Extended Handoff Direction Message. Currently, the "In Traffic System
Parameters Message" is not implemented. This fact makes it impossible to
update the mobile's settings for SRCH_WIN_N/R during a call. While these
values can be set per sector at the BSC, the mobile only uses the values it gets
from the paging channel.
For example, a call which originated in a rural cell with a large

SRCH_WIN_N that is carried into a urban cell with a smaller window setting
does not update its search window until the call is released and the mobile
monitors the paging channel again.
Neighbor lists are somewhat of a special condition. As with other parameters,

the settings at the BTS are for the paging channel. Because the mobile locks
to one sector at a time during idle, its neighbor search procedure uses the
neighbor list from that sector. When on a traffic channel, the BTS neighbor
list continues to be used to until the first handoff completes. From that point
on, the mobile generates a composite neighbor list (up to a maximum of 20
entries) with the following priorities:

1. Any pilots recently removed from the active list but have not exceeded
NGHBR_MAX_AGE
2. The neighbor list as received on the most recent Neighbor List Update
Message from the BSC (although any pilots from “1” are not repeated)
Note: If the Neighbor List Update Message contains 20 entries, the

mobile gives priority to pilots defined in the first priority, “1”, so all 20
can not be used. These rules are in the IS-95 standard.
The neighbor list received from the SBS is a composite (up to a maximum of
20 entries) of the neighbor lists of the sectors named in the most recent
Handoff Completion Message.
Access Mode of Parameters (C, G, S)

Each parameter in the NBSS 10.1 CDMA system has a modification
condition which determines how and if changes can be made to that
parameter. Certain BTS parameters (eg:HandoffBlockingThreshold in the
Sector/Advanced Sector MO) were previously modifiable via the BSM but
would require that the BTS be removed from service, reloaded and then re-
instated into service with the new modified parameter value. With the release
of NBSS 10.110.1 , most BTS parameters are changeable ‘on the fly’
meaning the parameter value can be adjusted without taking the BTS out of
service. Other parameters are only ‘readable’ and cannot be changed (eg:
SYS_TIME). The following definitions are used to describe each
parameter’s access mode:
• CREATABLE (C)......... A parameter that can be modified in value but not

necessarily ‘on the fly’
• GETTABLE (G)........... A parameter value that is ‘readable’ from the
BSM
• SETTABLE (S)............ A parameter value that can be modified ‘on the
fly’ which does not require taking the BTS out of service and reloading
the datafill
All parameters are in some combination of the above three access modes. For
example,
SYS_TIME = G, .........................(value is readable or gettable only)

BCAST_INDEX = C,G ................( value is readable and also can be changed
but not ‘on the fly’)
MAX_CAP_SZ = C,G,S .............(value is readable, can be changed ‘on the
fly’, without reloading the BTS datafill)
The access mode for each parameter is identified in the following datafill
tables.

Values in Datafill Tables in this Document

Please note that values given in the ‘Suggested Value’ column of the
following tables are DECIMAL values and must be converted to the
corresponding HEXADECIMAL equivalent for certain datafill tasks. Refer to
the Nortel Datafill Spreadsheets for both representations..
BSC static datafill

This section describes the meaning and use of the RF/air interface-related
static datafill at the BSC. This section does not address other forms of datafill
(such as, OA&M, connectivity, MTX and so on).
RF-related parameter values are suggested starting points for network

optimization and are not to be hard-and-fast rules. The values given in this
document should not be used for system deployment but are intended to
be used for illustrative and instructional purposes only.
SelectorBank Subsystem Managed Object (SBS MO)

There are considerable changes between the ‘global’ power control
functionality of prior relelases and that for NBSS 10.11 and later versions.
Due to the advent of 3G CDMA 2000 technology with releases 10.11 and
later, power control parameters must now be specified for various
RadioConfiguration (RC) rates (eg: RS1, RS2, RC3, RC4 and RC5). In
addition, the previously global nature of the power control parameters is now
settable in up to 10 different profiles which can each then be selected per
sector in the Pilot Database MO. Refer to the following diagram Figure 2-1.

Figure 2-1
Flexible Power Control Array
Flexible Power Control ‘Array’

il es
of
Pr
r ol Profile 10 (Pwr Control ID=9)
ont
e rC
ow
tP
en
er
i ff
D Profile 3 (Pwr Control ID=2)
10
to
U
p Profile 2 (Pwr Control ID=1)
Profile 1 (Pwr Control ID=0)
1536 SCH
RC3 768 SCH
SCH 384 SCH
RC1 RC2 RC3 RC3DATA
During
FCH 192 SCH
RC4 General
SCH Profile Specific
RC4 RC5 Pwr Control
FCH FCH Parameters
NumProfiles eg: 10
This diagram shows the various profiles (up to 10) that are contained within
the Flexible Power Control Array within the SBS MO. Each profile contains
many parameters relevant to the sub-profiles such as RS1 (previously Rate
Set 1), RS2 (Rate Set 2), RC3 FCH, RC4 SCH; as shown by the blocks inside
the appropriate profile. The name of the profile (PowerControlID) is then
used in the Pilot Database records to specify which profile to use for that
specific sector.

Table 2-4
SelectorSubSystem MO parameters (Legacy and MetroCell products)
SELECTOR SUBSYSTEM SBS MO

Parameter Parameter Name Access Range Suggested Note
Type Mode Value
DECIMAL
FLEXIBLE POWER CONTROL ARRAY

NumProfiles C,G,S 1-10
PROFILE
GENERAL PROFILE SPECIFIC PARAMETERS
FlexiblePowerControlID C,G,S 0-9 Number of profile
Title C,G,S String Name of profile

(eg:Default,
Repeater etc)
FwdPwrCtrlRefGain C,G,S 0-255 DGUs Reference gain for

Forward Power
Control
RLTrafficPilotGain C,G,S 0-255 Mobile TFC power

relative to RL Pilot
RLGain_Default C,G,S 0-255 Initial RL TFC Gain

used by mobile
RATE SET 1 (eg: 8 kb EVRC)

RS1
PrRXerror (FER%)
Reverse Full C,G,S 1/16 - 256/16% 8 0.5%
Reverse Half C,G,S 1/16 - 256/16% 24 1.5%
Reverse Quarter C,G,S 1/16 - 256/16% 40 2.5%
Reverse Eighth C,G,S 1/16 - 256/16% 40 2.5%
Reverse Unknown C,G,S 1/16 - 256/16% 8 0.5%
RRXincrease
Reverse Full C,G,S 1/256 - 4095/256 dB 42 0.164 dB
Reverse Half C,G,S 1/256 - 4095/256 dB 14 0.055 dB

Table 2-4

Type Mode Value
DECIMAL
Reverse Quarter C,G,S 1/256 - 4095/256 dB 7 0.027 dB
Eighth C,G,S 1/256 - 4095/256 dB 7 0.027 dB
Reverse Unknown C,G,S 1/256 - 4095/256 dB 42 0.164 dB
Reverse PRXlower C,G,S 1/256 - 4095/256 dB 1562 6.1dB Ew/Nt)
Reverse PRXupper C,G,S 1/256 - 4095/256 dB 3123 12.2dB (Ew/Nt)
Reverse PRXstart C,G,S 1/256 - 4095/256 dB 2611 10.2dB (Ew/Nt)
Note: Eb/No = Ew/Nt -3.0 dB for RS1 (eg: 10.2 dB Ew/Nt = 7.2 dB Eb/No)
Forward PrTxerror C,G,S 1/16 - 256/16 dB 24 1.5%
Forward RTXincrease C,G,S 1/256 - 4095/256 dB 24 0.1 dB
Forward PTXlower C,G,S -4095/256 - 0/256 -3584 -14 dB

dB
Forward PTXupper C,G,S -4095/256 - 0/256 -512 -2 dB

dB
Forward PTXstart C,G,S -4095/256 - 0/256 -1024 -4 dB

dB
RATE SET 2 (eg: 13kb)

RS2 PrRXerror (FER%)
Reverse Full C,G,S 1/16 - 256/16% 8 .5%
Reverse Half C,G,S 1/16 - 256/16% 24 1.5%
Reverse Quarter C,G,S 1/16 - 256/16% 40 2.5%
Reverse Eighth C,G,S 1/16 - 256/16% 40 2.5%
Reverse Unknown C,G,S 1/16 - 256/16% 8 .5%
RRXincrease
Reverse Full C,G,S 1/256 - 4095/256 dB 42 0.164 dB
Reverse Half C,G,S 1/256 - 4095/256 dB 14 0.055 dB

Table 2-4

Type Mode Value
DECIMAL
Reverse Quarter C,G,S 1/256 - 4095/256 dB 7 0.027 dB
Reverse Eighth C,G,S 1/256 - 4095/256 dB 7 0.027 dB
Reverse Unknown C,G,S 1/256 - 4095/256dB 14 0.055 dB
Reverse PRXlower C,G,S 1/256 - 4095/256dB 2023 7.9 dB (Ew/Nt)
Reverse PRXupper C,G,S 1/256 - 4095/256 dB 3584 14.0 dB (Ew/Nt)
Reverse PRXstart C,G,S 1/256 - 4095/256 dB 3072 12 dB (Ew/Nt)
Note: Eb/No = Ew/Nt -4.8 dB for RS2 (eg: 12 dB Ew/Nt = 7.2 dB Eb/No)
Forward PrTxerror C,G,S 1/16 - 256/16dB 24 1.5%
Forward RTXincrease C,G,S 1/256 - 4095/256dB 24 0.1 dB
Forward PTXlower C,G,S -4095/256 - 0/ -3072 -12 dB

256dB
Forward PTXupper C,G,S -4095/256 - 0/ 0 0 dB

256dB
Forward PTXstart C,G,S -4095/256 - 0/ -512 -2 dB

256dB
RADIO CONFIGURATION RC3

RC3 FCH Data (Fundamental Channel Data)
Reverse RxFER_Full C,G,S 1/16 - 255/16 % 8
Reverse RxFER_Half C,G,S 1/16 - 255/16 % 24
Reverse RxFER_Quarter C,G,S 1/16 - 255/16 % 40
Reverse RxFER_Eighth C,G,S 1/16 - 255/16 % 40
Reverse RxFER_Unknown C,G,S 1/16 - 255/16 % 8
Reverse RxMinSetPoint C,G,S -16320/256 to 0/256 -5632

dB
Reverse RxMaxSetPoint C,G,S -16320/256 to 0/256 -3968

dB

Table 2-4

Type Mode Value
DECIMAL
Reverse RxInitSetPoint C,G,S -16320/256 to 0/256 -4608

dB
Reverse RRXIncrease_Full C,G,S 1/256 to 4095/256 42
Reverse RRXIncrease_Half C,G,S 1/256 to 4095/256 14
Reverse RRXIncrease_Quarter C,G,S 1/256 to 4095/256 7
Reverse RRXIncrease_Eighth C,G,S 1/256 to 4095/256 7
Reverse RRXIncrease_Unknown C,G,S 1/256 to 4095/256 42
Reverse SCH RC3 C,G,S 1/256 to 4095/256 42 (when a RL SCH is

in use)
RRXIncrease_Unknown
Forward TxFER C,G,S 0 to 31 % 4
Forward TxFER_PktData C,G,S 0 to 31 % 4
Forward TxMinGain C,G,S -128/4 to +127/4 -72
Forward TxMaxGain C,G,S -128/4 to +127/4 -12
TxInitGain C,G,S -128/4 to +127/4 -28
Forward TxMinSetPoint C,G,S 0/8 to 255/8 dB Eb/ 8

No
Forward TxMaxSetPoint C,G,S 0/8 to 255/8 dB Eb/ 120

No
Forward TxInitSetPoint C,G,S 0/8 to 255/8 dB Eb/ 56

No
RC3 FCH Data During X (FCH parms different when SCH in use. See below)
SCH
RxMinSetPoint C,G,S -16320/256 - 0/256 -5362

dB
During a
RxMaxSetPoint C,G,S -16320/256 - 0/256 -4010
19.2 kb SCH dB
RxInitSetPoint C,G,S -16320/256 - 0/256 -4600

dB

Table 2-4

Type Mode Value
DECIMAL

dB
During a
38.4 kb SCH dB

dB

dB
During a
76.8 kb SCH dB

dB

dB
During a
153.6 kb dB
SCH
dB
RC3 SCH Data (Supplemental Channel Data)
19.2 kb TxFER_PktData C,G,S 0 to 31 % 10
RC3 SCH

Table 2-4

Type Mode Value
DECIMAL
TxMinGain C,G,S -128/4 to +127/4 -72
TxMaxGain C,G,S -128/4 to +127/4 -11
TxInitGain_Offset C,G,S -128/4 to +127/4 0
19.2 kb TxMinSetPoint C,G,S 0/8 to 255/8 dB Eb/ 8

No
RC3 SCH
TxMaxSetPoint C,G,S 0/8 to 255/8 dB Eb/ 101
(cont) No
TxInitSetPoint_Offset C,G,S 0/8 to 255/8 dB Eb/ 0

No
TxFER_PktData C,G,S 0 to 31 % 10
TxMinGain C,G,S -128/4 to +127/4 -60
TxMaxGain C,G,S -128/4 to +127/4 3
TxMinSetPoint C,G,S 0/8 to 255/8 dB Eb/ 8

No
38.4 kb
No
RC3 SCH
No

Table 2-4

Type Mode Value
DECIMAL
TxMinGain C,G,S -128/4 to +127/4 -48

No
76.8 kb
No
RC3 SCH
No
TxMinGain C,G,S -128/4 to +127/4 -36

No
153.6 kb
No
RC3 SCH
No


Table 2-4

Type Mode Value
DECIMAL

dB

dB

dB

No

No

No
RC4 SCH Data (Supplemental Channel Data)

Table 2-4

Type Mode Value
DECIMAL
TxMinGain C,G,S -128/4 to +127/4 -68
TxMaxGain C,G,S -128/4 to +127/4 -8

No
19.2 kb
No
RC4 SCH
No
TxMinGain C,G,S -128/4 to +127/4 -56

No
38.4 kb
No
RC4 SCH
No

Table 2-4

Type Mode Value
DECIMAL
TxMinGain C,G,S -128/4 to +127/4 -44

No
76.8 kb
No
RC4 SCH
No
TxMinGain C,G,S -128/4 to +127/4 -32

No
153.6 kb
No
RC4 SCH
No


Table 2-4

Type Mode Value
DECIMAL

dB

dB

dB

No

No

No
END OF FLEXIBLE POWER CONTROL ARRAY
RADIO LINK PROTOCOL PARAMETERS FOR PACKET DATA

Table 2-4

Type Mode Value
DECIMAL
RLP PARAMETERS
BufferThreshold_192 C,G,S 0 - 65535 1200
BufferThreshold_384 C,G,S 0 - 65535 2400
BufferThreshold_768 C,G,S 0-4294967295 3600
BufferThreshold_1536 C,G,S 0-4294967295 4800
BufferThreshold_Releas C,G,S 0 - 65535 1024

e
Init_Nak_Delay C,G,S 1 to 40 20ms frames 8
InterRound_Delay C,G,S 1 to 20 20ms frames 13
MaxSyncAttempts C,G,S 1 to 20 20ms frames 0
NAK_ROUNDS_FWD C,G,S 0-255 3
NAKS_PER_ROUND1 C,G,S 0-255 1
RLP_Delay C,G,S 0-255 Secs 0
SCH Release Hold Time C,G,S 0-4294967295 10
RLPQ PARAMETERS
FwdBuffer_High C,G,S 0 - 100% 80
FwdBuffer_Low C,G,S 0 - 100% 60
FwdBufferSize C,G,S 0 - 4294967296 32768

bytes
FwdTxOffGracePeriod C,G,S 0 - 255 20ms 5

frames
RevBufferSize C,G,S 0 - 4294967296 16383

bytes
RevRateXferLimit C,G,S 0 - 255 3

Table 2-4

Type Mode Value
DECIMAL
SCH DURATION PARAMETERS

FSCH_DURATION_TIME C,G,S 1-14 12
_19200

_38400

_76800

_153600
FSCH_FIXED_SCH_DUR C,G,S 1-14 10

ATION_TIME
INFINITE_BURST_SUPP C,G,S 0 or 1 (false/true) 0

ORT_FWD
INFINITE_BURST_SUPP C,G,S 0 or 1 (false/true) 0

ORT_REV
MAXIMUM_SCH_DURAT C,G,S 1-14 14

ION_TIME
MINIMUM_SCH_DURATI C,G,S 1-14 9

ON_TIME
MODE_SELECTION_IND C,G,S 0 to 3 1
EX
PERIOD_FUTURE_DAT C,G,S 0 - 255 20mS 18

A frames
RSCH_DURATION_TIME C,G,S 1-14 12

_19200

_38400

_76800

_153600

Table 2-4

Type Mode Value
DECIMAL
RSCH_FIXED_SCH_DU C,G,S 1-14 10

RATION_TIME
SCHRevDTXThreshold C,G,S 0 to 15, 20ms 10

frames
SCHSetupOverheadTim C,G,S 0 - 4294967296 250000

e bytes
SOFT HANDOFF PARAMETERS

MaxFwdSCHSHOLinks C,G,S 1 to 6 2
MaxRevSCHSHOLinks C,G,S 1 to 6 2
END OF PACKET DATA FUNCTIONALITY (SBS MO)
IntersystemSystemResp C,G,S Word 32 12,000,000 micro seconds

onseTimeout = 12 seconds
PowerControlSyncSwitc C,G,S 0 or 1 (false/true) 1 enabled

h
Pilot Search NGHBR_MAX_AGE C,G,S 0 - 15 0

Parameters
Minimum PILOT_INC C,G,S 0 - 15 Most System

Pilot systems Specific
Spacing use 3 or 4
Open Loop NOM_PWR C,G,S -8 to +7 dB 0 0 dB
NUM_PREAMBLE C,G,S 0-7 0
NOM_PWR_EXT C,G,S 0-1 0 Hard coded to

zero in the
software
Back Haul BackHaulDelay C,G,S 18,000 See notes

Delay below
Nearest Spare 1 C,G,S Word 32 0 Algorithm not

Neighbor recommended

Table 2-4

Type Mode Value
DECIMAL
Markov Spare 3 C,G,S 0-4 (0=variable, 1-4 0 Used to control

functions is fixed; full half, whether
quarter,eighth Markov uses
fixed or variable
rates
PWR_REP_THRESH C,G,S 1-31 frames 2
END OF SBS MO PARAMETERS
The following table shows the relationships between the various power
control parameters and the Radio Configuration channels (eg: RC1 etc)
Table 2-5
Relationship between FPC Parameters and RC
RC3 FCH During SCH

RC3 SCH
RC4 SCH
RC3 FCH
RC4 FCH
RC5 FCH
RS1
RS2
RRXIncrease (Full/Half/Quarter/Eighth/Unknown) ! ! ! ! !
PrRXerror (Full/Half/Quarter/Eighth/Unknown) ! !
PrTXerror ! !
PRXlower ! !
PRXstart ! !
PRXupper ! !
PTXlower ! !
PTXstart ! !
PTXupper ! !

Table 2-5
Relationship between FPC Parameters and RC
RC3 FCH During SCH

RC3 SCH
RC4 SCH
RC3 FCH
RC4 FCH
RC5 FCH
RS1
RS2
RTXincrease ! !
RXFER (Full/Half/Quarter/Eighth/Unknown) ! ! ! ! ! ! !
RXInitSetPoint ! ! ! ! !
RXMaxSetPoint ! ! ! ! ! !
RXMinSetPoint ! ! ! ! ! !
SCHRC3RRxIncreaseUnknown !
TXFER ! ! !
TXFER_PktData ! ! ! !
TXInitGain ! ! !
TXInitGainOffset ! !
TXInitSetPoint ! ! !
TXInitSetPointOffset ! !
TXMaxGain ! ! ! ! !
TXMaxSetPoint ! ! ! ! !
TXMinGain ! ! ! ! !
TXMinSetPoint ! ! ! ! !
Page Zone Table

The following table shows the definitions for parameters used in NBSS 10.1
for Intelligent Zone Based Paging. This new feature is overviewed earlier in

this section. For a more thorough discussion on Intelligent Zone Paging,

consult NTP 411-2133-130 MTX CDMA Planning Guide
Table 2-6
Intelligent Zone Paging - Page Zone Table MO
INTELLIGENT ZONE PAGING PARAMETERS (PageZoneTable)

Parameter Parameter Name Modifiable Range Suggested Notes
Type Value
(DECIMAL)
Page Zone NumberofZones C,G,S 0-255 MTA

Specific
PageZoneRecord: C,G,S List of 16bit cell MTA

CellList: CellNumber numbers in Specific
range 0-2047
PageZoneRecord: C,G,S 1-1024 MTA

CellList: NumberofCells Specific
PageZoneRecord: C,G,S 0=SYSTEM MTA

RepageMethod 1=ZONE Specific
PageZoneRecord: C,G,S 0-254 MTA

ZoneNumber Specific
See also ZoneNumber in BTSCallProcessing MO.
Packet Control Unit (PCU) Managed Object (MO)

This is a new managed object (MO) required for 1xRTT packet data
functionality. The parameters of interest are:
• L2TPAttributes
• PDSNIPAddresses
• FwdDataParameters
• RevDataParameters
Table 2-7
Packet Control Unit (PCU) MO
PACKET CONTROL UNIT (PCU) MO

Parameter Type Parameter Name Modifi Range Suggested Note
able Value
(DECIMAL)

InitialAckTimer C,G,S 1-5 secs 1

L2TPAttributes
NumberOfRetries C,G,S 1-10 5
PDSNIPAddress Number OfAddresses C,G,S 0-3

Array
IPAddress C,G,S
ActiveBufferThreshold C,G,S 1-20,000 20,000 ms

Timer ms
ActiveBufferThreshold C,G,S 0-1200 1 bytes

bytes
FwdDataParameters
DormantBufferThresh- C,G,S 0-1200 10 bytes
old bytes
DataAgingTimer C,G,S 1-20,000 1000 seconds

ms
MaxSecondsToBuffer C,G,S 1-25 15 seconds

DataCall
ArrivalRateThreshold C,G,S 0-100 2 bytes/sec

RevDataParameters bytes/
sec
TimeInterval C,G,S 0-20000 20000 ms

ms
.
Table 2-8
Pilot Database MO Parameters (Legacy and MetroCell products)
PILOT DATABASE MO
Parameter Parameter Name Modifiable Range Suggested Note
Type Value
(DECIMAL)
PDB record
Extended BaseID C,G,S Word 32 System Sector, Cell, CDMA

Derived Freq, Band
PILOT_PN C,G,S 0 - 511 See Note PN plan as

determined by the
local MTA
QuickRepeat C,G,S 0-1 1 Enable quick

repeat of EHDM.
0=False, 1=True

Table 2-8
PILOT DATABASE MO
Type Value
(DECIMAL)
Flexible ForwardGain C,G,S 0 - 255 not used not used

Forward
FER
CellType C,G,S See Note See Note CELL_STANDARD

CELL_PILOT_BEACON
CELL_BORDER
CELL_EHHO
CellCapability C,G,S Voice2G, Mixed_and_

Voice2G_ RRM
3G,Data3
G,Mixed,
MixedRR
M
MultiPilotHHOEnabled C,G,S 0-1 1 Enables or disables

MPHHO. 0=False,
1=True
CellCapability C,G,S Voice_2G,

Voice_2G
_3G,
Data_3G,
Mixed,
Mixed_an
d_RRM
Pilot Beacon Sector Parameters
ReferencePilot C,G,S BeaconTargetCellIDList
BeaconTargetCell_Inter C,G,S BeaconTargetCellIDList Cell_Ids of the

SystemCellID target cells.
BeaconTargetCell_Mark C,G,S BeaconTargetCellIDList

etID
BeaconTargetCell_Swit C,G,S BeaconTargetCellIDList

chNumber
Pilot Search Parameters
SEARCH_WIN_A C,G,S 0 - 15 5 20 PN chips (must

(4 - 452 be optimized)
PN chips)

Table 2-8
PILOT DATABASE MO
Type Value
(DECIMAL)
SEARCH_WIN_N C,G,S 0 - 15 10 100 PN chips (must

(4 - 452 be optimized)
PN chips)
SEARCH_WIN_R C,G,S 0 - 15 14 320 PN chips. Set

(4 - 452 to 13 if
PN chips) PILOT_INC=3
Pilot Strength Parameters
T_ADD C,G,S 0 - 63 28 -14dB

(-0.5x dB)
T_DROP C,G,S 0 - 63 32 -16 dB

(-0.5x dB)
T_COMP C,G,S 0-15 (x0.5 2 1 dB

dB)
T_TDROP C,G,S 0-15 3 4 seconds)

(=<0.1 -
319 sec)
T_ADD_OFFSET_A C,G,S 0-4 dB 0 Offset added to

0.5 dB T_ADD when there
increment are two pilots in the
(0-8) active set
T_ADD_OFFSET_B C,G,S 0-4 dB 0 Offset added to

0.5 dB T_ADD when there
increment are more than two
(0-8) pilots in the active
set
T_DROP_OFFSET_A C,G,S 0-4 dB 0 Offset added to

0.5 dB T_DROP when
increment there are two pilots
(0-8) in the active set
T_DROP_OFFSET_B C,G,S 0-4 dB 0 Offset added to

0.5 dB T_DROP when
increment there are more
(0-8) than two pilots in
the active set

Table 2-8
PILOT DATABASE MO
Type Value
(DECIMAL)
T_COMP_OFFSET_A C,G,S -2 to 2dB 0 Offset added to

0.5 dB T_COMP when
increment there are two pilots
(-4 to +4) in the active set.
T_COMP_OFFSET_B C,G,S -2 to 2 dB 0 Offset added to

0.5 dB T_COMP when
increment there are more
(-4 to +4) than two pilots in
the active set.
T_TDROP_OFFSET_B C,G,S -2 to +2 0 Offset added to

second T_TDROP when
(-4 to +4) there are more
than two pilots in
the active set.
DELTA_3 C,G,S 0-15.5 dB 31 Represents the

0.5 dB difference between
increment the strongest and
(0-31) 3rd strongest pilot
DELTA_4 C,G,S 0 - 15.5 31 Represents the

dB difference between
0.5 dB the strongest and
increment 4th strongest pilot
(0-31)
DELTA_5 C,G,S 0 - 15.5 31 Represents the

dB difference between
0.5 dB the strongest and
increment 5th strongest pilot
(0-31)
DELTA_6 C,G,S 0-15.5 dB 31 Represents the

0.5 dB difference between
increment the strongest and
(0-31) 6th strongest pilot
Border Sector Parameters
BorderRefPilotRTD C,G,S Word 16 Operator See description

Thresh (1/8 chips) Specific below
BorderTargetCell_Inter C,G,S BorderTargetCellIDList

SystemCellID

Table 2-8
PILOT DATABASE MO
Type Value
(DECIMAL)
BorderTargetCell_Mark C,G,S BorderTargetCellIDList

etID
BorderTargetCell_Switc C,G,S BorderTargetCellIDList

hNumber
EHHO Parameters
EHHOTargetCell_InterS C,G,S EHHOTargetCellIDList

ystemCellID
EHHOTargetCell_Marke C,G,S EHHOTargetCellIDList

tID
EHHOTargetCell_Switc C,G,S EHHOTargetCellIDList

hNumber
EHHOFerMaxFwd C,G,S 0 - 99% 99% Value shown

disable EHHO
EHHOFerMaxRev C,G,S 0 - 99% 99% Value shown

disable EHHO
EHHOFerModFwd C,G,S 0 - 99% 99% Value shown

disable EHHO
EHHOFerModRvs C,G,S 0 - 99% 99% Value shown

disable EHHO
EHHO_Window C,G,S 1 - 254 254 Value shown

disable EHHO
EHHOTCGMAX C,G,S 0 - 99% 99% Value shown

disable EHHO
EHHOEBNOMAX C,G,S 0 - 99% 99% Value shown

disable EHHO
NeighborList C,G,S word 32 Array, up to 20

neighbors
Q13ReducedRate C,G,S ACLRL_Q13 Disables Smart

REDUCEDR rate ie: gives best
ATE_LEVEL 13k voice quality
_0

Table 2-8
PILOT DATABASE MO
Type Value
(DECIMAL)
VirtualPilotPNList C,G,S An Array of PNs
FlexiblePwrCtrlID C,G,S 0-9 0
HardHandoff3G2GEnab C,G,S 0 (false) Defines 3G to 2G HO boundary. If

led or 1 (true) all sectors in Active Set have this
enabled, any calls will be switched
to 2G.
MaxNumInitLinks C,G,S 1-6 4 Allows up to 4 links

for IS95B Channel
Assignment in to
SHO
MCTA
CapacityThreshold C,G,S 0-64 64 Used by MCTA in

Selector. Default
gives even loading
across carriers
FrequencyPriority C,G,S 0-255 0 Used by MCTA in

Selector. Default
gives even loading
across carriers

BTS static datafill

This section describes the RF or air interface related static datafill at the
BTS. This section does not address other versions of datafill (OA&M,
connectivity, and so on). RF related parameter values are suggested starting
points for network optimization and are not to be hard-and-fast rules.
With NBSS 10.1 and later software releases, additional Managed Objects
have been included. These are described in the following diagram:
Figure 2-2
New Managed Object Relationships for NBSS 10.1
BTSCall- Advanced FA Advanced - Power M gmnt

Processing M O MO F1 Sector MO MO
F2
M CBTS F3
RO OT
SubSystem
RFM M O RadioSector
MO
Other M Os not shown

for clarity
The following tables will provide the parameter details by Managed Object.

Table 2-9
BTSC MO (Legacy), BTSCallProcessing MO (MetroCell), and FA MO parameters

Type Value
BTSC MO (Legacy Product) and BTSCallProcessing MO (MetroCell)
Access Parameters
AuthEnabled C,G,S 0 or 1 0 disabled
RandcRange C,G,S Min 1-254 Min = 1

Max 2-255 Max = 255
RandUpdateInterval C,G,S 15 - 1440
RandUpdateEnable C,G,S 0 or 1 0 disabled
System_ID (SID) C,G,S 0-32,767 system SID=0 is reserved

specific
Network_ID C,G,S 0-65,535 system NID=0 and 65,535

reserved
specific
MULT_SIDS C,G,S 0 or 1 0 To enable mobile

crossing inter-system
(false/true) boundaries to re-
register
MULT_NIDS C,G,S 0 To enable mobile

boundaries to re-
register
ChannelListArray C,G,S See IS95B MTA specific CDMA Freq

Assignmnents for each
band class
BAND_CLASS C,G, 0-1 MTA specific 0 = Cellular

1 = PCS
OTAProtocolId C,G IS-95A MTA specific IS-95A + TSB-74 for

800 MHz
+TSB-74 J-STD-008 for 1900
or J-STD- MHz or CDMA2000
008 or
CDMA200
0
P_REV C,G 0-6 5 5=IS95B
6=1xRTT
MIN_P_REV C,G 0-6 1 for

1900MHz or 3
for 800MHz
SYS_TIME G TFU_1 or As determined by the

system time
TFU_2

Table 2-9

Type Value
LP_SEC C,G 0 - 255 13 Number of leap

seconds occurring
from start of system
time
LTM_OFF C,G,S -24 to +23 MTA Specific Offset of local time in

units of 0.5hr from
system time (GPS)
DAYLT C,G,S 0-1 False or True 0=False

1=True
Power Control Parameter
PowerControlGainOffset C,G,S -127 to 1 This parameter is now

used to control the time
+128 the BTS takes to detect
a T1 problem and wilt
the cell
Paging and Registration Parameters
MAX_SLOT_CYCLE C,G,S 0-7 2 Selects the period of

time between mobile
_INDEX observances of paging
slots
BCAST_INDEX C,G 0-7 0 Not enabled.
REG_ZONE C,G,S 0 - 4095 MTA Specific Unique zones are

identified by this
parameter and SID/
NID of the zone
TOTAL_ZONES C,G,S 0-7 MTA Specific Maximum number of

zones where the MS
can be registered. A
value 0 diables Zone
Registration
REG_PRD C,G,S 29-85 80
HOME_REG C,G,S 0 or 1 1
false/true
ZONE_TIMER C,G,S 0-7 0 Indicates the length of

the zone registration
timer. 0=1 minute
TMSI_Zone C,G,S
FOR_SID_REG C,G,S 0 or 1 1 Enabled

false/true
FOR_NID_REG C,G,S 0 or 1 1 Enabled

false/true

Table 2-9

Type Value
POWER_UP_REG C,G,S 0 or 1 1 Enabled

false/true
PREF_MSID_TYPE C,G,S
IMSI_11_12 C,G,S 0-127 0
POWER_DOWN_REG C,G,S 0 or 1 1 Enabled

false/true
MCC C,G,S 0-1023
PARAMETER_REG C,G,S 0 or 1 1 To enable mobile

false/true boundaries to re-
register
REG_DIST C,G,S 0-2047 0 No distance-based

registration
Intelligent FreqBasedPagingEnable C,G,S 0 or 1 MTA Specific 0=False

1=True
Zone Paging d
Intelligent ZoneNumber C,G,S 0-255 MTA Specific Determined by System

Operator
Zone Paging
IVSN MAX_NUM_ALT_SO C,G,S 0-7 4 4 allows for 8k, 13k,

EVRC, Is733_13k
(Max number of
alternative voice
service options a
P_REV>3 mobile is
allowed to include in
the Origination or Page
Response Msg.)
Wilting, Blossoming, or Breathing Parameters
ForwardPowerEstimatio C,G,S 0-1 1 Enabled.

nEnabled
Digital C,G,S 1 - 200 sec 2 sec

TxPowerEstimationRate
OCM Paging Congestion Control

Table 2-9

Type Value
OCM_PTM_CpuOverload C,G,S 30-75 35 Similar to

OCM_PTM_PagingMs
PagingMsgThreshold gThreshold but only
used under BTSC
overload conditions.
This value is used in
conjunction with
OCM_PTM_CpuThres
hold to activate the
throttle mechanism.
This value is used in
conjunction with
OCM_PTM_CpuThres
hold to activate the
throttle mechanism.
OCM_PTM_CpuThreshol C,G,S 80-97 % 97 % The BTSC CPU load

level before the BTSC
d is considered
overloaded. This
threshold is used in
combination with
OCM_PTM_CpuOverl
oadPagingMsgThresh
old to activate throttle
mechanism to perform
paging channel
congestion control.
OCM_PTM_PagingMsgT C,G,S 30-100 75 The paging channel

message rate above
hreshold which the paging
channel is considered
congested and the
throttle mechanism is
activated to perform
paging channel
congestion control.
OCM_PTM_RestorePagin C,G,S 4-30 secs 30 The minimum time

period that the throttle
gTimeout will be applied.
OCM_PTM_ThrottleWind C,G,S 1 to 12,

ow: ArraySize number of
array
entries
OCM_PTM_ThrottleWind C,G,S
ow:
PagingChannelMsgType

Table 2-9

Type Value
OCM_PTM_ThrottleWind C,G,S Array entry

ow: ThrottleWindow consisting
of: msg
type (see
below),
start
throttling
level (0 to
6), steps to
completelt
hrottle (0 to
6)
OCM Paging Congestion Control is outside the scope of this document. Refer to Nortel NTP 411-2133-199 DMS-
MTX Software Delta for Planners for additional information.
‘No Call Processing’ Alarm Feature
NoCallPAlarmEnabled C,G,S 0 or 1 MTA Specific 0=False

1=True
NoCallPAlarmThreshold C,G,S 0-100% 20
NoCallPAutoWiltEnabled C,G,S 0 or 1 MTA Specific 0=False

1=True
FA (Legacy) and AdvancedFA (MetroCell) Managed Objects
CDMA_FREQ No C,G 0 - 2047 MTA Specific
AllowedUsers C,G,S 0-3 3
EnableHSReverseSCHFe C,G,S 0 or 1 1 Set to True if the BTS

supports reverse SCH
ature false/true datarates greater than
the
BAND_CLASS C,G, 0-1 MTA specific 0 = Cellular

1 = PCS
RadioConfigState C,G,S Voice_2G,Voic Mixed_and_R Sets allowed

e_2G_3G,Dat combinations of 2G/
a_3G,Mixed,M
RM 3G/Voice/Data.
ixed_and_RR
M

Sector (Legacy) and Advanced Sector (MetroCell) Managed Object

Table 2-10
Sector MO (Legacy) and Advanced Sector MO (MetroCell) Parameters
Seector (Legacy) and Advanced Sector (MetroCell) Managed Object

Type Value
OCNS Parameters
OCNS parameters are now set within the ActivateFCH/SCH/OCNS Actions.
Overhead Channels
PilotGain C,G,S 0 - 255 176 Sets Pilot Output Power
SyncGain C,G,S 0 - 255 70 Sets Sync Output Power
PagingGain C,G,S 0 - 255 148 Sets Paging Output

Power
HandoffBlocking C,G,S 0- 4194303 0 Sets fwd link handoff

Threshold bits blocking equal to digital
squared reference
CallBlocking C,G,S 0- 4194303 387,000 Establishes threshold at

Threshold bits which new calls will be
squared blocked
MinPilotToTotal C,G,S -255/16 to -211 Sets the digital reference,

PwrRatio 0/16 dB which is used for handoff
and call blocking
FwdDistribution C,G,S units of Value from lab can be

Delay 1/8 PN calibrated on site
chips
RvsDistribution C,G,S units of Value from lab can be

Delay 1/8 PN calibrated on site
chips
Access and Power Control Parameters
Open Loop NOM_PWR C,G,S -8 to +7 dB 0 This parameter is present

Power in both the BTS and the
Control SBS datafill
INIT_PWR C,G,S -16 to +15 -6 dB

dB
PWR_STEP C,G,S 0 - 7 dB 3 dB

Table 2-10

Type Value
NUM_STEP C,G,S 0 - 15 3 (3 + 1) = 4 access probes

per sequence
NOM_PWR_EXT C,G,S 0 -1 0 Used for low power

access applications
Forward PWR_REP_ C,G,S 0 - 31 2 Only applies to RateSet1

Loop Power THRESH (8 kbps)
Control
PWR_REP_ C,G,S 0 - 15 15 Only applies to RateSet1

FRAMES (8 kbps)
PWR_THRESH_ C,G,S 0-1 1 = True Only applies to RateSet1

ENABLE (8 kbps)
POWER_PERIOD_ C,G,S 0-1 0 (False) Only applies to RateSet1

ENABLE (8 kbps)
POWER_REP_ C,G,S 0 - 31 0 0 frames; Only applies to

DELAY RateSet1 (8 kbps)
RL Power RLGainTrafficPilot C,G,S -32 to +31 0

Control in 1/8dB
Access ACC_CHAN C,G,S 0 - 31 0 1 Access Channel

Parameters
ACC_TMO C,G,S 0 - 15 3 (2+3), 400ms

(x80ms)
BKOFF C,G,S 0 - 15 1 (1+1) slot delay
MAX_CAP_SZ C,G,S 0-7 3 Changed to accomodate

IVSN feature
MAX_REQ_SEQ C,G,S 0 - 15 2
MAX_RSP_SEQ C,G,S 0 - 15 2
MSG_PSIST C,G,S 0-7 0
PAM_SZ C,G,S 0 - 15 Depends Depends on

on Cell AccessChannelAcquisitio
Radius nSearchWidth
PROBE_BKOFF C,G,S 0 - 15 0 (0+1) slot delay

Table 2-10

Type Value
PROBE_PN_RAN C,G,S 0 - 15 0
PSIST0_9 C,G,S 0 - 63 0 ACCOLC (0-9) are all

allowed to transmit
PSIST10-PSIST15 C,G,S 0-7 0 ACCOLC (10-15) are all

allowed to transmit
REG_PSIST C,G,S 0-7 0
Azimuth C,G,S 0-359 Network

Specific
System Determination and Acquisition
PILOT_PN C,G,S 0 - 511 See Note PN plan as determined

by local MTA
PRAT C,G 0-3 1 Half-rate paging
ChannelLIst C,G,S list of

channel
numbers
ExtChList RC_QPCH_Indicat C,G,S 0 or 1 0

or
ExtChList ExtChannelArray C,G,S list of

channel
numbers
RC_QPCH_CAP_I C,G,S 0 or 1 0
ND
ServiceRedirectio C,G,S
nList
SectorID C,G, 0=Omni,

1=Alpha,
2=Beta,
3=Gamma
SectorCellID C,G 0-65535
SyncChIndicator C,G 0 or 1 1
PagingChannels C,G Array (1..7) 1

Table 2-10

Type Value
NumberOfQPCH C,G,S 0-3 0
QPCH_Rate C,G,S 0=4800, 0

1=9600
QPCH_PowerLeve C,G,S 0-7 1

lPage
SDB_Supported C,G,S 0 or 1 0
PAGING_CDMA_F C,G,S 0-2047 Network

REQ Specific
EXT_CDMA_FREQ C,G,S 0-2047 Network

Specific
RC4_Preferred C,G,S 0 or 1 0
Registration Parameters
BASE_CLASS C,G,S 0-1 Public

Macrocellul
ar
BASE_LAT C,G,S -1296000

to
+1296000
BASE_LONG C,G,S -2592000

to
+2592000
RESCAN C,G,S 0 or 1 0
Handoff Parameters
Pilot Search SEARCH_WIN_A C,G,S 0 - 15 5 20 PN chips (must be

Parameters (4 - 452 PN optimized)
chips)
SEARCH_WIN_N C,G,S 0 - 15 10 100 PN chips (must be

(4 - 452 PN optimized)
chips)
SEARCH_WIN_R C,G,S 0-15 14 320 PN chips

(4 - 452 PN
chips)

Table 2-10

Type Value
NGHBOR_MAX_ C,G,S 0 - 15 0
AGE
Pilot T_ADD C,G,S 0 - 63 28 -14 dB

Strength (-0.5x dB)
Parameters
T_DROP C,G,S 0 - 63 32 -16 dB

(-0.5x dB)
T_COMP C,G,S 0 - 15 2 1 dB
(x0.5dB)
T_TDROP C,G,S 0 - 15 3 4 seconds
Acquisition Parameters
AccessChannel C,G,S 25 - 4095 Depends

AcquisitionSearch in units of on cell
Width 1/8 PN radius
chips
AccessChannel C,G,S 25 - 4095 500 62.5 chips. Determines

Demodulation in units of the window for usable
SearchWidth 1/8 PN multipath signals
chips
TrafficChannel C,G,S 25 - 4095 500 62.5 chips. Determines

AcquisitionSearch in units of the window for usable
Width 1/8 PN multipath signals
chips
TrafficChannel C,G,S 25 - 4095 500 62.5 chips. Determines

Demodulation in units of the window for usable
SearchWidth 1/8 PN multipath signals
chips
ExtendedCellRing C,G,S BandClass Bits 0-3 Sector

s , Bits 4-15 cell
CDMAFreq Bits 16-26 freq
, BASE_ID, Bits 27-31 Band
Sector
Access Robustness Package
ACC_ENT_HO_OR C,G,S 0 or 1 1 Allow Access Entry

DER Handoff for IS95B and
IS2000 Mobiles

Table 2-10

Type Value
ACCESS_ENTRY_ C,G,S Bit- MTA Set to a ‘1’ to allow

HO_LIST mapped Specific Access Entry HO for
array corresponding neighbor.
correspond eg: If NL is 15 entries,
ing to NL and want to allow AEHO
for this for 1st nine then, set to
sector ‘111111111000000
ACCESS_HO C,G,S 0 or 1 1 Allow Access Handoff for

IS95B and IS2000
Mobiles
ACCESS_HO_ALL C,G,S Bit- MTA Set to a ‘1’ to allow

OWED_LIST mapped Specific Access HO for
array corresponding neighbor.
correspond eg: If NL is 15 entries,
ing to NL and want to allow AHO
for this for 1st seven and last two
secto then, set to
‘111111100000011
Extended Neighbor List Parameters (per entry)
NGHBR_CONFIG C,G,S 0-3 0
NGHBR_PN C,G,S 0-511
SEARCH_PRIORIT C,G,S 0-3 1

Y
NghbrFreqValid C,G,S 0 (false) or 0

1(true)
NghbrFreqInfo C,G,S
Traffic Management
MCTAThreshold C,G,S 0-255 64
MCTAPriority C,G,S 0-255 0
MaxVoiceResourc C,G,S 0-100% 100 No partitioning for Voice/

es Data
MaxDataResource C,G,S 0-100% 100 No partitioning for Voice/

s Data

Table 2-10

Type Value
MaxDataFCHReso C,G,S 0-100% 100 All data resources

urces available to FCH
Global Service Redirection (GSR)
Transmit C,G,S 0(false) or 0

1(true)
RedirectedAccess C,G,S 16 bit word Each bit in the word 16

represents an access overload
OverloadClasses class of mobile stations from 0 to
15. The Most Significant Bit
(MSB) shall be transmitted first,
therefore the MSB relates to
mobile station 0. If one of these
bits are set to 1, the mobiles
associated with this overload
class are to be redirected.
ReturnIfFail C,G,S 0(false) or See IS95B 7.7.2.3.2.18 or

CDMA2000 3.7.2.3.2.18
1(true)
DeleteTMSI C,G,S 0(false) or See IS95B 7.7.2.3.2.18 or

1(true) CDMA2000 3.7.2.3.2.18
ExcludeRedirectio C,G,S 0(false) or See IS95B 7.7.2.3.2.18 or

n 1(true) CDMA2000 3.7.2.3.2.18
RecordType C,G,S 1 or 2 1=Analog redirection or

2=CDMA redirection
AnalogRedire EXPECTED_SID C,G,S 0-32,767 See IS95B 7.7.2.3.2.18 or

ctionRecord CDMA2000 3.7.2.3.2.18
AnalogRedire IGNORE_CDMA C,G,S 0(false) or See IS95B 7.7.2.3.2.18 or

ctionRecord 1(true) CDMA2000 3.7.2.3.2.18
AnalogRedire SYS_ORDERING C,G,S 0-5 ObtainEitherSystemViaCustom,

ObtainSystemAOnly,
ctionRecord ObtainSystemBOnly,
ObtainSystemAFirstThenB,
ObtainSystemBFirstThenSyste
mA,
ObtainEitherSystem
CDMARedirec BAND_CLASS C,G,S 0 or 1 See IS95B 7.7.2.3.2.18 or

tionRecord CDMA2000 3.7.2.3.2.18
CDMARedirec EXPECTED_SID C,G,S 0-32,767 See IS95B 7.7.2.3.2.18 or


Table 2-10

Type Value
CDMARedirec EXPECTED_NID C,G,S 0-65,535 See IS95B 7.7.2.3.2.18 or

CDMARedirec CDMA_CHAN_List C,G,S List of See IS95B 7.7.2.3.2.18 or

tionRecord Channel #s CDMA2000 3.7.2.3.2.18
Extended Global Service Redirection (EGSR)
Transmit C,G,S 0(false) or 0 See CDMA2000 3.7.2.3.2.27

1(true)
RedirectedAccess Each bit in the word 16

OverloadClasses represents an access overload
class of mobile stations from 0 to
15. The Most Significant Bit
(MSB) shall be transmitted first,
therefore the MSB relates to
mobile station 0. If one of these
bits are set to 1, the mobiles
associated with this overload
class are to be redirected.
ReturnIfFail C,G,S 0(false) or See CDMA2000 3.7.2.3.2.27

1(true)
DeleteTMSI C,G,S 0(false) or See CDMA2000 3.7.2.3.2.27

1(true)
RedirectPRevInclu See CDMA2000 3.7.2.3.2.27

ded
ExcludingPRevInd See CDMA2000 3.7.2.3.2.27

icator
RedirectPMin See CDMA2000 3.7.2.3.2.27
RedirectPMax See CDMA2000 3.7.2.3.2.27
RecordType See CDMA2000 3.7.2.3.2.27
AnalogRedire EXPECTED_SID C,G,S 0-32,767 See CDMA2000 3.7.2.3.2.27

ctionRecord
AnalogRedire IGNORE_CDMA C,G,S 0(false) or See CDMA2000 3.7.2.3.2.27

ctionRecord 1(true)

Table 2-10

Type Value
AnalogRedire SYS_ORDERING C,G,S 0-5 ObtainEitherSystemViaCustom,

ctionRecord ObtainSystemAOnly,
ObtainSystemBOnly,
ObtainSystemAFirstThenB,
ObtainSystemBFirstThenSyste
mA,
ObtainEitherSystem
CDMARedirec BAND_CLASS C,G,S 0 or 1 See CDMA2000 3.7.2.3.2.27

tionRecord
CDMARedirec EXPECTED_SID C,G,S 0-32,767 See CDMA2000 3.7.2.3.2.27

tionRecord
CDMARedirec EXPECTED_NID C,G,S 0-65,535 See CDMA2000 3.7.2.3.2.27

tionRecord
CDMARedirec CDMA_CHAN_List C,G,S List of See CDMA2000 3.7.2.3.2.27

tionRecord Channel #s
TXPwrFilterDecay No C,G 0-16 9 10 second time constant

Const
Table 2-11
Radio Sector Managed Object
Radio Sector (MetroCell) Managed Object

Type Value
BBWStepPeriod C,G,S 1-20 1 100ms from lab

(units of
100ms)
RecPowerDecay C,G,S 0-10 0 Minimum filtering to

Exponential see RX power “as is”
TPTLEnabled C,G,S 0 or 1 1 Enabled

(false/
true)
—sheet 1 of 4—

Table 2-11

Type Value
TPEFilterDecayEx C,G,S 0-16 3 155ms time constant

ponential
ChannelizedPower C,G,S 0 or 1 1 Enable or disable the Tx

LimitingEnabled (false/ ASIC power limiting
true) functions
PeakPowerRedu C,G,S 0 or 1 see note Enable or disable the Tx

ctionEnabled (false/ ASIC power reduction
true) functions. Must be
enabled for MFRM and
disabled otherwise
DPMTxConfig C,G,S 0-4 1 determined by config
DPMRxConfig C,G,S 0-9 1 determined by config
TxGainOffset C,G,S -320/16 to 0 Assumes no Gains/

+320/16 Losses external to
dB BTS
Rx0GainOffset C,G,S -480/16 to 0 Assumes no Gains/

dB BTS
Rx1GainOffset C,G,S -480/16 to 0 Assumes no Gains/

dB BTS
Rx0AttenOffset C,G,S -63 to 0 Assumes std noise

+63dB figure/IP3 tradeoff
Rx1AttenOffset C,G,S -63 to 0 Assumes std noise

+63dB figure/IP3 tradeoff
PowerLimitingM C,G,S 0 to 2 2 0=CompositePowerLi

ode miting only,
1=CompositeAndPerC
arrierPowerLimiting,
2=CompositeAndPerC
arrierWeightedPowerL
imiting
—sheet 2 of 4—

Table 2-11

Type Value
HighPowerCarri C,G,S 0 or 1 0 False

er (false/
true)
Count C,G, 0 to 3 Settable thru

ChangeTxPowerDistri
bution Action
CDMA_FREQ C,G, CDMA Settable thru

Ch# ChangeTxPowerDistri
bution Action
PercentCarrierT C,G,S 100/10 to 1000 100% = 1/3rd of the

XPower 3000/10% MFRM power. Settable
thru
ChangeTxPowerDistri
bution Action
CarrierPowerLim C,G, 0 to 200% 100 Power limiting biased

itingBias equally off all carriers.
Settable thru
ChangeTxPowerDistri
bution Action
SectorID C,G, 0=Omni IDs the sector that the

1=Alpha RadioSector
2=Beta represents. Used to
3=Gama associate RadioSector
and PMs.
RxAutoCalibrati C,G,S 0 or 1 0 False. Rx0/

onEnabled (false/ Rx1GainOffset are
true) used to manually
balance Rx diversity
paths. May change to
true after autocal is
tested
RFMTxDelayCo C,G,S -1000000 0 Assumes no external

mpensation to equipment introducing
1000000 prop delay
nS
—sheet 3 of 4—

Table 2-11

Type Value
RFMRxDelayCo C,G,S -1000000 0 Assumes no external

mpensation to equipment introducing
1000000 prop delay
nS
—sheet 4 of 4—
Table 2-12
TCC/RFU MO (Legacy) and PowerManagement MO (MetroCell) parameters

Type Value
Wilting, Blossoming, and Breathing Parameters
WiltBlossStepSize C,G,S 1/16 to 4

48/16dB
WiltBlossEnabled C,G,S 0 - 1 False/ 1

True
BreathingStepSize C,G,S 1/16 to 4

48/16dB
BreathingDelta C,G,S 0/16 to 192 12dB increase over the

255/16dB noise floor.
ReverseLinkBalanci C,G,S 0/16 to 192

ngDelta 192/16 dB
BreathingEnabled C,G,S 0-1 0 (False) Disabled (Strongly

recommended that this
parameter NOT be
enabled.)
TXAttenNormal C,G,S 0/16 to 144 800MHz SFRM=144,

1120/16 1900MHz SFRM=162 ,
MFRM=208
ReverseHandoffBloc C,G,S 0-100 (%) 0 Not currently supported

kingThreshold on the reverse link.

Table 2-12

Type Value
ReverseCallBlocking C,G,S 0-100 (%) 0 Not currently supported

Threshold on the reverse link
CarrierRXPowerDiffe C,G,S 0/16 - 240 15dB TBV

renceThreshold 1120/16
dB
Rx0ReverseLinkNois C,G,S 0/16 - 640/ 0 no noise injection under

eInjection 16 dB normal conditions
Rx1ReverseLinkNois C,G,S 0/16 - 640/ 0 no noise injection under

eInjection 16 dB normal conditions
CarrierRXPowerDiff C,G,S 1-3600 30 only alarm if difference is

AlarmTimeThreshol secs present for 30 Secs TBV
d


3-1
Chapter 3
Data Collection 3
To correctly optimize a network, there is a tremendous amount of data that
needs to be collected and analyzed. This data is extracted from mobile drive
test equipment and from SBS logging. Mobile drive test gear provides you
with the information the mobile “sees” throughout the network. The SBS logs
provide the information as to how the system “sees” the mobile. This chapter
discusses the data collection from both the mobile point of view and the SBS
logs.
RF Performance Indicators
There are certain CDMA measurements that must be taken throughout the
network on a regular basis. While these measurements are not the only
measurements made, they are the primary gauges used to guide optimization
and troubleshooting.
Frame Error Rate

Frame Error Rate (FER) is the measure of the percentage of frames received
the network cannot use. This measurement is a call quality statistic measured
on the forward (FFER) or reverse (RevFER) links. A high FER is normally
attributed to not enough forward or reverse link coverage, or high
interference.
Mobile Receive Power

Mobile receive power is a coverage related measurement taken from the
Automatic Gain Control (AGC) circuitry of the mobile. This measurement,
normally shown in dBm, is a received measurement containing all RF within
the bandwidth of the mobile’s receiver.
Pilot Strength (Ec/Io)

Ec/Io is the ratio of the average energy per chip for the desired pilot channel
to total signal and interference. This measurement foretells the readability of
the associated traffic channels by measuring the cleanness of the pilot
channel. This value is the guide that triggers handoff and it is common for a

3-2 Chapter 3 Data Collection
mobile to fail to originate a call in an area with excessively low Ec/Io. Any
measured pilot has a matching Ec/Io value.
Handset Transmit Power (TXPO)

Handset Transmit Power is a measurement of the RF output power of the
mobile’s transmitter. This value includes the combined effects of the initial
power setup during open loop power control and power increments related to
closed loop power control. An increasing TXPO reading indicates the mobile
is working harder to maintain the reverse link. This in turn causes this mobile
to become a greater source of interference to other mobiles within the area.
Values of TXPO can vary from -50dBm near a site to +23dBm in bad
coverage.
Transmit Gain Adjust

This value is the sum of all closed loop power control commands received
from the base station from the beginning of the call. This value is typically
negative and indicates a problem area when this value drifts positive.
Ew/No Setpoint
This value is the ratio of Walsh Symbol Energy to Total Noise Power. This
measurement is only logged from the BSM and is a measure of the variable
setpoint used in Reverse Outer Loop Power control. This setpoint adjusts
every 1-2 seconds according to the FER on the reverse traffic channel. The
objective FER is normally set to a composite 1.5%.
Data Collection Tools

The Nortel Networks CDMA product provides extensive logging capabilities
for system optimization. The purpose of data collection is to log appropriate
attributes of mobiles on one or more SBS shelves through heavy traffic
periods or under simulated load conditions. This method produces large
quantities of statistically valid data (except for simulated case) and reflects
real traffic use patterns. Many performance attributes can be queried through
SBS logging with flexibility to perform:
• Per-SBS Shelf logging

• Per-Sector logging
• BTS Diagnostic/BTS Real-Time logging
All log packets contain the MIN of the mobile so one can decide to analyze a
distinct mobile. If an identified customer is experiencing poor performance,
one can track locations where calls were made and determine if these calls
were made in areas of poor performance earlier identified for troubleshooting
(feedback to customer).
These real-time logging methods can reduce the amount of drive testing
required for optimization. Real-time logging is better for parameter tuning

because it includes large quantities of data and real traffic patterns. Small
changes in these patterns are difficult to detect from drive testing and these
changes can get lost because of environmental differences between drive
tests.
However, some drive testing is required in the following set of conditions:
1. Detailed troubleshooting where attributes that can be logged at the

mobile are needed or, when both sides of messaging is needed
2. Parameter tuning requires metrics that can only be logged at the mobile.
Available Tools for optimization include:
• Neighbor List Tuning Tool in Nortel Networks RF Optimizer or if RFO is

not available, custom tool designed to analyze SBS Neighbor List Tuning
Array (NLTA)
• Unconditional SBS logs for per SBS shelf forward FER, handoff
statistics, traffic channel gain, Ew/No, drops, histograms of traffic
channel gain and Ew/No, per sector traffic gain, Ew/No, FER, Ec/Io, error
strings linked to callId and cell/sector, voice activity factor calculation
and so on.
• BTS Real-Time logging for power histogram, TPTL analysis, power/
NumOfLinks at blocking threshold
• Commercially available mobile data collection tools
Simulated Loading
Many customers require that optimization be carried out at the planned traffic
loading. Beware that this procedure can mask "stray" pilots because the Ec/Io
can be less than T_ADD when applying a load. For this reason, at least one
pass through the network is preferred without loading. The following
methods allow a simulated load to be applied which approximates an even
distribution of real users.
Forward Link
Forward link loading is accomplished through the use of OCNS (Orthogonal
Channel Noise Source). In NBSS 10. all OCNS settings are made via the
Advanced Sector configuration menu of the appropriate BTS sector. This can
be initiated in the BSM GUI by selecting the Advanced Sector MO (left-
mouse button) then right-mouse button to select General Operations from the
pull-down menu. You will then see the following window:

This is the configuration menu where Fundamental Channel (Fch) and

Supplemental Channel (Sch) OCNS is activated and very importantly,
deactivated.
For this example, select the ‘ActivateFchOCNS’ option to simulate Fch

OCNS. A new window will open as shown below:

OCNS Gain Mode - Set to Variable or Constant

OCNS Radio Configuration - (1=RS1, 2=RS2, 3=RC3, 4=RC4 & 5=RC5)
Number of Walsh Codes
Number of users per Walsh Code
Nominal Gain per User
In NBSS 10.1 the number of channel elements is automatically chosen, based

on the number of Walsh Codes selected above, since there are a maximum of
3 Walsh Codes per channel element.
So this is what the OCNS feature does. Assume the following entered values.
Note values are in decimal.
OCNS Gain Mode - Set to Variable (simulate Voice Activity)

OCNS Radio Configuration - 2 (for RS2, 13kb)
Number of Walsh Codes - 6
Number of users per Walsh Code - 3
Nominal Gain per User - 128
Setting the OCNS Gain Mode to ‘variable’ activates a voice activity

simulation on the Walsh Codes. This should be set to ‘constant’ for Sch
simulation.
OCNS Radio Configuration set to 2 or RS2 will simulate 13kb users, with
Full Rate frames at 14,400 bps, Half Rate at 7,200 bps etc. These rates will
follow the variable gain mode setting for voice activity simulation.
Number of Walsh Codes = 6 will reserve two channel elements (CE) for this
test, since there are a maximum of 3 Walsh Codes available from each CE.
With Number of Users per Walsh Code set to 3 and Number of Walsh Codes
above set to 6 then we will be simulating 3 x 6 = 18 users.
Nominal Gain per User will be the digital gain units for each one of these 18
simulated users. In this, from DGU = 128, we can calculate the absolute peak
power as follows:
Peak Power of each simulated user = 1282 x 4 = 1.02 watts

2542
This is the peak power and does not include voice activity factor. With 45%
VAF this average power per user would be 1.02 x 0.45 = 0.46 watts
(above assumes TPTLTargetPowerOffset = 0)

Now let’s look at an actual simulation for RS1, RS2 and RC3 for voice
applications on an 800MHz Metrocell BTS:
Before we begin the calculations, we must make some assumptions:

Table 3-1
Metrocell 800MHz and System Information
MC BTS 800 Total Tx Power Available 19.67 watts
Suggested Call Blocking Threshold for datafill 387,000 16.0 watts

(based on MPTTPR = -211 and PilotGain=176)
Total Overhead Power (Pilot, Paging and Sync) 3.6 watts

(based on PilotGain=176, Sync=70, Paging=148)
Assumed Sectors per User 2.25
Table 3-2
Capacity Assumptions from Field Trials
Capacity RS1 RS2 RC3
BTS Capacity per Sector per Carrier (for 100% 24 13 35 Simultaneous

Blocking) Users
BTS Capacity per Sector per Carrier (for 1% 15.3 6.61 24.6 Erlangs
Blocking)
The 1% blocking values in the above table come directly from the Erlang B
table, using the 100% values as the number of servers. The values are also
based on ‘primary’ users, not including soft handoff users. We will use the
1% values to calculate the required OCNS power since we are effectively
saying that for example, in RS1 we can support an average 15.3 primary users
at 1% blocking.
The ‘Traffic Power per Link’ for all radio configurations can be calculated
from the 100% blocking capacity and the Call Blocking Threshold, as
follows:
Traffic Power per Link = CallBlockingThreshold(w) - OverheadPower

100% Blocking Capacity
For example RS1:

RS1 TrafficPower per Link = 16 - 3.6 = 0.517 watts

24
We then need to apply the 45% voice activity factor to the above value to get
the Traffic Power per Link including VAF; in this case for RS1 0.517 x 0.45
gives 0.232 watts per link.
Table 3-3
Traffic Power per Link
RS1 RS2 RC3
Traffic Power per Link (incl 0.232 watts 0.43 watts 0.16 watts
VAF
Given the above information, we now need to calculate the total number of
links (primary and secondary, based on sectors per user) at 1% blocking, as
this is the amount of OCNS load we require.
Table 3-4
Capacity RS1 RS2 RC3
BTS Capacity per Sector per Carrier (for 1% 15.3 6.61 24.6 Erlangs or
Blocking) Primary Users
Sectors per User (SPU) 2.25 2.25 2.25 SPUs
Total Number of Links including Primary and 34.4 14.87 55.35

Secondary (SHO) users at 1% blocking
We now need to account for the expected number of drive test mobiles, since we do not need to
generate OCNS power for them (eg: 2)
Total number of Links needed to be simulated by 32.4 12.87 53.35 OCNS users
OCNS for 1% blocking
Traffic Power per Link (incl VAF) 0.232 w 0.43 w 0.16 w Traffic Power
per Link (incl
VAF
OCNS power required for radio configuration 7.5 w 5.5 w 8.5 w
Sector Loading (incl 3.6 watts Overhead) 11.1 w 9.1 w 12.1w
OCNS Sector Loading as percentage of Call 69% 57% 75%

Blocking Threshold (16 w)

From the above, we must now calculate the necessary OCNS parameters to
initiate OCNS transmission from the chosen sector(s).
Table 3-5
Calculation of required OCNS power
RS1 RS2 RC3
Total number of Links needed to be simulated 32.4 12.87 53.35

by OCNS for 1% blocking
Traffic Power per Link (incl VAF) 0.232 w 0.43 w 0.16 w
OCNS power required for radio 7.5 w 5.5 w 8.5 w

configuration
Table 3-6
OCNS power based on entered parameters
BSM OCNS Parameters RS1 RS2 RC3
OCNS Gain Mode Variable Variable Variable
OCNS Radio Configuration 1 2 3
Number of Walsh Codes 6 6 6
Number of users per Walsh Code 5 2 9
Nominal Gain per User 95 128 75
Voice Activity Factor (variable mode) 45% 45% 45%
Output power of OCNS 7.7 w 5.5 w 8.5 w
What’s important here is the amount of power that is generated by the OCNS
function and not so much what is entered in the table. You will notice that the
output powers in Table 3.6 closely match the calculated powers in Table 3.5
Reverse Link
A reverse link load can be crudely simulated by degrading the reverse link
according to the following equation:
Degradation (dB) = log10(1 - load)
where load is the fraction of pole capacity that the system is carrying (for
example with 50% load, the required attenuation is 3dB total).

Drive Testing and SBS Logging 3-9
Note: Remember to allow for the load that the test mobiles generate,
meaning the actual attenuation applied must be less than 3dB.
Reverse link loading is accomplished by one of four methods:
1. Attenuate at the mobile (TX path only - requires that uplink and downlink
are separated using duplexers).
Note: This method is the Nortel Networks preferred method. Shielded
boxes with attenuators for both reverse link loading and in-building
penetration are built for this purpose.
2. Attenuate at the BTS.

Note: Beware that, if the attenuator cannot easily be placed ahead of the
first active element, the attenuation value required needs to be calculated
so that the system noise figure increases by the required degradation.
3. Use the internal attenuator (the "wilting" attenuator) at the BTS.

Note: This method is not a very accurate method.
4. Do not degrade the reverse link but apply an offset during the data
processing
Note: Not recommended because an optimistic dropped call rate is
falsely obtained.
Drive Testing and SBS Logging

Note: For purposes of explanation, this document uses information
related with the Grayson Surveyor 32* drive testing tool. The guidelines
described in this document can be applied to most, if not all,
commercially available drive test gear.
Drive testing and its related data collection is an important part of the
optimization activity. Because of the associated cost, drive testing can be
accomplished as a last resort. The top advantage made available by drive
testing comes from its location based capability coupled with Nortel
Networks RF Optimizer for two way message logging. Many in-depth root
cause analyses depend on drive testing. Drive testing is often used for
integrating new sites into the system during network expansion also. In the
following sections, drive testing and associated logging are described.
Drive Testing
Each test van must be equipped with equipment to collect data from the test
mobile(s) and a compatible GPS receiver.

Test Van RF Configuration

Test mobiles can be placed inside the vehicle or, for more repeatable results,
an external antenna can be used. If external antennas are to be used, the most
convenient way to configure the RF connections in the test van is to use either
a car kit or a direct connection to the mobile with the external antenna. In
order to produce "in-car" signal levels with an external antenna, add
attenuation to the antenna connection to reach the customer-defined vehicle
or building penetration loss.
Table 3-7 is an example of the budget that should be calculated to correctly

determine the attenuation required:
Table 3-7
Attenuation Calculation
Losses or Gains (dB) Test Van Values (dB) “Real” In-Car Values (dB)
Antenna Gain +3.0 0
Cable and Connectors -3.0 0
Car Kit Loss -6.0 0
Test Van Antenna Gain +3.0 0
Attenuator -7.0 0
Penetration Loss 0 -10
Total -10.0 -10
The received power reading and transmit power indication of the mobiles
used in the test vans should be calibrated. The HP8924 CDMA Mobile Tester
allows this type of measurement. Even if an exact calibration is not carried
out, the different mobiles used in the test vehicles should be tested for
consistency from unit to unit.
Shakedown
Drive to each cell in the system and perform the following:
Mobile #1 : Keep the Markov call up (or start as the site is approached if it's
the first site you're testing)
1. As site is approached, confirm handoff into site

2. If sectored, drive a complete circuit around the site and confirm handoff
to all sectors
3. Check that the TX gain adjust is approximately -10 to -20 when near each
sector

Drive Testing 3-11
4. As you leave the site, confirm radius (RX power is "sensible").
Mobile #2: On each sector, power down the mobile, power up again, confirm
an origination and then release that call. Since the log is active, this captures
sync, paging, call origination and tear down (make sure some idle time is
captured on all sectors of a sectored site).
Mobile Logging: As you leave one site and head for another, stop the van in
the soft handoff area and save the logs for both. Start new logs for both
mobiles and continue to the next site (Meaning for each mobile, there is one
log per site).
Drive Routes
Drive Route Selection
Using the coverage area determined by the design tools, drive routes should
be established through the area with emphasis placed on main streets and
highways where customer traffic is high. The coverage area can be divided
into areas and for each area the drive routes defined and written down.
Each time, a route should be driven in exactly the same direction, from the
same start point to the same end point. Each route should be given a name or
number recorded on the mobile log sheet when the route is driven. The
written log is included in the log book for easy reference during data analysis.
During the drives, deviations from the routes such as detours and street
closures should be noted on the log sheets by the drivers.
Benchmark Route
A Benchmark Route can be a means of determining network performance and
consistency without the need for a full network drive. It can take the form of a
single loop that is selected to remain within the coverage area and to pass
through the different clutter types available in the network.
The Benchmark Route can take about one to two hours to drive under normal
driving conditions. It should be driven when a change is made to the network.
The data from the Benchmark Route can be compiled and analyzed to look
for trends in network performance.
Drive Testing with one cluster of cells on air

Drive testing with one cluster of cells on the air should be done with caution.
To make sure accurate data is collected you need all the neighbors of the cells
you are driving to be active and probably at least one more tier of cells
beyond that. Then it is possible that you will miss some interference
problems.
If data is collected on a small cluster, the following analysis can be

performed:

• Datafill audit/shakedown
• Per-site TX gain adjust
• SRCH_WIN_A
If drive testing is conducted on a cluster, the following must be repeated
when surrounding cells are active:
• Coverage/handoff control
• Neighbor list analysis
• SRCH_WIN_N/R
• Detailed dropped call analysis
Test Calls
With the exception of hard handoff borders, all testing should be conducted
using Markov calls. If two mobiles are used, one mobile can carry calls for
approximately a 10 minute period. At least one mobile can make short calls
(for approximately 2 mins). Do not try to re-establish a call immediately
following a dropped call. A wait period of 1 minute is necessary.
Mobile Log Mask

Table 3-8 can be used as a guide when setting up the log mask at the mobile
data collection equipment. The log mask is sent to the mobile and instructs
the mobile to deliver the specified data packets to the data collection
equipment. The following data packets must be collected from the mobile
during drive testing:
• Sparse AGC: This packet is the source of the receive power, transmit
power, and transmit gain adjust.
• Finger Info: This packet contains information about the rake receiver’s
activities and gives us the Ec/Io values used as a figure of merit. From this
information, the Best Server is determined.
• Markov Statistics: These packets are the source of the FER data.
Because FER is calculated according to statistics, the more Markov data
packets collected, the more valid the data set.
• Channel Messages: These messages are the IS-95 messages for the
Access, Paging, Forward Traffic, Reverse Traffic, and Sync channels.
This data determines call statistics such as the number of originations, the

Drive Testing 3-13
number of successful calls, the number of drops, or the number of access

failures.
Table 3-8
Mobile Log Mask
1=Log; Field Description
0= no
Log
0 Not Used
0 AGC value and Closed Loop PWR control Power control data for CD3000
0 Not Used
0 Rvs link frame rates and types Reverse link data transmitted
1 Access channel messages All access channel messages sent
1 Rvs link traffic channel messages All rvs traffic channel messages sent
1 Sync channel message entry All sync channel messages
1 Paging channel message entry All paging channel messages received
1 Fwd link traffic channel entry Fwd traffic channel messages received
0 Fwd link frame data Vocoder rate and data, forward link
0 Rvs link frame data Vocoder rate and data, reverse link
1 Temporal analyzer finger Searcher finger offset and power
0 Obsolete TA searcher data Searcher data (not used)
0 ETAK position and speed Lat, Long, and speed
1 Markov frame data rate Markov rate and error data
0 TA searcher data Searcher data (window size and position,

PN offset, signal energy measured, etc.)
0 Not Used

Table 3-8
Mobile Log Mask
1=Log; Field Description

0= no
Log
0 Vocoder error mask Vocoder rate and data with bit errors
detected
1 FM data Analog mode data
1 Access probe data Access probe information (sequence

number, probe number, Rx AGC, Tx Gain
Adjust, etc.)
1 GPS information Latitude, Longitude, speed heading, time

from the GPS receiver
0 Not Used
1 Sparse AGC AGC and Closed Loop Power Control for

QCP 800/1900
0 Not Used

SBS Logging 3-15
SBS Logging
Selector Log Mask
Table 3-9 illustrates SBS log masks that will cover most aspects of RF
optimization for 2G and 3G networks. Log masks with this many attributes
should only be enabled conditionally. (for specific mobiles as entered in the
CDMA ICC table at the MTX) For the 3G NBSS 10.1 load, new 3G SBS
Logging Attributes are available and are included below.
Table 3-9
SBS Loggable Attributes for NBSS 10.1, suggested for Optimization


3-17
Note: FCH refers to Fundamental Channel and SCH refers to

Supplemental Channel.
Loading Conditional Mobiles in to MTX ICC Tool

For ‘conditional SBS logging’ (logging of specific mobiles) follow this
procedure to enter mobiles in to the MTX ICC tool:
Note: The mobile you are attempting to enter into ICC must be
registered.
1. Logon to the appropriate MTX MAP terminal

2. Type the following command:
cdmaicc <Enter>
3. You are now in the CDMA ICC Command Interpreter Tool MTX
To list the contents of the table associated with the tool, type:
list all <Enter>
4. You should see a list of all mobiles entered previously (if any)
To put in a new conditional mobile, type:
add <Enter>

5. Enter the IMSI number (all 15 characters, without spaces) for example:
310102149711313 <Enter>
6. Make sure the following switches are set as below:

Logging ON
Reporting ON
Temp An OFF
7. Perform another ‘list all’ to make sure the mobile IMSI you entered is
indeed reflected in the list.
8. Do another ‘list all’ to make sure your changes have taken effect and that
the IMSI you entered is indeed reflected in the list.
Conditional and Unconditional SBS Logging of Active Users
Drive testing and its associated data logged at both mobile and SBS were
described in previous sections. Depending on the type of identified problems,
drive testing can be avoided because of its cost.
Diagnostic SBS logging is another optimization tool used to determine

problems without drive testing in many conditions. Diagnostic logging at the
Selector Bank Subsystem can be carried out while active traffic is carried by
the network. It is an important part of system examination and optimization.
Conditional SBS logging tracks certain MINs of mobiles and analysis is

concentrated on those suspicious mobiles. Some logs are collected on per-
SBS shelf basis, which provide flexibility in improving many system
parameters. For example, power control, handoff, and search windows are
adjusted per-SBS shelf. Using different settings on different shelves can
produce per-shelf results for comparison.
The attributes listed in Table 3-9 listed as "Required for Optimization" are
used for different aspects during optimization exercises.
Unconditional diagnostic log of RTD, NLTA plus known BTS locations can
be used to approximate mobile location on the basis of triangulation.
SBSVitalData if logged with the RTD and NLTA can map the drop locations
and often can determine the root cause.
SBSPowerControl contains the forward link digital gain and reverse link
target Ew/No. These values are used to find all locations where high forward
gain is required and to determine if this high gain is caused by vehicle speed,
traffic location within the cell, or caused by interfering sectors when in
conjunction with handoff information.

SBSErasureIndicatorBit loggable attribute contains forward link FER

information and SBSReceivedMuxDecision loggable attribute contains
reverse link FER information. Thus they can be used to monitor FER while
other parameters are adjusted, to target areas where high FER exists for
analysis/troubleshooting.
Diagnostic logging is also available at each BTS in terms of forward link

digital gains, analogue power at 100mS resolution (complements
BTSPerformanceData which only gives half-hour average),finger data, power
control bits.
Conditional Logging Procedure

Creating the Log Templates
Log templates are created using the BSM GUI and cannot be created using
CLIAPP. This procedure only needs to be conducted one time because the
template is re-used. Because the GUI is required, this procedure must be done
during a period of low BSM activity.
9. In the GUI, select the appropriate SBS subsystem (SelectorSubsystem1

MO) with the left mouse-button. More than one SBS shelf can be selected
for one template by holding down the {Shift} key and then using the left
mouse-button again. The following screen capture shows two shelves
selected. Field experience has shown that up to 4 shelves can be collected
through one template.

10. At the ‘Logging’ pull-down menu select ‘Log Creation’ and the following
window will open:
11. The SelectorSubsystem1 MOs selected will appear in the Elements view
as shown. Select each one in turn (left mouse-button) and the Loggable
Attributes will appear as shown in the following screen capture:

12. Choose the required Loggable Attribute names for the optimization task,
from Table 3-9 but using the left mouse-button. Multiple attributes can be
selected in this step. This is also the step where you can select the
‘Conditional Logging’ function. If this is not selected, the SBS activity of
all mobiles on the system will be recorded in the log file (unconditional
logging).
13. Once all the attributes are selected and the Conditional Logging flag is
enabled (if conditional logging is desired), select the ‘Generate Update
Registrations’ button and the following should occur:

14. All of the selected attributes for each one of the selected
SelectorSubsystem1 MOs will appear in the Loggable Attribute
Registrations window at the lower part of the screen. Now we can save
the template by selecting the ‘Save Log Template As...’ button.
15. This template is now stored as, for example, SBS001. Templates created
can be viewed by expanding the BSM MO and then expanding the
templates subdirectory.
Starting and Suspending the SBS Logs

At the MTX, use CDMAICC and make sure all drive test mobiles are enabled
for conditional logging. For safety, completely delete and re-enter the
mobiles. Also, because call minutes in the SBS logs need to be carefully
controlled, unless other mobiles that are in the table are not making calls,
these other mobiles should be removed from the table.
From the Unix Command Line Interpreter Application CLIAPP
Starting and Suspending Logs from the Unix Command Line Application
1. Type in cliapp from UNIX command line to get into the CLI shell.
2. At the CLI prompt, type in the following commands a few minutes before
the logs are due to be started:
> logcreate -c rfopt1.log using rfopt1.tmplt 1000 50;
> logcreate -c rfopt2.log using rfopt2.tmplt 1000 50;
and so on until the logs for all of the SBS shelves have been created.
The -c means continuous mode. The 1000 means start using a different
upload file on the BSM when the current one exceeds 1000kbyte = 1Mbyte.
The 50 means allow 50 files to be created before overwriting the first.
3. Make sure no error messages are received. Then type:

> logstat;
4. Make sure all the rfopt logs are in the ready state. The logs for each shelf
are now ready to start.
Just before the drive test crews start their first mobile log, type in the
following commands at the CLI prompt:
> logstat -r rfopt1.log;
> logstat -r rfopt2.log;
… and so on until the logs for all of the SBS shelves are started.
5. Make sure no error messages are received. Then type:

> logstat;
6. Make sure all the rfopt logs are in the active state. The logs for each shelf
are now collecting data whenever the mobiles in the CDMAICC table are
active on the system.
Note: Simple cli script files (e.g. rfopt_create.cli and rfopt_start.cli)
could easily be written to create and start all of the logs.
7. When all required data for this log session has been collected, suspend the
logs by typing:
> logstat -s rfopt1.log;
> logstat -s rfopt2.log;
... and so on until all logs have been suspended. This command stops the log.
Uploading the Logs
Uploading SBS Logs.
1. Type in cliapp to return to a CLI shell. Then type:

logstat -u rfopt1.log;
2. This command will initiate the upload of the data. Keep typing (use the
up-arrow):
logstat rfopt1.log;
3. …until the status changes from uploading to ready.

Repeat for the other logs. If scripts are created for uploading many

shelves, wait commands should be used to ensure one log completes its
upload before the next is initiated.
The log will appear in the opt/bsm/log directory with the name rfopt1.log
appended with a date/timestamp.
4. It is also a good idea to check the log status by simply typing logstat; in
CLI shell at any time. Detail descriptions of these commands can be
found by simply typing help -lp <command_name>; at a CLI shell
prompt.
Copying the Logs

It is important that the logs are copied to new filenames (and directories)
before the logs are terminated because the original logfiles are deleted when
that is done
Note: Renaming or moving the files is not enough because the BSM
tracks the files by file-id, not by filename).
The following Unix command creates a new file that is the concatenation of
the logs for all shelves and includes the date (970720 in this example):
cat rfopt?.log* > rfopt_970720.sbs
If any "stray" bsmqftptarget files are found, use the vi editor and, using the
existing records as a guide, create new logrecord entries at the end of the sbs
file (increment the logrecord number) and include the bsmqftptarget files.
These files need to be gzip'd and uuencode'd.
For the 4 shelf/4 mobile example, there are two logs per day which can be
identified by am and pm after the date.
Terminating the Logs

Make sure you have copied or concatenated (not just renamed) your files
before performing these steps!
Log Termination
1. At a CLIAPP prompt, type:

logstat -x rfopt1.log;
This command will end logging activity.
2. Repeat for the logs for all shelves.

3. Remove the log MO altogether by typing:
logdelete rfopt1.log;

This command physically removes any file(s) in which log data contained.
Once you use this command the log will be lost, so use this command with
care.
4. Repeat for the logs for all shelves.
BSM Logging Procedure using GUI

1. Logs are created and put in to ready state from the Template Editor by
opening the appropriate template and then selecting the ‘Create Log’
button at the lower part of the screen. The following window should then
open:
2. Enter the name of the SBS log file, disable the Auto-Enable function,
select Section by Size, Number of Sections = 50 and Section Size=1000.
Also select ‘Continuous’ for the Subsystem Log Full Behavior. Then
press ‘Create’. It is now necessary to open the Logging Management
function from the Logging pull-down menu of the main Navigator screen.
The Template Editor can now be closed.

3. Select ‘Loggable Attribute Only’ as the View Log Type and ‘Ready’ as
the View Log State. The logfile created should appear in the list as shown.
Select this log and to start the log, select the ‘Start/Resume’ button. By
changing the View Log State to ‘Active, the log should now show up as in
the Active (running) state. Use the ‘View Log State’ button to toggle
between different states of the log; eg: Ready, Active, Suspended,
Uploading etc.
The log can be temporarily suspended and then restarted; for example
during a meal break.
4. Finishing the log should be done with the ‘Suspend’ button and not the
‘Stop’ button.
5. Once suspended, the log(s) needs to uploaded from the SBS to the BSM.
Change the ‘View Log State’ to Suspended, select the log(s) and then
press the ‘Upload’ button. Once uploaded, the log will then be in the
‘Ready’ state. The uploaded log(s) will appear in the following BSM
subdirectory:

/opt/bsm/log
6. Once in the BSM it will be necessary to perform the same steps described
previously for naming the files and concatenating the files from various
shelf combinations into one SBS logfile.
SBS Logfile Format Conversion to ASCII Text File

Once the SBS files are created and uploaded to the BSM, there are several
different applications they can be used for, which are listed below:
1. Concatenated conditional SBS Logfile for inclusion with cooperative

Mobile Logfiles, for use in Drive Test Analysis software such as Nortel
RF Optimizer. The raw logfiles created above, once renamed to a .sbs
extension and paired with a companion mobile logfile (.mdm format) can
be inputted directly in to RF Optimizer for analysis.
2. Unconditional Neighbor List Tuning Arrays (NLTA) for use in RF
Optimizer Neighbor List Tuning Tool. Again, the RF Optimizer will
accept the raw format straight from the BSM.
3. SBS Logfiles for manual troubleshooting of network problems. SBS files
can be powerful troubleshooting tool for network problems such as hard
handoff issues. For this application, the binary data format of the raw SBS
file must be converted to a more convenient ASCII format. This can be
done using the included parsing tool ‘odlprs’ which is located in the
following subdirectory of the BSM:
/opt/bsmodl/
Locate this directory on the BSM by typing:
cd /opt/bsmodl/ <Enter>
Type the following to see the options for the odlprs tool:
odlprs -h <Enter>
Follow the example at the end of the options list, for example:
odlprs -o run1 /opt/bsm/log/cluster064001*
The odlprs tool will process the raw SBS file ‘cluster064001’ into an ASCII
representative file called ‘run1’ which will be located in the /opt/bsmodl/
directory. The following is an example of the output format from the tool:

=====================================================
Status : OLFLR_OK
Record Type : OCC_OUTBOUND_NOIS
File Offset : 777 (octal)
Time Stamp : 01/07/13-19:13:00.580
Record Length : 65
Header Length : 40
Source Node Id : 1331491 (0x00145123)
Source Port Id : 11105 (0x2b61)
Destination Node Id : 1331968 (0x00145300)
Destination Port Id : 11100 (0x2b5c)
Call Id : SID 0x4ec EntryPoint 0x1055 Count 0x0 Time
0x9f58634
PFFlags : 0x0063
Secondary Agent Id : 0x5120(Lower 2 bytes)
FramingBytes : 0xfaae
Sequence Number : 5
Resource Info : Frame Number 0x0001 Shelf Number 0x0001 Selector
Slot 0x04 DSP Id 0x02
LogData object contents:
Data Type : OCC_OUTBOUND_NOIS

Resource Type : OCC_SBS_RESOURCE
TimeStamp : 01/07/13-19:13:00.580
Source Node Id : 1331491 (0x145123)
Source Port Id : 11105 (0x2b61)
Destination Port Id : 11100 (0x2b5c)
MSG_NAME: SBCRLM_SBCQueryCellIdReq
SBCRLM_SBCQueryCellIdReq 30004 [ LVN 1 MLVN 1 NOIMSG_DISCARD Token 0 ]
{
TransactionId TransactionId 0x0006 { TransactionId 0 }
CellId CellId 0x01a9 { CellId 0x551 }
ExplicitBool CDALogging 0x01cf { Value 0 }
}
=====================================================
Status : OLFLR_OK
Record Type : OCC_INBOUND_NOIS
File Offset : 1100 (octal)
Time Stamp : 01/07/13-19:13:00.600
Record Length : 64
Header Length : 40
Source Node Id : 1331968 (0x00145300)
Source Port Id : 11100 (0x2b5c)
Destination Port Id : 11105 (0x2b61)
Call Id : SID 0x4ec EntryPoint 0x1055 Count 0x0 Time
0x9f58634
PFFlags : 0x0063
Secondary Agent Id : 0x5120(Lower 2 bytes)
FramingBytes : 0xfaae
Sequence Number : 6
Resource Info : Frame Number 0x0001 Shelf Number 0x0001 Selector

Data Management
The concatenated logfiles (rfopt_yymmdd.sbs e.g. rfopt_970720.sbs) must be
archived until data analysis. The following is a suggested plan:
4. Move (mv) the files to a directory named rfopt off the opt/bsm/log
directory.
5. Tar the files to tape.
6. Because the data analysis is done on a PC, the files can be transferred to
the analysis machine daily.
Note: In order to work with RF Optimizer, multiple copies of the log

must be made and named to match each mobile file taken that day (RF
Optimizer sorts out the correct Mins and timestamp ranges to match with
the mobile files).
The combination of these three steps make sure the files are safely kept.
A very thorough discussion on SBS logging is available from Nortel

Technical Applications and is called:
SBS Diagnostic Logging for RF Optimization

SW Release NBSS 10
Author Martin Kendall
Dated 16th July 2001
BTS Performance Logging

BTS PeformanceData is a form of Operational Measurement (OM) that is
measured within each BTS and reported to the BSSM every 30 minutes. This
document covers the Metro Cell platform only. See also NTP 411-2133-810.
Every half-hour, all BTSs can report the following information:
• Usage information
• Handoff information
• Transmit power information
• Received power information
• Call/Handoff blocking reasons
From these, we can determine or calculate:
• Total carried traffic in Erlangs or Minute of Use (including handoff)

• Primary carried traffic in Erlangs or Minute of Use (after discounting for

handoff)
• Available RF capacity
• Some transmitter faults
• Some receiver faults
A new logging option has been created specifically for BTS PerformanceData
and was modified from NBSS release 9.0 and later releases
·will result in one file for every half-hour period containing all MOs for all
BTSs
·order of BTSs/MOs will be random within each file
·file will commence with date/timestamp
·files will appear in the /opt/bsm/log directory on the BSSM
In the NBSS 9.0 and subsequent BSS Manager loads the BTS Performance
logging process has been simplified by removing the requirement to use the
BSS Manager log management framework to create templates and manage
the logs to collect BTS Performance data. Performance logging has been
consolidated and is now activated/deactivated with attributes located in the
SystemConfiguration1 MO and the BTSSubsystem Root1 MOs. The three
main steps performed to collect and process BTS Performance logs are:
•Logging activation
•Log parsing
•Log filtering (optional)
Performance Logging Activation/Deactivation

BTS performance logging can be activated on a system wide basis or on
individual BTS subsystems in the network. The new method collects the
complete suite of performance logs automatically without the need to set up a
template for each of the Managed Objects.
Individual Subsystem Activation/Deactivation

Activation/Deactivation of BTS Performance logging on an individual BTS
Subsystems is performed by toggling the ConsolidatedOMStatus attribute in
the BTS Subsystem’s Root1 MO.

From the Navigator:
1) Perform an “Edit and Update Attributes” on the Root1 MO of the BTS.
2) Change the field value for the ConsolidatedOMStatus to True or False.
3) Select the “Apply” button.
From the CLIAPP:
Perform an edit command on the individual BTS Root1 MO to set the

ConsolidatedOMStatus attribute to True or False. For example:
edit O%:CBS1:Cells1:MC1900BTS0200:MCBTSSubsystem1:Root1
ConsolidatedOMStatus = true
System-Wide Activation/Deactivation
Activation of system wide BTS performance logging is performed from the
SystemConfiguration1 MO using the OMStartupControl attribute. This
attribute contains a Boolean field for each BTS type; MiniBTS, MetroCell,
MacroBTS. Toggling the field value to True or False will update the value of
the ConsolidatedOMStatus attribute in each of the Root1 MOs for the
associated BTS type.

From the Navigator:
1) Perform an “Edit Attributes” on the SystemConfiguration1 MO
2) Change the field values to True or False for the appropriate BTS
subsystem.
3) Select the “Apply” button.
From the CLIAPP:
Perform an edit command on the SystemConfiguration1 MO to set the

desired subsystem’s field to True or False. To collect BTS Performance data
on all MetroCell BTS Subsystems use the following edit command.
edit O%:CBS1:systemConfiguration1
OMStartupControl =
MetroCellOMsActive = true
Performance Log Collection and Parsing

Data Collection
To reduce the impact that logging has on the BSS Manager performance, the
OM data is no longer parsed in real time then written to disk. The data is now
collected then written to an OM binary file that must be parsed to ASCII
format. The parsing process can be performed either manually or batch
parsed as a cron job during off peak periods. The binary data is stored in a
file located in the /opt/bsm/log/OMBinary directory using the naming
convention OMLogs-[yyymmddhhmmss]. The file is limited to a maximum
size of 10 MB.
Batch Parsing
The bsmcontrol application provides the user-interface to configure the batch

OM parsing. This allows the user to schedule the parsing at a specific time
during off-peak periods. The parser tool converts the binary file to readable
ASCII formatted files sorted by subsystem type then stores them in the /opt/
bsm/log directory. The naming convention used for the parsed file is
[subsystem-type]-[yyyymmddhhmmss]. The parseom tool keeps track of
what OMs it has parsed and only the new OMs are parsed.
To enable the batch parsing:
1. Start the bsmcontrol from unix using the command:

$ bsmcontrol –a
2. Select the “Config” tab. The Batch OM Parsing Configuration should

appear as shown below.
3. Select the “Enabled” box so that it is highlighted.
4. Enter the Minute, Hour, Day, Month,and Day of Week information for
when you want the processing to take place. For example [15 0 * * *]
would result in the logs being parsed every night at 15 minutes after
midnight.
5. Select ‘Apply’

Manual Parsing
The OMs can be parsed manually using the “parseom” command from the
unix prompt. The parsed files are stored in the /opt/bsm/log directory.
% parseom
Parsing all new OMs...done.
Log Filter
The ASCII formatted log produced by the parseom tool can be filtered to
produce a verbose version that contains the OM names as well as the values.
The output of the filter can be redirected to a file or piped through another
program. An example of the usage is shown below.
% /opt/bsm/util/bin/logfilter logfile > logfile.filtered
An example of the ‘parsed’ ASCII and resulting ‘filtered’ file from a

Metrocell are included at the end of this section.
File Content Format:
Data line format is:
for Single Value:
|DT|Seq|Value|
Where:
DT = Data Type ( 5 = 16 bit word, 7 = 32 bit word )
Seq = Sequence number
Value = value for this half hour
for an Array of Values
|DT|Seq|Count|Value|Value|…
Where:
DT = Data Type ( 3 = byte, 5 = 16 bit word, 7 = 32 bit word, 128 =

Wor16Array, 129 = Word32Array)

Seq = Sequence number
Count = number of array elements to follow
Value = value for this half hour
A partial Metro Cell Sample is shown below, for a single MO Advanced

Sector3 under AdvancedFA1
CLASS: Performance Event Reports
START:2001/02/08 13:00:00 Thu; STOP: 2001/02/08 13:30:00 Thu;
#LOGNUM|3|OPERATIONAL
|O%:CCLN-1-CBS1:CELLS-1-CELLS1:MCBTS-1-
MC1900BTS0200_WDC_KIM_3MFRM:MCBTSSUBSYSTEM-1-
MCBTSSUBSYSTEM1:ROOT-1-ROOT1:BTSCALLPROCESSING-1-
BTSCALLPROCESSING1:ADVANCEDFA-1-
ADVANCEDFA1:ADVANCEDSECTOR-1-ADVANCEDSECTOR3
|30.2.0.158.1.3|30.2.0.2.1.1|0x3FFF|44
|7|47|137
|7|48|33192
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0
|7|72|0
|7|73|0
|129|97|5 0 137 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0
|3|101|0
|3|102|0
|3|103|14

|7|104|180888
|7|105|400888
|7|106|147696
|7|107|0
|5|108|0
|128|109|2 1 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0
|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0
|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0
|5|125|0
|7|126|5
|7|127|0

|129|128|5 0 631 0 0 0
|129|129|3 0 0 0
|129|130|5 0 315 0 0 0
|129|131|3 0 0 0
|129|132|5 0 315 0 0 0
|129|133|3 0 0 0
#END
From the above example, it is necessary to decode each of the sequence

numbers to understand the contents of the file. Refer to the following tables
for a description of these sequence numbers by MO.

Advanced Sector MO
Table 3-10
Call/handoff counts and resource blocking
Seq # Name Meaning
108 FchOriginationNonBlocking2G Number of fundamental channel RC1/2 origination and

termination requests for which the BTS allocated
resources.
109 FchHandoffNoBlocking2G Number of fundamental channel RC1/2 soft handoff

requests for which the BTS allocated resources.
110 FchOriginationNonBlocking3G Number of fundamental channel voice RC3/4/5

Voice origination and termination requests for which the BTS
allocated resources.
111 FchOriginationNonBlocking3G Number of fundamental channel data RC3/4/5

Data origination and termination requests for which the BTS
allocated resources.
112 FchOriginationNonBlocking3G Number of fundamental channel RC3/4/5 origination and

Downgrade2G termination requests which were downgraded to RC1/2.
113 FchHandoffNonBlocking3GVoic Number of fundamental channel voice RC3/4/5 soft

e handoff requests for which the BTS allocated resources.
114 FchHandoffNonBlocking3GDat Number of fundamental channel data RC3/4/5 soft

a handoff requests for which the BTS allocated resources.
115 SchBurstNonBlocking3G Number of supplemental channel data RC3/4/5 burst

requests for which the BTS allocated resources.
116 SchHandoffNonBlocking3G Number of supplemental channel data RC3/4/5 soft

handoff requests for which the BTS allocated resources.
117 BlockedFchOriginations2G Number of fundamental channel RC1/2 origination and

termination requests for which the BTS failed to allocate
resources. The blocking reason from first to last element
of the array are: no physical resources (CE) were
available, no forward capacity, no reverse capacity, no
walsh code was available, no frame offset, no ecell
support, CFDS Radio Config State, CFDS HS RSCH.
—sheet 1 of 3—

Table 3-10
118 BlockedFchHandoffs2G Number of fundamental channel RC1/2 soft handoff

requests for which the BTS failed to allocate resources..
The blocking reason from first to last element of the array
are: no physical resources (CE) were available, no
forward capacity, no reverse capacity, no walsh code
was available, no frame offset, no ecell support, CFDS
Radio Config State, CFDS HS RSCH.
119 BlockedFchOriginations3GVoic Number of fundamental channel voice RC3/4/5

e origination and termination requests for which the BTS
failed to allocate resources.. The blocking reason from
first to last element of the array are: no physical
resources (CE) were available, no forward capacity, no
reverse capacity, no walsh code was available, no frame
offset, no ecell support, CFDS Radio Config State, CFDS
HS RSCH.
120 BlockedFchOriginations3GData Number of fundamental channel data RC3/4/5

origination and termination requests for which the BTS
failed to allocate resources.. The blocking reason from
first to last element of the array are: no physical
resources (CE) were available, no forward capacity, no
reverse capacity, no walsh code was available, no frame
offset, no ecell support, CFDS Radio Config State, CFDS
HS RSCH.
121 BlockedFchHandoffs3GVoice Number of fundamental channel voice RC3/4/5 soft

handoff requests for which the BTS failed to allocate
resources.. The blocking reason from first to last element
122 BlockedFchHandoffs3GData Number of fundamental channel data RC3/4/5 soft

—sheet 2 of 3—

Table 3-10
123 BlockedSchBursts Number of supplemental channel data RC3/4/5 burst

requests for which the BTS failed to allocate resources..
The blocking reason from first to last element of the array
are: no physical resources (CE) were available, no
forward capacity, no reverse capacity, no walsh code
was available, no frame offset, no ecell support, CFDS
Radio Config State, CFDS HS RSCH.
124 BlockedSchHandoffs Number of supplemental channel data RC3/4/5 soft

125 MctaFull Counts the number of times MCTA/CDA is run at the

BTS and there is no capacity for the sector (based on the
requested cell id and associated carrier). This peg is not
a direct indication of the success or failure of a call.
70 PerRingAccessCounts Extended Cell Attempts|Successes/Failures per-ring
71 RadialHandoffAttempts Extended Cell RadialHandoffAttempts
72 RadialHandoffSuccesses Extended Cell RadialHandoffSuccesses
73 RadialHandoffFailures Extended Cell RadialHandoffFailures
—sheet 3 of 3—
Note: All references to soft handoff include softer handoff.

Traffic, Throughput and Handoff

Table 3-11
Traffic, throughput and handoff
Seq OM Description Units Mapping from NBSS9 OMs
128 FrameCntF Count of all frames 20mS =FA25+FA32+FA39+FA46+FA53+FA59+

CH (Alpha) transmitted from frames FA28+
Alpha. Array has FA30+FA35+FA37+FA42+FA44+FA49+F
entries for RC1 to A51+F
RC5. A56+FA58+FA31+FA38+FA45+FA52
130 CEFrameC (Count of all frames 20mS =FA25+FA32+FA39+FA46+FA53+FA59+(

ntFCH transmitted from frames FA28+
(Alpha) Alpha)/(Way Softer). FA30+FA35+FA37+FA42+FA44+FA49+F
Array has entries for A51+F A56+FA58)/
RC1 to RC5. 2+(FA31+FA38+FA45+FA52)/3
132 PrimaryFra (Count of all frames 20mS =FA25+(FA28+FA30+FA32)/

meCntFCH transmitted from frames 2+(FA31+FA39)/ 3+(FA35+FA37+FA46)/
(Alpha) Alpha)/(Way Soft * 4+(FA53)/ 5+(FA38+FA42+FA44+FA59)/
WaySofter). Array 6+(FA49+FA51)/ 8+(FA45)/
has entries for RC1 9+(FA56+FA58)/10+(FA52)/12
to RC5.

CH (Beta) transmitted from frames FA28+
Beta. Array has FA29+FA35+FA36+FA42+FA43+FA49+F
RC5. A56+FA57+FA31+FA38+FA45+FA52

(Beta) Beta)/(Way Softer). FA29+FA35+FA36+FA42+FA43+FA49+F
Array has entries for A50+F A56+FA57)/
RC1 to RC5. 2+(FA31+FA38+FA45+FA52)/3

(Beta) Beta)/(Way Soft * 4+(FA54)/ 5+(FA38+FA42+FA43+FA60)/
WaySofter). Array 6+(FA49+FA50)/ 8+(FA45)/
to RC5.

CH transmitted from frames FA36+
(Gamma) Gamma. Array has FA37+FA48+FA55+FA38+FA43+FA44+F
RC5. A61+FA50+FA51+FA57+FA58+FA52
—sheet 1 of 3—

Table 3-11

(Gamma) Gamma)/ (Way FA30+FA36+FA37+FA43+FA44+FA50+F
Softer). Array has A51+F A57+FA58)/
entries for RC1 to 2+(FA31+FA38+FA45+FA52)/3
RC5.

(Gamma) Gamma)/ (Way Soft 4+(FA55)/ 5+(FA38+FA43+FA44+FA61)/
* WaySofter). Array 6+(FA50+FA51)/ 8+(FA45)/
to RC5.
129 FrameCntS Counter of SCH 20mS N/A

CH frames in same Frames
fashion as
FrameCntFCH
except multiply by
(SCH rate)/ (FCH
rate) e.g. if SCH rate
=153.6 then
increment at 16
frames per frame.
Array has entries for
RC3 to RC5.
131 CEFrameC Counter of SCH 20mS N/A

ntSCH frames in same Frames
fashion as
CECntFCH except
multiply by (SCH
rate)/ (FCH rate)
e.g. if SCH rate
=153.6 then
increment at 16
frames per frame.
RC3 to RC5.
—sheet 2 of 3—

Table 3-11
133 PrimaryFra Counter of SCH 20mS N/A

meCntSCH frames in same Frames
fashion as
PrimaryCntFCH
except multiply by
(SCH rate)/(FCH
rate) e.g. if SCH rate
=153.6 then
increment at 16
frames per frame.
RC3 to RC5.
—sheet 3 of 3—

Digital Power Utilization

Table 3-12
Digital power utilization
Sequence Name Meaning

Number
47 TCEForwardLinkUtilUWAvg Average of sum of digital gain squared for all

traffic channels. Automatically accounts for
subrate scaling (voice activity), power ctrl bit
boost etc.
48 OverheadForwardLinkUtilUWAvg Average of sum of digital gain squared for all

overhead channels
49 OCNSForwardLinkUtilUWAvg Average of sum of digital gain squared for all

OCNS channels
97 VoiceFchForwardLinkUtilAverage Average of sum of digital gain squared for all

fundamental voice channels. Automatically
accounts for subrate scaling (voice activity),
power ctrl bit boost etc. Array has entries for
RC1 to RC5
98 DataFchForwardLinkUtilAverage Average of sum of digital gain squared for all

fundamental data channels. Automatically
accounts for power ctrl bit boost. Array has
entries for RC3 to RC5
99 SchForwardLinkUtilAverage Average of sum of digital gain squared for all

supplemental data channels. Array has
entries for RC3 to RC5
100 PercentTimeAboveFwdCallBlocking Percentage of 2 second intervals where total

Threshold digital power exceeds CallBlockingThreshold.
101 PercentTimeAboveFwdHandoffBloc Percentage of 2 second intervals where total

kingThreshold digital power exceeds
HandoffBlockingThreshold.
102 PercentTimeAboveFwdVoiceCallBlo Percentage of 2 second intervals where total

ckingThreshold digital power exceeds
VoiceCallBlockingThreshold.
103 PercentTimeAboveFwdDataCallBlo Percentage of 2 second intervals where total

ckingThreshold digital power exceeds
DataCallBlockingThreshold
104 ConfiguredFwdCallBlockingThresho Total bits2 (including overhead channels) at

ld which new calls will be rejected.
—sheet 1 of 2—

Table 3-12
Digital power utilization
105 ConfiguredFwdHandoffBlockingThr Total bits2 (including overhead channels) at

eshold which new soft(er) handoffs will be rejected.
106 ConfiguredFwdVoiceCallBlockingTh Actual bits2 available for voice calls (excludes

reshold overhead channels)
107 ConfiguredFwdDataCallBlockingThr Actual bits2 available for data calls Excludes

eshold overhead channels).
—sheet 2 of 2—

Paging Channel at CEM

Table 3-13
Paging channel at CEM
Sequence Name Meaning

Number
126 PagingChannelMessageCount Count of paging messages received by the

CEM paging channel elements for this sector.
127 PagingChannelMessagesDropped Count of paging messages dropped by the

CEM or BTSC (due to overload control) for
this sector.
BTS Call Processing MO

Paging Channel at BTSC
Seq # Name Meaning
52 PagingChannelMessageCount Count of all paging messages intended to be sent.
53 PagingChannelMessagesDrop Count of paging messages dropped by the BTSC due

ped to CPU overload.
Power Management MO
RF Power
Sequen Name Units Meaning
ce
Number
62 CarrierRx0PowerA 16 * (dBm +120) Average receive power for diversity

vg branch 0
63 CarrierRx1PowerA 16 * (dBm +120) Average receive power for diversity

vg branch 1
64 CarrierRx0PowerM 16 * (dBm +120) Maximum receive power for diversity
ax branch 0
65 CarrierRx1PowerM 16 * (dBm +120) Maximum receive power for diversity

ax branch 1
59 CarrierTxPowerAvg 16 * dBm Average analog transmit power

60 CarrierTxPowerMa 16 * dBm Maximum analog transmit power
x
67 PercentPowerLimiti % Percentage time spent in Power Limiting

ng
Granularity: Per sector, per carrier

Units:
Receive power is 16 x dBfW
conversion to dBm = (value / 16) - 120
Transmit power is 16 x dBm
conversion to dBm = (value / 16)
Radio Sector MO
Multi-Carrier RF Power
Seq # Name Meaning
23 SectorPercentPowerLimiting Percentage time entire sector (all carriers in one
MFRM) was in Power Limiting
24 SectorTxPowerMax Peak TX power for sector (sum of all carriers in one

MFRM)
Granularity: Per sector
Units:
Transmit power is 16 x dBm
conversion to dBm = (value / 16)

Advanced FA (Frequency Assignment) MO

Physical CEM Resources
Seq # Name Meaning
23 NumOfTCAvailable Snapshot of free traffic channel elements at end of 30

minute period (CCEM only?).
24 TCEUtilMaximum Peak number of traffic channel elements in use during

the 30 minute period
72 TotalForwardPhysicalResourc Total number of provisioned forward link XCEM
es resources (excluding those flagged as faulty).
73 SchForwardPhysicalResource Forward physical resources reserved for SCH. Provide

sReserved sampled value at time of report.
74 SchMaximumForwardPhysical Maximum value over all samples of forward physical

ResourcesUsed resources in use for SCHs.
75 Fch2GMaximumForwardPhysi Maximum value over all samples of forward physical

calResourcesUsed resources in use for 2G FCHs.
76 Fch3GMaximumForwardPhysi Maximum value over all samples of forward physical

77 TotalReversePhysicalResourc Total reverse resources on the BTS, excluding faulty

es resources (ASICS). Provide sampled value at time of
report.
78 SchReversePhysicalResource Reverse physical resources reserved for SCH. Provide

Reserved sampled value at time of report.
79 SchMaximumReversePhysical Maximum value over all samples of reverse physical

ResourcesUsed resources in use for SCHs.
80 Fch2GMaximumReversePhysi Maximum value over all samples of reverse physical

calResourcesUsed resource in use for 2G FCHs
81 Fch3GMaximumReversePhysi Maximum value over all samples of reverse physical

CDSU T1 Port MO
T1/E1 Performance
Seq # Name Meaning
16 AvailableSeconds Number of seconds T1/E1 was fully operational
17 UnavailableSeconds UnavailableSeconds
18 ErroredSeconds ErroredSeconds
19 BurstyErroredSeconds BurstyErroredSeconds
20 SeverelyErroredSeconds SeverelyErroredSeconds
—sheet 1 of 2—

21 SeverelyErroredFramingSeco SeverelyErroredFramingSeconds
nds
22 LossOfSignalSeconds LossOfSignalSeconds
23 AlarmIndicationSignalSeconds AlarmIndicationSignalSeconds
24 LossOfFrameSeconds LossOfFrameSeconds
25 OutOfFrameSeconds OutOfFrameSeconds
30 TxAverageLinkUtilizationPerce TxAverageLinkUtilizationPercent
nt
31 RxAverageLinkUtilizationPerce RxAverageLinkUtilizationPercent
nt
32 TxPeakLinkUtilizationCounter TxPeakLinkUtilizationCounter
33 RxPeakLinkUtilizationCounter RxPeakLinkUtilizationCounter
—sheet 2 of 2—
CEM MO
Timing Source Performance
Seq # Name Meaning
44 CC1ESDriftCount Number of times an even second drift or PP2S timing

error is detected in the CEM CC1 over a 30 minute
interval.
45 CC1ESRecoveryCount Number of times the CEM CC1 initializes drift recovery

over a 30 minute interval.
46 CC2ESDriftCount Number of times an even second drift or PP2S timing

error is detected in the CEM CC2 over a 30 minute
interval.
47 CC2ESRecoveryCount Number of times the CEM CC2 initializes drift recovery

over a 30 minute interval.
Note: The actual utilization of these values from the BTS Performance
Logs are very powerful and are beyond the scope of this document. Please
refer to the document ‘BTS Performance Data Description, Formulas and
Calculations for RF Engineering’ for NBSS 10, which is available from
Nortel Customer Engineering or Technical Applications and also to NTP
411-2133-009 CDMA Traffic and Capacity Engineering Guide for NBSS
10.1, Section 8.

MTX Track
Another very useful tool in RF Optimization resides on the MTX MAP
terminal and is called MTXTRACK. Refer to the document DMS-MTX MAP
Commands Reference Manual, Volume 2 of 6 MTX10 for usage and applications for
this tool.
Appendix to Section 3 - Data Collection
Example of Metrocell parsed BTS Performance Log before filtering:

START:2001/11/22 05:30:00 Thu; STOP: 2001/11/22 06:00:00
Thu;#LOGNUM|1|OPERATIONAL
MC1900BTSB_MFRM:MCBTSSUBSYSTEM-1-
BTSCALLPROCESSING1
|67.2.0.153.1.1|67.2.0.2.1.1|0x3FFF|2
|7|52|0
|7|53|0
#END
BTSCALLPROCESSING1:ADVANCEDFA-1-ADVANCEDFA3
|67.2.0.150.1.3|67.2.0.2.1.1|0x3FFF|12
|5|23|0
|5|24|0

|7|72|128
|7|73|84
|7|74|0
|7|75|0
|7|76|0
|7|77|64
|7|78|0
|7|79|0
|7|80|0
|7|81|0
#END
|67.2.0.158.1.3|67.2.0.2.1.1|0x3FFF|44
|7|47|0
|7|48|30992
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0
|7|72|0
|7|73|0

|129|97|5 0 0 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0
|3|101|0
|3|102|0
|3|103|0
|7|104|236252
|7|105|492252
|7|106|205260
|7|107|10263
|5|108|0
|128|109|2 0 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0
|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0

|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0
|5|125|0
|7|126|0
|7|127|0
|129|128|5 0 0 0 0 0
|129|129|3 0 0 0
|129|130|5 0 0 0 0 0
|129|131|3 0 0 0
|129|132|5 0 0 0 0 0
|129|133|3 0 0 0
#END
ADVANCEDFA3:ADVANCEDSECTOR-1-
ADVANCEDSECTOR1:POWERMANAGEMENT-1-
POWERMANAGEMENT1
|67.2.0.159.1.3|67.2.0.2.1.1|0x3FFF|7
|5|59|0
|5|60|0
|5|62|475

|5|63|477
|5|64|477
|5|65|478
|5|67|0
#END
|67.2.0.150.1.2|67.2.0.2.1.1|0x3FFF|12
|5|23|0
|5|24|0
|7|72|128
|7|73|106
|7|74|0
|7|75|0
|7|76|0
|7|77|64
|7|78|32
|7|79|0
|7|80|0
|7|81|0
#END

|67.2.0.158.1.2|67.2.0.2.1.1|0x3FFF|44
|7|47|0
|7|48|41883
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0
|7|72|0
|7|73|0
|129|97|5 0 0 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0
|3|101|0
|3|102|0
|3|103|0
|7|104|236252
|7|105|492252
|7|106|9718
|7|107|194369

|5|108|0
|128|109|2 0 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0
|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0
|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0
|5|125|0
|7|126|0
|7|127|0
|129|128|5 0 0 0 0 0
|129|129|3 0 0 0
|129|130|5 0 0 0 0 0
|129|131|3 0 0 0

|129|132|5 0 0 0 0 0
|129|133|3 0 0 0
#END
POWERMANAGEMENT1
|67.2.0.159.1.2|67.2.0.2.1.1|0x3FFF|7
|5|59|529
|5|60|531
|5|62|171
|5|63|161
|5|64|172
|5|65|162
|5|67|0
#END
|67.2.0.150.1.1|67.2.0.2.1.1|0x3FFF|12

|5|23|0
|5|24|0
|7|72|128
|7|73|80
|7|74|0
|7|75|0
|7|76|0
|7|77|64
|7|78|0
|7|79|0
|7|80|0
|7|81|0
#END
|67.2.0.158.1.7|67.2.0.2.1.1|0x3FFF|44
|7|47|0
|7|48|40514
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0

|7|72|0
|7|73|0
|129|97|5 0 0 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0
|3|101|0
|3|102|0
|3|103|0
|7|104|236252
|7|105|492252
|7|106|97869
|7|107|195738
|5|108|0
|128|109|2 0 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0

|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0
|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0
|5|125|0
|7|126|0
|7|127|0
|129|128|5 0 0 0 0 0
|129|129|3 0 0 0
|129|130|5 0 0 0 0 0
|129|131|3 0 0 0
|129|132|5 0 0 0 0 0
|129|133|3 0 0 0
#END
POWERMANAGEMENT1
|67.2.0.159.1.7|67.2.0.2.1.1|0x3FFF|7
|5|59|0

|5|60|0
|5|62|805
|5|63|820
|5|64|806
|5|65|821
|5|67|0
#END
|67.2.0.158.1.1|67.2.0.2.1.1|0x3FFF|44
|7|47|0
|7|48|41158
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0
|7|72|0
|7|73|0
|129|97|5 0 0 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0

|3|101|0
|3|102|0
|3|103|0
|7|104|224319
|7|105|480319
|7|106|91580
|7|107|183161
|5|108|0
|128|109|2 0 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0
|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0
|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0

|5|125|0
|7|126|0
|7|127|0
|129|128|5 0 0 0 0 0
|129|129|3 0 0 0
|129|130|5 0 0 0 0 0
|129|131|3 0 0 0
|129|132|5 0 0 0 0 0
|129|133|3 0 0 0
#END
POWERMANAGEMENT1
|67.2.0.159.1.1|67.2.0.2.1.1|0x3FFF|7
|5|59|527
|5|60|528
|5|62|150
|5|63|138
|5|64|151
|5|65|139
|5|67|0

#END
MCBTSSUBSYSTEM1:ROOT-1-ROOT1:RFM-1-RFM3:RADIOSECTOR-
1-RADIOSECTOR1
|67.2.0.260.1.3|67.2.0.2.1.1|0x3FFF|2
|5|23|0
|5|24|0
#END
MCBTSSUBSYSTEM1:ROOT-1-ROOT1:RFM-1-RFM1:RADIOSECTOR-
1-RADIOSECTOR1
|67.2.0.260.1.1|67.2.0.2.1.1|0x3FFF|2
|5|23|0
|5|24|577
#END
MCBTSSUBSYSTEM1:ROOT-1-ROOT1:DCG-1-DCG1:CBCM-1-
CBCM1
|67.2.0.147.1.1|67.2.0.2.1.1|0x3FFF|1

|128|34|10 449 0 0 0 0 0 0 0 0 0
#END
MC800BTSB:MCBTSSUBSYSTEM-1-MCBTSSUBSYSTEM1:ROOT-1-
ROOT1:BTSCALLPROCESSING-1-BTSCALLPROCESSING1
|79.2.0.153.1.1|79.2.0.2.1.1|0x3FFF|2
|7|52|0
|7|53|0
#END
ROOT1:BTSCALLPROCESSING-1-
|79.2.0.150.1.1|79.2.0.2.1.1|0x3FFF|12
|5|23|44
|5|24|0
|7|72|0
|7|73|0
|7|74|0
|7|75|0
|7|76|0
|7|77|0

|7|78|0
|7|79|0
|7|80|0
|7|81|0
#END
|79.2.0.158.1.1|79.2.0.2.1.1|0x3FFF|44
|7|47|0
|7|48|40514
|7|49|0
|1025|70|4 |0|0|0 |0|0|0 |0|0|0 |0|0|0
|7|71|0
|7|72|0
|7|73|0
|129|97|5 0 0 0 0 0
|129|98|3 0 0 0
|129|99|3 0 0 0
|3|100|0
|3|101|0
|3|102|0

|3|103|14
|7|104|236252
|7|105|492252
|7|106|195738
|7|107|0
|5|108|0
|128|109|2 0 0
|5|110|0
|5|111|0
|5|112|0
|5|113|0
|5|114|0
|5|115|0
|5|116|0
|128|117|8 0 0 0 0 0 0 0 0
|128|118|8 0 0 0 0 0 0 0 0
|128|119|8 0 0 0 0 0 0 0 0
|128|120|8 0 0 0 0 0 0 0 0
|128|121|8 0 0 0 0 0 0 0 0
|128|122|8 0 0 0 0 0 0 0 0
|128|123|8 0 0 0 0 0 0 0 0
|128|124|8 0 0 0 0 0 0 0 0
|5|125|0
|7|126|0

|7|127|0
|129|128|5 0 0 0 0 0
|129|129|3 0 0 0
|129|130|5 0 0 0 0 0
|129|131|3 0 0 0
|129|132|5 0 0 0 0 0
|129|133|3 0 0 0
#END
POWERMANAGEMENT1
|79.2.0.159.1.1|79.2.0.2.1.1|0x3FFF|7
|5|59|552
|5|60|554
|5|62|167
|5|63|163
|5|64|169
|5|65|165
|5|67|0
#END

ROOT1:CEM-1-CEM1
|79.2.0.151.1.1|79.2.0.2.1.1|0x3FFF|4
|5|44|0
|5|45|0
|5|46|0
|5|47|0
#END
ROOT1:RFM-1-RFM1:RADIOSECTOR-1-RADIOSECTOR1
|79.2.0.260.1.1|79.2.0.2.1.1|0x3FFF|2
|5|23|0
|5|24|554
#END
ROOT1:DCG-1-DCG1:CBCM-1-CBCM1
|79.2.0.147.1.1|79.2.0.2.1.1|0x3FFF|1
|128|34|10 449 0 0 0 0 0 0 0 0 0
#END

Example of partial Metrocell parsed BTS Performance Log after Filtering:
START:2001/11/22 05:30:00 Thu; STOP: 2001/11/22 06:00:00 Thu;
#BEGIN LOGRECORD number = 1
TYPE = OPERATIONAL
FDN=O%:CCLN-1-CBS1:CELLS-1-CELLS1:MCBTS-1-
BTSCALLPROCESSING1
Event Name: ConsolidatedOMs
Originator OID: 67.2.0.153.1.1
Manager OID: 67.2.0.2.1.1
Event ID: (Type=0xB6, Seq=0x03)
Performance Attribute Name: PagingChannelMessageCount
Data Value: 0
Performance Attribute Name: PagingChannelMessagesDropped
Data Value: 0
#END LOGRECORD Number = 1
#BEGIN LOGRECORD number = 2
TYPE = OPERATIONAL
FDN=O%:CCLN-1-CBS1:CELLS-1-CELLS1:MCBTS-1-
Event Name: ConsolidatedOMs
Originator OID: 67.2.0.150.1.3

Manager OID: 67.2.0.2.1.1
Event ID: (Type=0xB6, Seq=0x03)
Performance Attribute Name: NumOfTCAvailable
Data Value: 0
Performance Attribute Name: TCEUtilMaximum
Data Value: 0
Performance Attribute Name: TotalForwardPhysicalResources
Data Value: 128
Performance Attribute Name: SchForwardPhysicalResourcesReserved
Data Value: 84
Performance Attribute Name: SchMaximumForwardPhysicalResourcesUsed
Data Value: 0
Performance Attribute Name:

Fch2GMaximumForwardPhysicalResourcesUsed


4-1
Chapter 4
Data Analysis Procedures 4
The following sections cover general data analysis procedures for most of the
network. Analysis of "special event" areas can identify a need for slightly
different settings than these procedures indicate.
Also, remember that data can be analyzed from two main points of view:
6. Macro view: Either plots of parameters over large parts of the network are
generated or averages and trends of different parameters are considered.
7. Micro view: This includes analysis of precise events, such as access
failures and dropped call analysis, as well as problems at exact locations.
Nortel Networks RF Optimizer

Nortel RF Optimizer CDMA provides an easy to use tool for the examination
of RF links between base stations and mobiles. RF Optimizer CDMA can be
used to make sure that the network is operating efficiently by providing
detailed analysis of key statistics, such as access failures, dropped calls, and
Frame Error Rate (FER).
Input Files
RF Optimizer uses two types of input files, the mobile log files and the SBS
log files. The mobile data files are collected from the mobile unit while the
SBS log data files are collected from the base station controller. All mobile
data files must be in MDM format to be processed with Nortel RF Optimizer.
When using the HP System (E7450), these files must be collected in binary
mode. The data files collected by the Grayson Inspector 32 must be pre-
processed using the file conversion program provided by Grayson to convert
them to the MDM format.
System Level Analysis (Macro)

System Level Analysis provides a macro or high level view of all files
selected for analysis. Performing System Level Analysis on separate files
may not result in statistically important data.

4-2 Chapter 4 Data Analysis Procedures
Search Windows
There are two search window functions in RF Optimizer, the Neighbor Set
Search Window and the Active Set Search Window. These are used to
minimize the size of the related window to speed up the searcher algorithm.
Shakedown Grid
The shakedown grid is the selection of the datafilled parameter from these
CAI messages: Sync Channel Message, System Parameters Message,
Extended System Parameters Message and Neighbor List Message. It
provides a report utility used for recording datafilled status.
System Map
The System Map displays information on a system wide basis, as defined by
the selection of files in the Active File List. The System Map shows
information from all (multiple) files selected together to analyze the network
performance. It also displays the location of the call events, such as Access
Failures, Dropped Calls.
TGA (Transmit Gain Adjust)

TGA analyzes the average Transmit Gain Adjust when the mobile is locked to
a single pilot. This data can show configuration or performance issues related
to a distinct site or sector. The data identifies any sites having a significantly
different link balance, and a site with an less than normal transmit gain adjust.
TGA shows an imbalance with a BTS receiver. When the mobile is locked to
a single pilot, the Transmit Gain Adjust is averaged and reported, along with
the amount of time spent locked to the pilot, and the number of occurrences
being averaged together.
BES (Burst Error Statistics)

The Burst Error Statistics analyzes the occurrences of consecutive frame
erasures. Burst Error Statistics will display Voice or Markov statistics, but the
user must indicate which one is analyzed. Forward and Reverse frames are
analyzed separately and separate histograms can be generated for each. In a
Voice Call, consecutive frame erasures in voice call are reported for all-rate
only. In a Markov Call, consecutive frame Erasures are reported for full-rate
frames only. In the event of a rate change to any rate except full, the
consecutive frame-erasures counter stops and resets. The counter continues
when full-rate frames are again identified.
Call Statistics
The Call Statistics analysis will display Call Statistics, Access failure and
Drop Statistics, Handoff Statistics, Sector Statistics, Channel Element
Statistics, and FER Analyzer, Markov and/or Voice. Each function found in
the Call Statistics is listed and described below:

Nortel Networks RF Optimizer 4-3
• The Call Statistics function gives summary information for Originations,

Access Failures, Dropped Calls and Call Seconds by Run, MIN and total
for all runs processed together.
• Handoff Statistics are calculated by using all files in the Active List.
Each handoff type that occurred is listed, with the Time and the
Percentage of time spent in the state. Distance, Percentage of Distance
and Speed are given for information only. The Speed is interpolated from
GPS data and does not represent the actual speed of the vehicle at a
distinct time. The Handoff Type name shows two conditions: the number
of sites in handoff and the number of sectors at each site in handoff.
• Sector Statistics are calculated by using all files in the Active List. Each
Sectors state is listed, with the Time and the Percentage of time spent in
the state. The Sectors state refers to the number of sectors in use at a time.
Sectors per user shows the average sectors used to support a user in the
selected data.
• Channel Element Statistics are calculated by using all files in the Active
List. Each Channel Element is listed, with the Time and the Percentage of
time spent in the state. The Channel Element state refers to the number of
channel elements in use at a time as indicated by the Handoff type in the
handoff Statistics.
• FER Analyzer can be used for Markov or Voice data on both the forward
and reverse links. Markov data can be qualified by Full Rate, Half Rate,
Quarter Rate and Eighth Rate while voice data reflects all rates at the
same time and cannot be qualified by rate.
Delta Tool
The Delta Tool allows the user to compare data from multiple files for a
geographic area. For example, data collected before a change to the system
can be compared to data collected after the change is done. The delta or
difference, between the two readings can be mapped to give a graphic image
of the results of the change.
File Level Analysis (Micro)

These functions provide a file by file analysis, using synchronized Views.
The Synchronized Views are graphic images of a single file (or set of mobile
and SBS log files), and are synchronized by time stamp for data analysis. To
display any of the following views, the Call Statistics window must be open.
Graph View
The Graph View will display information from a single active file. It also
displays selected parameters from the Grid View (and Flat text file). The
Graph view can be printed from within RF Optimizer.

Grid View
The Grid View will display information from a single active file. The Grid
View cannot be printed from within RF Optimizer. However, the user can
create a tab delimited ASCII output file from the Grid by using Save to File.
The Grid output file can be opened in programs such as Word, Wordpad or
Excel.
Message View
The Message View will display information from a single active file. The
Message View will display all Messages from the active file or the user can
select a subset of messages using the Message Chooser. The user can create a
tab delimited ASCII output file from the Message View by using Save to File.
The Message output file can be opened in programs such as Word, Wordpad
or Excel.
Detail Map View

The Detail Map View will display information from a single active file. The
Graph view can be printed from within RF Optimizer.
Datafill Audit and Shakedown

Datafill Audit
Examine the configuration files for all BTSs and the BSC and make sure the
expected RF parameters are input correctly.
Shakedown Data Analysis

1. Generate mobile message text files from the shakedown runs
2. For each sector, examine the parameter settings in the Sync Channel
Message, System Parameters Message, Extended System Parameters
Message, Access Parameters Message
3. Make sure the expected parameters are input correctly.
4. Examine the Neighbor List Message and confirm that the neighbor list is
correct (remembering this is only used for idle handoff).
Note: The Nortel Networks RF Optimizer tool automatically generates

Shakedown reports.
System Access
Access Failure Analysis
Because at least one of the mobiles in the test vehicle is making many short
calls, useful data on access attempts is available.
If the radio link fails before the mobile sends the Service Connect Complete
Message then it is considered a failed access attempt. Tools such as RF
Optimizer identify the time stamps of access failures. Using the mobile

System Access 4-5
message text files, message flow files and parametric files, classify the
failures into one of the following categories:
• Access probes exhausted (not received by system)

• Access probes exhausted (seen by system but acknowledgment not
reaching mobile)
• Acknowledgment received by mobile but Channel Assignment Message
not seen
• Channel Assignment Message seen at mobile but mobile does not acquire
forward traffic channel
• Mobile acquires forward traffic channel but system does not acquire
reverse traffic channel
• System acquires reverse traffic channel but forward acknowledgment
does not reach mobile
• Forward acknowledgment reaches mobile but reverse acknowledgment
does not reach system
• System receives reverse acknowledgment but Service Connect Message is
not seen at mobile.
Reverse link message failures are possibly caused by coverage problems.
Forward link message failures are possibly caused by the mobile being
restricted to one pilot during access (any other pilots are interferers). RF
Optimizer maps the locations of access failures.
Check that reverse link failures are not occurring in areas of solid coverage
(suspect a problem at one of the sites if this appears to be the condition).
Forward link access failures are likely to occur in areas where multiple pilots
are seen. If it appears to be occurring in isolated coverage, suspect a problem
at the site.
Access Success Rate

After the important OMs are in place and a system is carrying active traffic,
the access success rate reports can be produced as required. However,
measuring the access success rate on a pre-commercial system can only be
done using drive test data.
• Use the total call attempts from data for all mobiles for a complete
network or cluster drive.
• Discard any access failures that must not count in the total. For example,
drive routes that are out of coverage, sites not in service caused by datafill
error, and other reasons.

• Use the remaining failures and the total call attempts to calculate the
access failure rate.
Access Parameter Tuning
(INIT_PWR, NOM_PWR, MAX_REQ_SEQ, MAX_RSP_SEQ,
PWR_STEP, NUM_STEP, MAX_CAP_SZ, PROBE BKOFF, BKOFF)
(Set INIT_PWR to be consistent with average TXGA - others must be at

baseline datafill for now but need to be subject of a detailed test)
Dropped Calls
Link Supervision
The link supervision algorithms define the criteria for dropping a call.
Mobile Generated Release Order

The mobile will release the call if 250 frames are received without 2
consecutive good frames (meaning every 2 consecutive good frames resets a
5 second fade timer).
Also, the mobile disables its transmitter if 12 consecutive erasures are

received and re-enables it when 2 consecutive good frames are received.
SBS Generated Release Order

The SBS will release the call if 250 frames are received without 2 consecutive
good frames (meaning every 2 consecutive good frames resets a 5 second
fade timer).
The SBS will release the call if no acknowledgment (either an

acknowledgment or a Handoff Completion Message) is received to a Handoff
Direction Message within 5 seconds. The Handoff Direction Message is
retried 6 times. Also, if QuickRepeat is enabled, each of these retries is
composed of 3 repeats for a total of 18 repeats of the same message.
Analysis
Dropped call analysis can burn a large amount of time. Custom scripts or
tools such as Nortel Networks RF Optimizer identify and time stamp calls
which stopped too early. Through inspection of the mobile message logs and
parametric data, the root cause of some of the drops can be determined
without the need to use the selector logs. However, most of them need deeper
analysis requiring the SBS message files, the message flow files and
parametric files (possibly after re-processing at 20mS resolution). While later
sections of this document try to provide a step-by-step method to dropped call
root cause analysis, there is no replacement for complete knowledge of the air
interface and IS-95.

Dropped Calls 4-7
If the radio link fails after the mobile sends the Service Connect Complete
Message then it is considered a dropped call. Separate the dropped calls into
the following categories:
1. Coverage related
2. Optimizable (caused by slow handoff, search window, coverage control,
or PN plan related.)
3. Equipment problems (caused by hardware failures or backhaul
interruptions).
4. Hardware or software design related problems.
Examine the location for all of the category 1 failures. Check that this type of
dropped call is not occurring in areas of solid coverage (suspect a problem at
one of the sites if this appears to be the condition). If service is required in an
area not currently covered, it is possible to extend the range of existing sites
through antenna orientations or type changes, if not, an additional site is
required.
For category 2, the message flow file containing messages logged at both the
mobile and SBS is very useful here.
Category 3 problems must be referred to the appropriate maintenance group.
Category 4 problems must be communicated to the Nortel Networks

development group through the SR (Service Request) process.
Dropped Call Rate

Tools such as Nortel Network’s RF Optimizer will generate dropped call
statistics based on the actual number of test calls. If the long calls are used,
the following method can be used to prevent skewing the data:
• Decide on an average call duration (for example 100 seconds) that is used
in the calculations.
• Use the total call time output from the data analysis tool and calculate the
number of equivalent calls using the average call duration. Data for all
mobiles for a complete network or cluster drive can be used.
• Discard any dropped calls that must not count in the total. (for example,
drive routes that are out of coverage, sites not in service caused by datafill
error, and other reasons)
• Use the remaining drops and the total equivalent calls to calculate
dropped call rate.

RF Coverage and Handoff Control

Controlling the coverage area of separate cells is the single most important
aspect of CDMA RF optimization and is important to good CDMA
performance. Much has been written about the removal of frequency planning
in CDMA. All this means is the loss of one degree of freedom for interference
control.
Antenna patterns, orientations and tilts are the main tools used to limit cells to
their intended coverage area and create a main server where possible. Very
careful thought must be given to the selection of antenna type in terms of
beamwidth and internal electrical downtilt. Urban (and possibly suburban)
areas will often need downtilt in excess of 6 degrees so this can be a good
selection of electrical downtilt in many instances. The beamwidth must be
consistent with maintaining a good coverage pattern at these tilt levels. This is
true for sites planned to provide in building coverage.
Note: “Over covering" of an area, either to get in building coverage or for

capacity reasons, does not cause pilot pollution.
If these steps are not taken, the system is probable to show the following
"Pilot Pollution" related problems:
• “Slow handoff” dropped calls: Because, for SRCH_WIN_A setting, the

number of active pilots has a large affect on search time, there is an
increased risk of a new, strong pilot not being detected quickly enough.
This is made worse by the fact that, in high handoff areas, the pilot Ec/Io
values are normally very low (because of the high Io).
For example, if the mobile is in 4-way handoff in a loaded system, the

active pilot Ec/Io values can all be around -13dB. When a new pilot
exceeds T_ADD at, say, -14dB, it is approximately equal to the active set
pilots. By the time the mobile has filtered the measurement, sent a Pilot
Strength Measurement Message and the SBS has queried the BTS for
resources, the new pilot can be causing so much forward link interference
that the Handoff Direction Message does not reach the mobile.
• "Window" related dropped calls: If pilots are being seen some distance
outside their intended coverage area, dropped calls can results for two
reasons:
(1) If that pilot is strong enough to cause interference to a call in progress,
but the mobile's timing reference is from a local cell, the remote pilot is
outside SRCH_WIN_N and is not added to the active set and the call can
drop.

RF Coverage and Handoff Control 4-9
(2) If the mobile originates on the remote site and uses it as its timing
reference, the local sites are "not seen" if they are outside SRCH_WIN_N
and the call will drop as soon as one of the local sites becomes strong.
Note: It is not probable that the mobile will switch its timing to the
remote site while on a call because this would require that no rake fingers
be assigned to any of the local sites.
• Low Capacity: 4, 5, and 6 way handoff can be good in many instances

where there are many pilots with no main server or in a quickly changing
environment. In these conditions, the pilots not currently being
demodulated serve as "hot standbys" to which rake fingers can be
assigned quickly. This can be very important in maintaining a call in a
difficult environment.
However, in order not to compromise capacity (both forward and reverse
link), every effort must be made to make sure that this is the exception
rather than the rule. Also, because the mobile only has three rake fingers,
if there are, say, 4 equal pilots, the mobile assigns 3 fingers to 3 of them,
leaving the 4th as an interferer. This requires a higher forward power
allocation to exceed this interference and lower capacity.
The following three sections describe how to load survey data into a mapping
tool to generate plots that indicate which sites are candidates for antenna
changes. The source data used must represent one complete drive of the
system or cluster:
1. Generate files containing lat/long and handoff state (by number of sectors
- not channel elements). Use 6 colors to identify the number of sectors
involved and generate one plot for the entire system/cluster. (The Nortel
RF Optimizer can generate these plots automatically).
2. Generate files containing lat/long and the Ec/Io of the best finger.
Suggested settings are -16 to -8 with a step of 2. Generate one plot for the
complete system or cluster. (The Nortel RF Optimizer can generate these
plots automatically).
3. After studying the above plots, create a list of sectors which are possible
contributors to the high handoff or poor Ec/Io areas. For each of these
sectors, the plan is to generate a plot for that sector alone showing where
that pilot is appearing. Three types of per pilot plots can be used: strongest
rake finger, any rake finger, any occurrence in a PSMM. The value to be
plotted is the Ec/Io. Suggested settings are -16 to -8 with a step of 2.
Generate plots for one sector at a time. (The Nortel Networks RF
Optimizer can generate these plots automatically).
4. Generate files containing lat./long and mobile transmit power. Suggested
color settings are: less than 13dBm = green, 13 to 18dBm = orange, 18 to

23 dBm = red. Generate one plot for the complete system or cluster. (The
Nortel Networks RF Optimizer can generate these plots automatically).
Analysis of these plots is subjective but the general procedure is as follows:
The handoff state and overall Ec/Io plots can be used as an indicator of the
worst case areas for excessive handoff and interference. In areas of high
handoff (4, 5 and 6 way), examine the per pilot plot for each sector in that
area and determine if each pilot is intended to provide coverage in that area.
The three types of per pilot plot (strongest rake finger, any rake finger, any
occurrence in a PSMM) show progressively greater coverage area for a given
pilot so some experimentation is required to find the most clear image.
If the problems occur along the main beam of the antenna, a downtilt alone
can be enough. If there are problems along the edge of the antenna beam, also
consider a narrower beamwidth antenna and/or a re-orientation.
Do not try to remove signal from areas where the mobile transmit power is
above 18dBm (red) because these are the areas where high handoff is actually
helping to maintain the call.
To help decide on the exact changes, use single cell signal plots in Planet and
experiment with antenna changes. A signal level reduction that gets the
offending pilot below T_ADD can be calculated and applied before re-driving
the area.
Beware that, as unwanted pilots are removed from an area, the Io is being
reduced and so the next drive of the area can indicate new problem pilots,
making this a repeated process. The data for these plots is best taken without
any forward link loading because this raises the Ec/Io levels over the system
and shows pilots that can not otherwise be seen.
After the coverage of the separate sites has been correctly adjusted using the
procedures in the above section, additional reduction of handoff must be
contemplated in very unusual conditions. 4, 5 and 6 way handoff can be good
in many instances where there are many pilots with no main server or in a
quickly changing environment. In these occurrences, the pilots not currently
being demodulated serve as "hot standbys" to which rake fingers can be
assigned quickly. This can be very important in maintaining a call in a
difficult environment.
A majority of 2-way mixed with some 1-way (no handoff) and some 3-way
handoff should be considered normal. A figure of 2 sectors per user can be
considered a good objective.
T_ADD/T_DROP settings of -14dBm/-16dBm are now the recommended

settings for the following reasons:

• These values have given good results in simulations and field testing to
date, according to dropped call rate.
• In "pilot pollution areas", the Ec/Io levels of the active set pilots can be as
low as -12 or -13 dB. Even with T_ADD at -14dB, a new pilot is not
detected until it is equal in strength with the current pilots.
By the time the mobile has measured it and sent a Pilot Strength
Measurement Message, the system has set up resources and sent back an
Extended Handoff Direction Message. The forward link is too poor for
this to reach the mobile and the call drops. Raising T_ADD makes this
problem worse.
• Releasing a pilot above -16dB represents a loss of useful signal.

There are other reasons to prevent arbitrary reductions in soft handoff. For
example, given that the reverse link coverage has been planned assuming 4dB
soft handoff gain, one can calculate (for a propagation slope of 3.5) that the
last 4dB of the cell radius represents an area of 42%. Therefore, 42% of the
cell area needs to be in soft handoff to make sure complete reverse link
coverage. Restricting it to, say, 35% using the handoff thresholds (which are
forward link parameters and does not depend on of reverse link coverage) can
be a very bad thing to do.
This is a very simplistic calculation and the cell overlap that occurs in a real
design helps a lot with the reverse link coverage but it indicates the need to
think through decisions for reducing soft handoff more.
Soft Handoff Reduction

After software release 6.2, users now have an option of enabling a more
“intelligent” soft handoff reduction algorithm from the default disable setting.
With this new soft handoff reduction algorithm, a few more parameters are
introduced in managing soft handoff pilots.
While mobile is 1-way handoff these datafilled handoff parameters are used:
T_ADD
T_DROP
T_COMP
T_TDROP
While a mobile is in 2, 3, 4, 5, or 6 way soft handoff the parameters are as

follows:
T_ADD = (T_ADD – T_ADD_OFFSET)

T_DROP = (T_DROP – T_DROP_OFFSET)
T_COMP (datafill value in PDB)
T_TDROP (datafill value in PDB)
When a Pilot Strength Measurement Message is received, the pilots are

ranked in strength order from P1 (strongest) to Pn (weakest) (n <= 6) with
corresponding Ec/Io values of (Ec/Io)1 to (Ec/Io)n. The following rules are
then applied:
1. Always accept the second pilot (P2).

2. Accept third pilot when (Ec/I0)1 - (Ec/I0)3 <= DELTA_3
3. Accept fourth pilot when third pilot accepted and (Ec/I0)1 - (Ec/I0)4 <=
DELTA_4
4. Accept fifth pilot when fourth pilot accepted and (Ec/I0)1 - (Ec/I0)5 <=
DELTA_5
5. Accept sixth pilot when fifth pilot accepted and (Ec/I0)1 - (Ec/I0)6 <=
DELTA_6
Optimization of this new set of parameters requires additional efforts on top

of existing optimization methods for soft handoff. It is strongly recommended
that any parameter changes that have already been introduced to control
handoff be reset to the following Nortel Networks recommended default
values before introducing the soft handoff reduction algorithm (SHOR):
T_ADD = -14
T_DROP = -16
T_COMP = 1dB
PilotGain = 216 (800MHz) or 186 (1900MHz)
After these values have been set back to default values, begin the introduction
of the DELTA parameters with DELTA_6 and work up to DELTA_3.
Note: T_ADD_OFFSET must be set to 0.
For each parameter, the stages are as follows:
1. Set different values of the DELTA on different SBS shelves and use
CLFL100 (Dlogs) put in a group by SBS number to monitor dropped calls
on a per SBS basis

2. Select the most aggressive (smallest) value of the DELTA that gives an
acceptable increase in dropped calls and apply across all SBS shelves. Get
the busy hour dropped call rate from the MTX OMs and the busy half
hour average SPU from the FA MO/AdvancedFA MO Performance Data.
Finally, examine T_ADD_OFFSET in a like method. Take Delta_6 for

example, first get baseline data which requires record the system wide busy
hour dropped call rate from the MTX OMs and generation of a system wide
busy half hour average SPU from the FA MO/AdvanceFA MO Performance
Data for at least 2 days with moderate to heavy traffic. Follow the above
given procedure:
Stage 1
Configure sets of SBS shelves with varied SHOR parameter values:
2 shelves: Delta6 = 4 dB, Delta3/4/5 = 15.5 dB
Remaining shelves: SHOR disabled
Note: Systems with small numbers of SBS shelves can use one shelf per
DELTA or perform the analysis over several days with different values
per day. A shelf with the current DELTA under test set to maximum is
required every day as a benchmark.
Record the per SBS dropped call numbers for the test SBS shelves for at least
2 days with moderate to heavy traffic. Select the smallest DELTA_6 value
that has no impact on dropped calls relative to the shelves with SHOR
disabled and apply this DELTA_6 to all SBS shelves (not just the test
shelves).
Stage 2
Repeat the same data collection as that of baseline data, and make comparison
against baseline data. If system wide dropped call rate is still acceptable,
continue with the DELTA_5 parameter, if not, increase DELTA_6 by 1dB on
all shelves and review the dropped call rate from the MTX OMs.
If incremental evaluation of system wide dropped calls and handoff (and

capacity) improvements is not required, this can wait until all SHOR
parameters are in place.

The value selected for DELTA_6 forms a lower limit for DELTA_5 that can
be optimized by repeating the above procedure. In the same way,
T_ADD_OFFSET and T_ADD_OFFSET can be optimized. The strategy
shown here requires that the T_ADD and T_DROP values for 2 to 6-way
handoff are to be maintained at –14dB and –16dB in the order given and that
one only needs to change the 1-way to 2-way transition.
Configure sets of SBS shelves with varied SHOR parameter values:
2 shelves: T_ADD=-12, T_DROP=-14, Delta3/4/5/6 = Delta3/4/5/6

(selected), T_ADD_OFFSET = 2 dB
2 shelves: T_ADD=-13, T_DROP=-15, Delta3/4/5/6 = Delta3/4/5/6

(selected), T_ADD_OFFSET = 1 dB
Remaining benchmark shelves: Delta3/4/5/6 = Delta3/4/5/6(selected),

T_ADD_OFFSET = 0
Record the per SBS dropped call numbers for the test SBS shelves for at least
2 days with moderate to heavy traffic. Select the largest T_ADD_OFFSET
value that has no impact on dropped calls relative to the benchmark shelves
and apply this T_ADD_OFFSET to all SBS shelves (not just the test shelves).
Search Windows
The search sequence for mobile that has two active pilots and a neighbor list
of three PNs is approximately as follows (the actual algorithm is determined
by each handset manufacturer but this describes the principle):
A1, A2, N1, A1, A2, N2, A1, A2, N3, R, A1, A2, N1,...
The worst case search time to find a new neighbor can be generalized as:
Search Time = (NN x (TN + (NA x TA))) + TR
Where NA, NN are the number of active PNs and neighbors in the order
given. TA, TN and TR are the search times for the SRCH_WIN_A/N/R
windows.
Minimizing the search time is important to CDMA performance, both to

prevent dropped calls (caused by a new pilot increasing very quickly) and to
increase capacity (any delay in adding a new neighbor into the active set
means it is an interferer and more power is required to maintain the required
FER).
However, the chip sets used in current handsets cannot search infinitely fast.
Setting the search windows too small does not result in a worthwhile speed

Search Windows 4-15
improvement and possibly risks missing some important signal energy or a

new neighbor. Table 4-1 shows the acceptable search window combinations:
Table 4-1
Acceptable Search Window Combinations
A c tiv e /C a n d id a te S e a r c h W in d o w (S R C H _ W IN _ A )
(c h ip s )
10 14 20 28 40 60
N e ig h b o r S e a r c h
W in d o w
(S R C H _ W IN _ N )
(c h ip s )
20 No No No No No No
28 No No No No No No
40 No No No No Yes No
60 No No No Yes Yes Yes
80 No No No Yes Yes Yes
100 No Yes Yes Yes Yes Yes
130 Yes Yes Yes Yes Yes Yes
Table 4-2 shows the datafill, maximum delay, and matching distance for
different window sizes.
Table 4-2
Window Size Datafill
Window Size Datafill Value Maximum Delay (uS) Distance (km)

(chips)
14 (+/-7) 4 5.7 1.71
20 (+/-10) 5 8.1 2.44
28 (+/-14) 6 11.4 3.42
40 (+/-20) 7 16.3 4.88
60 (+/-30) 8 24.4 7.32
80 (+/-40) 9 32.6 9.76
100 (+/-50) a 40.7 12.20
130 (+/-65) b 52.9 15.86
160 (+/-80) c 65.1 19.52

Table 4-2
Window Size Datafill
Window Size Datafill Value Maximum Delay (uS) Distance (km)

(chips)
226 (+/-113) d 92.0 27.57
Note: The following three sections explain how to establish search

window settings that are according to the propagation environment within
the system or cluster.
SRCH_WIN_A
Generate histograms of the maximum mobile finger separation for fingers
locked to one pilot only. This is the basis for setting the best value for
SRCH_WIN_A.
Table 4-3
Histogram Example
Locked Pilot PNs Offset (uS) Ec/Io (dBm)
312 0.00 -10.61
312 1.32 -14.38
320 .10 -14.28
Note: In the finger packet shown in Table 4-3 above, two fingers are
locked to PN 312 so the 1.32uS offset adds to the histogram.
Gather all the histogram files for one complete network or cluster run.
Classify the areas by average cell size. Two or three areas is enough. F or
example, "small" dense urban cells and "large" suburban or rural cells.
Generate an combined histogram for each area. Evaluate the histogram
against the "Max Delay" column in Table 4-2 and select a window size that
gets 95% of the finger separations. Check the shape of the histogram to make
sure that the existing window setting is not already too small. For example, is
there a sharp cutoff at the current window setting? In this condition, more
data must be collected with a wider window setting before a correct decision
can be made.
Note: The Nortel Networks RF Optimizer performs this analysis

automatically.
To get an idea of the trade-offs included for different active search window
settings, the following calculations can be performed:

Search Windows 4-17
For an active window setting of 60 chips and assuming the window is

centered on the main ray from the cellsite, a multipath component that just
falls inside the window will have traveled an extra 7.3km (30 chips @
0.244km/chip = 7.3km).
For a nominal 2km radius and assuming a best case of free space path loss
and no reflection loss, the multipath will be 20log(9.3/2) = 13dB lower
than the main path. At the cell edge, even for an unloaded system, the Ec/
Io of the main ray is unlikely to be better than -5dB which puts the
multipath at -18dB i.e. marginal advantage. For a more accurate path loss
exponent of 3.5, the multipath will be 35log(9.3/2) = 23.3dB lower
(approx. -28.8dB Ec/Io).
When one considers the larger cells and repeats the calculations for, say, a
5km radius, assuming free space the multipath will be 7.8dB lower (-
12.8dB Ec/Io if one continues with the 5dB Ec/Io main ray assumption)
while assuming a 3.5 exponent the multipath will be 13.7dB down (-
18.7dB Ec/Io). The free space value represents an advantage to
demodulation but the 3.5 exponent value continues to be marginal.
The corresponding numbers for a 28 chip window are as follows:
14 chips represents 3.4km so, for the 2km case, the free space multipath
component will be 8.6dB down (13.6dB Ec/Io) while the 3.5 exponent
multipath will be 15.1dB down (-20.1dB Ec/Io).
For the 5km condition, the free space multipath component will be 4.5dB
down (-9.5dB Ec/Io) while the 3.5 exponent multipath will be 7.9dB
down (-12.9dB Ec/Io).
Clearly the 5km condition can benefit from a larger active search window
because components falling just outside the window can be appreciable
interferers. For the 2km condition, the 3.5 exponent continues to give only a
marginal advantage. However, the free space condition can be of value but
how accurate is a free space assumption?
Two more aspects need to be considered before any results can be drawn:
1. Search time is substantially increased. If one takes an example of 3 active

pilots, 10 neighbors with a neighbor window setting of 100 chips. With an
active window of 28 chips, the search time is 0.42 secs. With an active
window of 60 chips, the search time is 0.64 secs (a 52% penalty).
2. All Ec/Io values decrease as loading increases.

SRCH_WIN_N
In the Pilot Strength Measurement Messages, the mobile reports the phase of
the pilots to the nearest chip resolution. Unless this pilot comes from another
sector of the reference cell, there will be some offset from an exact PN
(multiple of 64 chips).
For example, in a system with Pilot_Inc = 4, a phase of 4874 is actually

PN 76 + 10 chip offset and a phase of 25338 is PN 396 - 6 chip offset.
The general formulas for converting PN_PHASE to a PN and an OFFSET

are:
PN = INT((PN_PHASE/(PILOT_INC * 64)) + 0.5) * PILOT_INC
OFFSET = PN_PHASE - (PN * 64)
Generate histograms of the offsets as described above. This is the basis for
setting the best value for SRCH_WIN_N.
Gather all the histogram files for one complete network or cluster run.
Classify the areas by average cell size. Two or three areas is enough. For
example "small" dense urban cells and "large" suburban or rural cells.
Generate a combined histogram for each area. Evaluate the histogram against
the possible window settings in IS-95/J-STD 008.
The histogram is normally biased to the positive side, meaning pilots delayed
from the reference are more common than early arriving pilots. Remembering
that the window is centered around the reference, select a window setting that
covers 99% of the offsets.
For example, if 99% of offsets corresponds to, say, 47 chips, the next
highest "half window" is 50 chips so a window setting of 100 chips
(datafill of 10) would be appropriate.
Check the shape of the histogram to make sure that the existing window
setting is not already too small. For example is there a sharp cutoff at the
current window setting? In this event, more data must be collected with a
wider window setting before a correct decision can be made.
Note: The Nortel RF Optimizer performs this analysis automatically.
SRCH_WIN_R
SRCH_WIN_R is typically set one step higher than SRCH_WIN_N. This
makes sure that pilots missing from the neighbor list will be captured but also
allows slightly more remote "stray" pilots to be detected.

Neighbor Lists 4-19
BTS AccessChannelDemodulationSearchWidth,
TrafficChannelDemodulationSearchWidth
Because these windows perform the same function for the BTS as
SRCH_WIN_A does for the mobile, the same analysis result can be used.
Say the 95% point on the histogram was 12.4uS or 15.2 chips. The BTS
demodulation windows are set in 1/8th chip units. 15.2 * 8 = 121.6.
Note: The smallest increment that the CSM searches is 125 1/8th chip
units so the settings should always be multiples of 125.
Neighbor Lists
Remembering that every Pilot Strength Measurement Message contains a
pilot which is designated as the reference pilot, the basic rules of neighbor list
adjustment based on active data are:
1. Any pilot that is requested to be added in a Pilot Strength Measurement

Message must be in the neighbor list of the reference pilot in that PSMM.
2. Any pilots that are now in the reference cell's neighbor list but never
occur in a PilotStrengthMeasurementMessage must be removed from that
neighbor list.
For example, consider the NeighborListTuningArray shown in Table 4-4:

Table 4-4
Neighbor List Tuning Array Example
Base ID Sector Band CDMA Pilot Keep Pilot PN

Class Frequency Strength Bit
28 3 1 50 -8.50 1 220
221 2 1 50 -11.50 1 192
28 1 1 50 -17.00 1 212
28 2 1 50 -21.50 0 216
Note: The NeighborListTuningArray is a repeat of the

PilotStrengthMeasurementMessage with extended base ID included
PN 220 is the reference (because it occurs first in the message) so we are

working on the neighbor list for that sector. PN 216 is being dropped so
we do not consider it in this analysis. PNs 192 and 212 should both be in
the neighbor list for PN 220.
Neighbor list tuning data comes from three possible sources:

1. Dropped call or failed access analysis.

2. Pilot Strength Measurement Messages (PSMMs) from drive test data.
3. NeighborListTuningArray data logged at the selector.
The NeighborListTuningArray(NLTA) data logged at the SBS is very

powerful because the quantity of data far exceeds anything that can be
reached through normal drive testing. Also, because the data represents actual
traffic patterns, there is far less risk of making bad neighbor list decisions
because of the drive test routes selected. Last, because the extended base id is
included, PN reuse does not cause problems in the data analysis.
The neighbor list tuning process is illustrated in Figure 4-1.
Figure 4-1
Neighbor List Tuning
CDMA RF Optimizer BSM
NCF file SBS files

(site database) with NLTA data
(Neighbor List
Tuning Array)
Datafill modifications
via NCF file
Neighbor List Tuning
Analysis
From this process a “tuned” neighbor list spreadsheet is generated that can be
compared with the old neighbor list.
Tuning tool sample output:
CELL104x, 6036: CELL104y,2335,21,-8; CELL104z,2705,26,-9;...;

CELL68y,536,5,-10; CELL96z,34,0.3,-11; CELL208x,41,0.4,-9
The above represents the output for one sector (CELL104x in this example)
and 6036 NLTA records were logged with this sector as the reference. There
is one entry for every PN that occurs when CELL104x is the reference pilot
(it is shown here with sector identification but the tool can be made to display
PNs or base IDs). Each entry contains the number of times that sector is
requested, the percentage that represents and the average Ec/Io. Underlined
sectors are those not in the currently datafilled Neighbor List.
In the above example, the first two entries are the adjacent sectors of the same
BTS so they are "normal" entries. CELL68y is possibly found through the

Neighbor Lists 4-21
composite Neighbor List (high "hits" and good Ec/Io) but can be added to
CELL104x's Neighbor List. CELL96z must be removed unless it is an
immediate neighbor. CELL208x is probably being found through the
Remaining Set search (low "hits" but good Ec/Io) and must be added if it is
determined that it does not need to be removed because of RF coverage
control.
For each sector, examine the statistics with the Planet equal power boundaries
plot. Make sure there is enough data for the sector. 1000 NLTA records can be
regarded as the minimum for that sector to be analyzed. Consider removing
any pilots that are now in the neighbor list but have been requested less than
1% of the time. If drive test data is being used, make sure that it is not a result
of the drive routes (for example, do not remove adjacent sectors of a sectored
site). Consider adding pilots that are not now in the neighbor list but have
been requested greater than 1% of the time.
The above rules lead to "safe" neighbor lists and will result in a system that is
strong against dropped calls. Remember, though, that long neighbor lists
result in longer search times to find new pilots. During these delays, a new
pilot that has not been searched is an interferer and this will result in a higher
forward power allocation from the BTS to exceed the interference. If this
occurs normally, capacity suffers. The goal is to keep neighbor lists to a
minimum to prevent adding sites that are not immediate neighbors of the
serving cell. Try to make good use of the composite neighbor list as much as
possible.
If the decision reached during analysis is that a neighbor list entry was
missing, first refer to the predictions and determine if that pilot is intended to
cover that area. If not, the problem can be corrected with antenna
adjustments. Only if it is determined that a real neighbor list omission has
been found should the pilot be added to the reference cell's neighbor list.

Figure 4-2
Neighbor List example
Cell A Cell C
a a
g b g b
Cell B
a
g b
Referring to Figure 4-2 above, when the beta sector of Cell A appears as a
handoff candidate with the beta sector of Cell C, it might not be put in C's
neighbor list. The assumption is that, if the beta sector of cell A is a handoff
candidate of the beta sector of Cell C then either the alpha or beta or both
sectors of Cell B probably will be (if this is not true, there are likely bigger
problems to be addressed first).
The beta sector of Cell C will be in the alpha and/or beta sector of B's
neighbor list and the composite neighbor list sent to the mobile while in the
beta sector of Cell A will contain the beta sector or Cell C. The advantage
occurs when the mobile is in the alpha or gamma sectors of cell A because the
mobile will not waste search time looking for the beta sector of Cell C.
Obviously, the above diagram is very idealistic. Because of site selection

issues and the topology of a real environment, many unusual cell
arrangements will be found in the field. However, it shows the principle that,
to reduce the search time to find new pilots, the aim must be to minimize
neighbor lists.
Performance/Trend Analysis
If multiple drives of the same drive routes are planned, or if a benchmark
route is being used, the following parameters must be tracked:
• Average forward traffic channel gain and percent time at maximum

• Handoff overhead by sectors
• Average mobile transmit power and percent time within 5dB of maximum
• Dropped call rate
The values of all of these measurements reduce as the optimization process
develops. Note that FER is NOT included as a metric. This is because there

Per-Site Analysis 4-23
exists a security that power control works and that if all other issues are
addressed, good FER performance will naturally follow.
Per-Site Analysis
Analysis of data for when the mobile is locked to a single pilot can indicate
configuration or performance issues related to a distinct site or sector.
Generate the following:
1. A file containing the average transmit gain adjust on a per site basis for all
sites in a run. This shows any sites having a significantly different link
balance. A site with a high transmit gain adjust can be suffering from a
poor receiver noise figure or can be in a location where forward link
interference is normal. A site with an abnormally low transmit gain adjust
can have a low transmit power.
2. A file containing all lines from the parametric flat file for which the
number of pilots locked = 1. A column containing the PN is needed. This
allows additional performance analysis on a per site basis for FER, traffic
channel gain, Ew/No setpoint, finger separation and so on.
Table 4-5 is an example output of a per site transmit gain adjust analysis. It is
known from other analysis that site B is subject to interference from an
adjacent CDMA system (hence higher TXGA). Site N has the CDMA BTS
running from the CDPD multicouplers and likely has a higher noise figure
(higher TXGA). Following analysis indicated that the transmit power was
7dB low on the J-2 sector (low TXGA). All other sectors are "normal" (the
data was collected with no load on the system).
Table 4-5
Transmit Gain Adjust Analysis
Pilot PN Site Name Average TXGA
8 A -14.411692
60 B-1 -10.224532
220 B-2 -16.575031
380 B-3 -10.456281
68 C-1 -15.800661
228 C-2 -14.310556
388 C-3 -13.104353
76 D -16.165448

Table 4-5
Transmit Gain Adjust Analysis
Pilot PN Site Name Average TXGA
80 E -15.964134
84 F -16.857579
88 G-1 -13.542665
248 G-2 -11.875561
408 G-3 -12.938774
92 H -16432903
104 I -16.466863
116 J-1 -15.796377
276 J-2 -22.511815
436 J-3 -14.196346
128 K -14.556199
136 L -16.485730
144 M -14.431992
148 N-1 -10.874728
308 N-2 -9.3749509
468 N-3 -9.9643809
152 O -14.361585
412 X -17.127062
Note: The Nortel RF Optimizer tool performs this analysis over many
mobile logs automatically.
Capacity
The main requirement for getting good CDMA capacity is to remove not
needed handoffs and minimize the transmit power requirements on both
forward and reverse links through the following:
• good RF coverage control (no unnecessary handoff and interference)

• successful handoff (good neighbor lists, best search window settings)

Capacity 4-25
• best power control settings

• increase paging channel performance
• increase access channel performance
Capacity Equations for the Reverse Link
( W / R)
N= ×f×S
(Eb / No) × v
Where:
N = theoretical number of users per sector (Pole Capacity)

W/R = spreading bandwidth / information bandwidth (i.e. the processing gain)
Eb/No = the energy per bit / noise density
v = the voice activity factor (VAF)
f = power received from users in this sector / power received from all users
S = the sectorization gain
Note: All values shown in linear terms (not dB).
This equation takes no account of thermal noise and so is for a sector of zero
radius (100% of the processing gain fights the noise of other users). To
design "real" cells, one needs to allocate some of the processing gain to
fighting thermal noise. Normally, half is allocated (design for 50% loading).
If one measures the noise floor of a BTS receiver with no load and then
applies a 50% load, the noise floor will double (because half the noise is
allocated to each). This is the "3dB noise increase for 50% load". A more
general equation linking noise increase and load is:
Load (%) = 100 x (1 - 10(-NR/10))
If you can measure the noise increase that a fixed number of users causes, you
can calculate either pole capacity or 50% load.
The basic steps to estimating the reverse link capacity for a sector are as
follows:
1. Find half hour measurement periods where the MOU <= 5 (negligible
traffic period).
2. Measure the received power for both diversity branches for all of these
periods and take the higher of the two branches.

3. Find the smallest of all these readings and call this the noise floor for this
sector for this day.
4. For all half hour periods where the average number of links >= 5, measure
the power in the higher of the two diversity branches.
5. Subtract the earlier measured noise floor to get the noise increase.
6. Divide the number of links by the SPU to get the distinct users for this
sector.
7. Given the number of users that gave the measured noise increase,
calculate the 50% load.
For each half hour period where the sector MOU <= 5:
(max(SectorRx0PowerAvg, SectorRx1PowerAvg))
Pnoise (dBm) = -120 +
16
Take the minimum Pnoise found for all the half hour periods where MOU <= 5
and call this Pnoisefloor.
If all half hour periods for this sector have MOU > 5 then there is consistently
too much traffic to get a reliable noise floor reading - move on to the next
sector.
Now find all the half hour periods for which AvgNumOfLinks >= 5 and
record the received power:
(max(SectorRx0PowerAvg, SectorRx1PowerAvg))
Ptraffic (dBm) = -120 +
16
The noise increase is the delta between Ptraffic and Pnoisefloor:
NR (dB) = Ptraffic - Pnoisefloor
Then calculate the loading percentage:
Loadcurrent (%) = 100 * (1 - 10(-NR/10))
… and find the 50% load point:
AvgNumOfUs ers * 50
NumOfUsers =
50%
Load current

Capacity 4-27
...and find the Erlangs this represents:
Erlangs50% = ErlangB(NumOfUsers50%, 1%)
Note: Keep in mind that the terms, f and S, in the reverse link capacity
equation can be improved when you improve the forward link capacity.
The only terms you can control easily are f and S and because these will also
be improved when you improve the forward link capacity, all remaining
discussion applies to the forward link.
Capacity Equations for the Forward Link

Slightly different equations are used, depending on if the data source is drive
test data or BTSPerformanceData logs. Capacity that is calculated using
BTSPerformanceData is covered in a document titled “CDMA RF
Performance Maintenance Guidelines” that is available from the Technology
Applications group. For this reason, the focus here is on estimating the
capacity based on drive test data.
Capacity Based on Drive Test Data:

The following equation gives the potential loaded capacity of a sector in
terms of the number of users with average forward traffic channel gain and
normal soft handoff percentage for a system or cluster:
1- ( fPilot + fPage + fSynch )

N=
ftraff × hrf × v
Where:
N = the number of average users a sector can support assuming the above
conditions.
fPilot = the fraction of total HPA power allocated for the pilot channel
fPage = the fraction of total HPA power allocated for the paging channel
fSynch = the fraction of total HPA power allocated for the synch channel
ftraff = the average fraction of total HPA power allocated for one traffic
channel
hrf = handoff reduction factor, a calculated value which includes the required
RF power caused by different types of handoff

v = the voice activity factor (VAF)
Handoff Reduction Factor (hrf): this term adjusts the average power per user
based on the collected handoff statistics for the system under test where:
hrf = η( 1,1) + 2 ⋅ η( 1,2 ) + 3 ⋅ η( 1,3) +
(2 ⋅ η ( 2 ,2 ) )
+ 3 ⋅ η( 2 ,3) + 4 ⋅ η( 2 ,4 ) + 5 ⋅ η( 2 ,5) + 6 ⋅ η( 2 ,6) ⋅ υ2
+
υ
(3 ⋅ η( 3, 3 ) )
+ 4 ⋅ η( 3,4 ) + 5 ⋅ η( 3,5) + 6 ⋅ η( 3,6) ⋅ υ3
+
υ
(4 ⋅ η ( 4 ,4 ) )
+ 5 ⋅ η( 4 ,5) + 6 ⋅ η( 4 ,6) + 5 ⋅ η( 5,5) + 6 ⋅ η( 5,6 ) + 6 ⋅ η( 6,6 ) ⋅ υ4
υ
δ x η(α,β
α,β)
α,β is defined as follows:
δ = number of sources of power control bits the system is having to send

to the one mobile
η(α,β) = the percentage of time the one mobile experienced this type of
handoff, and
α = the number of cells with which the mobile is communicating
β = the number of sectors with which the mobile is communicating
υξ = voice activity factor for ‘x’ number of cells in soft handoff (i.e., the
adjusted voice activity to explain differences in power gain of the power
control bit caused by handoff with x cells.)
Voice Activity Factor (VAF)

υ = the average Markov voice activity factor for single sector coverage
1
υx = [ P( full ) ⋅ 1 + P(half )0.5623 ⋅ +
2
1 1 23 1
P(quarter )0.4467 ⋅ + P(eighth)0.3162 ⋅ ] ⋅ + ⋅p
4 8 24 24 x
Where:
P(full) = the probability of a full rate frame occurring = 0.291
P(half) = the probability of a half rate frame occurring = 0.039

Capacity 4-29
P(quarter) = the probability of quarter rate frame occurring = 0.072
P(eighth) = the probability of an eighth rate frame occurring = 0.598
1/2, 1/4, 1/8 = the relative power (to a full rate frame) associated to each
corresponding frame
23/24 = the part of a frame for which the relative power levels apply
1/24 = the part of a frame for which the power control power level applies
px2 = the relative power (relative to a “no handoff” power control bit)
given to a power control bit for the appropriate type handoff:
for x=2 (for handoffs involving 2 cells), p22 = 2
for x=3 (for handoffs involving 3 cells), p32 = 3
for x=4 (for handoffs involving 4 or more cells), p42 = 4
the constants for 1/2, 1/4, & 1/8 rate frames are hard coded numbers in
our loads that further reduce the power of these frame rates.
Optimizing for Forward Link Capacity

The procedures covered in the RF coverage control section are planned at
giving good capacity over the network. However, often there is a requirement
to improve capacity more over a small area (up to, say, 4 sectors), possibly at
the cost of capacity in the surrounding sectors.
Referring to the forward link capacity equation, you can see that reductions in
traffic channel power and unnecessary handoff will both lead to higher
capacity. It is important to stress the unnecessary handoff because, taken too
far, handoff reduction causes poor performance of the forward link in terms of
dropped calls, FER, and capacity.
The following methods can be considered for improving capacity over a

small area (the "hotspot"):
• REMOVING interfering handoff from other sectors: If the mobile is

going into handoff with sectors outside the hotspot area and this is causing
handoff exceeding 3-way, those sectors can be removed by downtilting/
antenna change/orientation change/power reduction (remember to reduce
the reverse link as well). Because the mobile has only three rake fingers,
repeated handoff above 3-way requires more traffic channel power to
exceed the interference from the active set members that are not being
demodulated.

• REMOVING interfering power from other sectors: If sectors outside

the hotspot are transmitting power into the hotspot but the Ec/Io is too low
for the mobile to go into handoff, those sectors can be removed by
downtilting/antenna change/orientation change/power reduction
(remember to reduce the reverse link as well). These interfering sectors
result in a need for more traffic channel power to exceed the interference
and maintain FER.
• Reducing handoff within the hotspot: If pilot quality is good in the
hotspot, a reduction in pilot gain by 1 or 2dB on the hotspot sectors can be
very successful. Because the traffic channels remain at the same absolute
level as before, this has the effect of lowering the Ec/Io of the hotspot
sectors and reducing handoff. This is more successful than increasing
T_ADD and T_DROP for three reasons:
a. Increasing T_ADD and T_DROP must be done on the surrounding
sectors as well as the hotspot sectors because the mobile needs to have
the new values before reaching the hotspot sectors. This causes a
general lowering of handoff through the region. Reducing the pilot
gain targets the hotspot sectors and will allow surrounding sectors to
pick up some of the traffic because it actually shifts the handoff
boundaries rather than just reducing handoff.
b. Because of the rules for updating T_ADD and T_DROP (most
negative value for any of the active set), many more sectors need to be
changed than are required. This can cause problems where the higher
T_ADD and T_DROP cannot be allowed.
c. Reducing the pilot power frees up some HPA power for traffic
channels.
Hard Handoff (HHO)

It is well known that soft handoff is more reliable than hard handoff because
the mobile is in constant communication with at least one cell. But soft
handoff can only occur between cells that have identical CDMA frequency
assignment. Therefore, when a mobile moves across the boundaries of a
different MTX/BSC complex or different CDMA frequencies, hard handoffs
must occur.
Hard handoff (HHO) can be divided into several categories:
• inter-frequency HHO
• inter-frequency band HHO
• inter-system/inter-BSC HHO/SHO
• CDMA-AMPS HHO.

Inter-Frequency HHO
Spectrum allocated for a CDMA system normally is split into several CDMA
channels or carriers, and each has bandwidth of 1.25MHz. Depending on the
traffic requirement in certain areas, multi-carrier systems can be installed.
Different carriers can cover different service areas or multiple carriers can be
overlaid to provide high capacity need. Inter-frequency HHO is supported at
boundaries of different carriers.
Inter-Frequency Band HHO

CDMA technology supports operation at two frequency bands, 800MHz
cellular band and 1900MHz PCS band. As a matter of fact, the Nortel
Networks Metro Cell BTS can be configured to operate either at 800MHz or
1900MHz, or even operate at both bands at the same time.
Normally, these two bands are called the cellular and PCS bands. Inter-
frequency band HHO can transfer a call between the two frequency bands,
given that the mobile station is dual band capable.
Inter-System/Inter-BSC HHO and Inter-System SHO

When a mobile moves from service area covered by one BSC to service area
covered by another BSC, a normal HHO is performed to switch the vocoder
from the source SBS to a target SBS. Both BSCs in this case are operating at
the same frequency. This HHO mechanism requires a certain degree of risk,
because the mobile is moving towards cells on the same frequency and is
subject to much interference and can drop before handoff.
The condition can be improved by putting into operation so called Inter-

System Soft Handoff (ISSHO), which breaks the handoff process into two
stages:
1. Perform inter-system soft handoff between the source BSC and target
BSC
2. A vocoder switch which is carried out at the target BSC.
In other words, an ISSHO is one where the mobile starts communications

with a new cell controlled by a different BSC while continuing to
communicate with the old cell controlled by the source BSC, and the two
BSCs are connected to two different MTXs. It requires T1 links between the
BSCs to interconnect the adjacent systems, and provide exchange signaling
and voice traffic between the source system and target system.
CDMA-AMPS HHO
Currently, CDMA systems are deployed on top of an AMPS system within
the cellular band in many markets. HHO between the two technologies is
supported. Normally, HHO from CDMA to AMPS is triggered by RTD.

Nortel Networks has put into operation an enhanced HHO (EHHO) design
through which a CDMA to AMPS HHO can be triggered on the basis of
forward or reverse parameters affecting call quality such as FER or Eb/No,
and RTD trigger. The EHHO can be enabled and optimized on a per sector
basis.
The intention of an EHHO is for coverage holes in core of CDMA system

where underlying AMPS can have more robust coverage, especially for some
in building coverage where AMPS has a dedicated in building system but
CDMA does not. Remember that this requires that the handset be CDMA-
AMPS dual mode.
Note: EHHO is not only limited to perform HHO from CDMA to AMPS,
it can be used to make HHO from CDMA to CDMA in a multi-carrier
overlay deployment plan.
HHO Triggers
Nortel Networks now supports two types of hard handoff:
1. single pilot HHO, and

2. multi-pilot HHO.
In the condition of single pilot HHO, when the HHO is triggered, the mobile
is forced to perform HHO to one target sector meaning that after the HHO,
the mobile has only that pilot in its active set.
The Multiple Pilot Hard Handoff (MPHHO) function allows a mobile to hard
handoff to more than one sector. When the mobile lands on the target
frequency/switch, it can be supported by links from up to six of the target
cells at the same time, providing more reliable hard handoffs.
In order for multi-pilot inter-system CDMA-CDMA hard handoff to work,

both MSCs must be upgraded to MTX07. The MTX version NBSS7.0
supports up to 6 hard handoff target border cells. The band class and
frequency for all the target cells in the actual HHO have to be the same. All
the target cells in the actual HHO must be part of the same MSC
Note: This includes logical cells so the target cells can “straddle” an
ISSHO border.
If one of the two MSCs in hard handoff uses a version earlier than MTX07,
only one target sector is supported.
At present, three Hard Handoff triggers are implemented:
1. RTD trigger,

2. Pilot Beacon trigger,

3. and the Enhanced HHO trigger.
Note: Combinations of RTD and Pilot Beacon can be used.
HHO with RTD Trigger

For customers with multiple carriers, the RTD-triggered HHO mechanism is
normally used for the mobile to step down from the second carrier frequency
to the first. RTD defines the handoff boundary based on the time when a
signal travels round trip. The RTD trigger is preferred for starting the hard
handoff because it expands the second carrier boundary and prevents the
purchase of Pilot Beacon Units.
For the hard handoff with RTD triggers, two conditions have to be met before
the hard handoff can be initiated.
1. All pilots in the active set must be defined as CELL_BORDER in the

PDB record, meaning the mobile must not be in soft handoff with any
CELL_STANDARD.
2. The sector with the shortest measured RTD must exceed its datafilled
BorderRefPilotRTDThresh.
The BTSs send the RTD measurements to the intersystem handoff manager,
and the intersystem handoff manager sorts them in ascending order. The
minimum RTD is then compared with its matching datafilled
BorderRefPilotRTDThresh of its pilot in PDB. When the shortest RTD of the
active pilots is above its threshold in the PDB record the HHO be triggered. If
the shortest RTD is less than its relatively large BorderRefPilotRTDThresh
datafill, the HHO will still not be triggered, although the second shortest RTD
has a smaller threshold, and it is above that threshold.
The sector with the shortest RTD measurement is considered as the reference
sector by the switch intersystem handoff manager. This reference sector may
not be identical to the reference sector used by the mobile, which is selected
corresponding to the PN with the earliest arrived multipath component, and is
used for demodulation.
When performing IS95 message analysis, the system’s reference sector can be
identified as the one considered with the highest priority and placed first in
the Extended Handoff Direction Message.
The BTS is able to measure the Round Trip Delay as follows:
• Remembering that 1 chip is 0.814uS, 1 chip represents a 1-way

propagation distance of 244m.

• Say a mobile is 2km from it’s reference cell. The propagation delay in
terms of chips for 2km is 2/0.244 = 8.2 chips.
• The mobile uses this signal for it’s timing reference so it’s timing is now
8.2 chips “late” relative to system time.
• When the mobile now transmits to the BTS, a further 8.2 chip delay is
incurred. The BTS “expects” the signal to arrive as if the mobile were at
zero distance from the BTS. In this example the signal arrives 8.2 + 8.2 =
16.4 chips “late”.
This is what the RTD measurement is if the BTS were making all it’s
measurements right at the antenna. In reality, there is some processing delay
on both the transmit and receive paths internal to the BTS. Two parameters,
FwdDistributionDelay and RvsDistributionDelay, are available to “zero” out
this internal delay.
If these have been datafilled correctly then all RTD calculations only need to
take the “over the air” delay into account. If not, the sum of these two
parameters will be added to all RTD measurements. The DistributionDelays
are datafilled in 1/8th chip units. RTD is also reported by the system in 1/8th
chip units. A report is generated when the RTD changes by 2 chips.
Example: What is the required datafill value for an RTD triggered hard
handoff to occur at 1km from a cell a) if the DistributionDelays have been
set correctly and b) if the DistributionDelays have been left at 0 on a
1900MHz BTS?
Answer: 1km represents a 1-way delay of 1/0.244 = 4.1 chips and a

Round Trip Delay of 8.2 chips. Because the datafill is in 1/8th chip units,
the datafill for answer a) is 66. On a 1900MHz BTS, the sum of the
DistributionDelays is in 1/8th chip units and is 79 + 212 = 291. Therefore,
the datafill required for b) is 291 + 66 = 357.
HHO with Pilot Beacon Trigger

The Pilot Beacon trigger is activated when soft handoff manager (SHM) in
BSC processes a Pilot Strength Measurement Message (PSMM) sent by the
mobile and finds that a pilot reported in the message is of type
CELL_PILOT_BEACON according to the PDB record. The SHM then sends
an event for initiating the handoff.
There are two ways to implement pilot beacon:
1. install a hardware pilot beacon unit that has its antenna and signal
transmission, or
2. reuse the existing pilots as virtual pilot beacon signals.

Obviously, the first way is flexible for controlling beacon signal footprint and
gives better control of handoff boundaries. But it is clearly a cost solution that
has the need to purchase pilot beacon units, and the additional energy
transmitted by pilot beacon units can cause interference.
The second way is economic, because no additional hardware is needed.

However, if the existing pilots are optimized for voice traffic, the flexibility
of controlling handoff boundaries may not be reached.
With Pilot Beacon trigger, the intersystem handoff manager selects its
reference sector based on the forward link received Ec/Io of the pilots. The
mobile reports the PNs and their measured Ec/Io values in PSMM. After
receiving the PSMM, the system sorts the PNs according to their Ec/Io values
in descending order. The PN with the highest Ec/Io (least negative) is selected
as the reference sector. When studying the IS95 messages, one can find that
the reference sector reported by the mobile can be different from the reference
sector selected by the algorithm. Because the reference sector decided by the
mobile is the one that is equal to the earliest arriving multipath, it can be
different from the strongest pilot.
HHO with Combined RTD and Pilot Beacon Trigger

Looking at RTD trigger and pilot beacon trigger, each has its pros and cons.
The RTD trigger defines handoff boundary based on propagation time, and
does not link to signal strength. It can be used to expand the second carrier
boundary and prevents the need to purchase of Pilot Beacon Units. This
advantage is very useful to balance the traffic for those second carrier
boundary cells.
The problem is that it can select a non-optimum reference sector in certain

conditions, which can cause problems. Especially in the occurrence of single
pilot hard handoff. Pilot beacon trigger selects the reference sector based on
the strongest Ec/Io, and thus makes sure of the use of an optimum reference
sector. But it does not have the flexibility to expand the second carrier
boundary. Some deployments can benefit from a combination of both
triggers, either because different areas along the border dictate the use of
different triggers or because an area needs one trigger as a “backup” to the
other. As it is described, each trigger has advantages and disadvantages.
Correctly configured combinations of both triggers can take advantages of
both.
Enhanced HHO Trigger

Enhanced HHO trigger applies to the EHHO feature only. The operation this
feature requires new set of datafill parameters:
CellType = CELL_EHHO
EHHOFerMaxFwd = 12, Maximum EHHO Forward FER (range 0-100%)

EHHOFerMaxRvs = 15, Maximum EHHO Reverse FER (range 0-100%)
EHHOFerModFwd = 8, Moderate EHHO Forward FER (range 0-100%)
EHHOFerModRvs = 11, Moderate EHHO Reverse FER (range 0-100%)
EHHOTCGMax = 90, Max. allowable traffic channel gain (range 0-100%)
Note: Traffic channel gain is based on TxPilotGain and RateSet, 0%

corresponds to PTXlower, 100% corresponds to PTXupper.
EHHOEBNOMax = 80, Energy bit noise ratio set point threshold (range 0-
100%)
The range is determined by the PRXlower and PRXupper datafill in the SBS.
(0% corresponds to PRXlower and 100% to PRXupper)
EHHO_Window = 100 (range 1-255)
Note: This is a weighted factor used to calculate the forward and reverse
EHHO FER values, a small value favors the last FER reading while a
large value favors the long term trend, Eb/No and TCG are not averaged,
they are sampled on a per frame basis, the forward and reverse EHHO
FER values can be calculated from this window.
EHHOTargetMSCID = market related, switch ID for target cell or sector
EHHOTargetCellID = application related, Cell ID for the target
Based on those datafill, EHHO can be triggered if:
1. Reference pilot has been defined as CELL_EHHO, and

Note: Different from RTD based HHO, not all pilots in the active set
have to be defined as CELL_EHHO.
2. One of the following 4 triggering states is found:
a. Forward EHHO FER > EHHOFerMaxFwd

This can be tested in areas where forward interference is present, or in
a quickly changing environment such as an area with pilot pollution,
walking in a building, or underground.)
b. Forward EHHO FER > EHHOFerModFwd AND Transmit channel

gain > EHHOTcgMax
This can be tested at cell edge, where the FER increases as a result of
max channel gain being reached.

c. Reverse EHHO FER > EHHOFerMaxRvs

This can be tested in areas of reverse interference, or at cell edge, but
the test will be more difficult because the system does everything
possible to maintain the required FER. This trigger can apply in areas
of fast changing characteristics.
d. Reverse EHHO FER > EHHOFerModRvs AND Eb/No >

EHHOEbNoMax
This can be tested in areas of reverse interference.
There is a loggable attribute at the SBS called EHHO for monitoring and
optimization.
HHO Optimization
Field experience indicates that most hard handoff related issues have been
traced to either wrong datafill or poor RF coverage control, also wrong
selection of HHO triggering mechanism can have a negative capacity impact
or cause dropped calls. Therefore, hard handoff optimization activities must
look at these areas.
In an active network, the causes for a high call drop rate or poor capacity in
certain areas or sectors can be difficult to identify. If those areas contain HHO
boundaries, HHO can be one of causes. Optimization requires the following
activities:
a. Drive testing from the source side of the border to target side of
border.
b. Data logging on both the source and target SBSs
c. Data logging on the Grayson.
d. Processing of the SBS and mobile logs using Nortel RF Optimizer.
Note: Markov calls cannot be used to test hard handoff because there is
no mechanism to transfer the Markov state information from the source
Selector to the target Selector.
After these activities have been completed, perform the following analysis:
1. Inspect the post processed SBS log. It is certain that the hard handoff
trigger has occurred if the CATRLM_RLMIntersystemHandoffInd
NOIS message is logged on the source system.
If this message is not logged, this indicates that the trigger conditions for a
vocoder switched hard handoff were not met, meaning:

– If using Pilot Beacons, no beacons were found above T_ADD.

– If using RTD, either the active set always contains a non-border
sector or the RTD threshold was not crossed.
2. Inspect the post processed SBS log. It is possible that networking is
functioning correctly if the IHMRLM_RLMExtendedHandoffMsgReq
NOIS message is logged on the source system. If not, datafill can have a
mismatch:
Note: The IS-41 message format datafilled on the source system must
match the message format datafilled on the target system. A message
format mismatch causes the intersystem handoff to fail, but this event
does not generate a log.
The incoming group number of source system must match the outgoing
group number of the target system. The outgoing group number of the
source system must match the incoming group number of the target
system. A mismatch causes a return error to be sent from target system to
source system.
The following CELL900 log is also generated on the target system:
GRPNUM 3 IN THE FACILITIES DIRECTIVE MESSAGE IS NOT VALID

CHECK THE GRPNUMIC DATAFILL IN TABLE SYSCON FOR ROUTE
MTXAC7
3. Inspect the post processed SBS log. If an

IHMRLM_RLMExtendedHandoffMsgReq NOIS message is logged
on the source system, it is possible that the corresponding Extended
Handoff Direction message was sent by the source system.
4. Inspect the post processed SBS log. If an
IHMRLM_RLMExtendedHandoffMsgReq NOIS message is logged
on the source system, it is possible that the corresponding Extended
Handoff Direction message was sent by the source system. There are
three occurrences of the
IS95_FTChanExtendedHandoffDirectionMsg which contain
the information given in the
IHMRLM_RLMExtendedHandoffMsgReq and also have the
HARD_INCLUDED field set to ‘1’.
5. Inspect the post processed RF Optimizer message window or flow file. It
is possible that if a
IS95_FTChanExtendedHandoffDirectionMsg NOIS message
is logged at the Selector that the mobile will receive a corresponding
Extended Handoff Direction message. A quick way to look through an RF
Optimizer flow file to find an Extended Handoff Direction message for a
hard handoff is to search for the text string ‘Hard_Included:1’.

The following is an example of an Extended Handoff Direction message

associated with a hard handoff:
MM 22:10:16.9975FwdTraffic ExtendedHandoffDirection
AS: 4 MS: 1 AR: 0 PPNs: 112(0), SWin:6 T_Add:28
T_Drop:32 T_Tdrop:3 T_Comp:5 T_TDrop:3 Hard_Included:1 Frame Offset:4
Nom_Pwr:0 Private_LCM:0 Reset_L2:1 Reset_FPC:0 Encrypt Mode:0 Num_Preamble:0
Band Class:1 CDMA_Freq:500
If a IS95_FTChanExtendedHandoffDirectionMsg NOIS
message is logged by the SBS, the mobile receives at least one Extended
Handoff Direction message within a few hundred milliseconds of the
IS95_FTChanExtendedHandoffDirectionMsg NOIS message
containing the information given in this NOIS message.
6. Inspect the post processed RF Optimizer message window or flow file. It

is certain that the mobile was able to get the forward link on the target
system if it attempts to send a Handoff Completion message.
The following is an example of a Handoff Completion message associated
with a hard handoff:
MM 22:10:17.2025 RevTraffic HandoffCompletion AS: 7 MS: 0 AR: 1

PPNs:112
Note: Handoff Completion messages associated with hard handoff

always contain exactly one pilot.
If an Extended Handoff Direction message is logged, the mobile tries to

send a Handoff Completion message. If the mobile does receive an
Extended Handoff Direction message which indicates a hard handoff is to
occur but the mobile does not try to send a Handoff Completion message,
then the mobile has failed to acquire the forward link on the target BTS.
Check: (1) if the target BTS is in service and calibrated correctly; (2)
PTXStart on the target system (Selector Subsystem MO) is set
correctly; (3) BorderRefRTDThresh on the source system (Pilot
Database MO) is low if using RTD; (4) TargetCell on the source
system (Pilot Database MO) is set correctly.
7. Inspect the post processed SBS log. When a hard handoff successful, an
IS95_RTChanHandoffCompletionMsg NOIS message associated
with the (hard) Handoff Completion message sent by the mobile will be
logged.

If the mobile sends a hard Handoff Completion message but this message
is not logged at the Selector, then the reverse link FER is too high.
Check:
– (1) if NOM_PWR is set to ‘-8’ (Selector Subsystem MO) on all

SBSs on both the source and target system;
– (2) BorderTargetCell on the source system (Pilot Database
MO) is set correctly;
– (3) BorderRefRTDThresh is low enough;
– (4) the reverse link RF plumbing on the target BTS is functioning
correctly;
– (5) there is no external interference in the receive band on the
target BTS (e.g., intermod products, broadband noise from the
source BTS).
When RTD is selected as the HO trigger, the problem can occur if the mobile
does not release a non-border sector from the active set, the vocoder switch
for ISSHO and trigger for HHO will be prevented. When this sector is finally
released from the active set, the mobile can be beyond the target sector and
the call can drop. While Multi Pilot Hard Handoff will greatly decrease this
problem, delayed handoff can cause higher transmit power and impact
capacity.
It is possible for the mobile to never release the non-border sector. The call
will continue further into the interference caused by the sectors beyond the
border tier and the call will drop. Note that the effects are completely
different from inter-frequency hard handoff. In that condition, a mobile that is
“dragging” a non-border sector does not find any interference on the same
frequency. In those occurrences, it is likely that no HHO attempt is indicated
in the message log before the call drops. One can check for soft handoff with
non-border cells; downtilt as necessary.
HHO requires careful datafill. For instance, incomplete beacon datafill can
cause the mobile to continue past the “logical” cells without triggering a
vocoder switch for ISSHO or HHO, the forward link interference then
steadily increases until the call drops. The mobile can request handoff to PNs
found by the Remaining Set search but the handoff will not be permitted.
HHO Interaction with Traffic Distribution

In multi-carrier deployment designs, HHO bridges a call from one frequency
to another when one carrier ends. On the other hand, traffic distribution
between the carriers can interact with handoff in those border areas.
Therefore, careful design and optimization is important to achieve better trade
off.

Currently there are three main traffic distribution mechanisms supported by

the Nortel Networks CDMA products:
1. Hashing function
2. Global Service Redirection (GSR),
3. Multi-Carrier Traffic Allocation (MCTA).
The hashing function is a process for the equal distribution of traffic across
CDMA channels. It allows an idle mobile to without order log on to a precise
carrier when the mobile receives notification of multiple carriers in the
CDMA channel list message. The mobile applies the Hashing function to
determine the selected carrier.
Global Service Redirection (GSR) can be configured to direct all or part of

idle mobiles from one carrier to another on a per sector basis. For example,
GSR can be deployed at border cells of overlying carrier to direct idle
mobiles to the underlying.
Multi-Carrier Traffic Allocation (MCTA) uses an intelligent algorithm to

assign mobiles to a carrier with the greatest used forward traffic power. If
MCTA is improperly deployed at the border cells, calls can experience ping-
ponging between the carriers caused by HHO interaction with traffic
distribution.
Take a two carriers overlay condition for example, the overlying carrier
normally experiences less interference at its edge, while idle mobiles are
directed to the underlying carrier by GSR, thus overlying carrier’s border
sectors generally have better capacity margin than underlying carrier resulting
from a not having enough call originations. When a mobile triggers a HHO at
a border sector, handoff algorithm will direct the mobile to the underlying
carrier, while MCTA identifies overlying carrier having better capacity
margin and send it back to the overlying carrier given those carriers are
sharing the same BSC. The loop repeats itself and blocks the HHO.
The impact of this effect can be serious before multi-pilot HHO deployment,
because the mobile can miss its assigned HHO target sector completely. To
prevent this, one can disable MCTA by assigning different cell-ids for co-
located underlay/overlay carriers.
If the HHO border is over an ISSHO border cell, the problem can be avoided
by connecting underlay/overlay carriers to different BSCs. The side effect of
disabling MCTA is it causes a severe under utilization of overlay carrier
because GSR moves all idle traffic to the underlay carrier. The suggested
correction is to disable GSR as well. This way, better traffic balance between
underlay/overlay carriers can be reached, but it leads another potential
problem.

The problem is that the mobile in idle mode can travel quite a distance (many
tiers) and monitor the PN of the overlay carrier caused by hashing, but can
have gone beyond the reach of the paging channel. Similarly, even the mobile
establishes a call before reaching the paging channel limit, it will trigger RTD
based HHO to be sent to the underlay carrier, but it will be so far away from
the target underlay PN and will not be able to handoff to it.
However, if the system supports MPHHO, this problem can be prevented,

because MPHHO allows MCTA to be used safely on border cells. Remember
that the reference sector and its 1st target are used to determine many things
associated with a MPHHO, including when to start MCTA. It is the presence
of two (or more) frequencies for the CellId of the reference sector that
triggers MCTA. Therefore, the target datafill should be arranged so that an f1-
only CellId always appears first in the target list. The CellId for the border
cell itself can appear 2nd (or later) in the target list but as long as the 1st target
of the reference sector does not have f2, MCTA will never be triggered.
Remember that call originations can still be sent to f2 but any issues
associated with this can be reduced as follows:
• If the RTDThreshold has been extended, the mobile will likely be inside
the HHO boundary so the chances of an immediate HHO back to f1 are
small.
• MCTA would likely be setup for priority on f1 so only when f1 is heavily
loaded will calls even be sent to f2.
Furthermore, the handoff and traffic distribution interaction can be better
engineered for more advantages when using MPHHO.
MPHHO allows activation of MCTA at border cells and one can datafill a
larger BorderRefPilotRTDThresh to expand the usable coverage area. This
will push the HHO location into areas where several sectors exist on the
underlying carrier but MPHHO can be used to make sure the reliability of the
HHO. The combination of these two factors will allow much more efficient
usage of the border sectors.
Even if MCTA is not used, the extended coverage area will allow the sector to
carry traffic for longer time periods and hence go some way towards
offsetting the lack of call originations. In this event, an additional advantage
is that many active calls will terminate naturally before the HHO is even
triggered and could then be re-directed to the underlying carrier by the GSR.
The only potential problem is that the likelihood of a call drop can occur as
the result of their very long call time that dragged calls beyond coverage.
In some cases of overlay, a second carrier is deployed as an “island” in a high

traffic area. Careful consideration needs to be given to the minimum
“sensible” number of cells to deploy. Without MPHHO, the traffic carrying

capability of the border sectors is limited as described in the previous section.

The smaller the overlay area, the larger the ratio of border sectors to core
sectors so small cell counts result in inefficient use of the BTS equipment.
Also, the number of HHO attempts required increases and because these will
be single pilot HHOs, they are less reliable. MPHHO has the potential to
increase the efficiency of the border sectors as well as improve the reliability
of the HHOs. This means that a smaller number of overlay BTSs can be
possible.


5-1
Chapter 5 - Dropped Call and Access

Failure Reasons and Solutions 5
This section details the characteristics that are seen in the diagnostic logs for
different field issues that are found through the network.
Successful Call
This section explains the characteristics of the data for a mobile that
originates correctly, remains in the service area, completes a handoff, and
makes a normal release.
Indications in Mobile Data

If only mobile data is available, the parametric files show:
• Receive power > -100dBm
• Transmit power < +18dBm
• Normal Transmit Gain Adjust (actual value depends on site
configurations, loading, NOM_PWR setting)
• Low forward FER
• Good Ec/Io (> -12dB) on at least one pilot
Under these conditions, messaging is reliable. In message file output, a basic

call (originated and released from the mobile) contains the following elements:
• Origination message (sent to MTX on Access Channel).
• BTS Acknowledgment (received from BTS on Paging Channel)
• Channel Assignment (received from MTX on Paging Channel).
Note: The mobile now acquires the forward traffic channel and powers
its transmitter, then the BTS acquires the reverse traffic channel. All
transmissions are 1/8 rate null frames.
• Forward Acknowledgment (received from SBS on traffic channel -

acknowledges acquisition of reverse traffic channel - this is an ack that
requires an acknowledgment)

5-2 Chapter 5 - Dropped Call and Access Failure Reasons and Solutions
• Reverse Acknowledgment (sent to SBS - acknowledges receipt of

forward acknowledgment)
• Service Connect Message (received from SBS on traffic channel - all
remaining messaging is on the traffic channel).
• Service Connect Complete Message (sent to SBS - a successful
origination can be considered if this message is sent).
• Pilot Strength Measurement Message (sent to SBS - initiates handoff).
• Extended Handoff Direction Message (from SBS - directs handoff - if all
is well, this message contains the same PNs requested by the mobile).
• Handoff Completion Message (sent to SBS - confirms receipt of
Extended Handoff Direction Message).
• Neighbor List Update Message (from SBS - contains new composite
Neighbor List)
• Mobile Release Order (sent to SBS)
• Release Order (from SBS)
Analysis with Selector Logs

Using the parametric files, the following can be established:
• Receive power > -100dBm
• Transmit power < +18dBm
• Normal Transmit Gain Adjust (actual value depends on site
• Ew/No setpoint below maximum
• Traffic Channel gain below maximum
• Low forward FER (either full or all rate)
• Low reverse FER (either full or all rate)
• Good Ec/Io (> -12dB) on at least one pilot
Figure 5-1 shows the basic IS-95 message flow for a successful call. Notice
how the message sequence and acknowledgment sequence numbers work
together. For example, if a PSMM is sent with a message sequence of 3
(MS:3), the Extended Handoff Direction Message has an acknowledgment
sequence number of 3 (AS:3). This confirms that this message is the
acknowledgment to that distinct PSMM.

Successful Call 5-3
Figure 5-1
Messaging Example of Successful Call
MM 01:12:02.5850 I95_AChanOriginationMsgType AS:7 MS:5
AR:1
MM 01:12:02.7287 I95_PChanCDMAChannelListMsgType PPN:320
MM 01:12:02.8475 I95_PChanOrderMsgType
MM 01:12:03.1475 I95_PChanExtendedSystemParametersMsgType PPN:320
MM 01:12:03.1688 I95_PChanGeneralPageMsgType
MM 01:12:03.6687 I95_PChanChannelAssignmentMsgType
SS 01:12:03.7400 I95_FTChanOrderMsgType AS:7 MS:0
AR:1 OR:16
MM 01:12:03.8087 I95_FTChanOrderMsgType AS:7 MS:0
AR:1 OR:16
MM 01:12:03.8863 I95_RTChanOrderMsgType AS:0 MS:0
AR:0 OR:16
SS 01:12:03.9200 I95_RTChanOrderMsgType AS:0 MS:0
AR:0 OR:16
SS 01:12:03.9400 I95_FTChanPowerControlParametersMsgType
SS 01:12:03.9600 I95_FTChanServiceConnectMsgType AS:7 MS:2
AR:1
MM 01:12:04.0075 I95_FTChanPowerControlParametersMsgType
MM 01:12:04.0288 I95_FTChanServiceConnectMsgType AS:7 MS:2
AR:1
MM 01:12:04.0675 I95_RTChanServiceConnectCompletionMsgTyp AS:1 MS:0
AR:1
SS 01:12:04.1000 I95_RTChanServiceConnectCompletionMsgTyp AS:1 MS:0
AR:1
AR:0 OR:16
AR:0 OR:16
AR:0 OR:16
AR:0 OR:16
MM 01:12:05.2075 I95_RTChanPilotStrengthMeasurementMsgType AS:2 MS:1
AR:1 PPNs:320R:( -7.00)K 312:(-12.50)K
SS 01:12:05.2400 I95_RTChanPilotStrengthMeasurementMsgType AS:2 MS:1
AR:1 PPNs:320R:( -7.00)K 312:(-12.50)K
SS 01:12:05.3000 I95_FTChanExtendedHandoffDirectionMsgType AS:1 MS:3
AR:1 PPNs:320 (0) 312 (1) SrchWin A:6 TA:28 TD:32 TC: 5 TTD: 3
MM 01:12:05.3688 I95_FTChanExtendedHandoffDirectionMsgType AS:1 MS:3
AR:0 OR:16
AR:0 OR:16
MM 01:12:05.4475 I95_RTChanHandoffCompletionMsgType AS:3 MS:2
AR:1 PPNs:320 312
SS 01:12:05.4800 I95_RTChanHandoffCompletionMsgType AS:3 MS:2
AR:1 PPNs:320 312
AR:0 OR:16
SS 01:12:05.5000 I95_FTChanNeighborListUpdateMsgType AS:2 MS:4
AR:1 PPN Inc: 4 NPNs:316 60 300 288 428 304 292 176 420 364 56 284 172
276 200 188 184 296 424 428


AR:0 OR:16
AR:0 OR:16
AR:0 OR:16
MM 01:12:05.5700 I95_FTChanNeighborListUpdateMsgType AS:2 MS:4
AR:1 PPN Inc: 4 NPNs:316 60 300 288 428 304 292 176 420 364 56 284 172
276 200 188 184 296 424 428
AR:0 OR:16
SS 01:12:12.9400 I95_FTChanServiceOptionControlMsgType AS:2 MS:5
AR:1
MM 01:12:13.0287 I95_FTChanServiceOptionControlMsgType AS:2 MS:5
AR:1
AR:0 OR:16
AR:0 OR:16
AR:1
AR:1
MM 01:13:45.2288 I95_RTChanServiceOptionControlMsgType AS:0 MS:3
AR:0
AR:1
AR:1
AR:0 OR:16
AR:0 OR:16
AR:1 OR:21
AR:1 OR:21
AR:0 OR:21
AR:0 OR:21
MM 01:13:52.9725 I95_SChanSyncMsgType PPN:312
Note: The MM and SS in the far left column indicate messages logged at
the mobile (MM) and SBS (SS) respectively. If all is going normally,
every traffic channel message appears twice, one time at each logging
point.

Access Failures and Dropped Call Reasons in Single Frequency

System
Table 5-1 shows different reasons for access failures and possible fix actions.
This information is based on a single frequency system with no hard
handoffs.
Table 5-1
Access Failures
Description Indications Possible Solution Comments
Bad pilot selection - One or more probes, no Control RF to reduce

drops paging Ack or CA at mobile, occurrences of multiple
channel then immediately back pilots with no main
to SYNC. Poor Ec/Io. server.
Many Bad Paging
Channel CRCs.
Bad pilot selection - Mobile receives P- Control RF to reduce

missed Channel channel order and occurrences of multiple
Assignment Msg stops probing but no pilots with no main
CA seen. Selector logs server
have NOIS msgs
setting up resources
etc.
Bad pilot selection - Mobile receives Control RF to reduce

does not acquire fwd channel assignment but occurrences of multiple
traffic channel goes to SYNC within 1 pilots with no main
second. Selector power server. Increase PTX
control setpoints at start to -1dB.
selector frozen at
starting values. Mobile
never enables its
transmitter.
Bad pilot selection - At the end of a call, Downtilt remote PN if

remote PN mobile decides to Sync possible.
to a remote PN when
better local PNs are
clearly available. Next
origination fails
because Neighbor List
of remote PN does not
contain any of the local
PNs.

Table 5-1
Access Failures
Description Indications Possible Solution Comments
Bad pilot selection - Forward link terminates Control RF to reduce

before SVC before first handoff can occurrences of multiple
be completed (before pilots with no main
Service Connect server.
(Complete) messages).
Normally see multiple
EHODs and Service
Connects from selector
but not arriving at
mobile.
Table 5-2 shows different reasons for dropped calls and possible fix actions.
This information is based on a single frequency system with no hard
handoffs.
Table 5-2
Dropped Calls
Description Indications Possible Solutions Comments
Slow handoff Mobile requests Minimize search time

handoff to new pilot by optimizing
(which was in NL), SRCH_WINs
selector sees PSMM, (especially A but don't
starts sending EHODs go below 28 chips),
but none arrive at adjusting neighbor lists
mobile because new and reducing the
PN is interferer number of way HO by
(remains a candidate). controlling RF. If new
Mobile will SYNC to pilot increases in
pilot it was requesting. strength suddenly, look
Bad Ec/Io, high fwd at other antenna
erasures arrangements.
Coverage Mobile RX near or If you need coverage

below -100dBm. Mobile here and none of the
TX above +18dBm. existing cellsites can be
Bad erasures both "persuaded" to cover it
ways, bad Ec/Io. High then you need a new
selector power control cellsite.
setpoints.

Table 5-2
Dropped Calls
PN Aliasing Mobile sees and Inspection of the Pilot

requests handoff to a Database neighbor list
PN in the neighbor list shows that the PN
but call continues to actually refers to a
degrade and terminates reuse of that PN and
with all indications of not the one the mobile
fwd link interference is heading towards. PN
(good RX, bad Ec/Io, retune required.
high erasures).
Mobile does not Mobile sends Ack to Mobile fix required.

send Handoff Extended Handoff
Completion Direction Message but
Message doesn't follow up with
HOC. Selector times-
out waiting for HOC.
Pilot not in neighbor Good mobile RX power First see if the pilot that
list but bad Ec/Io and caused the drop is
erasures. Normal intended to provide
cause of termination is service to that area. If
messaging failure on not, control the
fwd link. After drop, coverage (downtilt
mobile SYNCs to a pilot etc.). If it is (or it can't
that wasn't in last be removed from that
neighbor list update. area) then a neighbor
PSMMs are not list change is required.
probable (although can
be picked up on
Remaining Set search).
Unidentified Good mobile RX power Is possibly a neighbor

Interferer but bad Ec/Io and list problem as
erasures. Normal described above but
cause of termination is interference has gone
messaging failure on away by time mobile
fwd link. After drop, syncs so it is difficult to
mobile SYNCs to a pilot tell who it is. Driving
that was in last slowly in the area can
neighbor list update but show the interfering
no PSMMs sent. PN. Easier to see with
OCNS off.

Table 5-2
Dropped Calls
Pilot outside Good mobile RX power First see if the pilot that
SRCH_WIN_N but bad Ec/Io and caused the drop is
erasures. Normal intended to provide
cause of termination is service to that area. If
messaging failure on not, control the
fwd link. After drop, coverage (downtilt
mobile SYNCs to a pilot etc.). If it is (or it can't
that was in last be removed from that
neighbor list update but area) then need wider
no PSMMs sent. SRCH_WIN_N on sites
in that area.
Hard Handoff
Drop caused by HHO normally is related to target cell selection. When using
single pilot HHO, the seen HHO drop rate is high. The HHO is generally
considered as not reliable. With enhancement features such as ISSHO and
MPHHO, large improvement has been reached. In some areas, HHO point
and target cells continue to need optimization.
For example, perform drive test in the areas of HHO border and use RF
Optimizer to log those HHO messages can provide detailed information for
handoff drop diagnosis. Look the following logged HHO messages:
Message Analysis:
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.670 F[< 128-14> 112 116] A[ 112 -13, 116 -13, 128 -12,] C[] N[] R[] Re-87.9 Tx 9.8 L 1 fer 3
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.707 > EHDM M5 A4 1 [ 128 112 116 248 ]
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.725 < HCM A5 M5 1
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.785 < MSACK A5 M1 0
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.847 > NBLUM M6 A5 1 [ 124 132 72 68 140 120 284 160 244 252 148 152 168 320 ]
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.925 < MSACK A6 M2 0
425[T] M2:207 2 (128 ) r04.41 a178 20:58:36.985 < PSMM A6 M6 1 [REF 112 @-16.0 k | 128 +6 @-15.0 k| 116 @-16.5 k| 248 +16 @-25.0 k| 140 +27 @-12.0
k|
500[H] M2:207 2 (112 ) r04.41 a178 20:58:37.027 > EHDM M6 A5 0 6,28,32, 3, [HARD [ CH 500 PN 112 ]
500[H] M1:256 1 (112 ) r02.37 a175 20:58:36.985 F[< 112-15>] A[] C[] N[] R[] Re-87.9 Tx 9.8 L 1
500[H] M1:256 1 (112 ) r02.37 a175 20:58:38.801 F[< 112-17>] A[ 112 -22,] C[] N[] R[] Re-87.3 Tx 9 L 1
500[H] M1:256 1 (112 ) r02.37 a175 20:58:40.816 F[< 112 0>] A[ 112 -22,] C[] N[] R[] Re-91.1 Tx-1.8 L-13 fer 90.7
500[H] M1:256 1 (112 ) r02.37 a175 20:58:42.882 F[< 112 0>] A[ 112 -22,] C[] N[] R[] Re-91.1 Tx-1.8 L-13 fer 100
425[I] M1:256 1 (128 ) r02.37 a175 20:58:43.077 >*SYNC pn= 128 CHAN=[425]
425[I] M2:207 2 (128 ) r04.40 a178 20:58:43.575 A[ 128 -11,] C[] N[] R[] Re-97 Tx-42.2 L-60
425[I] M2:207 2 (128 ) r04.40 a178 20:58:43.730 p ACPRM PN=[ 128 ]

Hard Handoff 5-9
This is an example where a mobile is in an area with no main server, and is in

four way soft handoff with PN 128, 112, 116, and 248 right before the hard
handoff. It triggers the RTD threshold on PN 112 and performs the hard
handoff on it. PN 248 is planned as a false HHO border site with RTD set to
10000. Right after HHO, mobile FER goes up to 90% while Ec/Io on 112 is
only around –17dB. After the call drop, the mobile then re-synchronizes on to
PN 128 on frequency 425 with Ec/Io of –11dB. This indicates that if PN 116,
128, and 248 were added as new target cells for PN 112, the call would not
have been dropped, because it can go into soft handoff with them
immediately after HHO for supporting the FWD link and the FWD FER can
be improved.
The other logged drive test messages by RF Optimizer shows an ISSHO

problem:
Message Analysis:
425[T] M2:075 2 (068) r04.09 a016 20:22:09.282 F[< 68-10>] A[64 -13, 68 -11, 116 -18, 164 -18,] C[] N[] R[152-22, 248-22,] Rx-79.8 Tx-7 L-7
425[T] M2:075 2 (068) r04.09 a016 20:22:09.307 < MSACK A1 M7 0
425[T] M2:075 2 (068) r04.09 a016 20:22:09.328 > EHDM M1 A7 1 [ 164 64 68 116]
425[T] M2:075 2 (068) r04.09 a016 20:22:09.347 < HCM A1 M0 1
425[T] M2:075 2 (068) r04.09 a016 20:22:09.368 > EHDM M1 A7 1 [ 164 64 68 116]
425[T] M2:075 2 (068) r04.09 a016 20:22:09.407 < MSACK A1 M0 0
425[T] M2:075 2 (068) r04.09 a016 20:22:09.447 < MSACK A1 M1 0
425[T] M2:075 2 (068) r04.09 a016 20:22:09.508 > NBLUM M2 A0 1 [72 168 52 56 128 16 156 152 140 200 272 124 212 160 112 120 248 128 244]
425[T] M2:075 2 (068) r04.09 a016 20:22:09.587 < MSACK A2 M2 0
500[H] M2:075 2 (164) r04.09 a016 20:22:09.648 > EHDM M3 A0 0 6,28,32, 3, [HARD [CH 500 PN 164]
500[H] M1:019 2 (164) r01.33 a157 20:22:09.631 F[< 164-14>] A[] C[] N[] R[] Rx-79.8 Tx-7 L-7
500[H] M1:019 2 (164) r01.33 a157 20:22:10.098 F[<-999 0>] A[64 -10, 164 -15,] C[] N[] R[] Rx-67.8 Tx-13 L-1
500[H] M1:019 2 (164) r01.33 a157 20:22:11.466 < HCM A7 M0 1
500[H] M1:019 2 (164) r01.33 a157 20:22:11.506 < PSMM A7 M1 1 [REF 164 @-18.0 k | 64 +22 @-16.0 k| 68 +22 @-14.0 k| 116 +17 @-26.5 k|
500[H] M1:019 2 (164) r01.37 a158 20:22:11.853 F[< 164-15>] A[164 -20,] C[64 -16, 68 -14, 116 -26,] N[] R[] Rx-68.4 Tx 1.4 L 12 fer 87.8
500[H] M1:019 2 (164) r01.37 a158 20:22:12.306 < HCM A7 M0 1
500[T] M1:019 2 (164) r01.37 a158 20:22:12.427 > NBLUM M0 A0 1 [160 168 108 172 180 100 64 140 216 76]
500[T] M1:019 2 (164) r01.37 a158 20:22:12.427 F[< 164-15>] A[164 -17,] C[64 -16, 68 -14, 116 -26,] N[] R[] Rx-68.4 Tx 1.4 L 12
500[T] M1:019 2 (164) r01.37 a158 20:22:12.506 < MSACK A0 M0 0
500[T] M1:019 2 (164) r01.37 a158 20:22:13.427 > EHDM M2 A1 1 6,28,32, 3, [ 164 64]
500[T] M1:019 2 (164) r01.37 a158 20:22:13.586 < MSACK A2 M1 0
500[T] M1:019 2 (164) r01.37 a158 20:22:13.626 < HCM A2 M3 1
500[T] M1:019 2 (164) r01.37 a158 20:22:13.647 > PCPAR M1 A0 1
500[T] M1:019 2 (164) r01.37 a158 20:22:13.666 < PSMM A2 M2 1 [REF 164 @-18.5 k | 64 +21 @-16.5 k| 68 +21 @-14.0 k| 116 +16 @-26.5 k|
500[T] M1:019 2 (164) r01.37 a158 20:22:13.706 < PSMM A2 M4 1 [REF 164 @-15.5 k | 64 +24 @-25.0 k| 68 +23 @-31.5 k| 116 +17 @-31.5 k| 108 -10 @-
10.5 k|
500[T] M1:019 2 (164) r01.37 a158 20:22:13.746 < MSACK A1 M2 0
500[T] M1:019 2 (164) r01.37 a158 20:22:13.748 > NBLUM M3 A3 1 [160 168 108 172 180 100 140 216 76 68 72 156 152 200 272 124 212]
500[T] M1:019 2 (164) r01.37 a158 20:22:13.808 > EHDM M4 A2 1 [ 164 64 68]
500[T] M1:019 2 (164) r01.37 a158 20:22:13.826 < MSACK A3 M3 0

500[T] M1:019 2 (164) r01.37 a158 20:22:13.827 > EHDM M4 A2 1 [ 164 64 68]
500[T] M1:019 2 (164) r01.42 a158 20:22:13.748 F[< 164-10>] A[64 -21, 68 -23, 164 -17,] C[108 -10, 116 -29,] N[] R[] Rx-66.5 Tx 2.5 L 16 fer 78.3
500[T] M1:019 2 (164) r01.42 a158 20:22:14.028 > NBLUM M5 A5 1 [160 168 108 172 180 100 140 216 76 72 84 52 56 128 28 40 80 192 184 16]
500[T] M1:019 2 (164) r01.42 a158 20:22:14.106 < MSACK A5 M5 0
10.5 k|
10.5 k|
500[T] M1:019 2 (164) r01.42 a158 20:22:15.506 < PSMM A5 M6 1 [REF 164 @-14.0 k | 64 +24 @-30.5 k| 68 +23 @-31.5 k| 108 -10 @-12.0 k|
500[T] M1:019 2 (164) r01.45 a159 20:22:16.082 F[< 164-16>] A[64 -24, 68 -27, 164 -20,] C[108 -11, 116 -31,] N[] R[] Rx-65.8 Tx-8.4 L 5 fer 90.6
10.5 k|
500[T] M1:019 2 (164) r01.45 a159 20:22:16.126 < PSMM A5 M6 1 [REF 164 @-14.0 k | 64 +24 @-30.5 k| 68 +23 @-31.5 k| 108 -10 @-12.0 k|
500[T] M1:019 2 (164) r01.45 a159 20:22:16.307 > BSACK M7 A4 0
500[T] M1:019 2 (164) r01.45 a159 20:22:16.347 > BSACK M0 A6 0
500[T] M1:019 2 (164) r01.48 a159 20:22:18.088 F[< 64-18> 68] A[64 -16, 68 -17, 164 -17,] C[108 -11, 116 -31,] N[] R[] Rx-66.3 Tx 2.6 L 16 fer 33.6
500[T] M1:019 2 (164) r01.48 a159 20:22:18.966 < PSMM A5 M7 1 [REF 164 @-23.5 d | 64 +22 @-21.5 k| 68 +22 @-23.5 k| 108 -12 @-12.5 k|
500[T] M1:019 2 (164) r01.52 a159 20:22:19.872 F[< 164-16>] A[64 -20, 68 -19, 164 -20,] C[108 -12,] N[] R[] Rx-68.2 Tx 11 L 22 fer 95
500[T] M1:019 2 (164) r01.54 a159 20:22:21.871 F[164-17 68] A[64 -24, 68 -21, 164 -21,] C[] N[] R[] Rx-66.3 Tx 2.8 L 16 fer 100
500[T] M1:019 2 (164) r01.54 a159 20:22:22.046 < PSMM A5 M0 1 [REF 164 @-20.0 d | 64 +21 @-28.0 d| 68 +21 @-25.5 d| 108 -11 @-13.5 k|
500[T] M1:019 2 (164) r01.54 a159 20:22:22.086 < PSMM A5 M7 1 [REF 164 @-23.5 d | 64 +22 @-21.5 k| 68 +22 @-23.5 k| 108 -12 @-12.5 k|
500[T] M1:019 2 (164) r01.54 a159 20:22:22.307 > BSACK M1 A7 0
500[T] M1:019 2 (164) r01.54 a159 20:22:22.466 < PSMM A5 M0 1 [REF 164 @-20.0 d | 64 +21 @-28.0 d| 68 +21 @-25.5 d| 108 -11 @-13.5 k|
500[T] M1:019 2 (164) r01.54 a159 20:22:22.687 > BSACK M2 A0 0
500[T] M1:019 2 (164) r01.60 a160 20:22:24.063 F[< 68-17> 64] A[64 -20, 68 -19, 164 -20,] C[108 -13,] N[] R[] Rx-67.5 Tx 4.4 L 16 fer 86.7
500[T] M1:019 2 (164) r01.63 a160 20:22:25.868 F[< 68-18> 64] A[64 -22, 68 -21, 164 -23,] C[] N[] R[] Rx-71.8 Tx 7 L 15 fer 100
500[T] M1:019 2 (164) r01.67 a160 20:22:28.088 F[< 68-14> 64] A[64 -19, 68 -16, 164 -20,] C[] N[] R[] Rx-74.1 Tx 4.2 L 10 fer 72
500[T] M1:019 2 (164) r01.70 a160 20:22:29.868 F[68-17 164 64] A[64 -17, 68 -16, 164 -16,] C[] N[] R[] Rx-77.1 Tx 5.3 L 8 fer 29
500[T] M1:019 2 (164) r01.70 a160 20:22:30.488 > EHDM M6 A0 1 [ 164 64]
500[T] M1:019 2 (164) r01.70 a160 20:22:30.506 < MSACK A6 M6 0
500[T] M1:019 2 (164) r01.70 a160 20:22:30.546 < HCM A6 M1 1
500[T] M1:019 2 (164) r01.70 a160 20:22:30.586 < PSMM A6 M2 1 [REF 164 @-14.5 k | 64 +30 @-21.0 k| 68 +30 @-20.0 k|
500[T] M1:019 2 (164) r01.70 a160 20:22:30.767 > EHDM M0 A2 1 [ 164 64 68]
500[T] M1:019 2 (164) r01.70 a160 20:22:30.786 < MSACK A0 M7 0
500[T] M1:019 2 (164) r01.70 a160 20:22:30.788 > EHDM M0 A2 1 [ 164 64 68]
500[T] M1:019 2 (164) r01.70 a160 20:22:30.807 > EHDM M0 A2 1 [ 164 64 68]
500[T] M1:019 2 (164) r01.70 a160 20:22:30.826 < HCM A0 M3 1
500[T] M1:019 2 (164) r01.70 a160 20:22:30.866 < MSACK A0 M0 0
500[T] M1:019 2 (164) r01.70 a160 20:22:30.906 < MSACK A0 M1 0
500[T] M1:019 2 (164) r01.70 a160 20:22:30.966 < HCM A0 M1 1
500[T] M1:019 2 (164) r01.70 a160 20:22:31.246 < HCM A0 M3 1
500[T] M1:019 2 (164) r01.70 a160 20:22:31.426 < HCM A0 M1 1
500[T] M1:019 2 (164) r01.70 a160 20:22:31.467 > BSACK M4 A3 0
500[T] M1:019 2 (164) r01.70 a160 20:22:31.507 > NBLUM M7 A1 1 [160 168 108 172 180 100 140 216 76 68 72 156 152 200 272 124 212]
500[T] M1:019 2 (164) r01.70 a160 20:22:31.586 < MSACK A7 M2 0
500[T] M1:019 2 (164) r01.73 a160 20:22:31.871 F[164-18 64 68] A[64 -17, 68 -17, 164 -17,] C[] N[] R[] Rx-74.7 Tx.3 L 5 fer 67
500[T] M1:019 2 (164) r01.73 a160 20:22:32.147 > NBLUM M1 A3 1 [160 168 108 172 180 100 140 216 76 72 84 52 56 128 28 40 80 192 184 16]
500[T] M1:019 2 (164) r01.73 a160 20:22:32.226 < MSACK A1 M3 0
500[T] M1:019 2 (164) r01.76 a160 20:22:34.107 F[< 164-15> 64 68] A[64 -17, 68 -16, 164 -14,] C[] N[] R[] Rx-72.8 Tx 3.3 L 10 fer 25.2
500[T] M1:019 2 (164) r01.79 a161 20:22:36.101 F[< 164-16>] A[164 -13,] C[] N[] R[] Rx-64.2 Tx-5.7 L 10 fer 29
500[T] M1:019 2 (164) r01.81 a161 20:22:37.868 F[< 164-17>] A[164 -20,] C[] N[] R[] Rx-61.9 Tx-8.2 L 9 fer 99
500[T] M1:019 2 (164) r01.84 a161 20:22:40.090 F[<-999 0>] A[] C[] N[] R[] Rx-65 Tx-5.2 L 9 fer 100
500[T] M1:019 2 (164) r01.87 a161 20:22:42.070 F[< 164 0>] A[164 -21,] C[] N[] R[] Rx-64.5 Tx-45.2 L-30
500[I] M1:019 2 (104) r01.87 a161 20:22:42.622 >*SYNC pn= 104 CHAN=[500]
500[I] M1:019 2 (104 ) r01.87 a161 20:22:43.208 p CHLST pn= 104 N= 1 500

Hard Handoff 5-11
500[I] M1:261 2 (104) r01.81 a178 20:22:43.430 p SPARM PN=[104] 4120, 3,

Looking through the messages, it is seen that the mobile was on F2
(frequency channel 425) in four way soft handoff with PN 64, 68 (on
BSC_1), and 164, 116 (on BSC_2) right before the hard handoff. The mobile
triggered the RTD threshold on PN 164 and performed the hard handoff on it.
Right after HHO, when mobile is listening to PN 164 only, its Ec/Io is around
–15dB and FER goes 87.8%. Mobile then goes into an area with no main
server and gets into multiple way handoff. Mobile sees a PN108 with Ec/Io
around –11dB and request for handoff with it. The handoff request is not
permitted because of interference by 108 (108 is in the NL of PN 164, the
pilot mobile was listening to at the PSMM time).
The mobile remains on the weak PNs until the call dropped. The mobile syncs
on to PN104 on F1 (frequency channel 500) later. The solution obviously is to
add PN 108, 64, 68, and 116 as new target cells for PN 164, and to allow the
mobile goes into soft handoff with them immediately after HHO for
supporting the FWD link.
This is an example with multiple target PNs on different MTXs. PN 64 and 68

are on BSC_1 switch and PN 108, 116, and 164 are on BSC_2. As long as site
075 (for PN 64 and 68) is defined as the logical site for BSC_2 switch (for
ISSHO purpose), we can datafill them as the multiple targets on 164 HHO.
The call drops immediately after Hard Handoff is recorded in the following
message:
21:11:18.656 - rf status Re -96.41 Tx 1.62 LB-15 A[ 324 -13, 336 -20.5, 340 -5.5,] C[] R[] r 1.93 a 162.
21:11:20.656 - rf status Re -98.19 Tx 2.44 LB-16 A[ 324 -14.5, 336 -16.5, 340 -5,] C[] N[ 224 268 272 328 352 ] R[] r 1.98 a 162.
21:11:23.396 < PSSM A3 M7 1 [REF 340 @ -6.0 k | 324 +11 @-15.0 k| 336 +1 @-17.0 d|
21:11:23.518 > EHDM M4 A7 1 [ 324 340 ]
21:11:23.536 < MSACK A4 M4 0
21:11:23.576 < HCM A4 M0 1 [ 324 340 ]
21:11:23.738 > NBLUM M5 A0 1 [ 336 352 328 272 464 ]
21:11:23.816 < MSACK A5 M5 0
21:11:23.998 > EHDM M4 A0 0 [HARD [ CH 50 PN340]
21:11:24.038 > EHDM M4 A0 0 [HARD [ CH 50 PN340]
21:11:24.078 > EHDM M4 A0 0 [HARD [ CH 50 PN340]
21:11:22.656 - rf status Re -92.62 Tx -5.67 LB-19 A[ 340 -6,] C[] N[ 184 224 268 328 336-11.5, 352 464] R[] r 2.00 a 163.
21:11:26.008 < HCM A7 M0 1 [ 340 ]
21:11:24.667 - rf status Re -76.67 Tx-14.97 LB-12 A[ 340 -15.5,] C[] N[ 224 268 328 352 464] R[] r 2.10 a 163.
21:11:26.667 - rf status Re -76.12 Tx 9.00 LB 12 A[ 340 -18.5,] C[] N[ 184 224 268 324 328 336 352 ] R[ 142-20.5,] r 2.13 a 164.
21:11:28.668 - rf status Re -74.37 Tx 7.09 LB 12 A[ 340 -17.5,] C[] N[ 184 224 268 324 328 336 352 464] R[] r 2.18 a 164.
21:11:32.407 >*SYNC polytope 0x18c = 396 ( 396 ) cdma_freq 50
21:11:33.707 p SPARM polytope 0x18c = 396 ( 396 )
21:11:30.667 - rf status Re -76.28 Tx-36.73 LB-34 A[ 0 -10, 396 -10.5,] C[] N[ 224 268 336 340 352 404 464] R[] r 2.23 a 164.
21:11:34.005 - rf status Re -80.50 Tx-52.25 LB-53 A[ 396 -8.5,] C[] N[ 48 340 404] R[] r 2.29 a 164.
21:11:36.005 - rf status Re -86.47 Tx-51.99 LB-59 A[ 396 -14, 400 -16.5,] C[] N[ 48-15, 340] R[] r 2.40 a 164.
21:11:45.472 >*SYNC polytope 0x30 = 48 ( 48 ) cdma_freq 50
21:11:46.088 p SPARM polytope 0x30 = 48 ( 48 )
21:11:38.005 - rf status Re -88.84 Tx-50.29 LB-60 A[ 0 -12,] C[] N[ 48-11.5, 60-13, 340 404] R[ 152-19.5,] r 2.42 a 164.

Examine MS RX signal strength immediately before and after the HHO

attempt. If it increases significantly, there is a stronger server than the target
cell controlling the HHO point. The HHO is occurring late.
Check the message log for soft handoff with standard cells that were dropped
immediately before HHO. If this is the condition, try downtilting that cell if
possible to reduce its overshoot into this border cell. If not try reducing the
RTD threshold to move the HHO point nearer to the boundary cell site.
The call dropped after a late (1.98KM from site RTD dist 1KM) hard handoff
prolonged by soft handoff with non border backlobe cell 336. This drop was
caused by interference from PN 396 ch 50 corrupting signalling on PN 340 ch
50. Indicated by increase in RX power from -98 on ch100 to -76 on ch50.
External Interference
This section explains the characteristics in the data for a mobile that
experiences forward link interference from a source outside the CDMA
system being optimized.
Some possible sources of interference are: intermodulation from an AMPS-

only BTS, co-channel interference from an AMPS BTS that has not been
cleared from the CDMA channel, an adjacent CDMA operator using the same
channel (this remains until inter-system soft handoff is available), a
microwave link, raised noise floor caused by the transmitter spectrum of
another CDMA operator in the same market but on a different channel.
Indications in Mobile Data

If only mobile data is available, the parametric files show:
• Good receive power (> -100dBm)
• Normal transmit power (< +20dBm)
• Higher than normal Transmit Gain Adjust (actual value depends on site
• High forward FER
• Low best server Ec/Io (< -12dB)
Under these conditions, forward link messaging is not reliable at best and can
be the actual cause of the drop. The message file output can show some or all
of the following:
• Repeats of the same message (check that the msg seq and ack seq
numbers are the same to make sure it is the same message).
• If a reverse message is repeated because an ack is not received, either it is
not reaching the selector (reverse link is worse) or the fwd ack is not

External Interference 5-13
reaching the mobile (fwd link is worse). The parametric files can indicate
which is occurring but ideally selector logs are required.
• If a fwd message is repeated then the rvs ack is not reaching the selector
(reverse link is worse).
• If the mobile repeats a message 3 times without seeing the ack, it tears the
call down and will go to the sync channel.
• If the selector repeats a message 5 times without seeing the ack, it sends a
forward release and the call is torn down. If the mobile sees the release, it
responds with a reverse release and stops transmitting. Otherwise, the
mobile times out if two consecutive good frames are not received within 5
seconds.


A-1
Appendix A- QCP Tech Mode Screen A

Handset Monitor Mode
Found on the handset by choosing menu - 7 - 0, a display appears with two
rows of three values. Moving from left to right across the rows, the following
items appear.
First row
PN Offset: in decimal
Receive State: uses the following codes:
0: Pilot Channel Acquisition
1: Sync Channel Acquisition
2: Idle
3: Access
4: Traffic Channel
Receive Power: In coded hex, can be translated by converting the hex number
to decimal, subtracting 256 from the decimal value, divide result by three, and
then subtract 63.25 (800MHz) or 66.25 (1900MHz). This final result is in
dBm.
Second row
First value unsupported
Second value unsupported
Transmit Gain Adjust: In coded hex, can be translated by converting value to

decimal and dividing by -2 (a value of 7F means the transmitter is inactive).

A-2 Appendix A- QCP Tech Mode Screen
Press This: See This: continue: See This:
Menu D D
MAIN MENU ↓ DEBUG ↓
0↓
1:Volume 1:Screen
2:Call Info 2:Test Calls
3:Security 3:CDMA Only
4 * D
D DEBUG ↑
0↑
4:Errors
FEATURES ↓
4↓ 5:Clr Errors
1:AutoAnswer 6:13K Voice
2:AutoRetry
3:Scratchpad 1
0
D
D 318 2 9D
X A 7F
ENTER FIELD
SERVICE CODE
******
See following
0 0 0 0 0 0 * explanation of
maintenance
(* or correct code, if different) display values

0 - Pilot Channel Acquisition Substate

1 - Sync Channel Acquisition Substate
2 - MS Idle State QCP- QCP-
3 - System Access State 1900 800
4 - Traffic Channel State
FF -67 -64
Receive State
F5 -70 -67
E6 -75 -72
D D7 -80 -77
C8 -85 -82
B9 -90 -87
PN Offset 318 2 94 Receive Power
AA -95 -92
9B -100 -97
X A 7F 8C -105 -102
80 -109 -106
Unsupported Transmit Adjust Receive

ReceivePower
PowerConversion:
Conversion:
RX
RXdBm = XXDEC / 3- -63.25
= XX / 3 63.25(800
(800MHz)
A = active pilots 7F 11.5
RX
dBm
= XX
DEC
/
MHz)
00 0 RX = XX
dBm DEC / 3 - 66.25 (1900MHz)
3 - 66.25 (1900 MHz)
X = exit reason dBm
(if(ifXX
DEC
0A -5 XX>>7F,
7F,replace
replaceXX
XXwith
withXX
XX- -256)
256)
14 -10 Transmit
TransmitGain
GainAdjust
AdjustConversion:
Conversion:
1E -15 TXADJ
TXADJdB = XXDEC / /22
= XX
dB DEC
28 -20 Transmit
TransmitPower
PowerOutput
OutputConversion:
Conversion:
TX
TXdBm = -73 - RX - TXADJ dB (800 MHz)
dBm = -73 - RXdBm - TXADJdB (800 MHz)
dBm
TXdBm = -76 - RXdBm - TXADJdB (1900

TX = -76 - RX - TXADJ (1900MHz)
MHz)
dBm dBm dB
1900 MHz PCS 800 MHz Cellular 1900 MHz PCS 800 MHz Cellular
Rx TxAdj Rx TxAdj Rx TxAdj Rx TxAdj
FF -67 0.5 -64 0.5 F9 -69 3.5 -66 3.5
FE -67 1 -64 1 F8 -69 4 -66 4

FD -67 1.5 -64 1.5 F7 -69 4.5 -66 4.5
FC -68 2 -65 2 F6 -70 5 -67 5
FB -68 2.5 -65 2.5 F5 -70 5.5 -67 5.5
FA -68 3 -65 3 F4 -70 6 -67 6
F3 -71 6.5 -68 6.5 DB -79 18.5 -76 18.5
F2 -71 7 -68 7 DA -79 19 -76 19

F1 -71 7.5 -68 7.5 D9 -79 19.5 -76 19.5
F0 -72 8 -69 8 D8 -80 20 -77 20

EF -72 8.5 -69 8.5 D7 -80 20.5 -77 20.5

EE -72 9 -69 9 D6 -80 21 -77 21
ED -73 9.5 -70 9.5 D5 -81 21.5 -78 21.5
EC -73 10 -70 10 D4 -81 22 -78 22

EB -73 10.5 -70 10.5 D3 -81 22.5 -78 22.5
EA -74 11 -71 11 D2 -82 23 -79 23
E9 -74 11.5 -71 11.5 D1 -82 23.5 -79 23.5
E8 -74 12 -71 12 D0 -82 24 -79 24
E7 -75 12.5 -72 12.5 CF -83 24.5 -80 24.5
E6 -75 13 -72 13 CE -83 25 -80 25
E5 -75 13.5 -72 13.5 CD -83 25.5 -80 25.5
E4 -76 14 -73 14 CC -84 26 -81 26
E3 -76 14.5 -73 14.5 CB -84 26.5 -81 26.5
E2 -76 15 -73 15 CA -84 27 -81 27

E1 -77 15.5 -74 15.5 C9 -85 27.5 -82 27.5
E0 -77 16 -74 16 C8 -85 28 -82 28
DF -77 16.5 -74 16.5 C7 -85 28.5 -82 28.5

DE -78 17 -75 17 C6 -86 29 -83 29
DD -78 17.5 -75 17.5 C5 -86 29.5 -83 29.5
DC -78 18 -75 18 C4 -86 30 -83 30

C3 -87 30.5 -84 30.5 AB -95 42.5 -92 42.5
C2 -87 31 -84 31 AA -95 43 -92 43
C1 -87 31.5 -84 31.5 A9 -95 43.5 -92 43.5
C0 -88 32 -85 32 A8 -96 44 -93 44
BF -88 32.5 -85 32.5 A7 -96 44.5 -93 44.5
BE -88 33 -85 33 A6 -96 45 -93 45
BD -89 33.5 -86 33.5 A5 -97 45.5 -94 45.5
BC -89 34 -86 34 A4 -97 46 -94 46

BB -89 34.5 -86 34.5 A3 -97 46.5 -94 46.5

BA -90 35 -87 35 A2 -98 47 -95 47
B9 -90 35.5 -87 35.5 A1 -98 47.5 -95 47.5
B8 -90 36 -87 36 A0 -98 48 -95 48

B7 -91 36.5 -88 36.5 9F -99 48.5 -96 48.5
B6 -91 37 -88 37 9E -99 49 -96 49
B5 -91 37.5 -88 37.5 9D -99 49.5 -96 49.5
B4 -92 38 -89 38 9C -100 50 -97 50
B3 -92 38.5 -89 38.5 9B -100 50.5 -97 50.5
B2 -92 39 -89 39 9A -100 51 -97 51
B1 -93 39.5 -90 39.5 99 -101 51.5 -98 51.5
B0 -93 40 -90 40 98 -101 52 -98 52
AF -93 40.5 -90 40.5 97 -101 52.5 -98 52.5
AE -94 41 -91 41 96 -102 53 -99 53

AD -94 41.5 -91 41.5 95 -102 53.5 -99 53.5
AC -94 42 -91 42 94 -102 54 -99 54
93 -103 54.5 -100 54.5 7B -25 -61.5 -22 -61.5

92 -103 55 -100 55 7A -26 -61 -23 -61
91 -103 55.5 -100 55.5 79 -26 -60.5 -23 -60.5
90 -104 56 -101 56 78 -26 -60 -23 -60

8F -104 56.5 -101 56.5 77 -27 -59.5 -24 -59.5
8E -104 57 -101 57 76 -27 -59 -24 -59
8D -105 57.5 -102 57.5 75 -27 -58.5 -24 -58.5
8C -105 58 -102 58 74 -28 -58 -25 -58
8B -105 58.5 -102 58.5 73 -28 -57.5 -25 -57.5
8A -106 59 -103 59 72 -28 -57 -25 -57
89 -106 59.5 -103 59.5 71 -29 -56.5 -26 -56.5
88 -106 60 -103 60 70 -29 -56 -26 -56

87 -107 60.5 -104 60.5 6F -30 -55.5 -27 -55.5

86 -107 61 -104 61 6E -30 -55 -27 -55
85 -107 61.5 -104 61.5 6D -30 -54.5 -27 -54.5
84 -108 62 -105 62 6C -31 -54 -28 -54

83 -108 62.5 -105 62.5 6B -31 -53.5 -28 -53.5
82 -108 63 -105 63 6A -31 -53 -28 -53
81 -109 63.5 -106 63.5 69 -32 -52.5 -29 -52.5
80 -109 64 -106 64 68 -32 -52 -29 -52
7F -24 -63.5 -21 -63.5 67 -32 -51.5 -29 -51.5
7E -24 -63 -21 -63 66 -33 -51 -30 -51
7D -25 -62.5 -22 -62.5 65 -33 -50.5 -30 -50.5
7C -25 -62 -22 -62 64 -33 -50 -30 -50
63 -34 -49.5 -31 -49.5 4B -42 -37.5 -39 -37.5
62 -34 -49 -31 -49 4A -42 -37 -39 -37
61 -34 -48.5 -31 -48.5 49 -42 -36.5 -39 -36.5
60 -35 -48 -32 -48 48 -43 -36 -40 -36
5F -35 -47.5 -32 -47.5 47 -43 -35.5 -40 -35.5
5E -35 -47 -32 -47 46 -43 -35 -40 -35
5D -36 -46.5 -33 -46.5 45 -44 -34.5 -41 -34.5
5C -36 -46 -33 -46 44 -44 -34 -41 -34

5B -36 -45.5 -33 -45.5 43 -44 -33.5 -41 -33.5
5A -37 -45 -34 -45 42 -45 -33 -42 -33
59 -37 -44.5 -34 -44.5 41 -45 -32.5 -42 -32.5

58 -37 -44 -34 -44 40 -45 -32 -42 -32
57 -38 -43.5 -35 -43.5 3F -46 -31.5 -43 -31.5
56 -38 -43 -35 -43 3E -46 -31 -43 -31
55 -38 -42.5 -35 -42.5 3D -46 -30.5 -43 -30.5
54 -39 -42 -36 -42 3C -47 -30 -44 -30

53 -39 -41.5 -36 -41.5 3B -47 -29.5 -44 -29.5

52 -39 -41 -36 -41 3A -47 -29 -44 -29
51 -40 -40.5 -37 -40.5 39 -48 -28.5 -45 -28.5
50 -40 -40 -37 -40 38 -48 -28 -45 -28

4F -40 -39.5 -37 -39.5 37 -48 -27.5 -45 -27.5
4E -41 -39 -38 -39 36 -49 -27 -46 -27
4D -41 -38.5 -38 -38.5 35 -49 -26.5 -46 -26.5
4C -41 -38 -38 -38 34 -49 -26 -46 -26
33 -50 -25.5 -47 -25.5 1B -58 -13.5 -55 -13.5
32 -50 -25 -47 -25 1A -58 -13 -55 -13
31 -50 -24.5 -47 -24.5 19 -58 -12.5 -55 -12.5
30 -51 -24 -48 -24 18 -59 -12 -56 -12
2F -51 -23.5 -48 -23.5 17 -59 -11.5 -56 -11.5
2E -51 -23 -48 -23 16 -59 -11 -56 -11
2D -52 -22.5 -49 -22.5 15 -60 -10.5 -57 -10.5
2C -52 -22 -49 -22 14 -60 -10 -57 -10
2B -52 -21.5 -49 -21.5 13 -60 -9.5 -57 -9.5
2A -53 -21 -50 -21 12 -61 -9 -58 -9
29 -53 -20.5 -50 -20.5 11 -61 -8.5 -58 -8.5
28 -53 -20 -50 -20 10 -61 -8 -58 -8
27 -54 -19.5 -51 -19.5 0F -62 -7.5 -59 -7.5
26 -54 -19 -51 -19 0E -62 -7 -59 -7
25 -54 -18.5 -51 -18.5 0D -62 -6.5 -59 -6.5

24 -55 -18 -52 -18 0C -63 -6 -60 -6
23 -55 -17.5 -52 -17.5 0B -63 -5.5 -60 -5.5
22 -55 -17 -52 -17 0A -63 -5 -60 -5

21 -56 -16.5 -53 -16.5 09 -64 -4.5 -61 -4.5
20 -56 -16 -53 -16 08 -64 -4 -61 -4

1F -56 -15.5 -53 -15.5 07 -64 -3.5 -61 -3.5

1E -57 -15 -54 -15 06 -65 -3 -62 -3
1D -57 -14.5 -54 -14.5 05 -65 -2.5 -62 -2.5
1C -57 -14 -54 -14 04 -65 -2 -62 -2

03 -66 -1.5 -63 -1.5 01 -66 -0.5 -63 -0.5
02 -66 -1 -63 -1 00 -67 0 -64 0

B-1
Appendix B- Calculating Required

Power Reduction for Unwanted PN B
Assume 4 pilots are being received at strengths as follows:
-7dB
-7dB
-10dB
-11dB
and we want to get the last one below T_ADD (-14dB). A simple reduction of
3dB will not achieve the required results since the Io will also reduce when
this pilot is lowered. A quick way to find out the Io reduction is to assign
weightings to the pilots, starting with 1 for the strongest:
-7 = 1
-7 = 1
-10 = 0.5
-11 = 0.4
for a grand total of 2.9. When we remove the last, we will have an Io
reduction of 2.5/2.9 = -0.64dB. Therefore, the pilot needs to lowered by 3 +
0.64 = 3.64dB.

B-2 Appendix B- Calculating Required Power Reduction for Unwanted PN

test
Family Product Manual Contacts Copyright Confidentiality Legal
CDMA
CDMA
To order documentation from Nortel Networks Global Wireless Knowledge Services, call
(1) (877) 662-5669
To report a problem in this document, call

(1) (877) 662-5669
or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at
http://www.nortelnetworks.com/td
Copyright  1996–2001 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in
writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its
employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the
same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly
authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein.
Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as
progress in engineering and manufacturing may warrant.
* Nortel Networks, the Nortel Networks logo, the Globemark HOW the WORLD SHARES IDEAS, and Unified Networks are
trademarks of Nortel Networks. Planet is a Trademark of Mobile Systems International (MSI)Surveyor is a Trademark of Grayson
Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
Document number: 411-2133-004
Product release: NBSS 10.1
Document version: Standard 03.01
Date: December 2001
Printed in the United States of America

CDMA Ebook

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CDMA Ebook

Hochgeladen von

Copyright:

Verfügbare Formate

411-2133-004

NBSS 10.1 Standard 03.01 December 2001

Document number: 411-2133-004

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright  1996–2001 Nortel Networks, All Rights Reserved

NORTEL NETWORKS CONFIDENTIAL

411-2133-004 Standard 03.01 December 2001

Updated to new NBSS 9.0 Software revision

NBSS 8.1 standard release

NBSS 8.1 preliminary release

NBSS 8.2 preliminary release

Initial release for technical review

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

411-2133-004 Standard 03.01 December 2001

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

Types of RF Optimization Parameters 2-7

411-2133-004 Standard 03.01 December 2001

Advanced FA (Frequency Assignment) MO 3-48

Chapter 5 - Dropped Call and Access Failure Reasons and

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

Appendix A- QCP Tech Mode Screen A-1

Appendix B- Calculating Required Power Reduction for Unwanted

411-2133-004 Standard 03.01 December 2001

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

411-2133-004 Standard 03.01 December 2001

About this document 1

Audience for this document

• NTP 411-2133-009, CDMA Traffic and Capacity Engineering Guidelines

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

411-2133-004 Standard 03.01 December 2001

An interesting perspective on 2G vs 3G optimization is emerging from Nortel

In an effort to reduce the amount of duplicated information, there are several

• NTP 411-2133-009, CDMA Traffic and Capacity Engineering Guidelines

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

• NTP 411-2133-506, CDMA Metro Cell System and RF Datafill

CDMA Power Control Principles

The traffic management has being expanded in IS-2000 (or 1xRTT)

411-2133-004 Standard 03.01 December 2001

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

Intelligent Paging Planning

3G-2G Voice Hard Handoff

1xRTT Link Budget

1xRTT RC3 Reverse Link RF Performance

411-2133-004 Standard 03.01 December 2001

aiming at estimating the coverage and capacity performance in a more real-

BTS Forward Power Budget Worksheet

1xRTT Radio Resource Manager

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

Optimization Overview (cont)

Improve Call Performance - This aspect includes reducing dropped calls

Efficient Capacity Management - This aspect includes maintaining enough

• system or cluster shakedown, de-bug, and datafill audit

411-2133-004 Standard 03.01 December 2001

• RF coverage and handoff control

• RF coverage and handoff control

As your system develops and matures, daily monitoring of call performance

The work during this stage of optimization look at:

CDMA 3G Data and Capacity Solutions RF Optimization Guide NBSS 10.1

• integrating new sites into the existing network

The following items represent the minimum entrance requirements for a

411-2133-004 Standard 03.01 December 2001

Note: The most common method of loading a pre-commercial system is