EVDO Performance and Principle Guideline

CDMA EVDO Performance and
Principle Guideline
Contents
1 Preface........................................................................................................................9
1.1 About this Manual...................................................................................................................9
1.1.1 Purpose...........................................................................................................................9
1.1.2 Intended Audience.........................................................................................................9
1.1.3 Organization...................................................................................................................9
1.1.4 Revision History..........................................................................................................11
1.1.5 Reference Documentation............................................................................................12
1.2 Conventions...........................................................................................................................13
1.3 Acronyms and Abbreviations................................................................................................14
2 Basic Call Flows.......................................................................................................17

2.1 Basic Concepts......................................................................................................................17
2.2 HRPD Session.......................................................................................................................18
2.2.1 HRPD Session Establishment......................................................................................18
2.2.2 HRPD Session Keep Alive...........................................................................................20
2.2.3 HRPD Session Closing................................................................................................21
2.3 HRPD Connection.................................................................................................................25
2.3.1 HRPD Connection Establishment Initiated by the AT..............................................25
2.3.2 HRPD Connection Re-Activation Initiated by the AT..............................................27
2.3.3 HRPD Connection Re-Activation Initiated by the PDSN........................................28
2.3.4 HRPD Connection Release Initiated by the AT........................................................30
2.3.5 HRPD Connection Closing Initiated by the AN.......................................................31
2.3.6 HRPD Connection Closing Initiated by the PDSN...................................................32
2.4 Configuration Negotiation.....................................................................................................33
2.4.1 Basic Concepts.............................................................................................................33
2.4.2 Common Configuration Negotiation Parameters.........................................................35
2.5 Other Procedures...................................................................................................................37
2.5.1 Access Authentication..................................................................................................37
2.5.2 AT Originates Location Update....................................................................................38
2.5.3 AN Originates Location Update...................................................................................39
2.6 Related Traffic Statistic Indexes...........................................................................................40
3 Access Process and Silence.....................................................................................42

3.1 Access Process......................................................................................................................42
3.1.1 Access Channels...........................................................................................................42
3.1.2 Access Probe Structure................................................................................................43

3.1.3 Access Probe Sequence................................................................................................45
3.1.4 Related Parameters.......................................................................................................46
3.2 Reverse Silence.....................................................................................................................48
3.2.1 Reverse Link Silence...................................................................................................48
3.2.2 Access Probe Sending and Silence Period...................................................................49
4 Handoff Algorithm..................................................................................................51
4.1 Overview of Handoff Algorithm...........................................................................................51
4.2 Pilot Sets................................................................................................................................51
4.2.1 Management of Pilot Sets............................................................................................52
4.2.2 Pilot Search..................................................................................................................52
4.3 Forward Virtual Soft Handoff...............................................................................................56
4.3.1 Background..................................................................................................................56
4.3.2 Function Description....................................................................................................56
4.3.3 Virtual Soft Handoff Procedure...................................................................................57
4.3.4 Application Scenario and of Performance Description Algorithm..............................59
4.3.5 Traffic Statistic Indexes and Data Collection..............................................................59
4.4 Reverse Soft Handoff............................................................................................................60
4.4.1 Background..................................................................................................................60
4.4.3 Application Scenario and Performance Description of Algorithm..............................61
4.5 AN Assisted Inter-AN Handoff.............................................................................................64
4.5.1 Background..................................................................................................................64
4.6 1X - DO Handoffs.................................................................................................................68
4.6.1 Dormant Handoffs to 1x from EVDO.........................................................................69
4.6.2 Active Handoffs to 1x from EVDO.............................................................................70
4.6.3 Dormant Handoffs to EVDO from 1X.........................................................................70
5 Reverse Power Control Algorithm.........................................................................72

5.1 Overview of Reverse Power Control Algorithm...................................................................72
5.2 Reverse Open Loop Power Control......................................................................................73
5.3 Reverse Closed Loop Power Control....................................................................................73
5.3.1 Reverse Outer Loop Power Control.............................................................................74
5.3.2 Reverse Inner Loop Power Control.............................................................................75
5.4 Application Scenario and Performance Description of Algorithm........................................76

5.5 Traffic Statistic Indexes and Data Collection........................................................................76
5.5.1 Related Traffic Statistic Indexes..................................................................................76
5.5.2 Data Collection Methods.............................................................................................76
6 Reverse Load Control Algorithm...........................................................................81

6.1 Background...........................................................................................................................81
6.2 Function Description.............................................................................................................81
6.2.1 Reverse Maximum Rate Limit.....................................................................................82
6.2.2 RAB.............................................................................................................................82
6.2.3 Reverse Rate Transition Probability............................................................................84
6.2.4 Reverse Rate Control...................................................................................................85
6.3 Application Scenario and Performance Description of Algorithm........................................86
6.3.1 Use Recommendations.................................................................................................86
6.3.2 Product Version Support..............................................................................................86
6.4 Traffic Statistic Indexes and Data Collection........................................................................86
6.4.1 Related Traffic Statistic Indexes..................................................................................86
6.4.2 Data Collection Methods.............................................................................................87
7 Forward Data Transmission Algorithm................................................................89

7.1 Overview of Forward Data Transmission Algorithm............................................................89
7.2 Forward Rate Control............................................................................................................89
7.2.1 Background..................................................................................................................89
7.2.2 Basic Principle.............................................................................................................90
7.3 Abis Flow Control.................................................................................................................94
7.3.1 Background..................................................................................................................94
7.3.2 Basic Principle.............................................................................................................94
7.4 Air Interface Scheduling Algorithm......................................................................................95
7.4.1 Background..................................................................................................................95
7.4.2 Basic Principle.............................................................................................................95
7.4.3 Evaluation of Scheduling Algorithm...........................................................................96
8 Protocols Used in CDMA20001x EV-DO Tests...................................................100

8.1 Overview.............................................................................................................................100
8.2 FTAP...................................................................................................................................100
8.2.1 Function Description..................................................................................................100
8.2.2 Product Version Support............................................................................................101
8.2.3 Operation Description................................................................................................101
8.3 RTAP...................................................................................................................................106
8.3.1 Function Description..................................................................................................106
8.3.2 Product Version Support............................................................................................106

8.3.3 Operation Description................................................................................................107
8.4 FLUS...................................................................................................................................108
8.4.1 Overview of FLUS.....................................................................................................108
8.4.2 Application Scenario of FLUS...................................................................................109
8.4.3 Loading Method.........................................................................................................109
8.5 OUNS..................................................................................................................................109
9 Multi-Carrier Networking Strategy....................................................................110

9.1 Overview of Multi-Carrier Networking Strategy................................................................110
9.2 Network Selection after Power-on......................................................................................110
9.3 Hash Algorithm...................................................................................................................111
9.4 Hard Assignment.................................................................................................................112
9.5 Inter-Frequency Handoffs...................................................................................................112
Figures
Figure 2-1 HRPD session establishment procedure...................................................................18
Figure 2-2 HRPD session keep alive..........................................................................................20
Figure 2-3 AT initiates HRPD session closing (A8 connection established).............................21
Figure 2-4 AT initiates HRPD session closing (no A8 connection established).........................22
Figure 2-5 AN initiates HRPD session closing (A8 connection established)............................23
Figure 2-6 AN initiates HRPD session closing (no A8 connection established)........................24
Figure 2-7 AT initiates HRPD connection..................................................................................25
Figure 2-8 AT re-activates HRPD connection (dormant state)...................................................27
Figure 2-9 PDSN re-activates HRPD connection......................................................................28
Figure 2-10 AT releases the HRPD connection..........................................................................30
Figure 2-11 AN releases the HRPD connection.........................................................................31
Figure 2-12 PDSN closes the HRPD connection.......................................................................32
Figure 2-13 Session configuration negotiation..........................................................................34
Figure 2-14 Access authentication.............................................................................................37
Figure 2-15 AT initiates the location update...............................................................................39
Figure 2-16 AN initiates location update...................................................................................39
Figure 3-1 EVDO reverse channel structure..............................................................................42
Figure 3-2 ACH physical layer packet format............................................................................43
Figure 3-3 EVDO access probe structure 1................................................................................43
Figure 3-4 Access probe time.....................................................................................................44
Figure 3-5 EVDO access probe structure 2................................................................................45
Figure 3-6 EVDO access probe sequence..................................................................................45
Figure 4-1 Virtual soft (softer) handoff......................................................................................56
Figure 4-2 DRC handoff.............................................................................................................58
Figure 4-3 Reverse soft handoff.................................................................................................61
Figure 4-4 AN assisted inter-AN handoff..................................................................................65
Figure 4-5 Dormant handoff to 1X from EVDO........................................................................69
Figure 4-6 Dormant handoff to EVDO from 1X (no EVDO session).......................................70

Figure 7-1 Forward link adaptive rate control procedure...........................................................90
CDMA EV-DO Performance and Principle Guideline
Preface
1.1 About this Manual

1.1.1 Purpose
This manual depicts basic principle for Huawei CDMA 1x EVDO-related
performance. In terms of the whole flow, it emphasizes the practicability.
For the performance algorithm functions, it mainly introduces why we put
forth the functions, what the functions are, when we use the functions, and
how to evaluate the functions. In addition, it makes an overview of
performance-related concepts and the knowledge required in this manual.
1.1.2 Intended Audience

This manual is intended for Huawei engineers knowing the basic concepts of
CDMA 1x EV-DO system.
1.1.3 Organization
This manual addresses the EVDO session of CDMA Performance Manual and
is organized as follows:
Chapter 1 Preface - Is an introduction to the purpose, intended audience, and
organization.
Chapter 2 Basic Call Flows - Presents the basic concepts and procedure of
the HRPD session establishment, service negotiation, and authentication in
the CDMA2000 EV-DO system.
Chapter 3 Access Process and Silence Covers the access procedure and
principle of AT in the EVDO system and EVDO-specific reverse silence.
Chapter 4 Handoff Algorithm Introduces the pilot sets, virtual soft
handoff, reverse soft handoff, and AN-assisted handoff between ANs. In
addition, it makes an overview of interoperability specifications of dual-mode
terminal between 1x network and EVDO network.
Chapter 5 Reverse Power Control Algorithm Explains the principles for
EVDO reverse open-loop power control and closed loop power control.
Chapter 6 Reverse Load Control Algorithm Introduces the measurement
methods, control methods, and the algorithm for EVDO reverse load.
Chapter 7 Forward Data Transmission Algorithm Covers EVDOspecific forward rate control principle, Abis flow control mechanism, and the
scheduling algorithm for air interface multi-user time multiplexing.
Chapter 8 Test Applications introduces the testing calls for performance
evaluation tests and load simulation functions, including Forward Test
Application Protocol (FTAP), Reverse Test Application Protocol (RTAP),
Forward Link User Simulation (FLUS), and Other User Noise Simulator
(OUNS).
1.1.4 Reference Documentation
3GPP2 C.S0024 v4.0, cdma2000 High Rate Packet Data Air Interface
Specification, October, 2002
3GPP2 A.S0008-0 v3.0, Interoperability Specification (IOS) for High

Rate Packet Data (HRPD) Access Network Interfaces, May 2003.
CBSC6600V200R001Power Control Algorithm Top-Level Design,

Algorithm Development Team, 2003
CBSC6600V200R001Soft Handoff Algorithm Top-Level Design,

Algorithm Development Team, 2003
CL93-V3762-1 X1, RLMAC Algorithm for IS-856 (1xEV),

QUALCOMM
CL93-V3439-1 Rev. A, CSM5500 Drivers Virtual Handoff and

Related Parameters, QUALCOMM
80-H0230-1 Rev. B, RPC Power Allocation for IS-856 (1x EV-DO),

QUALCOMM
80-H0551-1 Rev. B, G-Fair Scheduler, QUALCOMM
Cdma2000 1xEVDO Air Interface Flow Analysis Report, Guo Shikui,

2003
AN Assisted 1X Active State Handoff to EVDO System Assistance

System Algorithm, Nie Jimin, 2004
C.S0032 Test Requirement Analysis Report, Sun Zhonghua, 2003
EVDO Scheduling Algorithm Analysis, Nie Jimin, 2003
FLUS Function Analysis Report, Gan Bin, 2003
Prediction-Based Reverse Load Control Algorithm, Nie Jimin, 2004
C.S0029 Test Call Protocol Analysis Report, Gan Bin, 2003
Scott340,Background and Introduction To 1xEV-DO Technology,2005
1.2 Conventions
This manual is not an operation guide to performance algorithms. Refer to the
Help on the maintenance system for the points for attention.
1. About Supported Versions
The product version support involved in this manual means the first release
supporting the functions and features described in the Function Description.
For example, in chapter 6 Reverse Load Control Algorithm,
V200R001C02B012 earlier does not support the feature, namely
V200R001C02B012 and above versions support the feature.
2. About Performance Description
It describes the benefits and potential negative effect of the performance
algorithms. There is no quantitative description, because the results vary with
the application environments.
3. About Performance Measurement Indexes and Data Collection
It mainly describes how to elevate performance-related traffic statistic indexes
and the performance data collection methods after the algorithm is used. The
measurement points of the indexes are not the importance of this manual. For
details, refer to the related traffic statistic indexes. This manual also does not
introduce the use of performance data collection methods. For details, see the
corresponding guidelines.
4. About Common Parameters
For the purpose of facilitating the use by the readers, this manual lists key
parameters and involved commands. For the operations and settings of the
parameters, see Performance Parameter Manual.
1.3 Acronyms and Abbreviations

Acronyms and
abbreviations
Full name
AAA
Authentication, Authorization and Account
AC
Asynchronous Capsule
ACK
Acknowledgement
AN
Access Network
ANID
Access Network Identifiers
ARQ
Automatic Request
BSC
Base Station Controller
BTS
Base Transceiver Station
CANID
Current Access Network Identifiers
CDMA
Code Division Multiple Access
DRC
Data Rate Control
DRS
Data Ready to Send
DSC
Data Source Control
ESN
Electronic Serial Number
FCP
Flow Control Protocol
FCS
Frame Check Sum
HARQ
Hybrid Auto Retransmission request
HDR
High Data Rate
HLR
Home Location Register
HRPD
High Rate Packet Data
IMSI
International Mobile Subscriber Identity
IOS
Inter-Operation Specification
MAC
Medium Access Control
MEI
Mobility Event Indicator
MNID
Mobile Node Identification
NAI
Network Access Identifier
NAK
Not Acknowledgement
NID
Network Identification
PANID
Previous Access Network Identifiers
PCF
Packet Control Function
PDSN
Packet Data Service Node
PDU
Packet Data Unit
PER
Packet Error Rate
PPP
Point-to-Point Protocol
PZID
Packet Zone Identification
QoS
Quality of Service
RA
Reverse Activity
RAB
Reverse Activity Bit
RATI
Random Access Terminal Identifier
RLMAC
Reverse Link MAC
RLP
Radio Link Protocol
RoT
Rise Over Thermal
RPC
Reverse Power Control
RRI
Reverse Rate Indicate
SID
System Identification
SINR
Signal Interference and Noise Ratio
UATI
Unicast Access Terminal Identifier
Basic Call Flows
2.1 Basic Concepts

The use of CDMA20001x EVDO for data services requires two types of
sessions:
HRPD session, namely air interface session
Packet data service session, namely PPP session
The CDMA20001x EVDO packet data session can be in three states: Active,
Dormant, and Idle.
In the active state, air interface connection, A8 connection, A10 connection,
and PPP connection are established between the AT and PDSN and can be
used for the data transmission.
In the dormant state, only A10 connection and PPP connection are established
between the AT and PDSN. At that time, if the data is sent, the air interface
connection and A8 connection must be established and dormant state is
transited to the active state.
In the idle state, no air interface connection, A8 connection, A10 connection,
and PPP connection are established between the AT and PDSN.
2.2 HRPD Session

2.2.1 HRPD Session Establishment
If the HRPD session is released because of the power-on or other reasons, it is
required to establish the HRPD session and connection and to negotiate the
related protocols and attributes for the data communication.
The attribute configuration of HRPD session negotiation takes effect only

when next connection is established. Therefore, the data communication
actually starts from the establishment of next connection.
Figure 1.1 HRPD session establishment procedure

The procedure of HRPD session establishment is as follows:
1.
The AT sends a UATIRequest message to the AN over the access

channel, requesting the AN to assign a UATI.
2.
The AN assigns the AT a UATI and sends it to the AT through the

UATIAssignment message.
3.
The AT updates the UATI and responds with a UATIComplete message

to confirm the completion of UATI assignment. At that time, the HRPD
session is established preliminarily, but if the normal communications
between the AT and the AN must be conducted, it is required to establish
the HRPD connection and to negotiate the protocols and attribute
configuration.
4.
The AT initiates the establishment of HRPD connection and establishes

forward and reverse traffic channels.
5.
The AT sends a ConfigRequest message over the traffic channel,

carrying the protocols and attributes to be negotiated.
6.
The AN responds with the negotiation result through a ConfigResponse

message to complete the negotiation of protocols and its attributes. If
necessary, repeat steps 5 and 6 for multiple times of negotiations.
7.
The AT sends a ConfigComplete message to the AN after the

negotiation.
8.
The AN sends a Key Exchange message to exchange the key with the
AT.
9.
The AN sends a ConfigRequest message to the AT if having contents to

be negotiated; otherwise, skip directly to step 12, and the AT initiates
HRPD connection closing.
10. The AT sends a ConfigResponse message. If necessary, repeat steps 9

and 10 for multiple negotiations.
11. The AN sends a ConfigComplete message to the AT after all the
necessary protocols and attributes are negotiated.
12. The AT or the AN initiates the HRPD connection closing to initialize the
protocols and configure attributes.
2.2.2 HRPD Session Keep Alive

Both AT and the AN can initiate the HRPD session keep alive.
If failing to receive any message from the receiver within TSMPClose /
NSMPKeepAlive (defaulted to 1080) minutes, the sender sends a
KeepAliveRequest message to the receiver and the receiver responds with a
KeepAliveResponse message.
Figure 1.1 HRPD session keep alive

I. Related Parameters
Parameter
Command
Description
Session
closing
timer
(TSMPCLOSE)
Modify: MOD DOGCNP

Query: LST DOGCNP
If the AT and the AN monitor no

service flow on the forward and
reverse channels within the
TSMPCLOSE, close the HRPD
session.
2.2.3 HRPD Session Closing

HRPD Session Closing Initiated by the AT (A8 Connection Established)
In the active state of HRPD session, if the A8 connection and A10 connection
are established, the AT initiates the HRPD session closing.
Figure 1.1 AT initiates HRPD session closing (A8 connection established)

The procedure of AT initiating HRPD session closing (A8 connection
established) is as follows:
1.
The AT sends a SessionClose message to the AN to initiate the HRPD

session closing.
2.
After closing the HRPD session with the AT, the AN sends an A9Release-A8 message (cause value=normal call release) to the PCF to
request the PCF to release the A8 connection.
3.
The PCF sends an A11-Registration Request message (Lifetime=0) to

request the release of A10 connection.
4.
The PDSN sends an A11-Registration Reply message (Lifetime=0) to

confirm the release of A10 connection.
5.
The PCF sends an A9-Release-A8 Complete message to the AN for

confirming the release of A8 connection to complete the HRPD session
closing.
HRPD Session Closing Initiated by the AT (No A8 Connection

Established)
In the dormant state, no A8 connection between the AN and the PCF is
established and the AT initiates the HRPD session closing.
Figure 1.1 AT initiates HRPD session closing (no A8 connection established)

The procedure of AT initiating HRPD session closing (no A8 connection
1.
2.
The AT sends a SessionClose message to the AN to initiate the HRPD

session closing.
After closing the HRPD session with the AT, the AN sends an A9Update-A8 message (cause value=power-off in the dormant state) to the
PCF to request the PCF to release the related resources and A10
connection.
3.

4.

5.
The PCF sends an A9-Update-A8 Ack message to the AN for

closing.
HRPD Session Closing Initiated by the AN (A8 Connection Established)

In the active state, A8 connection and A10 connection are established, but the
AN initiates the HRPD session closing due to some reasons (such as crosssystem handoff but A13 interface signaling transmission failure and renegotiation and re-authentication failures).
Figure 1.1 AN initiates HRPD session closing (A8 connection established)

The procedure of AN initiating HRPD session closing (A8 connection
1.
The AN sends a SessionClose message to the AT to initiate the HRPD

session closing.
2.
The AT responds with a SessionClose message to the AN to confirm the

HRPD session closing.
3.
After closing the HRPD session with the AT, the AN sends an A9Release-A8 message (cause value=normal call release, other cause
values include transition to dormant state, handoff success, equipment
failure, and authentication failure) to the PCF to request the PCF to
release the A8 connection.
4.

5.

6.
The PCF sends an A9-Release-A8 Complete message to the AN for

closing
HRPD Session Closure Initiated by the AN (No A8 Connection

Established)
In the dormant state, no A8 connection is established.
If the HRPD session expires or configuration negotiation, key exchange and
CHAP authentication fails, the AN initiates the HRPD session closing.
Figure 1.1 AN initiates HRPD session closing (no A8 connection established)

The procedure of AT initiating HRPD session closing (no A8 connection
1.
The AN sends a SessionClose message to the AT to initiate the HRPD

session closing.
2.
The AN responds with a SessionClose message to the AN to confirm the

HRPD session closing.
3.
After closing the HRPD session with the AT, the AN sends an A9Update-A8 message (cause value=power-off in the dormant state) to the
PCF to request the PCF to release the related resources.
4.

5.

6.
The PCF sends an A9-Update-A8 Ack message to the AN for

confirming the release of related resources to complete the HRPD
session closing.
2.3 HRPD Connection

2.3.1 HRPD Connection Establishment Initiated by the
AT
When the AT has data to send, the AT initiates the establishment of HRPD
connection. It is assumed that the HRPD session is already established and the
access authentication passes.
Figure 1.1 AT initiates HRPD connection
The procedure of AT initiating HRPD connection is as follows:

1.
The AT sends a ConnectRequest+RouteUpdate message to the AN over

the access channel to request the AN to assign a traffic channel.
2.
The AN sends a TrafficChannelAssignment message to the AT to notify

the AT of pilots in the active set and the channels to be monitored.
3.
The AT switches to the AN-specific channel and responds with a

TrafficChannelComplete message to complete the traffic channel
establishment.
4.
The AN sends an A9-Setup-A8 message (DRI=1) to the PCF to request

the PCF to establish the A8 connection.
5.
After assigning the resources for A8 connection, the PCF sends an A11Registration Request message to the PDSN.
6.
After establishing the A10 connection, the PDSN sends an A11Registration Reply message to the AN to confirm the establishment of
A10 connection.
7.
The PCF sends an A9-Connect-A8 connection to the AN to confirm the

successful establishment of A8 connection.
8.
The AT or the PDSN sends a PPP-LCP Negotiation message to

negotiate mainly the size of PPP data packet and core network
authentication type (such as CHAP).
9.
The AT or the PDSN sends a PPP-IPCP Negotiation message to

negotiate mainly the upper-level protocols and assignment of IP
addresses.
10. After the LCP and IPCP are negotiated, the PPP connection and session
between AT and the PDSN complete. At that time, the data can be sent
through the PPP connection.
2.3.2 HRPD Connection Re-Activation Initiated by the

AT
In the dormant state, if the AT has data to send, the AT re-activates the PPP
connection between the AT and the PDSN.
Figure 1.1 AT re-activates HRPD connection (dormant state)

The procedure of AT re-activating HRPD connection is as follows:
1.
The PPP session between the AT and the PDSN is in dormant state.
2.
If
the
AT
has
data
to
send,
the
AT
sends
ConnectRequest+RouteUpdate message to the AN to request the AN to

assign a traffic channel.
3.
The AN sends a TrafficChannelAssignment message to the AT to notify

the AT of forward channel to be monitored.
4.
The AT switches to the AN-specific forward channel and sends a

TrafficChannelComplete message to the AN to establish the forward
and reverse traffic channels.
5.
The AN sends an A9-Setup-A8 message (DRI=1) to the PCF to request

the PCF to establish the A8 connection.
6.
After establishing the A8 connection, the PCF sends an A11Registration Request message to the PDSN.
7.
After establishing the A10 connection, the PDSN sends an A11Registration Reply message to confirm the establishment of A10
connection.
8.
The PCF sends an A9-Connect-A8 message to the AN to confirm the

establishment of A8 connection. At that time, the PPP connection is reactivated.
2.3.3 HRPD Connection Re-Activation Initiated by the

PDSN
In the dormant state, when the PDSN has data to send, the PDSN notifies AN
of re-activating the HRPD connection and activates the PPP connection.
Figure 1.1 PDSN re-activates HRPD connection

The procedure of PDSN re-activating HRPD connection is as follows:
1.
The PPP session between the AT and the PDSN is in dormant state.
2.
The PDSN sends a Packet Data Traffic message to the PCF to indicate
that the network side has data to send to the AT and to request the PCF to
establish the air interface connection.
3.
The PCF sends an A9-BS Service Request message to the AN to request

the AN to activate the HRPD session and establish the HRPD
connection.
4.
The AN responds with an A9-BS Service Response message.
5.
The AN sends a Page message to the AT over the control channel.
6.
The AT sends a ConnectRequest+RoouteUpdate message over the

access channel as a response to the Page message to request the AN to
assign the AT forward and reverse traffic channels.
7.
After assigning the AT forward and reverse traffic channels, the AN

sends a TrafficChannelAssignment message to the AT to notify the AT
of the channels to be monitored.
8.
The AT switches
to
the
AN-specific
channel
and
sends
TrafficChannelComplete message to the AN to establish the forward

and reverse traffic channels.
9.
The AN sends an A9-setup-A8 message (DRI=1) to the PCF to request

the PCF to establish A8 connection and the AT initiating the release of
HRPD connection.
10. After establishing A8 connection, the PCF sends an A11-Registration

Request message to the PDSN to trigger the accounting.
11. After establishing the A10 connection, the PDSN responds with an A11Registration Reply message to confirm the connection establishment.
12. The PCF sends an A9-Connect-A8 message to the AN to confirm the
establishment of A8 connection. At that time, the PPP connection is reactivated.
2.3.4 HRPD Connection Release Initiated by the AT
Figure 1.1 AT releases the HRPD connection

The procedure of AT releasing the HRPD connection is as follows:
1)
After the traffic data packet is sent, the AT sends a Connection Close message
over the reverse traffic channel to initiate the release of air interface connection.
2.
The AN sends an A9-Release-A8 message (cause value=Packet Call

Going Dormant) to request the release of A8 connection.
3.
The PCF sends an A11-Registration Request message to the PDSN and

sends an Active Stop accounting record.
4.
The PDSN responds with an A11-Registration Reply message to the

PCF.
5.
The PCF sends an A9-Releaase-A8 Complete message to the AN to

confirm the release of A8 connection. At that time, A10 connection for
this call is retained.
2.3.5 HRPD Connection Closing Initiated by the AN
Figure 1.1 AN releases the HRPD connection

The procedure of AN releasing the HRPD connection is as follows:
1)
The AN sends an A9-Release-A8 message (cause value= Packet Call Going

Dormant) to the PCF to request the release of A8 connection.
2)
The PCF sends an A9-Release-A8 Complete message to the AN to confirm the

release of A8 connection.
3)
The AN initiates the release of air interface connection. If necessary, this step
may occur in parallel with steps 1 and 2.
2.3.6 HRPD Connection Closing Initiated by the PDSN
Figure 1.1 PDSN closes the HRPD connection

The procedure of PDSN closing the HRPD connection is as follows:
1)
The PDSN sends an A11-Registration Update message to the PCF to request

the release of PPP connection between the PDSN and the AT.
2.
The PCF responds with an A11-Registration Ack message to the PDSN.
3.
The PCF sends an A11-Registration Request message to the PDSN to

4.
The PDSN responds with an A11-Registration Reply message to the

PCF.
5.
The PCF sends an A9-Disconnect-A8 message to the AN.
6.
The AN sends an A9-Release-A8 (cause value= Normal Call Release)

message to the PCF to request the release of A8 connection.
7.
The PCF sends an A9-Release-A8 Complete message to the AN to

8.
The AN sends a ConnectionClose message to the AT to request the

release of air interface connection.
9.
The AT sends a ConnectionClose (CloseReply) message to the AN to

confirm the release of air interface connection.
2.4 Configuration Negotiation

2.4.1 Basic Concepts
EVDO air interface has seven layers. Each layer includes some mandatory
and optional protocols.
When the AT is powered on and establishes a HRPD session with the AN, it is
required to negotiate the parameters involved in the protocols with the AN. If
the negotiated parameters are changed, the configuration negotiation occurs.
The configuration negotiation when the HRPD session is established initially
is initiated first by the AT after the UATI is assigned the AT. After the AT
completes the negotiation, the AN starts the negotiation.
Each parameter to be negotiated in the protocols has a default value. When the
AT and the AN use default values, it is not required to initiate a configuration
negotiation procedure to reduce the time and link bandwidth caused by the
configuration negotiation.
Figure 1.1 Session configuration negotiation

The originator provides the receiver with a list of receivable values for each
attribute through a ConfigRequest message. The receiver provides the originator
with a list of received values for each attribute through a ConfigResponse
message.
The received attribute values are selected from the list of receivable attribute values
of the originator.
The originator prioritizes the receivable values for each attribute in a descending
sequence. After receiving a ConfigRequest message, the receiver should respond
within TTurnaround (2s).
After completing all the configuration negotiations, the originator sends a
ConfigComplete message.
2.4.2 Common Configuration Negotiation Parameters

Protocol
Parameter
Packet application
configuration negotiation
Whether to allow the AT to automatically the

location update (RANHANDOFF)
Session protocol
Session closure timer (TSMPCLOSE)
Forward traffic channel

MAC protocol
Soft handoff delay (SFTHODLY)

Softer handoff delay (SFTERHODLY)
DRC channel continuous transmission flag
(DRCGATING)
DRCLock bit transmission interval
(DRCLOCKPERIOD)
DRCLock bit repeat times
(DRCLOCKLENGTH)
Reverse traffic channel

MAC protocol
Reverse rate transition probability

(TransitionProbability)
Reverse power control step (RPCSTEP)
Reverse traffic channel nominal power offset
(RTRAFDATAOFF)
Access channel MAC

protocol configuration
negotiation
Maximum times of AT single access probe

sequence (PRBSEQMAX)
Inter-probe backoff (PRBBKOFF)
Inter-probe sequence backoff
(PRBSEQ_BKOFF)
Access channel nominal power offset
(ACCDATAOFF)
Route update protocol

Pilot good available threshold (PILOTADD)

Pilot compare difference (PILOTCMP)
Pilot lowest available threshold (PILOTDROP)
Pilot drop timer (PILOTDROPTIMER)
Maximum AGE of neighbor set (NBRMAXAGE)
Search window size of active set and candidate
set (SRCHWINA)
Search window size of neighbor set
(SRCHWINN)
Search window size of remaining set
(SRCHWINR)
Pilot PN sequence increment
(PILOTINCREMENT)
Whether to use dynamic threshold
(DYNAMICTRESHINC)
Soft handoff add slope (SOFTSLOPE)
Pilot add intercept of soft handoff
(ADDINTERCEPT)
Pilot drop intercept of soft handoff
(DROPINTERCEPT)
2.5 Other Procedures

2.5.1 Access Authentication
Figure 1.1 Access authentication

The procedure of access authentication is as follows:
1)
The HRPD session between the AT and the AN is established, including the
procedures for UATI assignment, session configuration negotiation, and DH
key exchange.
2.
The AT sends an OpenRequest message to the AN to open the AN

stream. The AN responds with an OpenResponse message to open the
AN stream.
3.
The PPP and LCP negotiation between the AN and the AT is conducted,
mainly for the size of PPP data packet and authentication protocol type
(such as CHAP). Generally, the AN configures CHAP authentication
protocol type and initiates access authentication.
4.
The AN sends a CHAP-Challenge

authentication random) to the AT.
5.
After receiving the CHAP-Challenge message, the AT uses the MD5

algorithm to calculate the authentication result based on the
authentication random, and sends a CHAP-Response message to the
AN. The message includes the access authentication parameters, such as
NAI and CHAP-Challenge.
6.
After receiving the CHAP-Response message sent from the AT, the AN
sends an A12-Access Request message (including the authentication
parameters, such as NAI, CHAP-Challenge, and AN-IP) to the AN-AAA.
7.
According to the authentication parameters (such as NAI and

CHAPassword) in the A12 access request message, the AN-AAA uses
the MD5 algorithm to calculate the authentication result and compares
whether the result is consistent with the authentication result reported by
the AT. If the two authentication results are consistent, the AN-AAA
responds with an A12-Access Accept message to permit the AT to access
the EVDO network. in addition, the MNID (or IMSI) is returned with the
message; otherwise, the AN-AAA responds with an A12-Access Reject
message to reject the AT to access the EVDO network. If the
authentications password is null, the AN discards directly the A12Access Request message.
8.
If the AN-AAA permits the AT to access the EVDO network, the AN

acquires the IMSI by analyzing the attribute field of A12-Access Accept
message, and then sends CHAP-Auth Success message to the AT;
otherwise, the AN sends directly CHAP-Auth Failure message to the
AT.
9.
If the CHAP authentication passes, the air interface PPP connection is

established; otherwise, air interface PPP connection is released.
message
(including
the
2.5.2 AT Originates Location Update

When RANHandoff=0x01 in the configuration attributes and the AT detects
the location change (such as ANID, PZID, SID, and NID), the AT initiates
automatically the location update.
Figure 1.1 AT initiates the location update

The procedure of AT initiating the location update is as follows:
1)
The AT sends a LocationNotification message to the AN to notify the AT of

storing the ANID.
2.
The AN responds with a LocationAssignment message to notify the AT

of updating the ANID as the configuration of existing system.
3.
The AT notifies the AN of completing the ANID update through a

LocationComplete message.
2.5.3 AN Originates Location Update

After the HRPD session establishment completes or dormant handoff between
the ANs is conducted, the AN initiates automatically the location update.
Figure 1.1 AN initiates location update

The procedure of AN initiating the location update is as follows:
1)
The AN sends a LocationRequest message to query the ANID stored by the

AT.
2.
The AT responds with a LocationNotificaton message to the AN to send

the ANID stored by the AT.
3.
The AN sends a LocationAssignment message to the AT to notify the

AT of updating the ANID as the configuration of existing system.
4.
The AT notifies the AN of updating the ANID through the

LocationComplete message.
2.6 Related Traffic Statistic Indexes

Item
Function set
Description
HRPD session
setup requests
HRPD
session
performance
measurement
Measurement when the AN receives a

UATIRequest message
HRPD session
setup
success
times
HRPD
session
performance
measurement

UATIComplete message
Access
authentication
attempts
HRPD
session
performance
measurement
Measurement when the AN sends an

A12 Access-Request message to the AN
AAA
Access
authentication
success times
HRPD
session
performance
measurement
Measurement when the AN receives an

A12-Access-Accept message from the
AN AAA
Access
authentication
denies
HRPD
session
performance
measurement

A12 Access-Reject message from the
AN AAA
AT/AN-initiated
connection
requests
EV-DO
connection
performance
measurement
set

ConnectionRequest message from the
AT or
the AN receives a
ConnectionRequest message from the
AT as a response with the Page message
AT/AN-initiated
connection
success times
EV-DO
connection
performance
measurement
set

A9-Update A8 Ack message from the
PCF during the ATinitiated connection
setup or the AN receives an A9-Update
A8 Ack message during the connection
setup (including fast connection setup)
Fast connection
requests
EV-DO
connection
performance
measurement
set
Measurement when the AN receives the

fast connection initiated through the A9BS Service Request message
Fast
setup
success times
EV-DO
connection
performance
measurement
set

A9-Update A8 Ack message during the
fast connection setup
Access Process and Silence
3.1 Access Process

3.1.1 Access Channels
EVDO reverse channel includes access channel and reverse traffic channel, as
shown in Figure 1.1.
The access channel consists of preamble and access data (namely probe). The
AT sends a Request or Response message to the AN on the access channel.
Figure 1.1 EVDO reverse channel structure
Figure 1.2 shows the ACH physical layer packet format.
The net load of MAC layer is 234bits and the physical layer encapsulates
22Bits, totaled 256Bits.
Figure 1.2 ACH physical layer packet format

The ACH physical layer packet encapsulates 256bits, with the frame length of
26.66ms, so the physical layer packet rate on the data channel of ACH is
256/26.667=9.6Kbps.
Access Probe Structure
Access procedure consists of single or multiple access probes and access
probe consists of ACH prefix and multiple ACH data packets.
In each access probe, the pilot (I-channel) with PreambleLength frame
(namely PreambleLength 16 timeslots) is sent first as the preamble and then
the probe data (Q-channel) with at most CapsuleLengthMax 16 frames.
Figure 1.3 EVDO access probe structure 1

The access channel period represents the time when the AT may start an
access probe.
Figure 1.4 Access probe time

Figure 1.4 shows that in the EVDO network, the access period can be
overlaid.
The most significant 8 bits in 42 bits in the ACH long code mask are regarded
as the AccessCycleNumber, representing different system time.
The number of access cycles of terminals is different with each other, so the
access probe of different terminals starts and ends at different time. This
reduces the access collision probability.
For the prefix part, only pilot channel is sent. For the data part, both the pilot
channel and data channel are sent. The access preamble consists of two
frames. The value of the access pilot can be set by the parameter
PreambleLength.
Figure 1.5 EVDO access probe structure 2

In the access frame, the total power is assigned to data and pilot channels.
During the preamble portion of an access probe, the output power of the pilot
channel is higher than it is during the data portion, such that the total output
power of the preamble and portions of the access probe are the same.
Access Probe Sequence
Figure 1.6 EVDO access probe sequence

A persistent test must be performed by AT before it starts the access sequence,
which is used to control the request rate of MS. The congestion caused by
multiple users attempting to access the same sector is avoided this way. If the
persistent test succeeds, the probe sequence can be sent in the current access
channel cycle.
A probe sequence contains several access probes. After the AT transmits an access
probe, it waits for a random time defined as p. If the AT does not receive any
response from the system during this interval, the power levels of subsequent
probes in the sequence are increased by the increment extracted from the
PowerStep parameter. Then it transmits next probe. The AT does not send the
next probe until one of the following conditions is met:
The AT receives an ACAck message.
AT receives the deactivation command and stops the transmission.
Each sequence transmits ProbeNumStep probes (maximum number of

probes).
p = TACMPATProbeTimeout + (y * AccessCycleDuration)
s = TACMPATProbeTimeout + (k * AccessCycleDuration)
In the formulas,
ACMPATProbeTimeout: indicates the access probe wait response timer,

which is 128 timeslots.
Y and K: are uniformly distributed random integers between 0 and the

Access Channel Probe Backoff parameter value. (ProbeBackoff indicates
the backoff time of a probe. The length is normally four access channel
cycles.)
AccessCycleDuration: indicates the duration of the access cycle, which is

generally 64 timeslots.
During the access probe sequence, a persistent test based on its AT class is
performed by all Ats. If the test succeeds, the AT transmits its next probe
sequence.
Related Parameters
Parameter
Command
Description
Access probe duration

(ACYCLEDURATION)
Modify: MOD
DOAPM
The AT must send a new

access probe when the system
time (T) is an integral multiple
of the Access Cycle duration.
Query:
DOAPM
Access probe preamble
frame length (PRBLEN)
LST
Modify: MOD
DOAPM
Query:
DOAPM
LST
Access
channel
maximum
capsule
length
(CAPSULELENMAX)
Modify: MOD
DOAPM
AT open loop power

estimation
(OLOOPADJUST)
Modify: MOD
DOAPM
Open-loop
power
estimation
correct
factor
(PRBINIADJUST)
Modify: MOD
DOAPM
Maximum access probe

number
(PRBNUMSTEP)
Modify: MOD
DOAPM
Probe
power
(PWRSTEP)
Modify: MOD
DOAPM
step
Query:
DOAPM
Query:
DOAPM
Query:
DOAPM
Access persist vector
0/1/2/3(PERSISTENCE
0/1/2/3)
Maximum capsule length of

the access data
LST
LST
LST DOAPM
Query:
DOAPM
Length of each access probe

preamble of the MS.
LST
LST
Modify: MOD
DOAPM
The AT uses this parameter to

estimate mean open-loop
output power of pilot channel
of access probe
This parameter is used to
output
power
with
ATOpenLoopPowerEstimation
.
Maximum number of the
access probes in one access
sequence.
Power increment between two
successive
access
probes
accessed by the MS in the
same access sequence.
APersistence value used by an
AT with class 0/1/2/3 for
persistence test before sending
Query:
DOAPM
LST
AT
Acess
ProbeSequenceMax
(PRBSEQMAX)
Modify: MOD
DOMCNP
ProbeBackoff
(PRBBKOFF)
Modify: MOD
DOMCNP
Query:
LST
DOMCNP
Query:
LST
DOMCNP
ProbeSequenceBackoff
(PRBSEQ_BKOFF)
Modify: MOD
DOMCNP
Query:
LST
DOMCNP
OffsetNormalPower of
Access
Channel
(ACCDATAOFF)
Modify: MOD
DOAPM
Access macro division

switch
(ACCMACRODIVSWI
TCH)
Modify: MOD
DORRMMP
Query:
DOAPM
LST
Query:
LST
DORRMMP
the first probe.

The access network shall set
this field to the maximum
number of probe sequences for
a single access attempt.
The time bias of each access
probe during the access of an
access terminal (AT) is used
for calculating the start time of
the next access probe.
The access network shall set
this field to the upper limit of
the backoff range (in units of
AccessCycleDuration) that the
access terminal is to used for
calculating the start time of the
next probe sequence.
This parameter is used to
output
power
with
ATOpenLoopPowerEstimation
.
Switch for accessing macro
diversity.
This
parameter
determines whether to access
macro diversities.
3.2 Reverse Silence

Reverse Link Silence
EV-DO supports reverse link silence function.
The following parameters are delivered by the SectorParameters message:
ReverseLinkSilencePeriod
ReverseLinkSilenceDuration
In the designated period, all the ATs under a sector stops reverse transmission
and access probe for a certain period of time. The system can measure and
update the noise floor in the sector during this period. The data is used as the
basis of reverse load control.
The reverse link silence duration is a period starting from T and lasting for a
time defined by ReverseLinkSilenceDuration, where T must meet the
following requirement:
T mod (20482ReverseLinkSilencePeriod-1) = 0
Access Probe Sending and Silence Period
When the AT sends the first probe sequence, the link silence period test must
be performed before the persistence test. The AT determines the reverse link
silence period and duration according to the sector parameter message.
At the beginning of the access channel cycle, if the transmission of the access
probe and the reverse link silence period does not overlap, the AT is allowed
to send the access probe. Otherwise, the AT must wait for the next access
channel cycle that meets the requirements.
In a probe sequence, when the AT sends an access probe, it waits for a time
lasting for p. After this access probe is completed, the new probe starts from
timeslot p. If any of its part overlaps with the reverse link silence period, the
AT regenerates a pseudo random number in [0, ProbeBackoff] (ProbeBackoff
is the backoff time of the probe, it is normally four access channel cycles),
and then re-calculates p. If it does not overlap with the reverse link silence
period, the AT uses the timeslot p to send the next access probe within this
timeslot p after the previous access probe completes.
Related Parameters
Parameter
Command
Description
ReverseLinkSilenceInt
ervalDuration
(RLSDURATION)
Modify:
DOSPM
MOD
Query:
DOSPM
LST
ReverseLinkSilencePe
riod (RLSPERIOD)
Modify:
DOSPM
MOD
Query:
DOSPM
LST
Silence duration of the

reverse
link
silence
interval
The interval of AT added
into the reverse silence
state successively
Handoff Algorithm
4.1 Overview of Handoff Algorithm

The 1xEV-DO reverse link differs from 1X in that 1xEV-DO does not have
fundamental and supplemental channels (FCH and SCH). EVDO reverse link
has R-FCH at different rates and adopts the technology similar to the 1X soft
handoff, to maintain different pilot sets.
The forward channel adopts Time Division Multiplex technology and
transmits at full power. Correspondingly the forward channel uses a new
virtual soft handoff technology with which one specific carrier serves for an
AT at the same time on the forward link. This improves the peak throughput
of a single subscriber.
This chapter describes the intra-PDSN handoffs, without the inter-PDSN
handoffs of mobile IP.
4.2 Pilot Sets

Similar to 1x reverse plot sets, the EVDO reverse pilot sets are categorized as
Active Set, Candidate Set, Neighbor Set, and Remaining Set.
Management of Pilot Sets
Active set and candidate set management
The AT supports a maximum Active Set or Candidate Set Size of six pilots.
If any one of the following conditions is met, the AT adds the pilot to the
Candidate set:
The pilot is not in Active Set or Candidate Set, and the pilot strength
exceeds the threshold specified by PilotAdd.
The pilot is deleted from Active Set. The Pilot Drop timer has expired
and the value of DynamicThresholds is 1, and the pilot strength
exceeds the threshold specified by PilotDrop.
The pilot is deleted from Active Set but its Pilot Drop timer is not
expired.
If any one of the following conditions is met, the AT deletes the pilot from
Active Set:
The pilot is added to the Active Set.
The Pilot Drop timer has expired.
Neighbor set management

The AT supports a maximum Neighbor Set Size of 20 pilots.
Remaining set management
The AT initializes the Remaining Set to contain all the pilots whose PN
offsets index is an integer multiple of PilotIncrement and are not already
members of any other set.
4.2.1 Pilot Search

The access terminal shall continually search for pilots in the Connected State
and whenever it is monitoring the Control Channel in the Idle State. The access
terminal shall search for pilots in all pilot sets. This search shall be governed
by the following rules:

Search priority
The AT should use the same search priority for pilots in the Active set and
Candidate set. In descending order of search rate, the AT shall search, most
often, the pilots in the Active set and Candidate Set, then shall search the
pilots in the Neighbor Set, and lastly shall search the pilots in the Remaining
Set.
Search window size
The AT shall use the search window size specified by the configurable
attribute SearchWindowActive for pilots in the Active Set and Candidate Set.
For each pilot in Neighbr Set, in Connected state, the AT shall use the search
window size specified by the SearchWindowSize in the NeighborList
message, and in Idle state, the AT shall use the search window size specified
by the NeighborSearchWindowSize in the SectorParameters message. If
NeighborList message and SectorParameters message do not configure the
search window size, the AT shall use the search window size specified by
SearchWindowNeighbor field of the corresponding neighbor structure in the

RouteUpdateNeighobrList. The AT shall use search window size specified by
configurable attribute SearchWindowRemaining for pilots in the Remaining
Set.
Search window center
The access terminal should center the search window around the earliest
usable multipath component for pilots in the Active Set. The access terminal
should center the search window for each pilot in the Neighbor Set around the
pilots PN sequence offset plus the search window offset specified by
SearchWindowOffset field of the corresponding Neighbor structure in the
RouteUpdateNeighborList using timing defined by the access terminals time
reference. The access terminal should center the search window around the
pilots PN sequence offset using timing defined by the access terminals time
reference for the Remaining Set. The access terminal should center the search
window around the pilots PN sequence offset using timing defined by the
access terminals time reference for the Remaining Set.
Related Parameters
Parameter
Command
Description
ROUTEUP
(RouteUpdateRaiu
s)
Modify:
DOSPM
MOD
Query:
DOSPM
LST
PilotAdd
(PilotAdd)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
Modify:
DOCNP
MOD
Query:
DOCNP
LST
Modify:
DOCNP
MOD
Query:
DOCNP
LST
PILOTDROP
PilotCompare
Distance threshold on which the

AT performs a location update.
The unit is second. When the AT
moves to a new coverage area, it
computes the distance R between
the current area and the area
where it last sends a Route
Update message.
When the pilot strength exceeds
the threshold, the pilot can be
added to Active Set.
When the pilot strength in the
Active Set or Candidate Set is
smaller than the threshold, AT
enables the PilotDrop timer.
When the pilot strength in
candidate set is this parameter
value higher than that in active
set, the AT sends a RouteUpdate
message.
PILOTDROPTIM
ER
(PilotDropTimer)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
NBRMAXAGE
(NeighborMaxAg
e)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
PILOTINCREME
NT (Pilot PN
sequence
increment)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
SRCHWINA
(search window
size of active set
and candidate set)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
SRCHWINN
(search window
size of neighbor
set)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
SRCHWINR
(Search window
size of remaining
set)
Modify:
DOCNP
MOD
Query:
DOCNP
LST
If the pilot strength is smaller

than PILOTDROP, the AT
enables the timer. After the timer
expires, for the pilot in the active
set, the AT sends a RouteUpdate
message. For the pilot in
candidate set, the AT moves this
pilot to neighbor set.
The AT has a counter for each
pilot in the neighbor set. When
the AT receives a NeighborList
message, all counters of the
original pilots in the adjacent set
increases by 1. If the counter
exceeds this parameter, the pilot
is removed from the neighbor set.
The access network shall set this
field to the pilot PN sequence
increment, in units of 64 PN
chips that access terminals use
this parameter to search for the
Remaining Set.
Search window size used for AT
searching pilots in the active set
and candidate set.
The AT uses the search window
size defined in this parameter to
search for the carriers in the
neighbor set.
The AT uses the search window
size defined in this parameter to
search for the carriers in the
remaining set.
4.3 Forward Virtual Soft Handoff

Background
The EV-DO adopts a forward handoff algorithm that is different from the soft
handoff performed in IS95, namely, virtual software handoff.
On the 1x EV-DO forward link, the AT receives data from only one sector in
the active set. The DRC reported from an active AT informs the AN of C/I as
its best serving sector for data receiving. This is called virtual soft handoff.
The CDMA2000 1xEV-DO virtual soft handoff differs significantly from the
CDMA2000 1X soft handoff. In the CDMA2000 1X handoff, the MS can
receive data simultaneously from two or more sectors to obtain soft handoff
gain. In the CDMA2000 1xEV-DO virtual soft handoff, however, the AT can
receive data from only one sector and therefore cannot obtain soft handoff
gain.
Figure 1.1 Virtual soft (softer) handoff
4.3.2 Function Description

Through the virtual soft handoff, the AT analyzes the pilot signals it receives
and chooses the forward sector whose pilot signal has the highest C/I value.
This is the major function of the virtual soft handoff.
Searching for the Best Pilot Signal
On the forward link, pilot signals are sent in each slot. The searcher of the AT
quickly searches the entire band class for the pilot signal that has the highest
C/I value.
Choosing the Forward Serving Sector
The AT uses the DRC channel to choose the forward serving sector. The DRC
channel is also used to inform the AN of the highest forward data rate that the
current forward signal quality supports. The following two types of
information are sent on the DRC channel:
DRC Value (four bits): informs the AN of the expected receiving rate.
DRC Cover (three bits): informs the AN of the forward sector whose
pilot signal has the highest C/I value.
Virtual Soft Handoff Procedure

This section illustrates the virtual soft handoff procedure with an example. In
this example, the C/I value of the pilot signal in sector 2 becomes better than
that of the pilot signal in sector 1, and the forward traffic channel (FTC) shifts
from sector 1 to sector 2.
Figure 1.1 DRC handoff

The procedure of DRC handoff is as follows:
1.
The AT directs the DRC to a sector of BTS1. The BTS1 is current

activation cell.
2.
The BTS1 requests forward data from the BSC.
3.
The BSC sends forward data packets to the BTS1.
4.
The BTS1 sends forward data frames to the AT through the air interface.
5.
The AT directs the DRC to a sector of BTS2.
6.
After the BTS2 receives the DRC channel information from the AT, it
indicates that the AT hopes to receive data from the AT if the DRCCover
matches. The BTS2 requests the BSC to send forward data to the AT.
7.
If the DRCCover of DRC channel information received by the BTS1

from the AT is null cover, it indicates that the AT hopes to stop receiving
data from the BTS. The BTS1 notifies the BSC of stopping receiving
forward data sent to the AT.
8.
After switching the forward data sent to the AT to the BTS2 from BTS1,
the BSC notifies the BTS1 of clearing the forward data not sent to the
AT.
9.
When BTS2 turns into the current activation cell, the BSC sends forward
data packet to the BTS2.
10. The BTS2 sends forward data frame to the AT through air interface.
4.3.3 Application Scenario and of Performance

Description Algorithm
Application scenario
Virtual soft handoff is basic characteristic of 1xEV-DO.
Performance
Through the virtual soft handoff, the AT dynamically chooses the sector that
currently has the best radio operating environment. In this way, the virtual soft
handoff maximizes the forward throughput of the AT and raises the spectrum
utilization in the entire system.
In the virtual soft handoff, however, data transmission on the forward link is
interrupted for a moment. Therefore, frequent virtual soft handoffs reduce the
forward throughput of the AT and lower the spectrum utilization in the system.
Product version support
BSC
BSC6600 V200R001C02 and later
BTS
BTS3612 V200R001C03 and later

Traffic Statistic Indexes and Data Collection
None
The data collection methods are:
The RFMT assigns the IMSI tracing to record the number of the active
set, forward pilot strength, and DRC Cover. The granularity is 2 seconds.
The BTS assigns the IMSI call tracing to record the PER, handoff status,
forward power, reverse RSSI in each leg. The granularity is 2 seconds.
Related Parameters
Parameter
Soft handoff delay
(SFTHODLY)
Command
Modify:
DOMCNP
Query:
Description
MOD
LST
This parameter is
shortest
interruption when
the source sector
the expected
transmission
the AT shifts
to the target
DOMCNP
Softer
handoff
delay(SFTERHO
DLY)
sector during the virtual soft

handoff.
Modify:
DOMCNP
MOD
Query:
DOMCNP
LST
This parameter is
shortest
interruption when
the source sector
sector during the
handoff.
the expected
transmission
the AT shifts
to the target
virtual softer
4.4 Reverse Soft Handoff

4.4.1 Background
The reverse soft handoff in the CDMA2000 1xEV-DO network is the same as
the soft handoff in the CDMA2000 1X network. In both the types of soft
handoff, more than one sector can simultaneously receive signals from the
same AT, and the AN selectively combines the reverse signals from different
sectors to implement receiving gain on the reverse link.

Like in the IS2000 network, the AT has the following three defined types of
pilot set in the CDMA2000 1xEV-DO network:
Active set
Candidate set
Remaining set
Only sectors in the active set can receive and demodulate reverse signals from
the AT. The pilot sets are maintained through the RouteUpdate message. The
function of the RouteUpdate message is similar to that of the Pilot Strength
Measurement message in the CDMA2000 1xEV-DO network. The AT reports
the RouteUpdate message according to the current radio operating
environment, and the AN determines the active set according to the radio
operating environment information reported by the AT..
Figure 1.1 Reverse soft handoff

Application Scenario and Performance Description of Algorithm
The reverse soft handoff is a basic feature of the CDMA2000 1xEV-DO.
Performance Description
Through the reverse soft handoff, the AN obtains receiving gain and reduces
its transmit power, thus causing less interference to the system. In this way,
the call quality is improved, and the system capacity is expanded. The reverse
soft handoff, however, is implemented at the cost of physical resources such
as CE resources. Therefore, frequent reverse soft handoffs may reduce the
utilization of system resources.
BSC
BTS

4.4.3 Traffic Statistic Indexes and Data Collection

Performance Index
Measurement Subset
Description
Intra-BS Soft HO
requests EV-DO[Times]
EV-DO Reverse Channel

Soft-Handoff Performance
Measurement
Number of intra-BS soft

handoff (HO) requests for
adding legs and deleting
legs
Successful Intra-BS Soft

HO EV-DO[Times]

Measurement
Number of successful
intra-BS soft HOs for
adding legs and deleting
legs
Intra-BS Soft HO
Failures (Radio resources
unavailable) EVDO[Times]

Measurement

HO failures resulting from
radio resources
unavailable in the target
cell
Intra-BS Soft HO
Failures (Requested Abis
resources unavailable)
[Times]

Measurement

requested Abis resources
unavailable
Intra-BS Soft HO
Failures (Radio interface
abnormal)[Times]

Measurement

radio interface abnormal
Intra-BS Soft HO
Failures (Other causes)
[Times]

Measurement

causes other than the
following:
Intra-BS Soft HO
Failures (Radio
resources unavailable)
EV-DO [Times]
Intra-BS Soft HO
Failures (Requested
Abis resources
unavailable) [Times]
Intra-BS Soft HO
Failures (Radio
interface abnormal)
[Times]
Sent TCA for Intra-BS

Soft HO[Times]

Measurement
Number of traffic channel

assignment (TCA)
messages sent for intra-BS
soft HOs
RLP Octets Received on

Reverse Channels[KB]
EV-DO Service Data

Throughput Measurement
Total data that the BSC

receives on the RLP sublayer
The data can be collected in the following methods:
he RFMT assigns the IMSI tracing to record the number of the active set,
pilot strength, and DRC Cover. The granularity is 2 seconds.
The BTS assigns the IMSI call tracing to record the reverse PER,
handoff status, forward power, reverse RSSI in each leg. The granularity
is 2 seconds.
The CDR records the handoff events that occur during calls.
4.4.4 Related Parameters

Refer to the parameters of the pilot sets.
4.5 AN Assisted Inter-AN Handoff

4.5.1 Background
In some cases, for example, when the AT moves out of the coverage area of
the current subset, the AT needs to shift from the source AN to the target AN.
This process consists of the following steps:
1.
1. The AT sets up connection with the target AN and originates a

CDMA2000 1x EV-DO session setup process.
2.
2. Meanwhile, over the A13 interface, the target AN requests the

information about the session in the source AN from the source AN. The
following two situations may occur:
If the source AN saves the requested information, it verifies the

validity of the session and then sends the information to the target
AN.
If the requested information cannot be retrieved, or the source AN

cannot authenticate the request form the target AN, the source AN
sends a rejection message to the target AN. After target AN receives
the rejection message, the target AN verifies the validity of the AT
through the AN AAA.
3.
After the target AN receives the information, the target AN and the AT
complete the setup of the session according to the current conditions.
4.
The target AN sends a confirmation message to the source AN.
5.
The target AN sets up a connection with the target PCF through the A8
interface, and the target PCF sets up a connection with the PDSN
through the A10 interface.
6.
The PDSN starts the closure procedure to cut off the A10 connection
between the PDSN and the source PCF.
If the information to be queried cannot be searched, or the source AN cannot

verify the requests of target AN, the source AN sends a Rejected message to
target AN. After receiving the Rejected message, the target AN verifies the AT
immediately over AN AAA to verify its validity.
Figure 6.1 AN assisted inter-AN handoff

The procedure is as follows:
1.
The setup of the air interface link is started.
2.
The target AN queries relevant information from the source AN.
3.
The source AN sends the requested information to the target AN.
4.
The air interface link is set up.
5.
The location update is implemented.
6.
The target AN sends an acknowledgement message to the source AN.
7.
The A8 connection is set up at the target side.
8.
The A10 connection is set up at the target side.
9.
The PDSN releases the A10 connection at the source side.
10. The A8 connection is released at the source side.

11. The air interface link is released at the source side.

Current product versions do not support the inter-AN soft handoff. Therefore,
when the AT moves to the border of the source AN, the AT:
Releases the connection with the source AN
Shifts to the target AN in the dormant state
Sets up connection with the target AN.
If only the AT releases the connection, the following indexes may be affected:
Subscriber throughput: The AT may be far away from the source AN and
close to the target AN, and the signals from the target AN cause forward
interference to the AT. In this case, though the connection between the
AT and the source AN is still maintained, the AT requests a relatively low
rate from the source AN, the probability of the AT being scheduled by the
source AN is low, and the throughput of the AT is affected.
Sector throughput: The source AN assigns low rates for subscribers that
are on sector borders, so the throughput of the sector may be reduced.
The AN-assisted inter-AN handoff is a controllable function. In this function,

the target AN assists in the AT releasing the connection with the source AN.
When the pilot strength of another BSC in the reported neighboring set
information reaches a specific level, the AN originates the release of the
connection with the source AN, and the source AN assists the AT in the
release.
Application Scenario and Performance Description of Algorithm
The AN-assisted inter-AN handoff is originated when the AT needs to shift
from the source AN to the target AN, for example, when the AT moves beyond
the coverage area of the current subnet.
Performance
The target AN assists in releasing the connection with the source AN. When
the pilot strength of another BSC in the reported neighboring set information
reaches a specific level, the AN originates the release of the connection with
the source AN, and the source AN assists the AT in the release. In this way, the
reduction in the AT throughput and sector throughput is remedied.
BSC
BTS

4.5.3 Traffic Statistic Indexes and Data Collection

Item
HRPD Session Released
from AN(Source AN
release in inter AN
handoff)[Times]
Function set
HRPD Session
Performance
Measurement-BSC
Description
Number of HRPD session
releases that the source AN
initiates due to inter-AN
handoffs
The data can be collected in the following methods:
The RFMT assigns the IMSI tracing to record the number of the active
set, forward pilot strength, and DRC Cover. The granularity is 2 seconds.
The BTS assigns the IMSI call tracing to record the reverse PER,
handoff status, forward power, reverse RSSI in each leg. The granularity
is 2 seconds.
The CDR records the events that occur during calls.

Parameter
ANHOSWITCH
ANHOCOMP
Command
Description
Modify:
DORRMMP
MOD
Query:
DORRMMP
LST
Modify:
DORRMMP
MOD
Query:
DORRMMP
LST
Whether to allow the ANassisted inter-AN handoff
The handoff is triggered

when the maximum pilot
strength of another AN
exceeds that of the current
AN and the difference is
greater than the value of this
parameter.
4.6 1X - DO Handoffs
Generally, the CDMA2000 EV-DO network is built on the basis of the
CDMA2000 1X network. The CDMA2000 EV-DO network covers hotspot
areas, and its coverage area is smaller than the original CDMA2000 1X
network. So there are handoffs between 1x and DO in some special areas.
When the dual-mode terminal moves across the border between the 1X-only
area and the common area of the 1X and DO networks, three types of handoff
may occur:
Dormant Handoffs to 1x from EVDOError: Reference source not found
Active Handoffs to 1x from EVDO
Dormant Handoffs to EVDO from 1XError: Reference source not found
The dual-mode terminal does not support 1X-to-EV-DO active state handoff,
because the dual-mode terminal does not search for DO signals when it is in
the 1X active state.
4.6.1 Dormant Handoffs to 1x from EVDO
Figure 1.1 Dormant handoff to 1X from EVDO

The procedure of dormant handoff to 1X from EVDO is as follows:
1.
The AT switches to 1X frequency and sends an Origination message

(DRS=0) to the target PCF, and sends the ANID of source PCF.
2.
The target BSC/PCF responds with a BS Ack Order message.
3.
The target PCF sends an A11-Registration Request message to the

PDSN to request A10 connection establishment. The value of PANID
filed in the message is the ANID sent through the Origination message.
4.
The PDSN sends an A11-Registration Reply message to the target PCF

to confirm the A10 connection establishment. At that time, the dormant
handoff to 1X from EVDO completes.
5.
The PDSN sends an A11-Registration Update message to the source

PCF to initialize the release of A10 connection.
6.
The source PCF sends an A11-Registration Ack to confirm the release

of A10 connection.
7.
The source PCF sends an A11-Registration Request message

(Lifetime=0) to the PDSN to request the release of A10 connection.
8.
The PDSN responds an A11-Registration Reply message to confirm the

4.6.2 Active Handoffs to 1x from EVDO

The hybrid terminal does not support active handoff to 1X from EVDO.
When the dual-mode terminal in active state leaves EVDO network or the EVDO
signals are weak but 1X signals strong, the terminal transits to EVDO dormant state
first if searching the 1X network, and then initiates dormant handoff (see section
4.6.1).
Finally, the terminal initiates a re-activation on the 1X network.
4.6.3 Dormant Handoffs to EVDO from 1X
Figure 1.1 Dormant handoff to EVDO from 1X (no EVDO session)

The procedure of dormant handoff to EVDO from 1X is as follows:
1.
When detecting no air interface session, the target AN initiates the UATI
assignment and session configuration negotiation and establishes the air
interface session with the AT.
2.
The AT sends an OpenRequest message to the AN to open the AN

stream. The AN responds with an OpenResponse message to open the
AN stream.
3.
The PPP and LCP negotiation between the AN and the AT is conducted,
mainly for the CHAP authentication protocol type.
4.
The target AN generates an authentication random, which is sent to the

AT with a CHAP-Challenge message. After calculating the
authentication result, the AT sends the authentication result to the target
AN through a CHAP-Response message.
5.
The target AN sends the authentication parameters, such as

authentication random, authentication result reported by the AT, and ANI
to the AN-AAA through an A12 Access-Request message.
6.
The AN-AAA uses the MD5 algorithm to calculate the authentication

result and compares whether the result is consistent with the
authentication result reported by the AT. If the two authentication results
are consistent, the AN-AAA responds with an A12-Access Accept
message.
7.
After receiving the A12-Access Accept message, the target AN notifies

the AT of authentication success by sending a CHAP-Auth Success
message.
8.
If the target AN supports the location update, update the ANID of the AT
or restore the PANID through the ANID sent by the AT. This step may
occur anywhere after step 1.
9.
The AT notifies the target AN of AT ready to exchange data on service

stream. The flow control protocol is in Open state.
10. The target PCF sends an A11-Registration Request message to the

PDSN to request A10 connection establishment.
11. The PDSN returns an A11-Registration Reply message to confirm the
A10 connection establishment.
12. The PDSN sends an A11-Registration Update message to the source
PCF to initiate the release of A10 connection.
13. The source PCF sends an A11-Registration Ack message to confirm the
14. The source PCF sends an A11-Registration Request message
(Lifetime=0) to the PDSN to request the PDSN to release the A10
connection.
15. The PDSN responds with an A11-Registration Ack message to confirm
the release of A10 connection.
If the AT is already registered in the EVDO network (HRPD session
established), omit steps 1-7. Other steps are the same.
Reverse Power Control Algorithm
5.1 Overview of Reverse Power Control Algorithm

The CDMA system is a self-interfering system, because different subscribers
in the system use the same frequency at the same time. In actual applications
of the system, spread spectrum codes used in the system are not absolutely
orthogonal, and interference is caused between different subscribes. Each
code division channel in the system is subject to interference from other code
division channels. This type of interference is the inherent interference of the
system.
Different subscribers are at different distances from the BTS, so the signals
that the BTS receives from different subscribers are different in strength. With
the same transmit power, the signals from subscribers close to the BTS cause
great inference to subscribers far from the BTS, and the strong signals may
completely drown the weak signals. To solve this problem, the system
implements the reverse power control, which acts on the AT.
There are the following two types of reverse power control:
Reverse open loop power control
Reverse closed loop power control
The reverse closed loop power control is further divided into the following
types:
Reverse outer loop power control
Reverse inner loop power control
Through the reverse power control, the terminal adjusts the transmit power at
any time so that the terminal transmits at the minimum power and minimizes
the interference to other subscribers.
5.2 Reverse Open Loop Power Control

The reverse open loop power control enables the transmission attempts to be
demodulated by the BTS with the lowest possible power. This algorithm
estimates the reverser transmit power based on the forward transmit power.
The AT starts the open loop power control in the initial attempt sub state when
it accesses the network. When the AT originates an access attempt, it estimates
the power X0 of the first access attempt according to the strength of the
received forward signals. The following formulas are defined::
X0 = Average received power Rx(dBm) + OpenLoopAdjust +

ProbeInitialAdjust
Xi = X0 + (i 1) PowerStep
The parameters OpenLoopAdjust, ProbeInitialAdjust, and PowerStep come

from the AccessParameter message.
The power of the access data channel is described through its offset from the
power of the access pilot channel. The offset is determined by the parameters
DataOffsetNom and DataOffset9k6.
Data Rate(kbps)
Data Channel Gain Relative to Pilot (dB)
(Data Channel Is Not Transmitted)
9.6
DataOffsetNom + DataOffset9k6 + 3.75
5.3 Reverse Closed Loop Power Control

When the AT enters the connected state, the reverse closed loop power control
starts to take effect. This type of power control corrects the errors caused by
the reverse open loop power control. The reverse outer power control adjusts
the power control threshold (PCT) to maintain the SNR of the received
reverse pilot signals so that the PER is maintained at an acceptable level.
The reverse closed loop power control acts on the reverse pilot channel. The
powers of the reverse traffic channel, DRC channel, and ACK channel are
determined by their offset from the power of the reverse pilot channel. The
power of the reverse traffic channel is described through parameters
DataOffsetNom, DataOffset9k6, DataOffset19k2, DataOffset38k4,
DataOffset76k8, and DataOffset153k6.
Data Rate (kbps)
Data Channel Gain Relative to Pilot (dB)
(Data Channel Is Not Transmitted)
9.6
19.2
38.4
76.8
153.6
The offset of the reverse DRC channel from the reverse pilot channel is
determined by the parameter DRCChannelGain, and the offset of the reverse
ACK channel from the reverse pilot channel is determined by the parameter
ACKChannelGain.
5.3.1 Reverse Outer Loop Power Control

In the reverse outer loop power control, the AT has the following four states:
Inactive
The AT is dormant. No active data is sent, and no reverse power control is
implemented.
Normal
The reverse traffic channel is active, and reverse data is sent. The system
adjusts the PCT according to each reverse frame. When a good frame is
received, the PCT is reduced by a small step; when a bad frame is received,
the PCT is increased by a large step.
No Data
No reverse data is sent, but the AT is not dormant. The AT enters the no data
state when it stops reverse for about 0.5s. No outer power control feedback is
available. In the no data state, the reverse link of the AT may become bad. The
PCT gradually increases so that new reverse data to be transmitted when the
AT is in this state can be correctly demodulated. This algorithm, however,
defines the following two parameters to prevent the PCT from becoming
excessively high:
- The maximum increment of the PCT in the no data state
- The maximum PCT in the no data state.
Data Start
The data start state is a transitional state when data transmission is started in
the no data state. This state is an interim state between the no data state and
the normal state. In the data start state, when a good frame is received, the
PCT quickly drops to counteract the PCT increase in the no data state.
5.3.2 Reverse Inner Loop Power Control

The reverse inner loop power control is implemented in the BTS. The
frequency of the reverse inner loop power control is 600 Hz. The PCT set by
the outer loop power control is sent to the BTS through the forward traffic
frames over the Abis interface. The BTS compares the received PCT of the
reverse pilot signals with the target PCT. If the former is less than the latter,
the BTS requires the AT to raise its transmit power; if the former is greater
than the latter, the BTS requires the AT to reduce its transmit power. The BTS
sends power control bits to the AT through the forward RPC channel. When
the power control bit 0 represents raise the power by one RPC step. The RPC
step can be 0.5dB or 1dB, defined in the Power Parameters property table
when the reverse traffic channel implements the MAC protocol negotiation.
When the AT is in the process of a softer handoff, the power control bits of all
the legs are the same; when the AT is in the process of soft handoff, if the
power control bits of the legs are not the same, and the RPC in one leg is 1,
the AT reduces its transmit power.
5.4 Application Scenario and Performance

Description of Algorithm
This is a basic CDMA2000 EV-DO function, applicable to all CDMA2000
EV-DO networks and terminals.
Performance
Currently, PCT minimum value is -21dB by default and target FER is 1%. In
the labs, the test finds that FER is not converged but remains a low level
(0.1%-0.2%). The FER is converged to 1% only when the PCT minimum
value is -21dB.
All the V200R001 products support this function.
5.5 Traffic Statistic Indexes and Data Collection

5.5.1 Related Traffic Statistic Indexes
None
5.5.2 Data Collection Methods

The data collection method of this function is as follows:
The RFMT assigns the IMSI tracing to record the total number of
received reverse frames, the number of frame errors, and the status of 75
successive frames.
The BTS interference tracing implements a 30s periodic report and a 2s

periodic report. These reports record the RSSI of the EV-DO reverse
active set, the leg status, the target Ec/Io values of different reverse rates,
and the current Ec/Io and Eb/Nt.
Related Parameters
Parameter Name
Command
Remarks
REVPER
Modify: MOD DOPCP
Target
reverse
PER.
This
parameter is the
convergence target
of the reverse PER
in
normal
conditions.
Query:
LST
DORRMP:
DORRMINF=DOPCP;
MINPCT
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
MAXPCT
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
INITPCT
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
NORMALGFRAMED
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
This
is
the
minimum value of
the PCT adjusted
by the outer loop
power control.
This
is
the
maximum value of
the PCT adjusted
by the outer loop
power control.
This is the initial
value of the PCT
adjusted by the
outer loop power
control.
The up step length
of the PCT when
normal frames are
received in the
Normal state.
NORMALBRAMEU
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
NODATAIFRAMEU
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
NODATAMAXINC
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
NODATAMAX
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
DATAGFRAMED
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
PCTMININCSTEP
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
PCTMINCHANGE
Modify: MOD DOPCP

Query:
LST
DORRMP:
DORRMINF=DOPCP;
NUMIDLEFORNOD
ATA
Modify: MOD DOPCP
RPCSTEP
Modify: MOD DOMCNP
Query:
LST
DORRMP:
DORRMINF=DOPCP;
Query: LST DOMCNP
The down step

length of the PCT
when bad frames
are received in the
Normal state.
The up step length
of the PCT in the
No Data state.
Maximum increase
of the PCT in the
No Data state.
Maximum value of
the PCT in the No
Data state.
The down step
length of the PCT
when
normal
frames are received
in the Data Start
state.
Maximum interval
between successive
PCT
increases
when bad frames
are received.
Maximum change
in the PCT when
the inner loop
object is updated.
Number
of
successive
Idle
frames required for
the AT to enter the
No Data state.
Step length of the
AT adjusting the
reverse pilot power
according to the
reverse
power
control bits.
RTRAFDATAOFF
Modify: MOD DOMCNP

Query: LST DOMCNP
DRCChannelGain
Modify: MOD DOMPP

Query: LST DOMPP
ACKChannelGain
Modify: MOD DOMPP

Query: LST DOMPP
Nominal
power
offset of the reverse
link data (traffic)
channel.
This
parameter is used
for measuring the
power of the traffic
channel.
Offset
of
the
reverse
DRC
channel from the
reverse
pilot
channel
Offset
of
the
reverse
ACK
channel from the
reverse
pilot
channel
Reverse Load Control Algorithm
6.1 Background
The CDMA system is a self-interfering system. On the reverse link, the
transmit power of each AT is interference to other ATs. The reverse noise floor
increases with the increase of the number of reverse active subscribers. The
increase of the noise forces each AT to raise its transmit power to ensure that
the signals that reach the BTS has proper Eb/Nt and FER. If the reverse load
control is not implemented, the transmit power of the AT and the reverse
background noise keep on increasing, and the quality of the reverse link
deteriorates. When the power of the AT reaches its maximum value, and the
interference problem persists, the FER quickly increases. This results in voice
call drops and data service failures.
For the CDMA2000 EV-DO, high-speed data transmission of forward
services requires the quality of the reverse link reach a certain level, because
information such as the ACK and DRC information directly affects the
forward transmission rate in the CDMA2000 EV-DO system. Therefore, it is
essential tp implement the reverse load control in the CDMA2000 EV-DO
system. The reverse load control ensures that the reverse interference is kept
in a reasonable range. The reverse load control aims to strike a balance
between the service quality and the reverse capacity.
6.2 Function Description

The CDMA2000 EV-DO reverse load control algorithm includes the reverse
rate control of the AT. The reverse load control is implemented in the BTS,
and the reverse load control (or reverse rate control) is implemented through
the following three methods:
ReverseRateLimit Message
ReverseActiveBit
Reverse Transition probabilities
Reverse Maximum Rate Limit

The AN sends the following two types of reverse rate limit messages on the
common channel when the AT accesses the network or on the dedicated
channel when the dedicated channel is set up:
BroadcastReverseRateLimit
UnicastReverseRateLimit
These two types of reverse rate limit messages are intended to limit the
maximum rate of the AT. The BroadcastReverseRateLimit message is
broadcast to all the ATs that just access the network in the sector, and the
reverse maximum rate is specified in the message.
The UnicastReverseRateLimit message can be unicast to a specific AT at any
time to change the maximum rate limit of this AT. This message can be used
for implementing QoS-based reverse load control.
Currently, Huawei products support only the UnicastReverseRateLimit
message that is sent to the AT only when the AT accesses the network.
6.2.1 RAB
The RAB is sent by the AN to the AT through the forward RA channel. The
RAB has two states, namely 0 and 1. If the RAB is 1, the AT reduces its rate
by one level according to the reverse rate transfer probability; if the RAB is 0,
the AT raises its rate by one level according to the reverse rate transfer
probability. The CDMA2000 EV-DO reverse load control determines the
value of the RAB according to the current load.
The following two items are used to measure the load: RoT (Rise of Thermal)
and L(Load).
Rise of Thermal (RoT)
The RoT is defined by the following formula:
ROT ( dB ) RSSI ( dBm) Thermal noise floor(dBm)
In the formula, the RSSI is the sum of the strength of received reverse signals.
The RSSI is measured every 100ms at the BTS side, and the average RSSI in
1s is reported. The thermal noise floor is the background noise of the
measured thermal noise.
Load
This is a non-dimension value. The maximum value is 16384. This value is
calculated by the CSM5500 chip of the CECM in the BTS according to the
following data:
Number of active reverse subscribers
Reverse rate
Strength of received signals
The ratio of this value to 16384 is equivalent to the load level presented in the
percentage form.
The RoT and the L are equivalent to each other, and their relations can be
shown through the following equation:
ROT 10 log(
1
)
1 L .
Currently, Huawei products can use eight methods to measure the RAB,
namely the RoT, Load, RSSI, and different combinations of these three
values. The RoT is recommended for the measurement of the load.
There are the following threes methods to update the background noise:
Use the lowest noise as the background noise
Use the RSSI when there are no subscribers recently as the background
noise
Set the same silent cycle and silent duration for all the ATs in the sector.
All the ATs stop transmission during that period, and the system
measures the background noise.
This method is unique to the CDMA2000 EV-DO system, but it does not
prove effective in the laboratory, because ATs cannot enter the silent state at
the same time, and the background noise fluctuation is too great to be of much
reference value. In this method, an initial background noise value must be
configured. When the updated RSSI is less than the initial value, use the initial
value as the current RSSI.
The following two parameters affect the RAB:
RABLength: indicates the number of slots in which an RAB is

repeatedly sent on the RA channel.
RABOffset: indicates the offset when the RAB is sent. This parameter is
set differently in neighboring sectors.
6.2.2 Reverse Rate Transition Probability

The reverse rate transition probability is negotiated when the AT accesses the
network. The reverse rate transition probability includes the probability of hopping
between neighboring rate levels. When the AT receives the RAB, the AT picks a
random value between 0 and 1, and then compares this random value with the
probability of the hopping to the neighboring high rate level or low rate level. If the
former is less than the latter, the AT maintains the current rate; if the former is
greater than the latter, the AT makes this judgment till it receives the next RAB.
Currently, the reverse rate transfer probability is the optimal value recommended
by Qualcomm.
Parameter
Recommended
value (1/255)
Probability of AT transiting the rate from

9.6kbps to 19.2kbps
48
16
19.2kbps to 38.4kbps


19.2kbps to 9.6kbps
16

16

32

255
6.2.3 Reverse Rate Control

The ultimate reverse rate of the AT is determined by the following factors:
Reverse maximum rate limit
RAB
Reverse rate transfer probability
When the AT accesses the network, the BTS informs the AT of the maximum
rate it can reach through the reverse rate limit message. Meanwhile, the BTS
informs the AT of the reverse rate transfer probability. The BTS determines
the current RAB according to the current reverse load and reverse load control
algorithm, and then the BTS delivers the current RAB to the AT. Then AT
determines whether to raise or reduce the rate by one level.
After the AT accesses the network, when the received RAB is 0, the AT raises
the rate by one level or keeps it unchanged, contingent on the transfer
probability. When the received RAB is 1, the AT reduces the rate by one level
or keeps it unchanged. If the AT is in the soft handoff state in the reverse
direction, the RABs delivered are handled through the OR method, that is, the
AT reduces the rate if one or more RABs are 1.
When the AT accesses the network, the reverse rate is limited to 9.6 kbps.
When it receives the first BroadcastRRL or UnicastRRL message, the AT
configures the reverse rate according to the value specified in the RateLimit
message. According to the received RAB, the AT adjusts the reverse rate
within a range permitted by its transmit power.
If the received RAB value is always 1, the AT constantly reduces the reverse
rate until the rate drops to 9.6 kbps; if the received RAB is always 0, the AT
constantly raises the reverse rate until the rate reaches the maximum rate
specified in the reverse rate limit message. When the transmit power of the AT
is limited, the AT does not raise the reverse rate, or even reduces the reverse
rate.
6.3 Application Scenario and Performance

Description of Algorithm
6.3.1 Use Recommendations
This is a basic CDMA2000 EV-DO function, applicable to all CDMA2000
EV-DO networks and terminals.
In the laboratory test, when the number of reverse active subscribers are more
than eight, and the reverse rate limit is set as 76.8 kbps, good fairness and
high total sector throughput are obtained. The maximum rate limit, however,
currently cannot be implemented through the unicast method.
6.3.2 Product Version Support

BSC
BSC6600 V200R001C02B012 and later
BTS
BTS3612 V100R001B02 and later
6.4 Traffic Statistic Indexes and Data Collection

6.4.1 Related Traffic Statistic Indexes
Measurement
Index
Measurement Set
Description
Max
Active
Connectors
of
Carrier[Entries]
EV-DO Connection
Performance
Measurement-Carrier
Maximum number of active

connections on carriers
Reverse
Link
Frame Count(rate
n)[Entries]
EV-DO Service Data

Throughput
Performance
Measurement-BSC
Number of frames on R-TCHs

at the rate of n that the
selection/distribution
unit
(SDU) receives
Reverse Link Error

Frame
Count[Entries]
EV-DO Service Data

Throughput
Performance
Measurement
Number of error frames on RTCHs that the SDU receives
Average
Eb/Nt
(EV-DO)[dB]
Performance Stat of
EV-DO
Link
Information
Measurement
The average value of all the

Eb/Nt values set by the outer
loop power control on the
reverser link.
Reverse
Link
Average FER of
EV-DO Carrier[%]
Performance Stat of
EV-DO
Link
Information
Measurement
The average reverse link PER

of all the DO calls on the
carriers.
RLP
Octets
Received
on
Reverse
Channels[KB]
EV-DO Service Data

Throughput
Performance
Measurement
Total amount of data that the

BSC receives at the RLP sublayer.
Note:
The measurement items Max Active Connectors of Carrier[Entries] and

Reverse Link Frame Count(rate n)[Entries] can reflect the current
situation of the reverse date service rate control and provides reference
for the adjustment of algorithm parameters.
The measurement items Reverse Link Error Frame Count[Entries],
Average Eb/Nt (EV-DO)[dB], and Reverse Link Average FER of EV-DO
Carrier[%] reflect the current reference situation on the reverse link.
6.4.2 Data Collection Methods

The data collection methods of this function are as follows:
The RFMT assigns the IMSI tracing to record the total number of
received frames, the number of frame errors, and the status of 75
successive frames. The granularity is 2s.
The BTS assigns the IMSI call tracing to record the number of DO
reverse legs, the handoff status, the link quality, and the rate indication.
The EV-DO link measurement information in the traffic statistics reflects
the reverse link condition. The EV-DO traffic data throughput
measurement records the transmission of reverse service data, the frame
status, and the distribution of different rates.
The field received bad RTC MAC frame number in the CDR
measures the impact of the MAC-layer reverse rate control on data
transmission.

Parameter Name
Command
Remarks
ReverseRateLimit
Modify:
MOD DORRMMP
Query:
LST DORRMMP
Reverse maximum rate limit

delivered to the AT through the
ReverseRateLimit message.
TransitionProbabil
ity
Modify:
DOMCNP
MOD
Probability of the AT shifting

between neighboring rate levels
Query: LST DOMCNP

RABLENGTH
Modify: MOD DOSP
Number of slots used

sending reverse active bits
for
Query: LST DORRMP:

DORRMINF=DOSP;
RABOFFSET
Modify: MOD DOSP

Query: LST DORRMP:
DORRMINF=DOSP;
RADESNALG
Modify: MOD DORLCP

Query: LST DORRMP:
DORRMINF=DORLCP;
Reverse active bit offset. The

parameter RABLength and this
parameter determine the slots
used for RAB sending.
This parameter is used for
choosing the RAB algorithm
according to the load in the
reverse load control.
Forward Data Transmission Algorithm
7.1 Overview of Forward Data Transmission

Algorithm
The CDMA2000 1xEV-DO supports forward transmission rates that range
from 19.2 kbps to 2.4576 Mbps. The actual rate that the AT receives depends
on the following three factors:
Wireless signal quality at the location of the subscriber: determines the

rate the AT requests from the AN.
Forward scheduling algorithm implemented at the BTS: affects the

throughput of the system and the subscriber because multiple subscribers
share time division channels in the CDMA20001xEV-DO system.
Abis flow control: affects the forward transmission rate, but is required
because the CDMA2000 1xEV-DO system uses the virtual soft handoff
on the forward link, and forward data requested by the subscriber shifts
between different BTSs.
7.2 Forward Rate Control

7.2.1 Background
The CDMA2000 1xEV-DO system uses the rate control and system
scheduling technologies on the forward link, and the rate ranges form 38.4
kbps to 2.4 Mbps. The rate control technology is unique to the CDMA2000
1xEV-DO system. Unlike in the CDMA20001X system, in the CDMA2000
1xEV-DO system, the AN does not assign a rate for the AT, and the forward
rate is controlled by the AT itself.
During calls, the AT evaluates the C/I value on the F-TCH and determines:
The expected rate
The sector whose F-TCH has the best quality
Through the DRC channel, the AT reports the above two messages to the AN,
which dynamically adjusts the sector that serves the AT and the forward
transmission rate.
7.2.2 Basic Principle
Figure 1.1 Forward link adaptive rate control procedure

The procedure is as follows:
1.
In each slot, the BTS delivers a 192 bit forward pilot signal, and the AT
calculates the SINR of the forward pilot frequency through coherence
accumulation.
2.
The AT predicts the SINR in the next timeslot according to the estimation
of the SINR during the last slots.
3.
According to the SINR threshold, the AT obtains the highest transmission

rate that the forward link supports in the next slot.
The SINR threshold is configured in either of the following ways:
Experiential configuration method
According to the typical features of the wireless environment, the AT

configures different SINR thresholds for different transmission rates while
maintaining an appropriate error rate.
Adaptive configuration method
In different wireless environments, the system measures the error rate of

packet transmission in real time and different SNR thresholds for different
transmission rates while maintaining an appropriate error rate.
4.
The AT predicts the transmission rate that the forward link supports in
the next slot, and then it reports its prediction to the BTS through the
DRC channel.
5.
When beginning to serve the AT, the BTS sends packets to the AT
according to the requested rate.
6.
According to the packet decoding, the AT calculates the packet error rate
(PER) and uses the PER as the basis of the adaptive configuration of the
SNR threshold
The AT reports the following two values through the DRC channel to the AN:
DCR Cover: determines which sector in the active set serves the AT.
DRC Value: informs the AN of the receiving rate expected by the AT.
A total number of 16 transmission modes may be requested by the AT, and

these transmission modes are called DRC indexes. Each DRC index consists
of the following information:
Transmission rate
Size of the transmitted data
Channel encoding type (for example, 3x Turbo or 5x Turbo)
Symbol repetition type (if any)
Required of number of sub-packets
Figure 6.1 DRC index

DRC
index
Slot
Modulation
method
Preamble
chip
Net
load
Rate
(kb/s)
C/I(db)
0x0
n/a
QPSK
n/a
null
rate
n/a
0x1
16
QPSK
1024
1024
38.4
-11.5
0x2
QPSK
512
1024
76.8
-9.2
0x3
QPSK
256
1024
153.6
-6.5
0x4
QPSK
128
1024
307.2
-3.5
0x5
QPSK
128
2048
307.2
-3.5
0x6
QPSK
64
1024
614.4
-0.6
0x7
QPSK
64
2048
614.4
-0.5
0x8
QPSK
64
3072
921.6
+2.2
0x9
QPSK
64
2048
1228.8
+3.9
0xa
16QAM
64
4096
1228.8
+4.0
0xb
8PSK
64
3072
1843.2
+8.0
0xc
16QAM
64
4096
2457.6
+10.3
0xd
16QAM
64
5120
1536.0
Rev.A
0xe
16QAM
64
5120
3072.0
Rev.A
The number of slots used for sending the DRC information is determined by
the parameter DRC Length.
In non-gated transmission mode (the parameter DO Gating is configured as
continuous transmission), if the value of the parameter DRC Length is greater
than 1, the DRC information is repeatedly transmitted in n (n is the value of
the parameter DRC Length) successive slots. A relatively great value of the
parameter DRC Length provides a relatively great link margin and maintains a
low DRC error rate in a large-radius cell.
In gated transmission mode (the parameter DO Gating is configured as
discontinuous transmission), each DRC flag is transmitted one time in each
DRC Length. The slots used for transmission must be active slots (non-gated
slots). A relatively high value of the parameter DRC Length provides
relatively high reliability of DRC information transmission, but the DRC
change is slowed down and cannot keep up with the change of the wireless
environment. A relatively low value of the parameter DRC Length reduces
DRC retransmission times and the reliability of DRC transmission, but the
DRC change is fast. The DRC Length varies according to the number of soft
handoff legs in the active set. When the DRC value is received at the AN side,
there is no soft handoff gain, but soft handoff gain is available in the reverse
traffic channel. Therefore, the value of DRC Length should be increased so
that the reliability of DRC transmission is improved.
If the AT sends DRC information to sector A in timeslot n and requests a rate
of r, the AT should continuously searches for forward pilot signals at a rate of
r from sector A between timeslot (n + 1) and timeslot (n + DRC Length). The
parameter DRC Length affects:
The rate of the virtual soft handoff
The quick rate response
During the virtual soft handoff, the AT sends a DRC request with the DRC
Cover 0, indicating that is enters the handoff. Then, the AT sends information
about the serving sector and rate that it requests. A relatively low value of the
parameter DRC Length increases the system response and adaptability of the
system in the wireless environment. In this case, however, the value of the
parameter DRC Channel Gain (the ratio of DRC channel power level to
reverse pilot channel power level) must be high, and the reverse system
capacity is small.

Parameter
Command
DRCGating
(DRCGATING)
DRCLength
Modify:
DOCNP
MOD
Query:
DOCNP
LST
Modify:
DOMPP
MOD
Query:
DOMPP
LST
Description
When the DRC information is
continuously transmitted, each DRC
value is transmitted in DRC Length
slots. When the DRC transmission is
gated, the DRC value is transmitted
in one of DRC Length slots.
Number of slots that the AT uses to
transmit single DRC value.
7.3 Abis Flow Control

7.3.1 Background
The CDMA2000 EV-DO system uses a request mechanism for data service
transmission over the Abis interface. When the BTS sends a data transmission
request to the BSC, the BSC delivers the data service packets to the BTS. The
CECM in the BTS maintains a buffer queue for each transmission. To avoid
overflow, the flow control algorithm must be used.
Basic Principle
When the AT assigns a serving sector, the CECM in the BTS sends a forward
data request to the BSC. During data transmission, the reports the forward
buffer queue information to the BSC to control the transmit rate of the BSC.
This process is detailed as follows:
1.
When the AT assigns a serving sector, the CSM driver tells the CECM to
obtain the buffer information of the related channel and to send an Abis
request to the BSC.
2.
During data transmission, after the BSC sends the assigned number of
packets to the AT, the CSM driver tells the CECM to obtain the buffer
information of the related channel and to send an Abis request to the
BSC.
On the maintenance console, run the following command to query the flow
over the Abis interface:
DSP ABISFLUX: TYPE=BTSID, BTSID=1;

Only the CBIE supports this function. The CBIE measures the flow every three
seconds and calculates the average rate in this cycle (three seconds). The ratio of
the average rate to the configured bandwidth is used as the Abis interface flow
percentage. Therefore, the result of the above command is the value of the last
cycle.
7.4 Air Interface Scheduling Algorithm

7.4.1 Background
In the CDMA2000 EV-DO system, time division method is used for forward
traffic channel data frames. Therefore, the system serves a single subscriber in
a given slot. To maximize the throughput of all the sectors, the 1xEV-DO
system uses the scheduling algorithm, based on the time division features of
the carriers. The system determines which subscriber to serve in a given slot.
The CDMA2000 EV-DO system uses rate adjustment demodulation method,
and data transmitted for different subscribers is different at the same time
because of different wireless environments. Therefore, the subscriber
scheduling must consider the following factors:
Fairness among subscribers
Wireless environments
Overall system throughput.
7.4.2 Basic Principle

In the CDMA2000 EV-DO system, the forward scheduling algorithm is
implemented by the CSM5500 chip of the CECM, and there are two types of
forward scheduling, namely Fair and G-Fair.
I.
Fair Algorithm
For each active subscriber, the data throughput Tk and DRC requested rate
DRCk during the last period of time are recorded. The system chooses the
active subscriber that has the greatest value of DRCk/Tk and serves this
subscriber. When a subscribers DRC information shifts to another sector, this
subscriber is treated as a newly-accessing subscriber.
At the BSC side, the variable Tk is recorded for each subscriber, and this
variable is updated in each slot. Tk[n] represents the Tk value in timeslot n.
This variable represents the average throughput of the subscriber during the
last period of time. In each timeslot allocation period n, the system picks the
current DRC value of each subscriber, namely DRCk[n]. The system
calculates the value of DRCk[n]/Tk[n] for each subscriber and allocates the
timeslot to the subscriber that has the greatest value of DRCk[n]/Tk[n]. In
actual operation, since Tk[n] may be 0, the system allocates the timeslot to the
subscriber that has the smallest value of Tk[n]/DRCk[n].
When the total data requested to transmit by all the subscribers exceeds the air
interface capacity, this algorithm maintains a direct proportion between the
data throughput that each subscriber obtains and the rate that the subscriber
can request in the wireless environment. This is fair to all the subscribers.
Because of the random attenuation feature of the wireless environment, the
DRC greatly fluctuates. The system is inclined to serve a subscriber when its
DRC is at the best level, and the system throughput is thus increased.
The scheduling algorithm maintains two high-priority queues and four lowpriority queues for each subscriber. Signaling messages use a high-priority
queue. When a subscriber has data in high-priority queues to transmit, the Fair
algorithm is stopped, and an alternate mode is used for receive data.
II. G-Fair Algorithm
This algorithm is improved on the basis of the Fair algorithm. For each active
subscriber, the following three variables are recorded:
Tk
Dk
DRCk
The system serves the subscriber that has the greatest value of DRCk[n]/
Dk[n])/( Tk[n]/ hk(Dk[n]). hk(x) is a subscriber-specific function, and
subscribers obtain different service levels through this function. If hk(x) is
equal to x, the G-Fair algorithm becomes the same as the Fair algorithm.
7.4.3 Evaluation of Scheduling Algorithm

The fairness is one of the most important aspects for evaluating the scheduling
algorithm and it is a complicated issue.
The fairness can be represented as throughput fairness, time fairness,
opportunity fairness, and resource occupation fairness. The fairness
realization is conflicted to the system capacity and differentiated service.
Each scheduling algorithm is to integrate the index requirements and find a
balance point according to the customized fairness criterion.
Currently, Huawei EVDO system (V200R001) does not realize QoS and does
not differentiate the subscriber priority. Therefore, the throughput fairness is
taken into account in the scheduling algorithm.
From the perspective of subscriber feelings, the scheduling algorithm is
evaluated in the following two aspects:
For the subscribers in the same radio operating environments, their

throughputs are similar. The throughput should be different because of
access sequence.
When the subscribers are affected by the same events, the effects also
should be similar. For example, when some subscribers are added or
removed, the throughputs of accessed subscribers should be decreased or
increased proportionally.
Currently, the industry has a method of evaluating the fairness: evaluate the
normalized cumulative distribution function (CDF) to obtain the fairness of
subscriber throughputs. Specifically, if T[k] is the throughput of subscriber k,
the normalized throughput T[k] is derived to be:
T '[k ]
T [k ]
avg (T [i ])
i
The industry method is to evaluate the normalized throughput fairness when

CDF is equal to 0.1, 0.2 and 0.5 according to the test cases of different hybrid
services.
To maximize the system capacity, the scheduling algorithm shall provide
services for the subscriber with the best radio operating environment within
each timeslot. However, the subscribers in bad radio environments almost
cannot be served.
To realize the optimal fairness, the scheduling algorithm is used to schedule
the subscribers in turn, but the actual radio environments are not taken into
account. All the factors must be taken into account in an ideal scheduling
algorithm.
The G-Fair algorithm is recommended by Qualcomm and is the optimal
scheduling algorithm currently because it:
Take the radio operating environments and QoS.
While improving the system throughput, ensure each subscriber is

scheduled.
The designers can freely differentiate the scheduling priorities by the

subscriber function to realize the differentiated services.
For the process of actual fairness test and verification, the simple method is as
follows:
1.
In the places with the same radio environments, use three terminals for
dialing test. After the terminals are accessed to the sector and the
download is normal, check the consistency of its rates.
2.
Start and then stop the download of a terminal, and check whether the
impacts on the other two terminals are the same.
Pay attention to the following during the fairness test:
No subscribers access the test sectors.
Ensure the same radio operating environments. Even though C/I is

changed lightly, if the fluctuation is between two different DRCs, the rate
may be changed, which is mistaken as scheduling unfairness.
7.4.4 Application Scenario and Performance Description

of Algorithm
Performance
The BTS currently uses G-Fair algorithm and the performance is realized in
the CSM5500 chip.
BSC
BTS


Parameter
Command
Description
Throughput
filter
time
coefficient
(THRGHTFLTRTM)
Modify:
SET
BTSCDMADOCHIPPARA
Indicate the filter time

coefficient
when
measuring
the
subscriber throughputs
within a period of time.
Gfair delimiter from

middle
to
near
(DLMDLTNR)
Modify:
SET
BTSCDMADOCHIPPARA
Gfair delimiter from

middle to far to
middle
(DLFRTOMDL)
Modify:
SET
BTSCDMADOCHIPPARA
Gfair middle
(MDLGN)
Modify:
SET
BTSCDMADOCHIPPARA
gain
Query:
DSP
BTSCFG:
CFGID=BTSCDMADOCHIPPA
RA;
Query:
DSP
BTSCFG:
RA;
Query:
DSP
BTSCFG:
RA;
Query:
DSP
BTSCFG:
RA;
Gfair
near
gain
Modify:
SET
Gfair is divided intonear

end, middle end, and far
end according to the
AvgDRC size. This
parameter sets critical
value between middle
end and near end in the
Gfair.
Gfair is divided intonear
end, middle end, and far
end according to the
AvgDRC size. This
parameter sets critical
value between middle
end and far end in the
Gfair.
Indicate the gain of
AvgDRC in the Gfair in
the middle end.
Indicate the gain of
(NRGN)
BTSCDMADOCHIPPARA
Query:
DSP
BTSCFG:
RA;
AvgDRC in the Gfair in

the near end.
Protocols Used in CDMA20001x

EV-DO Tests
8.1 Overview
The CDMA2000 1xEV-DO system defines a set of procedures that apply to
minimal performance tests between the AT and the AN, and the system has specific
testing methods of the F-TCH and the R-TCH.
8.2 FTAP
Function Description
The forward test application protocol (FTAP) provides the following
procedures and messages between the AN and the AT:
Controls the FTAP test configurations between the AT and the AN.
Generates FTAP test packets at the AN and sends these packets on the FTCH to the AT, which receives and processes theses packets.
Generates and transmits information about the received FTAP packets at

the AT through FTAP loopback packets.
Transmits configured ACK channel bits, DRC values and DRC covers.
Measures the changes in the serving sector as seen at the AT in the Idle
State and the Connected State.
Measures the number of successfully received first Synchronous Control

Channel packets
Through the FTAP, you can:
Collect and obtain the measurement results of the AT side.
Measure the throughput and packet error rate of the F-TCH.
Measure the packet error rate of the R-TCH.

BSC
BSC6600 V200R001 and later
BTS
BTS3612 V200R001C03B012 and later
BTS3606 V200R001C03B012 and later
8.2.2 Operation Description

The operation functions include:
FTAP idle handoff rate performance test
FTAP connected handoff rate performance test
FTAP forward channel performance test
FTAP idle handoff rate performance test

I.
Procedure
The procedure of FTAP idle handoff rate performance test is as follows:

1.
In the Navigation Tree Window of Service Maintenance System, select

Maintenance. In the Navigation Tree of cdma 1X&EV-DO BSC
Maintenance Tool, open the Test Call Status Monitoring Retrieval
node, and double-click FTAP Idle Handoff Rate Test Performance
Retrieval.
2.
In the FTAP Idle Handoff Rate Performance Test Settings dialog box,
set the test conditions, and click OK to start the monitoring.
3.
In the report output window, you can browse online the data report
monitored in real time. Double-click a report to acquire the details of the
report.
4.
To stop the FTAP idle handoff rate performance test, close directly the
report output report.
II.
Input parameters
Field Name
Remarks
IMSI No
International mobile subscriber identity (IMSI) is a 15-digit

decimal number
Time limit for task

running
When the task runs for the designated period of time, it

will automatically stop
Save Monitored
Data to a file
Select whether to save the data of FTAP: Forward Link

Performance Tests to a file.
Resource tracing results can be saved in two types of files,
*.bin and *.txt.

*.bin files are used to review the resource tracing, while
*.txt files can be directly opened to view.
The formats for the names of the tracing result files are:
MMDD_HHMMSS_FTAP Forward Link Performance

Tests_IMSI No._ACK Mode_0.bin

Tests_IMSI No._ACK Mode_0.txt
The default directories for saving the tracing result files

are:
..\Airbridge\OutputFile\Rmon\TESTCALL_FTAP_RES
OURCE\BIN (for *.bin files)
..\Airbridge\OutputFile\Rmon\TESTCALL_FTAP_RESO
URCE\TXT (for *.txt files)
FTAP connected handoff rate performance test

I.
Procedure
The procedure of FTAP connected handoff rate performance test is as follows:

1.

node, and double-click FTAP Connected Handoff Rate Performance
Test Retrieval.
2.
In the FTAP Connected Handoff Rate Performance Test Settings

dialog box, set the test conditions, and click OK to start the monitoring.
3.
report.
4.
To stop the FTAP connected handoff rate performance test, close directly
the report output window.
II.
Input parameters
Field Name
Remarks
IMSI No

decimal number
Time limit for

task running
When the task runs for the designated period of time, it will
automatically stop
Save
Monitored

Data to a file

*.bin and *.txt.
*.bin files are used to review the resource tracing, while *.txt
files can be directly opened to view.
Tests_IMSI No._ACK Mode_0.bin

Tests_IMSI No._ACK Mode_0.txt
The default directories for saving the tracing result files are:
OURCE\BIN (for *.bin files)
OURCE\TXT (for *.txt files)
FTAP forward channel performance test

I.
Procedure
The procedure of FATP forward channel performance test is as follows:

1.

node, and double-click FTAPF Forward Channel Test Performance
Retrieval.
2.
In the FTAP Forward Channel Performance Test Settings dialog box,

set the test conditions and click OK to star the monitoring.
3.
monitored in real time. Click a report to acquire the details of the report.
4.
To stop the FTAP forward channel performance test, close directly the
report output window.
II.
FTAP forward channel performance test settings
Field Name
Remarks
IMSI No

decimal number
ACK Mode
Non-fixed ACK mode: The AT receives data packets at the

actual rate till it can decode the packets.
Fixed ACK mode, ACK Channel Bit is 0: The AT receives data
packets within only one slot. It no longer receives the packets
even if decoding fails.
Fixed ACK mode, ACK Channel Bit is 1: The AT does not
terminate
data packets receiving ahead of time. Even if the data packets
are decoded ahead of time, the AT does not terminate data
packets receiving until all slots for transmitting the data packets
ends.
DRC Value
DRC: Data Rate Control (forward rate control)

DRC
Rate (kbps)
Packet Length(Slots)
0
1
2
3
4
5
6
7
8
9
10
11
12
null
38.4
76.8
153.6
307.2
307.2
614.4
614.4
921.6
1228.8
1228.8
1843.2
2457.6
N/A
16
8
4
2
4
1
2
2
1
2
1
1
Sector No.
Select the parameter "Cell ID-Sector ID" of the testing object.
Reverse Fixed
Rate (kbit/s)
The maximum and minimum rates of the RTAP are respectively

fixed to a value.
Timelimit for
task running
When the task runs for the designated period of time, it will
automatically stop.
Save Monitored
Data to a file

*.bin and *.txt.
*.bin files are used to review the resource tracing, while *.txt
files can be directly opened to view.
MMDD_HHMMSS_FTAP Forward Link

Performance Tests_IMSI No._ACK Mode_0.bin
MMDD_HHMMSS_FTAP Forward Link

Performance Tests_IMSI No._ACK Mode_0.txt
The default directories for saving the tracing result files are:
..\Airbridge\OutputFile\Rmon\TESTCALL_FTAP
_RESOURCE\BIN (for *.bin files)
..\Airbridge\OutputFile\Rmon\TESTCALL_FTAP
_RESOURCE\TXT (for *.txt files)
III. Tracing retrieval

Maintenance Tools, open the Test Call Status Monitoring Retrieval
node, and double-click FTAP Idle Handoff Rate Test Performance
Retrieval, FTAP Connected Handoff Rate Performance Test
Retrieval, and FTAPF Forward Channel Test Performance Retrieval.
8.3 RTAP
The reverse test application protocol provides the following procedures and
messages between the AN and the AT:
Controls the FTAP test configurations between the AT and the AN.
Generates RTAP test/fill packets at the AT and sends these packets on the
R-TCH to the AN, which receives and processes theses packets.
Transmits packets at preset rates on the R-TCH.
The RTAP measures the throughput and PER on the R-TCH.

BSC
BSC6600 V200R001C02B012 and later
BTS
BTS3606 V100R001B01and later
8.3.3 Operation Description

RTAP reverse channel performance test
I.
Procedure

node, and double-click RTAP Reverse Channel Test Performance
Retrieval.
In the RTAP Reverse Channel Performance Test Settings dialog box,

set the test conditions, and click OK to start the monitoring.
report.
To stop the RTAP reverse channel performance test, close directly the
report output window.
II.
Input parameters
Field Name
Remarks
IMSI No
International mobile subscriber identity (IMSI) is a 15digit decimal number
Reverse Min.
rate
The minimum data transmission rate of reverse channels.
Reverse Max.
rate
The maximum data transmission rate of reverse

channels.
Time limit for

task running
When the task runs for the designated period of time, it

will automatically stop.
Save Monitored
Data to a file
Select whether to save the data of RTAP: Reverse Link

Resource tracing results can be saved in two types of
files, *.bin and *.txt.
*.bin files are used to review the resource tracing, while
*.txt files can be directly opened to view.
MMDD_HHMMSS_RTAP Reverse Link Performance
Tests_IMSI No._0.bin
MMDD_HHMMSS_RTAP Reverse Link Performance

Tests_IMSI No._0.txt
The default directories for saving the tracing result files

are:
..\Airbridge\OutputFile\Rmon\TESTCALL_RTAP_
RESOURCE\BIN (for *.bin files)
..\Airbridge\OutputFile\Rmon\TESTCALL_RTAP_
RESOURCE\TXT (for *.txt files)
III. Tracing retrieval

Maintenance Tools, open the Test Call Status Monitoring Retrieval
node, and double-click RTAP Forward Channel Test Performance
Retrieval.
8.4 FLUS
8.4.1 Overview of FLUS
The forward link user simulation (FLUS) is a forward subscriber simulation
method that is designed for the CDMA1xEV-DO system. Similar to the
OCNS in the CDMA1X system, the FLUS can simulate a group of forward
subscribers at different transmission rates.
Since the forward link of CDMA20001xEV-DO system is time division
multiplexed and transmits at full power, the simulation of the load on the
forward link from multiple subscribers is equivalent to the simulation of the
duty ratio of slots on the forward link. When the FLUS is started, the system:
Randomly simulates a FLUS subscriber in each slot.
Assigns a random value between 0 and 100 for this FLUS subscriber.
Compares the random value assigned in last step with the duty ratio set
by the FLUS subscriber.
If the random value is less than the duty ratio, the system sends data
to the FLUS subscriber in this slot.
If the random value is not less than the duty ratio, the system does not
send data to the FLUS subscriber in this slot.
A timeslot used for sending data to a FLUS subscriber cannot be used by a

real subscriber.
The FLUS considers the duty ratio of the slots that used for subscribers on a
long-term basis.
Application Scenario of FLUS
The FLUS is mainly applicable to the simulation forward loads.
Loading Method
Run STR (C) BTSFLUS on the maintenance console, choose the carrier for
which the FLUS is to be loaded, and then input the simulated subscriber
number (1 recommended) and the load percentage (1-100 recommended).
8.5 OUNS
The reverse load of EVDO is the same as that of 1x, using the other user noise
simulator (OUNS). For details, refer to CDMA20001x Performance and
Principle Guideline.
Multi-Carrier Networking Strategy
9.1 Overview of Multi-Carrier Networking Strategy

As the network capacity increases gradually, the pure EVDO network and
EVDO network overlaid on 1x network require the multi-carrier
configuration.
If the EVDO network uses the multi-carrier configuration, the policy must be
used to determine the frequency on which the terminal in idle state resides, the
frequency on which the terminal originates services, and the carrier on which
the terminal establishes the traffic channel.
This document illustrates the EVDO single-mode terminal. For the dual-mode
terminal behaviors, refer to White Paper for DO-1X Interoperability.
9.2 Network Selection after Power-on

The EVDO terminals have a preferred roaming list (PRL), which saves the
roaming network type, frequency, priority, and roaming allowed flag. Unlike
CDMA20001x, EVDO terminals have no SID and NID. Therefore, they are
not set in the PRL.
After power on, the terminal searches for EVDO signals on the specific
frequency according to the settings in the PRL. After acquiring the EVDO
network over the forward pilot channel, the terminal receives the
synchronization message over the control channel to synchronize with the
system time.
After synchronization, the terminal receives SectorParameter message (SPM).
If the Channel field in the SPM carries the information of only a frequency,
the terminal will reside on the frequency, and originates calls on this
frequency.
If the Channel field carries the information of multiple frequencies, the
terminal selects a frequency through Hash algorithm and originates calls on
the selected frequency.
Currently, Huawei V2R1 system does not support the manual configuration of
frequency in the SPM. The number of EVDO frequencies in use and
configured by system is as many as the number of frequencies whose

information is saved in the SPM.
9.3 Hash Algorithm

The EV-DO terminals use the following three inputs of Hash function for
multi-carrier networking:
Key = SessionSeed
N = ChannelCount value in the SectorParameters message
Decorrelate = 0
In this equation, SessionSeed is the common data of address management

protocol. When the address management protocol is in Inactive state, the
terminal generates a 32-digit pseudorandom code through the pseudorandom
generator and assigns it to SessionSeed.
The pseudorandom code generates the function as follows:
z n a z n 1 mod m
In this formula, a=75=16807. m=231-1=2147483647.
Before each session, the terminal initializes the function generated by the
pseudorandom number and calculates different Zn in each application. The
initialization calculation is as follows:
z 0 HardwareID mod m
In this formula, HardwareID indicates the terminal ESN. is a physical
measurement value generated by terminal, which varies with the time. If Z 0 is
0, the terminal needs to recalculate Z0.
9.4 Hard Assignment

9.5 Inter-Frequency Handoffs

EVDO Performance and Principle Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EVDO Performance and Principle Guideline

Uploaded by

Copyright:

Available Formats

CDMA EVDO Performance and

2 Basic Call Flows.......................................................................................................17

3 Access Process and Silence.....................................................................................42

3.1.2 Access Probe Structure................................................................................................43

5 Reverse Power Control Algorithm.........................................................................72

5.4 Application Scenario and Performance Description of Algorithm........................................76

6 Reverse Load Control Algorithm...........................................................................81

7 Forward Data Transmission Algorithm................................................................89

8 Protocols Used in CDMA20001x EV-DO Tests...................................................100

8.3.2 Product Version Support............................................................................................106

9 Multi-Carrier Networking Strategy....................................................................110

Figure 4-6 Dormant handoff to EVDO from 1X (no EVDO session).......................................70

CDMA EV-DO Performance and Principle Guideline

1.1 About this Manual

1.1.2 Intended Audience

CDMA EV-DO Performance and Principle Guideline

1.1.4 Reference Documentation

3GPP2 A.S0008-0 v3.0, Interoperability Specification (IOS) for High

CBSC6600V200R001Power Control Algorithm Top-Level Design,

CBSC6600V200R001Soft Handoff Algorithm Top-Level Design,

CL93-V3762-1 X1, RLMAC Algorithm for IS-856 (1xEV),

CL93-V3439-1 Rev. A, CSM5500 Drivers Virtual Handoff and

80-H0230-1 Rev. B, RPC Power Allocation for IS-856 (1x EV-DO),

CDMA EV-DO Performance and Principle Guideline

80-H0551-1 Rev. B, G-Fair Scheduler, QUALCOMM

Cdma2000 1xEVDO Air Interface Flow Analysis Report, Guo Shikui,

AN Assisted 1X Active State Handoff to EVDO System Assistance

C.S0032 Test Requirement Analysis Report, Sun Zhonghua, 2003

EVDO Scheduling Algorithm Analysis, Nie Jimin, 2003

FLUS Function Analysis Report, Gan Bin, 2003

Prediction-Based Reverse Load Control Algorithm, Nie Jimin, 2004

C.S0029 Test Call Protocol Analysis Report, Gan Bin, 2003

Scott340,Background and Introduction To 1xEV-DO Technology,2005

CDMA EV-DO Performance and Principle Guideline

1.3 Acronyms and Abbreviations

Authentication, Authorization and Account

Access Network Identifiers

Base Station Controller

Base Transceiver Station

Current Access Network Identifiers

Code Division Multiple Access

Data Rate Control

Data Ready to Send

Data Source Control

Electronic Serial Number

Flow Control Protocol

Frame Check Sum

Hybrid Auto Retransmission request

High Data Rate

Home Location Register

High Rate Packet Data

International Mobile Subscriber Identity

CDMA EV-DO Performance and Principle Guideline

Medium Access Control

Mobility Event Indicator

Mobile Node Identification

Network Access Identifier

Previous Access Network Identifiers

Packet Control Function

Packet Data Service Node

Packet Data Unit

Packet Error Rate

Packet Zone Identification

Reverse Activity Bit