01 CDMA Performance Principles (EV-DO) V3.3 For Customers PDF

CDMA Performance Principles (EV-DO) V3.
3 for Customers
Issue Date
01 2009-11-09
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided AS IS without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com support@huawei.com
CDMA Performance Principles (EV-DO) V3.3 for Customers
Revision Record
Revision Record
Date 2006-12-30 Versio n 1.00 Description Initial release, revised according to the review comments. Revised according to the comments of networking planning personnel. Updated based on V300R006C02, added with the description on new features, and modified based on the earlier version. Updated based on V300R006C03, added with the description on new features, and modified based on the earlier version. Updated based on V300R006C03, added with the description on new features, and modified based on the earlier version. Prepared by Chen Yanming, Che Wei, Huang Jianzhong, Xi Le, Chen Yijian, Liu Hong, Lai Guoting, Li Wei, Xu Qiongtao, and Wu Yufeng Chen Yanming, Che Wei, Xi Le, Chen Yijian, and Li Wei Chen Yanming, Chen Chao, Sun Wenjie, Wu Yufeng, Ye Guojun, Li Xuchao, Wu Jie, Li Wei, Xi Le, Zhang Rui
2007-02-08
1.01
2008-07-30
3.0
2009-03-27
3.2
Chen Yanming, Chen Chao, Sun Wenjie, Ye Guojun, Li Xuchao, Xu Qiongtao, Li Wei, Xi Le, and Wu Jie
2009-08-29
3.3
Chen Yanming, Chen Chao, Sun Wenjie, Ye Guojun, Li Xuchao, Xu Qiongtao, Li Wei, Xi Le, Wu Jie, Li Yang, Wang Guangze, Huang Jianzhong, Xie Yunjuan, Zhang Xinke, and Lin Weiyong
2009-11-10
Huawei Technologies Proprietary
Page 3 of 144
Contents
Contents
1 Preface ..........................................................................................................................................2-1
1.1 About This Document ...................................................................................................................................2-1 1.1.1 Purpose.................................................................................................................................................2-1 1.1.2 Intended Audience ...............................................................................................................................2-1 1.1.3 Organization.........................................................................................................................................2-1 1.1.4 Compilation and Review Record .........................................................................................................2-2 1.1.5 References............................................................................................................................................2-3 1.2 Agreement and Explanation ..........................................................................................................................2-4 1.3 Abbreviations and Acronyms ........................................................................................................................2-4
2 EV-DO Rev. A Principle ...........................................................................................................2-1

2.1 Network Structure .........................................................................................................................................2-1 2.2 EV-DO Rev. A Protocol Stack Model............................................................................................................2-2 2.3 Channels........................................................................................................................................................2-4 2.3.1 Forward Channel..................................................................................................................................2-5 2.3.2 Reverse Channel ..................................................................................................................................2-7 2.4 Access Probe ...............................................................................................................................................2-10 2.5 Scheduling of Control Channel Messages...................................................................................................2-12 2.6 Key Technologies ........................................................................................................................................2-13 2.6.1 HARQ ................................................................................................................................................2-13 2.6.2 Multiuser Scheduling .........................................................................................................................2-15 2.6.3 Rate Control.......................................................................................................................................2-15 2.6.4 Virtual Soft Handoff...........................................................................................................................2-16 2.6.5 Power Control ....................................................................................................................................2-17 2.6.6 Reverse Silence..................................................................................................................................2-17 2.7 Enhanced Performance of the EV-DO Rev. A System ................................................................................2-18
3 QoS Mechanism of the EV-DO Rev. A System....................................................................3-1

3.1 Real-Time Services .......................................................................................................................................3-1 3.1.1 VoIP Service.........................................................................................................................................3-1 3.1.2 VT Service ...........................................................................................................................................3-2 3.1.3 Stream Media Service ..........................................................................................................................3-3 3.1.4 Broadcast Multicast Service.................................................................................................................3-3 3.2 QoS Evaluation Indicators ............................................................................................................................3-4
iv
01 (2009-11-09)
Contents
3.2.1 Bandwidth............................................................................................................................................3-4 3.2.2 Latency.................................................................................................................................................3-5 3.2.3 Jitter .....................................................................................................................................................3-5 3.2.4 Error Rate.............................................................................................................................................3-5 3.3 QoS Service Model .......................................................................................................................................3-5 3.3.1 IntServ Model ......................................................................................................................................3-5 3.3.2 DiffServ Model ....................................................................................................................................3-5 3.4 E2E QoS Architecture ...................................................................................................................................3-7 3.4.1 E2E QoS Mechanism ...........................................................................................................................3-8 3.4.2 IP QoS Mechanism ..............................................................................................................................3-8 3.4.3 QoS Mechanism in the Bearer and Transmission Layers.....................................................................3-8 3.5 QoS Guarantee of the EV-DO Rev. A System...............................................................................................3-9 3.5.1 Overview..............................................................................................................................................3-9 3.5.2 Intra-User QoS Division ....................................................................................................................3-10 3.5.3 QoS between subscribers ................................................................................................................... 3-11 3.5.4 QoS Guarantee of Terrestrial Links ...................................................................................................3-12 3.5.5 QoS Guarantee of Air Interfaces ........................................................................................................3-12
4 Call Signaling Flow ...................................................................................................................4-1

4.1 HRPD Configuration Negotiation Flow........................................................................................................4-1 4.1.1 Setting up an HRPD Session................................................................................................................4-1 4.1.2 Configuration Negotiation ...................................................................................................................4-2 4.2 Keeping an HRPD Session Alive ..................................................................................................................4-4 4.3 Releasing an HRPD Session .........................................................................................................................4-4 4.3.1 HRPD Session Release Initiated by an AT...........................................................................................4-4 4.3.2 HRPD Session Release Initiated by an AN..........................................................................................4-6 4.4 Setting Up an HRPD Connection..................................................................................................................4-7 4.4.1 AT-Initiated HRPD Connection Release Process .................................................................................4-8 4.4.2 AN-Initiated HRPD Connection Setup Process ...................................................................................4-9 4.4.3 Quick Connection Setup ....................................................................................................................4-10 4.5 Releasing an HRPD Connection ................................................................................................................. 4-11 4.5.1 AT-Initiated HRPD Connection Release Process ............................................................................... 4-11 4.5.2 AN-Initiated HRPD Connection Release Process ..............................................................................4-12 4.6 Handoff .......................................................................................................................................................4-12 4.6.1 Soft Handoff.......................................................................................................................................4-12 4.6.2 Hard Handoff .....................................................................................................................................4-14 4.6.3 Call Migration....................................................................................................................................4-17 4.6.4 Intra-AN Dormant Handoff................................................................................................................4-17 4.6.5 Inter-AN Dormant Handoff................................................................................................................4-18 4.6.6 Interoperation.....................................................................................................................................4-19 4.7 Access Authentication .................................................................................................................................4-23 4.8 Location Update ..........................................................................................................................................4-25
01 (2009-11-09)
Contents
5 Admission and Load Control...................................................................................................5-1

5.1 ACH Load Control ........................................................................................................................................5-1 5.1.1 Algorithm Background.........................................................................................................................5-1 5.1.2 Function Description............................................................................................................................5-1 5.1.3 Application Scenarios ..........................................................................................................................5-2 5.2 Forward Admission and Load Control ..........................................................................................................5-2 5.2.1 Algorithm Background.........................................................................................................................5-2 5.2.2 Function Description............................................................................................................................5-2 5.2.3 Application Scenarios ..........................................................................................................................5-3 5.3 DORA Reverse Load and Admission Control...............................................................................................5-3 5.3.1 Algorithm Background.........................................................................................................................5-3 5.3.2 Technical Description...........................................................................................................................5-4 5.3.3 Application Scenarios ..........................................................................................................................5-5
6 Handoff Algorithm ....................................................................................................................6-1

6.1 Overview of Handoff Algorithms..................................................................................................................6-1 6.1.1 Pilot Set................................................................................................................................................6-1 6.1.2 Pilot Set Management ..........................................................................................................................6-1 6.1.3 Pilot Searching .....................................................................................................................................6-2 6.2 Intra-AN Soft Handoff ..................................................................................................................................6-3 6.2.1 Algorithm Background.........................................................................................................................6-3 6.2.2 Function Description............................................................................................................................6-3 6.2.3 Application Scenarios ..........................................................................................................................6-3 6.3 Inter-AN Soft Handoff ..................................................................................................................................6-4 6.3.1 Algorithm Background.........................................................................................................................6-4 6.3.2 Function Description............................................................................................................................6-4 6.3.3 Application Scenario ............................................................................................................................6-5 6.4 1x and EV-DO Rev. A Interoperation............................................................................................................6-5 6.4.1 Algorithm Background.........................................................................................................................6-5 6.4.2 Function Description............................................................................................................................6-5 6.4.3 Application Scenario ............................................................................................................................6-6 6.5 Virtual Soft Handoff......................................................................................................................................6-6 6.5.1 Algorithm Background.........................................................................................................................6-6 6.5.2 Function Implementation .....................................................................................................................6-7 6.5.3 Application Scenario ..........................................................................................................................6-10 6.6 Hard Handoff ..............................................................................................................................................6-10 6.6.1 Algorithm Background.......................................................................................................................6-10 6.6.2 Function Implementation ................................................................................................................... 6-11 6.6.3 Application Scenario ..........................................................................................................................6-15 6.7 Intra-AN Hard Handoff Macro Diversity....................................................................................................6-16 6.7.1 Algorithm Background.......................................................................................................................6-16 6.7.2 Function Description..........................................................................................................................6-16
vi
01 (2009-11-09)
Contents
6.7.3 Application Scenario ..........................................................................................................................6-16 6.8 AN-Assisted Inter-AN Handoff...................................................................................................................6-16 6.8.1 Algorithm Background.......................................................................................................................6-16 6.8.2 Function Description..........................................................................................................................6-16 6.8.3 Application Scenario ..........................................................................................................................6-17
7 Reverse Power Control..............................................................................................................7-1

7.1 Overview.......................................................................................................................................................7-1 7.2 Reverse Open Loop Power Control...............................................................................................................7-2 7.2.1 Algorithm Background.........................................................................................................................7-2 7.2.2 Function Description............................................................................................................................7-2 7.2.3 Application Scenario ............................................................................................................................7-3 7.3 Reverse Closed Loop Power Control ............................................................................................................7-3 7.3.1 Algorithm Background.........................................................................................................................7-3 7.3.2 Function Description............................................................................................................................7-4 7.3.3 Application Scenario ............................................................................................................................7-8
8 Forward Scheduling and Forward Rate Limit ......................................................................7-1

8.1 Forward Scheduling ......................................................................................................................................7-1 8.1.1 Algorithm Background.........................................................................................................................7-1 8.1.2 Function Description............................................................................................................................7-2 8.1.3 Application Scenarios ..........................................................................................................................7-3 8.2 Forward Rate Limit .......................................................................................................................................7-3 8.2.1 Algorithm Background.........................................................................................................................7-3 8.2.2 Function Description............................................................................................................................7-4 8.2.3 Application Scenarios ..........................................................................................................................7-4
9 Reverse Scheduling and Reverse Rate Limit........................................................................9-1

9.1 T2P ................................................................................................................................................................9-1 9.1.1 Token Bucket Mechanism....................................................................................................................9-1 9.1.2 T2P Functions ......................................................................................................................................9-2 9.1.3 T2P Allocation Principles.....................................................................................................................9-4 9.2 Reverse BE Subscriber Scheduling Strategy.................................................................................................9-5 9.2.1 Algorithm Background.........................................................................................................................9-5 9.2.2 Function Description............................................................................................................................9-5 9.2.3 Application Scenario ............................................................................................................................9-6 9.3 Reverse Rate Limit for Private-Line Subscribers..........................................................................................9-6 9.3.1 Algorithm Background.........................................................................................................................9-6 9.3.2 Function Description............................................................................................................................9-7 9.3.3 Application Scenario ............................................................................................................................9-7 9.4 Reverse Rate Limit for BE Flows of Grade Subscribers...............................................................................9-8 9.4.1 Algorithm Background.........................................................................................................................9-8 9.4.2 Function Description............................................................................................................................9-8 9.4.3 Application Scenario ............................................................................................................................9-9 01 (2009-11-09) vii
Contents
10 Multi-Carrier Networking....................................................................................................10-1
10.1 Overview ...................................................................................................................................................10-1 10.1.1 Demand for Multi-Carrier Networking ............................................................................................10-1 10.1.2 Problems in Multi-Carrier Networking ............................................................................................10-2 10.2 Camping of Idle ATs..................................................................................................................................10-3 10.2.1 Algorithm Background.....................................................................................................................10-3 10.2.2 Function Description........................................................................................................................10-3 10.2.3 Camping Strategies for Idle ATs.......................................................................................................10-4 10.2.4 Application Scenario ........................................................................................................................10-4 10.3 Paging........................................................................................................................................................10-4 10.3.1 Function Description........................................................................................................................10-4 10.3.2 Application Scenarios ......................................................................................................................10-5 10.3.3 Function Description........................................................................................................................10-5 10.4 Hard Assignment.......................................................................................................................................10-6 10.4.1 Algorithm Background.....................................................................................................................10-6 10.4.2 Function Description........................................................................................................................10-6 10.4.3 Application Scenarios ......................................................................................................................10-8
11 Transmission Resource Management ................................................................................11-1

11.1 Overview ................................................................................................................................................... 11-1 11.2 Abis Networking Mode ............................................................................................................................. 11-1 11.2.1 Interface Mode ................................................................................................................................. 11-1 11.2.2 Transmission Mode .......................................................................................................................... 11-1 11.3 Abis Transmission Resource Management................................................................................................ 11-2 11.3.1 Stage-by-Stage Flow Control ........................................................................................................... 11-2 11.3.2 Abis Interface Congestion Control................................................................................................... 11-3 11.3.3 Abis Bandwidth Admission Algorithm of BE Services.................................................................... 11-5 11.4 Abis Frame Multiplexing Technology ....................................................................................................... 11-6 11.5 Abis Transmission Efficiency.................................................................................................................... 11-6
12 Energy Saving of the EV-DO Rev. A System ...................................................................12-1

12.1 Algorithm Background..............................................................................................................................12-1 12.2 Function Description .................................................................................................................................12-1 12.2.1 Principles for Shutting Down Carriers .............................................................................................12-1 12.2.2 Shutting Down a Carrier ..................................................................................................................12-2 12.2.3 Re-enabling Carrier Handoff Process ..............................................................................................12-2
13 EV-DO Test Call.....................................................................................................................13-1

13.1 Algorithm Background..............................................................................................................................13-1 13.2 Function Description .................................................................................................................................13-1
14 EV-DO White List Function.................................................................................................14-1

14.1 Algorithm Background..............................................................................................................................14-1 14.2 Function Description .................................................................................................................................14-1
viii
01 (2009-11-09)
Contents
14.2.1 Residence Strategy for White List Subscribers ................................................................................14-1 14.2.2 Access Strategy for White List Subscribers .....................................................................................14-1 14.2.3 Handoff Strategy for White List Subscribers ...................................................................................14-2
01 (2009-11-09)
ix
1 Preface
1
1.1 About This Document
1.1.1 Purpose 1.1.2 Intended Audience
Preface
This document describes the principles of the features of the EV-DO Rev. A system. It presents an all-round profile of the performance algorithm functions, with focus on the purpose, usage, application scenarios, In addition, it introduces the basic concepts and knowledge associated with the features.
This document is intended for those Huawei internal engineers who possess fundamental knowledge of the CDMA2000 EV-DO system.
1.1.3 Organization
The organization of this document is as follows: Chapter 1 "Preface" describes the purpose, intended audience, and organization of this document. Chapter 2 "EV-DO Rev. A Principle" describes the principles and performance promotion of EV-DO Rev. A. Chapter 3 "QoS Mechanism of the EV-DO Rev. A System" describes the QoS mechanism of EV-DO Rev. A. Chapter 4 "Call Signaling Flow" describes the major signaling processes of the EV-DO Rev. A system. Chapter 5 "Admission and Load Control" describes the principles of the admission control and load control of the access channel and forward traffic channel. Chapter 6 "Handoff Algorithm" describes the principles of the reverse soft handoff, virtual soft handoff, and hard handoff, and the inter-operability principles of dual-mode terminals between the CDMA2000 1X and CDMA2000 EV-DO networks. Chapter 7 "Reverse Power Control" describes the principles of reverse open loop power control and closed loop power control in the EV-DO Rev. A system.
01 (2009-11-09)
2-1
Contents
Chapter 8 "Forward Scheduling and Forward Rate Limit" describes the forward scheduling principle and forward rate limitation principle. Chapter 9 "Reverse Scheduling and Reverse Rate Limit" describes the reverse scheduling principle and reverse rate limitation principle. Chapter 10 "Multi-Carrier Networking" describes the terminal residing policy and hard assignment algorithm for the multi-carrier networking mode. Chapter 11 "Transmission Resource Management" describes the Abis bandwidth management principle. Chapter 12 "Energy Saving of the EV-DO Rev. A System" describes the principle of saving power by powering off the EV-DO carrier. Chapter 13 "EV-DO Test Call" describes the purpose, methods, and types of EV-DO call test. Chapter 14 "EV-DO White List Function" describes the principles and implementation of the EV-DO white list function.
1.1.4 Compilation and Review Record

Chapter Chapter 1 Prepared by Chen Yanming Chen Yanming Chen Yanming Chen Chao, Zhang Rui, Sun Wenjie Li Wei Reviewer (Internal) Wan Rong, Zhang Rui, Chen Chao, Ye Guojun, Xie Yunjuan Wan Rong, Zhang Rui, Chen Chao, Ye Guojun, Xie Yunjuan Wan Rong, Zhang Rui, Chen Chao, Ye Guojun, Xie Yunjuan Wan Rong, Zhang Rui, Chen Chao, Ye Guojun Reviewer (External) Huang Feiquan Reviser Chen Yanming
Chapter 2
Huang Feiquan
Chen Yanming
Chapter 3
Huang Feiquan
Chen Yanming
Chapter 4
Huang Feiquan
Chen Yanming
Chapter 5
Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao
Jiang Wei, Xie Zhuogang Jiang Wei, Xie Zhuogang
Chen Yanming
Chapter 6
Sun Wenjie, Wu Jie, Chen Chao, Zhang Rui Wu Yufeng
Chen Yanming
Chapter 7
Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao
Jiang Wei, Xie Zhuogang
Chen Yanming
2-2
01 (2009-11-09)
1 Preface
Chapter Chapter 8
Prepared by Li Wei
Reviewer (Internal) Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao Wan Rong, Zhang Rui, Chen Chao, Ye Guojun, Xie Yunjuan Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao Lin Weiyong, Li Yang Xie Yunjuan, Chen Yanming, Xi Le, Chen Chao
Reviewer (External) Jiang Wei, Xie Zhuogang, Li Yuanxia Huang Feiquan
Reviser Chen Yanming
Chapter 9
Li Xuchao, Ye Guojun Chen Yanming Xi Le
Chen Yanming
Chapter 10
Jiang Wei, Xie Zhuogang Jiang Wei, Xie Zhuogang Jiang Wei, Xie Zhuogang Li Cong
Chen Yanming
Chapter 11
Chen Yanming
Chapter 12
Xi Le, Li Xuchao Chen Yanming Li Wei
Chen Yanming
Chapter 13
Chapter 14
Li Yanfen Li Xuchao
Jin Yanfei, Wang Jianyong
1.1.5 References
[1]. 3GPP2 C.S0024-A_v2.0_050727 cdma2000 High Rate Packet Data Air Interface Specification, September 2006 [2]. 3GPP2 A.S0008-B_v1.0_Interoperability Specification (IOS) for High Rate Packet Specification, October 2006 [3]. CDMA2000 BSC V200R003 EV-DO Rev. A Design Specification Description, November 2005 [4]. Scott340, Background and Introduction To 1xEV-DO Technology, 2005 [5]. EV-DO White Paper, April 2005 [6]. EV-DO Rev. A Physic and MAC, Qualcomm, 2004 [7]. EV-DO Rev. A Key Service Analysis Summary, Wan Rong, Wang Zhifeng, Jiang Ying, Ye Junguo, Deng Zhouyu, 2006 [8]. Enhanced Multi-Flow Packet Application Feature Definition Document 80-V7647-1 A , Qualcomm, September 8, 2005
01 (2009-11-09)
2-3
Contents
1.2 Agreement and Explanation

This manual cannot be used as the operation guide of the performance algorithm. For detailed operations, refer to the help of the Service Maintenance System. 1. About "Algorithm Background"
This part describes the application background and values of an algorithm. 2. About "Function Description"
This part describes the functions and principles of an algorithm.
1.3 Abbreviations and Acronyms

Abbreviations and Acronyms AAA AC ACK AN ANID ARQ BCMCS BSC BTS CANID CDMA DRC DRS DSC ESN FCP FCS HARQ HDR HLR HRPD Full Spelling Authentication, Authorization and Account Asynchronous Capsule Acknowledgement Access Network Access Network Identifiers Automatic Request Broadcast and multiplecast services 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
2-4
01 (2009-11-09)
1 Preface
Abbreviations and Acronyms IMSI IOS MAC MEI MNID NAI NAK NID PANID PCF PDSN PDU PER PPP PZID QoS RA RAB RATI RLMAC RLP RoT RPC RRI SID SINR UATI
Full Spelling International Mobile Subscriber Identity Inter-Operation Specification Medium Access Control Mobility Event Indicator Mobile Node Identification Network Access Identifier Not Acknowledgement Network Identification Previous Access Network Identifiers Packet Control Function Packet Data Service Node Packet Data Unit Packet Error Rate Point-to-Point Protocol Packet Zone Identification Quality of Service Reverse Activity Reverse Activity Bit Random Access Terminal Identifier Reverse Link MAC Radio Link Protocol Rise Over Thermal Reverse Power Control Reverse Rate Indicate System Identification Signal Interference and Noise Ratio Unicast Access Terminal Identifier
01 (2009-11-09)
2-5
2 EV-DO Rev. A Principle
2
2.1 Network Structure
EV-DO Rev. A Principle
EV-DO Rev. A has the same function entities as the 1X PS network, such as the A8/A9 and A10/A11 interfaces, PCF, and PDSN. In addition, EV-DO Rev. A is added with entities related to EV-DO authentication, such as the A12 interface and AN-AAA, and the A13/A16/A17/A18 interface related to inter-AN handoffs. The following figure shows the EV-DO Rev. A network architecture: Figure2-1 EV-DO Rev. A network architecture
NE functions: 1. PDSN: Packet Data Server Node. The PDSN provides the interface between the AN and the Internet, and is connected to the AT through the PPP link. 2. PCF: Packet Control Function 3. AN: Access Network. The AN provides radio connection with the AT, and implements functions such as radio resource management and power control. 4. AN AAA: implements the authorization, authentication, and accounting of the AT. 5. AT: Access Terminal
01 (2009-11-09)
2-1
Contents
Interface functions: 1. Abis interface: carries the service data and signaling messages between the BSC and BTS. 2. A8/A9 interface: The A8 interface carries service data between the AN and the PCF. The A9 interface carries the signaling messages used for establishing, maintaining, and releasing the service connections between the AN and the PCF, and the signaling messages of idle handoffs. 3. A10/A11 interface: The A10 interface transfers the traffic data between the PCF and the PDSN. The A11 interface transfers the signaling messages for establishing and releasing the A10 connections and the messages for charging. 4. A12 interface: connects the AN and the AN AAA and transfers signaling messages for access authentication. Generally, the AN and the AN AAA operate in RADIUS client and server mode. 5. A13 interface: transfers signaling messages for inter-AN idle handoffs. 6. A16 interface: transfers signaling messages for in-service handoffs between ANs. 7. A17/A18 interface: The A17 interface transfers the signaling messages for soft handoffs between the source and target ANs. The A18 interface transfers the service data for soft handoffs between the source and target ANs. The soft handoffs occurring on the A17/A18 interface are all reverse ones. The forward ones are virtual soft handoffs.
2.2 EV-DO Rev. A Protocol Stack Model

As shown in the following figure, the air interface protocol stack of EV-DO Rev. A is composed of seven protocol layers: physical layer, MAC layer, security layer, connection layer, session layer, stream layer, and application layer. Different layers implement different functions. All the layers can be active at the same time and involve no time sequence, except when data encapsulation is finished from the top layer to the bottom layer one by one. Figure2-2 EV-DO Rev. A protocol stack structure
2-2
01 (2009-11-09)
Protocol layer functions:

Physical layer: It defines the following information on forward/reverse physical channels:

Structure Output power Data encapsulation Baseband Radio frequency (RF) processing Operating frequency
MAC layer: It controls access to physical channels. The following describes the related protocols:

The MAC protocol for control channels defines the control transfer mode and timeslots. The MAC protocol for ACHs defines the access mode of ATs and the long code generation mode. The MAC protocol for forward TCHs defines rate control of forward TCHs. The MAC protocol for reverse TCHs defines capture and rate control of reverse TCHs.
01 (2009-11-09)
2-3
Contents
Security layer The functions of the security layer are:

Crypto Sync generation Key exchange Data encryption Air interface authentication
Connection layer The functions of the connection layer are:

System capture Setting up, maintaining, and releasing connections Managing mobility and controlling links in the connection state Multiplexing data packets in the session layer Demultiplexing data packets in the security layer The Radio Link Management Protocol maintains the radio link state between the AT and the AN. The Initialization State Protocol defines the messages and the signaling exchange for the AT to capture the AN. The Idle State Protocol defines the messages and the signaling exchange for the AT that captures the AN but is not connected to the AN. The Connected State Protocol defines the messages and the signaling exchange for the AT to communicate with the AT after a connection is set up. The Route Update Protocol tracks and maintains the location of the AT. The Packet Consolidation Protocol multiplexes the data packets in the session layer and demultiplexes those in the security layer.
The following describes the related protocols:

Session layer It sets up, maintains, and releases air interface sessions. The following describes the related protocols:

The Session Management Protocol activates other protocols in the session layer. This protocol also maintains and closes sessions. The Address Management Protocol allocates an address for the AT in a session. The Session Configuration Protocol negotiates session-related protocols and their configurations.
Stream layer It affixes QoS flags to data streams and signaling. Application layer It transmits, receives, and controls data packets for packet application and signaling application.
2.3 Channels
This section describes the following information on forward/reverse channels:
Channel structure
01 (2009-11-09)
2-4

Timeslot structure Channel identifier (ID)
2.3.1 Forward Channel

2.3.1.1 Channel Structure
Figure 2-3 shows the structure of the forward channel of the EV-DO Rev. A system. The forward channel consists of:

Pilot channel Medium Access Control (MAC) channel Control channel TCH
The MAC channel consists of:

Reverse Activity (RA) sub-channel DRCLock sub-channel Reverse Power Control (RPC) sub-channel ARQ sub-channel
The ARQ sub-channel is a new channel provided by the EV-DO Rev. A system. The channels marked in blue are enhanced in the EV-DO Rev. A system. Figure2-3 Structure of the forward channel of the EV-DO Rev. A system
The functions of each channel are: The pilot channel is used for system capturing, coherent demodulation, and quality measurement of links.

The RA sub-channel transmits the reverse load indicator of the system. The RPC sub-channel transmits power control bits of the reverse TCH.
The DRCLock sub-channel transmits the messages that indicate whether the system receives DRCs correctly from the AT. The ARQ sub-channel transmits the messages that indicate whether the AN receives data packets correctly from the reverse TCH.
01 (2009-11-09) 2-5
Contents
The TCH transmits data packets in the physical layer.
2.3.1.2 Timeslot Structure

The EV-DO Rev. A forward channels are multiplexed through Time Division Multiplexing (TDM) supplemented by Code Division Multiplexing (CDM). Data is sent in timeslots. The pilot channel, the MAC channel, the control channel, and the TCH use the time division mechanism. In the MAC channel, the H-ARQ or the L-ARQ sub-channel uses the TDM mechanism with the RPC sub-channel. The DRCLock sub-channel uses the TDM mechanism with the P-ARQ sub-channel and then uses the CDM mechanism with the RA sub-channel. See Figure2-4. Figure2-4 Structure of the forward MAC channel of the EV-DO Rev. A system
The forward channel of the EV-DO Rev. A system uses timeslots as the transmission unit. Each timeslot is 5/3 ms and consists of 2048 chips. Figure2-5 shows the timeslot structure. The BTS transmits data in 1 to 16 timeslots according to the size and the rate of the data packets in the forward channel. If data service is requested, the timeslots of the TCH are activated. In this case, all channels are multiplexed according to the specific sequence and the number of chips.

If data service is not requested, the timeslots of the TCH are idle. In this case, only the MAC channel and the pilot channel are transmitted. Figure2-5 Timeslot structure of the forward channel of the EV-DO Rev. A system
2-6
01 (2009-11-09)
2.3.1.3 Channel ID
The forward traffic channel consists of the preamble and data. The preamble carries the channel ID (MACIndex) as the ID of the communicating user or the ID of the forward channels, namely the MAC channel, traffic channel, and control channel. EV-DO Rel. 0 uses MACIndex of 6 bits. EV-DO Rev. A uses MACIndex of 7 bits, and its theoretical peak user capacity is twice EV-DO Rel. 0. Table 2-1 lists the MAC indexes assigned for the forward MAC channel, TCH, and control channel of the EV-DO Rev. A system. Table2-1 Assignment of MAC indicators MAC Index 0 and 1 2 3 4 5 64&65 66 67 68 69 70 71 663, 72127 Used by MAC Channel Not Used Not Used Not Used RA Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used RPC/DRCLock/A RQ Used by Preamble Not Used 76.8k Control Channel 38.4k Control Channel Not Used Broadcast Not Used Multiuser packet (128/256/512/1024, 4, 256) Multiuser packet (2048, 4, 128) Multiuser packet (3072, 2, 64) Multiuser packet (4096, 2, 64) Multiuser packet (5120, 2, 64) 19.2/38.4/76.8-kbit/s Control Channel (128/256/512, 4, 1024) Singleuser packet Preamble Length N/A 512 1024 N/A Variable N/A 256 128 64 64 64 1024 Depending on the DRC
2.3.2 Reverse Channel

2.3.2.1 Channel Structure
Figure 2-6 shows the reverse channel structure of the EV-DO Rev. A system. The reverse channel consists of the ACH and the reverse TCH.
ACH The ACH comprises:

Pilot channel Data channel

2-7
01 (2009-11-09)
Contents
Reverse TCH The reverse TCH consists of the following sub-channels:

Primary pilot channel Auxiliary pilot channel (a new channel in the EV-DO Rev. A system) MAC channel Ack channel Data channel
The MAC channel consists of the following sub-channels:

Reverse Rate Indicator (RRI) sub-channel Data Rate Control (DRC) sub-channel Data Source Control (DSC) channel (a new channel in the EV-DO Rev. A system)
Figure2-6 Structure of the reverse channel of the EV-DO Rev. A system
The ACH transfers AT access information about the BTS. The pilot channel performs coherent demodulation and timing synchronization of reverse links, so that the system captures the AT. The data channel carries the AT access information about the BTS. The reverse TCH transfers the rate indicator information about the reverse TCH and transmits the data packets from the MAC protocol of the reverse TCH. The reverse TCH also transmits rate requests to the forward TCH and indicates whether the AT correctly receives data packets from the forward TCH. Where:
The primary pilot channel can estimate the link quality besides performing coherent demodulation and timing synchronization of reverse links in the connected state.
The auxiliary pilot channel assists the BTS in demodulating big reverse packets.
The MAC channel assists the MAC layer in controlling transmission rates of the forward/reverse TCHs.

The RRI sub-channel indicates the data transmission rate of the reverse TCH. The DRC sub-channel carries the forward TCH data rate (DRCValue) requested by the AT and the forward serving sector ID (DRCCover). The DSC sub-channel carries the forward serving BTS ID.
2-8
01 (2009-11-09)

The ACK sub-channel indicates whether the AT correctly receives the data packets from the forward TCH.
The data channel transmits the data packets from the MAC layer of the reverse TCH.
The RRI sub-channel of the EV-DO Rev. A system consists of 6 bits (this is different from the EV-DO Rel. 0 system). Four bits indicate the size of the large reverse packet, and the other two bits indicate the sequence number of the sub-frame. The following figures show the mapping: Figure2-7 Twelve reverse benchmark rates
2.3.2.2 Sub-Frame Structure of the Reverse TCH

The EV-DO Rev. A reverse channels are multiplexed through Code Division Multiplexing (CDM) supplemented by Time Division Multiplexing (TDM). Data is sent in sub-frames, with each sub-frame occupying four timeslots. The DSC channel uses TDM with the ACK channel and then uses CDM with other channels. Figure2-8 shows the sub-frame structure of the reverse TCH. Figure2-8 Sub-frame structure of the reverse TCH
01 (2009-11-09)
2-9
Contents
2.3.2.3 Channel ID
The reverse channel uses Walsh codes to identify channels and uses long codes to identify subscribers. Table2-2 lists Walsh codes allocated to reverse channels. Table2-2 Walsh codes allocated to reverse channels Channel Pilot Reverse Rate Indicator (RRI) Data Source Control (DSC)/ACK Data Rate Control (DRC) Data Auxiliary Pilot Walsh Channel
16 W0
16 W4 32 W12
16 W8
W24 and/or W12

32 W28
Table2-3 Walsh codes allocated to ACHs Channel Pilot Data Walsh Channel
16 W0
W24
2.4 Access Probe

The ACH consists of a preamble and the access data (probe). An AT sends a request to the AN or responds to a request from the AN by using the ACH. The access procedure consists of one or multiple probes. See Figure2-9. An access probe consists of the access channel preamble and multiple access channel data packets. During the transmission of the packets in the ACHs physical layer, the pilot channel and the data channel are also transmitted. The output power
2-10 01 (2009-11-09)
of the pilot channel during the preamble of an access probe is higher than that during probe data. See Figure2-10. The ACH cycle indicates the time when the AT may start an access probe. The length of the preamble is determined by the frame parameters PreambleLength or the timeslot parameter PreambleLengthSlots. Figure2-9 Differences in the ACH structure between EV-DO Rev. A and EV-DO Rel. 0
Figure2-10 Access probe sequence of the EV-DO Rev. A system
01 (2009-11-09)
2-11
Contents
Before starting a probe sequence, the AT performs a persistence check. This avoids collision caused by simultaneous access attempts to the same sector. If the persistence check is passed, the AT starts to send the access probe sequence during the current ACH cycle. If a probe sequence packet contains multiple access probes, the AT waits for a random time p to send an access probe after sending the previous access probe. If during this time the AT does not receive any response from the system, the AT increases the transmit power by one PowerStep and then transmits another access probe. The AT stops sending probes when any of the following conditions is met:

The AT receives an ACAck message. The transmission stops upon a deactivation command.
The number of probes transmitted by each sequence reaches ProbeNumStep (maximum number of probes).
p = TACMPATProbeTimeout + (y * AccessCycleDuration) s = TACMPATProbeTimeout + (k * AccessCycleDuration)

ACMPATProbeTimeout is the timer for responding to the access probe. Its value often is 128 timeslots. y and k are two random integers evenly distributed between 0 and ProbeBackoff (ProbeBackoff: normally four ACH cycles). AccessCycleDuration is the duration of an access cycle. Its value often is 64 timeslots.
The AT also performs a persistence check between two access probe sequences. The AT sends the next access probe sequence only when the check is passed.
2.5 Scheduling of Control Channel Messages

In the EV-DO Rev. A system, scheduling of control channel messages consists of the following parts:

Scheduling of synchronous control channel packets Scheduling of sub-synchronous control channel packets Scheduling of asynchronous control channel packets
Compared with the EV-DO Rel. 0 system, the current system provides extra scheduling of sub-synchronous packets. The minimum scheduling period is eight timeslots, which greatly improves the transmission rate of the synchronous messages such as the paging message. In addition, the short packet scheduling mechanism is used for the sub-synchronous packets and asynchronous packets. This saves air interface resources.
2-12 01 (2009-11-09)
Figure2-11 Architecture of control channel scheduling
The synchronous packets are sent once every synchronous control channel cycle. The sub-synchronous packets are sent once every sub-synchronous control channel cycle. This increases transmission frequency. Asynchronous messages can be transmitted if no synchronous packet or sub-synchronous packet is being transmitted. Sub-synchronous packets and asynchronous packets use short packet format. This saves transmission resources on the air interface. The priorities are as follows: Synchronous control channel packet scheduling > sub-synchronous control channel packet scheduling > asynchronous control channel packet scheduling. Therefore, sub-synchronous packets must avoid timeslots used by synchronous packets, and asynchronous packets must avoid the timeslots used by synchronous packets and sub-synchronous packets.
2.6 Key Technologies

2.6.1 HARQ
The EV-DO Rel. 0 system uses the Hybrid Automatic Retransmission Request (HARQ) in the forward links, but the EV-DO Rev. A system uses it in both the forward and reverse links. All traditional Automatic Request (ARQ) technologies support error frame retransmission but do not support error correction. To save system resources, the EV-DO system uses the HARQ that integrates channel code detection/correction with packet retransmission. HARQ Type-I integrates the Front Error Control (FEC) and the ARQ. It performs decoding and error correction of each received data frame. If error correction succeeds, the data frame is received. If correction fails, the data frame is discarded. In this case, an NAK message is sent, requesting data frame retransmission. HARQ Type-I discards error data frames without using the information carried in those frames. HARQ Type-II saves the data frames that fail to be decoded and then combines them with the retransmitted data frames before decoding. This increases the probability of successful decoding. Compared with HARQ Type-I, HARQ Type-II requires the receiving end to support packet storage and combination. A data frame retransmitted based on HARQ Type-II is the same as the original one. Therefore, error correction capability is limited. To meet transmission requirements in a complicated radio environment, the HARQ of the EV-DO system uses incremental redundancy decoding based on HARQ Type-II. The EV-DO Rev. A system uses multi-timeslot interleaving technology. The transmission interval between two adjacent multi-timeslot data packets is three timeslots. During the
01 (2009-11-09)
2-13
Contents
interval, data packets of other subscribers can be transmitted. Figure 2-12 shows the forward HARQ of the Ack channel. Figure 2-12 Forward HARQ
A data packet can be divided into different timeslots for transmission. Every four timeslots are interleaved. The AT can terminate the timeslots that are being transmitted. The AT receives four timeslots and then demodulates the information they carry. The AT sends an ACK response through the Ack channel after the AT receives the fourth timeslots. The EV-DO Rev. A system divides the original 16-timeslot reverse frame of the EV-DO Rel. 0 system into four 4-timeslot sub-packets and then sends the four 4-slot sub-packets, with three sub-packets interleaving with each other. Figure 2-13 shows the HARQ that supports advance termination of reverse data. Figure 2-13 Reverse HARQ
The ARQ channel consists of the following three bits:
2-14
01 (2009-11-09)

H-ARQ: It is used for responding to the first three sub-frames. L-ARQ: It is used for responding to the fourth sub-frame. P-ARQ: It is used for responding to the whole physical packet.
2.6.2 Multiuser Scheduling

Timeslot resources are the most valuable resources in the forward links of the EV-DO system. To use the timeslot resources better, the EV-DO system allocates the timeslots of the forward links between multiple subscribers. In each timeslot, the served subscriber is chosen according to the multiuser scheduling rules.
2.6.3 Rate Control

2.6.3.1 Forward Rate Control
The EV-DO system provides an effective rate control algorithm for forward links. Figure 2-14 shows implementation of the algorithm. The algorithm consists of the following steps: 1. Estimate the Signal Interference and Noise Ratio (SINR) of the pilot. In each timeslot, the BTS delivers a forward pilot signal. The AT performs demodulation to obtain the SINR of the forward pilot. 2. Predict the channel. Predict the SINR of the forward pilot in the next timeslot according to the SNR of the previous forward pilots. 3. Get the maximum transmission rate supported by the forward link in the next timeslot according to the adaptive SINR threshold. Figure 2-14 Implementation of the rate control in a forward link
01 (2009-11-09)
2-15
Contents
2.6.3.2 Reverse Rate Control

The EV-DO Rev. A system provides a rate control algorithm for reverse links. For the process, see Figure 2-15. The algorithm consists of the following steps: 1. The BTS measures the reverse Rise over Thermal (ROT) and then compares it with the set threshold. The BTS then works out the current load of the system and gets the Reverse Activity Bit (RAB). The AT then gets the Quick RAB (QRAB) and the Filtered RAB (FRAB) based on the RAB. 2. The BTS sends the RAB to the ATs in the local sector through the RA sub-channel. 3. The AT combines the RABs sent by all BTSs in its active set and then requests the MAC protocol of the reverse TCH to choose the transmission rate of the reverse TCH according to the T2P algorithm. Figure 2-15 Implementation of rate control in a reverse link
The reverse T2P algorithm refers to the reverse rate control and load control algorithms introduced by the EV-DO Rev. A system.
2.6.4 Virtual Soft Handoff

One design objective of the EV-DO system is to support asymmetric high-speed burst packet services. The EV-DO system must guarantee a high transient bandwidth required for transmission of burst data, and it must also enable multiple subscribers to share the full power transmitted by the BTS in the time division mode to improve the capacity of the system. Therefore, the EV-DO system uses the virtual soft HO technology to balance the system capacity and to reduce the signaling overhead. The principle of virtual soft handoff is as follows: In each timeslot, the AT continuously measures the SNR of all pilots in the active set and then chooses the BTS with the biggest SNR as its serving BTS. The AT sends the DRC channel and the DSC channel to the BTS. The DSC channel indicates the serving BTS. The DRC channel consists of the serving sector ID (DRCCover) and the expected forward transmission rate (DRCValue). In each timeslot, the AT can perform forward data communication with the current serving sector only.
2-16
01 (2009-11-09)
Compared with the soft/softer handoff, the virtual soft handoff supports a lower handoff signaling overhead. The virtual soft handoff, however, fails to provide macro diversity gains that can be provided by the soft/softer handoff. To reduce the handoff delay due to virtual soft handoff during packet transmission of high-speed real-time services, the EV-DO Rev. A system uses the DSC channel.
2.6.5 Power Control

In forward links, the EV-DO system uses TDM supplemented by CDM. No power control is provided. In reverse links, the EV-DO system uses TDM supplemented by CDM. Power control is required to control interference caused by multiple subscribers. For details about the principle of reverse power control, see chapter 7 "Reverse Power Control."
2.6.6 Reverse Silence

2.6.6.1 Reverse Link Silence
The EV-DO Rev. A technology provides the reverse silence function. The network delivers the ReverseLinkSilencePeriod and ReverseLinkSilenceDuration parameters in the SectorParameters message. According to the specified period, the ATs in the sector stop the reverse transmission and access probe simultaneously for a period at the specified time. During this period, the system measures and updates the noise floor of the sector and uses the updated noise floor as the basis for reverse load control. The reverse link silence interval starts from the moment T (CDMA system time, unit: frame) and lasts for frames (number: ReverseLinkSilenceDuration). T meets the following condition:
T mod(2048 * 2
ReverseLinkSilencePeriod
1) = 0
2.6.6.2 Access Probe Transmission and Silence Period

Before sending the first probe of the probe sequence, the AT performs a silence interval test before a continuity test. The AT decides the interval and duration of the reverse link silence according to the message that carries sector parameters. When the ACH cycle starts, the AT is allowed to send the access probe if the transmission of the access probe does not overlap with the reverse link silence interval. If they overlap, the AT fails to send the probe before the next access channel cycle that meets the preceding condition. The procedure is as follows: In a probe sequence, the AT sends an access probe and then waits for a random time (p). When the previous access probe is complete, the AT starts a new probe p later. If any part of the new probe overlaps with the reverse link silence interval, the AT regenerates a pseudo-random number that ranges from 0 to ProbeBackoff (probe backoff time that often lasts for four ACH cycles) to recalculate p again. If the probe does not overlap with the reverse link silence interval, the AT sends the next access probe in the timeslot p after the previous probe is complete.
01 (2009-11-09)
2-17
Contents
2.7 Enhanced Performance of the EV-DO Rev. A System

The EV-DO Rev. A system improves the performance of the EV-DO Rel. 0 system to meet the requirements of new services and network functions.
Spectral efficiency The EV-DO Rev. A system supports more user packets and smaller packets to support more flexible service adaptation and packet encapsulation. Therefore, the spectral efficiency is improved.
Quick paging The EV-DO Rev. A system supports quick paging for real-time services by adding a shorter sub-synchronous control period in the control channel for sending paging messages.
Quick access The EV-DO Rev. A system shortens the access prefix by changing the data encapsulation format of the ACH. In addition, it speeds up the access and uses power bursts to greatly shorten the access time of real-time services.
System capacity In reverse physical links, the high order modulation and the HARQ are used. The flow control mechanism provided by the reverse MAC controls the T2P of reverse links. In this way, the ROT control threshold increases and the transmission rate and capacity of reverse links are greatly improved. In addition, throughput of forward links is further improved to support symmetric broadband multimedia services and to provide a higher system capacity required by packet data services.
QoS To support end-to-end (E2E) QoS services, the air interfaces provide an effective QoS guarantee mechanism that shortens the service delay greatly.
Service coverage The EV-DO Rev. A system controls forward link HOs more accurately to greatly shorten HO delay and to support seamless coverage of services.
Cross-paging The EV-DO system can transmit paging messages of the 1X system to save system resources.
2-18
01 (2009-11-09)
3 QoS Mechanism of the EV-DO Rev. A System
QoS Mechanism of the EV-DO Rev. A System
3.1 Real-Time Services

IP-based networks are the tendency of the telecom industry. In addition, the radio IP networks must bear real-time services such as Voice over IP (VoIP) and (VT). Therefore, the market requests the EV-DO Rev. A system to support real-time services. The packets of real-time services must be processed separately. The packets of different traffic streams need to be processed according to different QoS. Related Terms
IP Flow: It is specified by Flow Profile ID and corresponds exactly to ReservationLabel. Reservation: It is identified by ReservationLabel. The RLP Flow determines the corresponding Reservation through FlowNNReservationFwd/Rev.
RLP Flow: Each RLP flow has a unique RLP ID. When FlowNNIdentificationFwd is set to 0x01, the RLP flow on the forward link is activated. Similarly, when FlowNNIdentificationRev is set to 0x01, the RLP flow on the reverse link is activated. The maximum values of forward and reverse RLP flows are set through MaxNumRLPFlowsFwd.
MAC flow: (MAC Flow Id) MAC flow NN in the BucketLevelMaxNN > 0 attribute stands for the activated state. The maximum value is set by MaxMACFlows.

ROHC channels: It is a unidirectional channel between the AT and the PDSN on which ROHC is implemented. A ROHC channel can be a forward channel (decompressed on the AT) or reverse channel (decompressed on the PDSN). One A8/A10 connection can carry no more than one Forward ROHC Channel and no more than one Reverse ROHC Channel. The ROHC parameters are saved on the AN when the main instance is being set up. The ROHC channels between the AT and the PDSN are set up and the saved channel parameters are used when the assisted A8/A10 connection (SO67) is being set up. Forward channel parameters are the same as reverse channel parameters.
3.1.1 VoIP Service

The VoIP service is also called IP telephone or IP network telephone. With this technology, the voice data is coded, digitized, and then compressed into compressed frames. The compressed frames are then encapsulated into IP packets that can be transmitted over the IP network. Today, more and more evidence proves that the IP-based network is the developing
01 (2009-11-09)
3-1
Contents
tendency of the telecom industry. The traditional voice services over TDM will gradually and inevitably be replaced by VoIP. Figure3-1 shows the structure of a VoIP network. Figure3-1 VoIP network structure
The VoIP setup process is as follows: 1. Setting up the main connection and saving QoS and ROHC configuration parameters on the AN. 2. Setting up and configuring the SIP signaling control flow. Setting up the voice service stream and configuring QoS parameters. Configuring ROHC parameters. 3. The SIP registration is performed: The AT initiates the registration after the QoS feature is configured and then activated. 4. Activating the QoS feature. When it is the calling party, the AT must set up the SIP session. When it is the called party, the AT reacts after it receives the first SIP INVIT message. 5. Setting up the SIP session. 6. Starting conversation. The voice package follows the RTP/RTCP protocol and the RTP/UDP/IP header uses the ROHC. 7. Conversation ends and resources release.
3.1.2 VT Service
The VT service is the trend of the telecom industry in the future. The VT service enables subscribers during voice communication to receive the video information including dynamic and static video images. Subscribers can also terminate the video communication without impacting the voice communication. The VT service requires more resources. This leads to heavier loads on the system. Compared with the traditional voice communication, the VT communication requires higher transmission rate because the information to be transmitted increases. To lower the transmission load, the VT service uses video compression and coding technology. The technology requires less bandwidth for transmission but makes communication more prone to errors in transmission. Figure3-2 shows the structure of a VT network.
3-2
01 (2009-11-09)
Figure3-2 VT network structure
Several IP flows are established for a VT subscriber. Each flow corresponds to a Flow Profile ID. 1. Main service instance (SO59) 2. SIP control flow (SO64) 3. Voice RTCP packet flow (SO64): The X.R0039-0 v1.0 specifies that the voice RTCP flow must support RTCP or BE and its QoS attribute is the same as the QoS attribute of the SIP flow. 4. Voice packet RTP flow (SO67) 5. Video RTCP packet flow (SO64) 6. Video packet RTP flow (SO67) Corresponding to the RLP flow/A8/A10 connection flow, the SIP control flow, voice RTCP packet flow, and video RTCP packet flow can be merged into one flow (with the same QoS attribute). That is, four flows are required by the VT service.
3.1.3 Stream Media Service

With the stream media technology, the continuous video and voice information is compressed and then stored on a server. In this way, the end user can watch the video even if the multimedia file is being downloaded. The basic service modes are as follows:

On-demand Live Download
3.1.4 Broadcast Multicast Service

The broadcast multicast service (BCMCS) is used to broadcast data to the ATs in the coverage area of the service. In a communication network, some information is welcomed by many subscribers. Such information includes warning, news, weather forecast, stock information, traffic report, sports news, real estate information, lottery, and advertisement. The system broadcasts the information to subscribers who subscribe to such information. Subscribers can receive the information when working in the office, spending time at home or on a trip, shopping, walking dogs in the park, sailing on a yacht, or even exploring a forest. In addition, the BCMCS supports various terminals.
01 (2009-11-09) 3-3
Contents
The feature of the BCMCS is that only forward traffic links are available. Therefore, a large number of ATs can share the forward channel. This greatly improves the link usage and the system capacity. The forward channel, however, must support link quality required by all ATs that receive the broadcast messages. As shown in Figure3-3, the content server sends the data to the BTS. The BTS sends the data in the broadcast channel, and then the ATs can listen to and receive the data and decode and assemble them into the original information and send the information to the application layer. Figure3-3 Broadcast multicast service
Laptop computer Cell phone Lapto p
Cell phone
ed ar Sh
MA CD
st ca ad o Br
o di Ra
l ne an h C
Content Serve
Network
Base Station
Laptop computer
Cell phone
Laptop s
3.2 QoS Evaluation Indicators

To guarantee the end-to-end QoS of all services, the EV-DO Rev. A system supports the QoS implementation scheme. Due to the limitation on network bandwidth, transmission and process delay, or network congestion, delay and delay jitter occur when the data packets are being transmitted in the network. As a result, the voices or images received by subscribers are incoherent or even interrupted. During the evaluation of service quality, bandwidth, delay, and jitter are analyzed.
3.2.1 Bandwidth
Bandwidth refers to the amount of data that a communication system can transmit in a unit of time. Bandwidth reflects the transmission capability of the system and is sometimes used as a major yardstick for evaluating the capacity of the system. In a CDMA system, the system bandwidth is subject to restrictions of the bandwidth over the air interface. The bandwidth over the air interface is changeable, depending on factors such as the user type, service type, radio transmission environment, and radio resource allocation mechanisms.
3-4
01 (2009-11-09)
3.2.2 Latency
End-to-end delay is a key QoS index of real-time services. Delay exists at the access plane and non-access plane. Delay at the access plane refers to delay caused by processing at the link layer and physical layer. Delay at the non-access plane refers to delay caused by network transmission and conversion of media formats.
3.2.3 Jitter
Jitter refers to the change in delay. Jitter during data transmission severely harms the quality of real-time services. For example, some voice packets are sent from the source end at roughly the same intervals. However, the voice packets may encounter different delay lengths during queuing and processing, therefore arriving at the destination end at irregular intervals.
3.2.4 Error Rate

The error rate is the ratio of the number of unsuccessfully transmitted packets to the total number of transmitted packets in a certain period. The error rate is a key indicator of the transmission reliability of channels. Depending on the transmission modes of service data, the error rate may take different forms, for example, the frame error rate, packet error rate, and bit error rate.
3.3 QoS Service Model

The IETF provides two service models.

Integrated Service (IntServ) model DiffServ model Two models can be used separately or together.
3.3.1 IntServ Model

According to the Resource Reservation Protocol (RSVP), the IntServ model performs E2E resource reservation between the sending end and the receiving end of the data stream. It provides an E2E QoS guarantee and requires high processing and storage capacities from the route node. The network scalability of the IntServ model is low. The IntServ model applies to network edges or small-scale networks only.
3.3.2 DiffServ Model

To meet the requirement for network scalability, the IETF forwards the DiffServ model by simplifying the service mechanism and service object of the internal nodes in networks. This model performs only scheduling and forwarding in internal nodes and stream monitoring and state maintenance in border nodes. The internal nodes control the transmission of stream aggregates, and single stream control is performed at the network border. According to the profile and required QoS of streams, the border node aggregates the streams that enter the network to different stream aggregates. The aggregate information is stored in the differential service code point (DSCP) field of the headers of IP data packets. Based on the DSCP setting, the internal nodes schedule the data packets. The external activity of internal nodes is called per hop behavior (PHB). Single stream aggregation performed by border nodes cooperates with stream aggregate forwarding performed by internal nodes based on DSCP. The IETF defines the following four PHB service types:
01 (2009-11-09) 3-5
Contents

Best Effort (BE) Expedited Forwarding (EF) Assured Forwarding (AF) Class Selector (CS)
The DiffServ model can be implemented based on the hierarchical network structure. The DiffServ domain is divided into Differential Service Region (DSR) and Differential Service Domain (DSD). The DSR consists of several connected DSDs, and the DSD consists of several connected internal nodes. In a DSD, the service supply strategy must be consistent with that defined by the PHB. Between DSDs, the service supply strategy can be inconsistent with that defined by the PHB. Cross-region services are provided between DSDs based on the Service Level Agreement (SLA) and Traffic Conditioning Agreement (TCA). Each DSD has a clearly defined border. DSDs connect to non-DSDs through border nodes. Border nodes provide the following functions:

Traffic classification Measurement Labeling Traffic shaping Discard
Figure3-4 DiffServ work flow
Classification Select packets based on their headers according to specific rules. The classification modes are as follows:
Behavior aggregate (BA): Classify packets based on the DS domain of the IP packet header.
3-6
01 (2009-11-09)
Multi field (MF): Classify packets based on the aggregate of some domains in the IP packet header. The domains include the source and destination IP addresses, the source and destination port numbers, the DS domain, and the protocol number.
Measurement Measure time parameters (such as rate) of the traffic stream selected by the traffic classifier. The measurement result is used to control the labeling, shaping, and discard of traffic streams. The measurement result can also be used for statistics.
Labeling Set the DS domain of packets. This often occurs at the network border. Shaping Delay the output of packets in traffic streams to meet the requirements of the service model.
Discarding Discard packets according to specific rules.
The DiffServ model defines the strategies for the stream aggregate of border nodes and the stream forwarding of internal nodes. The DiffServ model is a priority service model based on strategy control. Network resources are allocated according to the general service strategy, and hop-by-hop resource reservation is not required. As a result, the DiffServ model is free of limited network scalability caused by distributed resource reservation in the IntServ model. The DiffServ model, however, cannot directly control a single stream. The service strategy used by the DiffServ model cannot guarantee enough network resources during the stream transmission. Therefore, the DiffServ model fails to provide an E2E QoS guarantee. The DiffServ model is often used in core network nodes.
3.4 E2E QoS Architecture

The QoS contains the following properties:

Bandwidth Delay Jitter Packet loss ratio Priority Service classification
The E2E QoS is guaranteed by segmentation of network element (NE) devices. See Figure3-5. QoS requirements vary with segments, and all segments work together to meet the QoS requirements of the upper layer. In addition, the parameters have mapping relations in different layers when the parameters are implemented. Therefore, the E2E QoS guarantee can also be classified into QoS guarantees of air interfaces and terrestrial links. Figure3-5 E2E QoS architecture
01 (2009-11-09)
3-7
Contents
The E2E QoS uses multi-layer service architecture.

The application layer describes E2E QoS requirements. The network layer describes the IP QoS requirements.
The bearer and transmission layers describe the QoS requirements of the lower layer bearer and transmission.
The QoS parameters are mapped and transferred between different QoS service layers.
3.4.1 E2E QoS Mechanism

The E2E QoS corresponds to the first layer of the E2E QoS service architecture. The application layer of the source end and that of the peer end negotiate the properties of the E2E QoS service parameters. The application layers then send the properties to the network layer by using related service data streams, service control streams, or service state streams.
3.4.2 IP QoS Mechanism

The IP QoS service corresponds to the second layer of the E2E QoS service architecture. In a CDMA2000 network, the IP QoS must be implemented in the ATs and in the core network. The network can use the DiffServ or IntServ model. The ATs must negotiate and identify IP QoS properties.
3.4.3 QoS Mechanism in the Bearer and Transmission Layers

The QoS of the bearer layer refers to the third layer of the E2E QoS service architecture. It consists of the following:

External network bearer Core network bearer Access network bearer
The access network bearer consists of the following:

R-P bearer Access bearer
3-8
01 (2009-11-09)
The QoS of the external network bearer layer and core network bearer layer relates to the transformation protocol of the link layer. To solve the QoS problems of the R-P bearer layer and the transmission layer, use excess configurations or the DiffServ model. The radio access network uses the following QoS control mechanisms:
Admission control Through this mechanism, the system determines whether the service requirements can be met according to the QoS requirements of the service and the available resources in the system. This mechanism requires accurate monitoring of the system load.
Load control The randomness of packet services makes the admission control difficult to meet the requirement. The moving of ATs also causes variation in system load. When the system load has changes, it can be adjusted through the load control mechanism.
Power control Power control can help reduce the effect of intra-frequency interference and near-far interference to improve the network performance.
Scheduling policy The transmission sequence is determined by the priorities of the services and subscribers. The priority is associated with factors such as the service or subscriber type, QoS requirements, radio link quality, available system resources, and array length.
3.5 QoS Guarantee of the EV-DO Rev. A System

3.5.1 Overview
The EV-DO Rev. A network is developed for high-speed real time multimedia packet data services that require the E2E QoS service. The system negotiates properties of the QoS parameters by using the main service instance and auxiliary service instances. All service instances are allocated with resources. When establishing a main service instance, the PDSN returns the A11-Session Update message to the QoS profile information about the subscriber to the AN. The AN needs to store the QoS profile information into the HRPD session information. The QoS profile information is used by the AT for real-time QoS configuration and service authentication. By default, the QoS of main service instances is set to Best-Effort. The auxiliary service instances are used to negotiate the QoS property over Best-Effort. The QoS property depends on the subscribers request and is restricted by the subscribers QoS configuration and the local strategy. According to the QoS property requested by the service, the AT can create one or more auxiliary service instances. The core network uses the DiffServ model to implement the IP QoS. The used QoS control strategies are as follows:

Service classification Measurement Labeling Shaping Discard
The access network implements the QoS by using radio resource management and link transfer technologies. The BTS sub-system implements the QoS control mechanism of forward links and the terminal implements the QoS of reverse links.
01 (2009-11-09) 3-9
Contents
3.5.2 Intra-User QoS Division

The EV-DO Rev. A system uses the multi-flow packet application protocol. Each subscriber can have multiple traffic streams with different QoS requirements. The data packets of the traffic streams have different priorities due to their different service properties. The priorities are reflected by radio resource management and terrestrial link resource management such as access control, load control, and priority scheduling. Services are classified into the following types during implementation of Huawei products:

Expedited Forwarding (EF): VoIP, VT, and Online Gaming Assured Forwarding (AF): Video Streaming Best Effort (BE): FTP and HTTP
3.5.2.1 Multi-Flow Mechanism

Multi-flow means that a subscriber instance provides the functions of several link streams simultaneously (corresponding to several RLP instances). Each link stream has its QoS property. A link can bear one or more upper layer traffic streams and can provide QoS guarantees to the borne traffic streams. Compared with the default packet application, the multi-flow packet application (MFPA) supports extra functions as follows:

Adding multi-flow processing in the RLP protocol Applying data bearer to signaling Supporting QoS
3.5.2.2 Multi-Flow Implementation

The EV-DO Rev. A system supports the Multi-flow Packet Application (MFPA). A connection layer packet (MAC layer packet) may contain one or more RLP flow packets. In addition, the RLP flow combinations carried by different connection layer packets may differ. The specific combination depends on the reverse T2P scheduling mechanism. Figure3-6 Multi-flow service mechanism
3-10
01 (2009-11-09)
The following describes the key concepts relating to multi-flow implementation.

IP flow It corresponds to a traffic stream. Each IP flow is identified by FLOW_ID (or ReservationLabel in the HRPD system). IP flows exist between the AT and the PDSN.
Reservation This is the air interface resource requested by the AT and created by the AN for bearing IP flows. It is identified with ReservationLabel. Reservations and IP flows are in a one-to-one mapping relation.
RLP link flow The main link flow bears the PPP control signaling and corresponds to SO59. The auxiliary link flow bears the IP flows that have QoS requirements. The options include SO64 and SO67. IP flows with similar QoS requirements can be carried by the same RLP link flow.
MAC flow The MAC flow is carried by the reverse traffic channel. Although a MAC flow can carry multiple upper layer flows, an RLP link flow is generally associated with an RTCMAC flow.
R-P connection A8/A10 connections: A8 connections have a one-to-one relation with A10 connections, and link flows have a one-to-one relation with R-P connections.
3.5.3 QoS between subscribers

For a private line subscriber, a radio environment test is required before subscription to guarantee its requested private line rate. For a regular subscriber, no radio environment test is required before subscription and no minimum rate is guaranteed.
3.5.3.1 Private Line Subscribers

Private line subscribers are fixed subscribers of the EV-DO system. They cannot move in the network. Before subscription, the radio environment is tested. The EV-DO system requires that the DRC (forward channel rate request sent by the AT according to the current forward channel environment in the system) of the subscriber should be over eight times the private line rate requested by the subscriber. In the reverse radio environment test, the maximum rate must meet the requirements to guarantee the private line rate requested by the subscriber. The system allows private line subscribers to access the network at any time.
3.5.3.2 Regular Subscribers

The system applies no special requirements to regular subscribers. In addition, the system does not guarantee access for regular subscribers. The maximum rate of background services is limited by subscriber grade. The BE services support three subscriber grades as follows:
Gold medal subscribers Gold medal subscribers have the highest priority and enjoy the highest peak rate. Silver medal subscribers Silver medal subscribers have higher priority and enjoy higher peak rate.
3-11
01 (2009-11-09)
Contents
Bronze medal subscribers Bronze medal subscribers have the lowest priority and the lowest peak rate.
The maximum rate of such subscribers can be customized according to the following rule: Maximum rate of gold medal subscribers maximum rate of silver medal subscribers maximum rate of bronze medal subscribers
3.5.4 QoS Guarantee of Terrestrial Links

Full IP transmission is used inside the AN. The AN supports the DiffServ model and implements traffic classification based on DiffServ Code Point (DSCP). The QoS of the terrestrial link is ensured through:

Traffic shaping Labeling strategy Scheduling strategy Discard strategy Flow control Congestion control
For details about implementation strategies, see the related sections in this document. Figure3-7 QoS guarantee of terrestrial links
3.5.5 QoS Guarantee of Air Interfaces

Air interface QoS is guaranteed through forward/reverse scheduling. For details, see the related sections in this document.
3-12
01 (2009-11-09)
4 Call Signaling Flow
4
4.1.1 Setting up an HRPD Session
Call Signaling Flow
This section describes the call signaling flows involved in the EV-DO Rev. A system.
4.1 HRPD Configuration Negotiation Flow

When an HRPD session is released due to the data card power-off or some other reasons, if data communication is required, an HRPD session and connection must first be set up and the related protocols and attributes must be negotiated. Note that the attribute configuration negotiated at the current session takes effect at the next connection setup. Therefore data communication begins at the setup of the next connection. Figure4-1 HRPD session setup process
01 (2009-11-09)
4-1
Contents
During the session setup procedure, upon receiving the UATI Request message, the AN sends the HardwareID Request message and the UATI Assignment message. The HardwareID Response message is no longer related to the session setup. That is, upon receiving the UATI Complete message, the AN considers that setting up the session succeeds. It does not matter if the HardwareID Response message is received after the session is set up.After the connection is set up, if the AN has not received the HardwareID Response message, the AN sends the HardwareID Request message to the AT again. If the AN has not received the HardwareID Response message after the configuration negotiation is complete, the session is released.
4.1.2 Configuration Negotiation

Each time the AT accesses the network, the AN checks whether the negotiation flag of the AT is consistent with that saved in the AN. If the negotiation flags are different from each other, it initiates the negotiation again. The negotiation process is triggered in the following cases: 1. The AT initiates the negotiation process when it attempts to access the network for the first time. 2. The AN triggers the configuration negotiation process in the following three cases:
During the inter-AN handoff process, the negotiation parameters in the session information from the source AN are different from those supported by the target AN. In this case, the AN initiates the configuration negotiation process. During the dynamic configuration process, the maintenance console dynamically changes the negotiation parameters. (In this case, the AN initiates the negotiation process not immediately but during the next access process of the AT.) During the signaling check process of the AC channel, if the negotiation flag in the packets sent by the AT is different from that saved in the AN, or is different from the negotiation parameters of the current access sectors, the AN needs to trigger the configuration negotiation process again.
Figure4-2 Configuration negotiation process
4-2
01 (2009-11-09)
3. First is the UATI assignment procedure. If the air interface of the EV-DO system does not use International Mobile Subscriber Identity (IMSI), the subscriber must be assigned with a UATI before session configuration. Hardware ID, which is ESN, is required by the system. Because the subscriber ID in the UATI Request message is RATI, the subscriber interface tracing at the maintenance console cannot trace the message. 4. The configuration negotiation is performed over the traffic channel. Therefore a connection must be set up first. On the other hand, the protocols specify that an AT cannot communicate with an AN if the session is not in the open state. Therefore the session must be opened by the default parameters. Default parameters of the sub-layers of each protocol are used for service setup. 5. After the connection is set up, the system enters the session configuration negotiation stage. Accordingly the SCP protocol enters the AT initiated state. First, the protocols and applications are negotiated and then the system enters the AN initiated state. The conversion message is the Configuration Complete message. The parameter configuration of the sub-layers of each protocol is negotiated. The configuration of each protocol and application must be compliant with the specifications of the configuration. 6. Upon finishing the attribute configuration negotiation, the AN sends Configuration Complete to complete the configuration negotiation, or sends Soft Configuration Complete to move to AT initiated state. Then, the system starts negotiating the next personality.
01 (2009-11-09)
4-3
Contents
7. After the configuration negotiation is over, the connection must be released. Because the initial connection is set up according to the default parameters, the new configuration negotiation parameters can be used only after a new connection is set up. 8. Completion of the session setup triggers a location update procedure to let the AN know the position of the AT. Pay attention to the following points during configuration negotiation:
After the configuration negotiation is over, the connection must be released (cause value 0x1202). Connection negotiation is not immediately set up after dynamic configuration. Next time when the AT initiates a connection, the connection must be negotiated first.
If the negotiation fails (such as timer timeout), the session is released. If the negotiation is not supported, both the AN and AT use the default values.
4.2 Keeping an HRPD Session Alive

After a session is set up, the AN keeps the session information on the BSC, and the AT is in the detecting state. The AN checks the AT state by detecting the traffic from the AT in the reverse channel. If the AN detects that the inactive period of an AT reaches TSMPClose/NSMPKeepAlive minutes (0x0CA8/3, 54 hours by default), the AN initiates the sessions keep alive process. An AT cannot initiate a sessions keep alive process. Figure4-3 Process of keeping an HRPD session alive
4.3 Releasing an HRPD Session

4.3.1 HRPD Session Release Initiated by an AT
An A8 connection and an A10 connection exist when the HRPD session is active. In this case, the procedure for HRPD session release initiated by an AT is as follows: Figure4-4 Process of session release initiated by the AT (with the A8 connection)
4-4
01 (2009-11-09)
1. The AT sends a SessionClose message to initiate the release process of the HRPD session. 2. The AN stops the HRPD session with the AT. The AN then sends an A9-Release-A8 message (cause value: normal call disconnection) to the PCF, requesting the PCF to release the A8 connection. 3. The PCF sends an A11-Registration Request message (Lifetime: 0) to request A10 connection release. 4. The PDSN sends an A11-Registration Reply message ((Lifetime: 0) to the PCF, confirming A10 connection release. 5. The PCF sends an A9-Release-A8 Complete message to the AN, confirming A8 connection release. The release of the HRPD session is complete. No A8 connection exists between the AN and the PCF when the HRPD session is dormant. In this case, the procedure for HRPD session release initiated by an AT is as follows: Figure4-5 Process of session release initiated by the AT (without the A8 connection)
1. The AT sends a SessionClose message to initiate the release process of the HRPD session. 2. The AN stops the HRPD session with the AT. The AN then sends an A9-Update-A8 message (cause value: power-off in the dormant state) to the PCF, requesting the PCF to release related resources and the A10 connection.
01 (2009-11-09)
4-5
Contents
3. The PCF sends an A11-Registration Request message (Lifetime: 0) to request A10 connection release. 4. The PDSN sends an A11-Registration Reply message ((Lifetime: 0) to the PCF, confirming A10 connection release. 5. The PCF sends an A9-Update-A8 Ack message to the AN, confirming A8 connection release. The release of the HRPD session is complete.
4.3.2 HRPD Session Release Initiated by an AN

An A8 connection and an A10 connection exist when an HRPD session is active. In this case, the AN initiates HRPD session release due to specific causes (such as a failure in signaling transfer, re-negotiation, or re-authentication on the A13 interface during an inter-subnet HO). Figure4-6 Process of session release initiated by the AN (with the A8 connection)
1. The AN sends a SessionClose message to the AT to initiate the release process of the HRPD session. 2. The AT sends a SessionClose message back to the AN, confirming the release of the HRPD session. 3. The AN stops the HRPD session with the AT. The AN then sends an A9-Release-A8 message (cause value: normal call disconnection) to the PCF, requesting the PCF to release the A8 connection. 4. The PCF sends an A11-Registration Request message (Lifetime: 0) to request A10 connection release. 5. The PDSN sends an A11-Registration Reply message ((Lifetime: 0) to the PCF, confirming A10 connection release. 6. The PCF sends an A9-Release-A8 Complete message to the AN, confirming A8 connection release. The release of the HRPD session is complete. The release of the HRPD session is complete. No A8 connection exists if the HRPD session is dormant. The AN initiates the release of the HRPD session in any of the following cases:

HRPD session timeout Failure of configuration negotiation Failure of key exchange

01 (2009-11-09)
4-6

Failure of CHAP authentication
Figure4-7 Process of session release initiated by the AN (without the A8 connection)
1. The AN sends a SessionClose message to the AT to initiate the release process of the HRPD session. 2. The AT sends a SessionClose message back to the AN, confirming the release of the HRPD session. 3. The AN stops the HRPD session with the AT. The AN then sends an A9-Update-A8 message (cause value: power-off in dormant state) to the PCF, requesting the PCF to release related resources. 4. The PCF sends an A11-Registration Request message (Lifetime: 0) to request A10 connection release. 5. The PDSN sends an A11-Registration Reply message ((Lifetime: 0) to the PCF, confirming A10 connection release. 6. The PCF sends an A9-Update-A8 Ack message to the AN, confirming the release of the related resources. The release of the HRPD session is complete.
4.4 Setting Up an HRPD Connection

The setup of HRPD connections can be initiated by an AT or by the AN. The AN can initiate fast connection setup. The HRPD connections are set up in many scenarios. The scenarios of the HRPD connection setup are as follows: 1. Before the configuration negotiation On completion of the UATI assignment, the AT sends a ConnectionRequest message to trigger the AT-initiated air interface connection setup process. Then the air interface link is set up and the configuration negotiation is performed. When the negotiation is complete, the connection is released. (The connection on the A8/A10 interface is not set up). 2. After the configuration negotiation
01 (2009-11-09)
4-7
Contents
On completion of the configuration negotiation, the AT sends the XonRequest message on the AccessStream. Upon receiving the XonRequst message, the AN triggers the AN-initiated air interface connection setup process or the AN-initiated quick connection setup process to set up the air interface connection and authenticate the connection. When the authentication is complete, the AN triggers the AN-initiated A10 connection setup (DRI = 0) process. 3. To send data by the AT The AT sends the ConnectRequest message to trigger the AN-initiated A10 connection setup (DRI = 0) process, and then triggers the AT-initiated air interface connection setup process before transmitting data. 4. To conduct a call test For the test items that require the setup of connections with the AT, the AN-initiated air interface setup process (The A10 connection is not set up) is triggered during the test. 5. To send data by the PDSN If the PDSN needs to send data, trigger the procedure for connection setup initiated by the PDSN.
4.4.1 AT-Initiated HRPD Connection Release Process

An AT initiates setup of an HRPD connection if the AT needs to transmit data. (Assume that an HRPD session exists.) Figure4-8 AT-Initiated HRPD Connection Setup Process
4-8
01 (2009-11-09)
1. The AT sends a Connection Request message and a Route Update message to the AN through the ACH, requesting the AN to assign a TCH. 2. The AN sends a Traffic Channel Assignment message to the AT, specifying the channel and the active set to be monitored by the AT. The AT switches over to the channel specified by the AN and then sends a Traffic Channel Complete message to the AN. 3. A8/A9 and A10/A11 connections are set up. 4. The PPP connection between the AT and the PDSN is set up. 5. The AT and the PDSN exchange packet data after connection setup.
4.4.2 AN-Initiated HRPD Connection Setup Process

An AN initiates setup of an HRPD connection if the AN needs to transmit data. Figure4-9 AN-Initiated HRPD Connection Setup Process
01 (2009-11-09)
4-9
Contents
1. The PPP session between the AT and the PDSN is dormant. The PDSN sends packet data to the PCF, indicating that the network has data to be sent to the AT and requesting for the setup of an air interface connection. 2. The PCF sends an A9_BS service Request message to the AN, requesting for activating the HRPD session and for setup of an HRPD connection. 3. The AN sends an A9_BS service Response message to the PCF. 4. The AN sends a Page message to the specified AT through the control channel. 5. The AT sends a Connection Request message and a Route Update message to the AN through the ACH, requesting the AN to allocate a reverse TCH. 6. The AN sends a Traffic Channel Assignment message to the AT, specifying the channel and the active set to be monitored by the AT. The AT switches over to the channel specified by the AN and then sends a Traffic Channel Complete message to the AN. 7. The AN sets up an A8/A9 connection with the PCF. The HRPD connection setup is complete.
4.4.3 Quick Connection Setup

The AT and the AN activate the Suspend Time timer when releasing an HRPD connection. If the AN needs to send data before the timer expires, the AN triggers a TCA message by using the RouteUpdateOpen command to set up a connection. The related fields in the TCA message carry the contents reported by the latest RU message. The fast connection setup is free of exchange of the CR message and the Page message. Supporting the quick connection setup is optional for ANs but is mandatory for ATs. Figure4-10 Procedure for quick connection setup
4-10
01 (2009-11-09)
4.5 Releasing an HRPD Connection

4.5.1 AT-Initiated HRPD Connection Release Process
Figure4-11 AT-initiated HRPD connection release process
1. 2. 3.
After sending the packet data, the AT initiates the release of the air interface connection by sending a ConnectionClose message in the reverse TCH. The AN sends an A9-Release-A8 message (cause value: packet call enters the dormant state) to the PCF, requesting for A8 connection release. The PCF sends an A11-Registration-Request message to the PDSN and uploads the Active Stop billing record.
01 (2009-11-09)
4-11
Contents
4. 5.
The PDSN sends an A11-Registration-Reply message to the PCF. The PCF sends an A9-Release-A8 Complete message to the AN, confirming A8 connection release. Note that the A10 connection remains in this case
4.5.2 AN-Initiated HRPD Connection Release Process

Figure4-12 AN-initiated HRPD connection release process
1. 2. 3. 4. 5. 6.
The AN sends an A9-Release-A8 message (cause value: packet call enters the dormant state) to the PCF, requesting for A8 connection release. The PCF sends an A11-Registration Request message to request A10 connection release. The PDSN sends an A11-Registration-Reply message to the PCF. The PCF sends an A9-Release-A8 Complete message to the AN, confirming A8 connection release. The AN sends a ConnectionClose message to the AT, requesting release of the air interface connection. The AT sends a ConnectionClose message to the AN, confirming release of the air interface connection.
4.6 Handoff
4.6.1 Soft Handoff
The EV-DO has gain of soft handoff only in the reverse direction. The previous versions only support intra-AN soft handoff. In the case of the version later than BSC V300R006C02, the system supports inter-AN soft handoff, greatly improving the user experience at the AN border. Inter-AN soft handoffs are recommended for the BSC6680 V3R6C03B015SPC004 and later versions.
4.6.1.1 Intra-AN Soft Handoff

Intra-AN soft handoff
4-12
01 (2009-11-09)
Figure4-13 Procedure of intra-AN soft handoff
1. 2.
After the AT detects that the intra-frequency neighbor signal strength is above or below the threshold, it reports the RouteUpdate message. If the system determines that the neighbor cell information contained in the RouteUpdate message meets the condition of addition or deletion a leg, the AN delivers the TrafficChanelAssignment message, notifying the AT to add a leg or delete a leg. Upon receiving TrafficChannelAssignment, the AT adds or deletes a leg according to the message and reports a TrafficChannelComplete message to the system.
3.
4.6.1.2 Inter-AN Soft Handoff

The signaling flow of adding a leg is different from the signaling flow of deleting a leg in the inter-AN soft handoff. The signaling flow to add a leg is shown in the following figure (assuming that all the pilots of the current active set belong to the source AN): Figure4-14 Procedure of inter-AN soft handoff to add a leg
AT RU A17-A llocate Request A17-A llocateAck TrafficChannelAssignment ResetReport TrafficChannelComplete NeighborList S-AN T-AN 1 2 3 4 5 6 7
1. 2.
The AT reports the RU message. The system determines that it is an inter-AN soft handoff and that a leg needs to be added. The source AN sends the A17-Allocate Request message to the target AN, requesting the target AN to allocate resource. The target AN sends the A17-Allocate Ack message to the source AN. The source AN sends the TCA message to the AT. The source AN sends the ResetReport message to the AT to reset the RouteUpdate message report mechanism. The AT sends a TCC message that is received simultaneously by the source leg and the target leg. The source AN sends the NeighborList message. In this case, the source leg functions as the serving leg.
3. 4. 5. 6. 7.
01 (2009-11-09)
4-13
Contents
The signaling flow to delete a leg is shown in the following figure (assuming that the last pilot of the active set to be deleted belongs to the target AN). Figure4-15 Procedure of inter-AN soft handoff to delete a leg
1. 2. 3. 4. 5. 6. 7.
The AT reports the RU message. The system determines that it is the inter-AN leg deletion. The source AN sends the TCA message to the AT. The source AN sends the ResetReport message to the AT to reset the RouteUpdate message report mechanism. The AT returns the TCC message. After the source AN successfully receives the TCC message, the target AN sends the A17-Deallocate Request message to request deleting related resource. The target AN sends the A17-Deallocate Ack message to the source AN. The source AN sends the NeighborList message to the AT.
4.6.2 Hard Handoff

The hard handoff is classified into intra-AN hard handoff and inter-AN hard handoff.
4.6.2.1 Intra-AN Hard Handoff

The following figure shows the procedure of intra-AN hard handoff. Figure4-16 Procedure of intra-AN hard handoff
4-14
01 (2009-11-09)
1. 2. 3. 4. 5. 6. 7. 8. 9.
The AT sends the RouteUpdate message to the AN. The AN determines whether to trigger intra-AN hard handoff. The AN sends the A9 Al Disconnected message to the source PCF, requesting the source PCF to stop sending data to the AT. Upon receiving the A9 Al Disconnected message, the PCF notifies the PDSN to stop sending the data and sends the A9 Al Disconnected Ack message to the AN. Establish new Abis interface resource. The AN sends the ConnectionClose+TrafficChannelAssignment message to the AT. The AT sends the ConnectionClose message. The AT sends Pilot and DRC channels. After the system captures the reverse channel, the AN sends the RTC ACK message. After the AT successfully captures the TrafficChannelComplete message to the AN. forward channel, it sends the
10. The AN sends the A9-AL Connected message to the PCF, and assembles and sends the message to the PDSN. 11. Upon receiving the Ack message from the PDSN, the PCF sends the A9-AL Connected Ack message to the AN and starts sending data. 12. The AN releases the old Abis interface resource to complete the handoff.
4.6.2.2 Inter-AN Hard Handoff

The following figure shows the procedure of inter-AN hard handoff. Figure4-17 Procedure of the inter-AN hard handoff
01 (2009-11-09)
4-15
Contents
AT Source AN Source PCF Target AN

Target PCF PDSN
RouteUpdate
1 A9 Al Disconnected A9 Al Disconnected Ack A16-Session Transfer Request A9 Setup A 8 A11-Registration Request A11-Registration Reply A10: XOFF
2 3 4 5 6 7
A9 Connect A 8 A16-Session Transfer Response ConnectionClose + TrafficChannelAssignment A16-Session Transfer Complete ConnectionClose TrafficChannelComplete A9 Al Connected
8 9 10
11 12 13 14 A11-Registration Request A11-Registration Reply 15 16 17 18 19 20
A9 Al Connected Ack UATIAssignment UATIComplete
A16-Session Release Indication A16-Session Release Indication Ack
21 22
Connection Between AT and Target AN Closes
23
A13-Resource Release Request A13-Resource Release Response
24 25
1. 2. 3.
The AT sends the RouteUpdate message to the source AN. The source AN sends A9 Al Disconnected message to the source PCF, requesting the source PCF to stop sending data to the AT. Upon receiving the A9 Al Disconnected message, the source PCF sends the inband flow control XOFF to notify the PDSN to stop sending data and sends the Ack message to the source AN. The source PCF sends the A9 Al Disconnected Ack message to the source AN. The source AN sends the A16-Session Transfer Request message to the target AN to request transfer of the connected session.
4. 5.
4-16
01 (2009-11-09)
6. 7. 8. 9.
Upon receiving the A16-Session Transfer Request message, the target AN sends the A9 Setup A8 message to the target PCF. Upon receiving the A9 Setup A8 message, the target PCF sends the A11-Registration Request message to the PDSN and waits for the response. The PDSN sends the A11-Registration Reply message to the target PCF. Upon receiving the Ack message from the PDSN, the target PCF sends the A9 Connect A8 message to the target AN.
10. The target AN sends the A16-Session Transfer Response message to the source AN. 11. The source AN sends the ConnectionClose and TrafficChannelAssignment messages to the AT. 12. The source AN sends the A16-Session Transfer Complete message to the target AN. 13. The AT sends the ConnectionClose message to the source AN. 14. The AT sends the TrafficChannelComplete message to the target AN. 15. After capturing the AT, the target AN sends the A9 Al Connected message to the target PCF. 16. The target PCF sends the A11-Registration Request to the PDSN. 17. The PDSN sends the A11-Registration Reply message to the target PCF. 18. Upon receiving the Ack message from the PDSN, the target PCF sends the A9 Al Connected Ack to the target AN. 19. The target AN sends the UATIAssignment message to the AT to assign a new UATI. 20. The AT sends the UATIComplete message to the target AN. 21. The target AN sends the A16-Session Release Indication message to the source AN to notify the source AN to release the session. 22. The source AN sends the A16-Session Release Response to the target AN. 23. The connection between the target AN and the AT is released. 24. The target AN sends the A13-Resource Release Request message to the source AN, notifying the source AN to re-assign the original UATI to other AT. 25. The source AN sends A13-Resource Release Response message to the target AN.
4.6.3 Call Migration

An EV-DO call migration is equivalent to an inter-AN hard handoff. The signaling flow of call migration is the same as that of inter-AN hard handoff.
4.6.4 Intra-AN Dormant Handoff

Figure4-18 Procedure for intra-AN dormant handoff
01 (2009-11-09)
4-17
Contents
1. 2.
The AT and AN update the UATI. The system initiates AT location update.
The AN updates A10/A11 through A8/A9. After this is complete, the AN releases A8/A9 and enters the dormant state.
4.6.5 Inter-AN Dormant Handoff

The following figure shows the procedure for inter-AN dormant handoff. Figure4-19 Procedure for inter-AN dormant handoff
1.
The AT initiates a UATI update on the target AN.
4-18
01 (2009-11-09)
2. 3. 4.
The target AN and source AN implement session migration through the A13 Session info Request/A13 Session info Response/A13 Session info Confirm message. The target AN initiates location information update on the AT. The target AN sets up an A10/A11 connection with the T-PCF, and then releases the A8/A9 connection. The AT enters the dormant state.
4.6.6 Interoperation
The system supports the following three interoperations: 1. 2. 3. 4. 5. Dormant handoff of packet data service from 1X to Rev. A Dormant handoff of packet data service from Rev. A to1X Active State Handoff of Packet Data Service from Rev. A to 1X Active State Handoff from Rev. A Data Service to 1X Voice Service This chapter describes the handoff procedure for each interoperation.
4.6.6.1 Dormant Handoff of Packet Data Service from 1X to Rev. A

The following figure shows the procedure for dormant handoff of packet data services from the 1X system to the EV-DO Rev. A system. Figure4-20 Procedure for dormant handoff of packet data services from the 1X system to the EV-DO Rev. A system
01 (2009-11-09)
4-19
Contents
1.
If the target AN detects no air interface session, it performs UATI assignment and session configuration negotiation to set up a session between the hybrid terminal and the target AN. The AT indicates that it is ready for data exchange on access streams. The AN performs PPP and LCP negotiation with the AT, and configures the CHAP authentication protocol type. The target AN generates an authentication random number and then sends it in the CHAP-Challenge message to the hybrid terminal. The hybrid terminal calculates the authentication result and then sends it in the CHAP-Response message to the AN. The AN sends the A12 Access-Request message that carries the authentication random number, the authentication result reported by the hybrid terminal, and the authentication parameters such as NAI to the AN-AAA. The AN-AAA performs authentication based on the MD5 algorithm and then compares the result with the authentication result reported by the terminal. If the authentication results are the same, the AN-AAA sends an A12-Access Accept message to the target AN. After receiving the A12-Access Accept message, the target AN notifies the terminal of the authentication success by sending a CHAP-Auth Success message. The hybrid terminal updates the location, indicating that it accesses a new AN. The target AN sends an A9-Setup-A8 message (Data Ready Indicator: 0).
2. 3. 4.
5.
6.
7. 8. 9.
10. The target PCF sends an A11-Registration Request message, requesting the PDSN to set up an A10 connection. 11. The PDSN sends an A11-Registration Reply message to the target PCF, confirming A10 connection setup. 12. The PDSN sends an A11-Registration Update message to the source PCF to initialize A10 connection release. 13. The source PCF sends an A11-Registration Acknowledge message to the PDSN. 14. The source PCF sends an A11-Registration Request message (Lifetime: 0) to the PDSN, requesting the PDSN to release the A10 connection. 15. The PDSN sends an A11-Registration Reply message to the source PCF, confirming A10 connection release.
4.6.6.2 Dormant Handoff of Packet Data Services from Rev. A to 1X

The following figure shows the procedure for dormant handoff of packet data services from the EV-DO system to the 1X system. Figure4-21 Procedure for dormant handoff of packet data services from the EV-DO Rev. A system to the 1X system
4-20
01 (2009-11-09)
1.
The hybrid terminal switches over to the 1X system and then sends an Origination message (DRS: 0) to the BTS. The Origination message carries the SID, NID, and PANID of the terminal in the source PCF so that the target PCF can set the PANID in the A11-Registration message. The BTS sends a BS Ack Order message to the terminal. The target PCF sends an A11-Registration Request message to the PDSN, requesting the PDSN to set up an A10 connection. (The value of the PANID field in the A11-Registration Request message is the PANID carried in the Origination message.) The PDSN sets up an A10 connection and then notifies the target PCF of the setup by sending an A11-Registration Reply message. Dormant handoff from the EV-DO Rev. A system to the 1X system is complete. The PDSN sends an A11-Registration Update message to the source PCF to initialize A10 connection release. The source PCF sends an A11-Registration Acknowledge message to the PDSN. The source PCF sends an A11-Registration Request message (Lifetime: 0) to the PDSN, requesting the PDSN to release the A10 connection. The PDSN sends an A11-Registration Reply message to the source PCF, confirming A10 connection release.
2. 3.
4.
5. 6. 7. 8.
4.6.6.3 Active State Handoff of Packet Data Service from Rev. A to 1X

The following figure shows the procedure for active handoff of packet data services from the EV-DO system to the 1X system. Figure4-22 Procedure for active state handoff from Rev. A to 1X packet data service
01 (2009-11-09)
4-21
Contents
The procedure is the same as the procedure of dormant handoff from Rev. A to 1X packet data service, except that the AT that actively requires the release of the EV-DO connection is added.
4.6.6.4 Active State Handoff from Rev. A Data Service to 1X Voice Service
Active State Handoff from Rev. A Data Service to 1X Voice Service Figure4-23 Procedure for active state handoff from Rev. A data service to 1X voice service
4-22
01 (2009-11-09)
1. 2. 3. 4. 5. 6.
The AT receives a voice service paging message from the 1X when the DORA is in active state. (In this case, for DORA, the air interface of the AT is lost.) The AT stops the EV-DO data transmission and enters dormant state. The AT sends the Page Response message. The system returns the Ack message and sets up the 1X traffic channel. The AT returns the Service Connect message. When the timer expires, if the voice call is still not ended, the A11 connection will be released.
4.7 Access Authentication

Access authentication is classified into the following two types: Initial access authentication It indicates the access authentication after the initial the setup of a session. Re-authentication It indicates the access authentication after the initial access of a subscriber after a given point in time. The following figure shows the procedure for initial access authentication. Figure4-24 Process of Access Authentication
01 (2009-11-09)
4-23
Contents
The procedure for access authentication includes steps 5 to 10. The procedure is the same for both initial access authentication and re-authentication. 1. Steps 1 to 3 show the procedure for session setup and configuration negotiation. For details, see the related section in this document. 4. The AN sends a Page message to the AT to start initial access authentication. 5. The AT and the AN perform PPP and LCP negotiation about the size of PPP data packets and the authentication protocol type (such as CHAP). The AN generally sets the authentication protocol type to CHAP and initiates access authentication. 6. The AN sends a CHAP-Challenge message that carries the authentication random number to the AT. 7. The AT uses the MD5 algorithm to work out the authentication result based on the authentication random number and then sends the CHAP-Response message to the AN. The CHAP-Response message carries authentication parameters such as NAI and CHAP-Challenge. 8. The AN sends an A12-Access Request message to the AN-AAA. The A12-Access Request message carries authentication parameters such as NAI and CHAP-Challenge and AN-IP. 9. The AN-AAA uses the MD5 algorithm to work out the authentication result based on the authentication parameters (such as NAI and CHAPPassword) carried in the A12-Access Request message. The AN-AAA then compares the result with the authentication result reported by the AT. If the authentication results are the same, the AN-AAA sends an A12-Access Accept message to the target AN. If the authentication results conflict, the AN-AAA sends an A12-Access Reject message to the AN. If the authentication password is null, the AN-AAA discards the A12-Access Request message. 10. If the AN-AAA allows the AT to access the AN, the AN obtains the IMSI by analyzing the property field of the A12-Access Accept message and then sends the CHAP-Auth Success
4-24
01 (2009-11-09)
message to the AT. If the AN-AAA rejects the AT to access the AN, the AN sends a CHAP-Auth Failure message to the AT. 11. If the CHAP authentication is successful, the air interface PPP connection is set up between the AT and the AN. If the CHAP authentication fails, the air interface PPP connection between the AT and the AN is released.
4.8 Location Update

If the RANHandoff parameter in the configuration properties is 0x01 and the AT detects a location update (such as changes in ANID, PZID, SID, and NID), the AT initiates a location update by sending a LocationNotification message. Upon HRPD session setup or during an inter-AN dormant HANOFF, the AN initiates a location update by sending a LocationRequest message. Figure4-25 Procedure for location upgrade
Steps 1 to 4 show the AN-initiated process for a location update. Steps 2 to 4 show the AT-initiated process for a location update. 1. 2. 3. 4. The AN sends a LocationRequest message to query the ANID stored on the AT. The AT sends a LocationNotification message that carries the ANID stored on the AT to the AN. The AN sends a LocationAssignment message to the AT, requesting the AT to update the ANID. The AT sends the LocationComplete message, informing the AN of the location update.
01 (2009-11-09)
4-25
5 Admission and Load Control
5
5.1 ACH Load Control
Admission and Load Control
5.1.1 Algorithm Background

If two or more access messages collide, the BTS receives high-power signals but fails to demodulate them. To reduce access collision, limit the access probe frequency of ATs and reduce load on ACHs.
5.1.2 Function Description

The channel occupancy ratio and the collision rate of an ACH reflect the ACH load. If a large number of subscribers initiates access probes simultaneously, the channel usage and the collision rate of the ACH rise.
5.1.2.1 Calculation of ACH Occupancy Ratio

Only one access capsule, which may include multiple access channel packets, is sent in an access channel cycle. If more than one access capsule is sent in an access cycle, the capsules collide. The access capsules sent in different access channel cycles can be overlapped. The ACH occupancy ratio is the ratio of the number of access capsules to the number of access channel cycles.
5.1.2.2 Calculation of ACH Collision Rate

When the CSM6800 decodes an access packet, it can confirm whether the access packet is demodulated successfully and whether the CRC passes. The BTS chip provides the energy (EcpNt) of each finger of the ACH/TCH and the total energy (CombinedAverageEcpNt). The two parameters are used to calculate the access collision rate according to whether the access packet is demodulated successfully.
5.1.2.3 ACH Load Control

Both the Default Access Channel MAC Protocol and the Enhanced Access Channel MAC Protocol provide the APersistence field that controls the transmission frequency of access probe sequences for ATs of different grades. When an AT sends the first probe of each probe sequence, it performs a persistence test. Assume that the grade of the AT is I (i = 0, 1, 2, or 3). The AccessParameters message
01 (2009-11-09)
5-1
Contents
carries the APersistence[i] parameter. Calculate the probability (p) of the persistence test of the AT. When the AT sends the first probe of the probe sequence, x that ranges from 0 to 1 is randomly generated. If x is smaller than p, the test is passed. If the number of continuous failures exceeds 4/p and the start time is not in the silence period or in the forward channel listening period, the AT can send the access probe in the incoming ACH cycle. In other cases, the AT must perform a silence period test again. To control the ACH load, control the frequency at which ATs send access probe sequences by adjusting the value of the APersistence[i] (i = 0, 1, 2, or 3) parameter. The access channel load control algorithm supports the following three functions: 1. Disabling the adjustment. 2. Load control based on occupancy and APersistence[i] adjustment based on the step 3. Load control based on occupancy and collision, and APersistence[i] adjustment based on step The subscribers in the ACH load control area are classified into four grades: private line subscribers, gold medal subscribers, silver medal subscribers, and copper medal subscribers. APersistence is adjusted in the following two methods: 1. Focusing on the grade of subscribers. When the access load is high, the value of Apersistence of low-grade subscribers is increased up to the maximum value. When the access load is low, the value of Apersistence of high-grade subscribers is decreased. This method may result in complete access failures of low-grade subscribers, but it has no impact on the subscriber with high grade. The difference between different subscribers with high grade is not reflected, that is, the access delay is not directly proportional to the grade. 2. Focusing on fairness. The Apersistence of the subscribers is averaged without focusing on the grade.
5.1.3 Application Scenarios

Set different APersistence values for subscribers of different grades. Subscribers of higher grades have higher access priorities.
5.2 Forward Admission and Load Control

During operation, the system load changes due to the following reasons: new call access, flow activation, AT movement, data bursts in the application layer, and changes in the radio environment. If carrier load reaches a certain degree, the subscriber QoS deteriorates, especially for the low priority services. In this case, admission control or even call release is required to reduce the carrier load. As a result, subscribers with a good radio environment enjoy enhanced services. Thus, the system operates stably and performs better.

When a forward flow is activated, the admission control is performed based on the forward load of the carrier indicated by the DRC of the AT. The forward admission control is
5-2 01 (2009-11-09)
performed according to the static bandwidth and is based on the real-time monitoring of the timeslot usage. These two admission control methods are not chosen through a switch. Only when a subscriber is admitted by these two methods, the access requests are admitted. To disable one of the methods, set the threshold value to the maximum. The private line subscriber is always admitted.
5.2.2.1 Admission Control Based on Number of Subscribers

Admission control specifies the maximum number of subscribers that are allowed to access a CDMA2000 EV-DO sector carrier. If the maximum number is large, many subscribers can access the network, but the service quality of a single subscriber is low.
5.2.2.2 Admission and Load Control Based on Timeslot Usage

During admission control, the timeslot usage of all EF streams on a carrier cannot exceed the maximum timeslot usage threshold of EF streams; the timeslot usage of all EF and AF streams on a carrier cannot exceed the maximum total timeslot usage threshold of EF and AF streams.
5.2.2.3 Admission Algorithm of the Air Interface Forward BE Service

The load is calculated through the equivalent rate of the subscriber. The time when there is no data transmission is not counted as the effective transmission time. If the equivalent rate is high, it indicates that the system possesses sufficient resources, the load of the system is light, and admission of the subscriber is not limited. If the equivalent rate is low, it indicates that the load of the system is heavy, and the admission control and load control should be performed according to the actual situation. If the system is overloaded to some extent, this algorithm denies the admission of subscribers in poor radio environments. If the system is overloaded to a moderate extent, this algorithm denies the admission of all subscribers. If the system is overloaded to a great extent, the subscribers in poor radio environments are deleted.

Admission control applies to connection setup, soft handoff branch addition, and flow activation in the EV-DO system.
5.3 DORA Reverse Load and Admission Control

Compared with the EV-DO Rel. 0 subscribers, the reverse rate of the EV-DO Rev. A subscribers is greatly improved. The peak rate of a single subscriber is increased 120 times. Thus, the EV-DO Rev. A subscribers contributes more to the reverse ROT than the EV-DO Rel.0 subscribers. Without enabling the reverse load control, three to five EV-DO Rev. A subscribers near the lab can make the ROT 50 dB. In this case, new subscribers cannot access the system, and the subscriber feeling is deteriorated. Thus, the reverse load control function of the EV-DO Rev. A network should be enabled for commercial use. The reverse rate control is performed through the T2P algorithm in the EV-DO Rev. A system. Compared with the reverse shift probability matrix algorithm of the EV-DO Rel.0, the EV-DO Rev. A system can provide the scheduling for different MAC flows. Actually, the reverse rate
01 (2009-11-09) 5-3
Contents
is adjusted based on the RAB. If the reverse load is heavy, the reverse rate is decreased. If the reverse load is light, the reverse rate is increased. If the reverse load is excessively heavy and the reverse rate is excessively low, the subscriber feeling is affected. The reverse admission algorithm is used to deny access of new subscribers in the case that the reverse load of the system is heavy and the lowest reverse rate of the subscriber cannot be ensured. In this case, the reverse rate of the accessed subscriber is ensured. When the system supports the macro diversity, if one carrier permits the admission, the call admission is permitted. When the active subscriber performs the soft handoff, the admission judgment cannot be performed.
5.3.2 Technical Description

The T2P algorithm is used in the EV-DO Rev. A system to perform the reverse rate control. Different T2P resources are used to enable the AT to send the reverse packets of different sizes. The bigger the reverse packet is, the more T2P resources are required. When the size of the termination sub-packet is fixed, the bigger the reverse packet used by the AT, the higher reverse rate that the AT can reach. Thus, the rate of the reverse BE subscribers can be guaranteed by the proper size of the reverse subscriber packet. The T2P resources available for different flows change with the load of carriers. The tendency for the change depends on the PF curve of the flow. The following figure shows the PF curves of the BE service and VoIP service with default parameters. Figure5-1 PF curves of the BE service and VoIP service with Qualcomm default parameters
30 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0 -2 -4 -6 -8 -10 -12
27
27
T2PUp/T2PDn (b/(1-b))
dB
10
VoIP PF BE PF 1.5
-10
-7.75
-8.25
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Average T2P
According to the previous figure, with carrier load (the Y coordinate axis, 10log (b/(1-b), represents the value of the ratio of busy RABs in the dB domain) increasing, the average T2P resources (X coordinate axis) available for different services are different. To ensure the service experience of subscribers, sufficient T2P resources should be distributed to the subscribers. Thus, when the load of a sector reaches a certain threshold, new access requests should be denied to avoid overload of the sector. In addition to the number of subscribers, the neighbor interference also has impact on the reverse load. Thus, even the new access requests are denied when the reverse load reaching the threshold, the reverse load of a sector may keep increasing, causing the poor service experience of the subscribers in the sector. In this case, enable the load control mechanism to release the air interface connections of specified subscribers.
5-4
01 (2009-11-09)

With increasing number of the subscribers in a sector, if the reverse load cannot meet the service demands of the subscribers, enable the reverse admission control and load control functions.
01 (2009-11-09)
5-5
6 Handoff Algorithm
6
6.1.1 Pilot Set
1. Active set
Handoff Algorithm
6.1 Overview of Handoff Algorithms

The EV-DO Rev. A system supports various handoff modes. HANOFF algorithms are as follows: soft handoff, hard handoff, virtual soft handoff, and 1X and EV-DO interoperation. All handoffs described in this section occur in the same PDSN.
The EV-DO Rev. A system classifies pilot sets into the following four types.
The active set is a pilot set (specified by the PN offset and the CDMA channel) of the current serving sector. A sector serves the AT in the following cases: The connection is set up, and the AT is configured with the forward TCH, reverse TCH, and reverse power control channel. The connection is closed, and the AT is detecting the control channel of the sector. 2. Candidate set In the candidate set, the ATs, not contained in the active set, can receive the pilots with strong strength. The candidate set is specified by the PN offset and the CDMA channel. 3. Neighbor set The neighbor set contains candidate pilots that are not in the active or candidate sets but that can be added to the active set. The neighbor set is specified by the PN offset and the CDMA channel. 4. Remaining set In the remaining set, the ATs are not contained in any of the three sets. Additionally, the PN of the AT in the remaining set is an integral multiple of the PN_INC. The AT maintains all four sets, but the AN maintains only the active set and the neighbor set.
6.1.2 Pilot Set Management

1. Management of the Active Set and the Candidate Set An AT supports up to six pilots in the active or candidate set. An AT adds a pilot to the candidate set if the pilot meets any of the following conditions:
01 (2009-11-09) 6-1
Contents

The pilot is not in the active set or in the candidate set, and the strength of the pilot exceeds the value specified by the PilotAdd parameter. The pilot is deleted from the active set. The pilot drop timer expires and the value of DynamicThresholds is 1. The strength of the pilot exceeds the value specified by the PilotDrop parameter.
The pilot is deleted from the active set, but the pilot drop timer does not expire. An AT removes a pilot from the candidate set if the pilot meets any of the following conditions: The pilot is added to the active set. The pilot drop timer expires. 2. Neighbor Set Management The neighbor set contains up to 32 pilots. 3. Remaining Set Management The AT initializes its remaining set to contain all the pilots whose PN offset is an integral multiple of PilotIncrement if they are not members of any other set.
6.1.3 Pilot Searching

In the idle state, the AT monitors the control channel. In the connected state, the AT continuously searches for all pilots according to the following rules: 1. Search priority In descending order of search frequency, the AT searches for the pilots in the active and candidate sets, then for those in the neighbor set, and lastly for those in the remaining set. 2. Size of the search window For pilots in the active set and candidate set, the AT uses the search window size specified by the SearchWindowActive parameter in the SearchParameters configuration table. For pilots in the neighbor set, in the connected state, the AT uses the search window size specified by the SearchWindowSize parameter in the NeighborList message. In the idle state, the AT uses the search window size defined by the NeighborSearchWindowSize parameter in the SectorParameters message. If the search window size is not configured in the NeighborList message or in the SectorParameters message, the AT uses the search window size defined by the SearchWindowNeighbor field in the SearchParameters configuration table during configuration negotiation based on the Default Route Update Protocol. For the pilots in the remaining set, the AT uses the search window size defined by the SearchWindowRemaining parameter in the SearchParameters configuration table. 3. Center of the search window For pilots in the active set, the AT can set the center of the search window around the earliest usable multi-path component. Each pilot in the neighbor set uses timing defined by AT time reference. The AT can set the center of the search window around the PN sequence offset of the pilot plus the search window offset specified by the SearchWindowOffset field of the corresponding neighbor structure in the RouteUpdateNeighborList. Each pilot in the remaining set uses timing defined by AT time reference. The AT should set the center of the search window around the PN sequence offset of the pilot.
6-2
01 (2009-11-09)
6 Handoff Algorithm
6.2 Intra-AN Soft Handoff

The reverse soft HANOFF in a CDMA2000 1xEV-DO network is the same as the soft handoff in a CDMA2000 1X network. Multiple sectors can simultaneously receive signals from the same AT. The AN selectively combines the reverse signals from different sectors. The active set pilots receive the information on combination of the signals from the AT to achieve soft handoff gain.

As in the IS2000 network, the AT has the following four pilot set types in the CDMA2000 1xEV-DO network: active set, candidate set, neighbor set, and remaining set. Only the sectors in the active set of the AT can receive, demodulate, and output the reverse signals from the AT. The pilot sets of the AT are maintained by the RouteUpdate message. The function of the RouteUpdate message is similar to the Pilot Strength Measurement message in the 1X network. The AT reports the RouteUpdate message according to the current radio environment. The AN then determines the active set and the neighbor set according to the radio environment information reported by the AT. The neighbor combination algorithm of the EVDO system is as follows: Based on the network structure, a certain number of neighbor pilots with certain priority are configured to each carrier.

When the DB obtains all the neighbor pilots of the carrier, it sequences the neighbor pilots from high priority to low priority. Every time after the handoff, the system sequences legs of the active set based on strength of the pilot (from high pilot strength to low pilot strength: A1, A2, A3, A4, A5, A6).
Based on the sequence, the system selects the first neighbor pilots from the sequenced active set and places them to the neighbor set. If the neighbor pilot exceeds 32, the algorithm exists in the system. If the number of the neighbor pilot is within 32, the system takes out the second neighbor pilots in sequence from each active set and places them to the neighbor set until that number of the pilot exceeds 32 or all the neighbor pilots of the legs of the active set are visited.
If both the EV-DO same-frequency pilot and EV-DO different-frequency pilot exist in the neighbor pilot, frequency of the neighbor pilot is not concentrated on during the neighbor combination. The neighbor combination should comply with the sequence configured by the DB. Different frequency of different frequency can be sent in a NeighborList message.
The count field in the NeighborList message is 5 bit. Thus, information about 31 neighbors can be contained in the message. Number of the neighbor pilot should be less than or equal to 31 during the neighbor combination.

1. Application scenario The reverse soft handoff is a basic feature of the CDMA2000 1xEV-DO system. 2. Performance The receiving gain caused by the reverse soft handoff reduces the transmit power of mobiles to achieve the following benefits: less interference caused by mobiles to the system, improved call quality, and expanded system capacity. The reverse soft handoff,
01 (2009-11-09)
6-3
Contents
however, consumes physical resources such as CE. Therefore, frequent reverse soft handoffs reduce the usage of system resources. 3. Supporting version: BSC: BSC6600 V200R001C02 and later versions BTS: BTS3612 V200R001C03 and later versions BTS3606 V200R001C03 and later versions
6.3 Inter-AN Soft Handoff

The inter-AN active soft handoff ensures stable services when an AT moves between ANs. In addition, it avoids ping-pong handoffs and uses the A17/A18 link resources by performing call migration.

An AT moves to the boundary of the AN and detects pilots of another AN (target AN). In this case, the AT triggers an inter-AN soft handoff and sets up legs with the target AN. As the AT moves close to the target AN, an inter-AN virtual soft handoff is triggered when the pilots of the target AN grow into strongest ones. When the AT accesses the target AN, and the pilot strength of the source AN meets the soft handoff deletion requirement, the AT deletes the legs of the source AN. Figure6-1 Inter-AN soft handoff
Then, the AT moves inwards the target AN. When the AT is away from the AN boundary, call migration (that is, inter-AN hard handoff) is triggered. Thus, the A16 interface session is migrated from the source AN to the target AN. Figure6-2 Inter-AN call migration
6-4
01 (2009-11-09)
6 Handoff Algorithm
The call migration is triggered in the following case: The AN receives the RouteUpdate message that all legs of the source AN needs to be deleted. In this case, the call migration delay timer starts if the call migration delay timer is enabled, and all legs in the target active set are from the target AN. When the timer expires, call migration is triggered if no leg of the source AN exists in the active set. If a leg of the source AN is added to the active set before the timer expires, the timer stops, and call migration is not activated.
6.3.3 Application Scenario

The inter-AN soft handoff applies to the boundary between two ANs. This function is implemented based on a proprietary Huawei protocol. Therefore, the inter-AN soft handoff applies to Huawei ANs only. All manufacturers agree that it is impossible to implement soft handoff between the ANs provided by different manufacturers. This function applies to both the EV-DO Rel.0 network and the EV-DO Rev. A network, and is the same for terminals of the EV-DO Rel.0 network and those of the EV-DO Rev. A network.
6.4 1x and EV-DO Rev. A Interoperation

With wide application of 1x and EV-DO dual networks, the interoperation of 1x/EV-DO Rev. A dual-mode terminals becomes a major issue. In the existing network, the interoperation of CDMA 1x and EV-DO dual-mode terminals is used to provide low-speed voice services and high-speed packet data services.

The principles of 1x and EV-DO interoperation are as follows:
01 (2009-11-09) 6-5
Contents
1.
Voice services take priority based on dual-network monitoring.
2. In the EV-DO network, terminals periodically monitor voice paging from the 1x network. If a terminal receives a voice paging message when the EV-DO Rev. A connection is active, the terminal automatically disconnects the air interface link in the EV-DO network and answers the voice call in the 1x network. 3. Each terminal has the same IMSI in the 1x network and in the EV-DO network.
4. To ensure availability of inter-network handoffs, the IMSI of a dual-mode terminal is the same, no matter whether the terminal is in the 1x network or in the EV-DO network. 5. Data services are preferentially provided on the EV-DO network whenever possible.
6. Terminals do not monitor the control channel of the EV-DO system when the 1x connection is active. 7. A dual-mode terminal monitors the control channel of the EV-DO system only when the 1x system is dormant or null. 8. Terminals perform handoff decision by themselves. No interoperation handoff is triggered in the network. For details, see chapter 4 .

1. Handoff between the 1x and EV-DO overlapped coverage and the 1x coverage
2.
Handoff between the 1x coverage and the EV-DO coverage
6.5 Virtual Soft Handoff

The DRC-based virtual soft handoff supported by the EV-DO Rel.0 system causes a long handoff delay. It thus fails to support the QoS required by delay-sensitive services such as VoIP. In the EV-DO Rev. A system, the DSC channel is added to shorten the delay caused by
6-6
01 (2009-11-09)
6 Handoff Algorithm
the virtual soft handoff. The DSC channel changes before the DRC changes so that the target BTS can transfer the forward data queue from the source BTS in advance. When the DRC changes, the target BTS immediately sends the forward data to the AT. Figure6-3 Virtual soft handoff of the EV-DO Rev. A system
Forward data channel Reverse DSC channel Reverse DRC channel Forward data flow
Before handoff
During handoff
After handoff
If an AT detects that the C/I of cell B is higher than that of cell A, the DSC channel changes from A to B. In this case, the BTS transfers data to be sent to the data queue of cell B. When the DRC changes from A to B, cell B can immediately send the data to the AT. In this way, the air interface sends data without Interruption. Therefore, the delay caused by the virtual soft handoff is shortened.
6.5.2 Function Implementation

6.5.2.1 Implementation of Virtual Soft Handoff of BE Flows and AF Flows
Figure6-4 shows the procedure for the virtual soft handoff of BE flows and AF flows. Figure6-4 Procedure for the virtual soft handoff of BE flows and AF flows
01 (2009-11-09)
6-7
Contents
The AT directs the DSC from BTS1 to BTS2.
1. The AT detects that the C/I of BTS 2 is higher than that of BTS 1 and then directs the DSC channel to BTS 2. 2. BTS 1 detects that the DSC channel is directed to BTS 2 and then reports a DSCSwitchInd message (LastPktId: 20) to the AN. BTS 2 detects that the DSC channel is directed to BTS 2 and then reports a ForwardRequest message to the AN. These two messages can be reported simultaneously. In this case, BTS 1 continues to send packets to the AT. 3. After some time, BTS 1 reports a ForwardStop message to the AN, requesting the AN to stop the packet transmission. Assume that the ID of the last packet (LastPktId) sent by the AN is 100. 4. The AN sends packets (starting from the packet whose ID is 100) to BTS 2 through unicast. In this case, BTS 2 starts sending packets to the AT. The virtual soft handoff is complete.
6.5.2.2 Implementation of Virtual Soft Handoff of EF Flows

During the DRC-based virtual soft handoff supported by the EV-DO Rel.0 system, the FMR sends forward service data to only one target BTS. The DSC-based virtual soft handoff supported by the EV-DO Rev. A system provides the early indication function. During the early indication period, the FMR must send service data simultaneously to both the source BTS and the target BTS. In this case, the target BTS is configured with in advance a data queue. Errors may occur when Qualcomm chips detect DSC and DRC channels. Therefore, the target BTS detected during DSC early indication may be incorrect. To ensure that the real target BTS prepares the data in advance, the forward data must be sent to all BTSs in the active set. This is called multicast. Multicast can minimize the adverse effects caused by DSC/DRC detection errors. Multicast, however, increases traffic on the Abis interface. To solve this problem, the multicast reduction algorithm is used to change multicast to dual-cast.
6-8
01 (2009-11-09)
6 Handoff Algorithm
If the multicast reduction switch (VshoMultiCastReduceSw) is on, target BTSs are determined according to the following rules: 1. The current active serving BTS is a target of multicast.
2. If DscValue carried in the DscSwitchInd message reported by the active serving BTS is valid, the target BTS specified by the DscSwitchInd message is a target BTS of multicast. If DscValue is invalid, all BTSs in the active set are targets of multicast. 3. If the number of serving BTSs is not 0, the non-serving BTSs are eliminated from the list of target BTSs. If the number of serving BTSs is 0, it means that errors occur during DSC/DRC channel detection. In this case, all active set BTSs are targets of multicast. With the multicast reduction algorithm, the number of target BTSs can be limited to two in most cases. Figure6-5 shows the procedure for virtual soft handoff of the VT service. Figure6-5 Procedure for virtual soft handoff of EF services (VT service)
1. The AT detects that the C/I of BTS 2 is higher than that of BTS 1 and then directs the DSC channel to BTS 2. 2. BTS 1 detects that the DSC channel is directed to BTS 2 and then reports a DSCSwitchInd message (LastPktId: 20). BTS 2 detects that the DSC channel is directed to BTS 2 and then reports a ForwardRequest message. These two messages can be reported simultaneously. In this case, BTS 1 continues sending packets to the AT. (Assume that the ID (PktId) of the last packet sent by the AN to BTS 1 is 60.) 3. The AN sends the packets (packet ID: 20 to 60) to BTS 2 through unicast. In this case, BTS 1 continues sending packets to the AT.
01 (2009-11-09)
6-9
Contents
4. After sending the packet whose ID is 60 to BTS 2, the AN starts sending multicast packets to both BTS 1 and BTS 2 (starting from the packet whose ID is 61). In this case, BTS 1 continues sending packets to the AT. 5. After some time, BTS 1 reports a ForwardStop message to the AN, requesting the AN to stop the packet transmission. Assume that the ID of the last packet (LastPktId) sent by the AN is 100. 6. The AN sends packets (starting from the packet whose ID is 101) to BTS 2 through unicast. In this case, BTS 2 starts sending packets to the AT. The virtual soft handoff is complete.

1. Application scenario The virtual soft handoff is a basic feature of the EV-DO Rev. A system. The AN V300R006C02 and later versions support the inter-AN virtual soft handoff. 2. Performance
The EV-DO Rev. A system uses the DSC early indication, multicast, and multicast reduction algorithm to shorten the delay caused by the virtual soft handoff. Therefore, the QoS requirements of the delay-sensitive services are met. 3. Supporting version
BSC: BSC6600 V200R003 and later versions BTS: V3R1 and later versions
6.6 Hard Handoff

The current hard handoff algorithms of the EV-DO system are used for improving coverage in the network boundary. The AN V300R006C02 and later versions support inter-frequency hard handoffs. The hard handoff of the EV-DO system can be classified as follows: 1. Classification of triggering modes: RTD-based hard handoff, DRC-based hard handoff, RL Link Quality hard handoff, intra-frequency hard handoff, and OFS-based hard handoff In the RTD-based hard handoff, DRC-based hard handoff, and RL Link Quality hard handoff, the target carrier can be configured with a different frequency or with the carrier operating in a different band. 2. Classification based on whether the strength of target pilot signals is measured or not: blind handoff algorithm and non-blind handoff algorithm. In the EV-DO system, the OFS-based handoff and intra-frequency hard handoff are non-blind handoffs, and the other hard handoffs are blind handoffs.
6-10
01 (2009-11-09)
6 Handoff Algorithm
In the OFS-based hard handoff, the target carriers are configured through the ADD NBRCDMACH command. For other hard handoffs, the target carriers are configured through the ADD DOHHOTRG command.
6.6.2 Function Implementation

6.6.2.1 RTD-Based Hard Handoff
The principle of the RTD-based hard handoff algorithm is as shown in 0. The RTD of a leg reflects the link delay of the reverse signals sent from the AT to the BTS of the leg. Based on the measurement of the shortest RTD in the active set, the distance between the AT and the current serving BTS can be determined, which facilitates triggering of a hard handoff. Inter-frequency neighboring cells are divided into the following three regions according to the shortest RTD of the legs in the active set: 1. 2. Region A: The shortest RTD is below the maximum loop delay threshold in the center (CENTERTHRLD). Region B: The shortest RTD is above the maximum loop delay threshold in the center (CENTERTHRLD) but below the maximum loop delay threshold at the border (BORDERTHRLD). Region C: The shortest RTD is above the maximum loop delay threshold at the border (BORDERTHRLD).
3.
Figure6-6 Schematic diagram of the RTD-based hard handoff
The RTD-based hard handoff strategies are as follows: 1. 2. 3. In region A, no inter-frequency hard handoff is triggered. In region B, changes of the source pilot strength are detected in real time. If the pilot of the strongest leg is weaker than a threshold, a hard handoff is triggered. In region C, a hard handoff is triggered directly.
6.2.2.2 OFS-Based Hard Handoff

An AT performs Other Frequency Search (OFS) if both the following conditions are met.
01 (2009-11-09)
6-11
Contents
1. The strength of the strongest pilot in the active set and in the candidate set is less than -5 dB. 2. Pilots on other frequencies exist in the candidate set or in the neighbor set. Therefore, we can control whether an AT performs OFS depending on whether the Neighbor List message carries pilots on other frequencies. If the EV-DO inter-frequency OFS hard handoff switch (OFSDOHHOSW) is on, the AT performs OFS and the AN performs the OFS algorithm decision. If the difference between the strength of the strongest pilot on the serving frequency and that of the strongest pilot on another frequency exceeds the hard handoff threshold, an OFS-based hard handoff is triggered.
6.2.2.3 Intra-Frequency Hard Handoff

The EV-DO intra-frequency hard handoff mainly applies to the scenario of inter-AN handoffs. Ping-pong handoffs are likely to occur due to the intra-frequency interference. Thus, if the requirements for the inter-AN soft handoff are met, inter-AN soft handoffs are preferred. The intra-frequency hard handoff is triggered when either of the following requirements is met. 1. 2. The target active set pilot minus the source active set pilot is the value of the relative threshold for intra-frequency hard handoffs. The strength of the pilot in the source active set is below the threshold of an intra-frequency outgoing hard handoff, and the strength of the pilot in the target active set is above the target carrier handoff threshold in an intra-hard handoff.
The DOSFHHORURSW parameter is added to BSC6680 V300R006C08. This parameter periodically triggers the RUR message so that the AT can report the RU message in time. In this case, hard handoffs can be performed on the AT in time. BSC6680 V300R006C08 supports the A16 interface designed on the basis of a Huawei proprietary protocol. The A16 request message carries the target cell list to increase the handoff success rate. The configuration for the inter-AN hard handoff varies with the A16 protocol.
A. If the standard A16 protocol is applied, the handoff relation from the target AN to the source AN must be configured for the neighbor cell.
6-12
01 (2009-11-09)
6 Handoff Algorithm
B. If the A16 interface designed based on a Huawei proprietary protocol is applied, the configuration for the target AN carrier is not required.
The intra-frequency hard handoff is developed based on the soft handoff. An intra-frequency neighboring cell relation must be configured to the target carrier. In the hard handoff, the target carrier can be added without the ADD DOHHOTRG command. For details about how to configure a target carrier, see the CDMA2000 EV-DO Hard Handoff Solution.
6.2.2.4 Call Migration

If an AT that is in a call moves from the source AN to the target AN, session migration needs to be triggered to reduce data transmission between the ANs when all soft handoff legs are set up on the target AN. The EV-DO Rev. A system uses the existing inter-AN hard handoff process to complete inter-AN session migration. This is called call migration. The time when call migration occurs greatly affects the result of the call migration. If call migration occurs too early, inter-AN hard handoffs are frequently triggered at the boundary between ANs. In this case, inter-AN hard handoffs occur instead of inter-AN soft handoffs. The values of the soft handoff are not realized. If call migration occurs too late, data transmission between ANs occupies high bandwidth. In addition, the source AN must be configured with sufficient information about target AN carriers. Thus, the inter-AN call migration decision is important. InFigure6-7, the AT moves from the source AN (S-AN) to the target AN (T-AN). In the first tier region, all soft handoff legs of the AT may be set up on the T-AN. S-AN legs, however, may also be added at that time. Therefore, it is too early to trigger call migration in this case. When the AT moves to the second tier region, call migration can be triggered immediately because the AT is far from the S-AN. If the AT stays in the first tier region, call migration should also be triggered. Figure6-7 Procedure for call migration
01 (2009-11-09)
6-13
Contents
The call migration is triggered in the following cases: The AN receives the RouteUpdate message that all legs of the source AN needs to be deleted. In this case, the call migration delay timer starts if the call migration delay timer is enabled, and all legs in the target active set are from the target AN. When the timer expires, call migration is triggered if no leg of the source AN (this indicates that the AT exists in the target AN for a long time) exists in the active set. If a leg of the source AN is added to the active set before the timer expires, the timer stops, and call migration is not activated. Figure6-8 Procedure for call migration
6-14
01 (2009-11-09)
6 Handoff Algorithm
RU Inter- AN soft handoff : Obtaining the target active set
Turn on the call migration switch?
All the legs in the new active set come from the target ANs? Y
When the call migration delay timer expires, still no legs are added at the source AN side?
End
Y The call migration during the inter AN soft handoff is triggered .

Currently, hard handoffs cannot be performed on the EV-DO Rel. 0 terminals. Hard Handoff Algorithm RTD hard handoff OFS hard handoff Intra-frequency hard handoff Call migration Application Scenario All hard handoffs Inter-frequency handoffs Inter-AN handoffs. If the A16 interface is designed based on a Huawei proprietary protocol, Huawei's ANs must be used on the source and target sides. Inter-AN handoffs
01 (2009-11-09)
6-15
Contents
6.7 Intra-AN Hard Handoff Macro Diversity

The hard handoff macro diversity means that multiple reverse legs are set up for the AT during a hard handoff so that the AT is in the soft handoff state after the hard handoff is complete. Therefore, the hard handoff success rate increases and the soft handoff gain improves the reverse QoS.

During the hard handoff decision at the source pilot, multiple target pilots in the same AN are generated according to the current radio environment and data configurations. In this way, the AT is in the soft handoff state immediately after the hard handoff is complete. Therefore, the hard handoff success rate increases.

Intra-AN hard handoff
6.8 AN-Assisted Inter-AN Handoff

When an AT in the active state moves from an AN to another, if the source AN determines from the RouteUpdate message reported by the AT that the difference between the strongest pilot strength of the source AN and that of the target AN exceeds a preset threshold, the source AN releases the call. After the AT moves to the target AN, if the active set and the subnet change, it sends a UATIRequest to the target AN. In this case, the session is transferred through the A13 interface to the target AN. After session transfer, the AT or the AN initiates reactivation to continue the service transmission.

In AN-assisted inter-AN handoff, the session information at the source AN is transferred to the target AN, and then the connection is set up at the target AN, and all resources at the source side are released. Before handoff, the AT is in the Active state, and the source AN stores the session information about this AT and has a complete traffic link. The handoff process consists of the following procedures: 1. Source AN releasing the connection (controlled by the AN): If the source AN finds from the RouteUpdate message reported by the AT that the difference between strengths of the pilots in the source and target ANs exceeds a preset value, the source AN releases the call. 2. Dormant AN-assisted inter-AN handoff (controlled by the AT): After the AT moves to the target AN, the active set and the subnet change. The AT, therefore, sends a UATIRequest. At this point, the two ANs transfer the session through the A13 interface.
6-16
01 (2009-11-09)
6 Handoff Algorithm
3. Connection setup at the target AN (controlled by the AT if reverse traffic exists, or by the AN if forward traffic exists): AT or AN reactivation is implemented, and the data transmission continues. After handoff, the AT is in the Active state, and the source AN no longer stores the session information about this AT. Instead, the target AN stores this information and has a complete traffic link.
Handover Process
Figure6-9 Process of the AN-assisted inter-AN handoff
Figure6-9 shows that the AN-assisted inter-AN handoff process is divided into three procedures described as follows: 1. Releases on the source: The source AN determines whether to perform the AN-assisted inter-AN handoff by sending the ConncetionClose message to the AT and shutting down the existing connection. In the dormant handoff, the AT sends a UATI update request to the target AN, and then the target AN requires the source AN to perform a session migration (this is not shown inFigure6-9 ). During the setup of services at the target side, the AN needs to send data to the AT. Thus, the AN initiates a paging call to the AT, requesting the AT to set up new services. (Or the AT needs to send data to the AN, and the AT initiates a request for connection setup.)
2.
3.

1. The inter-AN hard handoff over the A16 interface is not configured or supported.
01 (2009-11-09)
6-17
Contents
2.
A Huawei AN (the source AN) interconnects with an AN provided by another manufacturer.
6-18
01 (2009-11-09)
7 Reverse Power Control
7
7.1 Overview
1. 2. 3.
Reverse Power Control
The reverse power control function controls the transmit power of an AT. Even if the ATs at different distances from the BTS have the same transmit power, the strength of the signals received by the BTS is different. Strong signals may block weak signals. This is called near-far effect. To avoid the near-far effect, the reverse power control is applied so that the transmit power of ATs at different distances can be demodulated by the BTS and few interference is generated to other ATs. The reverse power control consists of the following three parts. The AT estimates the open loop transmit power. The BTS performs closed loop correction. The AN performs outer loop correction based on Cyclic Redundancy Check (CRC).
The reverse power control works on ATs. The transmit power of an AT is estimated in an open loop and controlled in a closed loop. In the case of no closed loop control (for example, the transmit power on an access channel), the open loop controls the transmit power. Figure7-1 Starting points of the open loop power control and closed loop power control
01 (2009-11-09)
7-1
Contents
Reverse power control works on ATs, containing open loop power control and closed loop power control. Reverse closed loop power control has two categories: reverse outer loop power control and reverse inner loop power control. Open loop power control: When an AT sends a probe, the open loop estimation is performed on its transmit power. Thus, the BTS can demodulate the probe with minimum power. The transmit power in an open loop estimates the reverse transmit power on the basis of the forward receive power. The process is related to the channel type, RC value, BTS transmit power, and RSSI. Closed loop power control: It is implemented based on the open loop power control. Closed-loop power control modes can be classified into outer-loop power control mode and inner-loop power control mode. Figure7-2 shows the principles of closed loop power control. Figure7-2 Principles of reverse outer loop power control and inner loop power control
7.2 Reverse Open Loop Power Control

Open loop power control enables the BTS to demodulate the access probe from an AT (the higher the power is, the easier can the access probe be demodulated). At the same time, the interference caused by the terminal with other terminals must be minimized (that is, the power must be as low as possible). Therefore, reverse open loop power control is required.

This algorithm is used to estimate the required reverse transmit power based on the received BTS transmit power. Open loop power control starts when the AT sends the first probe to access the network. When the AT initiates an access probe, it estimates the power (X0) of the first access probe according to the strength of the signal received from the BTS. X0 = Average received power Rx (dBm) + OpenLoopAdjust + ProbeInitialAdjust Xi (power of access probe i sent by an AT) = X0 + (i 1) x PowerStep The AccessParameters message carries the parameters OpenLoopAdjust, ProbeInitialAdjust, PowerStep. The power that is used to access the data channel is presented with the offset from the power that is used to access the pilot channel. The offset depends on DataOffsetNom and DataOffset9k6:
7-2
01 (2009-11-09)
Data Rate (kbit/s) 0 9.6
Data Channel Gain Relative to Pilot (dB) (Data Channel Is Not Transmitted) DataOffsetNom + DataOffset9k6 + 3.75
Note that open loop power control is not only used to adjust the power of the pilot channel in the access channel. During transmission of the reverse TCH, the initial power of the reverse pilot channel equals the average transmit power of the pilot channel of the last probe in the access channel. During transmission of the reverse TCH, the power of the reverse pilot channel must also be adjusted according to the difference between the current forward average received power and the forward average received power of the last access probe.

As a basic function provided by the EV-DO system, reverse open power control applies to all EV-DO Rel.0 and EV-DO Rev. A terminals during their access.
7.3 Reverse Closed Loop Power Control

When an AT is in the service state, the transmit power of the AT must be reasonably controlled to maximize the reverse throughput of the network and to ensure stable operation of the network. Reverse close power control is implemented to ensure the operation of the system through the definition of reverse PER and by adjusting the transmit power of the terminal according to the system load. Power control of an AN is implemented on both the AN and the BTS. Therefore, reverse closed loop power control consists of the reverse outer loop power control that applies to the AN and the reverse inner loop power control that applies to the BTS. Figure7-3 Procedure for reverse closed loop power control of the EV-DO Rev. A system
01 (2009-11-09)
7-3
Contents

Closed loop power control works on the reverse pilot channel. The power of the reverse TCH, DRC channel, DSC channel, RRI channel, and ACK channel is presented with the offset from the reverse pilot channel. The reverse closed loop power control adjusts the power of the reverse pilot channel. Accordingly, the power of other channels changes. The power of a reverse TCH depends on the size and the transmission mode of physical layer packets on the reverse TCH. The following table lists the T2P values used by a TCH in the case of different packet sizes and different transmission modes. Physical Layer Packet Size (bits) 0 128 128 256 256 512 512 Transmissi on Mode N/A High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency Data Channel Gain Relative to Pilot (dB) Pre-Transition (Data Channel is not transmitted.) T2PHiCapPreTransition128 T2PLoLatPreTransition128 T2PHiCapPreTransition256 T2PLoLatPreTransition256 T2PHiCapPreTransition512 T2PLoLatPreTransition512 Data Channel Gain Relative to Pilot (dB) Post-Transition (Data Channel is not transmitted.) T2PHiCapPostTransitio n128 T2PLoLatPostTransition 128 T2PHiCapPostTransitio n256 T2PLoLatPostTransition 256 T2PHiCapPostTransitio n512 T2PLoLatPostTransition 512
7-4
01 (2009-11-09)
Physical Layer Packet Size (bits) 768 768 1024 1024 1536 1536 2048 2048 3072 3072 4096 4096 6144 6144 8192 8192 12288 12288
Transmissi on Mode High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency High Capacity Low Latency
Data Channel Gain Relative to Pilot (dB) Pre-Transition T2PHiCapPreTransition768 T2PLoLatPreTransition768 T2PHiCapPreTransition1024 T2PLoLatPreTransition1024 T2PHiCapPreTransition1536 T2PLoLatPreTransition1536 T2PHiCapPreTransition2048 T2PLoLatPreTransition2048 T2PHiCapPreTransition3072 T2PLoLatPreTransition3072 T2PHiCapPreTransition4096 T2PLoLatPreTransition4096 T2PHiCapPreTransition6144 T2PLoLatPreTransition6144 T2PHiCapPreTransition8192 T2PLoLatPreTransition8192 T2PHiCapPreTransition1228 8 T2PLoLatPreTransition1228 8
Data Channel Gain Relative to Pilot (dB) Post-Transition T2PHiCapPostTransitio n768 T2PLoLatPostTransition 768 T2PHiCapPostTransitio n1024 T2PLoLatPostTransition 1024 T2PHiCapPostTransitio n1536 T2PLoLatPostTransition 1536 T2PHiCapPostTransitio n2048 T2PLoLatPostTransition 2048 T2PHiCapPostTransitio n3072 T2PLoLatPostTransition 3072 T2PHiCapPostTransitio n4096 T2PLoLatPostTransition 4096 T2PHiCapPostTransitio n6144 T2PLoLatPostTransition 6144 T2PHiCapPostTransitio n8192 T2PLoLatPostTransition 8192 T2PHiCapPostTransitio n12288 T2PLoLatPostTransition 12288
01 (2009-11-09)
7-5
Contents
7.3.2.1 Reverse Outer Loop Power Control

Reverse outer loop power control is implemented to adjust the power control threshold (PCT) to maintain the signal-to-noise ratio of the received reverse pilot signal so that the packet error ratio (PER) is kept at a level. After the traffic channel is set up, reverse outer loop power control starts. The AN obtains related information from the reverse packets sent by the BTS (CRC is determined by the chip of the BTS). According to the information, the AN learns whether the packet contains any error, and then adjusts the PCT accordingly and sends the adjusted PCT to the BTS through forward packets. Figure7-4 shows the criteria for the AN to decide whether a packet is correct. Figure7-4 Procedure for packet decision in the EV-DO Rev. A system
Start
CRC passed No
Yes
Yes
Sub-packet ID > termination target
No Error packet Correct packet
End
1. 2. 3.
Packets that fail in the CRC are error packets. Packets that pass the CRC are correct packets if their sub-packet ID is smaller than or equal to the termination target. Packets that pass the CRC are error packets if their sub-packet ID is larger than the termination target.
Therefore, the target PER of outer loop power control is for power control but not for CRC. The reverse outer loop power control may be in any of the following three states: 1. Inactive state
The terminal is in the dormant state, with disconnected air interface link. No active data is transmitted. In this case, no reverse power control occurs. 2. Normal state
The terminal sends data packets to the BTS through the active reverse TCH. The AN gets packet error information from packets sent by the BTS.
For an idle packet sent by the BTS, no processing is performed.
7-6
01 (2009-11-09)
For a valid packet that contains errors, the AN increases the PCT till the set maximum value.
For a correct packet, the AN decreases the PCT till the set minimum value.
The relation between PCT rise step and drop step is as follows:
Target PER = number of error packets / (number of error packets + number of correct packets) * 100%
Number of error packets * rise step = number of correct packets * drop step No data state The terminal does not send data to the BTS, but it is not in the dormant state. That is, the air interface link is alive. A terminal is in the no data state about 0.5s after it stops sending data to the BTS. In this case, no outer loop power control feedback is available, and the reverse link may deteriorate. To ensure that the reverse data transmitted in the no data state can be demodulated on time, the PCT keeps rising slowly according to the reverse outer loop power control algorithm. If the algorithm is in the no data state because no reverse packet is received for consecutive three interleaves in a specified period, the PCT changes by packet instead of sub-packet.
3.
7.3.2.2 Reverse Inner Loop Power Control

The BTS performs reverse inner loop power control. With the ARQ mechanism used in the EV-DO Rev. A system, reverse inner loop power control makes decisions based on termination target of each sub-frame. The power control rate is 150 Hz. The forward IDLE frame on the Abis interface sends the BTS the PCT set by the outer loop power control. This PCT prevents forward flow control from affecting outer loop power control. The IDLE frame that carries the PCT, however, may be discarded due to congestion control. The BTS compares the PCT on the received reverse pilot with the target PCT. If the received PCT is lower than the target PCT, the BTS requests the terminal to increase its transmit power. If the received PCT is higher than the target PCT, the BTS requests the terminal to decrease its transmit power. The BTS sends power control bits to the terminal through the forward RPC channel. If the power control bit is 0, the power needs to be increased by one step (RPCStep). If the power control bit is 1, the power needs to be decreased by one step. An RPCStep is 0.5 dB or 1 dB. The PowerParameters property table defines the RPCStep during MAC protocol negotiation of the reverse TCH. In a softer handoff, the power control bits sent on different legs are the same. The terminal performs maximum ratio combining (MRC) of the power control bits. In a soft handoff, the power control bits sent on different legs conflict. If any power control bit is 1, the terminal decreases its transmit power.
7.3.2.3 Differences in Closed Loop Power Control Between EV-DO Rel.0 and EV-DO Rev. A
Counter Power control rate (bit/s) Relation between power control success/failure and demodulation success/failure EV-DO Rel.0 600 x (1 -1/DRCLockPeriod) If demodulation succeeds or fails, power control succeeds or fails. EV-DO Rev. A 150 If demodulation is successful or fails, power control is successful or fails. For LL services, power control may fail though demodulation is successful.
7-7
01 (2009-11-09)
Contents
Power control states

Inactive state Normal state No data state Data start state

Inactive state Normal state No data state

As a basic function of the EV-DO system, reverse closed loop power control applies to all ANs and ATs. Figure7-5 shows the process of reverse outer loop power control. Figure7-5 PCT adjustment of the reverse outer loop power control in the EV-DO Rev. A system
In Figure7-5the minimum unit of time is sub-frame (four slots), and the meaning of each letter is shown as follows: G stands for correct packets (demodulation is correctly performed before the target termination).

B stands for error packets (demodulation is correctly performed or not before the target termination). N stands for no data. C indicates that demodulation fails.
In the EV-DO Rev. A system, the packets on reverse links are transmitted in three sub-packet (unit: three sub-packets) interleaving. Thus, commas are used to between every three sub-frames. The power control process shown in Figure7-5 is described as follows: First interleaving: The first sub-packet is a correct packet. Thus, one step is reduced by the PCT according to protocols.
7-8
01 (2009-11-09)
The second sub-packet cannot be decoded. Thus, the termination target of the sub-packet is unavailable and you cannot determine whether the sub-packet is a correct or an incorrect packet. The PCT remains unchanged. The third sub-packet is a correct packet. Thus, one step is reduced by the PCT according to protocols. Second interleaving: The first sub-packet is the same as the second sub-packet of the first interleaving. The second sub-packet and the second sub-packet in the first interleaving belong to the same data packet. In Figure7-5 , assume that the termination target is 2. You can infer that the sub-packet is an incorrect packet because it cannot be decoded. In addition, the AN does not obtain the termination target of this packet. Thus, the AN cannot make decision on the packet and does not decrease the PCT. The third sub-packet is the same as the first or third sub-packet of the first interleaving. Third interleaving: The first sub-packet is the same as the second sub-packet of the second interleaving. The second sub-packet is the same as the second sub-packet of the second interleaving. The third sub-packet is the same as the second sub-packet of the first interleaving. Fourth interleaving: (In the following part, explanation to the sub-packets that you can conclude from the preceding principles is not provided.) The second sub-packet is correctly decoded and the AN obtains the relevant information. Its termination target is 2, which means that this packet is an error one and that the PCT increases because this packet is decoded from the fourth sub-packet. Fifth interleaving: The first sub-packet is an error packet and the PCT increases because the fourth sub-packet is not correctly decoded. Sixth interleaving: (The principle of the process is the same as the preceding one.) Seventh interleaving: The second sub-packet is decoded from the third sub-packet. Even so, the system needs to determine whether it is a correct packet because each packet has its own termination target. For example, the termination target of the second packet in the second interleaving is 2. Thus, the system can determine that the second sub-packet that has not already been decoded as an error packet. Although the packet is decoded from the third sub-packet, the termination target of this packet is greater than 3 and you can infer that this packet is a correct one.
01 (2009-11-09)
7-9
8 Forward Scheduling and Forward Rate Limit
Forward Scheduling and Forward Rate Limit
8.1 Forward Scheduling

In the EV-DO system, forward TCHs transmit data frames based on TDM. Each timeslot can serve one subscriber only (except for the multiuser packets). Each subscriber can have multiple flows and each flow can have multiple queues. Byte streams join different queues according to their properties. In each timeslot, the bytes in all queues of each subscriber form a candidate transmission instance according to the descending order of the byte priorities. The scheduler works out priority of each user packet according to the candidate transmission instances and the packet formats supported by the current air interface. The scheduler then determines the candidate transmission instance packet to be sent by the timeslot by comparing priorities of all packets. The BTS chips implement the forward air interface scheduling algorithm that determines the subscriber to be served by a specified timeslot.

A subscriber can have multiple flows and each flow can bear a different QoS property. Each flow can have the following three queues: first transmission queue (FTx), RLP layer retransmission queue (RTx), and MAC layer retransmission queue (DARQ). The chip scheduler defines three priorities: BitSufferMetric, BitMetric, and PacketMetric. Calculate BitSufferMetric based on different priority formulas of delay-sensitive and throughput-sensitive services. BitSufferMetric defines the order of the bytes in all queues that form a candidate transmission instance. BitMetric is used to measure PacketMetric. The scheduler chooses the candidate transmission instance with the largest PacketMetric value for scheduling. QoS requirements vary with service types. The MC priority factor ensures priority differences between services. The following metric polynomial presents the priorities calculated by the scheduler. MC0, , and MC 7 indicate metric factors (MC7 > MC6 > MC5 > MC4 > MC3 > MC2 > MC0). The scheduler chooses the packet with the highest priority for scheduling. The scheduler uses the preceding polynomial to compare priorities of packets. That is, the packet with greater Initial Class factor takes the higher priority. If the Initial Class factors of two packets are the same, the scheduler compares x calculated by the following TSBSM or DSBSM formula. For throughput-sensitive services, see the following formula:
01 (2009-11-09)
7-1
Contents
For delay-sensitive services, see the following formula:
In the preceding two formulas:

In the preceding formulas, hrght2DelayConvFactorBSM is a global parameter that is valid to all throughput-sensitive flows. This parameter acts as a normalization factor that converts throughput-sensitive services to delay-sensitive ones. Therefore, the scheduler can compare throughput-sensitive services with delay-sensitive ones. The GosFactor parameter can be set separately for each flow. This parameter is valid to throughput-sensitive services only. It defines scheduling priority of each flow.
The AvgThroughput parameter means a filtered throughput. The TargetThroughput parameter can be set separately for each flow. is a small positive number.
According to the two formulas, if the average throughput higher than the target throughput increases, the byte is less likely to join a candidate transmission instance. In addition, the related data packet is also less likely to be scheduled. If the average throughput is lower than the target throughput, the ratio is large because is a small positive number. In this case, the byte is more likely to join a candidate transmission instance. Additionally, the related packet is more likely to be scheduled. BitMetric is defined as follows for throughput-sensitive and delay-sensitive services:
The PacketMetric formula is as follows:

8.1.2.1 Generating a Candidate Transmission Instance
A single-subscriber transmission instance is generated for each subscriber, and the standard format is used. The multi-subscriber transmission instance has five package formats, namely, (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64), and (5120,2,64). Only the subscribers with requesting rates higher than 153.6 kbit/s can be categorized into the multi-subscriber candidate
7-2 01 (2009-11-09)
8 Forward Scheduling and Forward Rate Limit
transmission instance. Multi-subscriber transmission instance must meet the following conditions: The instance is composed of more than one subscriber or composed of the DRC erasure mapped single user(s). Bit stuffing is implemented in descending order. Each flow has only one value. Bit stuffing determines which flow is converted into packets first.
8.1.2.2 Selecting the Transmission Instance with the Top Priority

Through the comparison between the packet metrics of a single-subscriber and multi-subscriber, the one with the largest packet metric is allocated the transmission instance. If the packet metrics are the same, the packet of single-subscriber is preferred to that of multi-subscriber, and the packet of multi-subscriber with a higher rate is preferred to that of multi-subscriber with a lower rate.
8.1.2.3 Maximizing Encapsulation Efficiency

The encapsulation efficiency is maximized without changing the data in the transmission instance. If a single-subscriber packet is allocated the transmission instance, it can be converted into a non-graded multi-subscriber packet when the load requirement is met. The single-subscriber packet must be compatible with the DRC. The single-user transmission instance can also be converted to multiuser transmission instance. This is not recommended. If transmission of a multi-subscriber packet can be satisfied with a lower rate, a (1024,4,256) packet can be converted into a ({128,256,512},4,256) packet. The format conversion of multiuser packages is not recommended.
8.2.2.4 Air Interface Scheduling Scheme

Three schemes are available: Balancing timeslot fairness and efficiency, sector throughput maximization, and area rate steadiness.

The telecom operators can select a suitable algorithm according to the charging strategy:
If the capacity is expanded, the scheme of balancing timeslot fairness and efficiency is recommended. If the traffic-based charging strategy is adopted, the scheme of sector throughput maximization is recommended.
If the telecom operator wants to guarantee the subscriber experience in key areas, the scheme of rate stabilization is recommended.
8.2 Forward Rate Limit

As a part of the Inter-User QoS function, forward rate limit differentiates subscribers by limiting their peak rates (physical layer rates).
01 (2009-11-09)
7-3
Contents

Currently, the forward rate limit function is implemented in two methods. During the definition of a subscriber, the information such as the subscriber grade and forward peak rate are written in the PDSN-AAA. The peak rate of a subscriber is limited through traffic shaping. Another method is to limit the rate through the AN-AAA.

This function takes effect after the gold-, silver-, and bronze-medal and private line subscriber grades are enabled.
7-4
01 (2009-11-09)
9 Reverse Scheduling and Reverse Rate Limit
9
9.1 T2P
Reverse Scheduling and Reverse Rate Limit
9.1.1 Token Bucket Mechanism

Code division multiplexing (CDM) is used on the reverse traffic channels of the CDMA2000 EV-DO Rel.0 system. In code division multiplexing, multiple ATs transmit data and thereby impose load on the sectors at the same time. Based on the change in the load on the sectors, the AN sends RA bits over the RA channel of each sector to inform the ATs of the load on the sector. Based on the RA bits, the ATs adjust their transmit rates. The operation is random and does not support QoS. In the CDMA2000 EV-DO Rev. A system, the Subtype3 RL MAC protocol supports QoS between multiple active MAC flows and realizes rate control by controlling the Traffic-to-Pilot power (T2P) ratio of each active flow. The AN sends RA bits according to the load on the sectors, and the ATs controls the transmission rate of each active flow according to the T2P resources allocated to them. In the absence of restrictions on the total transmit power of the ATs, multiple MAC flows in one AT are identical to multiple MAC flows in multiple ATs. Figure9-1 T2P token bucket mechanism
01 (2009-11-09)
9-1
Contents
The Subtype3 RL MAC protocol maintains a size-variable token bucket for an individual MAC flow. The T2P resources available for this flow are presented with the water level in the bucket. Subtype3 RL MAC manages active MAC flows and negotiates different T2P parameters for the MAC flows according to the service attributes of the MAC flows. These parameters determine the priority levels of the MAC flows in obtaining resources and the transmission modes of the MAC flows. Different streams correspond with different T2P resource outflows, which affect the load of all surrounding sectors and the RAB of the sector in the AT's active set. The T2P scheduler changes its inflows and bucket size according to the change of the RAB so that different streams can have different rates, thus meeting the reverse QoS requirements of different subscribers and different services of a subscriber. The water surface of the bucket relates to its inflow, outflow, and other factors. Inflow means T2P resources incoming to the bucket. It depends on the current sub-frame load and the maximum capacity of the bucket. Inflow impacts on outflow, water surface, and size of the bucket. Outflow means the maximum T2P resources available for the current sub-frame. It depends on the water surface, inflow, and assignment jitter factor of the bucket. Outflow of the bucket decides the size of the transmitted packets.
9.1.2 T2P Functions

T2P decides the size and number of sub-packets transmitted in the current sub-frame. In other words, T2P measures packet transmission capability of the AT in the current sub-frame. For packets in the same size, the AT can send them in the High Capacity (HC) mode or in the Low Latency (LL) mode. T2P resources required before and after the transition point are different. Figure9-2 shows the transition point. If the sub-packet number is smaller than or equal to the transition point value, PreTransitionT2P is used as the T2P value required for sending the sub-packet (unit: 0.25 dB). If the sub-packet number is larger than the transition point value, PostTransitionT2P is used as the T2P value required for sending sub-packets. Figure9-2 T2P transition point in HC transmission modes
9-2
01 (2009-11-09)
The following table lists the T2P resources required for sending packets in different sizes before and after the transition point. Packet Size (bit) T2PLoLat PreTransition (0.25 dB) 28 40 52 59 65 73 77 77 T2PLoLat PostTransition (0.25 dB) 3 15 28 35 40 46 52 57 T2PHiCap PreTransition (0.25 dB) 3 15 28 35 40 46 52 57 T2PHiCap PostTransition (0.25 dB) 3 15 28 35 40 46 52 57
128 256 512 768 1024 1536 2048 3072
01 (2009-11-09)
9-3
Contents
Packet Size (bit)
T2PLoLat PreTransition (0.25 dB) 82 87 93 105
T2PLoLat PostTransition (0.25 dB) 62 68 74 85
T2PHiCap PreTransition (0.25 dB) 62 68 74 85
T2PHiCap PostTransition (0.25 dB) 62 68 74 85
4096 6144 8192 12288
9.1.3 T2P Allocation Principles

QoS requirements vary with services:

Best Effort (BE) services (such as FTP and HTTP services) tolerate long E2E transmission delay and have no requirements on throughput.
Unlike BE services, the Assured Forwarding (AF) services specify the minimum throughput.
Expedited Forwarding (EF) services (such as VoIP and online games services) require short end-to-end delay but do not have strict requirements on throughput and PER.
T2P resource allocation principles vary with services due to their different QoS requirements.
EF services (such as VoIP) require short delay, so all arrived data must be immediately transmitted as small packets. This requires enough T2P resources available at any time. AF services require a minimum throughput. To ensure the minimum throughput, a large number of T2P resources are required to maintain a medium size of packets.
For BE services, T2P resources are allocated based on the service load. The packet size also greatly changes. The priority function (PF) indicates the quantity of T2Pinflow resources that the current flow can enter the steady state. It also indicates mapping between the reverse load and T2Pinflow resources. See Figure9-3. The PF curve varies with service types.
For an EF service, T2Pinflow changes slightly when the service load changes in a specified scope. In this case, available T2P resources are steady and able to meet the services requirements on delay. If the load exceeds the threshold, available T2P resources decrease to zero. This means that the system restricts the load of EF services.
The PF curve of AF services is similar to that of EF services. AF services, however, support a larger T2Pinflow range to maintain a medium packet size. In addition, more T2P resources are required to maintain a medium packet size. This greatly affects the load. Therefore, the load threshold of AF services is lower than that of EF services.
The PF curve of BE services shows that available T2P resources decreases till zero as the load increases. If the load decreases, the acceptable packet size increases.
Figure9-3 PF curves of different services
9-4
01 (2009-11-09)
9.2 Reverse BE Subscriber Scheduling Strategy

For BE services, the PF curve is divided into:
The difference is smaller in the case of a high load but is greater in the case of a low The difference is greater in the case of a high load but is smaller in the case of a low The difference is the same no matter the load is high or low.
load.
load.

Each PF curve shows different T2Pinflow resources available for BE flows of different grades when the ROT changes (that is, the load changes). Figure9-4 shows the mapping relations between loads of gold, silver, and bronze medal subscribers and their T2Pinflow resources when the difference is larger in the case of a low load. Figure9-4 Mapping relations between loads of gold, silver, and bronze medal subscribers and their T2P inflow resources
01 (2009-11-09)
9-5
Contents
When the load is the same (10lg (b/(1 - b)) = 1.5), the T2Pinflow resources available for gold/silver/bronze medal subscribers are 13 dB, 10 dB, and 7.8 dB respectively. That is, gold medal subscribers can use more T2Pinflow resources than silver medal subscribers, and silver medal subscribers can use more T2Pinflow resources than bronze medal subscribers. Therefore, the packet size of gold medal subscribers send is larger than that of silver medal subscribers, and the packet size of silver medal subscribers send is larger than that of bronze medal subscribers. The curve also shows that the difference in available T2P resources increases as the load drops. This curve suits the cases where scheduling priority is given to higher-grade subscribers in the case of a low load. The other two types of PF curve show the same relation between available T2P resources of different grade subscribers and their load. The difference in T2P resources, however, increases as the load rises if the difference is greater in the case of a high load but is smaller in the case of a low load. If the difference is the same despite the fact that the load is high or low, the difference in T2P resources allocated to different grade subscribers remains the same regardless of the load.

Modify PF curves for different grade subscribers by using the three types of PF curve parameters. In this way, flows of different classes can obtain different T2P resources according to the reverse load during scheduling. Therefore, the inter-user QoS function is implemented.
9.3 Reverse Rate Limit for Private-Line Subscribers

During the definition, a private line subscriber signs a contract with the telecom operator to ensure that the subscriber can obtain a stable bandwidth anytime. To ensure the fixed reverse rate of a private line subscribers throughput, set the related T2P parameters.
9-6
01 (2009-11-09)

The reverse rate of an EV-DO Rev. A user depends on its packet size and termination target. Table9-1 lists the mapping relations among physical layer data rates, packet sizes, and termination targets. Table9-1 Mapping relations among physical layer data rates, packet sizes, and termination targets Packet Size (bit) Transmit Duration 1 sub-frame 128 256 512 768 1024 1536 2048 3072 4096 6144 8192 12288 19.2 38.4 76.8 115.2 153.6 230.4 307.2 460.8 614.4 921.6 1228.8 1843.2 Transmit Duration 2 sub-frames 9.6 19.2 38.4 57.6 76.8 115.2 153.6 230.4 307.2 460.8 614.4 921.6 Transmit Duration 3 sub-frames 6.4 12.8 25.6 38.4 51.2 76.8 102.4 153.6 204.8 307.2 409.6 614.4 Transmit Duration 4 sub-frames 4.8 9.6 19.2 28.8 38.4 57.6 76.8 115.2 153.6 230.4 307.2 460.8 Effective Data Rate (kbit/s)
For packets in the same size, their data rates greatly vary with their termination targets. To fix the reverse rate of a subscriber, fix the packet size and termination target. To fix the packet size and termination target of a subscribers throughput, set the related T2P parameters.

The fixed rate that is required by DOA reverse private line subscribers can be implemented by setting the termination target to a fixed value, such as 0 (1 packet is terminated). In this case, Table9-2 is simplified as shown in Table 9-2. Table9-2 Mapping relations between reverse rate of private line subscribers and packet sizes
01 (2009-11-09)
9-7
Contents
Packet Size (bits)
Effective Data Rate (kbit/s) Transmit Duration 1 sub-frame
128 256 512 768 1024 1536 2048 3072 4096 6144 8192 12288
19.2 38.4 76.8 115.2 153.6 230.4 307.2 460.8 614.4 921.6 1228.8 1843.2
By setting T2P parameters, all reverse packets of private-line subscribers terminate at the first sub-packet, fixed T2P resources are allocated to reverse private-line subscribers, and maximum size of transmit packets are limited. Thus, when the inflow is adequate, the packet transmission rate of reverse private-line subscribers is fixed in a specified position. Reverse private-line subscribers are not differentiated in the aspect of service flows. Only packet formats are restricted.
9.4 Reverse Rate Limit for BE Flows of Grade Subscribers

Telecom operators hope that the system can support their differentiated services. BE flow reverse rate limit of grade subscribers helps telecom operators to provide differentiated services to their subscribers. Operators can classify their reverse subscribers and set a higher maximum rate for higher-grade subscribers.

According to the current default T2P settings, all subscribers on a sector with a low load can use 12288-bit packets. That is, the maximum rate of all subscribers BE flows is 1.8 Mbit/s. 0 lists the mapping relations between reverse rate of private line subscribers and packet sizes. When the packets of different sizes are transmitted in High Capability mode, the minimum
9-8 01 (2009-11-09)
T2P resource required by each subframe is as listed inTable9-3. To terminate the BE flow during sending the second or third sub-packet, more T2P resources are required, and the termination is hard to control. Applying efficient T2P resources to terminate the BE flow during sending the first sub-packet may waste the power, and the cell load is affected. Thus, to terminate the packets of BE service cannot be controlled properly. Table9-3 Mapping relations between packet size of BE service and T2P Payload Size (bits) 128 256 512 768 1024 1536 2048 3072 4096 6144 8192 12288 Data Rates (after 16-slots) 4.8 9.6 19.2 28.8 38.4 57.6 76.8 115.2 153.6 230.4 307.2 460.8 Average T2P (dB) 0.75 3.75 7 8.75 10 11 13 14.25 15.5 17 18.5 21.25
By setting T2P parameters, the T2P resources allocated to BE services can be restricted a specified range. Thus, the maximum packet size of BE services are controlled. The number of termination sub-packets cannot be controlled precisely. As a result, the rates of BE services cannot be accurately controlled, and only the maximum rate of a corresponding packet (when it terminates on the first sub-packet) can be restricted.

The reverse T2P algorithm enables telecom operators to set parameters according to different QoS requirements. The system limits BE flow rates for different class subscribers and provides different maximum rates to the subscribers according to their classes. This function enables telecom operators to limit reverse BE flow rates for gold/silver/bronze medal subscribers.
01 (2009-11-09)
9-9
10 Multi-Carrier Networking
10
10.1 Overview
Multi-Carrier Networking
This section describes AT camping and hard assignment strategies in the case of multi-carrier networking.
10.1.1 Demand for Multi-Carrier Networking

As the CDMA network grows, its traffic keeps increasing. In this case, multi-carrier networking is required. At the early stage of a CDMA network, all BTSs use the coverage provided by a single carrier (F1). As more and more subscribers choose the CDMA network, the load on the BTSs in the hot spot areas becomes heavier and heavier. If the load on the BTSs exceeds the maximum capacity of the single carrier, another carrier (F2) needs to be added. The capacity of the single carrier, however, can support the BTSs in light-traffic areas, so they continue to use the single carrier (F1). As a result, a boundary between single-carrier and multi-carrier areas appears in the network. As the number of subscribers further increases, the second carrier fails to support heavy traffic in the hot spot areas. Therefore, more carriers need to be added (F3, F4, ). At last, different areas are equipped with different quantities of carriers and different boundaries appear, as shown in Figure10-1. Figure10-1 Multi-carrier coverage in hot spot areas
01 (2009-11-09)
10-1
Contents
The carrier that covers the whole network is called the basic carrier, and those covers hot spot areas are called overlapped carriers. Cells in the areas covered with overlapped carriers are classified into two types. Neighbor cells of the areas covered by only the basic carrier are called boundary cells of overlapped carriers. Other cells are internal cells of overlapped carriers. Solutions described in this section apply to overlapped carriers caused by unbalanced traffic distribution and their boundary cells.
10.1.2 Problems in Multi-Carrier Networking

Multi-carrier networking must solve the following problems at least: 1 Inconsistent coverage provided by multiple carriers Forward and reverse coverage provided by different carriers in the same cell may vary due to the following causes:

Signals at different frequencies (bands) have different attenuation properties. External interference and load on carriers may also vary. Intra-frequency interference in the system varies.
In a boundary cell, the overlapped carriers bear lighter soft HANDOFF traffic and suffer from less intra-frequency interference. Therefore, they often provide larger coverage than the basic carrier. This inconsistency should be considered during frequency selection of AT hashes, access hard assignment, and hard handoffs. 2. Idle AT Frequency selection and network capture problems should be solved:

Which frequency an idle AT stays at How an idle AT sends a paging message How an AT performs an idle HANDOFF
In a boundary cell as shown in 0, if an AT hash that stays at the overlapped carrier moves out of the cell, it is disconnected from the network because no overlapped carrier exists outside the cell. 3. Multi-carrier traffic load sharing Multiple carriers are configured to share traffic load. Reasonable use of multiple carriers can bring the following benefits:

Improving access success rate Upgrading performance of data services Lowering call drop rate Improving resource usage rate
4.
Mobility management During a soft or hard HANDOFF when an AT is in a call, the AT becomes idle after the connection is released. Avoid call drop due to a hard HANDOFF. Ensure that the AT becomes idle without disconnecting from the network after the connection is released.
5.
Avoidance of interference Ensure that all ATs stay at carriers with less interference. Ensure that all call requests are assigned to carriers with less interference. To eliminate the interference on a network, perform frequency clearance. All other measures can only mitigate interference.
10-2
01 (2009-11-09)
10.2 Camping of Idle ATs

See the previous section.

An EV-DO Rev. A AT decides on which channel it camps according to the Hash algorithm. If the AT detects an OverheadMessages.Updated indication in the queue, it executes the Hash algorithm to choose the channel it camps on. Before initial negotiation of an EV-DO Rev. A AT, the terminal property is EV-DO Rel.0 by default. In this case, the AT must choose its channel based on the channel list field in the SectorParameters message. If the property reported by an EV-DO Rev. A AT after initial negotiation is EV-DO Rel.0, the AT works as an EV-DO Rel.0 AT. If the property reported by an EV-DO Rev. A AT after initial negotiation is EV-DO Rev. A, the AT works as an EV-DO Rev. A AT. The AT of EV-DO Rel.0 camps on a frequency according to the EV-DO Rel.0 protocol. The AT of EV-DO Rev. A follows the EV-DO Rev. A protocol. The Hash algorithm input of the EV-DO Rel.0 AT and that of the EV-DO Rev. A AT are different.
10.2.2.1 Hash Algorithm for EV-DO Rel.0 ATs

The AT obtains information on available channels on the current sectors according to the channel list field in the SectorParameters message. If the channel list does not contain any channel, the AT camps on the current channel. If the channel list contains one channel, the AT camps on the listed channel. If the channel list contains two or more channels, the AT decides on which channel it camps according to the Hash function.
Key refers to SessionSeed. L stands for its low 16 bits and H for its high 16 bits. N means the value of the ChannelCount field in the SectorParamters message. Decorrelate equals zero. SessionSeed means public data of the address management protocol.
10.2.2.2 Hash Algorithm for EV-DO Rev. A ATs

In the EV-DO Rev. A system, the Sectorparameters message provides two new fields extended channel list and AccessHashingChannelMask. An EV-DO Rel.0 AT chooses the channel it camps on according to the EV-DO Rev.1 protocol, and an EV-DO Rev. A AT chooses the channel it camps on according to the EV-DO Rev. A protocol. An EV-DO Rev. A AT chooses its channel based on the fields channel list and extended channel list in the SectorParameters message. Both channel list and extended channel list define AccessHashingChannelMask. In this case, the AT calculates N of each channel specified in the SectorParameters message according to the following formula:
01 (2009-11-09)
10-3
Contents
Where j means channel number j. Mj means AccessHashingChannelMask of channel number j. AccessHashingClassMask is a negotiation parameter.
indicates the AND calculation performed between the two binary numerals. [AccessHashingMaskLength:0] represents bit 0 to bit (AccessHashingMaskLength) of AccessHashingClassMask. Nj stands for the number of 1s after the preceding calculation. Assume that two carriers, F1 and F2, exist in a sector. To make the EV-DO Rev. terminal only camp on F1 rather than F2, configure F1 with more bits whose AccessHashingChannelMask is set to 1.
The AT chooses the channel with the largest Nj to camp on. If m channels provide the largest Nj, the AT chooses its channel by using the following Hash function:
N here means the number of the channels that provide the largest Nj.
10.2.3 Camping Strategies for Idle ATs

The system provides three camping strategies for idle ATs: 1. 2. 3. If all available overlapped carriers are provided by the EV-DO Rel.0 system, all ATs camp on EV-DO Rel.0 carriers at random. If all available overlapped carriers are provided by the EV-DO Rev. A system, all ATs camp on EV-DO Rev. A carriers at random. If both the EV-DO Rel.0 and Rev. A systems provide available overlapped carriers, EV-DO Rel.0 ATs camp on EV-DO Rel.0 carriers and EV-DO Rev. A ATs camp on EV-DO Rev. A carriers at random.

This function applies to the multi-carrier networking scenario.
10.3 Paging
The idle status of ATs is based on the location update between subnets. Therefore, the minimum paging unit of the system is a subnet. The subnet planning has a profound impact paging load and paging success rate. The load of the paging channel increases with the number of subscribers in a subnet. When the load increases to a certain degree, congestion may occur and paging success rate is affected. The UATI updates more frequently if the size of the subnet is smaller. The heavy load of the access channel and the entire system affects the access speed and success rate. BSC6680 V300R006C08 and later versions supports two paging strategies:
10-4
01 (2009-11-09)
1. 2.
The paging message is transmitted three times. It is transmitted in the current subnet the first two times. For the third time, the paging message is sent within the current AN. The paging message is transmitted three times. First time, it is transmitted based on the distance. Then, it is sent within the current subnet. Last time, it is transmitted within the current AN.
Currently, paging is carried out in the subnets of the EV-DO network. The paging message is initiated for the first and second times in the subnet where the terminal is registered recently. For the third time, the paging message is transmitted within the current AN.

Distance-based paging, mainly applied to the network with high loads on the control channel, reduces the paging range, thus decreasing the loads of the control channel. Distance-based paging requires that each carrier must be configured with the accurate information about the longitude and latitude and that no RRU is configured with the GPS clock. Thus, in the case that the information about the longitude and latitude is not accurate and that too many RRUs exist in the network, distance-based paging cannot be used.

If RouteUpdateRadiusOverhead and the session attribute RouteUpdateRadiusMultiply are not set to 0, distance-based paging is used; otherwise, subnet-based paging is applied. In the case of distance-base paging, the paging range is calculated based on the distance during the first paging. For the second time, the paging message is transmitted within the current subnet. For the third time, this message is transmitted within the current AN. The paging range is calculated on the basis of the distance between the BTS where the AT is registered currently and the BTS where the AT is registered last time. xL and yL respectively represent the longitude and latitude of the BTS in an active set when an AT sends the RUM last time. xc and yc stands for the longitude and latitude of the current BTS. The following formula is used to calculate the distance.
If r rm x ro + ra, the paging message is transmitted within the coverage of the current BTS. ro stands for the field RouteUpdateRadiusOverhead carried in SectorParameters. rm and ro are the attributes for negotiation configuration.
01 (2009-11-09)
10-5
Contents
10.4 Hard Assignment

Hard assignment is a traffic assignment strategy for multi-carrier networking. For a multi-channel cell, the SectorParameters message of the EV-DO system can configure multiple channels. When an AT attempts to access the cell, it chooses one of the channels specified in the SectorParameters message by using the Hash algorithm. The Hash algorithm ensures that ATs are evenly distributed on multiple channels in the long-term measurement perspective. It, however, fails to ensure that ATs are evenly distributed at any moment. In addition, different types of ATs are assigned different channel numbers, or calls are assigned a preferred specified channel number. In this case, hard assignment is required. When an AT accesses the AN through a channel on a frequency, the AN sends a TCA message to the AT, assigning another frequency for the AT to set up a TCH.

Figure10-2 shows the process of hard assignment. Figure10-2 Process of hard assignment
10.4.2.1 Hard Assignment Algorithm

The preceding figure shows that the RSSI-based hard assignment has the highest priority, followed by the access priority hard assignment, EV-DO Rev. A prevision priority hard assignment, and load-balancing hard assignment. The working principles for these assignments are described as follows:
EV-DO reverse RSSI-based hard assignment The system supports two RSSI-based hard assignment modes (based on absolute RSSI and based on both the difference in the number of equivalent users and the difference in relative RSSI)
1.
During hard assignment based on absolute RSSI, the BSC sets deletion flags of all carriers on the access sector. In the reverse RSSI statistical window, MainNum means the number of main RSSIs that exceed the upper threshold and DivNum means the number of diversity RSSIs that exceed the upper threshold. If both MainNum and DivNum are higher than or equal to the reverse interference decision threshold, the BSC sets the deletion flag of the carrier to TRUE. If they are lower than the reverse interference decision threshold, the BSC sets the deletion flag of the carrier to FALSE. If
01 (2009-11-09)
10-6
no carrier for assignment is detected according to all assignment algorithms, carrier remedy is required. Then, the carrier with the TRUE deletion flag, admission, and minimum main and diversity RSSIs within the access sector is allocated to AT to set up the service channel. During hard assignment based on both the difference in the number of equivalent users and the difference in relative RSSI, the BSC detects the maximum and minimum RSSI values of all carriers on the access sector. If the maximum RSSI is lower than the RSSI absolute threshold, the BSC sets deletion flags of all carriers to FALSE. If the maximum RSSI is higher than or equal to the RSSI absolute threshold, the BSC sets the deletion flag of the carrier with the minimum RSSI to FALSE. EV-DO Rev. A prevision priority hard assignment This assignment is applied only to the EV-DO Rev. A carriers. If both the EV-DO Rel. 0 terminals and the EV-DO Rev. A terminals exist in the network, the system can assign these terminals to different carriers to reduce the impact of the EV-DO Rev. A terminals on the reverse rate of EV-DO Rel. 0 terminals. During the initial configuration initiation, the EV-DO Rev. A terminals use the EV-DO Rel. 0 attributes. Therefore, these terminals are assigned to the EV-DO Rev. A carriers supporting the EV-DO Rev. A prevision priority hard assignment. The working principles for the EV-DO Rev. Access priority hard assignment 1. 2. The AN assigns the call to the access carrier. (The load on the access carrier must be lower than the hard assignment threshold.) If the load on the access carrier is higher than or equal to the hard assignment threshold, access priority assignment fails and the next hard assignment algorithm is required. Multi-band assignment is not involved in this assignment algorithm. Load-balancing (basic) hard assignment When only the load-balancing hard assignment algorithm (other hard assignment algorithms are disabled) is enabled, the system assigns subscribers to the carrier with the lowest load through the load measurement method. Note that the hard assignment threshold cannot be used currently.
10.4.2.2 Inter-Band Hard Assignment

The system performs configuration negotiation to query the frequency band supporting capability of an EV-DO Rev. A terminal. The inter-band hard assignment function is available only for the EV-DO Rev. A terminals that support the required frequency bands. Because different frequency bands have different coverage scopes, the system assigns terminals to a specified carrier only when all of the following conditions are met: In addition, the AN does not perform the hard assignment when an AT accesses the network and performs initial configuration negotiation, because the system has not confirmed the bands supported by the AT.
10.4.2.3 Hard Assignment Optimization Algorithm Based on the Timeslot Usage

The traditional method of the load measurement based on the timeslot usage means that load balancing is performed based on the timeslot usage of real-time services rather than based on the timeslot usage of the forward traffic channel. To achieve the RLP throughput balance of the carrier in a sector, the hard assignment optimization algorithm based on timeslot usage load measurement is recommended. The details of the optimization algorithm are as follows:
01 (2009-11-09)
10-7
Contents
Each carrier can be in the high load state or low load state. The carrier transition between the two states is determined by two thresholds, as shown in the following figure.
When the carriers in a sector are in the low load state, hard assignment is carried out to enable the terminal to work on the carrier with the lowest timeslot usage. When the carriers in a sector are in the high load state, hard assignment is carried out to enable the terminal to work on the carrier with fewest equivalent subscribers. When both the carriers in the high load state and in the low load state exist in a sector, the terminal is assigned to work on the carrier with the lowest timeslot usage and in the low load state. In addition, if the timeslot usage of the carrier through which the terminal accesses the network is lower than the access priority timeslot usage threshold, hard assignment is not performed on the terminal and the terminal can directly work on this access carrier.

The following table lists application scenarios of each hard assignment algorithm. Scenario This algorithm is enabled if some carriers on a sector are affected by reverse interference. This function assigns calls to the carriers with little or no interference. ATs are evenly distributed on all channels by using the Hash algorithm to ensure load balancing between all channels. If an AT accesses the AN through carrier A and the load on carrier A is lower than the hard assignment threshold, the AN assigns the call to carrier A. Hard Assignment Algorithm EV-DO reverse RSSI-based hard assignment
Access priority hard assignment
10-8
01 (2009-11-09)
This algorithm applies to EV-DO Rev. A carriers only. If EV-DO Rev. A and EV-DO Rel.0 ATs coexist, assign them to different EV-DO Rev. A carriers to take different load control measures. At coverage boundaries between cities and suburbs, calls are set up on carriers that provide larger coverage whenever possible to reduce hard HOs. This algorithm is used to balance loads among carriers. The RLP throughput of the carrier needs to be balanced.
EV-DO Rev. A prevision priority hard assignment
Priority-based hard assignment
Load-balancing (basic) hard assignment Load-balancing hard assignment based on the timeslot usage
When the ASSALWDO parameter is set to YES, only the load-balancing hard assignment algorithm and priority hard assignment algorithm take effect. The other hard assignment algorithms can be used only when the corresponding algorithm switches are enabled. When all the hard assignment algorithm take effect, the RSSI hard assignment has the highest priority to be used by the system, followed by the access priority hard assignment, prevision priority hard assignment (choose the carrier of the same network, which has a high priority and the load lower than the hard assignment threshold), load-balancing hard assignment (choose the carrier with a high priority and low load), and interference avoidance.
01 (2009-11-09)
10-9
01 (2009-11-09)
10-1
11 Transmission Resource Management
11

Transmission Resource Management
11.1 Overview
The Abis interface is a logical interface between a BSC and a BTS. The Abis interface consists of the following: Abis signaling Abis service Operation & Maintenance Link (OML) signaling
Abis transmission resource management mainly includes the flow control, congestion control, and admission control between the BTS and the BSC.
11.2 Abis Networking Mode

11.2.1 Interface Mode
Telecom operators may need different Abis networking modes because they have different types of transmission resource. Huawei EV-DO access network supports various Abis networking modes to meet operators' requirements. Today, Huawei supports the following networking modes: 1. 2. 3. Both BTSs and their BSC use E1/T1 links. Both BTSs and their BSC use FE links. BTSs use E1/T1 links, but their BSC uses FE links.
11.2.2 Transmission Mode

Different Abis networking modes use different transmission modes: 1. Bandwidth monopolization transmission Each BTS exclusively occupies a transmission link or link group to the BSC. 2. Fractional ATM transmission
01 (2009-11-09)
11-1
Multiple BTSs share the same transmission link or link group to the BSC. Each BTS uses fixed timeslots and bandwidth. In this mode, BTSs can share transmission resources with other devices that support fractional ATM transmission. 3. Bandwidth sharing transmission Multiple BTSs share the same transmission link or link group to the BSC. Data forwarding in different link groups supports transmission cascading. In this mode, BTSs share physical bandwidth. The BSC can specify the bandwidth to be occupied by each BTS.
11.3 Abis Transmission Resource Management

Transmission resources are valuable to most telecom operators. Abis transmission resource management aims for a higher quality of data service experience by using the limited Abis bandwidth more profitably. Abis transmission resource management provides bandwidth management algorithms as its core functions.
11.3.1 Stage-by-Stage Flow Control

Abis flow control is used to limit the data traffic sent by the FMR to a BTS according to the receiving capacity of the BTS. This avoids packet loss due to buffer overflow of the BTS. Downlink flows are controlled stage by stage. That is, flows are controlled respectively between the BTS to the BSC, between the BSC and the PCF, and between the PCF and the PDSN. See Figure11-1. The data recipient in each stage reports the available buffer timely. According to the available buffer, the sender speeds up or slows down its data transmission to avoid data overflow and improve system throughput. Flow control triggered stage by stage ensures that data is transmitted in real time and bandwidth is effectively used. Figure11-1 Stage-by-stage flow control
1.
Flow control between the BTS and the BSC The flow control over the Abis interface between the BTS and the BSC limits the amount of the data transmitted by the BSC within the receiving capability of the BTS to avoid buffer overflow. The EV-DO network adopts the request mechanism for transmitting data services over the Abis interface because few buffer space exists in the chips of the BTS channel board. This request mechanism controls the amount of the data sent by the quick sender within the receiving capability of the slow receiver, thus ensuring that the data amount of the BSC does not exceed the limit of the receive buffer space.
2.
11-2
Flow control between the BSC and the PCF
01 (2009-11-09)
The downlink flow control between the BSC and the PCF operates as follows: The BSC adds the information about the next byte number and receiving window size, which are expected by the RLP flows, to the reverse data packets. If no reverse data packet exists, the BSC constructs a blank flow control packet for adding the preceding information to the PCF after the flow control timer expires. The size of the receiving window is calculated based on the data that can be received by the remaining RLP buffer space.
11.3.2 Abis Interface Congestion Control

Congestion means that the data rate of a service drops due to insufficient resources. The BSC controls the amount of data sent in the forward transmit channel to avoid packet loss caused by transmission congestion on the Abis interface.
Forward Congestion Control Based on the BTS Request

Based on the Abis bandwidth allocated to the subscriber, DRC-requested rate, rate limit for the subscriber grade, and data amount of the FMR forward buffer, the BTS constructs a congestion control message and sends it to the BSC. According to the information contained in this message, the FMR of the BSC determines the amount of data to be transmitted to the subscriber and guarantees the stability of data transmission and the fairness among subscribers. The forward congestion control function based on the BTS request is supported by the BSC6680 V200R002, V200R003, V300R001, and V300R006C01.
Forward Congestion Control Based on Back Pressure of BSC Interface Boards

On a BSC interface board, each transmitting port has eight sending queues. The sending queues receive data with different priorities from the FMR. Table11-1 lists the mapping between queues and data priorities. Table11-1 Mapping between queues and data priorities on a BSC interface board Queue ID 0 1 2 3 4 Data Type OAM (operation and maintenance) Internal signaling 1X voice service EF services (real-time voice/video/games) of private line subscribes

BACMS services AF services 1X data services
5 6 7
BE services of gold medal subscribers BE services of silver medal subscribers BE services of bronze medal subscribers
The BSC interface board detects the length of queues 4 to 7. If a queue of a port exceeds the congestion threshold, the BSC interface board determines that the port is congested. In this case, the BSC interface board sends a congestion message to the FMR, requesting the FMR to lower the transmission rate of the port. If the BSC interface board detects that the lengths of
01 (2009-11-09) 11-3
queues 4 to 7 of a port which is in the congested state are smaller than the congestion clearance threshold, the BSC interface board determines that the port is not congested. In this case, the BSC interface board sends a congestion clearance message to the FMR, requesting the FMR to increase the transmission rate of the port. Figure11-2 shows the schematic diagram of the congestion control. Figure11-2 Forward congestion control based on back pressure of BSC interface boards
Reverse Congestion Control Based on Back Pressure of BTS Interface Boards

The principle of reverse congestion control is similar to that of forward congestion control. In reverse congestion control, the BTS interface boards rather than the BSC interface board performs the detection and the AT rather than the FMR adjusts the transmission rates. On the BTS interface board, there are also eight queues for receiving reverse data with different priorities. Table11-2 lists the mapping between queue priorities and data types on a BTS interface board. Table11-2 Mapping between queue priorities and data types on a BTS interface board Queue priority 0 1 2 3 4 5 6 7 Data Type OAM Internal signaling 1X Voice services Data transmitted in LL mode of private line subscribers 1X data services Data transmitted in HC mode or EV-DO Rel. 0 data of gold medal subscribers Data transmitted in HC mode or EV-DO Rel. 0 data of silver medal subscribers Data transmitted in HC mode or EV-DO Rel. 0 data of bronze medal subscribers
11-4
01 (2009-11-09)
The BTS interface board detects the length of queues 4 to 7 of each port in real time. If the BTS interface board detects that a queue of a port exceeds the congestion threshold, it determines that the port is congested. In this case, the BTS interface board sends a congestion message to the channel board. The channel board chooses one or more sectors that occupy the highest reverse bandwidth on the Abis interface, and then adjusts their RAB threshold to the minimum value. In this case, the RAB becomes busy and the ATs on these sectors decrease their transmission rates to relieve the reverse congestion. If the BTS interface board detects that the lengths of queues 4 to 7 of a port which is in the congested state are smaller than the congestion clearance threshold, the BTS interface board determines that the port is not congested. In this case, the BTS interface board sends a congestion clearance message to the channel board, requesting the channel board to recover the RAB threshold.
11.3.3 Abis Bandwidth Admission Algorithm of BE Services

Admission control ensures that the admissible traffic streams obtain sufficient Abis bandwidth and restricts the number of calls to access the network and prevents the QoS from deteriorating. On the Abis link, no bandwidth grant is issued to BE services and the bandwidth already allocated to the BE service may be preempted by EF or AF services. When air interface resources are sufficient, the user experience of BE services may decline because of insufficient bandwidth on the Abis link. Therefore, a proper bandwidth admission strategy is added for the BE services. The admission decision algorithm for forward BE services is as follows:
Objectives The admission of BE services is permitted only when there is sufficient bandwidth that meets the rate requirement of the BE service. To ensure that EF and AF services are implemented prior to BE services, no rate grant is issued to the active BE services.
Allocation method When choosing a PVC, choose the channel that can allocate the maximum bandwidth for BE services from links whose free bandwidth meets the allocation requirements. Allocation formula: Free bandwidth of a link (that is, the bandwidth left after the bandwidth for EF/AF traffic is allocated)/number of BE traffics on the link. The formula is as follows:
The bandwidth allocated for the DOA AF/EF traffic on the related link is deducted. The bandwidth allocated for the BE flow on the related link is not deducted.
Abis bandwidth admission method of BE services Set a threshold for the Abis bandwidth admission of BE services. When allocating the bandwidth, find the link whose value of BE flow experience of the PVC is the greatest. Compare the value of BE flow experience of the PVC to the Abis bandwidth admission threshold for BE services. If the value is smaller than the threshold, the admission is rejected.
Related Parameters
01 (2009-11-09)
11-5
11.4 Abis Frame Multiplexing Technology

The frame multiplexing technology improves the Abis transmission efficiency. The FP Mux technology improves the packet efficiency of the protocol stack by transmitting several Abis frames with similar properties in one UDP packet.
11.5 Abis Transmission Efficiency

Figure11-3 shows the EV-DO Abis transmission efficiency. Figure11-3 EV-DO transmission efficiency
11-6
01 (2009-11-09)
12 Energy Saving of the EV-DO Rev. A System
12
Energy Saving of the EV-DO Rev. A System
12.1 Algorithm Background

For commercial networks, there are busy hours and idle hours. In busy hours, operators must enable all carriers to ensure the QoS. In idle hours, however, operators can disable certain carriers to reduce the operation cost (OPEX). In a long-term perspective, this method can greatly reduce carriers' OPEX. ATs, however, may be disconnected from the ANs when carriers shut down power amplifiers (PAs). This function uses different HO algorithm in different scenarios to avoid call drops of ATs.
12.2 Function Description

12.2.1 Principles for Shutting Down Carriers
Comply with the following principles when shutting down carriers to guarantee that the subscriber experience is not impacted.
Do not shut down the PAs of the following carriers:

Carriers configured with BCMC Carriers used in pseudo pilot scenarios Carriers that serve private line subscribers or 1X trunking network subscribers
In case of festivals (such as national and international festivals) or natural disasters (such as earthquakes and tsunamis), a large number of subscribers may access certain carriers during the period when the PAs are shut down. To allocate system resources more properly or to minimize losses caused by natural disasters, the system shuts down PAs of carriers one by one but restores them all at a time.
In this document, carriers are classified into the following three types:

Basic carriers Non-basic carriers Other carriers (pseudo pilots)
01 (2009-11-09)
12-1
Carriers cannot shut down the basic or other carriers. The basic and other carriers often provide the largest coverage. Carriers can shut down non-basic carriers during the specified period when the system is not busy. Only the basic carriers are configured with paging channels. Private line subscribers are accessed to the basic carriers based on the configured frequency.
Shut down non-basic carriers in sequence based on their loads. The carrier which is in the Shuttingdown state does not support soft handover.
12.2.2 Shutting Down a Carrier

Traffic statistics show that the system is idle from 00:00 a.m. to 06:00 a.m. Therefore, set 00:00 a.m. as the time when the carrier is shut down. The system performs the following operations to shut down a carrier: 1. Check whether requirements for shutting down a carrier are met. If the requirements are met, all subscribers on the carrier are migrated. 2. Shut down the carrier after all subscribers are migrated.
12.2.3 Re-enabling Carrier Handoff Process

After idle hours, more and more subscribers access the system and the load of single carrier rises gradually. In this case, enable the carrier to improve subscriber experience. The system enables carriers when any of the following conditions is met: 1. After the idle hours, that is, after 06:00 a.m. (configurable), the system enables inactive carriers regardless of the system load. 2. During idle hours, that is, from 00:00 a.m. to 06:00 a.m., the load of active carriers exceeds the restoration threshold. In this case, the system enables all inactive carriers in the sector.
12-2
01 (2009-11-09)
13 EV-DO Test Call
13

EV-DO Test Call
EV-DO test calls are performed to measure the performances of the forward channel and the reverse channel in real environment. The system collects statistics about the following objects: Active set changes detected by the AT in the idle state Service sector changes detected by the AT in the connected state Delay of the air interface link
In real environment, the AT selects the access sector, forward rate, and reverse rate based on the real radio environment. By using this function, the AN can specify the access sector, forward rate, and reverse rate for the AT. In the loopback mode, the system can collect statistics of counters, such as packet error rate and delay, on the air interface.

As an O&M function, test calls are initiated by users on the AT. Users can specify the tested AT, test type, and related parameters based on the mobile node identification (MNID). For example, UEs can specify the tested Sector ID, reverse channel rate, and test duration. The test types are as follows:
FTAP handoff rate performance measurement in idle state: Measure the handoff rate of pilots in active sets in idle state and the frame error rate on the forward control channel based on the forward test application protocol (FTAP). FTAP handoff performance measurement in connected state: Measure the handoff rate of service sectors in connected state and packet error rate on the forward control channel. FTAP forward channel performance measurement: Measure the counters, such as the throughput and packet error rate of the FTAP forward channel. RTAP reverse channel performance measurement: Monitor the RTAP enhanced reverse channel performance. FETAP handoff rate performance measurement in idle state: Measure the handoff rate of pilots in active sets in idle state and the frame error rate on the forward control channel based on the forward enhanced test application protocol (FETAP).
01 (2009-11-09)
13-1
FETAP handoff performance measurement in connected state: Measure the handoff rate of service sectors in connected state and packet error rate on the forward control channel. FETAP forward channel performance measurement: Measure the counters, such as the throughput and packet error rate of the FETAP forward channel.
RETAP reverse channel performance measurement: Monitor the RETAP enhanced reverse channel performance.
13-2
01 (2009-11-09)
14 EV-DO White List Function
14
EV-DO White List Function

In special scenarios such as exhibition halls and important occasions, good network performance for specific subscribers in the white list must be guaranteed. The EV-DO white list function is used to provide dedicated frequencies for specified subscribers and configures these subscribers as high-grade subscribers to guarantee their priority over the air interface and on the Abis link.

14.2.1 Residence Strategy for White List Subscribers
The paging messages for the ordinary subscribers are not transmitted on the dedicated carriers. Additionally, the system cannot ensure that only the subscribers in the white list camp on the dedicated carriers or that only ordinary subscribers camp on the ordinary carriers. Therefore, it is recommended that all subscribers camp on the ordinary carriers and that the assignment should be implemented to ensure that the subscribers in the white list access the network through the dedicated carriers.
14.2.2 Access Strategy for White List Subscribers

The system allows ordinary subscribers to set up negotiated connections on the dedicated carriers when the subscribers' VIP properties are unavailable because the system has not obtained the ESNs or MEIDs of the subscribers. Connection setup in other cases is processed as follows: 1. If the access carrier is a dedicated carrier, the system performs hard assignment (this operation is not controlled by the hard assignment switch) by default: The load-balancing hard assignment is performed for the subscribers in the white list and they are preferentially assigned to work on the dedicated carriers that support the subscriber groups in the white list; if none of the dedicated carriers supports the subscriber groups in the white list, the subscribers in the white list are assigned to work on the ordinary carriers; ordinary subscribers are directly assigned to work on the non-dedicated carriers (if the carriers in a sector are all dedicated carriers, the access requests of ordinary subscribers are rejected). If the access carrier is an ordinary carrier, by default, hard assignment (this operation is not controlled by the hard assignment switch) is also implemented on the subscribers in the white list. The system assigns these subscribers in the white list to work on the
2.
01 (2009-11-09)
14-1
dedicated carrier (supporting the subscriber group to which these subscribers in the white list belong) with the lowest load in the same sector. If no dedicated carriers exist in this sector or if the admission through dedicated carriers fails, the subscribers in the white list are assigned to work on the ordinary carriers. For ordinary subscribers, hard assignment is controlled by the hard assignment switch, and they can be assigned to work only on the ordinary carriers.
14.2.3 Handoff Strategy for White List Subscribers

White list subscribers can be handed off between ordinary carriers and dedicated carriers through soft handoffs. To implement such operations, the dedicated carriers must support the subscriber group to which these subscribers in the white list belong. Whether the subscribers in the white list can use the dedicated carriers is determined by the carriers through which these subscribers access the network. To be more specific, only the subscribers in the white list accessing the network through dedicated carriers can use the dedicated carriers. (The subscribers in the white list that are handed off to the dedicated carriers cannot use the dedicated carriers.) Ordinary subscribers cannot be handed off from ordinary carriers to dedicated carriers through soft handoffs.
14-2
01 (2009-11-09)

01 CDMA Performance Principles (EV-DO) V3.3 For Customers PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

01 CDMA Performance Principles (EV-DO) V3.3 For Customers PDF

Încărcat de

Drepturi de autor:

Formate disponibile

CDMA Performance Principles (EV-DO) V3.

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

CDMA Performance Principles (EV-DO) V3.3 for Customers

Huawei Technologies Proprietary

2 EV-DO Rev. A Principle ...........................................................................................................2-1

3 QoS Mechanism of the EV-DO Rev. A System....................................................................3-1

CDMA Performance Principles (EV-DO) V3.3 for Customers

4 Call Signaling Flow ...................................................................................................................4-1

5 Admission and Load Control...................................................................................................5-1

6 Handoff Algorithm ....................................................................................................................6-1

CDMA Performance Principles (EV-DO) V3.3 for Customers

7 Reverse Power Control..............................................................................................................7-1

8 Forward Scheduling and Forward Rate Limit ......................................................................7-1

9 Reverse Scheduling and Reverse Rate Limit........................................................................9-1

11 Transmission Resource Management ................................................................................11-1

12 Energy Saving of the EV-DO Rev. A System ...................................................................12-1

13 EV-DO Test Call.....................................................................................................................13-1

14 EV-DO White List Function.................................................................................................14-1

CDMA Performance Principles (EV-DO) V3.3 for Customers

CDMA Performance Principles (EV-DO) V3.3 for Customers

1.1.4 Compilation and Review Record

Jiang Wei, Xie Zhuogang Jiang Wei, Xie Zhuogang

Sun Wenjie, Wu Jie, Chen Chao, Zhang Rui Wu Yufeng

Wu Jie, Xu Binbin, Xie Yunjuan, Chen Chao

Jiang Wei, Xie Zhuogang

CDMA Performance Principles (EV-DO) V3.3 for Customers

Reviewer (External) Jiang Wei, Xie Zhuogang, Li Yuanxia Huang Feiquan

Reviser Chen Yanming

Li Xuchao, Ye Guojun Chen Yanming Xi Le

Xi Le, Li Xuchao Chen Yanming Li Wei

Jin Yanfei, Wang Jianyong

1.2 Agreement and Explanation

This part describes the functions and principles of an algorithm.

1.3 Abbreviations and Acronyms

CDMA Performance Principles (EV-DO) V3.3 for Customers

CDMA Performance Principles (EV-DO) V3.3 for Customers

2 EV-DO Rev. A Principle

EV-DO Rev. A Principle

2.2 EV-DO Rev. A Protocol Stack Model

CDMA Performance Principles (EV-DO) V3.3 for Customers

2 EV-DO Rev. A Principle

Protocol layer functions:

Physical layer: It defines the following information on forward/reverse physical channels:

Security layer The functions of the security layer are:

Connection layer The functions of the connection layer are:

The following describes the related protocols:

CDMA Performance Principles (EV-DO) V3.3 for Customers

2 EV-DO Rev. A Principle

Timeslot structure Channel identifier (ID)

2.3.1 Forward Channel

The MAC channel consists of:

The TCH transmits data packets in the physical layer.

2.3.1.2 Timeslot Structure

CDMA Performance Principles (EV-DO) V3.3 for Customers

2 EV-DO Rev. A Principle

2.3.2 Reverse Channel

ACH The ACH comprises:

Pilot channel Data channel

Reverse TCH The reverse TCH consists of the following sub-channels:

The MAC channel consists of the following sub-channels: