1x evdo optimization_guide_v3.0_chr

Nortel Networks Confidential and Proprietary
. . . . . . . . . .
..........CoreRFEngineering
Dept.5395
1xEV-DORFOptimizationGuide
1xEV– DO Release 3.x
Product Line: 1xEV-DO Release 3.0 ChR
Version: Initial Release
Issue Date: March 3, 2006
Author: Mike Woodley
Department: Core RF
Authorizing Manager: Frank Jager / Farhad Bassirat
2003 Nortel Networks
All rights reserved.
Information subject to change without notice.
The information disclosed herein is proprietary to Nortel Networks or others and is not to be used by or disclosed to unauthorized
persons without the written consent of Nortel Networks. The recipient of this document shall respect the security status of the
information.

Nortel Networks Confidential and Proprietary 2
Table of Contents
TABLE OF CONTENTS............................................................................................................................. 2
1 INTRODUCTION................................................................................................................................ 8
1.1 RELATED DOCUMENTS.................................................................................................................... 8
1.2 SCOPE.............................................................................................................................................. 9
1.3 REVISION HISTORY ......................................................................................................................... 9
1.4 CONTRIBUTORS ............................................................................................................................... 9
1.5 AUDIENCE ....................................................................................................................................... 9
2 1XEVDO OPTIMIZATION EVENTS FLOW CHART................................................................. 10
3 1XEV-DO PRE OPTIMIZATION OBJECTIVES.......................................................................... 11
3.1 ENTRANCE AND EXIT CRITERIA.................................................................................................... 11
3.1.1 RF Design Review ................................................................................................................ 11
3.1.2 Coverage Control ................................................................................................................. 11
3.1.3 RF Coverage Availability ..................................................................................................... 11
3.1.4 Inter-RNC Border Design..................................................................................................... 13
3.1.5 CIQ Review and Provisioning Verification .......................................................................... 15
4 1XEV-DO OPTIMIZATION EVENTS............................................................................................ 17
4.1 INITIAL RF PARAMETERS VERIFICATION...................................................................................... 17
4.2 PRE OPTIMIZATION SYSTEM HEALTH CHECK................................................................................ 17
4.3 FTAP AND RTAP TESTING ........................................................................................................... 19
4.4 TCP / IP PARAMETERS .................................................................................................................. 20
4.5 SHAKEDOWNS ............................................................................................................................... 24
4.6 GOLDEN VALUE (STATIONARY) TESTING...................................................................................... 24
4.7 CLUSTER DRIVE TESTING.............................................................................................................. 25
4.8 TROUBLESHOOTING....................................................................................................................... 25
5 DATA COLLECTION / POST PROCESSING TOOL SETUP .................................................... 26
5.1 LAPTOP SETUP............................................................................................................................... 26
5.2 AT SETUP...................................................................................................................................... 27
5.3 DATA COLLECTION TOOL SETUP................................................................................................... 27
5.3.1 RNC Logging Setup .............................................................................................................. 27
5.3.2 Optis-M Setup....................................................................................................................... 32
5.3.3 Optis-M Log Masks .............................................................................................................. 35
5.3.4 Invex3G Chassis Setup ......................................................................................................... 38
5.3.5 InVex3G Log Masks.............................................................................................................. 40
5.4 AT LOG DATA POST-PROCESSING TOOL SETUP............................................................................ 41
5.4.1 RF Optimizer EV-DO ........................................................................................................... 41
5.4.2 XCAP-DO............................................................................................................................. 43
5.5 DOM - RNC LOG POST PROCESSING TOOLS................................................................................. 45
5.5.1 Converting RNC Logs from Binary to Text........................................................................... 45
5.5.2 NEWTUN (Post Processing and Analysis of RNC Logs)...................................................... 45
5.6 OM DATA COLLECTION TEMPLATE CONFIGURATION SETUP........................................................ 54
5.7 CELLDM DATA COLLECTION ...................................................................................................... 56
5.8 OM ANALYSIS TOOLS................................................................................................................... 61
5.9 TCP PERFORMANCE LOGGING TOOLS........................................................................................... 63
6 SHAKEDOWNS................................................................................................................................. 65
6.1 OBJECTIVES................................................................................................................................... 65
6.2 EVDO SITE SHAKEDOWN PROCESS .............................................................................................. 65

6.3 EVDO INTER SUBNET ACTIVE HANDOFF (ISSHO) SHAKEDOWN PROCESS.................................. 69
6.4 (A13) DORMANT SESSION HANDOFF SHAKEDOWN PROCESS ........................................................ 71
6.5 DATA PROCESSING AND ANALYSIS ............................................................................................... 73
6.5.1 EVDO Site Shakedown Analysis........................................................................................... 73
6.5.2 Inter RNC Active Handoff Shakedown Analysis ................................................................... 77
6.5.3 A13 Dormant Session Handoff Analysis............................................................................... 78
7 GOLDEN VALUE (STATIONARY) TESTING............................................................................. 79
7.1 INTRODUCTION.............................................................................................................................. 79
7.2 FTP SERVER CONFIGURATION ...................................................................................................... 79
7.3 GOLDEN VALUE TESTING PROCESS............................................................................................... 79
8 OM COLLECTION AND ANALYSIS ............................................................................................ 84
8.1 CONNECTION ATTEMPTS ............................................................................................................... 84
8.2 FAILED CALL ATTEMPTS (FCA / ACCESS FAILURE)...................................................................... 84
8.3 DROPPED CONNECTIONS (ABNORMAL CONNECTION CLOSES)...................................................... 84
8.4 SESSION SETUP PERFORMANCE (INCLUDES A13 SESSION HANDOFFS)........................................... 85
8.4.1 UATI Request Initiated A13 Dormant Handoff Performance............................................... 85
8.4.2 Prior Session Initiated Dormant Handoff Performance....................................................... 85
8.4.3 A10 Connection Setup Performance..................................................................................... 85
8.4.4 Session Configuration Failures ............................................................................................ 86
8.5 SERVING SECTOR SWITCHING AND SOFT/SOFTER HANDOFF PERFORMANCE ................................ 86
8.6 INTER RNC ACTIVE HANDOFF TRAFFIC STATISTICS AND SECONDARY BORDER MEASUREMENT. 86
8.7 1XEVDO PAGING PERFORMANCE MEASUREMENTS ..................................................................... 86
8.8 PER SECTOR AIRLINK RESOURCES ALLOCATION (BLOCKING)...................................................... 86
9 CLUSTER DRIVE TESTING........................................................................................................... 87
9.1 DATA COLLECTION PROCESS ........................................................................................................ 87
9.2.1 Access Failure Rate.............................................................................................................. 92
9.2.2 Connection Drop Rate.......................................................................................................... 95
9.2.3 Throughput in Mobility Condition........................................................................................ 99
9.2.4 Connection Setup Time....................................................................................................... 102
10 TROUBLESHOOTING............................................................................................................... 103
10.1 SESSION SETUP AND A13 HANDOFF SUCCESS RATE ................................................................... 103
10.1.1 Data Collection Methods.................................................................................................... 103
10.1.1.1 AT Logs..................................................................................................................................... 103
10.1.1.2 RNC Logs.................................................................................................................................. 103
10.1.1.3 OMs........................................................................................................................................... 109
10.1.2 KPI Calculation.................................................................................................................. 113
10.1.2.1 KPI Value and Tolerance Factor................................................................................................ 113
10.1.2.2 Calculating KPI from AT Logs.................................................................................................. 114
10.1.2.3 Calculating KPI from RNC Logs............................................................................................... 114
10.1.2.4 Calculating KPI from OMs........................................................................................................ 114
10.1.3 Troubleshooting Guide....................................................................................................... 115
10.2 SESSION SETUP TIME................................................................................................................... 118
10.2.1.1 AT Logs..................................................................................................................................... 119
10.2.1.2 RNC Logs.................................................................................................................................. 119
10.2.1.3 OMs........................................................................................................................................... 119
10.2.2 KPI Calculation.................................................................................................................. 119

10.3 CONNECTION SETUP TIME........................................................................................................... 120
10.3.1.1 AT Logs..................................................................................................................................... 120
10.3.1.2 RNC Logs.................................................................................................................................. 120
10.3.1.3 OMs........................................................................................................................................... 120
10.3.2 KPI Calculation.................................................................................................................. 121
10.4 ACCESS FAILURES....................................................................................................................... 122
10.4.1.1 AT Logs..................................................................................................................................... 122
10.4.1.2 RNC Logs.................................................................................................................................. 124
10.4.1.3 OMs........................................................................................................................................... 125
10.4.2 KPI Calculation.................................................................................................................. 125
10.5 CALL BLOCKS ............................................................................................................................. 133
10.5.1.1 AT Logs..................................................................................................................................... 133
10.5.1.2 RNC Logs.................................................................................................................................. 133
10.5.1.3 Blocking OMs............................................................................................................................ 134
10.5.2 Blocking KPI Calculation................................................................................................... 134
10.6 CONNECTION DROPS ................................................................................................................... 138
10.6.1.1 AT Logs..................................................................................................................................... 138
10.6.1.2 RNC Logs.................................................................................................................................. 139
10.6.1.3 Dropped Connection OMs......................................................................................................... 140
10.6.2 Dropped Connection KPI Calculation ............................................................................... 141
10.6.2.3 Calculating Dropped Connections KPI from RNC Logs ........................................................... 142
10.6.2.4 Calculating Dropped Connection KPI from OMs...................................................................... 142
10.6.3 Dropped Connection Troubleshooting Guide..................................................................... 143
10.7 FL SECTOR SWITCHING SUCCESS RATE ...................................................................................... 154
10.7.1.1 AT Logs..................................................................................................................................... 154
10.7.1.2 RNC Logs.................................................................................................................................. 154
10.7.1.3 OMs........................................................................................................................................... 154
10.7.2 Forward Sector Switching Success Rate KPI Calculation ................................................. 154
10.8 FL SECTOR SWITCHING TIME...................................................................................................... 155
10.8.1.1 AT Logs..................................................................................................................................... 155
10.8.1.2 RNC Logs.................................................................................................................................. 155

10.8.1.3 OMs........................................................................................................................................... 156
10.8.2 KPI Calculation.................................................................................................................. 156
10.9 RL SHO SUCCESS RATE.............................................................................................................. 157
10.9.1.1 AT Logs..................................................................................................................................... 157
10.9.1.2 RNC Logs.................................................................................................................................. 157
10.9.1.3 OMs........................................................................................................................................... 158
10.9.2 KPI Calculation.................................................................................................................. 158
10.10 FL PER-USER THROUGHPUT ................................................................................................... 160
10.10.1 Data Collection Methods................................................................................................ 160
10.10.1.1 AT Logs..................................................................................................................................... 160
10.10.1.2 TCP Trace Logs......................................................................................................................... 160
10.10.1.3 RNC Logs.................................................................................................................................. 162
10.10.1.4 OMs........................................................................................................................................... 162
10.10.2 KPI Calculation.............................................................................................................. 162
10.10.3 Troubleshooting Guide................................................................................................... 163
10.11 FL PER-SECTOR THROUGHPUT................................................................................................ 180
10.11.1.1 AT Logs..................................................................................................................................... 180
10.11.1.2 RNC Logs.................................................................................................................................. 180
10.11.1.3 OMs........................................................................................................................................... 180
10.11.2 KPI Calculation.............................................................................................................. 181
10.12 RL PER-USER THROUGHPUT ................................................................................................... 181
10.12.1.1 AT Logs..................................................................................................................................... 181
10.12.1.2 RNC Logs.................................................................................................................................. 182
10.12.1.3 OMs........................................................................................................................................... 182
10.12.2 KPI Calculation.............................................................................................................. 182
10.13 RL PER-SECTOR THROUGHPUT ............................................................................................... 185
10.13.1.1 AT Logs..................................................................................................................................... 185
10.13.1.2 RNC Logs.................................................................................................................................. 185
10.13.1.3 OMs........................................................................................................................................... 185
10.13.2 KPI Calculation.............................................................................................................. 185

10.14 FL ACHIEVABLE DATA RATE.................................................................................................. 186
10.14.1.1 AT Logs..................................................................................................................................... 186
10.14.1.2 RNC Logs.................................................................................................................................. 186
10.14.1.3 OMs........................................................................................................................................... 186
10.14.2 KPI Calculation.............................................................................................................. 187
10.15 RL ACHIEVABLE DATA RATE ................................................................................................. 191
10.15.1.1 AT Logs..................................................................................................................................... 191
10.15.1.2 RNC Logs.................................................................................................................................. 191
10.15.1.3 OMs........................................................................................................................................... 191
10.15.2 KPI Calculation.............................................................................................................. 191
10.16 PACKET LATENCY ................................................................................................................... 193
10.16.1.1 AT Logs..................................................................................................................................... 193
10.16.1.2 RNC Logs.................................................................................................................................. 193
10.16.1.3 OMs........................................................................................................................................... 193
10.16.2 KPI Calculation.............................................................................................................. 194
10.17 DO-TO-1X HANDOFF DELAY .................................................................................................. 194
10.17.1.1 AT Logs..................................................................................................................................... 194
10.17.1.2 RNC Logs.................................................................................................................................. 195
10.17.1.3 OMs........................................................................................................................................... 195
10.17.2 KPI Calculation.............................................................................................................. 195
10.18 DO-TO-1X SUCCESS RATE ...................................................................................................... 195
10.18.1.1 AT Logs..................................................................................................................................... 195
10.18.1.2 RNC Logs.................................................................................................................................. 195
10.18.1.3 OMs........................................................................................................................................... 196
10.18.2 KPI Calculation.............................................................................................................. 196
APPENDIX A: EVDO OPTIMIZATION AND TROUBLESHOOTING FLOW CHARTS............ 197

APPENDIX B: CLI SYSTEM READINESS CHECK.......................................................................... 202
APPENDIX C: SHAKEDOWN FORM ................................................................................................. 205
APPENDIX D: EXAMPLES OF PAST ISSUES................................................................................... 206

1 Introduction
This document provides a guideline for RF engineers to do the RF optimization of a 1xEV-DO system.
1xEV-DO system is optimized to carry non real-time packet data services and hence does not support voice
services. In the forward link, 1xEV-DO air interface is designed to provide up to 2.4 Mbps data rate with
only one 1.25 MHz carrier using TDM (Time Division Multiplexing) system. In the reverse link, 1xEV-DO
provides up to 153.6 kbps data rate similar to 1xRTT. Since the forward link physical layer implementation
of 1xEV-DO and CDMA/1xRTT are different, they cannot exist in the same frequency. 1xEV-DO has to
be deployed in a separate carrier.
1.1 Related Documents
• [1] “1xEV-DO Coverage and Capacity Performance,” v2.0, Muhieddin Najib, Core RF
Engineering, February 2004 (http://navigate.us.nortel.com/imds?pg=/eng/wne/cdma/sys/rf/lb)
• [2] “1xEV-DO Provisioning Guideline,” v2.1.03, Kenneth Ho, Core Network Engineering, August
2004 (http://navigate.us.nortel.com/imds?pg=/eng/wne/cdma/sys/dim/gl)
• [3] “1xEV-DO RF Parameters and Datafill Guide,” v3.01, Mike Garramone, Core RF
Engineering, October 2005.
(http://livelink.us.nortel.com/livelink/livelink.exe?func=ll&objId=9655009&objAction=browse&s
ort=name)
• [4] “DOM-RNC Logging,” Wei Lou, Core RF Engineering, draft to be released.
• [5] “QTP-5500 Access Terminal Users Guide,” 80-B1311-2, Rev A, Qualcomm, March 2004.
• [6] “1xRTT and 1xEV-DO RF Link Budgets,” Muhieddin Najib, Core RF Engineering, October
2004 (presentation to Orange).
• [7] “1xEV-DO RF System Performance,” Miro Budic, Core RF Engineering, October 2004
(presentation to Orange).
• [8] “1xEV-DO RF Parameters,” Brian Troup, Core RF Engineering, September 2004
(presentation in Verizon Users Group).
• [9] “Inter-RNC Active Handoff RF Engineering Guideline,” Version 0.02, Brian Troup, October
2005.
(http://livelink.us.nortel.com/livelink/livelink.exe?func=ll&objId=9655009&objAction=browse&s
ort=name)
• [10] “Optis-M Quick Start Guide,” v1.05, WirelessLogix, 2004 [11] “OPTis-M User Guide,”
v1.05, WirelessLogix, 2004
• [11] “Maximum 1xEV-DO Application Layer Throughput,” Dept. 2N51, October 2002.
• [12] “Generic Network Acceptance Process – 1xEVDO Network,” v4.1, Mike Woodley, January
2005.
• [13] “Microsoft Windows 2000 TCP/IP Implementations Details,” Dave MacDonald and Warren
Barkley, 2005 Microsoft Corp.
• [14] “RFC 3481 – TCP over Second (2.5G) and Third (3G) Generation Wireless Networks,”
www.faqs.org/rfcs/rfc3481.html
• [15] “TAP Users Guide”, Rev. A, Airvana, April 22, 2001
• [16] “1xEVDO Troubleshooting Guide”, Std 2.05, NTP 411-2133-949, April 2005
• [17]“1xEVDO Performance Measurements”, Draft 4.07, NTP 411-2133-924, September 2005.
• [18] “Invex3G Quick Start Guide”, version 4.3, Andrew Corporation, 2005.
• [19] “1xEV-DO CELLDM Logging Feature Application Guide”, Wei Lou, Version 0.1, October
20, 2005.
• [20] “A13 Dormant Handoff and UA10 Minimization Application Guide”, Miroslav Budic, Draft,
September 23, 2005.

1.2 Scope
This document only covers the RF optimization aspect of 1xEV-DO Release 0.
RF optimization guideline document for IS-95 CDMA is available as NTP 411-2133-004. RF optimization
guideline document for IS-2000 (1xRTT) is available at
http://navigate.us.nortel.com/imds?pg=/eng/wne/cdma/sys/po/opt.
1.3 Revision History
Issue Date Reason
1.0 November 4, 2005 Initial release for EVDO rel. 3.0.
1.1 March 3, 2006 Updated to reflect EVDO 3.0 ChR.
The latest version of this document is available at
http://navigate.us.nortel.com/imds?pg=/eng/wne/cdma/sys/po/opt.
1.4 Contributors
The following are the key contributors to the contents of the document:
• Rubianto Satrio
• Wei Lou
• Brian Troup
• Miro Budic
• Martin Kendall
• Mike Woodley
• Alexander Contreras
• Saied Kazeminejad
• Gordon Edwards
• Remo Agostino
1.5 Audience
This document is intended for Nortel Networks and customer RF engineers that are involved in the 1xEV-
DO deployment and want to understand how to optimize a 1xEV-DO network. A basic understanding of
IS95 and IS2000, as well as general RF principles is expected of the reader.
THIS VERSION IS CURRENTLY FOR INTERNAL AUDIENCES ONLY

2 1xEVDO Optimization Events Flow Chart
N
Y
Y
N
Establish Network Optimization Entrance and
Exit Criteria (Section 3.1)
1xEVDO / CDMA 1xRTT network RF
Coverage Design Review
(Section 3.1.1 – 3.1.4)
Coverage design is sufficient to meet
optimization exit criteria?
Review Customer CIQ responses and
current network provisioning
(Section 3.1.5)
Is network provisioning and call models
sufficient to support optimization exit
criteria?
RF Datafill Parameters Review and
Verification (Section 4.1)
Pre Optimization System Health Check
(Section 4.2 and Appendix B)
PreOptimizationObjectives
FTAP and RTAP Airlink Bandwidth
Verification (Section 4.3)
TCP / IP Parameter Review and
Verification
(Section 4.4)
Site and Border Shakedowns
(Section 6)
Golden Value (Stationary Testing)
(Section 7)
Cluster Drive Testing / Optimization
(Section 8 - 9)
Exit Criteria
Satisfied?
Perform Troubleshooting
(Section 10)
Exit Market
Y
InMarketOptimizationActivities

3 1xEV-DO Pre Optimization Objectives
This chapter gives an overview of the events and processes in the 1xEV-DO RF optimization work. The
subsequent chapters (Chapter 3 onward) will then discuss them in more detail.
3.1 Entrance and Exit Criteria
Entrance Criteria
In general there are four important steps that need to be done prior to the 1xEV-DO RF optimization:
• Review the 1xEV-DO RF design (in iPlanner) to make sure that it meets the coverage and
capacity/throughput objectives.
• Check that the 1xEV-DO network design matches the requirements listed in the CIQ (Customer Input
Questionnaire) response.
• Ensure that the recommended datafill is used for the initial RF parameters.
• 1xEV-DO basic system readiness checkup is conducted.
• The 1xEV-DO drive test routes are determined and agreed upon.
• Exclusion criteria and warranty boundaries agreed upon by Nortel and the customer
Exit Criteria
The detailed exit criteria need to be negotiated between Nortel Networks and the customer. They have to be
agreed upon prior to the 1xEV-DO RF optimization effort. Metrics that can be used for this purpose
include:
• Data-rate-to-DRC matching (i.e., showing that the decoded data rate received matches the DRC
requested).
• Single-user application throughput under a certain RF and mobility condition.
• Access failure rate.
• Connection drop rate.
• Connection setup time.
3.1.1 RF Design Review
Just like in CDMA, a good 1xEV-DO network starts with a good 1xEV-DO RF design. Therefore, the first
step in 1xEV-DO RF optimization should be to review the final RF design. Some important items to check
are discussed below.
3.1.2 Coverage Control
One of the most important principles of CDMA RF design, i.e. coverage control, still applies to 1xEV-DO.
In 1xEV-DO, the AT (Access Terminal) continuously estimates the SINR (signal-to-interference-plus-noise
ratio) in the forward link and requests a data rate based on the SINR. In general, the better the SINR, the
higher the data rate requested (the exact algorithm depends on the AT vendor implementation). Hence we
should check the RF design to ensure that each sector covers only the area it is intended to cover. Any
potential pilot pollution area should be cleaned up as much as possible, e.g., by using different antenna
configuration. The final RF design result should show that:
• The forward link SINR or Ec/Nt (C/I) is ≥ -2 dB throughout the network.
3.1.3 RF Coverage Availability
As in CDMA, the 1xEV-DO RF design must satisfy the path loss requirement for the designed data rate
from the link budget. This can be shown using the pilot composite coverage plot or the required AT
Transmit power plot.

The 1xEV-DO cell radius depends, among other things, on the designed data rate. If the 1xEV-DO network
is overlaid 1-to-1 on an IS-95 network, then it is good for the forward link data rate of 307 kbps (at 1900
MHz and with AT receive diversity) and reverse link data rate of 19.2 kbps as the chart below shows [1]. If
higher data rate is needed, then additional cell sites are needed.
38.4
kbps
76.8
kbps
153.6
kbps
307.2
kbps
614.4
kbps
921.6
kbps
1228.8
kbps
1843.2
kbps
2457.6
kbps
w/o
Diversity
136% 111% 99% 88% 73% 61% 55% 45% 40%
1900
MHz w/
Diversity
161% 131% 116% 104% 87% 72% 65% 53% 47%
w/o
Diversity
158% 129% 114% 102% 85% 71% 64% 52% 46%
850
MHz w/
Diversity
185% 151% 134% 120% 100% 83% 75% 62% 54%
w/o
Diversity
145% 118% 105% 93% 78% 65% 59% 48% 42%
450
MHz w/
Diversity
169% 137% 122% 109% 91% 76% 68% 56% 49%
1xEV-DO forward link cell radius relative to IS-95 EVRC.
9.6 kbps 19.2 kbps 38.4 kbps 76.8 kbps 153.6 kbps
All
Frequencies
111% 101% 89% 75% 57%
1xEV-DO reverse link cell radius relative to IS-95 EVRC.
Another important thing to consider is that a certain data rate in the reverse link is required to support the
high data rate in the forward link. Therefore the RF design has to ensure the reverse link data rate is enough
to support the forward link data rate. The chart below shows the measurement results from LAV network in
Ottawa [6], [7]. To support the TCP ACKs, the reverse link data rate has to be at least 1/40 of the forward
link data rate. So, for example, a forward link data rate of 2 Mbps requires a reverse link data rate of 50
kbps or higher.
Max Fwd Rate vs Rev Rate
80
82
84
86
88
90
92
94
96
98
100
19.2 38.4 76.8
Reverse Rate [kbps]
NormalizedFwdRate[%]
Reverse link data rate impact on forward link throughput.

3.1.4 Inter-RNC Border Design
In Nortel’s EVDO release 3.0 there is a new feature called “Inter RNC Active Handoff” (IRAHO) that will
allow ATs to add pilots to its Active set from DOMs primarily homed on adjacent RNCs. The intent of the
feature is to:
• Prevent dropped connections and access failures in border areas
• Enhance sector and AT throughput in border areas
This feature allows the AT to add pilots from a DOM in another subnet through secondary homing.
Secondary homing allows an operator to home DOMs to up to 8 secondary RNCs in addition to its Primary
RNC (i.e. data fill the routing table in the DOM with the primary RNC and up to 8 secondary RNC’s).
Through secondary homing an AT can add pilots from DOMs in an adjacent subnet without having any
knowledge of that subnet’s Color Code, or Subnet ID. The figure below shows an example of the physical
connectivity of DOMs and RNCs in a multi homed scenario.
Figure – EVDO Multi Homing Configuration example
The limitations of this feature are that it is only functional when the AT is already in an Active data call and
crosses a subnet boundary. If the call continues long enough such that the AT requests a pilot from a DOM
in the adjacent subnet that is not secondarily homed to the source or anchor RNC then the call will drop
because the Resource Lookup on the anchor RNC will fail.
Implementation of the inter RNC active soft handoff feature requires the secondary sector border to be
planned such that coverage between the primary sectors and the secondary sectors is contiguous to enable
soft handoffs to occur. To prevent dropped connections the secondary sectors should be in areas of low
mobility such as secondary roadways or through areas where there are not high concentrations of fixed

users. Care should be taken in border planning such that there will be a dominant PN in the coverage
overlap region between border sectors. The absence of a dominant server in these areas may lead to Ping
Pong. Excess ping pong can lead to excessive session setups, access failures and dropped connections. The
following figure illustrates secondary sector deployment in an area of high mobility. The secondary border
can be defined as Subnet 1+ in the figure below. The shape of the secondary border for Subnet 1 will allow
AT’s originating calls in Subnet- 1 to move to sectors deep within Subnet-3 and Subnet -7 without
dropping the active call and would be ideal for extending coverage in Subnet-1 along the highway or any
other high speed road [9].
(Subnet-3)
RNC-3
RNC-4
(Subnet-4)
RNC-5
(Subnet-5)
RNC-6
(Subnet-6)
(Subnet-7)
RNC-7
(Subnet-2)
RNC-2
RNC-1
(Subnet-1)
Subnet-1+Highway or other
high speed road
Figure: IRAHO Example Showing the Ability to Maintain an Active Connection from RNC-7 -> RNC-1
-> RNC-3
The level of mobility can be seen as the percentage of calls entering or leaving a cell at any particular
period of time. It could be expressed by the following ratio:
Cell
Coverage
ATs entering cell ATs leaving cell
A C
B
ATs staying in cell
Cell
Coverage
ATs entering cell ATs leaving cell
A C
B
ATs staying in cell

Level of mobility = (A + C) / (A + B + C)
One way to get an idea of low mobility areas would be to look at the 3G data mobility behavior of the
underlying 1xRTT network. There is no formula that can provide an exact mobility ratio, but the BTS OMs
FCHOriginationNonBlocking3GData and the FCHHandoffNonBlocking3GData can help to provide an
educated guess. They can be used in the following ratio which is similar to the mobility ratio above:
Level of mobility ≈ (FCHHandoffNonBlocking3GData) /
(FCHHandoffNonBlocking3GData + FCHOriginationNonBlocking3GData)
Similarly, one way to get an idea of the level of data activity in a 1xEV-DO network is to analyze the data
activity in the underlying 1xRTT network. This can be done by comparing, on a per sector basis, the data
Minutes of Use (MOU) within the 1xRTT network. On a Nortel Networks 1xRTT data network, the MOU
can be determined using the 3G Data MOU, i.e. PrimaryFrameCntFCH[3,5,7] from the BTS performance
OMs. Lower amount of 3G Data MOU would indicate a lower data activity area.
After initial deployment, RNC logs should be collected and analyzed using the NEWTUN tool. The
NEWTUN tool will provide a list of DOMs that should be homed as secondary DOMs to the RNC under
consideration. The use of NEWTUN to refine the DOM homing configuration will be iterative but should
be highly refined after about the 3rd
round of analysis.
Setting and managing the number of primary and secondary DOMs per RNSM is done at the DO RNC’s
topology manager. In addition to managing the number of primary and secondary DOMs per RNSM, each
DOM has a primary selection table used for data filling the IP address of the primary RNC. Likewise there
is a secondary RNC homing table which contains fields for adding the IP addresses of secondary RNC’s
and a field the indicates whether secondary homing has been enabled or not [9].
Example DOM Menu Config Primary / Candidate and Secondary RNCs
3.1.5 CIQ Review and Provisioning Verification
Prior to the 1xEV-DO RF optimization, it is a good practice to review the 1xEV-DO CIQ that the customer
filled out and check that the 1xEV-DO network design matches the requirements listed in the CIQ
response. Several important lists/information to check are as follows:
• IP address design for RNCs, nodal elements, and DOMs
• Inter Subnet borders and assignment of secondary RNCs to border sites – up to 8 secondary RNCs
homed per sector.

• Unique Color Code value for each RNC
• EVDO Neighbor List – maximum of 20 neighbors per sector
• Traffic Engineering – data application call model, distribution of services, and subscriber counts
Reference [3] provides the complete provisioning rules and procedures for the DOM, DO-RNC, DO-EMS,
and the backhaul networks. Of particular interest to RF engineers is probably the DOM provisioning.
Currently each Metrocell can house three DOMs. However, there can be only one DOM per carrier (for 3
sectors). Therefore, if 1xEV-DO is deployed in only one carrier, the maximum number of DOMs is the
same as the number of Metrocells. If the required number of DOMs is bigger than the number of
Metrocells, then cell splitting may be considered.
The required number of DOMs depends on the DOM capacity limitation, reverse link Erlang requirement,
forward link throughput requirement, and the Metrocell limitation mentioned above [2]. A DOM has 96
channel elements and can serve about 90 connections in the reverse link (across 3 sectors). Assuming an
average CE/user of 1.5, the number of primary users that can be served by a sector in a tri-sector site is 20
[1].

4 1xEV-DO Optimization Events
4.1 Initial RF Parameters Verification
Since 1xEV-DO introduces many new RF parameters, it is important to verify that the correct RF
parameters have been configured. The default RF datafill parameters are the recommended starting point
for optimizing a network. Please refer to [3] and [8] to get detailed descriptions these parameters and their
recommended values.
EVDO Editor is a PC based application for viewing and editing specific RF parameters at the DOM level
(i.e. RF Gain, Cell Radius, RAB Offsets, and Neighborlists). It also will allow users to view parameters at
the RNC level. Currently, EVDO Editor has business rules checking capabilities for DOM level
parameters. Future releases will have business rules checking capabilities for RNC level parameters.
EVDO Editor can be found at http://navigate.us.nortel.com/imds?pg=/eng/wne/core/tool/adm/cdma/doed.
EVDO Editor
4.2 Pre Optimization System Health Check
The basic system readiness checkup is done to verify that the 1xEV-DO system is ready to carry traffic. In
summary, the following attributes should be checked:
• Verify status of all Nodes (DOM and RNC) using “NORTEL-XX# show node” have an administrative
and operational status of “Up”
• Verify status of all Modules (BIO Cards, RNSM, SC, DOM, etc) using “NORTEL-XX# show module”
has a status of “Active”.
• Verify status of all the interfaces (i.e. Ethernet, T1/E1, PPP, node 1/0/1) using “NORTEL-07# show
interface” command. All interfaces must have an administrative and operational status of “UP”.

o Ethernet interfaces:
DOM Backhual – If a T1 is connected to a DOM along with 100/10 base T ethernt
connection, the DOM will prompt traffic from the RNC over T1.
2 Ethernet ports per BIO card – for support of A10/A11 interface communication,
Abis, A12, and OA&M paclets. On CLI, BIO Ethernet interfaces are listed as
Ethernet 1/x/1, 1/x/2 where x denotes the slot of the card.
1 Ethernet port per SC control module - these are optional interfaces for carrying
OAM traffic. On CLI, the active SC port is listed as Ethernet 1/0/1.
Management IP Interface – an optional interface that is used in conjunction with the
SC aux. Ethernet if operators want to forward management IP traffic to a virtual
management interface. On CLI the management IP interface is listed as mgmt1/0/1.
o All Used T1/E1:
DOM Backhaul – used to backhaul DOM physical and link layer traffic to the
aggregation router.
o PPP Interface for each T1/E1 interface
DOM Backhaul - a PPP link is associated with each T1 between the DOM and the
aggregation router to provide duplexed, simultaneous, bidirectional, sequential,
packet transfer of encapsulated Abis and OAM IP packets between two dedicated
network peers. On CLI, the DOM T1 / PPP interface is denoted as: ppp1/0/1,
ppp1/0/2, ppp1/0/3, and ppp1/0/4 interfaces.
o Node 1/0/1 interface
Abis and OAM data - provides a loop back or virtual interface for the transfer of
Abis data from the DOM to the primary RNC and OAM data to the EMS. On CLI it
is shown as : node 1/0/1 interface.
• Status of the Abis links between the DOM and the RNC using “NORTEL-07# show abis peer”. Every
RNC should have an Abis status of “Connected” to every DOM that is homed to it.
• Status of the traffic and control channels established between the DOM and the RNC.
• Ping the Node IP address of DO RNC, IP Addresses on the aggregation router associated with DOM
backhaul links, and the DO EMS IP address from the DOM. “NORTEL-07> ping 10.0.0.0”
• Ping the IP address of all DOMs, IP addresses of DOM PPP Links, all PDSNs, and the DO EMS from
the RNC.
• Status of GPS for all DOMs. “NORTEL-07> show GPS health”
The basic system readiness checkup should be done from the EMS. An example of how to do it from the
command line interface can be found in Appendix B. In the event any of the system readiness checks fail
refer to the troubleshooting or recovery sections of reference [16].

4.3 FTAP and RTAP Testing
FTAP and RTAP tests should be performed to network end to end performance capabilities inclusive of the
EVDO airlink. FTAP and RTAP are built in test EVDO testing utilities that send test frames to determine
the available bandwidth of the network.
Prior to testing, a location where RF is known to be good should be selected. In addition, AT logs should be
captured during TAP testing to measure the PER% seen at the AT.
Data rates given by FTAP tests should be equivalent to the average DRC request rate and RTAP tests
should show equivalence to the average Reverse link Rate limit of the sector.
The following is an example of how to configure TAP tests from CLI: For more information on TAP tests
see, reference [15].

4.4 TCP / IP Parameters
Prior to starting optimization a review of configured TCP / IP parameters should be performed. Due to the
fact the FTP protocol, used extensively in optimization activities, is based on TCP, a thorough review of
configurable TCP and PPP layer parameters should be performed to insure accurate performance reporting.
See Reference [13] for more information on TCP/IP parameter descriptions.
Recommended TCP/IP Configuration:
• Data Collection Laptop configuration – Insure that the following TCP / IP settings are
optimized. TCP send and receive buffers should be optimized according to the bandwidth delay
product (i.e. Buffer Size = Bandwidth x delay). For EVDO, ideal Buffer Size =
(2450kbps/8bits/byte * 150msecs) = 45.9kBytes.
o Recommended TCP RX Window Size = 64240
TcpWindowSize (Configured from Registry Editor)
Key: TcpipParameters, TcpipParametersInterfaceinterface
Value Type: REG_DWORD—number of bytes
Valid Range: 0–0x3FFFFFFF (1073741823 decimal). In practice the TCP/IP stack will
round the number set to the nearest multiple of maximum segment size (MSS). Values
greater than 64 KB can be achieved only when connecting to other systems that support
RFC 1323 Window Scaling.
Description: This parameter determines the maximum TCP receive window size
offered. The receive window specifies the number of bytes that a sender can transmit
without receiving an acknowledgment. In general, larger receive windows improve
performance over high-delay, high-bandwidth networks. For greatest efficiency, the
receive window should be an even multiple of the TCP Maximum Segment Size (MSS).
This parameter is both a per-interface parameter and a global parameter, depending
upon where the registry key is located. If there is a value for a specific interface, that
value overrides the system-wide value. See also GobalMaxTcpWindowSize.
o Recommended MTU Size = 1500
MTU (Configured from Registry Editor)
Key: TcpipParametersInterfacesinterface
Value Type: REG_DWORD—number
Valid Range: 88–the MTU of the underlying network
Default: 0xFFFFFFFF
Description: This parameter overrides the default Maximum Transmission Unit (MTU)
for a network interface. The MTU is the maximum packet size, in bytes, that the
transport can transmit over the underlying network. The size includes the transport
header. An IP datagram can span multiple packets. Values larger than the default for the
underlying network cause the transport to use the network default MTU. Values smaller
than 88 cause the transport to use an MTU of 88.
• Note: Windows 2000 TCP/IP uses PMTU detection by default and queries the NIC
driver to find out what local MTU is supported. Altering the MTU parameter is
generally not necessary and may result in reduced performance.
• PMTU Discovery (Enabled)

When a connection is established, the two hosts involved exchange their TCP maximum segment
size (MSS) values. The smaller of the two MSS values is used for the connection. Historically, the
MSS for a host has been the MTU at the link layer minus 40 bytes for the IP and TCP headers.
However, support for additional TCP options, such as time stamps, has increased the typical
TCP+IP header to 52 or more bytes.
EnablePMTUDiscovery
Key: TcpipParameters
Value Type: REG_DWORD—Boolean
Valid Range: 0, 1 (false, true)
Default: 1 (true)
• IP Header Compression (Disabled)
It is well known (and has been shown with experimental data) that TCP header compression does
not perform well in the presence of packet losses. If a wireless link error is not recovered, it will
cause TCP segment loss between the compressor and decompressor, and then header compression
does not allow TCP to take advantage of Fast Retransmit Fast Recovery mechanism. The header
compression algorithm does not transmit the entire TCP/IP headers, but only the changes in the
headers of consecutive segments. Therefore, loss of a single TCP segment on the link causes the
transmitting and receiving TCP sequence numbers to fall out of synchronization. Hence, when a
TCP segment is lost after the compressor, the decompressor will generate false TCP headers.
Consequently, the TCP receiver will discard all remaining packets in the current window because
of a checksum error. This continues until the compressor receives the first retransmission which is
forwarded uncompressed to synchronize the decompressor.
As previously recommended, header compression SHOULD NOT be enabled unless the packet
loss probability between the compressor and decompressor is very low. Actually, enabling the
Timestamps Option effectively accomplishes the same thing. Other header compression schemes
like RFC 2507 and Robust Header Compression are meant to address deficiencies in RFC 1144
header compression.
Figure 4 – Disabling IP Header Compression in Windows 2000
In order to disable IP header compression, go to Start -> Settings->Network and Dial Up
Connections, and then select the appropriate device and then “Properties”. After selecting
properties, then go to the TCP/IP component under the Networking tab and select properties again.

• Software data compression (Disabled)
Data compression enables information to be transmitted beyond the actual connection speed. Data,
particularly text and graphics, usually contain repeated sequences of identical information. Data
compression works by replacing many characters of repeated information with a few characters
and transmitting only one copy of repeated sequences of data.
Communication software, such as Network and Dial-up Connections, may support data
compression. For example, using a 14.4 Kbps V.32bis modem, you can enable software
compression, and experience an average throughput of 28.8 Kbps. Tests show that software
compression can result in higher data transfer rates than hardware compression.
To insure accurate reporting of application or physical layer throughput over the access network
the “Enable Software Compression” setting in the Windows “Dialup Networking Properties - >>
PPP Settings” should be disabled.
Figure – Disable Software Compression

• LCP Extensions (Disabled)
LCP is part of the PPP protocol that provides for the establishment, configuration, and testing of
the peer to peer data link connection. The enable LCP extensions option within the PPP settings of
Windows Dial Up Networking allows the software to take advantage of additional LCP features.
Some extensions for LCP and there functions are as follows and more detail provided in
http://ietfreport.isoc.org/idref/rfc1570/#ref-2
1. Identification [12] – allows the application to identify itself to its peer (Link Maintenance
Packet)
2. Time Remaining [13] – notifies the peer of the time remaining in the session
3. Frame Check Sequence (FCS) Alternatives [9] – provides a method to specify another FCS
format to be sent by the peer or to negotiate it away altogether.
4. Self Describing Padding [10] – Indicates to the peer that the use of padding is understood.
Used when some protocols, such as network layer or compression protocols, are configured
which require detection and removal of any trailing padding.
5. Callback [13] – provides a method for the implementation to request a dial up peer to call
back.
6. Compound Frames [15] – allows the implementation to send multiple PPP encapsulated
packets within the same frame. (self describing padding must be used in conjunction with this
option)
• TCP Timestamps (Enabled)
Another RFC 1323 feature introduced in Windows 2000 is support for TCP time stamps. Like
SACK, time stamps are important for connections using large window sizes. Time stamps were
conceived to assist TCP in accurately measuring round-trip time (RTT) to adjust retransmission
time-outs. The use of time stamps is disabled by default. It can be enabled using theTcp1323Opts
registry parameter.
Tcp1323Opts
Key: TcpipParameters
Value Type: REG_DWORD—number (flags)
Valid Range: 0, 1, 2, 3
0 (disable RFC 1323 options)
1 (window scale enabled only)
2 (timestamps enabled only)
3 (both options enabled)
Default: No value; the default behavior is as follows: do not initiate options but if requested
provide them.
Description: This parameter controls RFC 1323 time stamps and window-scaling options. Time
stamps and window scaling are enabled by default, but can be manipulated with flag bits. Bit 0
controls window scaling, and bit 1 controls time stamps.
• Selective Acknowledgment (SACK) - (Enabled)
SACK is especially important for connections using large TCP window sizes. Prior to SACK, a
receiver could only acknowledge the latest sequence number of contiguous data that had been
received, or the left edge of the receive window. When SACK is enabled, the receiver continues to
use the ACK number to acknowledge the left edge of the receive window, but it can also
acknowledge other non-contiguous blocks of received data individually.
When SACK is enabled (the default), a packet or series of packets can be dropped, and the
receiver can inform the sender of exactly which data has been received, and where the holes in the
data are. The sender can then selectively retransmit the missing data without needing to retransmit
blocks of data that have already been received successfully.

SACK is controlled by the SackOpts registry parameter. The Network Monitor capture below
illustrates a host acknowledging all data up to sequence number 54857341, plus the data from
sequence number 54858789-54861685. SACK is enabled by default in Windows
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x1A0D; Proto = TCP; Len: 64
TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722,
src:1242 dst:139
TCP: Source Port = 0x04DA
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 925104 (0xE1DB0)
TCP: Acknowledgement Number = 54857341 (0x3450E7D)
TCP: Data Offset = 44 (0x2C)
TCP: Reserved = 0 (0x0000)
+ TCP: Flags = 0x10 : .A....
TCP: Window = 32722 (0x7FD2)
TCP: Checksum = 0x4A72
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: SACK Option
TCP: Option Type = 0x05
TCP: Option Length = 10 (0xA)
TCP: Left Edge of Block = 54858789 (0x3451425)
TCP: Right Edge of Block = 54861685 (0x3451F75)
• FTP Server (Sun) XMIT Hi Water mark
o If the FTP server is a SUN Solaris workstation, insure that the TCP XMIT HIWAT
setting is configured for 64k.
o Windows based FTP servers have no configurable TCP TX buffer setting.
o ndd -set /dev/tcp tcp_xmit_hiwat 65536
• The tcp_xmit_hiwat parameter is effectively the size of the send buffer. The send
buffer high watermark tunes the transport layer socket buffer size on a kernel wide
basis. The socket buffer can also be changed on a per-socket basis by using the
SO_SNDBUF socket option within an application. Mind that for UDP the size of the
output buffer represents the maximum datagram size.
4.5 Shakedowns
The first step in 1xEV-DO RF optimization is to perform a shakedown of each cell site and all inter subnet
borders. Like in CDMA, the objective of the shakedown is to verify that we can get a connection on each
sector and switch to the adjacent sector in the forward link (and softer-handoff to it in the reverse link), and
to ensure that the sector RF parameters (like PN offset and neighbor list) are correct. Chapter 6 presents the
detailed procedure to do the shakedown.
4.6 Golden Value (Stationary) Testing
The second step in 1xEV-DO optimization is to perform a stationary data testing to measure the maximum
single-user application throughput in the forward and reverse link. During this exercise, the TCP, RLP,
and/or other RF parameter setting can be optimized to improve the throughput. Once those settings are
optimized and finalized, the measured single user application throughput becomes the “golden” value, i.e.,

the upper bound of what we can achieve in the network. Chapter 7 presents the detailed processes involved
in performing stationary (Golden Value) data testing.
4.7 Cluster Drive Testing
Once the stationary data testing is done, we can do drive tests along the important roads to measure various
RF performance in a cluster. We can also do more stationary data testing in different locations (that are
deemed important) throughout the cluster. Based on these test results, the datafill (i.e. Power and resources
related parameters, etc) can be adjusted to improve the 1xEV-DO performance. Chapter 9 details the
process involved in performing typical 1xEV-DO cluster drive testing.
4.8 Troubleshooting
If RF performance problems are encountered during the stationary and drive testing (or anytime during the
deployment period), engineers will have to analyze various performance attributes in efforts to diagnose
where the root cause lies. Depending on the problems, troubleshooting may require more than the regular
mobile logs obtained from the cluster drive testing. Chapter 10 presents various tips and examples to help
engineers troubleshoot various 1xEV-DO RF performance problems.

5 Data Collection / Post Processing Tool Setup
This chapter will discuss briefly the requirement and the setup procedure for 1xEV-DO RF data collection
and post-processing tools. More detailed discussion can be found in the reference documents mentioned in
each section.
5.1 Laptop Setup
The preferred method of 1xEV-DO data collection/testing is using a laptop connected to WirelessLogix
Optis-M tool (EV-DO version) or Andrew Invex3G. If only one AT is used (like in the shakedown), then
XCAL-DO or Invex3G PC can be used.
Laptop connected to Optis-M data collection tool.
Laptop connected to Invex3G data collection tool
The laptop used for 1xEV-DO testing has to have the following:
• Windows 2000 or XP operating system
• Intel Pentium4 processor 1.6 GHz equivalent or above
• 512MB RAM or above
Please refer to [12] for more detailed specification requirements.
The following software needs to be installed in the laptop:

Drive Test Data Collection Tools:
• WirelessLogix Optis-M / XCAL -DO version 2.2.0 or later.
o Available from Couei website: http://pms.couei.co.jp
o Login with user id = guestna@nortelnetworks.com and password = WLsupportNortel
• Andrew Invex3G / PC version 4.3 or later.
o http://www.andrew.com/products/measurement_sys/Invex/
Drive Test log Post Processing Tools:
• EV-DO RF Optimizer version 2.2.5.30 or later.
o Available at http://navigate.us.nortel.com/imds?pg=/eng/wne/core/tool/cdma/rfoevdo)
• XCAP-DO ((from WirelessLogix) version 3.77 or later can also be used.
o Available from Couei website: http://pms.couei.co.jp
o Login with user id = guestna@nortelnetworks.com and password = WLsupportNortel
DOM-RNC logs post-processing tools:
• NEWTUN Available at: http://navigate.us.nortel.com/imds?pg=/eng/wne/core/tool/adm/cdma/ntn
• LogFileConvert (Java tool) (Available on RNC)
• LogConvertDOS (Available on RNC)
Applications:
• FTP Client application such as WS-FTP Pro. Chariot may also be used.
Optional tools:
• TCP performance logging tools: Windump, Snoop, Ethereal and TCPTrace.
• OM analysis tool: OMAX (Nortel OM analysis tool available through Mike Anderson)
• There are several TCP parameters that need to be set correctly. See Section 4.4 above.
If either Optis-M or Invex3G are used as the data collection tool, then the TCP parameters need to be set
inside the tool. However, if either XCAL-DO or Invex3G - PC are to be used, then we need to change these
parameters in the laptop. One easy way to do it is by using DrTCP utility software (available in the internet,
for example from http://www.dslreports.com/drtcp).
Section Appendix 4.4 contains a detailed description of settable TCP / IP paremeters on how to optimize
them for the data collection tools (i.e. laptop, etc) and the FTP server.
5.2 AT Setup
The ATs (mobiles) that are recommended to be used for 1xEV-DO RF optimization along with data
collection platform support are given below:
• Qualcomm QTP-6500 (ZRF 6500) – Optis / XCAL / Invex3G
• Sierra Wireless 580 – Optis / XCAL / Invex3G
• Sierra Wireless /Audiovox 5220 – Optis / XACL / Invex3G
• Samsung A890 – Optis / XCAL
• LG Vx8000 – Optis / XCAL
• Novatel Merlin V620 – Optis / XCAL / Invex3G
If XCAL-DO or Invex3G - PC is used as the data collection tool then the right driver for the AT needs to
be installed in the laptop.
5.3 Data Collection Tool Setup
5.3.1 RNC Logging Setup
RNC logs should be collected for the following tests:

• A13 Dormant Session Handoff Shakedowns
• Cluster Drive Tests
Note: The timestamps given in RNC logs are based on GMT time. In order to correlate the RNC logs with
AT logs it will be necessary to adjust the RNC log timestamps according to the difference in local time and
GMT time.
For a fully loaded DO-RNC, there is one active System Controller on slot 7, one redundant SC on slot 9,
one hot swap SC on slot 10 and one hot swap redundant SC on slot 8. A single DO-RNC can have up to
four RNC-BIO modules and up to eight RNC-RNSM modules.
For a DOM, there is one BIO/SC module and one 1xEVDO modem. The 1xEVDO-Modem contains two
modules, Forward Link Processor Module (FLM) and Reverse Link Processor Module (RLM). Given that
call processing resources could be assigned to any cards in the RNC, logging has to be enabled on all the
cards (RNSM or SC) in the system.
Logging can be configured through the DO EMS or CLI to configure the logging system of each individual
card.
Logging Trap Severity
Within each hardware module that has a CPU, various software components generate all kinds of events.
The verbal description of these events is considered as “event messages”. Those “event messages” can be
selectively captured as a “log” by logging system of the module. The selective capturing functionality is
implemented by setting up a set of input traps which is also called “Severity”.
So in the end, the captured “logging messages” by the logging system are the subset of all event messages
generated by those software components within the hardware module. The EVDO system supports severity
levels from 1-32. For most events a severity level of 8 is all that is required. Other events like “Forward
Sector Switching” may require logging severity levels of 22.
The following is shows the components of an RNC log message:
Configure the Log File
Both the DO-RNC have there own logging manager where the logging manager is the means of
configuring the properties of the Log File. The log file itself is the actual captured log saved on the RNC
SC, RNSM or the DOM BIO/ SC cards.
Time Stamp
of the Date
CPU ID
Message ID
6-10-04 10:19:47.241 S=16 C=010301 F=0009 ID=0397 [0x3403ef (uati) SCSM
SCSM_Open] : Received Connection Opened Indication event
Message
Severity Level
Time Stamp of
hh:mm:ss.sss
Component ID
Message
Body
Time Stamp
of the Date
CPU ID
Message ID
6-10-04 10:19:47.241 S=16 C=010301 F=0009 ID=0397 [0x3403ef (uati) SCSM
SCSM_Open] : Received Connection Opened Indication event
Message
Severity Level
Time Stamp of
hh:mm:ss.sss
Component ID
Message
Body

• To configure the log files using the DO-EMS go to “Network Database” “DO-RNC” RNC
Menu Show Cards as shown below.
• Select the SC Card from the Cards Menu
• From the SC Card Menu select Show logfacilityMgr Modify Logfacility 5 (Call Control)
• The following boxes need to be configured in the Call Control Log facility Manager on the SC Card
o Logging Enabled = True
o Maximum Severity = 5, 8, 16, 22, 32, etc
o Output to File = On
o Maximum Severity on File = Maximum Severity entered above
DO-EMS RNC Menu

RNC Cards Menu
SC Card Menu
Log Facility Manager

Call Control Log Facility
Once all changes are made to the Call Control Log Facility Manager select Submit
To perform a severity level range selection, for example from 1 to 16 on call-control component do
the following from the CLI prompt:
NORTEL-07>en
NORTEL-07#config
NORTEL-07(config)#logging trap severity 16 call-control
To perform a set of individual severity levels selection, for example severity level 5, 9 and 16
on call-control component.
NORTEL-07>en
NORTEL-07#config
NORTEL-07(config)#logging trap severity fatal call-control
NORTEL-07(config)#logging trap severity 5 call-control +
NORTEL-07(config)#logging trap severity fatal call-control -
NOTE: To configure a set of individual severity level selection, users need to first specify a
range of severity setting then add each individual severity level one at a time with “+”. Finally,
users need to remove the first range severity setting with “-” sign.
To access those non-SC modules, users need first login into those SC modules. From there use
following procedure to access and configure the input traps on those modules.

NORTEL-07>en
NORTEL-07#config
NORTEL-07(config)#module-logging bio1/11/1
NORTEL-07(module-logging-bio1/11/1)#trap severity 16 resource-control
NORTEL-07>en
NORTEL-07#config
NORTEL-07(config)#module-logging rnsm1/13/1
NORTEL-07(module-logging-rnsm1/13/1)#trap severity 16 call-control
To Enable or disable logging from the CLI prompt do the following:
On RNC SC card for call-control component:
NORTEL-07>en
NORTEL-07#config
NORTEL-07(config)#logging start call-control (To enable log capture)
NORTEL-07(config)#no logging start call-control (To disable log capture)
Parsing and Retrieving Log Files
To parse the logs under RNC: (This step is not necessary if using NEWTUN)
NORTEL-07(config)#logging convert file <rnc_binary_log.bin> <rnc_output_file.txt>
No wild card supported under command line, so log need to be parsed one by one.
To check the log files under RNC:
NORTRL-07>shell
NORTRL-07(shell)(disk0)>cd logs
NORTRL-07(shell)(disk0)>ls (To view all the files under the logs directory)
To get the log the log files, users can use various FTP programs to access the log directory and then extract
those logs. Once those logs are download to users’ local hard drive, they can be viewed with any kind of
text file editor program.
For more detailed information on RNC logging see reference [4].
5.3.2 Optis-M Setup
Once the Optis-M GUI is installed, the user needs to do the following:
• Connect AC/DC Converter’s input connector to power source.
• Connect AC/DC Converter’s output connector to the Power supply connector on the front panel of
Optis-M.
• Connect Ethernet cable to Ethernet connector on the front panel of Optis-M and laptop.
• Turn on the Optis-M unit using the power switch on the front panel.
• Connect Mobile data cable to the USB port of each slot on the front of Optis-M.
• Connect GPS Antenna to the GPS Antenna connector on the front panel of Optis-M.
• Set the laptop IP address to the appropriate one (usually 1.1.1.1) so that it can communicate with
Optis-M box.
• Start the Optis-M software. Ensure that the client hardware status light (at the bottom right corner of
Optis-M window) is green.
• Configure the Optis-M ports. Below is an example for two Chesters connected to Optis-M.

Port Setting window in OPTis-M.
Phone Type setting under Port Settings window.

Data Port Configuration under the Port Settings window
• Set the log masks.
For more details on setting up Optis-M, please refer to [10].

5.3.3 Optis-M Log Masks
The log mask settings for the general 1xEV-DO data collection (e.g. cluster drive testing) are shown in the
pictures below. The 1xEV-DO log masks are always needed. The CDMA/1xRTT log mask is needed for
measurement with hybrid AT (e.g. for 1xEV-DO to 1xRTT handoff analysis).
For a specific testing or troubleshooting, different log masks may be needed.

OPTis-M 1xEV-DO log mask.

OPTis-M
CDMA/1xRTT
log mask setting.

5.3.4 Invex3G Chassis Setup
• Note: Invex3G Chassis, Release 4.3 / 4.4 should be provisioned with at least 2 DI (digital
communications interface) boards for EVDO optimization testing. The legacy CI boards are
processor limited which will have negative consequences when measuring data throughput
performance.
• Note: If Invex3G DI boards are not available at the commencement of optimization testing,
Invex3GPC or Wirelesslogix tools should be used to insure success.
Invex3G Chassis - Setup
• Connect the RJ45 Ethernet crossover cable from the System Controller Module (GWSC-0100) of the
Invex3G mainframe to the Network Interface Card of the Personal Computer (laptop) that will be used
to run the Invex3G software.
• Connect the GPS antenna to the GPS ANT connector on the mainframe.
• Insert the AT (PCMCIA) into the Digital Card Interface (DCI) Module or attach the AT to the
Communications Interface Card (CI) using the appropriate connector cable to the CI ports (STS-A and
STS-B).
Invex3G mainframe also charges all ATs that use the proprietary cable interface to the CI board.
The upper port (A) of the CI module supports Data and Voice application, and the lower port (B) is
reserved for Voice ONLY. Therefore if doing a data call, use ONLY the upper ports in the
Communication Interface (CI) Card.
Each CI port and DI card slot has dedicated LED Indicators (STS-A and STS-B) for status check:
• Green: Phone Attached - Normal
• Red: Fault
• Amber: Waiting
• Connect the power supply to the Invex3G unit.
DI Card Slot

• Open the start menu on the laptop and go to “My Network Places” or Network and Dial up
Connections” and select the “Local Area Connections” icon and then select properties.
• On the “General” tab go the Internet Protocol (TCP / IP) component and select “Properties”
• On the “General” tab select “Use the Following IP Address” and enter the following:
o IP Address – 192.168.3.100
o Subnet mask – 255.255.255.0
• Click OK and Close the Networking tab
• Power the laptop and the Invex3G unit. The unit can be powered either by connecting directly to the
cigarette lighter or using an inverter in the van.
• Once the software has been launched it is necessary to create new device connections if they were not
created beforehand.
o Click on the Connections tab in the workspace
o Click on the Connections folder icon and select “New” connection
o Next, the “add new connection” dialog appears. There are three options available for
connection configuration:
o Invex3G Chassis – specifies connection to the hardware mainframe
o Invex3G Serial Device – specifies connection to a device attached to
the PC (Invex3G-PC option)
o Select Invex3G default chassis option and then OK.
o Select “Connect All” from the workspace connections menu to open the connection to the
Invex3G chassis.
o After selecting connect all the “Open Connections” dialog begins. Click the Andrew
chassis name to highlight it and then click OK.

o The Invex connection status dialog box will open up to display the connection progress.
At the initial start up it may take several minutes for the chassis flash memory to update
so, be patient.
• Once the connection process is complete a list of devices attached to the chassis will be displayed in
the devices tree
5.3.5 InVex3G Log Masks
Configure Invex3G logs masks as follows for EVDO and CDMA log collection.
• Go to the “Devices” tab in the Invex3G workspace and right click on the collection device and
select properties. The following window will appear.

• Select the CDMA L3 and QCP 1xEVDO L3 tabs and click “Collect 1xEVDO Layer 3 Messages”
and “Collect CDMA Layer 3 Messages” boxes.
• Select the QCP 1xEVDO tab and then select all messages.
• Select the QCP1X tab and select all messages.
• For more information on Invex3G configuration see reference [18].
5.4 AT Log Data Post-Processing Tool Setup
5.4.1 RF Optimizer EV-DO
RF Optimizer EV-DO software can be downloaded from the link below:
http://navigate.us.nortel.com/imds?pg=/eng/wne/core/tool/cdma/rfoevdo
Then follow the installation procedure carefully. Once RFO is installed, attach a RFO dongle key and
launch RFO. Go to Tools Options to configure the tool:

• In the "File Locations" tab, be sure to select a location for "Extraction Logs" that you can easily locate
later. The extraction log accumulates many informative messages during raw processing. Since new
messages always get appended to the existing file, the file can become quite large. It's a good idea to
periodically delete the extraction log once you have reviewed its contents.
• When selecting locations for "Database Data Files", "Extraction Logs" or "Temporary Files", be sure
to select only folders to which you have full access rights, and on the drive that has plenty of available
space. These files, created by RF Optimizer EVDO during processing, can consume a significant
amount of disk space.
• In the "Binning" tab, set temporal and spatial bin sizes (the default setting of 1s and 100m is a good
starting point). Keep in mind that the smaller the bin sizes, the longer it will take RF Optimizer EVDO
to process the data, and the larger the resulting databases will be.
• In the "Processing Options" tab, it is strongly recommended to keep the "Delay..." option checked.
This will delay the Data Synchronization analysis for any log file, which can be very time consuming
due to the amount of data processed, until the first time you have a need to open the DRC Information
Viewer. Keeping this option checked will significantly save upfront processing time, compared to not
checking this option.
• You are ready to process data.
• Please keep in mind that by Microsoft's design, each of your database (MSDE) is limited to 2GB. Due
to the varying nature of raw data, it is not possible to predict how much database space each raw file

will take up after it is processed, so exercise caution and avoid processing too many files into one
single database. You are free to create as many databases as your hard drive can hold.
5.4.2 XCAP-DO
XCAP DO software also needs a dongle key to run. Once launched, click on Tools Options to configure
the tool. There are six tabs in the Options window, and most of the default values are good for typical use.
• General: contain settings for distance unit, message viewer option, sync option, etc.
• Path: select the directories for the log data (raw data), model (processed data), and exported data.
• Map: contains settings for map display.
• Map2: contains additional settings for map display (like shift offset).
• Graph: contains settings for graph display.
• CDF/PDF: contains options for CDF and PDF graph type, i.e. line or bar and 2D or 3D.
To process a log file (XCAP Do calls it “creating a new model”), click on File New:

• Sampling Interval: As in RFO, it is typically set to 1000 ms.
• Merge/Separate: If you select more than one file, and want to create one model for them (e.g. to get an
aggregate statistics from a cluster), then choose “Merge”. If you want to create a model for each file
separately, then choose “Separate”.
• Model Name: If you merge several files, you can choose a name for the merged model. If you choose
“Separate” then the model name is the same as the individual file name.
• Selective Parsing: If you want to process only certain messages, you can select them from here. For
example, if you are measuring RF coverage and not concerned about throughput, then you can uncheck
PPP Data and Throughput Info box.

5.5 DOM - RNC Log Post Processing Tools
Currently, RNC logs can be analyzed one of two ways; converting the logs to text and opening the resulting
logs with Excel, or to use NEWTUN to post process and analyze the logs in binary format.
5.5.1 Converting RNC Logs from Binary to Text
The binary to text file parser resides in the RNC SC and DOM card. To parse a DOM or RNC log, you
need to telnet into the DOM or the RNC. The following steps should be followed once logged into the
DOM or RNC to convert the binary data to text:
• Nortel-07> en
• Nortel-07# shell
• Nortel-07#(shell)(disk0:/)# cd logs
• Copy the filename of the log
• Nortel-07(config)# logging convert file <bin filename> <new text file name>
• After converting the file ftp it down to a PC for analysis.
5.5.2 NEWTUN (Post Processing and Analysis of RNC Logs)
NEWTUN (Nortel Engineering Wireless Tuning Tool) is a Windows based tool developed by Nortel’s
Wireless Tools group for processing and analyzing EVDO call statistics according to events captured in
RNC logs. NEWTUN is currently only a Beta release and is only available to select groups. To obtain a
license key please contact Tag Support. The processing of RNC logs with NEWTUN requires the input
files from the RNC to be in the raw *.bin or *.gz format (format prior to text conversion). During post
processing of the logs NEWTUN will convert the logs to a viewable format. NEWTUN will not read RNC
logs that are in *.txt format.
NEWTUN supports the following functionality in the current release:
• Call Performance statistics such as dropped connection and access failure rates,
• Call flow analysis in various states
• Call radius configuration tuner
• In the future it will support Neighborlist tuning and integration with EVDO editor output files
NEWTUN Setup Guidelines
When first starting NEWTUN, the user should ensure that the tool settings are configured as required.
File Locations

• It is recommended that the User save the Database files in a location where there is a lot of free
disk space available when processing large amounts of data.
• NEWTUN creates a number of temporary files during processing that may be large depending
upon the amount of data processed. These temporary files are cleaned up upon completion of
processing activities.
• To save browsing time, the user can setup default location of where the program should search for
raw binary logs.
Process Filtering

Filter Messages
• When checked the tool will only process Call Control messages
• Certain “useless” CC messages will also be excluded
Skip Files
Currently does nothing but will allow automatic removal of files with Severity levels lower than
required by call model analyzer.
Max Severity
• When calculating fail / drop statistics it is important that the log files are collected at the
appropriate severity level. Should the level be too low the tool will warn the user accordingly.
Database Creation
Raw data must be processed and stored into a database for post-analysis. To create a new database:
1. Open DataManager from Main Window Toolbar
2. Click New Database Tool button on Data Manager

3. Enter Name of new database
File Processing
NEWTUN processes raw binary Airvana RNC log files. For space reasons, the tool will accept gzipped
binary log files. To process Files
1. Create database for storing data
2. Highlight database to store processed data
3. Select files for processing
4. Add files to highlighted Database
5. Repeat steps 1 – 4 to batch up data as desired
6. Click Process Button

Once all files have been successfully processed, select the database of interest and click the Select
button.
By default, the statistics view will automatically be populated for post-analysis.
Notes
• When selecting data, all files within a database are automatically selected
• Files cannot be removed from a database.
• Clicking the delete button will remove the highlighted database
• Tool does NOT process RNC converted text files
Statistics Display
The statistics view is the main apparatus for displaying performance results and navigating throughout the
call messaging for debugging purposes.

The statistics displayed are based upon all the calls identified within the database selected from the data
manager.
Connection types
Two types of connections are defined within NEWTUN:
Session – Connections assisting with the configuration of a session startup
Data – Connections associated with the transfer of user data
How these connection types are determined is beyond the scope of this document. As mentioned in the
Known Issues section, break-up of connection types is not accurate and is undergoing improvements.
Call Classification Types
Name Description
Call Attempts Total number of Connection Attempts
Failed Access Connections that failed to acquire traffic channel
Dropped Calls Connections that dropped once on traffic channel
Border Dropped
Calls
Dropped calls that may be close to a border RNC region
Good Calls Calls that closed normally
Incomplete Access Calls that had no more messaging to indicate outcome of Access Attempt
Incomplete Traffic Call that had no more messaging to indicate whether call would terminate
successfully or not
Unknown Failures Calls that failed but had insufficient information to determine whether traffic was

1x evdo optimization_guide_v3.0_chr

1x evdo optimization_guide_v3.0_chr

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to 1x evdo optimization_guide_v3.0_chr

Similar to 1x evdo optimization_guide_v3.0_chr (20)

More from Phuoc Phuoc

More from Phuoc Phuoc (8)

1x evdo optimization_guide_v3.0_chr