Scme Do 372411

CDMA2000® 1xEV-DO
System Capacity Monitoring and Engineering

(SCME)
Release 30.0 and higher
Guidelines
401-614-331
Issue 6.0
May 2009
Alcatel-Lucent - Proprietary
This document contains proprietary information of Alcatel-Lucent
and is not to be disclosed or used except in accordance with applicable agreements.
Copyright© 2009 Alcatel-Lucent.

Unpublished and not for publication. All rights reserved.
Trademarks
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners.
Copyright© 2009 Alcatel-Lucent. All Rights Reserved.
Conformance Statements
NOTE: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are
designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment
generates, uses, and can radiate radio frequency energy, and if not installed and used in accordance with the instruction manual, may cause harmful interference
to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference in which case the user will be required to
correct the interference at his/her own expense.
Security Statement
In rare instances, unauthorized individuals make connections to the telecommunications network through the use of remote access features. In such event,
applicable tariffs require that the customer pay all network charges for traffic. Alcatel-Lucent cannot be responsible for such charges and will not make any
allowance or give any credit for charges that result from unauthorized access.
Alcatel-Lucent - Proprietary
See notice on first page.
Contents
About this Document

Purpose of this Document .............................................................................................................................v
Reasons for Reissue ......................................................................................................................................v
New in this Release .......................................................................................................................................v
Related Engineering Documents ................................................................................................................. vi
To obtain technical support, documentation, and training or submit feedback ........................................... vi
1 1xEV-DO
Introduction ............................................................................................................................................... 1-1
2 EV-DO RNC Initial Engineering

RNC Initial Engineering ............................................................................................................................ 2-1
Considerations Affecting Capacity ........................................................................................................... 2-7
Initial Engineering Procedures ................................................................................................................ 2-13
3 EV-DO BTS Initial Engineering

BTS Initial Engineering ............................................................................................................................ 3-1
Procedure 3-1: Determining Sector Data Traffic Load Based on Data Usage Profile .............................. 3-6
Procedure 3-2: Determining Sector Data Traffic Load Based on Data Application Traffic Model ........ 3-10
Procedure 3-3: Determining Sector QoS Traffic Load ............................................................................ 3-15
Procedure 3-4: Determining Number of Carriers (without QoS) ............................................................ 3-18
Procedure 3-5: Determining Number of Carriers (with QoS) ................................................................. 3-21
Procedure 3-6: Determining Backhaul Facilities (without QoS) ............................................................ 3-29
Procedure 3-7: Determining Backhaul Facilities (with QoS) ................................................................. 3-33
Procedure 3-8: Determining Number of Equivalent QoS Units .............................................................. 3-40
4 Base Station OA&M Controller (BSOC) for Stand Alone EV-DO

(SAEVDO)
Procedure 4-1: Determine the number of BSOC RCS-AP pairs ............................................................... 4-4
............................................................................................................................................................................................................................................................
401-614-331 Alcatel-Lucent - Proprietary iii
Issue 6.0 See notice on first page.
May 2009
Contents
5 Growth Engineering, Monitoring and Critical Triggers

Procedure 5-1: GER Part 1—Predicting Future BHCA ............................................................................ 5-2
Procedure 5-2: GER Part 2—Predicting Date a System Component Reaches Capacity .......................... 5-5
1xEV-DO Carrier Growth Engineering Guideline .................................................................................... 5-6
Critical Trigger Recipes .......................................................................................................................... 5-16
EVDO_ACC_CHAN_OCC_% ............................................................................................................... 5-18
EVDO_AP_PO_% .................................................................................................................................. 5-21
EVDO_CONN_ACT_OHM ................................................................................................................... 5-23
EVDO_CONN_ACT_TP ........................................................................................................................ 5-26
EVDO_CONN_SEC ............................................................................................................................... 5-28
EVDO_FL_TS_BUSY_% ...................................................................................................................... 5-32
EVDO_FL_TS_CC_% ............................................................................................................................ 5-35
EVDO_FLM_PO_% ............................................................................................................................... 5-38
EVDO_FWD_DL_OCC_% .................................................................................................................... 5-41
EVDO_LIU_PO_% ................................................................................................................................ 5-45
EVDO_RLM_PO_% .............................................................................................................................. 5-47
EVDO_RVS_DL_OCC_% ..................................................................................................................... 5-50
EVDO_RNC_RL_PPS ........................................................................................................................... 5-53
EVDO_RNC_FL_PPS ............................................................................................................................ 5-55
EVDO_SESS_OHM ............................................................................................................................... 5-57
EVDO_SESS_TP .................................................................................................................................... 5-61
EVDO_SESS_APFR .............................................................................................................................. 5-63
EVDO_TP_PO_% .................................................................................................................................. 5-66
GL Glossary
............................................................................................................................................................................................................................................................
iv Alcatel-Lucent - Proprietary 401-614-331
See notice on first page. Issue 6.0
May 2009
About this Document
Purpose of this Document

This document is designed to cover System Capacity Monitoring and Engineering
(SCME) considerations for the 1xEV-DO system.
Reasons for Reissue

The information contained in this document is current for Release 30.0 and higher, Issue
6.0. The changes and enhancements made for this release are described below.
SCME EVDO will be re-published on the web for important and/or substantial updates.
Please refer to the Alcatel-Lucent customer viewable documentation web site for the latest
information
New in this Release

Issue 6.0 of this document contains new or updated information related to the Release 30.0
and higher, including:
• Updated Mod 2.0 information in Table 1-1, “Maximum Number of T1s Per Controller
Supported per Configuration” (p. 1-3)
• Updated Table 2-4, “R1SR with 752i TP Maximum RNC Capacity” (p. 2-5)
• Updated Table 3-1, “Subscriber Loading” (p. 3-2)
• Edited calculations within “Note 2: The overall forward to reverse link traffic ratio can
be written as:” (p. 3-4)
• Updated values within Table 3-4, “Service Provider Inputs on QoS Usage Profile”
(p. 3-14)
• Updated values within Table 3-7, “Backhaul Unit Physical Bandwidth” (p. 3-25)
• Updated values within Table 3-13, “Backhaul Capacity (Call Legs) of QoS
Applications” (p. 3-32)
• Updated Critical Trigger “EVDO_CONN_ACT_OHM” (p. 5-23)
• Updated Critical Trigger “EVDO_CONN_ACT_OHM” (p. 5-23)
• Updated Critical Trigger “EVDO_RNC_RL_PPS” (p. 5-53)
............................................................................................................................................................................................................................................................
401-614-331 Alcatel-Lucent - Proprietary v
May 2009
About this Document
• New Critical Trigger “EVDO_RNC_FL_PPS” (p. 5-55)

• New Critical Trigger “EVDO_SESS_OHM” (p. 5-57)
• Updated Critical Trigger “EVDO_ACC_CHAN_OCC_%” (p. 5-18)
• Various editorial changes throughout the document
Related Engineering Documents

General engineering and features information can be found in the CDMA Network
Planning Letter (401-610-094).
Engineering information for the Packet Switch and the cell sites are summarized to
provide complete system information in one source. Alcatel-Lucent 9281 Packet Switch
Operations, Administration, and Maintenance (235-200-100) is the source for Packet
Switch.
To obtain technical support, documentation, and training or submit feedback

The Online Customer Support (OLCS) web site, http://support.alcatel-lucent.com,
provides access to technical support, related documentation, related training, and feedback
tools. The site also provides account registration for new users.
............................................................................................................................................................................................................................................................
vi Alcatel-Lucent - Proprietary 401-614-331
May 2009
1 1xEV-DO
Introduction
............................................................................................................................................................................................................................................................
EV-DO (Evolution - Data Optimized) optimizes the air interface for high speed data
services. EV-DO incorporates a different network architecture and thus requires a new
methodology for deployment. The EV-DO system can be deployed as a stand-alone
system or co-located with existing IS95/CDMA2000 networks. The following diagram
depicts a high-level architecture of the EV-DO wireless network.
Figure 1-1 High Level Architecture EV-DO Network with R1SR Frame
............................................................................................................................................................................................................................................................
401-614-331 Alcatel-Lucent - Proprietary 1- 1
May 2009
1xEV-DO Introduction
Figure 1-2 High Level Architecture EV-DO Network with UNC Frame (Logical
Network Connectivity)
RNC Configuration
The EV-DO RNC consists of an RISR FMS frame which can contain up to 8 Application
Processors (APs - CP2140) and 16 Traffic Processors (TPs), or optionally beginning in
R30 of a UNC FMS frame (Universal Network Cabinet) which can contain up to 8
Application Processors (APs - CP2500) and 10 Universal Traffic Processors (UTPs).
The next generation 1xEV-DO RNC is housed in a Universal Network Cabinet (UNC).
The UNC-based RNC provides a capacity increase over the R1SR-based RNC. The UNC
supports up to 600 EV-DO carriers.
There are two types of APs in terms of memory:
• 1 Gbyte (CP2140)
• 2 Gbyte (CP2140, CP2500)
And there are three types of TPs:
• 752i TP
• 690 TP
• UTP (R29 and beyond)
............................................................................................................................................................................................................................................................
1-2 Alcatel-Lucent - Proprietary 401-614-331
May 2009
Base Station Configuration

EV-DO can be supported in all existing Modular cells 1.0-4.0. The addition of the EV-DO
carrier is simply to replace an IS95/3G1x CDM with a EV-DO CDM. The Modular cell
cabinet supports the mixed IS95/3G1x and EV-DO carrier configuration.
The configuration for the EV-DO CDM includes the EVM and the Controller.
EVM
There are two types of EVMs:
• DB-EVM (Dual Board EVM)
• SB-EVM (Single Board EVM)
DB- EVM is composed of FLM (Forward Link Modem) and RLM (Reverse Link
Modem). SB-EVM is composed of BAP (BTS Application Processor) and BMP (BTS
Modem Processor).
CONTROLLER
There are four types of controllers:
• CRC (with modified software to support EV-DO)
• URCm
• URC
• URC-II
The backhaul of EV-DO can support T1/E1 or Ethernet. The table below shows the
maximum number of T1s per controller each configuration can support.
Table 1-1 Maximum Number of T1s Per Controller Supported per Configuration
Mod 1.0 Mod 2.0 M od 3.0 Mod 4.0
CR C 2 2 2 N/A
st
URC m 2 2 4 for the 1 C DM, 2 N/A
per CDM for
subsequent C DMs
URC N/A N/A N/A 4
URC II N/A N/A N/A Up to 8 T1s per
URC -II. Total of
20 T1s per fra me*
*Assumes FID 8973.10 in R31. One frame can have up to 3 controllers. The default
factory configuration is 8 T1s for the 1st controller and 6 T1s for the 2nd and 3rd
controller.
............................................................................................................................................................................................................................................................
May 2009
Each base station can configure up to six 3-sector or one 6-sector EV-DO carriers (support
for 3rd carrier is in R30 with FID 8219.17; support for 4th & 5th carrier is in R31 with
FID 8219.21 and support for 6th carrier is in R32. with FID 8219.16).
FID 8219.21 should be enabled only if all 1xEV-DO RNCs in the RNC group are on the
same release. When an RNC belongs to an RNC group, and the RNCs in the group are not
running the same release, do not enable the 4th and 5th carriers on the RNC.
Reference: For more information on FID 8219.21, refer to the BTS OA&M (401-614-
104).
Each 3-sector carrier requires one EVM (DB-EVM or SB-EVM), and each 6-sector carrier
requires two EVMs (DB-EVM or SB-EVM). From processing capacity perspective, URC
can support the following number of fully loaded carriers:
Table 1-2 URC Capacity

Controller Maximum Maximum
Type Recommended EVDO Recommended EVDO 6-
3-sector Carriers sector Carriers (Rel.0 or
(Rel.0 or Rev.A) Rev.A)
URC/URCm 1 Not supported
URCII 3* 2*
* Assumes FID 12078.44 in R31. Otherwise, URC-II can support two fully loaded 3-
secotor carriers and one 6-sector carrier.
............................................................................................................................................................................................................................................................
May 2009
2 EV-DO RNC Initial Engineering
RNC Initial Engineering

............................................................................................................................................................................................................................................................
RNC Initial Engineering Overview

Initial engineering is a method to initially equip a system based on parameters from the
market need or using standard defined values. The intent of initial engineering is to get a
system up and running that will be close to the projected need (i.e., it does not provide a
procedure that will strictly fulfill all the performance targets). Immediately after the
system is up and running, growth engineering procedures should be executed to correct
deficiencies in initial engineering.
The RNC's capacity is primarily determined by the following resources:
• AP processor occupancy (generally correlated to AP signaling event rate)
• AP active sessions
• AP dormant sessions
• TP processor occupancy
• TP packet per second rate or throughput (for both forward and reverse link)
• TP active sessions
• TP PPP sessions
In addition, the Lead AP has additional capacity constraints:
• Performance impacting feature activation (e. g. some security features)
• OA&M activity (e. g. pcmd)
• Inter RNC activity (A13 idle transfers)
The data server AP has additional capacity constraints
• Call processing and OA&M data access
• Data audits
............................................................................................................................................................................................................................................................
May 2009
EV-DO RNC Initial Engineering RNC Initial Engineering
This section will assist you in initially engineering the RNC. In order to accomplish this,
the following input for RNC Initial Engineering is needed:
• Number of subscribers per RNC
• For VoIP applications, BHCA per sub, call hold time, % origination versus termination
• For PTT applications, BHCA per sub, call hold time, % origination versus termination
• For Best Effort data applications, connection requests per hour per sub, average packet
size, % origination versus termination
• What features are going to be enabled?
• Mobility of the end user (soft hand-offs, A13 idle transfers, etc.)
Important! If this information is not readily available, Alcatel-Lucent proposed

values are available. However, in this case, it is extremely important to verify these
input parameters with growth engineering procedures immediately after the network is
deployed to insure the RNC is properly equipped.
RNC Configurations
The RNC performs the functionalities of EV-DO controller as well as the PCF. The bearer
traffic and in-band signaling traffic are handled by the TP in the RNC, and the AP in the
RNC manages the out-of-band signaling traffic. The R1SR RNC frame, and the UNC
RNC frame, have up to 8 Application Processors (AP). The APs are grouped in pairs. In
addition Each AP has one or two Traffic Processors (TP) on the same shelf. The APs in a
pair run in active-active mode and back each other up. If one of the APs in a pair fails, then
the other AP takes over its load.
R1SR Frame
The R1SR RNC can be equipped with Application Processors (CP2140), Traffic
Processors (TP690, TP752i, or UTP) and one alarm card. Two Cajun Ethernet switches
are used to carry all message, control, and data traffic between these components and the
router that is attached to the RNC.
The following configurations are permissible:
• 2 APs and 4 TPs (690s or 752i) (minimum configuration)
• 4 APs and 8 TPs
• 6 APs and 12 TPs
• 8 APs and 16 TPs (maximum configuration)
• 2 APs and 4 UTPs (minimum configuration)
• 4 APs and 6 UTPs
• 8 APs and 10 UTPs (maximum configuration)
............................................................................................................................................................................................................................................................
May 2009
UNC Frame
The UNC-based RNC (referred to as FMS-2220 cabinet) provides higher capacity per
frame (configurable to up to 600 1xEV-DO carriers) over the R1SR-based RNC. The
FMS-2220 cabinet incorporates two independent Universal Shelves. Each of the Universal
The UNC RNC can be equipped with Application Processors (CP2500 APs), Traffic
Processors (UTP) and one alarm card. Two Extreme Ethernet switches are used to carry all
message, control, and data traffic between these components and the router that is attached
to the RNC.
The following configurations are permissible:
• 2 APs and 4 UTPs (minimum configuration)
• 8 APs and 10 UTPs (maximum configuration)
For more information on hardware components and configuration requirements, refer to
CDMA2000® 1xEV-DO Radio Access System - Planning and Implementation Guide (401-
614-101).
Engineering IP Addresses
The needed IP addresses for the RNC components are as follows:
Table 2-1 IP Addresses for RNC Components (R1SR and UNC)

Network Element Name within Number of IP addresses
FMS
AP01 - AP08 8 primary, 8 secondary
TP01 - TP 16 16 primary, 16 secondary (reserved)
Alarm Card AC01 - AC08 8
Ethernet Switch ESA01 -ESB02 2
Router FER01 1
HDRFMS VCVM 1
AMW VCVM 1
All the network elements have an individual IP address and also note that there is an
additional IP address for the HDRFMS VCVM, which may reside on any one of the 8 APs
and there is an additional IP address for the AMW VCVM. All of these IP addresses are
Internal IP addresses. Each RNC belongs to a separate subnet.
Engineering RNC Capacity Limits

The engineering limits provided in the following tables for R1SR and UNC frames are
estimates based on controlled lab environment operations.
............................................................................................................................................................................................................................................................
May 2009
Table 2-2 AP R1SR Signaling Distribution at full capacity

Item Per AP per hour event AP 1&2 AP 3&4 AP 5&6 AP 7&8
rate – R1SR RNC
1 At Session Setup 4200 4800 4900 4900
2 Connect Setup & 84700 113400 133600 133600
Connect Release (Start
& Stop)
3 Session Close 4200 4800 4900 4900
4 Soft Handoff 40300 63600 78700 78700
5 Softer Handoff 40200 63600 78700 78700
6 Session Keep Alive 5300 5700 4900 4900
Request
7 Paging 20100 32400 38800 38800
8 Idle Transfer - Target 24300 27700 26900 26900
9 Idle Transfer - Source 24300 27700 26900 26900
Table 2-3 AP UNC Signaling Distribution at full capacity

Item Per AP per hour Event AP 1&2 AP 3&4 AP 5&6 AP
Rate - UNC RNC 7&8
1 AT Session Setup 8400 9600 9800 9800
2 Connect Setup & Connect 169400 226800 267200 267200
Release (Start&Stop)
3 Session Close 8400 9600 9800 9800
4 Soft Handoff 80600 127200 157400 157400
5 Softer Handoff 80400 127200 157400 157400
6 Session Keep Alive 10600 11400 9800 9800
Request
7 Paging 40200 64800 77600 77600
8 Idle Transfer - Target 48600 55400 53800 53800
9 Idle Transfer - Source 48600 55400 53800 5800
Note: Assumption is that each page results in an average of 30 paged sectors.
............................................................................................................................................................................................................................................................
May 2009
Table 2-4 R1SR with 752i TP Maximum RNC Capacity
Item R1SR Configuration Limits

1 2 3 4
Configura- Configura- Configura- Configura-
tion tion tion tion
Group Groups Groups Groups
1 Maximum Number of 1xEV-DO 34 100 180 260
Carriers (3 sectors)
configurable1
2 Total number of UATI section 80k 160k 240k 320k
with 1G AP
3 Total number of UATI sections 200k 400k 600k 800k
with 2G AP
4 Total number of active sessions 4k 8k 12k 16k
with TP 752i
5 Total number of active sessions 6K 12K 18K 24K
with UTP and 1G AP
6 Total Number of active sessions 8K 16K 24K 32K
with UTP and 2G AP
7 TP 752i RL PPS rate2 12727 25454 38181 50909
8 TP 752i FL PPS rate2 18666 37333 56000 74666
2
9 UTP FL PPS rate 82352 123528 164705 205881
10 TP RL PPS rate 38888 58332 77777 97221
11 Ethernet Switch to MLS 1 Gbps 1 Gbps 1 Gbps 1 Gbps
capacity
Important! An R1SR configuration group is defined as 2 APs and 4 TP690s, 2 PAs

and 4 TP752is, 2 APs and 2 UTPs, or 2 APs and 4 UTPs.
1
Actual supported number of carriers depends on call load and other RNC activity.
2
Assume UTP FL is accelerated
Table 2-5 UNC Maximum RNC Capacity
Item UNC Configuration Limits

1 2 3 4
Configura- Configura- Configura- Configura-
tion tion tion tion
Group Groups Groups Groups
............................................................................................................................................................................................................................................................
May 2009
Item UNC Configuration Limits

1 Maximum number of 1xEV- 50 200 400 600
DO Carriers (3 sectors)
configurable1
3 Total number of UATI 200k 400k 600k 800k
section
6 Total number of active 8K 16K 24K 32K
sessions
9 UTP FL PPS rate2 82352 123528 164705 205881
10 UTP RL PPS rate2 38888 58332 77777 97221
11 Ethernet Switch to MLS 4 Gbps 4 Gbps 4 Gbps 4 Gbps
capacity
Important! A UNC configuration group is defined as 2 APs and 2 UPTPs or 2 APs

and 4 UTPs.
1
Actual supported number of carriers depends on call load and other RNC activity
2
Values are the maximum combined FL and RL PPS rate the TP will support.
............................................................................................................................................................................................................................................................
May 2009
EV-DO RNC Initial Engineering Considerations Affecting Capacity
Considerations Affecting Capacity

............................................................................................................................................................................................................................................................
Cell Assignment Performance Considerations
Geographic Cell AP Mapping

In the geographic mapping approach the system is divided into geographically contiguous
groups of cells. Each group is mapped to a separate AP. The primary purpose of this
approach is to minimize AP CPU load. When soft handoff occurs if the source and target
cells are mapped to different APs then signaling must be relayed between the 2 APs since
the original AP retains control of the session.
In the future as multiple EV-DO carriers per sector are deployed, it is required that all
carriers from one cell be mapped to the same AP.
Non Geographic Cell AP Mapping

One reason to consider non-geographic Cell-AP mapping is to minimize the impact of an
AP failure. Presently, depending upon the type of failure it is estimated that it can take up
to 2 minutes for the system to activate the cells on the backup AP after an AP failure.
During this time, while both active and dormant sessions are preserved without user
interruption, new connection setup will not be processed until failover completes. If the
cells are mapped geographically to APs, connection setup in an area will be affected when
an AP failure occurs. The purpose of non-geographic mapping is to distribute neighboring
cells to separate APs to minimize this coverage gap during the time required to switch to
the backup AP.
When cells are added in the middle of an existing coverage area it should be noted that to
preserve the optimal non-geographic mapping it would be necessary to re-map a large
number of cells. Another important consideration is to ensure that the cells mapped to a
given RNC are geographically contiguous, even when using non-geographic Cell-AP
mapping within an RNC area. If this condition is not met and cells from multiple RNCs
are interspersed then the performance of the system would degrade since the number of
inter-RNC dormant handoffs would increase.
Non-geographic Cell-AP mapping comes with a CPU performance penalty on the APs,
because soft handoff results in separating serving and controlling AP functionality across
multiple APs in virtually all cases. This results in an increase of AP-to-AP messages and
in turn an increase of AP CPU utilization. The impact of this increased hand off rate
should be considered when calculating RNC capacity and can be calculated the
information provided in Table 2-12.
............................................................................................................................................................................................................................................................
May 2009
Summary of AP Assignment Methods

The advantages of the geographic assignment method are:
• Reduction in AP CPU utilization (traffic model dependent)
• Easier to assign and maintain cell-AP mapping
The advantage of non-geographic assignment is:
• Minimized connection setup coverage gap and improved success rate in the event of
AP failure
The selection of the cell mapping approach is a trade-off between system reliability and
capacity. Since the AP failover mechanism and overall system reliability/availability is
continued to be enhanced to minimize system outage, it is recommended that geographic
assignment method is used. This helps to reduce the extra loading on AP CPU and avoid
the complexity of networking configuration and maintenance activities.
Idle Transfer Impact

A13 Idle transfers are one of the biggest issues affecting EVDO capacity. EVDO has a
philosophy of mobiles being "always on". Thus, every EVDO user's RNC location is
updated when crossing RNC boundaries. The net result is a user who is not actively
placing EVDO calls is still using EVDO RNC resources.
Minimizing the A13 affect is tedious and involves moving RNC boundaries. As an
alternative, the RNC grouping feature can be used where RNCs within a group do not
perform A13 idle transfers.
A13 Idle transfers impacts all APs, because the main call processing function (OHM)
controls the transfer. In addition, the lead AP has an extra impact because the A13
transfers from all the OHMs within the RNC are sent to the lead AP, which forwards
(called target A13s) them to the other RNC. This A13 process on the lead AP also receives
A13s and distributes them to OHMS (source idle transfers)
Optional Feature Impact

Optional features or functions, when activated, may introduce performance impact to the
system. These need to be factored into capacity analysis. This section provides an impact
estimate based on the standard traffic model. The actual performance impact depends on
traffic pattern of each individual system. It is strongly recommended that traffic usage is
monitored after system deployment and critical triggers and engineering guidelines are
utilized to engineer the system capacity.
Quality of Service Features (12078 series)

Quality of Service (QOS) will increase CPU utilization in the TP and may reduce RNC
capacity. AP impact is minimal. The exact TP degradation depends on the percentage of
............................................................................................................................................................................................................................................................
May 2009
QOS type calls versus best effort data calls. The maximum degradation is approximately
5% per TP when 100% of the calls are QoS type calls.
Table 2-6 QOS TP Capacity Degradation

% QoS Calls relative to TP Capacity Degradation
Best Effort Data Calls
25% 1.4%
50% 2.8%
75% 4.2%
100% 5.5%
When the QOS feature is enabled for the first time, QOS call penetration will be low and
RNC impact will be negligible. However, over time, the QOS penetration will go up. It is
recommended to monitor both TP and AP CPU critical triggers when the feature is
enabled.
Per Call Measurement Data (12269 series)

Per Call Measurement Data (PCMD) will increase CPU utilization on the APs and a
bigger increase on the lead AP due to its interface with the OMP. The exact increase can
be 10% or higher and is proportional to call volume since every record of a call is stored. It
is recommended to monitor AP CPU critical triggers when the feature is enabled.
Push to Talk (12184 series)

Push to talk (PTT) is a type of QoS call and will impact both APs and TPs. Although the
QoS aspect of PTT will not impact the AP as mentioned in the previous section, the
expected increased in paging levels (due to terminating PTT calls) will have an impact on
AP performance, assuming 50% of PTT calls are terminating calls. Use Table 2-9 to
determine the paging impact on the AP and Table 2-10 to determine PTT impact on the
TP.
Impact of Security features on the EVDO RNC

Security features such as Session Security, firewalls and IPsec can impact RNC
performance. The impact is largely dependant on how the security feature is configured.
For example, a firewall may be configured to inspect every packet, which causes heavy
CPU usage. Another example is IPsec where TCP/IP messages can be configured to
authenticate and encrypt messages. This also places a heavy burden on the CPU. More
details on how to configure security features can be found in the optional feature
document for the specific feature.
............................................................................................................................................................................................................................................................
May 2009
The impact due to security can be huge; in some cases it can cause a 50% or greater
capacity reduction. Since there is a wide variability, it is recommended to monitor your
critical triggers before and after you enable any security feature and if the critical trigger is
exceeded, follow the recommendation of the critical trigger.
Impact of 3GPP2 Model Variations EVDO RNC

Signaling traffic is mainly processed and supported by AP (Application Processor) and
can be characterized by event rate, active users, and dormant users.
............................................................................................................................................................................................................................................................
May 2009
Table 2-7 AP Capacity Variation
Item Event / S M Change in Change in Change in A P

counts to obtain O ccurrence Occurrence %P O
event rate for per Hour per per H our per Consumption
BE, P TT, VoIP CP2140 CP 2500
2 3 4 5
Idle Transfer 7750 15500 1% on serving

1
(Source) AP
Idle Transfer 7750 15500 1% on serving

2
(Target) AP
Idle transfer 47000 94000 1% on A13 on

3
( A13 proces s on Lead A P onl y
lead AP .
Calculated by
sum ming item s
1 and 2 above
for all AP s.)
Ses sion Setup 1000 2000 1% on serving
4
AP
Ses sion Clos e 18600 37200 1% on serving
5
AP
S ession K eep 116800 233600 1% on serving
6
A live Request AP
C onnection 34300 68600 1% on serving

7
S etup AP
C onnection 311500 623000 1% on serving

8
Releas e AP
Paging 11500 23000 1% on serving

9
AP
Soft and Softer 7700 15400 1% on serving

10
H andoff AP
Attempt
Bearer traffic is mainly processed and supported by TP (Traffic Processor) and can be
characterized by forward link packet per second rate, reverse link packet per second rate,
and simultaneous active users. Packet size distribution as a result of application mix can
also impact TP processing efficiency.
............................................................................................................................................................................................................................................................
401-614-331 Alcatel-Lucent - Proprietary 2- 1 1
May 2009
Table 2-8 Other Capacity Impacting Items

Ite m E n a b le d A P + /- P o te n tia l TP P o te n tia l
(Y es/N o ) AP + /- TP
Im p ac t Im p ac t
2 3 4 5 6 7
1 P T T P a ck et N /A +
B u ndlin g
2 S ecu rity - N /A
F ea tu r e s 1
3 R N C G r ou pin g + N /A
4 G eogra ph ic C ell + N /A
A ssig n m e nt
5 N on -G e o gra p hic - N /A
C ell A ssign m e nt
6 Q oS N /A -
7 P er C a ll - N /A
M ea su r e m e nt
D ata
8 BCM C S - -
9 P agin g im pa c ts - N /A
(PT T , V oIP , etc.)
10 O th er I m pa c ts
11 T o tal ( S u m
r o ws 1 – 1 0 )
1
Use 20% if the impact can not be determined, but then follow the procedure de-
scribed in a previous section.
............................................................................................................................................................................................................................................................
May 2009
EV-DO RNC Initial Engineering Initial Engineering Procedures
Initial Engineering Procedures

............................................................................................................................................................................................................................................................
Overview
To begin the Initial Engineering Procedures, enter the data for RNC initial engineering in
the following tables.
Table 2-9 AP Impacting User Behavior

Item ALU Value Your Value
ALU Value Your Value
( event rate ( event rate
per user per per user per
hour) hour)
1 Total Max 320,000 users for 4
Subscribers R1SR & Maximum
of 800,000 users for
UNC
2 REV A BE Connection requests 4.5
3 Data Session setups 0.18
4 Session close 0.18
5 REV A QoS Connection requests 0
6 (VoIP, PTT) Session setups 0
7 Session close 0
8 Total Connection requests
4.5
(sum of rows 2 and 5)
9 Session setups (sum
0.18
of rows 3 and 6)
10 Session close (sum of
0.18
rows 4 and 7)
11 Paging Rate 1.27
12 Idle Transfers source 1.03
13 Idle Transfers target 1.03
14 Other Soft Hand Offs 3.6
15 Softer Hand Offs 1.54
16 Keep Alive 0.2
17 Other Impacts 0
............................................................................................................................................................................................................................................................
May 2009
Table 2-10 TP Impacting User Behavior

Item ALU Your Value
Recommended
Value
1 Total Number of subscribers 320,000 max
( R1SR)
800,000 max
( UNC)
2 Busy Hour Call attempt/subscriber 4.5
3 Best Effort Data bytes per call - FL 105,000
4 Best Effort Data bytes per call - RL 52,500
5 Forward Link Average Packet Size 600
5a Average call hold time 20s
6 Reverse Link Average Packet Size 200
6a Soft handoff Overhead 25%
7 PTT Busy Hour Call
0
attempt/subscriber
8 % origniations 0
9 % terminations 0
10 Typical FL or RL PTT PPS rate 4.5
11 Average call hold time 0
12 VoIP Busy Hour Call

0
attempt/subscriber
13 % origniations 0
14 % terminations 0
15 Typical FL or RL VoIP PPS rate (w/
23.5
silent suppression)
16 Average call hold time 0
17 Total Packet Per Second Rate - FL

18 Total Packet Per Second Rate - RL
To calculate Row 17:

Tot al Pac ket Per Se con d Ra te - F orw ard Lin k
= ( Ite m 1 * ( Ite m 2 * Item 3 / I tem 5
+ I tem 7 * I tem 10 * Item 11
+ I tem 12 * Ite m 1 5 * Ite m 1 6))
/ 3 600
............................................................................................................................................................................................................................................................
May 2009
To calculate Row 18:

To tal Pac ket Pe r Se con d R ate - F orw ard Li nk
= ((It em 1 * (I tem 2 * It em 4 / Ite m 6
+ Item 7 * I tem 10 * I tem 11
+ Item 12 * Ite m 15 * Ite m 1 6))
/ 3600 ))* ( 1 + ite m 6 a)
Capacity Calculations
Initial engineering for the RNC is accomplished by the following steps.
1. Fill in Table 2-9 and Table 2-10.
2. Determine the AP and TP type you want to use. For guidance, discuss wit your
Alcatel-Lucent customer advocate.
3. Determine the number of APs based on signaling
4. Determine the number of APs based on total subscribers
5. Determine the number of APs/TPs based on active subscribers
6. Determine the number of TPs based on packet per second rate
7. From steps 1 - 5, take the maximum number of APs and TPs and determine the RNC
equipage. In some cases, more than 1 RNC would be needed.
Details of Each Steps
Step 1 - Fill in Tables

Fill in Table 2-9.
When filling in this table, information from the previous tables must be considered. In
order to do this, knowledge of how your RNC is going to be used is essential. Although
Alcatel-Lucent recommended values are given, it is strongly encouraged to carefully
examine what is entered - it may result in a system that is over or under engineered. Once
Table 2-9 is filled in, you may proceed.
Fill in Table 2-10.
This table needs to be filled in to determine method for QoS degradation. In order to do
this, knowledge of how your RNC is going to be used is essential. Although Alcatel-
Lucent recommended values are given, it is strongly encouraged to carefully examine
what is entered - it may result in a system that is over or under engineered. Once
Table 2-10 is filled in, you may proceed.
Step 2 - Determine your AP and TP types

For a R1SR frame, your AP choices are a 1 Gigabyte or a 2 Gigabyte CP2140. Your TP
choices are a TP752i or UTP.
For a UNC, your only choice is a CP2500 for the AP and a UTP for the TP.
............................................................................................................................................................................................................................................................
May 2009
Enter these values in Table 2-12, from step 2.
Step 3 - Determine the number of APs based on signaling traffic

The total signaling impact needs to be calculated. First, copy the values from Table 2-9,
column 4 to the appropriate row in column 2 below. Then, copy the appropriate values
from Table 2-2 or Table 2-3, depending on your RNC frame type.
Next, for each item, subtract column 2 from column 3 and enter in column 4. Values can
be negative or positive.
Then, look up this value in Table 2-7, rounding to the next highest value and enter in
column 5. Again, the values can be positive or negative.
Finally, sum all the percentages together. The result should be zero or positive. If not, your
system is over-engineered and you will need to reduce the per subscriber event rates per
RNC.
Once the system is properly engineered, enter the number of APs and TPs in Table 2-12
"from step 3".
............................................................................................................................................................................................................................................................
May 2009
Table 2-11 Worksheet for calculating AP signaling impact

Item Your Multiply Values Deviation %PO deviation
Values column 2 from table (subtract from capacity limit
(from values by 2-2 or 2-3 column 2 (use column 4 data
table 2- the total from column and look up value
10, number of 3 in table 2-8,
column subscribers rounding to the
4) in table 2- next highest
10 percentage
1 2 3 4 5 6
1 Connection
requests
2 Session setups
3 Session close
4 Paging Rate
5 Idle Transfers
source
6 Idle Transfers
target
7 LEAD AP Idle
Transfers (sum
of rows 5 and
6 above, not
found in table
2-10)
8 Soft Hand Offs
9 Softer Hand
Offs
10 Keep Alive
11 Other Impacts
12 OA&M Impact1
13 Total CPU Deviation (add rows 1 through 13)2
1
ALU assumes 10% OA&M impact. If you expect more OA&M impact, enter a positive
number here
2
CPU Deviation must be zero or positive. If CPU deviation is negative, this indicates the
system is over engineered.
Step 4 - Determine the number of APs based on total subscribers

For a R1SR frame, compare your input from Table 2-9, line 1 to Table 2-5 lines 3 or 4 or
Table 2-6, line 4 (depending on your selected AP type) by choosing a value from Table 2-5
or Table 2-6 greater than the number you entered in Table 2-9. Select the appropriate
AP/TP configuration. Enter this number in Table 2-12 in "from step 4".
For a UNC frame, compare your input from Table 2-9, line 1 to Table 2-7, line 3 by
choosing a value from Table 2-7 greater than the number you entered in Table 2-9. Select
the appropriate AP/TP configuration. Enter this number in Table 2-12 in "from step 4".
Step 5 - Determine the number of APs/TPs based on active subscribers

Step 5a
............................................................................................................................................................................................................................................................
May 2009
First, you need to determine the number of erlangs needed based on your connection rate.
To do this, use the formula:
Erlangs/subscriber = (Busy Hour Call attempt/subscriber* hold time)/3600
To find the erlangs for each call type, use the following from Table 2-10:
• line 2 and line 5a for REV A best effort data
• line 7 and line 11 for PTT
• line 12 and line 16 for VoIP
Sum these 3 erlang values to determine the total number of erlangs/subscriber.
To determine the total erlangs needed for the entire RNC use the following equation;
Total Erlangs (active users) = Erlangs/subscriber * Total Number of Subscribers (row 1
Table 2-8)
Step 5b
For an R1SR RNC, first determine the TP type you want. Then, using the total erlang
value from step 5a, compare to Table 2-5 or Table 2-6 (depending on TP type) line 5 by
choosing a value greater than the sum of the erlang numbers. Once you find that value,
find the heading value for the same column and this will tell you how many APs and TPs
you will need. Enter this number in Table 2-12 "from step 5".
For an UNC RNC use these total erlang value from step 4a and compare to Table 2-7 line
4 by choosing a value greater than the sum of the erlang numbers. Once you find that
value, find the heading value for the same column and this will tell you how many APs and
TPs you will need. Enter this number in Table 2-12 "from step 5".
Step 6 - Determine the number of TPs based on packet per second rate and/or
throughput
For a R1SR frame, compare the value needed from Table 2-10 row 17 to the values in
Table 2-5 or Table 2-6 row 6 (depending on your TP type). Choose a PPS rate greater than
your need, the heading value in that column will be the number of APs and TPs needed.
Enter these values in Table 2-12, "from step 6- FL".
Then, compare the value needed from Table 2-10 row 18 to the values in Table 2-5 or
Table 2-6, rows 7 (depending on your TP type). Choose a PPS rate greater than your need,
the heading value in that column will be the number of APs and TPs needed. Enter these
values in Table 2-12, "from step 6 - RL"
For a UNC frame, compare the value needed from Table 2-10 row 17 to the values in
Table 2-5, row 5. Choose a PPS rate greater than your need, the heading value in that
column will be the number of APs and TPs needed. Enter these values in Table 2-12,
"from step 6 - FL".
............................................................................................................................................................................................................................................................
May 2009
Then, compare the value needed from Table 2-10 row 18 to the values in Table 2-7, row 6.
Choose a PPS rate greater than your need, the heading value in that column wil be the
number of APs and TPs needed. Enter these values in Table 2-12, "from step 6 - RL".
Step 7 - Determine the number of APs and TPs

Take the maximum number of APs and TPs from each column and enter these values in
the "from step 7 - Total". This will be your RNC configuration.
Table 2-12 RNC Configuration
Step AP TP
HW Type HW Type
From step 2
Number of APs Number of TPs
From step 3
From step 4
From step 5
From step 6 - FL
From step 6 - RL
From step 7 - Total
Determine the number of carriers a RNC can support

The factors determining the number of carriers a RNC can support are total throughput
load of all carriers and total signaling load of all carriers.
a. The throughput the RNC can support in the forward link can be determined by
multiplying Table 2-10 rows 5 and 17. The throughput the RNC can support in the
reverse link can be determined by multiplying Table 2-10 rows 6 and 18. This
value should needs to be less than the sum of the throughput of all connected
carriers.
b. Similarly, the signaling load of all carriers has to less than the values in Table 2-9
row 14.
The total number of carriers supported is the smaller value of what was calculated.
............................................................................................................................................................................................................................................................
May 2009
............................................................................................................................................................................................................................................................
May 2009
3 EV-DO BTS Initial Engineering
BTS Initial Engineering

............................................................................................................................................................................................................................................................
BTS Initial Engineering Overview

Initial engineering is a method to initially equip a system based on parameters from the
market need or using standard defined values. The intent of initial engineering is to get a
system up and running that will be close to the projected need (i.e., it does not provide a
procedure that will strictly fulfill all the performance targets). Immediately after the
system is up and running, growth engineering procedures should be executed to correct
deficiencies in initial engineering.
The general principles of initial engineering are:
1. Determine user behavior
2. Determine BTS needs
3. Determine Backhaul needs
This is a hierarchical approach starting at the air interface and moving up the network.
EV-DO User Behavior Initial Engineering Outline
Traffic Model
User behavior in a telecommunication network is normally described by traffic models. A
traffic model contains a set of parameters which characterize the dynamics of all activities
generated by end users. These activities can be categorized into subscriber loading and
subscriber usage model.
General Volume Loading

The subscriber loading specifies how many users are in the system.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering BTS Initial Engineering
Table 3-1 Subscriber Loading

ITEM VALUE Notes
Average number of Customer to provide value Assuming the total number
subscribers per sector of cells/sectors in the
considered market has been
determined. (e.g., by RF
design consideration).
Rev. A subscriber Customer to provide value Percentages of subscribers
percentage (%) using Rev. A mobiles.
Reverse link transmitting Customer to provide value or Average number of
users use Alcatel-Lucent simultaneously transmitting
recommended value of 8 users on the reverse link.
Subscriber Usage Model (high level)

In this context, the Service Provider creates the estimated subscriber bearer traffic usage
without using detailed connection/session level statistics assumptions and application
level traffic model.
............................................................................................................................................................................................................................................................
May 2009
Table 3-2 Service Provider Inputs on Data Usage Profile

ITEM VALUE Notes
Sub sc riber M o nthly Customer to pro vide E stimate d mo nthly da ta usage
Data Usage (M bytes) value per subscriber.
Co unted Days per Customer to pro vide Num ber of d ays in a month
M o nth value that the subscrib er will use the
netwo rk.
BH Traffic Ratio Customer to pro vide Pe rcentage of the b usy hour

value traffic am ong the daily traffic.
If m ultiple busy h ours a re
expected, the value is divided
by the num ber of b usy hour s
per da y.
BH Ac tivity R atio Customer to pro vide Possib ility of a subscriber
value bein g active in a busy h our.
BH Ac tive Subscr iber Customer to pro vide Num ber of d ata sessions per
Data Sessio n Cou nt value or use Alc atel- bu sy hour generated by an
Lucent r ec omm ended active subscr ibe r.
value of 1
FL to RL Load Ra tio Customer to pro vide Ratio of forwar d to reverse
value or use Alc atel- link sector da ta lo ad.
Lucent r ec omm ended
value of 5
Subscriber Usage Model (Detailed)

The detailed subscriber usage model defines, for instance, what applications the subscriber
is using and how often the subscriber uses the service. Application traffic is composed of
multiple applications aggregated together to simulate a subscriber's experience. This
model covers most of the typical data applications with different traffic intensities and will
provide the average forward and reverse link packet size distribution. Table 3-3, “Data
Application Traffic Model (Alcatel-Lucent recommended values)” (p. 3-4) contains
assumptions made on application characteristics and usage mix.
............................................................................................................................................................................................................................................................
May 2009
Table 3-3 Data Application Traffic Model (Alcatel-Lucent recommended values)
Small
Application File File Web Near RT
Email Transaction
Category Downloading Uploading Browsing Streaming
(see Note 1)
Data Call
10% 20% 10% 20% 0% 40%
Percentage
Packet-Call 10
2000 (FL) 200 (RL) 54 (FL) 2400 (FL) 0.52 (FL)
size (kbyte) (FL)
Forward
200
Link Packet 1270 (FL) 1270 (RL) 1270 (FL) 400 (FL) 200 (FL)
(FL)
Size (Bytes)
FL to RL
20:1 1:10 10:1 5:1 >100:1 1:1
Traffic Ratio
Reading
180 180 40 60 N/A 5.5
Time (sec)
Number of
Packet-Calls
1 1 20 10 1 2
per Data
Session
Note 1: Small transactions include applications such as ATM/credit card transactions,

telemetry, short message service, etc.
Note 2: The overall forward to reverse link traffic ratio can be written as:
FL
Avg _ Data _ Session _ Size
FL _ RL _ Ratio = RL
Avg _ Data _ Session _ Size
where:
Avg _ Data _ Session _ Size FL / RL =
∑ Data _ Percentage * Packet _ Call _ Size

FL / RL
i i
* Packet _ Calls _ in _ Sessioni
i∈ Data _ App
with
Packet _ Call _ SizeiRL = Packet _ Call _ SizeiFL / FL _ to _ RL _ Ratioi
............................................................................................................................................................................................................................................................
May 2009
Data Traffic Load Procedures

The following procedures are used to determine the data traffic load per sector based on
the previous tables.
Procedure 3-1, “Determining Sector Data Traffic Load Based on Data Usage Profile”
(p. 6) utilizes the data usage profile information (such as subscriber monthly usage.
Procedure 3-2, “Determining Sector Data Traffic Load Based on Data Application Traffic
Model” (p. 10) uses the data application traffic model information (such as FTP, web
browsing, e-mail, etc.). Only one procedure is needed for BTS initial engineering,
depending on the type of information available to the Service Provider.
Important! These procedures assume that Rel. 0 and Rev. A users shared the same
set of values in Table 3-2, “Service Provider Inputs on Data Usage Profile” (p. 3-3)
and Table 3-3, “Data Application Traffic Model (Alcatel-Lucent recommended
values)” (p. 3-4). Separate sets of values can be used for Rel. 0 and Rev. A users, if
needed.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-1: Determining Sector Data Traffic Load
Based on Data Usage Profile
Procedure 3-1: Determining Sector Data Traffic Load Based on Data

Usage Profile
............................................................................................................................................................................................................................................................
Purpose
This procedure determines the average offered data traffic load in each sector using data
usage profile.
........................................................................................................................................................................................................................
1 As previously determined (Table 3-1, “Subscriber Loading” (p. 3-2)), the average number
of subscribers per sector.
Given: Subscribers_per_Sector = 2000

........................................................................................................................................................................................................................
2 As previously determined (Table 3-1, “Subscriber Loading” (p. 3-2)), the Rev. A
subscriber percentage.
Given: RevA_Percentage = 60%

........................................................................................................................................................................................................................
3 Calculate the Rel. 0 subscriber percentage as

Re l 0 _ Percentage = 100% − Re vA _ Percentage
Rel. 0 Percentage = 100% - 60% = 40%

........................................................................................................................................................................................................................
4 As previously determined (Table 3-2, “Service Provider Inputs on Data Usage Profile”
(p. 3-3)), the BH Activity Ratio.
Given: BH_Activity = 30%

........................................................................................................................................................................................................................
5 Calculate the number of Rel. 0 subscribers (per sector) that are active during a busy hour
as
BH _ Active _ Subscribers0 = Subscribers _ per _ Sector * Re v0 _ Percentage * BH _ Activity
BH_Active_Subscribers0 = 2000*0.4*0.3 = 240
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
6 Calculate the number of Rev. A subscribers (per sector) that are active during a busy hour
as
BH _ Active _ Subscribers A = Subscribers _ per _ Sector * Re vA _ Percentage * BH _ Activity
BH_Active_SubscribersA = 2000*0.6*0.3 = 360

........................................................................................................................................................................................................................
(p. 3-3)), the Subscriber Monthly Data Usage (Mbytes).
Given: Monthly_Data_Usage = 35.8 Mbytes

........................................................................................................................................................................................................................
(p. 3-3)), the Counted Days per Month.
Given: Days_In_Month = 30
........................................................................................................................................................................................................................
(p. 3-3)), the BH Traffic Ratio.
Note: The BH Traffic Ratio is typically between 8 to 15%.

Given: BH_Traffic_Ratio = 10%
........................................................................................................................................................................................................................
(p. 3-3)), the FL to RL Load Ratio
Given: FL_to_RL_Load_Ratio = 5.1
Important! We adjusted the default value provided in Table 3-2, “Service Provider
Inputs on Data Usage Profile” (p. 3-3) slightly (from 5 to 5.1) in this example to be in
line with the Table 3-3, “Data Application Traffic Model (Alcatel-Lucent
recommended values)” (p. 3-4). Please refer to Note 3 under Table 3-3.
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
11 Calculate the busy hour active subscriber throughput on the forward link as
FL _ to _ RL _ Load _ Ratio
BH _ Subscriber _ Throughput _ FL = *
FL _ to _ RL _ Load _ Ratio + 1
Monthly _ Data _ Usage * 8000 * BH _ Traffic _ Ratio

Days _ In _ Month * BH _ Activity * 3600
5.1 35.8 * 8000 * 10%

BH_Subscriber_Throughput_FL = * = 0.739 kbps
5.1 + 1 30 * 30% * 3600
........................................................................................................................................................................................................................
12 Calculate the busy hour active subscriber throughput on the reverse link as
BH _ Subscriber _ Throughput _ FL
BH _ Subscriber _ Throughput _ RL =
FL _ to _ RL _ Load _ Ratio
0.739
BH_Subscriber_Throughput_RL = = 0.145 kbps
5.1
........................................................................................................................................................................................................................
13 Calculate the forward link busy hour data load per sector from Rel. 0 subscribers as
Data _ Load 0 _ FL = BH _ Active _ Subscribers0 * BH _ Subscriber _ Throughput _ FL
Data_Load0_FL = 240 * 0.739 = 177.4 kbps

........................................................................................................................................................................................................................
14 Calculate the forward link busy hour data load per sector from Rev. A subscribers as
Data _ Load A _ FL = BH _ Active _ Subscribers A * BH _ Subscriber _ Throughput _ FL
Data_LoadA_FL = 360 * 0.739 = 266.0 kbps
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
15 Calculate the reverse link busy hour data load per sector from Rel. 0 subscribers as
Data _ Load 0 _ RL = BH _ Active _ Subscribers0 * BH _ Subscriber _ Throughput _ RL
Data_Load0_RL = 240 * 0.145 = 34.8 kbps

........................................................................................................................................................................................................................
16 Calculate the reverse link busy hour data load per sector from Rev. A subscribers as
Data _ Load A _ RL = BH _ Active _ Subscribers A * BH _ Subscriber _ Throughput _ RL
Data_LoadA_RL = 360 * 0.145 = 52.2 kbps

END OF STEPS
........................................................................................................................................................
............................................................................................................................................................................................................................................................
May 2009
Based on Data Application Traffic Model
Procedure 3-2: Determining Sector Data Traffic Load Based on Data

Application Traffic Model
............................................................................................................................................................................................................................................................
Purpose
This procedure determines the average offered data traffic load in each sector using data
application traffic model.
........................................................................................................................................................................................................................
1 As previously determined (Table 3-3, “Data Application Traffic Model (Alcatel-Lucent

recommended values)” (p. 3-4)), the Percentage for each data application i.
Given:
Data_Percentage (File Downloading) = 10%
Data_Percentage (File Uploading) = 20%
Data_Percentage (Web Browsing) = 10%
Data_Percentage (Email) = 20%
Data_Percentage (Near RT Streaming) = 0%
Data_Percentage (Small Transaction) = 40%
........................................................................................................................................................................................................................

recommended values)” (p. 3-4)), the forward link Packet Call Size for each data
application i.
Given:
Packet_Call_Size (File Downloading - FL) = 2000 kbytes
Packet_Call_Size (File Uploading - RL) = 200 kbytes
Packet_Call_Size (Web Browsing - FL) = 54 kbytes
Packet_Call_Size (Email - FL) = 10 kbytes
Packet_Call_Size (Near RT Streaming - FL) = 2400 kbytes
Packet_Call_Size (Small Transaction - FL) = 0.52 kbytes
........................................................................................................................................................................................................................

recommended values)” (p. 3-4)), the Number of Packet-Calls per Data Session for each
data application i.
Given:
Packet_Calls_in Session (File Downloading) = 1
Packet_Calls_in_Session (File Uploading) = 1
............................................................................................................................................................................................................................................................
May 2009
Packet_Calls_in_Session (Web Browsing) = 20

Packet_Calls_in_Session (Email) = 10
Packet_Calls_in_Session (Near RT Streaming) = 1
Packet_Call_Size (Small Transaction) = 2
........................................................................................................................................................................................................................
4 As previously determined (Table 3-2), the BH Active Subscriber Data Session Count.
Given: Active_Subscriber_Data_Sessions = 1
........................................................................................................................................................................................................................

recommended values)” (p. 3-4)), the Forward to Reverse Link Traffic Ratio for each data
application i.
Given:
FL_to_RL_Ratio (File Downloading) = 20
FL_to_RL_Ratio (File Uploading) = 0.1
FL_to_RL_Ratio (Web Browsing) = 10
FL_to_RL_Ratio (Email) = 5
FL_to_RL_Ratio (Near RT Streaming) = 100
FL_to_RL_Ratio (Small Transaction) = 1
........................................................................................................................................................................................................................
6 Calculate the busy hour active subscriber throughput on the forward link as
BH _ Subscriber _ Throughput _ FL = Active _ Subscriber _ Data _ Sessions *

Packet _ Call _ Sizei * 8 * Packet _ Calls _ in _ Sessioni
∑
i∈Data _ App
Data _ Percentagei
3600
Note: For file uploading, we assume Packet_Call_Size(FL) = Packet_Call_Size(RL)*

FL_to_RL_Ratio.
BH_Subscriber_Throughput_FL = 1 * [ 2000 * 1 * 10 % + ( 200 * 0 . 1) * 1 * 20 % + 54 * 20 * 10 %
8
+ 10 * 10 * 20% + 2400 * 1 * 0% + 0. 52 * 2 * 40%] * = 0.739 kbps
3600
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
7 Calculate the busy hour active subscriber throughput on the reverse link as
BH _ Subscriber _ Throughput _ RL = Active _ Subscriber _ Data _ Sessions *

Packet _ Call _ Sizei * 8 * Packet _ Calls _ in _ Sessioni
∑
i∈Data _ App
Data _ Percentagei
FL _ to _ RL _ Traffic _ Ratio i * 3600
Note: For file uploading, we assume Packet_Call_Size(FL) = Packet_Call_Size(RL)*

FL_to_RL_Ratio.
2000 54
BH_Subscriber_Throughput_RL = 1 * [ * 1 * 10 % + 200 * 1 * 20% + * 20 * 10%
20 10
10 2400 8
+ * 10 * 20 % + * 1 * 0% + 0. 52 * 2 * 40%] * = 0.145 kbps
5 100 3600
........................................................................................................................................................................................................................
8 As previously determined (Procedure 3-1, “Determining Sector Data Traffic Load Based
on Data Usage Profile” (p. 3-6)), the number of Rel. 0 subscribers (per sector) that are
active during a busy hour (BH_Active_Subscribers0).
Given:
Subscribers_per_Sector = 2000
Rel.0_Percentage = 40%
BH_Activity = 30%
BH_Active_Subscribers0 = 2000*0.4*0.3 = 240
........................................................................................................................................................................................................................
9 As previously determined (Procedure 3-1, “Determining Sector Data Traffic Load Based
on Data Usage Profile” (p. 3-6)), the number of Rev. A subscribers (per sector) that are
active during a busy hour (BH_Active_SubscribersA).
Given:
Subscribers_per_Sector = 2000
RevA_Percentage = 60%
BH_Activity = 30%
BH_Active_SubscribersA = 2000*0.6*0.3 = 360
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
10 Calculate the forward link busy hour data load per sector from Rel. 0 subscribers as
Data _ Load 0 _ FL = BH _ Active _ Subscribers0 * BH _ Subscriber _ Throughput _ FL
Data_Load0_FL = 240 * 0.739 = 177.4 kbps

........................................................................................................................................................................................................................
11 Calculate the forward link busy hour data load per sector from Rev. A subscribers as
Data _ Load A _ FL = BH _ Active _ Subscribers A * BH _ Subscriber _ Throughput _ FL
Data_LoadA_FL = 360 * 0.739 = 266.0 kbps
........................................................................................................................................................................................................................
12 Calculate the reverse link busy hour data load per sector from Rel. 0 subscribers as
Data _ Load 0 _ RL = BH _ Active _ Subscribers0 * BH _ Subscriber _ Throughput _ RL
Data_Load0_RL = 240 * 0.145 = 34.8 kbps

........................................................................................................................................................................................................................
13 Calculate the reverse link busy hour data load per sector from Rev. A subscribers as
Data _ Load A _ RL = BH _ Active _ Subscribers A * BH _ Subscriber _ Throughput _ RL
Data_LoadA_RL = 360 * 0.145 = 52.2 kbps
END OF STEPS
........................................................................................................................................................
Subscriber Usage Model (QoS)

In the planning practice, it is regarded that a QoS subscriber is also a general packet data
subscriber, hence the addition of QoS applications do not impact the general packet data
traffic modeling, rather the QoS traffic is added into the network on top of the data traffic.
............................................................................................................................................................................................................................................................
May 2009
Table 3-4 Service Provider Inputs on QoS Usage Profile
VALUE
ITEM Push to Talk Voice over IP Video Telephony
(PTT) (VoIP) (VT)
QoS Application Penetration Customer to Customer to Customer to
of Rev. A subscribers (%) provide value provide value provide value
Busy Hour Call Attempt Customer to Customer to Customer to
(BHCA) per QoS subscriber provide value provide value provide value
Customer to Customer to
Customer to
provide value provide value or
provide value or
or use ALU use ALU
Call Holding Time use ALU
recommended recommended
recommended
value of 30 value of 110
value of 110 seconds
seconds seconds
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-3: Determining Sector QoS Traffic Load
Procedure 3-3: Determining Sector QoS Traffic Load

............................................................................................................................................................................................................................................................
Purpose
This procedure determines the average offered QoS traffic load in each sector.
........................................................................................................................................................................................................................
1 As previously determined (Table 3-1, “Subscriber Loading” (p. 3-2)), the average number
of subscribers per sector.
Given: Subscribers_per_Sector = 100

........................................................................................................................................................................................................................
2 As previously determined (Table 3-1, “Subscriber Loading” (p. 3-2)), the Rev. A
subscriber percentage.
Given: RevA_Percentage = 60%

........................................................................................................................................................................................................................
3 As previously determined (Table 3-4, “Service Provider Inputs on QoS Usage Profile”
(p. 3-14)), the QoS Application Penetration of Rev. A subscribers for each QoS service
type j.
Given:
QoS_Penetration (PTT) = 30%
QoS_Penetration (VT-24) = 3%
........................................................................................................................................................................................................................
4 Calculate the number of subscribers (per sector) that use QoS services for each QoS
service type j as
QoS _ Subscribers j = Subscribers _ per _ Sector * Re vA _ Percentage * QoS _ Peneration j
QoS_Subscriber (PTT) = 2000*0.6*0.3 = 360

QoS_Subscriber (VT-24) = 2000*0.6*0.03 = 36
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
(p. 3-14)), the Busy Hour Call Attempt (BHCA) per QoS subscriber for each QoS service
type j.
Given:
BHCA_per_QoS_Subscriber (PTT) = 1
BHCA_per_QoS_Subscriber (VT-24) = 1
........................................................................................................................................................................................................................
6 Calculate the Busy Hour Call Attempt (BHCA) per Sector for each QoS service type j as
BHCA _ per _ Sector j = QoS _ Subscriber j * BHCA _ per _ QoS _ Subscriberj
Given:
BHCA_per_Sector (PTT) = 360*1 = 360
BHCA_per_Sector (VT-24) = 36*1 = 36
........................................................................................................................................................................................................................
(p. 3-14)), the Call Holding Time for each QoS service type j.
Given:
Call_Holding_Time (PTT) = 30 seconds
Call_Holding_Time (VT-24) = 110 seconds
........................................................................................................................................................................................................................
8 Calculate the offered Erlang load per sector for each QoS service type j as
BHCA _ per _ Sectorj * Call _ Holding _ Time j
Erlang _ Load j =
3600
Erlang_Load (PTT) = 360*30/3600 = 3
Erlang_Load (VT-24) = 36*110/3600 = 1.1
........................................................................................................................................................................................................................
9 Calculate the primary busy hour QoS Erlang load per sector as
QoS _ Erlang _ Load = ∑ Erlang _ Load
j∈QoS _ App
j
QoS_Erlang_Load = 3+1.1 = 4.1
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
10 10.Calculate the percentage of QoS traffic in Erlang for each service type j out of the total
QoS traffic in Erlang as
Erlang _ Load j
Erlang _ Percentage j =
QoS _ Erlang _ Load
Erlang_Percentage (PTT) = 3/4.1 = 73.2%

Erlang_Percentage (VT-24) = 1.1/4.1= 26.8%
END OF STEPS
........................................................................................................................................................
Number of EV-DO Base Stations and Carriers
Estimating Base Stations and Carriers

For initial engineering, the number of BTSs should be determined by the RF coverage
needs. Once this is determined, the procedure below will determine the number of carriers
needed in each BTS.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-4: Determining Number of Carriers (without
QoS)
Procedure 3-4: Determining Number of Carriers (without QoS)

............................................................................................................................................................................................................................................................
Purpose
The purpose of this procedure is to determine the number of carriers needed in each BTS.
........................................................................................................................................................................................................................
1 As previously determined, the forward link busy hour data load per sector from Rel. 0
users (Data_Load0_FL).
Given: Data_Load0_FL = 177.4 kbps

........................................................................................................................................................................................................................
2 As previously determined, the reverse link busy hour data load per sector from Rev. A
users (Data_LoadA_FL).
Given: Data_LoadA_FL = 266.0 kbps

........................................................................................................................................................................................................................
3 The number of carriers needed on the forward link can be determined as

⎡ Data _ Load 0 _ FL Data _ Load A _ FL ⎤
N Carrier _ FL = ⎢ + ⎥
⎢ RF _ Throughput 0 _ FL RF _ Throughput A _ FL ⎥ ROUNDUP
where the values for RF_Throughput0_FL and RF_ThroughputA_FL are listed below.
Table 3-5 Target of Forward Link Sector-Carrier RF Throughput
Engineering Target of FL Sector-Carrier

RF Throughput
Single AT Receiving Dual AT Receiving

Antenna Antenna
Rel. 0 600 kbps 850 kbps
Rev. A 700 kbps 1000 kbps
The engineering target throughput presented above is approximately 20% lower than the
full air interface throughput.
............................................................................................................................................................................................................................................................
May 2009
QoS)
If both single and dual receiving antenna data ATs are present in the market, the forward
link RF throughput per sector-carrier can be estimated as follows:
RF_Throughput0_FL = a0 * RF_ Throughput0_1Rx
+ (1-a0) * RF_ Throughput0_2Rx
RF_ ThroughputA_FL = a A * RF_ ThroughputA_1Rx
+ (1-a A) * RF_ ThroughputA_2Rx
Where a0 is the percentage of single-Rx antenna AT out of all Rel. 0 mobiles, and aA is the
percentage of single-Rx antenna AT out of all Rev. A mobiles.
Given: RF_Throughput 0_FL = 850 kbps; RF_Throughput A_FL = 1000 kbps
⎡177.4 266. 0 ⎤
N Carrier _ FL = ⎢ + =1
⎢ 850 1000 ⎥⎥ ROUNDUP
........................................................................................................................................................................................................................
4 As previously determined, the reverse link busy hour data load per sector from Rel. 0 users
(Data_Load0_RL).
Given: Data_Load0_RL = 34.8 kbps

........................................................................................................................................................................................................................
users (Data_LoadA_RL).
Given: Data_LoadA_RL = 52.2 kbps

........................................................................................................................................................................................................................
6 As previously determined (Table 3-1, “Subscriber Loading” (p. 3-2)), the reverse link
transmitting users.
Given: reverse link transmitting users = 8
............................................................................................................................................................................................................................................................
May 2009
QoS)
........................................................................................................................................................................................................................
7 Calculate the number of carriers needed on the reverse link as

⎡ Data _ Load 0 _ RL Data _ Load A _ RL ⎤
N Carrier _ RL = ⎢ + ⎥
⎢ RF _ Throughput 0 _ RL RF _ Throughput A _ RL ⎥ ROUNDUP
where the values for RF_Throughput_RL are listed below as a function of reverse link
transmitting users.
Reverse Link RF Throughput (RLP Layer Payload)
Reverse Link Engineering Target of RL Sector-
Transmitting Users Carrier RF Throughput (kbps)
Rel.0 Rev.A
2 125 280
4 160 400
6 175 390
8 190 370
10 200 340
12 200 300
14 185 280
16 155 260
18 125 240
Giv en: RF_Throug hput 0_RL = 190 kbps; RF_Throug hput A_FL = 370 kbps
⎡ 34. 8 52. 2 ⎤
N Carrier _ RL = ⎢ + =1
⎢ 190 370 ⎥⎥ ROUNDUP
........................................................................................................................................................................................................................
8 Calculate the number of carriers as

N Carrier = max{N Carrier _ FL, N Carrier _ RL}
NCarrier = max{1,1} = 1
END OF STEPS
........................................................................................................................................................
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-5: Determining Number of Carriers (with
QoS)
Procedure 3-5: Determining Number of Carriers (with QoS)

............................................................................................................................................................................................................................................................
Purpose
The purpose of this procedure is to determine the number of carriers needed in each BTS
in the presence of QoS traffic.
........................................................................................................................................................................................................................
users (Data_Load0_FL).

........................................................................................................................................................................................................................
users (Data_LoadA_FL).

........................................................................................................................................................................................................................
3 As previously determined, the offered Erlang load per sector for each QoS service type j
(Erlang_Loadj).
Given:
Erlang_Load (PTT) = 3
Erlang_Load (VT-24) = 1.1
........................................................................................................................................................................................................................
4 Calculate the effective forward link QoS RF loading level as follows
∑ Erlang _ Load
j∈QoS _ App
j * rj * c j
QoS _ Loading _ FL =
RF _ Throughput A _ FL
where RF_ ThroughputA_FL is given in Table 2-7; the values for rj (QoS service data
rate) and cj (transmission cost per kbps of QoS service data rate) are listed below
............................................................................................................................................................................................................................................................
May 2009
QoS)
........................................................................................................................................................................................................................
5 Forward Link QoS Loading Parameters

QoS Application j Service data rate at FL Transmission
PPP layer (kbps) rj Cost cj
PTT 4 4.5
VoIP 5 5.0
VT - 24kbps 40 2.0
VT - 40kbps 56 2.0
VT - 48kbps 60 2.0
VT - 64kbps 80 2.0
Given:
Service Data Rate (PTT) = 4; FL Transmission Cost (PTT) = 4.5
Service Data Rate (VT-24) = 40; FL Transmission Cost (VT-24) = 2.0
RF_ ThroughputA_FL = 1000 kbps
3 * 4 * 4.5 + 1.1 * 40 * 2.0

QoS_Loading_FL = = 0.142
1000
........................................................................................................................................................................................................................
6 Calculate the number of carriers required on the forward link as follows

⎡ Data _ Load 0 _ FL Data _ Load A _ FL ⎤
N Carriers _ FL = ⎢ + + QoS _ Loading _ FL ⎥
⎢ RF _ Throughput 0 _ FL RF _ Throughput A _ FL ⎥ ROUNDUP
where RF_ Throughput0_FL and RF_ ThroughputA_FL are given in Table 3-5;
Given: RF_Throughput 0_FL = 850 kbps; RF_Throughput A_FL = 1000 kbps
⎡177.4 266. 0 ⎤
N Carrier _ FL = ⎢ + + 0 .142 ⎥ =1
⎢ 850 1000 ⎥ ROUNDUP
........................................................................................................................................................................................................................
7 As previously determined, the reverse link busy hour data load per sector from Rel. 0 users
(Data_Load0_RL).
............................................................................................................................................................................................................................................................
May 2009
QoS)

........................................................................................................................................................................................................................
users (Data_LoadA_RL).

........................................................................................................................................................................................................................
9 Calculate the reverse link QoS RF loading level as

Erlang _ Load j
QoS _ Loading _ RL = ∑
j∈QoS _ App QoS _ RF _ Capacity j
where QoS_RF_Capacityj (primary Erlang) is given in the following table.
Table 3-6 RF Capacity for QoS Services

QoS Application j QoS RF Erlang Capacity
(per Sector-Carrier)
PTT 35
VoIP 35
VT- 24kbps 10
VT- 40kbps 7
VT- 48kbps 6
VT- 64kbps 5
Given:
QoS_RF_Capacity (PTT) = 35
QoS_RF_Capacity (VT-24) = 10
3 1.1
QoS_Loading_RL = + = 0.196
35 10
........................................................................................................................................................................................................................
10 As previously determined (Table 2-1), the reverse link transmitting users.
............................................................................................................................................................................................................................................................
May 2009
QoS)
........................................................................................................................................................................................................................
11 Calculate the number of carriers required on the reverse link as follows

⎡ Data _ Load 0 _ RL Data _ Load A _ RL ⎤
N Carriers _ RL = ⎢ + + QoS _ Loading _ RL ⎥
⎢ RF _ Throughput 0 _ RL RF _ Throughput A _ RL ⎥ ROUNDUP
where RF_ Throughput0_RL and RF_ ThroughputA_RL are given in Table .
Given: RF_Throughput 0_RL = 190 kbps; RF_Throughput A_RL = 370 kbps
⎡ 34.8 52.2 ⎤
N Carrier _ RL = ⎢ + + 0. 196⎥ =1
⎢ 190 370 ⎥ ROUNDUP
........................................................................................................................................................................................................................
12 Calculate the number of carriers as follows:

N Carrier = max{N Carrier _ FL, N Carrier _ RL}
NCarrier = max{1,1} = 1
s out of all data connections.
END OF STEPS
........................................................................................................................................................
Backhaul Facilities Determination

EVDO BTS supports both T1/E1 and Ethernet backhaul facilities. The backhaul employs
the transport protocol of UDP/IP/HDLC for the user traffic on T1/E1 backhaul or
UDP/IP/Ethernet for the user traffic on Ethernet backhaul.
Although the line speed of the Ethernet BH link is 100 Mbps, the true Ethernet backhaul
capacity is determined by how much bandwidth has been configured for the BTS across
the end-to-end Ethernet transport network. In case of the leased Ethernet transport
bandwidth, it is determined by the Service Level Agreement (SLA) service attributes. The
bandwidth profiles used in Metro Ethernet Network (MEN) include:
• Committed Information Rate (CIR)
• Committed Burst Size (CBS)
• Excessive Information Rate (EIR)
• Excessive Burst Size (EBS)
The backhaul per unit physical bandwidth (T1/E1/CIR_1M) is summarized in the table
below.
............................................................................................................................................................................................................................................................
May 2009
QoS)
Table 3-7 Backhaul Unit Physical Bandwidth

Backhaul Physical
T1 E1 CIR_1M
Bandwidth (Mbps)
BT 1 / E1 / CIR _ 1M 1.536 1.92 1
This section determines the number of T1/E1s required or the amount of leased Ethernet
bandwidth (CIR) based on the projected traffic loading. The backhaul facility capacity
estimation on the forward link is described in the following:
• For T1/E1 backhaul, R T 1 _ FL = 1 . 1Mbps and R E 1 _ FL = 1 .4 Mbps RLP

throughput for both Rel.0 and Rev. A system s.
• For Ethernet backhaul, the engineering target of transport efficiency is 70%.
That is, a 1 Mbps Ethernet CIR is able to carry R CIR _ 1 M _ FL = 0 .7 Mbps RLP
throughput for both Rel. 0 and R ev. A system s.
The forward link backhaul RLP throughput per unit bandwidth (T1/E1/CIR_1M) is
summarized in the table below.
Table 3-8 RLP Throughput per Unit Backhaul Bandwidth

Backhaul RLP
T1 E1 CIR_1M
Throughput (Mbps)
RT1 / E1 / CIR _ 1M _ FL 1.1 1.4 0.7
The reverse link backhaul capacity varies with the number of simultaneously transmitting
users, the RF loading of different applications, and data users' RF conditions. As an
engineering guideline, the backhaul facility transmission overhead OH on the reverse link
is estimated as follows:
OH = p + q max{Nˆ Tx _ User _ RL,30}
where
N Tx _ User _ RL
Nˆ Tx _ User _ RL =
QoS _ Loading _ RL
1−
N Carrier
is the equivalent number of simultaneously data transmitting users per sector-carrier on the
reverse link, in the presence of QoS traffics, as if the entire carrier only has general packet
data traffic, while is the average number of simultaneously data transmitting users on the
reverse link (Table 3-1, “Subscriber Loading” (p. 3-2)). QoS_Loading_RL is the QoS RF
............................................................................................................................................................................................................................................................
May 2009
QoS)
loading level (as determined in Procedure 3-3, “Determining Sector QoS Traffic Load”
(p. 3-15)); NCarrier is the number of RF carriers (as determined in Procedure 3-5,
“Determining Number of Carriers (with QoS)” (p. 3-21)). The values for p and q are listed
in the table below.
Table 3-9 Reverse Link Backhaul Overhead

Reverse Link w/o RMI Header w/ RMI Header
Backhaul Compression Compression
Overhead
Parameters p (%) q (%) p (%) q (%)
DS1 Rel. 0 24 2.8 13 2.8
Rev. A 18 3.4 8 3.4
Ethernet Rel. 0 32 2.8 23 2.8
Rev. A 26 3.4 17 3.4
Backhaul Facilities Determination without QoS Traffic

Backhaul can be dimensioned to support base station average throughput target.
Supporting full air interface throughput capacity will provide best possible user
performance, but backhaul resources may not be efficiently utilized. On the other hand, if
full air interface throughput is not supported, the backhaul becomes the limiting resource
instead of the air link. In Tables 2-14 and 2-15, the supportable average throughput relative
to average full air interface throughputs per carrier (termed carrier loading herein) for
different backhaul configurations are presented. Using these two tables, the required
number of T1/E1 facilities can be determined based on Service Provider's base station
throughput target.
The following two tables show the effective average forward link carrier throughput (or
carrier loading) with different T1/E1 backhaul configurations for a single carrier cell.
............................................................................................................................................................................................................................................................
May 2009
QoS)
Table 3-10 T1 Backhaul Configuration and Supported Carrier Loading for One
Carrier Cell
T1 Backhaul S ystem 1 T1 2 T1 3 T1 4 T1
Single Rx Rel. 0 360kbps/sector 675kbps/sector 750kbps/sector 750kbps/sector

Antenna (50% carrier (90% carrier (100% carrier (100% carrier
loading) loading) loading) loading)
Rev. A 360kbps/sector 700kbps/sector 850kbps/sector 850kbps/sector

(40% carrier (80% carrier (100% carrier (100% carrier
Dual Rx Rel. 0 365kbps/sector 700kbps/sector 980kbps/sector 1000kbps/sector


Table 3-11 E1 Backhaul Configuration and Supported Carrier Loading for One
Carrier Cell
E1 Backhaul System 1E1 2E1 3E1 4E1
Single Rx Rel. 0 450kbps/sector 700kbps/sector 750kbps/sector 750kbps/sector


Dual Rx Rel. 0 460kbps/sector 850kbps/sector 1000kbps/sector 1000kbps/sector


Important! The 100% carrier loading level corresponds to full air interface
throughput. The full air interface throughput is approximately 20% higher than the
engineering target throughput presented in Table 3-5.
............................................................................................................................................................................................................................................................
May 2009
QoS)
For reference, the table below lists the number of T1/E1 links or leased Ethernet
bandwidth needed per RF carrier to support the engineering target throughput given in
Table 3-5, assuming the best effort data traffic is forward link limited, using the following
formula:
RF _ Throughput0, A _ FL
N Backhaul = N Sector * (1 + α ) *
RT 1/ E1/ CIR _1M _ FL
where NSector = 3 is the number of sector per cell; alpha is a margin factor to account for
the burstiness of data traffic beyond the average data throughput over the backhaul. The
default value for engineering is 10%.
Table 3-12 Reference Backhaul Links/Bandwidth to Support Forward Link

Engineering Target Throughput
Backhaul Links Per Carrier T1 E1 CIR_1M
Rel. 0 1.80 1.41 2.83
Single Rx Antenna Rev. A 2.10 1.65 3.30
Rel. 0 2.55 2.00 4.01
Dual Rx Antenna Rev. A 3.00 2.36 4.71
URC and URC II currently support up to 4 T1/E1s for EVDO; up to 8 T1/E1s will be
supported in the future. For a lightly loaded BTS, especially for initial deployment, it is
feasible to configure the backhaul bandwidth less than the reference value.
The following procedure can be used to determine the number of backhaul unit bandwidth
(T1/E1/CIR_1M) to support Service Provider's projected traffic load.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-6: Determining Backhaul Facilities (without
QoS)
Procedure 3-6: Determining Backhaul Facilities (without QoS)

............................................................................................................................................................................................................................................................
Purpose
This procedure determines the required backhaul bandwidth in each BTS in the absence of
QoS traffic.
........................................................................................................................................................................................................................
subscribers (Data_Load0_FL).

........................................................................................................................................................................................................................
2 As previously determined, the forward link busy hour data load per sector from Rev. A
subscribers (Data_LoadA_FL).

........................................................................................................................................................................................................................
3 Calculate the effective forward link backhaul data load for the best effort traffic as
Data _ Load Backhaul _ FL = N Sector (1 + α )(Data _ load 0 _ FL + Data _ Load A _ FL )
where NSector is the number of sectors per cell; alpha is a margin factor to account for the
burstiness of data traffic beyond the average data throughput over the backhaul. The
default value for engineering is 10%.
Given: NSector = 3
Data_LoadBackhaul_FL = 3*(1+0.1)*(177.4+266.0) = 1463 kbps
........................................................................................................................................................................................................................
4 Calculate the number of backhaul unit bandwidth (T1/E1/CIR_1M) required on the

forward link as
⎡ Data _ Load Backhaul _ FL ⎤
N Backhaul _ FL = ⎢ ⎥
⎢ RT 1/ E1/ CIR _1M _ FL ⎥
where
RT 1/ E1/ CIR _1M _ FL
............................................................................................................................................................................................................................................................
May 2009
QoS)
is given in Table 3-8.
Given: RT1_FL = 1100 kbps
⎡1463 ⎤
NBackhaul_FL = ⎢ = 2 T1
1100 ⎥ ⎢ ⎥ ROUNDUP
........................................................................................................................................................................................................................
5 As previously determined, the reverse link busy hour data load per sector from Rel. 0
subscribers (Data_Load0_RL).

........................................................................................................................................................................................................................
subscribers (Data_LoadA_RL).

........................................................................................................................................................................................................................
transmitting users.

........................................................................................................................................................................................................................
8 Calculate the reverse link backhaul overhead for Rel. 0 traffic as

OH 0 = p0 + q0 min{N Tx _ User _ RL,30}
where the values of p0 and q0 are listed in Table 3-9, “Reverse Link Backhaul Overhead”
(p. 3-26) from the Rel. 0 rows.
Note: Assume RMI Header Compression is used.
Given: p0 = 13%, q0 = 2.8%

OH0 = 0.13 + 0.028*min{8,30} = 0.354
............................................................................................................................................................................................................................................................
May 2009
QoS)
........................................................................................................................................................................................................................
9 Calculate the reverse link backhaul overhead for Rev. A traffic as

OH A = p A + q A min{N Tx _ User _ RL,30}
where the values of pA and qA are listed in Table 3-9, “Reverse Link Backhaul Overhead”
(p. 3-26) from the Rev. A rows.

Given: pA = 8%, qA = 3.4%
OHA = 0.08 + 0.034*min{8,30} = 0.352
........................................................................................................................................................................................................................
10 Calculate the effective reverse link backhaul data load for the best effort traffic (including
backhaul overhead) as
Data _ Load Backhaul _ RL = N Sector (1 + SHOBackhaul )(1 + α )
[Data _ Load 0 _ RL(1 + OH 0 ) + Data _ Load A _ RL(1 + OH A )]
where SHOBackhaul (with a default of 30%) represents the backhaul traffic generated by the
soft-handoff connections. Note that SHOBackhaul is lower than the air interface soft-handoff
connection overhead SHOAirlink (which is default to be 40%). For EVDO, only the
successfully decoded reverse packets are sent over the backhaul. The actual backhaul
traffic overhead is less than the soft-handoff overhead.
Given: SHO = 30%

Data_LoadBackhaul_RL = 3*(1+0.3)*(1+0.1)*[34.8*(1+0.354)+52.2*(1+0.352)] = 504.9
kbps
........................................................................................................................................................................................................................
11 Calculate the number of backhaul unit bandwidth (T1/E1/CIR_1M) required on the

reverse link as
⎡ Data _ Load Backhaul _ RL ⎤
N Backhaul _ RL = ⎢ ⎥
⎢ BT 1/ E1/ CIR _1M ⎥ RIOUNDUP
where B is given in Table 3-7, “Backhaul Unit Physical Bandwidth” (p. 3-25).
............................................................................................................................................................................................................................................................
May 2009
QoS)
Given: BT1 = 1536 kbps

⎡ 504.9 ⎤
NBackhaul_RL = ⎢ = 1 T1
⎢ 1536 ⎥⎥ ROUNDUP
........................................................................................................................................................................................................................
12 Calculate the required number of backhaul unit bandwidth (T1/E1/CIR_1M) as

N Backhaul = max{N Backhaul _ FL, N Backhaul _ RL}
NBackhaul = max{2,1} = 2 T1
END OF STEPS
........................................................................................................................................................
Backhaul Facilities Determination with QoS Traffic

The backhaul capacities (in unit of call legs) for different QoS applications are listed in
Table 2-17. Due to the difference of backhaul payload formats in the forward and reverse
directions, the backhaul call capacities are different. In the forward direction (from RNC
to BTS), the backhaul carries the application packets. In the reverse direction (from BTS
to RNC), the backhaul carries the over-the-air packets with varying packet sizes,
depending on the RF condition of the AT.
Table 3-13 Backhaul Capacity (Call Legs) of QoS Applications

QoS Application VoIP PTT VT VT
24 kbps 40, 48, 64 kbps
T1 FL 86 245 31 TBD
RL 85 145 22 TBD
E1 FL 115 320 40 TBD
RL 113 205 30 TBD
Ethernet FL 45 133 20 TBD
(per Mbps CIR)
CIR<3Mbps RL 45 85 13 TBD
Ethernet FL 48 141 21 TBD
(per Mbps CIR)
CIR>=3Mbps RL 48 90 14 TBD
The backhaul bandwidth required in the unit of T1/E1/CIR_1M can be estimated using the
following procedure.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-7: Determining Backhaul Facilities (with QoS)
Procedure 3-7: Determining Backhaul Facilities (with QoS)

............................................................................................................................................................................................................................................................
Purpose
This procedure determines the required backhaul bandwidth needed in each BTS in the
presence of QoS traffics.
........................................................................................................................................................................................................................
subscribers (Data_Load0_FL).

........................................................................................................................................................................................................................
2 As previously determined, the forward link busy hour data load per sector from Rev. A
subscribers (Data_LoadA_FL).

........................................................................................................................................................................................................................
3 As previously determined, the offered Erlang load per sector for each QoS service type j
(Erlang_Loadj).
Given:
Erlang_Load (PTT) = 3
Erlang_Load (VoIP) = 0
Erlang_Load (VT-24) = 1.1
........................................................................................................................................................................................................................
4 As previously determined, the primary busy hour QoS Erlang load per sector
(QoS_Erlang_Load).
Given: QoS_Erlang_Load = 4.1

........................................................................................................................................................................................................................
5 As previously determined, the percentage of QoS traffic in Erlang for each service type j
out of the total QoS traffic in Erlang (Erlang_Percentagej)
Given:
Erlang_Percentage (PTT) = 73.2%
............................................................................................................................................................................................................................................................
May 2009
Erlang_Percentage (VoIP) = 0%
Erlang_Percentage (VT-24) = 26.8%
........................................................................................................................................................................................................................
6 Calculate the forward link backhaul effective call leg capacity per unit backhaul
bandwidth (T1/E1/CIR_1M) in the presence of mixed QoS services as
−1
~ ⎛ Erlang _ Percentage j ⎞
CCall _ Leg _ FL = ⎜ ∑ ⎟
⎜ j∈QoS _ App C _ FL ⎟
⎝ j ⎠
where forward link is given in Table 3-13.
Given: C_FL (PTT) = 245, C_FL (VT-24) = 31

~ 1
C Call _ Leg _ FL = = 85.9
0.732 0.268
+
245 31
........................................................................................................................................................................................................................
7 Calculate the number of call legs that needs to be supported on the backhaul based on the
QoS blocking target on the forward link as
N Call _ Leg _ FL = ErlangB −1 ( N Sector * QoS _ Erlang _ Load , BLK _ QoS )
where NSector is the number of sectors per cell; BLK_QoS is the aggregate blocking target
of QoS services. The recommended backhaul blocking target is 1%.
Given BLK_QoS = 1%, NSector = 3

From Erlang B table,
NCall_Leg_FL = ErlangB-1(3*4.1, 1%)= 21
........................................................................................................................................................................................................................
8 Calculate the effective forward link backhaul data load for the best effort traffic as
Data _ Load Backhaul _ FL = N Sector (1 + α )(Data _ load 0 _ FL + Data _ Load A _ FL)
where alpha is a margin factor to account for the burstiness of data traffic beyond the
average data throughput over the backhaul. The default value is 10%.
Data_LoadBackhaul_FL = 3*(1+0.1)*(177.4+266.0) = 1463 kbps
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
9 Calculate the required backhaul bandwidth (in the unit of T1/E1/CIR_1M) on the forward
link as
⎡ Data _ Load Backhaul _ FL N Call _ Leg _ FL ⎤
N Backhaul _ FL = ⎢ + ~ ⎥
⎢ RT 1/ E1/ CIR _1M _ FL CCall _ Leg _ FL ⎥
Given: R T1_FL = 1100 kbps
⎡1463 21 ⎤
N Backhaul_FL = ⎢ + ⎥ = 2 T1
⎢1100 85 .9 ⎥ ROUNDUP
........................................................................................................................................................................................................................
10 As previously determined, the reverse link busy hour data load per sector from Rel. 0
subscribers (Data_Load0_RL).

........................................................................................................................................................................................................................
subscribers (Data_LoadA_RL).

........................................................................................................................................................................................................................
12 Calculate the reverse link backhaul effective call leg capacity per unit backhaul bandwidth
(T1/E1/CIR_1M) in the presence of mixed QoS services as
−1
~ ⎛ Erlang _ Percentage j ⎞
CCall _ Leg _ RL = ⎜ ∑ ⎟
⎜ j∈QoS _ App C _ RL ⎟
⎝ j ⎠
where Cj_RL is given in Table 3-13.
Given: C_RL (PTT) = 145, C_RL (VT-24) = 22

~ 1
C Call _ Leg _ RL = = 58.0
0.732 0.268
+
145 22
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
13 Calculate the number of call legs that needs to be supported backhaul based on the QoS
blocking target on the reverse link as
N Call _ Leg _ RL = (1 + SHOBackhaul ) N Call _ Leg _ FL
where SHOBackhaul (with a default of 30%) represents the backhaul traffic generated by the
soft-handoff connections. Note that SHOBackhaul is lower than the air interface soft-handoff
connection overhead SHOAirlink (which is default to be 40%). The reason is that, for
EVDO, only the successfully decoded reverse packets are sent over the backhaul.
Therefore, the actual backhaul traffic overhead is less than the soft-handoff overhead.
Given: SHOBackhaul = 30%

NCall_Leg_RL = (1+0.3)*21 = 27.3
........................................................................................................................................................................................................................
14 As previously determined, the reverse link QoS RF Loading (QoS_Loading_RL).
Given: QoS_Loading_RL = 0.196

........................................................................................................................................................................................................................
transmitting users.

........................................................................................................................................................................................................................
16 As previously determined (Procedure 3-5, “Determining Number of Carriers (with QoS)”

(p. 3-21)), the number of carriers (NCarrier).
Given: NCarrier = 1
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
17 Calculate the equivalent reverse link transmitting users as

N Tx _ User _ RL
Nˆ Tx _ User _ RL =
QoS _ Loading _ RL
1−
N Carrier
8
Nˆ Tx _ User _ RL = = 9.95
0.196
1−
1
........................................................................................................................................................................................................................
18 Calculate the reverse link backhaul overhead for Rel. 0 traffic as
OH 0 = p0 + q0 min{Nˆ Tx _ User _ RL,30}
where the values of p0 and q0 are listed in Table 3-9 from the Rel. 0 rows.

Given: p0 = 13%, q0 = 2.8%
OH0 = 0.13 + 0.028*min{9.95,30} = 0.409
........................................................................................................................................................................................................................
19 Calculate the reverse link backhaul overhead for Rev. A traffic as

OH A = p A + q A max{Nˆ Tx _ User _ RL,30}
where the values of pA and qA are listed in Table 3-9 from the Rev. A rows.

Given: pA = 8%, qA = 3.4%
OHA = 0.08 + 0.034*min{9.95,30} = 0.418
............................................................................................................................................................................................................................................................
May 2009
........................................................................................................................................................................................................................
20 Calculate the effective reverse link backhaul data load for the best effort traffic (including
backhaul overhead) as
Data _ Load Backhaul _ RL = N Sector (1 + SHOBackhaul )(1 + α )
[Data _ Load 0 _ RL(1 + OH 0 ) + Data _ Load A _ RL(1 + OH A )]
Given: SHOBackhaul = 30%

Data_LoadBackhaul_RL = 3*(1+0.3)*(1+0.1)*[34.8*(1+0.409)+52.2*(1+0.418)] = 527.9
kbps
........................................................................................................................................................................................................................
21 Calculate the required backhaul bandwidth (in the unit of T1/E1/CIR_1M) on the reverse
link as
⎡ Data _ Load Backhaul _ RL N Call _ Leg _ RL ⎤
N Backhaul _ RL = ⎢ + ~ ⎥
⎢ BT 1/ E1/ CIR _1M CCall _ Leg _ RL ⎥
ROUNDUP
where B is given in Table 3-7.
Given: B T1 = 1536 kbps
⎡ 527.9 27. 3 ⎤
N Backhaul_RL = ⎢ + ⎥ = 1 T1
⎢ 1536 58. 0 ⎥ ROUNDUP
........................................................................................................................................................................................................................
22 Calculate the required number of backhaul unit bandwidth (T1/E1/CIR_1M) as

N Backhaul = max{N Backhaul _ FL, N Backhaul _ RL}
NBackhaul = max{2,1} = 2 T1
END OF STEPS
........................................................................................................................................................
Calculating Total Offered Load

To calculate the total offered load based on the number and type of carriers grown or
degrown in megabits per second, use:
• 2.05 Mb/s per Rev 0 Carrier
............................................................................................................................................................................................................................................................
May 2009
• 4.4 Mb/s per Rev A Carrier

The number of uplink pairs used is determined based on total calculated offered load.
Table 3-14 Total Calculated Offered Load

Total Calculated Offered Load Uplink Pairs
Up to 2400 Mbs 2
2400 – 5600 Mbs 4
Important! Capacity assumes that all uplinks are load shared in a LAG and that one
link in the pair can be lost with no loss of capacity.
PDN and RAN traffic traverse the links twice and the 2.05 Mb/s and 4.4 Mb/s are roughly
balanced incoming and outgoing on the uplinks as each direction received the combined
total load. 2.05 Mbs for Rev 0 and 4.4 Mbs for Rev A represent the load into the UNC and
also out of the UNC. The calculation assumes approximate overhead symmetry.
Example: 40 Rev 0 and 250 Rev A carriers would be calculated as:
(4 0*2. 05) + (25 0*4. 4) = 1 182 Mbs
Equivalent QoS Unit (EQU) License Engineering

The concept of an EQU license is similar to the 3G1X "channel element", but in the
software domain. It refers to the software functionality that has been developed in the BTS
dedicated to support the QoS traffic. The unit of evaluation is an EVRC VoIP call leg, i.e.,
1 EQU = 1 EVRC VoIP call leg. For other QoS applications, the EQUs needed to support
an application call leg represents the relative RF and BTS resources needed comparing
with those for an EVRC VoIP call leg. The following table shows the EQU requirement
for each QoS application.
Table 3-15 EQU Requirement for QoS Services

QoS Application j EQUs needed for each
BTS call leg ( n EQU _ j )
PTT 1
VoIP 1
VT- 24kbps 2.5
VT- 40kbps 4
VT- 48kbps 5
VT- 64kbps 6.5
Important! If there are multiple carriers equipped in a BTS, the EQU resource is
shared for all the sector carriers.
............................................................................................................................................................................................................................................................
May 2009
EV-DO BTS Initial Engineering Procedure 3-8: Determining Number of Equivalent QoS
Units
Procedure 3-8: Determining Number of Equivalent QoS Units

............................................................................................................................................................................................................................................................
Purpose
This procedure determines the number of EQUs that need to be licensed in each BTS in
the presence of QoS traffic.
........................................................................................................................................................................................................................
1 As previously determined, the primary QoS Erlang load per sector (QoS_Erlang_Load).
Given: QoS_Erlang_Load = 4.1

........................................................................................................................................................................................................................
2 As previously determined (see Procedure 2-3), the percentage of QoS traffic in Erlang for
each service type j out of the total QoS traffic in Erlang (Erlang_Percentagej).
Given:
Erlang_Percentage (PTT) = 73.2%
Erlang_Percentage (VT) = 26.8%
........................................................................................................................................................................................................................
3 Calculate the effective EQU per call leg in the mixed traffic scenario as
n~EQU = ∑n EQU _ j * Erlang _ Percentage j
j∈Qos _ App
where the first value is found in Table 3-15, and NSector is the number of sector per cell.
Given: nEQU (PTT) = 1, nEQU (VT-24) = 2.5

n~EQU = (1*0.732 + 2.5*0.268) = 1.402
........................................................................................................................................................................................................................
4 Calculate the number of call legs that needs to be supported for an EQU based call
blocking target as
N Call _ Leg _ EQU = (1 + SHO Airlink )
ErlangB −1 ( N Sector * QoS _ Erlang _ Load , BLK _ EQU )
where NSector is the number of sector per cell; BLK_EQU is the call blocking target due
to EQU shortage. The default value is 2%;
............................................................................................................................................................................................................................................................
May 2009
Units
SHOAirlink represents the soft-handoff overhead for the reverse link air interface
connections. For engineering purpose, SHOAirlink = 40% is used.
Given BLK_QoS = 2%, NSector = 3, SHOAirlink = 40%

From Erlang B table, NCall_Leg_EQU = (1+0.4) * ErlangB-1 (3*4.1, 2%) = 1.4*19 = 26.6
........................................................................................................................................................................................................................
5 Calculate the required number of licensed EQUs as

N = N _ EQU * n~ EQU ⎡ Call _ Leg ⎤
EQU ROUNDUP
NEQU = ⎡27 * 1.402⎤ ROUNDUP = 38
END OF STEPS
........................................................................................................................................................
............................................................................................................................................................................................................................................................
May 2009
Units
............................................................................................................................................................................................................................................................
May 2009
4 Base Station OA&M Controller
(BSOC) for Stand Alone EV-DO
(SAEVDO)
Overview
............................................................................................................................................................................................................................................................
The 1xEV-DO Stand Alone Network (SAEVDO) feature provides the same cell site
OA&M services needed by 1xEV-DO as those provided in the current converged cell
OA&M Mobile Switching Center (MSC), while eliminating all unnecessary network
elements. Since the only service provided by this modified MSC will be OAM services for
cell sites, this new product will be called the Base Station OAM Controller (BSOC).
MSC network elements eliminated in the BSOC include:
• Executive Cellular Processor (ECP)
• Interprocessor Message Switch (IMS) token ring
• Digital Cellular Switch (DCS)
• Call processing and Database Node (CDN) complex
• Home and Visitor Location Register (HVLR) complex
• Signaling System 7 (SS7) complex
• Automated Message Accounting (AMA)
Figure 4-1 shows the placement of BSOC components within the 1xEV-DO network and
the connections between the BSOC components and other components of the radio control
network.
............................................................................................................................................................................................................................................................
May 2009
Base Station OA&M Controller (BSOC) for Stand Alone Overview
EV-DO (SAEVDO)
Figure 4-1 BSOC Components in the 1xEV-DO System
Purpose
The purpose of the BSOC architecture is to provide OAM support based on the RCS for
Cell Sites in 1xEV-DO systems for which no call processing service is required.
The BSOC will not provide any call processing service in an SAEVDO system. Instead, it
will provide all of the OAM services the AMPS/PCS MSC provides to subtending cells
that are equipped with only EV-DO carriers. The roles and responsibilities of the BSOC
are:
• Provide a set of platforms upon which the RCS can be run - this set of platforms must
be as highly available as the RCS APs in the AMPS/PCS MSC
• Provide the same set of technician input commands available on the AMPS/PCS MSC
for cell OAM control
• Provide the same set of user display services available on the AMPS/PCS MSC for
cell OAM monitoring and control (not all MSC screens are relevant in the BSOC)
• Provide the same cell configuration management available on the AMPS/PCS MSC
• Provide the same communication management available on the AMPS/PCS MSC for
establishing, maintaining, and using signaling links between the BSOC and each cell
in the network
• Provide an OMP environment that can be shared between its use to support the 1X-
EVDO RNC and its use to support OAM management of BSOC APs and applications
............................................................................................................................................................................................................................................................
May 2009
Base Station OA&M Controller (BSOC) for Stand Alone Overview
EV-DO (SAEVDO)
The following diagram can be used as a reference model to show the implementation of
the BSOC within the network.
Figure 4-2 1xEV-DO Reference Model with BSOC
Engineering
The BSOC RCS AP must support up to 40 RCSs per AP pair. This requires that the system
be equipped with 2GB APs (Host or Satellite).
Use the following procedure to determine the required number of BSOC RCS-AP pairs.
............................................................................................................................................................................................................................................................
May 2009
Base Station OA&M Controller (BSOC) for Stand Alone Procedure 4-1: Determine the number of BSOC RCS-AP
EV-DO (SAEVDO) pairs
Procedure 4-1: Determine the number of BSOC RCS-AP pairs

............................................................................................................................................................................................................................................................
Purpose
Determine the required number of BSOC RCS-AP pairs (#_BSOC_APpairs)
........................................................................................................................................................................................................................
1 Determine the number of cells in the MSC (#_DOcells_MSC)

........................................................................................................................................................................................................................
2 Divide number of cells (#DOcells_MSC) by 40 and round up.
#_BSOC_APpairs = roundup (#_DOcells_MSC / 40)
Example:
Given: 330 cells

#_BSOC_APpairs = (330/40) = 8.25 = 9 RCS-AP pairs
END OF STEPS
........................................................................................................................................................
............................................................................................................................................................................................................................................................
May 2009
5 Growth Engineering, Monitoring
and Critical Triggers
Overview
............................................................................................................................................................................................................................................................
Growth engineering provides a mechanism to determine/predict when a system will run

out of capacity and needs more equipment to meet the capacity needs. The procedure is to
monitor a subset of service measurements, aggregate them in formulas and compare to
system limits. Approaching a limit indicates when growth is required.
Monitoring Service Measurements (SM) provides insights into system performance and
can identify if any of the capacity limitations are being approached. This section will
identify the SM counts that serve as critical triggers for system capacity. For more details
of these SM counts, as well as all SM counts available, please refer to 1xEV-DO Service
Measurements Guide (401-614-326).
Other performance related metrics (i.e. session setup rate, call drop rate, handoff success
rate) may involve broader analysis (e.g. RF planning) than just capacity issues. They can
be found in EV-DO Performance and Capacity Metrics (401-610-013) and will not be
discussed here.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers Procedure 5-1: GER Part 1—Predicting Future BHCA
Procedure 5-1: GER Part 1—Predicting Future BHCA

............................................................................................................................................................................................................................................................
Purpose
This procedure provides a method of predicting future capacity (that is, capacity versus
time). EVDO capacity is characterized by four capacity items:
• AP Processor Occupancy (Proportional to session setup, connection request, idle
transfers paging, hand-offs, OA&M events, etc.)
• Total dormant users
• Total active users
• Throughput
Each of the items above can be predicted using GER Part 1
........................................................................................................................................................................................................................
1 Plot the measured capacity versus time for the period that trigger data is being collected.
Call it the C-t plot.
See Figure 5-1, “GER Plots (Measured C-t)” (p. 5-3).
........................................................................................................................................................................................................................
2 Obtain the projected growth in subscriber base from your marketing organization. Plot this
projected number of subscribers versus time. Call it the S-t plot.
See Figure 5-2, “GER Plots (S-t)” (p. 5-3).
........................................................................................................................................................................................................................
3 Plot the ratio of measured capacity to Subscribers (B/S) versus time. Call it the B/S-t plot.
See Figure 5-3, “GER Plots (C/S -t)” (p. 5-4).
Extrapolate this plot based on its present trend. Be sure to factor in the seasonal and other
market variables which influence the C/S ratio. There may be great fluctuations during the
year, and it is best to design for the highest C/S ratio.
........................................................................................................................................................................................................................
4 From the S-t and the C/S-t plots in Steps 2 and 3, plot the projected capacity versus time.
See Figure 5-4, “GER Plots (Extrapolated B-t)” (p. 5-4).
Important! Compute the "C" value for a point in time "t" by multiplying the value of
"S" at time "t", by the value of "C/S" for that same time "t". Repeat this process for all
............................................................................................................................................................................................................................................................
May 2009
"t" on the time axis. This results in an extrapolation of the C-t plot of Step 1.
See Figure 5-2, “GER Plots (S-t)” (p. 5-3).
END OF STEPS
........................................................................................................................................................
Figure 5-1 GER Plots (Measured C-t)
Measured “C - t” Plot
Capacity
0
1 2 3 4 5 6 7
Time (months)
Figure 5-2 GER Plots (S-t)
“S - t” Plot
Number of
Subscribers
0
1 2 3 4 5 6 7
Time (months)
............................................................................................................................................................................................................................................................
May 2009
Figure 5-3 GER Plots (C/S -t)
“C/S - t” Plot
Capacity/Subs.
Ratio
0
1 2 3 4 5 6 7
Time (months)
Figure 5-4 GER Plots (Extrapolated B-t)
Extrapolated “C - t” Plot
Capacity
0
1 2 3 4 5 6 7
Time (months)
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers Procedure 5-2: GER Part 2—Predicting Date a System
Component Reaches Capacity
Procedure 5-2: GER Part 2—Predicting Date a System Component

Reaches Capacity
............................................................................................................................................................................................................................................................
Purpose
GER Part 2 uses current data to predict at what date a particular system component will
reach its capacity. For each critical trigger, trend the resource versus capacity.
........................................................................................................................................................................................................................
1 For each resource, measure and collect the hourly call counts over a period of time (for
example, 16 weeks). Plot the counts versus time. Call it the TV-C plot.
........................................................................................................................................................................................................................
2 Make a straight-line extrapolation of the TV-C plot. This plot a straight-line extrapolation
is a practical method, because a trigger's threshold marks the point at which a
characteristic of a component begins to function unpredictably. This is because a
component is designed for proper operation in the linear region of its operating
characteristic. In addition to subscribers, other things that impact component functionality
include new features, new releases, and increased use of existing features.
........................................................................................................................................................................................................................
3 From the extrapolated TV-C plot, determine where the threshold value intersects the TV-C
plot to obtain the date when the component runs out of capacity. Figure 5-5, “Trending the
Number of UATI Sessions (TV-C)” (p. 5-5) shows an example of plotting the UATI
Critical Trigger.
END OF STEPS
........................................................................................................................................................
Figure 5-5 Trending the Number of UATI Sessions (TV-C)

# of UATI
Sessions
100,000
65,000
40,000
26,000
Past Now Future Time
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers 1xEV-DO Carrier Growth Engineering Guideline
1xEV-DO Carrier Growth Engineering Guideline

............................................................................................................................................................................................................................................................
The decision to add an additional 1xEV-DO carrier can be triggered by forward link usage
or reverse link usage, or both. If these thresholds are met consistently (i.e., for multiple
hours during multiple days per week over several weeks), it's Alcatel-Lucent's
recommendation to add an additional carrier. There are multiple metrics for forward and
reverse link. The key is to have multiple indicators showing consistent trend. There may
be cases when one metric has exceeded its threshold while other metrics are well below
their thresholds. These cases require detailed analysis and further investigation.
In general, any one of the three metrics can trigger the addition of carriers:
• Criteria 1: Combination of time slot usage and per-user throughput
• Criteria 2: Number of active connections
• Criteria 3: Combination of RSSI rise and number of active connections
Criteria 1: Time Slot Usage and Per-User Throughput
The indicators for forward link loading are time slot usage and per-user throughput (for
BE users only). The corresponding critical trigger for time slot usage is
"EVDO_FL_TS_BUSY_%".
Forward link time slot usage gives the percentage of total physical layer slots used for the
forward link transmission of control and traffic data. On the forward link, time-slot is a
shared RF resource and its usage is one of the primary indicators of forward link carrier
loading. However, a large value for this metric does not necessarily mean congestion on
the air link. A single user doing FTP downloads throughout the hour can drive the time-
slot utilization very high. The end user experience is very important when determining
whether additional RF capacity is needed. This is the reason that per-user throughput is
used as another metric of carrier loading when BE traffic is present. For QoS applications
such as PTT, time slot usage alone is used as the forward link loading.
For cells equipped with DB-EVM and prior to R30, per-user throughput FL (kbps) can be
estimated as:
RLP_TXED_FTC*8/10E3/3600 / (EVM_AVG_ELIG_USER / 10E6)
For cells equipped with DB-EVM and R30 and later, per-user throughput FL (kbps) can be
estimated as:
RLP_TXED_FTC*8/10E3/3600 / (EVM_AVG_ELIG_USER_BE / 10E6)
For R27 and later and cells equipped with SBEVM, it is defined as:
RLP_TXED_FTC*8/10E3/3600 / (EVM_ACTIVE_USAGE / 2160000)
............................................................................................................................................................................................................................................................
May 2009
(EVM_RLP_TXED_FTC_BE + EVM_RLP_TXED_FTC_CPS +
EVM_RLP_TXED_FTC_CS +
EVM_RLP_TXED_FTC_CV + EVM_RLP_TXED_FTC_SMC)*8/10E3/3600 /
(EVM_ACTIVE_USAGE / 2160000)
EVM_RLP_TXED_FTC_BE*8/10E3/3600 / (EVM_ACTIVE_USAGE_BE /
2160000)
Where RLP_TXED_FTC is RLP octets transmitted on forward traffic channel.
EVM_AVG_ELIG_USER (Obsolete in R30): This count records the average number of
active BE users per slot that are eligible to be selected by the scheduler for the
sector/carrier. This count shall be pegged regardless of the scheduler choice. It shall not
include the users that are already in the process of transmission and without data waiting.
This count must be divided by 10E6 to obtain the average number of scheduler eligible BE
users per slot.
EVM_AVG_ELIG_USER_BE (New in R30): This count records the average number of
active BE users per slot that are eligible to be selected by the scheduler for the
sector/carrier. This count shall be pegged regardless of the scheduler choice. It shall not
include the users that are already in the process of transmission and without data waiting.
This count must be divided by 10E6 to obtain the average number of scheduler eligible BE
users per slot.
EVM_RLP_TXED_FTC_BE is RLP Octets Transmitted on the Forward Traffic Channels
for Best Effort.
EVM_RLP_TXED_FTC_CPS is RLP Octets Transmitted on the Forward Traffic
Channels for Push-to-Talk.
EVM_RLP_TXED_FTC_CS is RLP Octets Transmitted on the Forward Traffic Channels
for Conversational Speech.
EVM_RLP_TXED_FTC_CV is RLP Octets Transmitted on the Forward Traffic Channels
for Conversational Video.
EVM_RLP_TXED_FTC_SMC is RLP Octets Transmitted on the Forward Traffic
Channels for Signaling Media Control (QoS signaling excluding Push-to-Talk).
EVM_ACTIVE_USAGE is EVM Active Usage. For each slot (traffic channel or control
channel), this count is incremented by the number of users who have data to send for any
flow (BE, or EF), either waiting to be scheduled or in the process of transmission. This
count is incremented based on the users (not flows) as long as they have data to be served.
This count is only reported for a sector-carrier equipped with an SB-EVM.
............................................................................................................................................................................................................................................................
May 2009
EVM_ACTIVE_USAGE_BE - For each slot (traffic channel or control channel), this

count shall be incremented by the number of Best Effort users who have data to send,
either waiting to be scheduled or in the process of transmission and this count is reported
as the summation of all such users across all slots over the entire SM collection interval. If
a user has multiple packets waiting or in the middle of transmission, this count shall be
incremented by 1 in each transmission and intervening slot for the same user. This count
shall be incremented based on the users (not flows) as long as they have data to be served
regardless of whether the DRC is 0, or there is a DRC erasure, or the cover is not pointing
to sector. Only one sector shall peg each user towards this count. This count is only
reported for a sector-carrier equipped with an SB-EVM.
The performance target for per-user throughput is set by each Service Provider. It depends
on the level of end user experience the Service Provider desires to support. When there are
more users competing for resource, it is expected that the per-user throughput will go
down. It is useful to evaluate such metrics prior to making the decision of adding carriers.
The criteria of adding another carrier based on FL loading is:
EVDO_FL_TS_BUSY_% >= 75
AND
Per-User Throughput <= target set by the Service Provider
Criteria 2: Number of Active Connections

The indicators for reverse link loading are simultaneous active connections and RSSI rise.
Either parameter may require additional carrier if the respective threshold is exceeded.
The corresponding critical trigger for active connections is EVDO_CONN_SEC.
Simultaneous active connection counts represent the total number of active traffic channel
links on a given sector/carrier. It includes both soft and softer handoffs.
This metric is more relevant on the reverse link since each RF connection including soft
and softer links is demodulated at the cell site. On the forward link, a user may get served
only when the user requests data. As a result, the presence of multiple connections does
not have a direct bearing on forward link loading. However, it is logical to expect that as
the number of connections increase, so would the forward link utilization. The exact
relationship is highly dependent on factors such as data application, usage profile, etc., and
may vary from sector to sector or over time for the same sector.
Average and peak connections per sector carrier are defined as:
AvgConn = AVG_ACTIVE_CONN_PER_SECTOR / 360*
PkConn = PEAK_ACTIVE_CONN_PER_SECTOR
............................................................................................................................................................................................................................................................
May 2009
Where PEAK_ACTIVE_CONN_PER_SECTOR is peak number of simultaneous active

Rel. 0 and Rev.A connections per sector-carrier. Every 10 seconds, the number of active
connections are sampled at the sector-carrier level. This count is the maximum of all 10
second samples during the hour.
AVG_ACTIVE_CONN_PER_SECTOR is the sum of multiple simultaneous active Rel.0
and Rev.A connection samples per sector-carrier.
Important! FID-12402.2 in R32 allows SM interval to be 60 or 15 minutes. In cases

where SM interval is different from 60 minutes, replace the value 360 with the # of 10
seconds in the SM interval. For example, if SM interval is 15 minutes, replace 360
with 90.
For additional information see 1xEV-DO Service Measurements Guide (401-614-326).
The criteria for adding carrier based on number of connections is
AvgConn >= AvgThrshld_1
OR
(PkConn >= PkThrshld AND AvgConn >= AvgThrshld_2)
Refer to trigger “EVDO_CONN_SEC” (p. 5-28) for the definitions of thresholds
Criteria 3: RSSI Rise and Number of Active Connections

Another indicator of reverse link loading is RSSI rise. RSSI rise is the rise of the total
CDMA signal above the noise floor and is the primary input for reverse link overload
control. In general, high CDMA loading will cause high RSSI, but the reverse is not true
since this can also be caused by out of system interference. In order to minimize the
impact of external interference to the RSSI rise evaluation, Rev.A system utilizes a new
measurement mechanism to treat the external interference as part of the noise floor. In
addition, the value of RSSI rise also impacts the cell/sector coverage. The effective cell
coverage shrinks as RSSI rise increases. Since a few users can cause high RSSI rise, this
threshold is bounded with the number of connections.
Average long term RSSI rise is defined as
Av gRSS I = SM _EN HANC ED_ AVG _RS SIRI SE / 1 00
Where SM_ENHANCED_AVG_RSSIRISE is average of the RSSI Rise value calculated
using the enhanced algorithm.
For additional information see 1xEV-DO Service Measurements Guide (401-614-326).
The threshold for RSSI rise depends on the setting in the translation (On-chip ROC RAB
Threshold). 6 dB is the recommended value. Alcatel-Lucent recommends the long term
average RSSI rise not exceed 80% of the setting.
The criteria for adding carrier based on RSSI Rise is:
(AvgRSSI >= 80% * Target)
............................................................................................................................................................................................................................................................
May 2009
AND
(AvgConn >= 30)
The decision of when to add another carrier is a complex one. It is important to have
multiple indicators showing a consistent trend. If this is not the case, further investigation
is needed. Please refer to RF Engineering Guideline for 1xEV-DO Systems (401-614-323)
for details, or contact Alcatel-Lucent CTAs for help.
There are other factors that will impact the carrier capacity, such as T1/E1 and EVM board
utilization. Please refer to triggers EVDO_FWD_DL_OCC_%, EVDO_LIU_PO_%,
EVDO_FLM_PO_% and EVDO_RLM_PO_% in the critical trigger section for details.
EV-DO Base Station Critical Triggers Summary

Several Critical Triggers can help to assess system component resource utilization at the
base station level. They are grouped into three categories: CPU Utilization, Backhaul and
Air Interface, and are summarized in the following table.
Table 5-1 EV-DO CPU and Data Link Triggers
C a p a c ity C r itic a l T r ig g e r s D e s c r ip tio n T r ig g e r T h r e s h o ld

P a r a m e te r s
C P U and E V D O _FLM _P O _% FLM or B AP 85%

D a ta lin k p ro c e s s o r o c c u p a n c y
U tiliz a tio n
E V D O _FW D _D L_O C C _% T h e d a ta lin k A v g = 7 5 %, O R

o c c u p a n c y fo r th e
fo r w a r d lin k
P eak = 90%
AN D
Avg = 50%
E V D O _ L IU _ P O % L IU p r o c e s s o r 85%
occupancy
E V D O _R LM _P O _% R LM or B M P 85%
p ro c e s s o r o c c u p a n c y
E V D O _R V S _D L_O C C _% T h e d a ta lin k A v g = 7 5 %, O R
o c c u p a n c y fo r th e
r e v e r s e lin k
P eak = 90% AN D
Avg = 50%
A ir In te r fa c e E V D O _AC C _C H AN _O C C _% A v e ra g e a c c e s s 4 0 % w ith 2 0 %
channel occupancy w a r n in g le v e l
p e r s e c to r c a r r ie r
E V D O _C O N N _S E C A c tiv e c o n n e c tio n s Avg =

A v g T h r s h ld _ 1
O R
(P k = P k T h r s h ld
AN D Avg =
A v g T h r s h ld _ 2 )
E V D O _FL_TS _B U S Y _% A v e r a g e fo r w a r d lin k 75%

tim e s lo t u tiliz a tio n
fo r b o th u s e r a n d
c o n tr o l tr a ffic p e r
s e c to r c a r r ie r
E V D O _FL_TS _C C _% A v e r a g e fo r w a r d lin k 20%

tim e s lo t u tiliz a tio n
fo r c o n tr o l c h a n n e l
............................................................................................................................................................................................................................................................
May 2009
EV-DO RNC Critical Trigger Summary

To monitor SM for the purpose of identifying potential capacity issue with EV-DO RNC,
it is necessary to be familiar with the EV-DO RNC Capacity limits.
The capacity numbers are results from multiple resource limitations (CPU, memory) at
different levels (per RNC, per AP, per TP) and are independent of one another. These
numbers represent maximum capacity. Equipment growth should be considered when any
of the parameters is approached.
Carrier capacity ("Number of EV-DO Carriers") grows non-linearly when the 3rd and 4th
pairs of AP are added. AP1-4 host additional centralized RNC functions (PCF,
DataServer) and less carriers should be allocated to them. AP5-8 are regular APs which
can handle more carriers. Session capacity ("Total Number of Sessions") has per RNC
limit from PCF-A11 function. Session capacity doesn't grow proportionally when AP7
and AP8 are added.
Initial network sizing and capacity planning should follow the engineering guidelines
Initial Engineering section of this chapter.
These recommendations and guidelines are based on a traffic model modified from 3GPP2
1xEV-DV Traffic Model. Actual traffic pattern could vary from one market to another
depending on the billing schedule, demographic composition, life style, or the existence of
certain killer application or services.
Table 5-2 lists critical triggers corresponding to the categories in RNC Capacity found in
Chapter 2, in addition to CPU Utilization counts. The "Threshold Values" column lists the
maximum capacity or worst tolerable condition. It is suggested that trend needs to be
monitored and actions need to be considered once 90% of the "Threshold Values" are or
will soon be achieved.
............................................................................................................................................................................................................................................................
May 2009
Table 5-2 EV-DO RNC Critical Triggers and Warning Levels
Critical
Trigger Recom-
Capacity Warning Threshol mended
Parameters Suggestions on SM monitoring Level d Mitigation
Trigger: EVDO_TP_PO_% 60% 80% Upgrade to
TP processor utilization a 752i TP if 690
TP is currently
TP_UTILIZATION - CPU utilization in %
being used or
upgrade to
UTP or add
more TPs to
frame.
Trigger: EVDO_AP_PO_% 43% when 50% when First, try to
AP processor utilization b no failover no failover balance the
is in place is in place CPU by
AP_AVG_PROC_OCCUPANCY - CPU
redistributing
utilization in %
cells within
AP pair. Then,
add a pair of
APs and the
proper number
of TPs/UTPs
until RNC is
fully equipped,
then add RNC
and
CPU redistribute
Utilization cells
Number of Dependent on base station load
1xEV-DO
Carriers
Throughput can be used for capacity planning but is not recommended to be used as critical
trigger since average aggregate throughput without detailed packet-level characteristics does
not fully represent system loading.
Total A10_OCT_SENT_TO_RLP - forward link byte count

Throughput RLP_OCT_SENT_TO_PCF - reverse link byte count
............................................................................................................................................................................................................................................................
May 2009
Critical
Trigger Recom-
Trigger: EVDO_SESS_OHM 85% of Refer to Enable FID
Total number of UATI sessions per AP d critical Table 2-4, 10607.3 or
trigger “R1SR redistribute
AVE_SESSION_PER_OHM - Average
with 752i high-loading
UATI sessions over one hour, and
TP carriers. Add a
TOTAL_ALLOCATED_SESS_AP - total Maximum pair of APs
UATI sessions over one hour RNC and 4 TPs or 2
Capacity” UTPs until
(p. 2-5), or RNC is fully
Trigger: EVDO_SESS_TP
Table 2-5, equipped, then
Total number of R-P sessions per TPe “UNC add RNC if
Total
TOTAL_ALLOCATED_SESS_TP - total R- Maximum needed.
Number of
P sessions on a TP RNC
Sessions
(Active & Capacity”
Dormant) (p. 2-5)
Trigger: EVDO_CONN_ACT_AP 85% of AVE=80% Add a pair of
Average and peak number of active critical or APs and 4 TPs
connections per APf trigger or 2 UTPs
PEAK=95
until R NC is
AVG_ACTIVE_CONN_PER_AP - average %
fully equipped,
number of active ATs on the AP and
then add RNC
PEAK_ACTIVE_CONN_PER_AP - peak AVE=75%
Number of and
Active number of active ATs on the AP redistribute
Connections cells
............................................................................................................................................................................................................................................................
May 2009
Critical
Trigger Recom-
Trigger: EVDO_RNC_RI_PPS and 85% of See limits Upgrade the
EVDO_RNC_FL_PPS critical in the TP, or
RL/FL Packets Per Second (PPS) per TP trigger respective configure a
sections new RNC.
PEAK_TP_UTILIZATION -.Peak Traffic
Processor Utilization.
TP_UTILIZATION - TP Processor
Utilization.
A10_PKT_SENT_TO_RLP - A10
Packets Sent to RLP.
RLP_PKT_SENT_TO_PCF - RLP
RL/FL Packets Sent to PCF.
packet per
second rates AVG_ACTIVE_AT_COUNT - Average
(PPS) active AT sessions.
a. TP processor utilization is a straightforward way to assess the loading condition on

TP. It is expressed as the percentage of time the CPU is busy processing data. As a
rule of thumb, the processor utilization should be kept below 90%. If any TP is
approaching this limit, actions need to be taken to reduce its workload.
b. AP processor utilization reflects how busy the processor is. With the effort to
preserve most calls and processes during a failover event, AP CPU utilization is
targeted to be at or below 45%.
c. TOTAL_ALLOCATED_SESS_TP is the total sessions allocated on a TP and is
incremented when new sessions are established and decremented when a session is
released. It should be compared to the "Total Number of Sessions" row (item3) in
Table 2-4 “R1SR with 752i TP Maximum RNC Capacity” (p. 2-5), and Table 2-5,
“UNC Maximum RNC Capacity” (p. 2-5).
Please note that the numbers in these tables are the total sessions for all TPs in the
specific configuration and need to be divided by number of TPs to get a "per TP"
threshold.
The max per OHM is 40k assuming FID 10607.3 is enabled and 1GB AP is used.
If 2GB AP is used and FID 9053.2 feature is enabled, the limit goes up to 65k per
OHM. AVG_SESSION_PER_OHM is the average UATI session on the OHM over
the hour. Both counts can be used to monitor against the total UATI session limits.
............................................................................................................................................................................................................................................................
May 2009
d. The percentage is in terms of maximum simultaneous active sessions. In R27, the

maximum active sessions should be 1,000 per TP assuming FID 10607.3 feature is
turned on. If the feature is disabled, the maximum active sessions per TP falls back
to R25 level, i.e. 520.EV-DO
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers Critical Trigger Recipes
Critical Trigger Recipes

............................................................................................................................................................................................................................................................
This section provides critical trigger recipes for the EV-DO network.
By keeping track of and trending these critical triggers and the effect of increased
penetration of features, retrofit, etc., the system operator can prepare in advance for
necessary growth. The CDMA Networks Planning Letter (401-610-094) should also be
consulted when considering future critical triggers.
Format of Critical Trigger Recipes

Critical trigger recipes follow a quick reference, manual page type of format. A recipe
typically contains the following:
TITLE
The critical trigger mnemonic.
TYPE
The kind of resource (Signaling or Traffic)
SYSTEM
The system component to which the critical trigger is associated.
TRIGGER
The trigger and translation of its mnemonic.
DESCR
The trigger definition.
LIMIT VALUE
Detail on the limits placed on component resources.
ENG RULE
Engineering information for that component resource.
MEASUREMENT
Tools to use and fields to look at for critical data.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers Critical Trigger Recipes
ACTION
Action to be taken when approaching the limit value.
A recipe may also include the following:
COMMENTS
Additional helpful information.
EXAMPLE
An illustration of the use of a trigger.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_ACC_CHAN_OCC_%
EVDO_ACC_CHAN_OCC_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Cell Sector Carrier
TYPE
Signaling Resource
TRIGGER
EVDO_ACC_CHAN_OCC_%
Average access channel occupancy per sector carrier
DESCRIPTION
EVDO_ACC_CHAN_OCC_% is at cell sector carrier level and reflects the average access
channel occupancy in percentage. Access channel is used by an access terminal (AT) to
initiate communication with the access network (AN) or to respond to the AT directed
message when AT does not have a traffic channel assigned.
Access cycle duration is the basic time unit of all access channel activities and is
determined by translation parameter "accesscycleduration". It indicates when mobile can
start transmitting a probe and how often base station needs to start a new probe search. The
access cycle duration can only take on the following values: 16, 32, 64, and 128 slots. The
recommended value is 64 slots. The access channel capacity varies with the value of
access cycle duration.
EVDO_ACC_CHAN_OCC_% = 100 * EVM_ACCESS_CHANNEL_SUCC_ATTEMPT
* accesscycleduration * 1.667/(3600*1000)
Note: for DB-EVM, SM count EVM_ACCESS_CHANNEL_SUCC_ATTEMPT for
sector 1 actually contains the sum for all sectors on one carrier, and sector 2 & 3 will have
0 values. As a result, the above formula needs to be divided by the number of sectors and it
represents the average access channel occupancy across all three sectors.
Note: FID-12402.2 in R32 allows SM interval to be 60 or 15 minutes. In cases where SM
interval is different from 60 minutes, replace the value 3600 with the # of seconds in the
SM interval. For example, if SM interval is 15 minutes, replace 3600 with 900.
LIMIT VALUE
40%
............................................................................................................................................................................................................................................................
May 2009
Access channels are contention based. As occupancy increases, collisions of two mobiles
accessing the channel at the same time becomes more common. When occupancy exceeds
20%, it is likely that the impact on system performance caused by access collisions will
become increasingly significant.
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the
EVDO_ACC_CHAN_OCC_% Limit Value.
MEASUREMENT
The HDR performance measurement data is collected hourly from each 1xEV-DO AP and
stored on the OMP under the directory: /omp/omp-data/logs/HCS/sm_summary_files in a
data file <AG_YYYYMMDDHHmmTMZ.HDRFMSXXX> where:
YYYY = 4 digit year
MM = 2 digit month
DD = 2 digit day of month
HH = 2 digit hour of day
mm = 2 digit minute of hour
TMZ = 3 digit time zone indicator (for example, EST)
XXX = 3 digit AP Frame (RNC) number (for example, 021)
EVM_ACCESS_CHANNEL_SUCC_ATTEMPT (new) - This count measures the total
number of successful access probes received from the Access Channel for a sector-carrier
and it can be used to calculate the Access Channel occupancy. This count replaces the
EVM_HAI_ACCESS_CHANNEL_MESSAGE.
Reference: For additional information see 1xEV-DO Service Measurements Guide (401-
614-326).
ACTION
When this trigger is approaching the engineering limit, reduce access cycle duration to
increase the access channel capacity. For DB-EVM, upgrade to SB-EVM.
EXAMPLE
Data from file:
200602171800EST.HCSFMS020
HCS 185
…
SECT 03
CARR 01
............................................................................................................................................................................................................................................................
May 2009
…
EVM_RRI_EMPTY, 0
EVM_ACCESS_CHANNEL_SUCC_ATTEMPT, 31
EVM_AVG_PCNT_SLOTS_BELOW_RMIN, 0
Vallent PROSPECT
• Template Type: IxEV_SectorCarrier
• Template Name: TREND_DO EVDO_ACC_CHAN_OCC_%
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_AP_PO_%
EVDO_AP_PO_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Application Processor
TYPE
Traffic Resource
TRIGGER
EVDO_AP_PO_%
AP average Processor Occupancy (PO) as a percentage
DESCRIPTION
Processor Occupancy (PO) is a measure of the percentage of the CPU being utilized for
call processing for the EV-DO AP.
LIMIT VALUE
50%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_AP_PO_%
Limit Value.
MEASUREMENT
stored on the OMP under the directory: /omp/omp-data/logs/HDR/sm_summary_files in a
YYYY = 4 digit year
MM = 2 digit month
TMZ = 3 digit time zone indicator (for example, EST)
AP_AVG_PROC_OCCUPANCY- Average Processor Occupancy for a AP. This count is
the measure of the percentage of time the processor is busy performing call processing
related tasks. The Average Processor Occupancy shall be calculated at the end of each
hour by averaging all the measurements for the duration of the past hour.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_AP_PO_%
For additional information see 1xEV-DO RNC AP OA&M (401-614-102), or CDMA2000®

1xEV-DO Service Measurements (401-614-326).
ACTION
When the PO reaches the limit value, add a pair of APs and 4 TPs, or 2 UTPs, until the
RNC is fully equipped, and then add a RNC and redistribute the cells.
EXAMPLE
Data from file:
AG_200702231800EST.HDRFMS020
AP 193
AP_AVG_PROC_OCCUPANCY, 20
AP_PEAK_PROC_OCCUPANCY, 44
AP_OVERLOAD_NUM, 0
AP_OVERLOAD_DURATION, 0
AP 195
AP_AVG_PROC_OCCUPANCY, 19
AP_PEAK_PROC_OCCUPANCY, 33
AP_OVERLOAD_NUM, 0
AP_OVERLOAD_DURATION, 0
AP 197
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_CONN_ACT_OHM
EVDO_CONN_ACT_OHM
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Application Processor (AP)
TYPE
Traffic Resource
TRIGGER
EVDO_CONN_ACT_OHM
The active sessions during the hour for the overhead manager (OHM) software process on
an AP
DESCRIPTION
EVDO_CONN_ACT_OHM provides the peak and average active sessions per OHM.
Note: UTPs are installed
LIMIT VALUE
Active Sessions per Configuration Group

R1SR UNC
1G AP 2G AP 2G AP
TP690 4000 4000 N/A
TP752i 4000 4000 N/A
UTP 6000 8000 8000
Note: A configuration group is defined as 2 APs and 4 TP690s, 2 APs and 4 TP752is, 2
APs and 2 UTPs, or 2 APs and 4 UTPs. For each configuration group in your frame, sum
both OHMs in the configuration group and compare to the applicable limit value in the
table.
ENG RULE
EVDO_CONN_ACT_OHM Limit Value.
............................................................................................................................................................................................................................................................
May 2009
MEASUREMENT
The HDR performance measurement data is collected hourly from each 1xEV-DO OHM
and stored on the OMP under the directory: /omp/omp-data/logs/sm_summary_files in a
data file <HDR/YYYYMMDDHHmmTMZ.HDRFMSXXX> where:
YYYY = 4 digit year
MM = 2 digit month
TMZ = 3 digit timezone indicator (for example, EST)
XXX = 3 digit AP frame number
AVG_ACTIVE_CONN_PER_OHM - Average Active Connections per OHM. This count

takes a snapshot of the number of active connections on the OHM where it is being
measured and accumulates the results every 10 seconds. This count represents the value
per quarter hour. This count provides the raw total, not the average. Dividing the result by
the number of 10 second periods in the whole collection period will provide the average
number of connections per OHM.
PEAK_ACTIVE_ CONN_PER_OHM - Peak Active Connections per OHM. This count
takes a snap shot of the number of active connections on the OHM where it is being
measured every 10 seconds. This count is the maximum of active connections per OHM of
all the data collected during the hour.
For additional information see 1xEV-DO RNC AP OA&M (401-614-102), and
CDMA2000® 1xEV-DO Service Measurements (401-614-326).
ACTION
When the total number of connections reaches the limit value, add a APs and 4 UTPs until
the RNC is fully equipped, and then add a RNC and redistribute the cells.
............................................................................................................................................................................................................................................................
May 2009
EXAMPLE
OHM 301
OHM_RESIDENT_AP, 051
OHM_SESS_CAPACITY, 000000
AVG_ACTIVE_CONN_PER_OHM, 0
FAST_CONNECT_FAIL_RL_NOT_ACQ, 0
FAST_CONNECT_FAIL_NO_RSC, 0
FAST_CONNECT_TCA_SENT, 0
FAST_CONNECT_ESTABLISHED_CALLS, 0
PAGE_TRANSMISSION_FAILURE, 0
PEAK_ACTIVE_CONN_PER_OHM, 0
AVG_SESSION_PER_OHM, 0
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_CONN_ACT_TP
EVDO_CONN_ACT_TP
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Traffic Processor (TP)
TYPE
Traffic Resource
TRIGGER
EVDO_CONN_ACT_TP
The active sessions on an TP during the hour
DESCRIPTION
EVDO_CONN_ACT_TP provides the peak active sessions per TP.
LIMIT VALUE
Refer RNC Capacity with 752i TP and RNC Capacity with 690 TP
Table 5-3 Limited Value for Number of Active Sessions
6 APs & 8 APs &

Peak Active 2 APs & 4 TPs 4 APs & 8 TPs or 12 TPs or 16 TPs or
Sessions or 4 UTPs 6 UTPs 8 UTPs 10 UTPs
TP 690 or TP 752i 4000 8000 12000 16000
UTP 12000 18000 24000 30000
ENG RULE
EVDO_CONN_ACT_TP Limit Value.
MEASUREMENT
The HDR performance measurement data is collected hourly from each 1xEV-DO TP and
stored on the OMP under the directory:
/omp/omp-data/logs/HDR/sm_summary_files in a data file
<AG_YYYYMMDDHHmmTMZ.HDRFMSXXX>
where:
YYYY = 4 digit year
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_CONN_ACT_TP
MM = 2 digit month
HH = 2 digit hour of daymm = 2 digit minute of hour
PEAK_ACTIVE_AT_COUNT - Peak Active AT sessions at TP The count reports the
peak number of active AT sessions. The count is based on 15 second scans.
For additional information see 1xEV-DO RNC AP OA&M (401-614-102), and
ACTION
When the total number of connections reaches the limit value, add a APs and 4 TPs until
the RNC is fully equipped, and then add a RNC and redistribute the cells.
EXAMPLE
Data from file:
AG_200702231800EST.HDRFMS020
…
OHM 303
…
TP 307
…
PEAK_TP_UTILIZATION, 11
RAN_AUTH_FAIL_INVALID_MNID_ESN, 0
AVG_ACTIVE_AT_COUNT, 20
PEAK_ACTIVE_AT_COUNT, 29
AVG_DORMANT_AT_COUNT, 7
PEAK_DORMANT_AT_COUNT, 19
…
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_CONN_SEC
EVDO_CONN_SEC
............................................................................................................................................................................................................................................................
SYSTEM
TYPE
Traffic Resource
TRIGGER
EVDO_CONN_SEC
Active connections per sector carrier.
DESCRIPTION
EVDO_CONN_SEC is at the cell sector carrier level and reflects the simultaneous active
connections (Rel.0 and Rev.A) on that sector carrier during the hour. Please note that
active connections include soft handoff legs on the reverse link.
LIMIT VALUE
The limit value is:
AvgConn = AvgThrshld_1
OR
(PkConn = PkThrshld AND AvgConn = AvgThrshld_2)
where
AvgConn = AVG_ACTIVE_CONN_PER_SECTOR/360
PkConn = PEAK_ACTIVE_CONN_PER_SECTOR
The thresholds for simultaneous active connections depend on the mix of Rel.0 and Rev.A
usage. Rev.A usage percentage RevA% is defined as
AVG_ACTIVE _CONN_PER_ SECTOR_REV A

Rev.A usage percentage RevA% =
AVG_ACTIVE _CONN_PER_ SECTOR
Table 5-4 The definitions of different thresholds for Re.0 and Rev.A are listed in
Table 5-5, “Thresholds for Rel.0 and Rev.A Connections” (p. 5-29).
............................................................................................................................................................................................................................................................
May 2009
Table 5-5 Thresholds for Rel.0 and Rev.A Connections
AvgThrshld_1 PkThrshld AvgThrshld _2

Rel.0 30 45 20
Rev.A 60 77 40
Mixed 30*(1-RevA%) + 45*(1-RevA%) + 20*(1-RevA%) +
60*RevA% 77*RevA% 40*RevA%
Note: FID-12402.2 in R32 allows SM interval to be 60 or 15 minutes. In cases where SM

interval is different from 60 minutes, replace the value 360 with the # of 10 seconds in the
SM interval. For example, if SM interval is 15 minutes, replace 360 with 90.
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_CONN_SEC
Limit Value.
MEASUREMENT
The HDR performance measurement data is collected hourly from each EV-DO AP and
data file
<AG_YYYYMMDDHHmmTMZ.HDRFMSXXX>
where:
YYYY = 4 digit year
MM = 2 digit month
The peg counts involved are:
PEAK_ACTIVE_CONN_PER_SECTOR- peak number of simultaneous active Rel.0 and
Rev.A connections per sector-carrier. Every 10 seconds, the number of active connections
are sampled at the sector-carrier level. This count is the maximum of all 10 second
samples during the hour.
AVG_ACTIVE_CONN_PER_SECTOR - sum of simultaneous active Rel.0 and Rev.A
connection samples over the data collection period per sector-carrier. Every 10 seconds,
the number of simultaneous active connections are sampled at the sector-carrier level. This
count is the total of all 10 second samples during the collection period. To get the average
simultaneous active connections, divide this count by the number of samples in the
collection period.
............................................................................................................................................................................................................................................................
May 2009
AVG_ACTIVE_CONN_PER_SECTOR_REVA - sum of simultaneous active Rev A

connection samples over the data collection period per sector-carrier. Every 10 seconds,
the AP scans each sector-carrier to get the active Rev A connections for this sector-carrier
and then accumulates to its previous accumulated value. To get the average simultaneous
active connections, divide this count by the number of samples in the collection period.
614-326).
ACTION
When this trigger is approaching the engineering limit consistently (i.e. for multiple hours
each week day over several weeks), reverse link noise rise needs to be examined. Please
refer to "1xEV-DO Carrier Growth Engineering Guideline" in this document for more
details.
EXAMPLE
Data from file:
AG_200802231800EST.HDRFMS020
…
HCS 001
AVG_BTS_EQU_LICENSE_USAGE, 0
PEAK_BTS_EQU_LICENSE_USAGE, 0
BTS_EQU_LICENSE_STATE, 0
SECT 01
CARR 01
NUM_TIMES_MAX_CONN_REACHED, 0
AVG_ACTIVE_CONN_PER_SECTOR, 170
…
PEAK_ACTIVE_CONN_PER_SECTOR, 3
…
PEAK_ACTIVE_CONN_PER_SECTOR_REVA, 3
AVG_ACTIVE_CONN_PER_SECTOR_REVA, 134
............................................................................................................................................................................................................................................................
May 2009
Vallent PROSPECT
• Template Name: TREND_DO AVG_ACTIVE_USERS_SECT_CARR and
TREND_DO PEAK_ACTIVE_USERS_SECT_CARR
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_FL_TS_BUSY_%
EVDO_FL_TS_BUSY_%
............................................................................................................................................................................................................................................................
SYSTEM
TYPE
Traffic Resource
TRIGGER
EVDO_FL_TS_BUSY_%
Average forward link time slot utilization per sector carrier.
DESCRIPTION
EVDO_FL_TS_BUSY_% is at cell sector carrier level and reflects the percentage of
forward link time slots that are busy for user and control traffic. This trigger is one of the
indicators of forward link RF loading.
EVDO_FL_TS_BUSY_% = EVM_TOTAL_BUSY_PCNT_SLOTS / 10E6 +
(EVM_CC_SLOTS_SYNC_MSG_XMIT + EVM_CC_SLOTS_ASYNC_MSG_XMIT +
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT)*100/2160000
Note: the formula of this trigger is changed in R30 to reflect new SM count names and to
include sub-sync usage.
Note: Please note FID-12402.2 in R32 allows SM interval to be 60 or 15 minutes. In
cases where SM interval is different from 60 minutes, replace the value 216000 with the #
of slots in the SM interval. For example, if SM interval is 15 minutes, replace 2160000
with 540000.
LIMIT VALUE
75%
Important! This trigger is changed in R28 to include control channel usage to better
evaluate cells at RNC borders which are likely to have higher control channel usage
due to idle handoffs. The Limit Value is increased from 70% to 75%.
ENG RULE
EVDO_FL_TS_BUSY_% Limit Value.
............................................................................................................................................................................................................................................................
May 2009
MEASUREMENT
The HCS performance measurement data is collected hourly from each 1xEV-DO AP and
data file <YYYYMMDDHHmmTMZ.HCSFMSXXX> where:
YYYY = 4 digit year
MM = 2 digit month
EVM_TOTAL_BUSY_PCNT_SLOTS - the percentage of busy slots used for user traffic
data transmission. This count must be divided by 10E6 to obtain a value in percent.
EVM_CC_SLOTS_ASYNC_MSG_XMIT - total number of slots used for sending the
asynchronous signaling messages on the Control Channel for a sector-carrier.
EVM_CC_SLOTS_SYNC_MSG_XMIT - total number of slots used for sending the
synchronous signaling messages on the Control Channel for a sector-carrier. This count
shall not include the slots used for sending the sub-synchronous signaling messages.
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT (newly created - R30) - total number of
slots used for sending the sub-synchronous signaling messages on the Control Channel for
a sector-carrier.
614-326).
ACTION
When this trigger is approaching the engineering limit consistently (i.e. for multiple hours
during multiple days per week over several weeks), per-user throughput needs to be
examined. Please refer to "1xEV-DO Carrier Growth Engineering Guideline" in this
document for more details.
EXAMPLE:
Data from file:
200602171800EST.HCSFMS020
HCS 185
…
SECT 03
CARR 01
............................................................................................................................................................................................................................................................
May 2009
…
EVM_CC_SLOTS_ASYNC_MSG_XMIT, 1248
EVM_CC_SLOTS_SYNC_MSG_XMIT, 67544
…
EVM_ACTIVE_USAGE_BE, 2813677
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT, 0
...
EVM_AVG_ELIG_USER_BE, 1212648
EVM_TOTAL_BUSY_PCNT_SLOTS, 27213194
Vallent PROSPECT
• Template Name: TREND_DO EVM_TOTAL_BUSY_PCNT_SLOTS
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_FL_TS_CC_%
EVDO_FL_TS_CC_%
............................................................................................................................................................................................................................................................
SYSTEM
TYPE
Signal Resource
TRIGGER
EVDO_FL_TS_CC_%
Average forward link time slot utilization for control channel per sector carrier.
DESCRIPTION
EVDO_FL_TS_CC_% is at cell sector carrier level and reflects the percentage of forward
link time slots that are used by synchronous and sub-synchronous control channel for
signaling messages.
EVDO_FL_TS_CC_% = (EVM_CC_SLOTS_SYNC_MSG_XMIT +
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT)*100/2160000
Note: Please note FID-12402.2 in R32 allows SM interval to be 60 or 15 minutes. In
cases where SM interval is different from 60 minutes, replace the value 216000 with the #
of slots in the SM interval. For example, if SM interval is 15 minutes, replace 2160000
with 540000.
LIMIT VALUE
20%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_FL_TS_CC_%
Limit Value.
MEASUREMENT
The HCS performance measurement data is collected hourly from each 1xEV-DO AP and
data file <YYYYMMDDHHmmTMZ.HCSFMSXXX> where:
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009

EVM_CC_SLOTS_SYNC_MSG_XMIT (newly created - R30) - total number of slots
used for sending the synchronous signaling messages on the Control Channel for a sector-
carrier. This count does not include the slots used for sending the sub-synchronous
signaling messages.
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT (newly created - R30) - total number of
slots used for sending the sub-synchronous signaling messages on the Control Channel for
a sector-carrier.
614-326).
ACTION
When this trigger is approaching the engineering limit, paging traffic needs to be reduced
by modifying paging strategy and/or deploying the following paging improvement
features:
• Distance-based paging (FID-12184.7)
• PTT Paging Enhancements (FID-12184.1, 12184.5, 12184.7)
EXAMPLE:
Data from file:
200602171800EST.HCSFMS020
HCS 185
…
SECT 03
CARR 01
…
EVM_CC_SLOTS_ASYNC_MSG_XMIT, 1248
EVM_CC_SLOTS_SYNC_MSG_XMIT, 67544
…
EVM_ACTIVE_USAGE_BE, 2813677
EVM_CC_SLOTS_SUBSYNC_MSG_XMIT, 0
...
............................................................................................................................................................................................................................................................
May 2009
EVM_AVG_ELIG_USER_BE, 1212648
EVM_TOTAL_BUSY_PCNT_SLOTS, 27213194
Vallent PROSPECT
• Template Type: 1xEV_SectorCarrier
• Template Name: TREND_DO EVDO_FL_TS_CC_%
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_FLM_PO_%
EVDO_FLM_PO_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Forward Link Modem (FLM/BAP)
TYPE
Traffic Resource
TRIGGER
EVDO_FLM_PO_%
FLM/BAP average Processor Occupancy (PO) as a percentage
DESCRIPTION
call processing for the EV-DO FLM if the modem type is DB-EVM or BAP if the modem
type is SB-EVM.
EVDO_FLM_PO_% = FLM_BAP_AVG_PROC_OCCUPANCY
LIMIT VALUE
85%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_FLM_PO_%
Limit Value.
MEASUREMENT
The HCS performance measurement data is collected hourly from each EV-DO AP and
data file <YYYYMMDDHHmmTMZ.HCSFMSXXX>
where:
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009
FLM_BAP_AVG_PROC_OCCUPANCY - Average Processor Occupancy for FLM/BAP.

"Processor Occupancy" is defined as the measure of the percentage of time the processor
is busy performing call processing related tasks. The system measures the processor
occupancy for FLM of an EVM board or BAP of an SB-EVM board at the end of each 10-
second interval. The 10-second samples are then averaged for the hour. This count is in
unit of percentage. For example, a value of 4 indicates 4% occupancy.
614-326).
ACTION
Upgrade to SB-EVM if the modem type is DB-EVM, or add an additional cell and/or
carrier.
EXAMPLE
Data from file:
200602180500EST.HCSFMS020
…
HCS 119
RELEASE 26.00
VERSION 001
CONTL 002
MCC_ELAPSED_TIME, 3600
LIU_AVG_PROC_OCCUPANCY, 0
...
DATALINK 001
...
EVM001
EVM_TYPE EVM
MODEM_ELAPSED_TIME, 3600
FLM_BAP_AVG_PROC_OCCUPANCY, 4
FLM_PEAK_PROC_OCCUPANCY, 4
FLM_OVERLOAD_NUM, 0
FLM_OVERLOAD_DURATION, 0
…
Vallent PROSPECT
• Template Type: IxEV_EVM
............................................................................................................................................................................................................................................................
May 2009
• Template Name: TREND_DO FLM_OCC
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_FWD_DL_OCC_%
EVDO_FWD_DL_OCC_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Data Link
TYPE
Traffic Resource
TRIGGER
EVDO_FWD_DL_OCC_%
The data link occupancy for the forward link.
DESCRIPTION
EVDO_FWD_DL_OCC_% is the occupancy for a data link in the forward direction.
Please refer to Table 3-7, “Backhaul Unit Physical Bandwidth” (p. 3-25) for backhaul
physical bandwidth for T1, E1 or Ethernet. The datalink occupancy can be computed as
follows:
For T1:
DL _ DOWNLINK _ PEAK _ THRUPUT * 8
Average _ EVDO _ FWD _ DL _ OCC _ % = *100
1000 *1536

PeakEVDO _ FWD _ DL _ OCC _ % = *100
1000 *1536
For E1:
DL _ DOWNLINK _ AVG _ THRUPUT * 8
AverageEVD O _ FWD _ DL _ OCC _ % = *100
1000 *1920

PeakEVDO _ FWD _ DL _ OCC _ % = *100
1000 *1920
For Ethernet:
............................................................................................................................................................................................................................................................
May 2009
The forward link bandwidth (Mbps) available per Ethernet connection

(Ethernet_BW_FWD) can be determined by parameter "Service Level Agreement -
Network Bandwidth (forward)" on RC/V form btseqp/cdmeqp using common OA&M
with 3G-1x.
DL _ DOWNLINK _ AVG _ THRUPUT * 8

Average EVDO _ FWD _ DL _ OCC _ % = * 100
Ethernet _ BW _ FWD * 10 6

Peak EVDO _ FWD _ DL _ OCC _ % = * 100
Ethernet _ BW _ FWD * 10 6
LIMIT VALUE
Average EVDO_FWD_DL_OCC_% = 75%
Or
Peak EVDO_FWD_DL_OCC_% = 90% And Average EVDO_FWD_DL_OCC_% = 50%
ENG RULE
EVDO_FWD_DL_OCC_% Limit Value.
Note: If feature 12304.12 (Support EVDO and 3G1x Traffic on the Same T1 at Lightly
Loaded Cells, R29) is deployed, please monitor 1x SM counts CDMA-SUBCELL/CRC
field 20 (Aggregate Average Downlink Throughput) and CDMA-SUBCELL/CRC field 21
(Aggregate Average Uplink Throughput) which can be found in the CDMA Network
Service Measurements (401-610-135).
MEASUREMENT
where:
YYYY = 4 digit year
MM = 2 digit month
mm = 2 digit minutes of the hour
............................................................................................................................................................................................................................................................
May 2009
The Service Measurement counts are:

DL_DOWNLINK_AVG_THRUPUT - Downlink average throughput. For each link,
the number of bytes in the downlink is counted at the LIU for every 10 second interval.
The downlink average throughput is calculated and reported in bytes/sec every hour by
averaging the data over the hour.
DL_DOWNLINK_PEAK_THRUPUT - Downlink peak throughput. For each link, the
number of bytes in the downlink is counted at the LIU for every 10 second interval.
The downlink peak throughput in bytes/sec is calculated by taking the interval with the
maximum bytes in the past hour and dividing by 10 seconds.
The facility type of this backhaul is indicated by the "FACTYPE" field.
614-326).
ACTION
When the thresholds are reached consistently, add more T1/E1s or convert to Ethernet
backhaul.
EXAMPLE
Data from file:
200602180500EST.HCSFMS020
…
HCS 119
RELEASE 28.00
VERSION 001
FACTYPE DS1
CONTL 005
…
DATALINK 001
DL_UPLINK_AVG_THRUPUT, 84
DL_UPLINK_PEAK_THRUPUT, 2521
DL_DOWNLINK_AVG_THRUPUT, 57
DL_DOWNLINK_PEAK_THRUPUT, 755
DATALINK 002
.
.
Vallent PROSPECT
• Template Type: IxEV_Datalink
............................................................................................................................................................................................................................................................
May 2009
• Template Name: TREND_DO EVDO_FWD_DL_AVG_OCC_%_T1, TREND_DO

EVDO_FWD_DL_PEAK_OCC_%_T1, TREND_DO
EVDO_FWD_DL_AVG_OCC_%_E1, TREND_DO
EVDO_FWD_DL_PEAK_OCC_%_E1.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_LIU_PO_%
EVDO_LIU_PO_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Link Interface Unit (LIU)
TYPE
Traffic Resource
TRIGGER
EVDO_LIU_PO_%
LIU average Processor Occupancy (PO) as a percentage
DESCRIPTION
call processing for the EV-DO LIU.
LIMIT VALUE
85%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_LIU_PO_%
Limit Value.
MEASUREMENT
EVDO_LIU_PO_% = LIU_AVG_PROC_OCCUPANCY
where:
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_LIU_PO_%
LIU_AVG_PROC_OCCUPANCY- Average Processor Occupancy for a LIU. The

processor occupancy for the LIU is measured at the end of ten second intervals. Processor
Occupancy is defined as the measure of the percentage of time the processor is busy
performing call processing related tasks. The Average Processor Occupancy shall be
calculated at the end of each hour by averaging all the measurements for the duration of
the hour. This count is in unit of percentage. For example, a value of 4 indicates 4%
occupancy. This count is kept per HCS (controller).
614-326).
ACTION
Balance the load among controllers by re-assigning carriers (if applicable).
Upgrade controller to URCII.
Add an additional controller if possible.
EXAMPLE
Data from file:
200702231800EST.HCSFMS020
HCS 007
…
CONTL 005
MCC_ELAPSED_TIME, 3600
LIU_AVG_PROC_OCCUPANCY, 0
LIU_PEAK_PROC_OCCUPANCY, 1
…
Vallent PROSPECT
• Template Name: TREND_DO LIU_OCC
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RLM_PO_%
EVDO_RLM_PO_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Reverse Link Modem (RLM/BMP)
TYPE
Traffic Resource
TRIGGER
EVDO_RLM_PO_%
RLM/BMP average Processor Occupancy (PO) as a percentage
DESCRIPTION
call processing for the EV-DO RLM if modem type is DB-EVM or BMP if modem type is
SB-EVM.
LIMIT VALUE
85%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_RLM_PO_%
Limit Value.
MEASUREMENT
EVDO_RLM_PO_% = RLM _BMP_AVG_PROC_OCCUPANCY
where:
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009
RLM_BMP_AVG_PROC_OCCUPANCY - Average Processor Occupancy for

RLM/BMP. For DB-EVM the average processor occupancy for the Reverse Link Modem
(RLM) is calculated at the end of each hour by averaging all the RLM processor
occupancy measurements for the past hour.The system measures the processor occupancy
at the end of each 10-second interval. For Single Board EVM (SB-EVM), the system
measures the BMP average processor occupancy. This count is in unit of percentage. For
example, a value of 4 indicates 4% occupancy.
614-326).
ACTION
Upgrade to SB-EVM if the modem type is DB-EVM, or add an additional cell and/or
carrier.
EXAMPLE
Data from file:
200602180500EST.HCSFMS020
…
HCS 119
RELEASE 28.00
VERSION 001
CONTL 002
...
DATALINK 001
...
EVM001
EVM_TYPE EVM
MODEM_ELAPSED_TIME, 3600
FLM_BAP_AVG_PROC_OCCUPANCY, 4
FLM_PEAK_PROC_OCCUPANCY, 4
FLM_OVERLOAD_NUM, 0
FLM_OVERLOAD_DURATION, 0
RLM_BMP_AVG_PROC_OCCUPANCY, 3
RLM_PEAK_PROC_OCCUPANCY, 4
…
Vallent PROSPECT
............................................................................................................................................................................................................................................................
May 2009
• Template Name: TREND_DO RLM_OCC
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RVS_DL_OCC_%
EVDO_RVS_DL_OCC_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Data Link
TYPE
Traffic Resource
TRIGGER
EVDO_RVS_DL_OCC_%
The data link occupancy for the reverse link.
DESCRIPTION
EVDO_RVS_DL_OCC_% is the occupancy for a data link in the reverse direction. The
datalink occupancy can be computed as follows:
For T1:
DL _ UPLINK _ AVG _ THRUPUT * 8

Average EVDO _ RVS _ DL _ OCC _ % = *100
1.536 *106
DL _ UPLINK _ PEAK _ THRUPUT * 8
Peak EVDO _ RVS _ DL _ OCC _ % = *100
1.536 *106
For E1:
Average EVDO _ RVS _ DL _ OCC _ % = *100
1.920 *106
Peak EVDO _ RVS _ DL _ OCC _ % = *100
1.920 *106
For Ethernet:
The reverse link bandwidth (Mbps) available per Ethernet connection
(Ethernet_BW_RVS) can be determined by parameter "Service Level Agreement -
Network Bandwidth (reverse)" on RC/V form btseqp/cdmeqp using common OA&M with
3G-1x.
Average EVDO _ RVS _ DL _ OCC _ % = * 100
Ethernet _ BW _ RVS * 10 6
Peak EVDO _ RVS _ DL _ OCC _ % = * 100
Ethernet _ BW _ RVS * 10 6
............................................................................................................................................................................................................................................................
May 2009
.LIMIT VALUE
Average EVDO_RVS_DL_OCC_% = 75%
Or
Peak EVDO_RVS_DL_OCC_% = 90% And Average EVDO_RVS_DL_OCC_% = 50%
ENG RULE
EVDO_RVS_DL_OCC_% Limit Value.
MEASUREMENT
where:
YYYY = 4 digit year
MM = 2 digit month
The Service Measurement counts are:
DL_UPLINK_AVG_THRUPUT - Uplink average throughput. For each link, the number
of bytes in the uplink is counted at the LIU for every 10 second interval. The uplink
average throughput is calculated and reported in bytes/sec every hour by averaging the
data over the last hour. The facility type of this backhaul is indicated by the "facility type"
field.
DL_UPLINK_PEAK_THRUPUT - Uplink peak throughput. For each link, the number of
bytes in the uplink is counted at the LIU for every 10 second interval. The uplink peak
throughput in bytes/sec is calculated by taking the interval with the maximum bytes in the
past hour and dividing by 10 seconds. The facility type of this backhaul is indicated by the
"facility type" field.
614-326).
ACTION
When the thresholds are reached consistently, add more T1/E1s or convert to Ethernet
backhaul.
............................................................................................................................................................................................................................................................
May 2009
EXAMPLE
Data from file:200602180500EST.HCSFMS020
…
HCS 119
RELEASE 28.00
VERSION 001
FACTYPE DS1
CONTL 005
…
DATALINK 001
DL_UPLINK_AVG_THRUPUT, 84
DL_UPLINK_PEAK_THRUPUT, 2521
DL_DOWNLINK_AVG_THRUPUT, 57
DL_DOWNLINK_PEAK_THRUPUT, 755
DATALINK 002
Vallent PROSPECT
• Template Type: 1xEV_Datalink
• Template Name: TREND_DO EVDO_RVS_DL_AVG_OCC_%_T1, TREND_DO
EVDO_RVS_DL_AVG_OCC_%_E1, TREND_DO
EVDO_RVS_DL_PEAK_OCC_%_T1, TREND_DO
EVDO_RVS_DL_PEAK_OCC_%_E1.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RNC_RL_PPS
EVDO_RNC_RL_PPS
............................................................................................................................................................................................................................................................
SYSTEM
EV-D0 Radio Network Controller (RNC)
TYPE
Traffic Resource
TRIGGER
EVDO_RNC_RI_PPS determines the packets per seconds (PPS) to the packet control
function (PCF) that can be supported on a RNC. This path is called revers link (RL).
DESCRIPTION
The RL PPS that a RNC can support is determined by number and types of TPs configured
in the RNC. Determine the RNC PPS as follows:
• Calculate the peak to average ratio for each TP.
TP_AVG_TO_PEAK_RATIO = PEAK_TP_UTILIZATION ÷ TP_UTILIZATION
If TP_AVG_TO_PEAK_RATIO is greater than 1.2, you may want to consider using
1.2 which gives a 20% margin above the average. Alcatel-Lucent recommends a 20%
margin. A higher TP_AVG_TO_PEAK_RATIO will give you greater than 20%
margin, which is acceptable. Lower than 20% margin may result in occasional
increased bearer path latency.
• Calculate the effective RL packet rates
EFF_RL_PPS=2 *AVE_ACTIVE_AT_COUNT + RLP_PKT_SENT_TO_PCF/3600
• Calculate Average Peak PPS rate for Reverse Link for each TP
TP_PPS_RL = TP_AVG_TO_PEAK_RATIO * EFF_RL_PPS
LIMIT VALUE
Compare TP_PPS_RL against the limits in the following table.
TP Type RL PPS Limit

TP690 2000
TP752i 3181
UTP 9722
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RNC_RL_PPS
ENG RULE
EVDO_RNC_TOTAL_PPS Limit Value.
MEASUREMENT
where:
YYYY = 4 digit year
MM = 2 digit month
PEAK_TP_UTILIZATION -.Peak Traffic Processor Utilization: This count represents the

peak busy processor occupancy percentage for a TP during the past collection period
TP_UTILIZATION - TP Processor Utilization: This count represents the average
processor occupancy percentage for a TP during the past collection period. Pegged
Against: TP which reported the CPU utilization.This count is used to measure the
processor occupancy of a TP.
RLP_PKT_SENT_TO_PCF - RLP Packets Sent to PCF: This count is incremented for
each packet that is received at the PCF from the RLP for forwarding to the PDSN and is
the total of all such packets processed by a TP. It is pegged against the TP on which the
RLP packet was received.
AVG_ACTIVE_AT_COUNT - This count reports the average number of active AT
sessions
For additional information see 1xEV-DO RNC AP OA&M (401-614-102) and
ACTION
IF TP_PPS_RL approaches or reaches the limit:
• If space is available, add more TP.
• If TP 690s are equipped, upgrade to TP752i
• If TP752i's are equipped, upgrade to UTPs
• Configure a new RNC
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RNC_FL_PPS
EVDO_RNC_FL_PPS
............................................................................................................................................................................................................................................................
SYSTEM
EV-D0 Radio Network Controller (RNC)
TYPE
Bearer Traffic Resource
TRIGGER
EVDO_RNC_FL_PPS determines the packets per seconds (PPS) to the radio link
protocols (RLP) that can be supported on a RNC. This path is called forward link (FL).
DESCRIPTION
The FL PPS that a RNC can support is determined by number and types of TPs configured
in the RNC. Determine the RNC FL PPS as follows:
• Calculate the peak to average ratio for each TP.
TP_AVG_TO_PEAK_RATIO = PEAK_TP_UTILIZATION ÷ TP_UTILIZATION
If TP_AVG_TO_PEAK_RATIO is greater than 1.2, you may want to consider using
1.2 which gives a 20% margin above the average. Alcatel-Lucent recommends a 20%
margin. A higher TP_AVG_TO_PEAK_RATIO will give you greater than 20%
margin, which is acceptable. Lower than 20% margin may result in occasional
increased bearer path latency.
• Calculate Average Peak PPS rate for Forward Link for each TP
TP_PPS_FL = TP_AVG_TO_PEAK_RATIO * A10_PKT_SENT_TO_RLP / 3600
LIMIT VALUE
Compare TP_PPS_FL against the limits in the following table.
TP Type FL PPS Limit
TP690 2300
TP752i 4666
UTP (unaccelerated) 11000
UTP (accelerated) 20588
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_RNC_FL_PPS
Limit Value.
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_RNC_FL_PPS
MEASUREMENT
where:
YYYY = 4 digit year
MM = 2 digit month
PEAK_TP_UTILIZATION -.Peak Traffic Processor Utilization: This count represents the
peak busy processor occupancy percentage for a TP during the past collection period
TP_UTILIZATION - TP Processor Utilization: This count represents the average
processor occupancy percentage for a TP during the past collection period Pegged
Against: TP which reported the CPU utilization.
This count is used to measure the processor occupancy of a TP.
A10_PKT_SENT_TO_RLP - A10 Packets Sent to RLP: This count is incremented for
each packet received on the A10 interface that is sent to RLP for forwarding to an AT and
is the total of all such packets processed by a TP. It is pegged against the TP on which the
GRE packet was received. This count shall not include the A10 Packets sent to RLP for
BCMCS.
For additional information see 1xEV-DO RNC AP OA&M (401-614-102) and
ACTION
When the total TP_PPS_FL approaches or reaches the limit value:
• If space is available, add more TP
• If TP 690s are equipped, upgrade to TP752i
• If TP752i's are equipped, upgrade to UTPs
• If UTPs are equipped, turn on the acceleration
• Configure a new RNC
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_SESS_OHM
EVDO_SESS_OHM
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Application Processor
TYPE
Traffic Resource
TRIGGER
EVDO_SESS_OHM
The average number of session (active and dormant) on an AP.
DESCRIPTION
EVDO_SESS_OHM provides the average number of sessions per AP.
LIMIT VALUE
Refer to Table 2-4, “R1SR with 752i TP Maximum RNC Capacity” (p. 2-5) or Table 2-5,
To get the value for Per AP: Divide the number in the table by the number of APs.
AP Type Limit
1G AP 40,000
2G AP 100,000
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_SESS_OHM
Limit Value.
MEASUREMENT
data file <AG_YYYYMMDDHHmmTMZ.HDRFMSXXX>
where:
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009

AVG_SESSION_PER_OHM
This count provides the data to calculate the average number of sessions during the past
hour which shall include active and dormant sessions. Every 10 seconds, the OHM takes a
snap shot of all sessions and accumulates to its previous accumulated value. The post
processing of this count should divide the value by 360 to get the average number of
sessions for the hour.
TOTAL_ALLOCATED_SESS_OHM
This count takes a snapshot of the Total Allocated Sessions in the OHM in which it is
measured.
For additional information, see 1xEV-DO RNC AP OA&M (401-614-102) and
ACTION
When the total number of allocated sessions reaches the limit value:
• add APs and 4 TPs until the RNC is fully equipped
• add an RNC and redistribute the cells/carriers.
COMMENT
See “EVDO_SESS_APFR” (p. 5-63) for the number of AT session per AP frame.
............................................................................................................................................................................................................................................................
May 2009
EXAMPLE
Data from file:
...
OHM 301
FAST_CONNECT, 4
AN_INIT_KEEP_ALIVE_REQ, 0
TP_NUM_SESS_DENIED, 0
FAST_CONNECT_FAIL_NO_TCC_RCVD, 0
AT_INIT_KEEP_ALIVE_REQ, 0
AT_INIT_SESS_CLOSE, 0
NUM_AUTH_FAIL_FOR_PSTPND_SEC_PCKT_OLD_CC, 0
NUM_AUTH_FAIL_FOR_PSTPND_SEC_PCKT_NEW_CC, 0
SESS_REL_KATIMER_EXP, 0
INT_SUBNET_IDLE_TRFR_A13_REQ_RECVD, 0
ISBNT_IDL_TRFR_A13_SESS_INFO_RSP_SENT, 0
INT_SUBNET_IDLE_TRFR_A13_REJECT_SENT, 0
INT_SUBNET_IDLE_TRFR_A13_CONFIRM_RECVD, 0
TOTAL_ALLOCATED_SESS_OHM, 7
AVG_ACTIVE_CONN_PER_OHM, 58
FAST_CONNECT_FAIL_RL_NOT_ACQ, 0
FAST_CONNECT_FAIL_NO_RSC, 0
FAST_CONNECT_TCA_SENT, 4
FAST_CONNECT_ESTABLISHED_CALLS, 4
PAGE_TRANSMISSION_FAILURE, 0
AN_INIT_OP_SESS_CLOSE_CMD, 0
NUM_AT_REL0_SESS_ESTABLISHED, 0
NUM_AT_REVA_SESS_ESTABLISHED, 0
PEAK_SESSION_PER_OHM, 9
PEAK_SESSION_NO_RP_CONN_PER_OHM, 9
AVG_SESSION_NO_RP_CONN_PER_OHM, 7
SESSION_BLOCKED_NO_UATI, 0
CS_RESV_CLOSED_PDSN_A11_SESSION_UPDATE, 0
............................................................................................................................................................................................................................................................
May 2009
CV_RESV_CLOSED_PDSN_A11_SESSION_UPDATE, 0
CPS_RESV_CLOSED_PDSN_A11_SESSION_UPDATE, 0
RESV_NULLED_PDSN_A11_SESSION_UPDATE, 0
RESV_GRANTED_PDSN_A11_SESSION_UPDATE, 0
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_SESS_TP
EVDO_SESS_TP
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Traffic Processor
TYPE
Traffic Resource
TRIGGER
EVDO_SESS_TP
The total number of R-P sessions allocated per TP.
DESCRIPTION
EVDO_SESS_TP provides the total number of R-P sessions allocated per TP.
LIMIT VALUE
Refer to Table 2-4 and Table 2-5, “UNC Maximum RNC Capacity” (p. 2-5).
To get the value for Per TP: Divide the number in the table by the number of TPs.
TP Type Limit
TP690 1000
TP752i 1000
UTP 5000
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_SESS_TP Limit
Value.
MEASUREMENT
YYYY = 4 digit year
MM = 2 digit month
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_SESS_TP

TOTAL_ALLOCATED_SESS_TP- Total Allocated Sessions (per TP). This count is
incremented whenever a new session is allocated and decremented when a session is
closed. It is the total of all session activities in a TP. This count is used to measure session
setup/ close activity.
Reference: For additional information see 1xEV-DO RNC AP OA&M (401-614-102) and
ACTION
When the total number of allocated sessions reaches the limit value: Add an AP pair and 4
TPs until the RNC is fully equipped,then add an RNC and redistribute the cells/carriers.
EXAMPLE
Data from file:
AG_200702231800EST.HDRFMS020
…
OHM 308
…
TP 307
…
RAN_AUTH_FAILURES_NO_AT_CHALLENGE_RSP, 0
AAA_SERVER_FAILURES, 0
TOTAL_ALLOCATED_SESS_TP, 276
RAN_AUTH_FAIL_AT_CONFIG_RJCT_RCVD, 0
…
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_SESS_APFR
EVDO_SESS_APFR
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Application Processor Frame
TYPE
Traffic Resource
TRIGGER
EVDO_SESS_APFR
The average number of sessions (active and dormant) on an all APs in an AP Frame.
DESCRIPTION
EVDO_SESS_APFR provides the average number of sessions (active and dormant) per
AP Frame.
LIMIT VALUE
Refer to Table 2-4, “R1SR with 752i TP Maximum RNC Capacity” (p. 2-5) and Table 2-5,
For all the APs in the Frame, sum the average number of session per AP
(SUMTOTALFrameAPs[AVG_SESSION_PER_AP]).
AP type in Limit
Frame
1G 300,000
2G 800,000
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_SESS_APFR
Limit Value.
............................................................................................................................................................................................................................................................
May 2009
MEASUREMENT
data file <AG_YYYYMMDDHHmmTMZ.HDRFMSXXX>
where:
YYYY = 4 digit year
MM = 2 digit month
AVG_SESSION_PER_OHM - This count provides the data to calculate the average
number of sessions during the past hour which shall include active and dormant sessions.
Every 10 seconds, the OHM takes a snap shot of all sessions and accumulates to its
previous accumulated value. The post processing of this count should divide the value by
360 to get the average number of sessions for the hour
[AVG_SESSION_PER_OHM] of all APs in an AP Frame < the limit value for that Frame.
Reference: For additional information see 1xEV-DO RNC AP OA&M (401-614-102) and
ACTION
When the total number of allocated sessions for the AP Frame reaches the limit value:
• Add APs and 4 TPs until the RNC is fully equipped
• Add an RNC and redistribute the cells/carriers.
COMMENT
See “EVDO_SESS_OHM” (p. 5-57) for the number of AT session per AP.
............................................................................................................................................................................................................................................................
May 2009
EXAMPLE
Data from file:
AG_200702231800EST.HDRFMS020
…
OHM 301
FAST_CONNECT, 4
AN_INIT_KEEP_ALIVE_REQ, 0
…
AN_INIT_OP_SESS_CLOSE_CMD, 0
…
............................................................................................................................................................................................................................................................
May 2009
Growth Engineering, Monitoring and Critical Triggers EVDO_TP_PO_%
EVDO_TP_PO_%
............................................................................................................................................................................................................................................................
SYSTEM
EV-DO Traffic Processor
TYPE
Traffic Resource
TRIGGER
EVDO_TP_PO_%
Traffic Processor (TP) Processor Occupancy (PO) as a percentage.
DESCRIPTION
Processor Occupancy is a measure of the percentage of the CPU being utilized on a TP.
LIMIT VALUE
80%
ENG RULE
Follow the General Engineering Rule. For Trigger-Value, use the EVDO_TP_PO_% Limit
Value.
MEASUREMENT
data file <AG_YYYYMMDDHHmmTMZ.HDRAPXXXHDRFMSXXX>
where:
YYYY = 4 digit year
MM = 2 digit month
TP_UTILIZATION - This count is used to measure the processor occupancy of a TP.
Also, monitor the following TP overload control related counts. An rare overload may be
acceptable due to external circumstances, but consistent overload needs to be addressed.
............................................................................................................................................................................................................................................................
May 2009
TP_OVERLOAD_NUM_PACKETS_DROPPED - Number of packets dropped due to

overload control
TP_OVERLOAD_TOTAL_ARR-RATE - Packet arrival rate when overload happened
NUM-TIMES-TP-OVERLOADED - Number of times TP went into overload in the hour
TP_OVERLOAD_DURAITON - Duration of time TP stayed in overload condition
Reference: For additional information see 1xEV-DO RNC AP OA&M (401-614-102).
ACTION
When the PO reaches the limit value, add a pair of APs and 4 TPs or 2 UTPs until the
RNC is fully equipped, and then add a RNC and redistribute the cells.
EXAMPLE
Data from file:
AG_200702231800EST.HDRFMS020
…
TP 307
PCF_INIT_REACT_ATTMPT, 1471
PCF_INIT_REACT_FAIL, 94
ERR_ON_A10_INTF, 0
PACKET_DISCARD_INVALID_AT, 0
PACKET_DISCARD_INSUFF_BUFFER, 0
A10_OCT_SENT_TO_RLP, 200428076
RLP_OCT_SENT_TO_PCF, 44104329
TP_UTILIZATION, 7
TP_OVERLOAD_NUM_PACKETS_DROPPED, 0
TP_OVERLOAD_TOTAL_ARR_RATE, 0
…
NUM_TIMES_TP_OVERLOADED, 0
TP_OVERLOAD_DURATION, 0
…
............................................................................................................................................................................................................................................................
May 2009
............................................................................................................................................................................................................................................................
May 2009
Glossary
............................................................................................................................................................................................................................................................
# 2N
2N (or duplex) reliability strategy uses 2 links. For example, the SS7 2N strategy uses 2 links, each
engineered at 40% occupancy.
3B21D
The 3B21D is the main hardware component for the Executive Cellular Processor Complex (ECPC). It is a
fully duplexed, fault-tolerant computer with 256 MB of physical memory. The 3B21D contains the
Input/Output Processor (IOP), the Central Processor Unit (CPU), the memory stores, and the disk file
controller.
Packet Switch
Alcatel-Lucent registered trademark for its Electronic Switching System.
............................................................................................................................................................................................................................................................
A A-Link
A-Links connect the ECP Complex to STPs. A-Links implement the full protocol as they are used for ANSI-
41 messaging. F-Links are used for direct connections between endpoints. A-Link engineering always uses 2N
(duplex) reliability and diverse transmission paths.
access channel
A setup channel used by a mobile unit to access a system to obtain service.
ACDN (Administrative Call Processing/Database Node)
The ACDN has responsibility for assigning new calls to CDNs for processing.
ACHT (Average Call Holding Time)
The Average Call Holding Time (ACHT) is the duration of time, typically in seconds, that a call lasts. Based
on the current Standard Call Distribution Tree, this number is about 96 seconds.
ACU (Analog Conversion Unit)
The ACU combines the output of a given CDMA Cluster’s CCUs. A given ACU supports two CDMA
clusters. ACUs are duplex, equipped as primary and standby.
A/D (Analog to Digital)
The process of converting an analog sample into the digital equivalent.
............................................................................................................................................................................................................................................................
401-614-331 Alcatel-Lucent - Proprietary GL-1
May 2009
Glossary
AM (Administrative Module)
A hardware component of the Packet Switch. Provides switch maintenance, administration, traffic
measurements, and network management. Includes the 3B21D processor.
AMA (Automatic Message Accounting)
Automatic Message Accounting (AMA) is a collection of call records used by Service Providers to bill their
customers for calls made on the system. AMA also provides useful information to the system operator and
engineer. From AMA, originations and terminations data on a Cell by Trunk Group Number (TGN) or
Office Code (NXX) basis for all the different call types may be obtained. Detailed holding times, such as
how long a call to a particular NXX lasts can also be obtained. This data helps to efficiently engineer
facilities.
AMPS (Advanced Mobile Phone Service)
The name given to the first Lucent Technologies cellular telephone system.
analog transmission
Technology that uses a stream of continuously changing electrical waves to carry voice or low-speed data.
ATM (Asynchronous Transfer Mode)
The ATM is used to move mass quantities of digital data to remote locations via data nodes.
............................................................................................................................................................................................................................................................
B bandwidth
Information-carrying capacity of a communications channel. The larger the bandwidth, the more
information it carries.
BBA trio
The combination of the BCR-BIU-ACU units for the new CDMA equipment configuration. See also entries
for Baseband Combiner Radio (BCR), Bus Interface Unit (BIU), and Analog Conversion Unit (ACU).
BCR (Baseband Combiner/Radio)
The BCR combines the I and Q signals from each of the Analog Conversion Units (ACUs) and (on the
forward link) converts the signal to RF with an RF up-converter. In the reverse path, it receives RF signals
and down-converts to baseband.
beacon radio/channels
A voice radio (usually analog) designated to operate at full power and used to assist in TDMA handoffs.
BHAC (Busy Hour Answered Calls)
Busy Hour Answered Calls (BHACs) represent the number of actual completed calls that generate revenue
(are billable). This number can be obtained from Service Measurement data on a per-trunk-group basis.
BHCA (Busy Hour Call Attempts)
The total number of originating and terminating call attempts handled by the system in a typical one hour
period. This is a count of all call attempts, not just completed calls.
BIU (Bus Interface Unit)
The BIU is the interface between the BCR, the ACU, and the Time Division Multiplexed (TDM) bus. It
provides a control bus interface to the CCC, CCUs, ACUs and BCRs. It provides power conversion and
alarm control functions. BIUs are duplex; equipped as primary and standby.
............................................................................................................................................................................................................................................................
GL-2 Alcatel-Lucent - Proprietary 401-614-331
May 2009
Glossary
............................................................................................................................................................................................................................................................
C CAI (Common Air Interface)

Specifies the RF interface by which CDMA products are being developed.
CCS
Hundred Call Seconds. See the entry, Hundred Call Seconds
CCS7 – ANSI SS7
CDMA (Code Division Multiple Access)
CDMA uses a spread-spectrum form of modulations requiring a contiguous block of spectrum (1.25 MHz)
rather than the channelized approach used by analog and TDMA. See also entries for Direct Sequence
Spread-Spectrum and spread-spectrum.
CDMA Carrier
A CDMA Carrier is the 1.25 MHz block of spectrum used for CDMA. This same block of spectrum is
reused in every cell. In addition, the system/cell can support multiple carriers.
CDMA Channel Unit (CCU)
CCUs create CDMA channels. Each CCU can be configured with two CDMA Channel Elements (CEs).
Groups of CCUs are logically connected to form a cluster which is controlled by a single CDMA Cluster
Controller (CCC).
CDMA Cluster
A CDMA cluster is a group of equipment consisting of one CDMA Cluster Controller (CCC) and up to
seven CDMA Channel Units (CCUs).
CDMA Cluster Controller (CCC)
A CDMA Cluster Controller is the controller for a group (seven maximum) of CDMA Channel Units
(CCUs).
CDMA Speech Handler (SH)
See entry for Protocol Handler for Voice (PHV).
CDN (Call Processing and Database Node)
A type of attached processor on the CNI/IMS Ring of the Alcatel-Lucent Wireless Network which is
responsible for call processing. The system may have up to 24 CDNs.
CDPD (Cellular Digital Packet Data)
CDPD systems transmit packets of digital data over idle channels on existing cellular networks.
CDX (Compact Digital Exchange)
A smaller-sized version of the Packet Switch, which runs the 5E10 version of the Packet Switch software.
CE (Channel Element)
A CDMA Channel Element (CE) contains the necessary circuitry to perform forward link and reverse link
CDMA spread-spectrum processing. Each CE supports one CDMA channel. Each CE can be assigned one
or more of these channel functions: pilot, synch, paging, access, traffic.
CELP (Code-Excited Linear Prediction)
A table-driven coding method that compresses several voice channels into the same 64 Kbps bandwidth that
a single Pulse Code Modulation (PCM) channel used to require. CELP is a term used in relation to variable
rate vocoders.
............................................................................................................................................................................................................................................................
May 2009
Glossary
cell
A geographical area, usually depicted as hexagon-shaped, that is served by a cellular system. Cellular
technology is based on the premise that a group of radio frequencies used within one cell can be used again
in distant cells.
cell site
An installation, located within a cell, housing the equipment needed to set up and complete calls on cellular
phones. (A cell site includes the following equipment: FM radio transmitter and receiver equipment,
antennas, and computers.)
CEPT (Conference on European Postal and Telecommunications Administrations)
An international standards organization.
CGSA (Cellular Geographic Service Area)
A basic coverage area served by a cellular system.
channel
A channel is a portion of the cellular frequency band designated for a single cellular telephone conversation.
It is an actual cellular RF channel as identified by the Federal Communications Commission (FCC), 30 kHz
for analog and 1.25 MHz for CDMA.
channel assignment
The process of specifying which voice channels are to be used at each cell site in a mobile service area.
CM (Communications Module)
Part of the Packet Switch hardware. The CM provides the fiber optic interconnections to the Switching
Modules (SMs), switches network data, voice, and control messages, and distributes timing and
synchronization.
CMSC (Compact Mobile Switching Center)
The Compact MSC (CMSC) provides a lower cost alternative to Service Providers by repackaging existing
components of the Alcatel-Lucent Wireless Network MSC to minimize development and testing impacts.
The “base” offering of the CMSC is stand-alone (there is no networking capability); it supports 10,000
analog subscribers (generating less than 4,000 BHCA); and it supports up to 10 cell sites. Options available
on top of the base system include TDMA, CDMA, and networking over SS7 or X.25 data links.
CNI/IMS (Common Network Interface/Interprocessor Message Switch) Ring
Part of the ECPC software, the CNI/IMS Ring supports a variety of nodes for signaling, call processing, and
message routing. The Ring provides an interface between the cell site and the ECPC, and the ECPC and the
DCS.
CNIP (Calling Number Information Presentation)
The CNIP feature displays calling number information (the calling party number) when alerting a mobile
phone.
CPU (Central Processor Unit)
A component of the ECPC, the CPU provides high speed control functions, such as logic, control, and
arithmetic processes as required by the 3B21D computer.
............................................................................................................................................................................................................................................................
May 2009
Glossary
CSN (Cell Site Node)

The CSN is the link node that provides the interface between the cell site and the ECPC. The CSN performs
broadcast functions for mobile paging and performs cell-to-cell message routing.
CTSO (Customer Technical Support Organization)
Formerly known as PECC.
............................................................................................................................................................................................................................................................
D D/A (Digital to Analog)

The process of converting a digital sample into the analog equivalent.
DCCH (Digital Control Channel)
Digital technology used to control messages between the mobile station and cell site (IS-136). Based on the
IS-54B TDMA Standard and specified as part of the IS-54C Standard. DCCH provides Basic System
Access (voice channel assignments, page responses, system parameters, etc.), plus air interface support for
new services, such as sleep mode and message services.
DCS (Digital Cellular Switch)
A generic term for the switching fabric of a Alcatel-Lucent Wireless Network switch. A DCS in the Alcatel-
Lucent Wireless Networks would a Packet Switch (for FDMA/TDMA and CDMA protocols).
DFI (Digital Facilities Interface)
The DFI provides the DS1 interface for packet pipes associated with a particular Cell Interface Module (for
example, CDMA). A DFI is located in the DLTU of the Packet Switch that supports the packet pipes, PSTN
trunks, CST, and data links.
DFU (Digital Facilities Unit)
Now called the Digital Facilities Interface. See entry for DFI.
DLN (Direct Link Node)
The DLN is the link node that provides the interface between the DCS and the CNI/IMS Ring. Each Alcatel-
Lucent Wireless Network system has at least two DLNs.
DLTU (Digital Line Trunk Unit)
The DLTU is used to house the digital trunk units. The DLTU contains the DFI circuit packs.
DMA (Direct Memory Access)
The means by which a peripheral unit can read/write directly to a main processor’s memory without any
CPU problems
DN (Directory Number)
A subscriber’s unique 10-digit mobile phone number.
down-time
The period of time in which a system is unable to service any calls due to failures within the system.
DPC (Dynamic Power Control)
The DPC controls the power transmitted from the mobiles to the cell site to help equalize the received signal
levels. DPC works in both the forward and reverse directions, and is a key component of the Alcatel-Lucent
CDMA product, essential for increased capacity and improved performance.
............................................................................................................................................................................................................................................................
May 2009
Glossary
DS0
A DS0 is a single 64 Kbps time slice on a T1 and/or E1.
DS1
A DS1 is a circuit board that supports the 24/30 DS0 channels on a T1/E1.
DSC (Dedicated Switch Connection)
Connects a cell site data link (via a 64 Kb DS0, multiplexed into a T1 span. The T1 span then terminates to
a DS1 interface at the DCS. At this point, the DS0 will have a connection nailed up through the DCS to
another SD0. This channel is multiplexed, along with other T1 channels from other cell sites. The DS0s are
then demultiplexed and cabled to the cell site node of the IMS/CNI ring of the ECP.
............................................................................................................................................................................................................................................................
E E1
An E1 is a four-wire voice/data trunking facility that carries 30 duplex channels via 64 Kbps time slices.
EAI (Emergency Action Interface)
The firmware-controlled graphic display interface to the ECP to allow boot and other critical maintenance
procedures.
ECPC (Executive Cellular Processor Complex)
The 3B21D computer is the main processor for the ECPC. It controls the operation of the Alcatel-Lucent
Wireless Network. The ECPC is responsible for mobility management, call processing, system
maintenance, technician interfaces, and system integrity.
Erlang
The Erlang is a unit for the measurement of traffic intensity. In strict terms, it really is usage rate and is
equal to 3600 Call Seconds (CCS) per hour. For example, the average call holding time per subscriber is 96
seconds, which is 0.96 CCS and 0.0267 Erlangs (that is, 97/3600).
............................................................................................................................................................................................................................................................
F F-Link
F-Links are SS7 links between the ECPC and the Packet Switch that implement MTP layers 1, 2, and 3 only
and are not used for ANSI-41 traffic. F-Links, depending on the associated protocol stack, can be used for
ANSI-41 communication, ISUP/TUP call delivery, or communication between the Packet Switch and the
ECPC. F-Link engineering between two MSCs should use 2N engineering and diverse transmission paths to avoid
losing communication if a path (cable for example) were to be severed.
FAF
Feature Activation File.
FCC (Federal Communications Commission)
Created in 1934, this group is responsible for regulating all types of communications in the United States.
FDMA (Frequency-Division Multiple Access)
FDMA uses narrowband channels of spectrum, each carrying one telephone circuit, in a system where any
mobile can access any one of the frequencies.
............................................................................................................................................................................................................................................................
May 2009
Glossary
frame relay
Frame relay is a method of packet switching capable of transporting voice. Frame relay is used to transport
speech between the radio unit in the cell to the frame selector in the DCS.
frame selector
The frame selector performs the soft handoff function and is located in the DCS.
FRPH (Frame Relay Protocol Handler)
The FRPH provides the interface between the T1 facility and the frame relay packet switching platform. For
the first release of the CDMA product, the FRPH terminates the CDMA packet pipes from the CDMA cell
sites.
............................................................................................................................................................................................................................................................
G GPS (Global Positioning System)

The GPS is the United States Department of Defense (DOD) sponsored global satellite system used to
provide accurate time and position location. The Reference Frequency and Timing Generator (RFTG)
makes use of the GPS receiver to synchronize CDMA signals.
G-RCF (Growth Radio Channel Frame)
Growth Radio Channel Frames can be added to the CDMA Primary Radio Channel Frame (P-RCF) to
increase the capacity of your CDMA system.
GSM (Global Switching Module)
A component of the International version of the Packet Switch.
............................................................................................................................................................................................................................................................
H handoff
An automatic transfer of a cellular telephone call from one cell to another, maintaining call quality as the
mobile user moves throughout the coverage area.
hard handoff (CDMA-to-analog)
A CDMA-to-analog hard handoff occurs when the dual mode CDMA mobile is instructed to change its
mode from CDMA to analog during a call. Consequently, the assigned frame selector will be removed from
the call configuration.
handoff S-Type
See S-Type handoff.
handoff Y-type
See Y-type handoff.
HLR (Home Location Register)
The database in charge of managing mobile phone subscribers. The HLR stores a permanent copy of a
mobile subscriber’s subscription information, and some location information to enable call routing to the
MSC where the mobile subscriber is located.
holding time
Holding time is the duration of time, typically in seconds, that any system resource (for example, zone office
(network interface) trunk, cell site trunk, senders, and receivers) is used for a single call. For example, the
holding time for a sender or receiver is about 2 seconds.
............................................................................................................................................................................................................................................................
May 2009
Glossary
Hundred Call Seconds

Hundred Call Seconds (CCS) is a measure of usage. (The leading "C" in the acronym comes from the
Roman numeral for one hundred, centum.) CCS is used to measure system resource usage and call attempts.
One CCS of trunk usage indicates that one trunk was carrying traffic for 100 seconds. It could also indicate
that 10 trunks were each experiencing traffic for 10 seconds each. Since a CCS is a period of 100 seconds,
and 1 hour is equal to 3600 seconds, there are 36 CCS in one hour.
............................................................................................................................................................................................................................................................
I I and Q (In-phase and Quadrature-phase) Signals

I and Q signals are used in the digital to analog conversion process.
IOP (Input/Output Processor)
Part of the 3B21D computer. The IOP serves as the interface between several peripheral controllers and the
Central Processor Unit (CPU). It acts as the hub connecting up to 16 microprocessor-based peripheral
controllers to the CPU. The IOP helps to free up the CPU for non-Input/Output tasks.
IRN (Integrated Ring Node)
The basic hardware building block of an IUN. One of the boards in an IUN that serves as the main processor
(aside from the CDNs).
ISDN (Integrated Services Digital Network)
ISDN is an integrated services network that provides digital connections between user-network interfaces.
ISUP (ISDN User Part)
CCS7 protocol for trunk setup, release, administration, and maintenance.
IUN (IMS User Node)
Any node on the IMS/CNI ring. For Alcatel-Lucent Wireless Network this includes CDNs, CSNs, and
RPCNs.
............................................................................................................................................................................................................................................................
K kHz
Abbreviation for kilohertz.
Kbps
Abbreviation for Kilobits per second.
............................................................................................................................................................................................................................................................
L LAF (Linear Amplifier Frame)

The LAF is part of the Series II cell site. It combines and amplifies transmit signals and sends them to the
Antenna Interface Frame (AIF).
LAN
Local Area Network.
LAPB (Link Access Protocol - Balanced)
A protocol standard at the data link layer. Provides error detection and control to higher protocol layers.
LAPD (Link Access Protocol - D Channel)
Data link layer protocol specified for the D-Channel.
............................................................................................................................................................................................................................................................
May 2009
Glossary
LMT (Lightwave Microcell Transceiver)

The LMT contains optical to electrical conversion equipment and a low power antenna for localized RF
transmission and reception.
LZR
Abbreviation for linearizer.
............................................................................................................................................................................................................................................................
M MAAP
Maintenance and Administration Panel (part of DCS).
MAHO
Mobile Assisted Handoff.
MB
Abbreviation for Megabytes.
MCC (Maintenance/Master Control Center)
The primary human interface with an Electronic Switching Center (ESS). On the Packet Switch, the MCC
features a color monitor with full diagnostic maintenance software, a Read-Only-Printer (ROP), and office
alarms.
MHz
Abbreviation for Megahertz.
MIHO
Mobile Initiated Handoff. A call mode change for dual-mode mobiles.
MIN (Mobile Identification Number)
A 34-bit number that is a digital representation of the 10-digit number assigned to the mobile station.
mobile-originated
Any call from a mobile unit, regardless of the destination of the call.
mobile-terminated
Any call completed to a mobile unit, regardless of the origination of the call.
mobile unit
The cellular equipment that interfaces a user with a wireless system by a radio link.
MSC (Mobile Switching Center)
All of the control and switching elements for a cellular system are contained at the MSC. For a Alcatel-
Lucent Wireless Network, the MSC consists of the ECPC, the CNI/IMS Ring, and the Packet Switch.
multiplexing
A means of transmitting two or more signals over the same transmission path or the same voice channel.
............................................................................................................................................................................................................................................................
N NAF
Network Application Feature.
............................................................................................................................................................................................................................................................
May 2009
Glossary
nail-up connection
A dedicated switch connection through the DCS. For example, the cell site connection to the ECP data links
is a nailed-up connection.
neighbor cell
A neighbor cell is a cell that is adjacent to the cell currently serving a mobile subscriber.
neighbor group
A group of cell sites near the cell site serving a call. When a handoff is required from the serving cell site,
the system will try to hand off the call to one of the cells in the group.
neighbor list
A list of cell sites in a neighbor group.
NVM
Non-Volatile Memory.
............................................................................................................................................................................................................................................................
O OA&M (Operations, Administration, and Maintenance)

Generic name given to Alcatel-Lucent Wireless Network functions such as technician interfaces,
diagnostics, service measurements, status reports, etc.
OIF (Optical Interface Frame)
The OIF is the interface between the radio frame and the microcell. It contains the equipment to provide the
optical-electrical interface between the Radio Channel Frame (RCF) and the fiber that delivers signals to
and from the Lightwave Microcell Transceiver (LMT).
OMP (Operations and Management Center)
The OMP is an element of the Alcatel-Lucent Wireless Network distributed architecture which is dedicated
to the support of all system OA&M activities. The OMP is based on a Sun Netra that is integrated into the
Alcatel-Lucent Wireless Network.
............................................................................................................................................................................................................................................................
P packet pipe
A packet pipe is a special trunk that is used to send packetized voice and data between a given CDMA
cluster and the DCS speech handlers, called the PHV.
packet switching
In packet switching, data is sent out in a sequence of small chunks called packets. Each packet is passed
through the network from node to node along some path leading from source to destination. At each node,
the entire packet is received, stored briefly, and then transmitted to the next node.
PCM (Pulse Code Modulation)
The binary coded signal corresponding to the user time assignment in a TDMA or a CDMA system.
PCS (Personal Communications Services)
PCSs are services that are planned for new digital Radio Frequency (RF) equipment. PCS will convey both
voice and data over wireless networks.
............................................................................................................................................................................................................................................................
May 2009
Glossary
PHV (Protocol Handler for Voice)

The PHV is one of the new components required to support CDMA on your existing Packet Switch. It is
used to transmit packets to and receive packets from the CDMA mobile unit through the cell site (or up to
three cell sites when in soft handoff). The PHV converts voice packets received from a cell site into 64 Kbps
voice and vice versa.
PN (Pseudo-Noise) Codes
Pseudo-Noise is the name given to the Mobile Station (MS) communications over the CDMA carrier (RF)
and is identified using a specific code. This PN Code is given to the MS at setup time and is what the cell
and MS use to communicate with each other. Each MS has a unique PN Code while active with a call.
PO (Processor Occupancy)
Processor Occupancy (PO) is the percentage of time a processor is handling calls or messages. It is a key
trigger for most system components. Every BHCA takes a toll on the PO of the CDN and the DCS. The limit
for DCS PO is 85 percent, which corresponds to 52,000 BHCAs.
Port and Call Usage Rates
Port Usage Rate (PUR) and Call Usage Rate (CUR) are primarily measures of Time Slot Interchanger (TSI)
use made by ports and calls in CCS or Erlangs for one call.
PSK (Phase Shift Keying)
Phase Shift Keying (PSK) is a type of encoding or modulation technique for transforming digital data into
analog signals.
PSTN (Public Switched Telephone Network)
The network that provides public telephone service. The portion of the total network that provides the
capability to interconnect any home or office in the country with any other.
PSU (Packet Switching Unit)
The PSU is one of the new components required to support CDMA on the Alcatel-Lucent Wireless
Network. The PSU consists of three circuit packs: the Protocol Handler for Voice (PHV), the Frame Relay
Protocol Handler (FRPH), and the Protocol Handler for Asynchronous Transfer Mode (PHA). The PSU
handles CDMA traffic to and from the CDMA mobile unit through the cell site. The Packet Switch
Switching Module (SM) provides an interface to a single PSU.
PSU Packet Bus
The PSU Packet Bus receives and sends packets to the appropriate PHV.
............................................................................................................................................................................................................................................................
R radio channel
Actual cellular Radio Frequency (RF) channel as identified by the FCC. For analog, the channel is 30 kHz
wide. In CDMA, the radio channel is 1.25 MHz wide.
RAP (Ring Attached Processor)
A classification of IUN. The CDN and the DLN are types of RAPs.
RC/V (Recent Change and Verify)
The Recent Change and Verify (RC/V) system provides the user interface to the database management
system.
............................................................................................................................................................................................................................................................
May 2009
Glossary
RF Call Trace
RF Call Trace is one of the optional features developed for CDMA. It provides for call performance
assessment from the mobile. By measuring the signal strengths of mobile calls from various cell sites, a
system operator can analyze the quality of the radio environment.
RFTG (Reference Frequency and Timing Generator)
Provides synchronization signals to the Synchronized Clock and Tone (SCT) board. It is also used to
provide the CDMA and analog radio reference frequency. It makes use of the Global Positioning System
(GPS) receiver to synchronize the CDMA signals.
RMN (Reach Me Number)
The RMN is part of the SMS feature of CDMA. A RMN is similar to paging. Callers leave a RMN which
gets displayed at the called party’s mobile unit.
roaming
The term used to describe a cellular telephone operating outside its home calling area.
ROP (Read-Only Printer)
A printer used most often for printing system maintenance information.
RPC
Ring Peripheral Controller.
RPCN (Ring Peripheral Controller Node)
The interface between the IMS/CNI ring and the ECP.
............................................................................................................................................................................................................................................................
S scan points
Scan points are physical contact closure devices that the ECP monitors. If the device is triggered, the ECP
starts an alarm message. Examples of scan points are intrusion alarms and high temperature alarms.
SCT (Synchronized Clock and Tone) board
The SCT provides timing capabilities, CDMA board synchronization, and a 19.6608 MHz reference clock.
The SCT’s signals are derived from the RFTG.
Service Measurements (SMs)
Subsystem responsible for collecting hourly data from various processors throughout the system. Data
collected via SM is used to monitor the health of the system and to engineer its growth.
setup channel
A channel used for the transmission of digital control information from a cell site to a mobile unit or from
a mobile unit to a cell site.
SFF (Store and Forward Functionality)
SFF is part of the SMS feature for CDMA. The SFF enables the Message Center (MC) to store the SMS
message and forward it at the appropriate time for conveyance to the mobile unit.
SH (Speech Handler)
The image used by the PHV to support CDMA. An SH converts voice packets to PCM and vice versa.
............................................................................................................................................................................................................................................................
May 2009
Glossary
SM (Switching Module)
The SM provides switching functionality and voice connectivity to the Public Switched Telephone Network
(PSTN) and the cell sites. The SM contains two new components necessary to support CDMA: the Packet
Switching Unit (PSU) and the PSU Packet Bus.
SMS (Short Message Service)
The SMS feature for CDMA has the ability to display short “canned” messages, and display a Reach Me
Number (RMN). The SMS feature incorporates a Message Center (MC) which provides Voice Response
Functionality (VRF) and Store and Forward Functionality (SFF).
soft handoff
A soft handoff occurs when two or more logical connections on a packet pipe are utilized by the frame
selector. A soft and softer handoff can occur at the same time.
softer handoff
A softer handoff occurs when a CDMA Channel Element utilizes two CDMA channels between itself and
the mobile unit.
spectrum
A range of frequencies available for radio transmission and reception. The FCC has set aside portions of the
spectrum for cellular service, while other portions of the spectrum are allocated to media such as television,
FM radio, and satellite transmissions.
spread-spectrum
Spread-spectrum technology refers to an entire family of radio transmission techniques that are used to
organize the distribution of radio frequency energy over a range of frequencies.
SS7 (Signaling System 7) node
The SS7 node is responsible for application level signaling messages. This node provides the physical data
link connections to the network. Each SS7 node provides one high-speed data link to a Signal Transfer Point
(STP) in the network, which handles message routing.
S-Type handoff
An S-Type Handoff "switches" a call from an existing trunk to a new trunk. This means that the handoff is
done by breaking the existing trunk connection before making the connection to the new trunk. The S-Type
handoff results in a small gap in the call which is perceptible by the subscriber. It is mainly used in 3-way
calling which is a low-runner call type. Here, 3 trunks would already be in use and a handoff will require a
4th trunk. This 4th trunk is not available in current DCS releases. Only 3 trunks can be involved in a
switching operation. Therefore, to complete the handoff, a break with an existing trunk must be performed
before a connection to a new trunk can be made.
STP (Signal Transfer Point)
The STP handles the routing of messages throughout the SS7 signaling network.
subrate multiplexing
The subrate multiplexing facility of CDMA allows multiple packet pipes to occupy the same facility.
............................................................................................................................................................................................................................................................
T T1
A T1 is a four-wire voice/data trunking facility that carries 24 duplex channels over 64 Kbps time slices.
............................................................................................................................................................................................................................................................
May 2009
Glossary
Tandem Calls
Inter-MSC call delivery. The PSTN delivers a call to the in-call system. The in-call MSC “Tandems”
(delivers) the call to the serving MSC.
Tandem Master
This is the in-call MSC. When the in-call MSC is not the Serving MSC, the call must be delivered to the
serving MSC. The in-call MSC that delivers the call to the serving MSC, is called the Tandem Master.
Tandem Slave
The MSC that receives a call from the Tandem Master and delivers the call to a mobile via one of its
connected cells. This MSC is also called the serving system.
TDMA (Time-Division Multiple Access)
TDMA divides each carrier frequency into a number of time slots, each of which constitutes an independent
telephone circuit. Current North American digital cellular systems use TDMA.
TIA (Telecommunications Industries Association)
The group responsible for setting telecommunications standards in the United States.
time slot
A time slot is a software entity (memory address and word pairs) that provides "to" and "from" pointers for
voice or data that enters and exits module(s).
TMS (Time Multiplexed Switch)
The Time Multiplexed Switch (TMS) is a space switch used by DCS Modules to route Inter-Module calls.
The TMS will only switch calls when it has like-numbered time slots on both the Sending Module and the
Receiving Module. This can be the cause of TMS "mismatch blocking," because time slots do not have the
same numbers (that is, they do not match). Each new pair of Modules acquires 256 new TMS time slots
(accessed via their own TMS link).
TMS Link Usage
TMS Link Usage is the amount of time that each Module uses its own link into the TMS. TMS Link Usage
is given in Erlangs or CCS.
trigger
A critical system trigger is defined as the component parameter whose particular value forces either further
tuning or growth of that component’s resources to prevent possible resource exhaustion. For example, in the
DCS, a key resource is the 501CC processor whose occupancy is a parameter that is considered a trigger.
When it reaches a particular threshold value (85 percent), it forces either further tuning (by moving the
DCS’s group of cells and/or trunks around) or growth (by adding a new DCS to the system).
trunk
A facility or circuit established to interconnect two switching machines.
TSI (Time Slot Interchanger)
The Time Slot Interchanger (TSI) is the switching fabric within every Module that switches the time slices
of each call entering a port to either another port within the same Module or to the TMS. It also switches
calls coming in from another Module via the TMS to an outgoing port.
............................................................................................................................................................................................................................................................
May 2009
Glossary
TSI Usage
TSI Usage is the amount of time that the TSI is being used by the Module for call routing. It also indicates
the load on the DCS network. It is given in terms of Erlangs or CCS.
............................................................................................................................................................................................................................................................
V VCA (Voice Channel Administration)

The subsystem responsible for maintaining the transient status of cell site trunks throughout the system.
VCA interacts with call processing.
VCDX (Very Compact Digital Exchange)
A smaller-sized version of the Packet Switch.
VLR (Visitor Location Register)
The VLR is a database that stores the necessary information needed to handle calls while a mobile
subscriber is visiting outside his home location area. The VLR can be integrated within the MSC or it can
be a separate network element.
vocoder (voice encoder)
A vocoder is part of the Packet Switch that converts encoded compressed voice packets to Pulse Code
Modulation (PCM) voice samples and back.
voice channel
A channel on which a voice conversation occurs, and on which brief digital messages may be sent from a
cell site to a mobile unit or from a mobile unit to a cell site.
Voice Response Functionality (VRF)
VRF is part of the SMS feature for CDMA. The VRF enables the Message Center (MC) to play
announcements that prompt a caller to leave a SMS message.
............................................................................................................................................................................................................................................................
X X.25
Communications protocol.
............................................................................................................................................................................................................................................................
Y Y-Type handoff
A Y-Type Handoff "joins" a call from an existing trunk to a new trunk. "Joins" means that the handoff is
done by first making the connection to the new trunk, and only after this, the existing trunk connection is
broken down. The Y-Type handoff results in no gap in the call. It is used in most cases since most are 2-party
calls. Here, 2 trunks would already be in use and a handoff will require a 3rd trunk. Since 3 trunks can be
involved in a switching operation, to complete the handoff without a gap in the call, the connection to a new
trunk is made before breaking the connection with the existing trunk.
............................................................................................................................................................................................................................................................
May 2009
Glossary
............................................................................................................................................................................................................................................................
May 2009

Scme Do 372411

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Scme Do 372411

Загружено:

Авторское право:

Доступные форматы

CDMA2000® 1xEV-DO

System Capacity Monitoring and Engineering

Release 30.0 and higher

Copyright© 2009 Alcatel-Lucent.

Copyright© 2009 Alcatel-Lucent. All Rights Reserved.

About this Document

2 EV-DO RNC Initial Engineering

3 EV-DO BTS Initial Engineering

4 Base Station OA&M Controller (BSOC) for Stand Alone EV-DO

5 Growth Engineering, Monitoring and Critical Triggers

Purpose of this Document

Reasons for Reissue

New in this Release

• New Critical Trigger “EVDO_RNC_FL_PPS” (p. 5-55)

Related Engineering Documents

To obtain technical support, documentation, and training or submit feedback

Base Station Configuration

Table 1-2 URC Capacity

RNC Initial Engineering

RNC Initial Engineering Overview

Important! If this information is not readily available, Alcatel-Lucent proposed

Table 2-1 IP Addresses for RNC Components (R1SR and UNC)

Engineering RNC Capacity Limits

Table 2-2 AP R1SR Signaling Distribution at full capacity

Table 2-3 AP UNC Signaling Distribution at full capacity

Note: Assumption is that each page results in an average of 30 paged sectors.

Table 2-4 R1SR with 752i TP Maximum RNC Capacity

Item R1SR Configuration Limits

Important! An R1SR configuration group is defined as 2 APs and 4 TP690s, 2 PAs

Table 2-5 UNC Maximum RNC Capacity

Item UNC Configuration Limits

Item UNC Configuration Limits

Important! A UNC configuration group is defined as 2 APs and 2 UPTPs or 2 APs

Considerations Affecting Capacity

Cell Assignment Performance Considerations

Geographic Cell AP Mapping

Non Geographic Cell AP Mapping

Summary of AP Assignment Methods

Idle Transfer Impact

Optional Feature Impact

Quality of Service Features (12078 series)

Table 2-6 QOS TP Capacity Degradation

Per Call Measurement Data (12269 series)

Push to Talk (12184 series)

Impact of Security features on the EVDO RNC

Impact of 3GPP2 Model Variations EVDO RNC

Table 2-7 AP Capacity Variation

Item Event / S M Change in Change in Change in A P

Idle Transfer 7750 15500 1% on serving

Idle Transfer 7750 15500 1% on serving

Idle transfer 47000 94000 1% on A13 on

C onnection 34300 68600 1% on serving

C onnection 311500 623000 1% on serving

Paging 11500 23000 1% on serving

Soft and Softer 7700 15400 1% on serving

Table 2-8 Other Capacity Impacting Items

Initial Engineering Procedures

Table 2-9 AP Impacting User Behavior

Table 2-10 TP Impacting User Behavior

12 VoIP Busy Hour Call

17 Total Packet Per Second Rate - FL

To calculate Row 17:

To calculate Row 18:

BH_Active_Subscribers0 = 20000.40.3 = 240

BH_Active_SubscribersA = 20000.60.3 = 360

QoS_Subscriber (PTT) = 20000.60.3 = 360