NT-CDMA 1xEV-DO DO-RMC Theory of Operations

411-2133-514
CDMA
1xEV-DO DO-RNC
Theory of Operations
1xEV-DO 3.0 Preliminary 03.06 October 2005
Whats inside...
Introduction DO-RNC hardware architecture DO-RNC software architecture End-to-end call flow DO-RNC redundancy DO-RNC capacity DO-RNC OA&M Appendix: A12 Messages
test
CDMA
1xEV-DO DO-RNC
Document number: 411-2133-514 Product release: 1xEV-DO 3.0 Document version: Preliminary 03.06 Date: October 2005
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright 2004-2005 Nortel Networks, All Rights Reserved Originated in the United States of America/Canada NORTEL NETWORKS CONFIDENTIAL
The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. * Nortel Networks, the Nortel Networks logo, the Globemark, and Unified Networks are trademarks of Nortel Networks. CDMA2000 is a trademark of Telecommunications Industry Association (TIA). CDMA2000 1X is a trademark of the CDMA Development Group. Internet Explorer is a registered trademark of Microsoft Corporation. Netscape is a registered trademark of Netscape CommunMotorola 750 Power PC is a trademark of Motorola.Solaris, Sun, Sun Fire, Sun StorEdge, and Ultra Enterprise are trademarks or registered trademarks of Sun Microsystems, Inc. VxWorks is a trademark of WindRiver.All other trademarks are the property of their respective owners. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document.
ii Nortel Networks Confidential
Copyright 2004-2005 Nortel Networks
411-2133-514
Preliminary
03.06
October 2005
Nortel Networks Confidential
iii Copyright 2004-2005 Nortel Networks
Publication history
October 2005 1xEV-DO 3.0, Preliminary 03.06. Prepare document for preliminary release. September 2005 1xEV-DO 3.0, Draft 03.05. Changed the title of this NTP to 1xEV-DO DORNC Theory of Operations. 1xEV-DO 3.0, Draft 03.04. Added standard references to About this document. August 2005 1xEV-DO 3.0, Draft 03.03. Corrected Unsuccessful prior A13 dormant handoff call flow description. 1xEV-DO 3.0, Draft 03.02. Performed the following changes: Updated names of NTP references in the Related documents section. Added technical content and performed edits.
1xEV-DO 3.0, Draft 03.01. Updated Related documents section Made formatting changes
1xEV-DO 2.2, Standard 02.09. Replaced Figure 3-3 with Table 3-1, Manufacturer Code to M Value conversion table. June 2005 1xEV-DO 2.2, Standard 02.08. This is the standard release of this document. May 2005 1xEV-DO 2.2, Preliminary 02.07. Minor changes to the cover page.
CDMA
1xEV-DO DO-RNC Theory of Operations
1xEV-DO 3.0
iv Publication history Nortel Networks Confidential
April 2005 1xEV-DO 2.2, Preliminary 02.06. Made minor edits. 1xEV-DO 2.2, Preliminary 02.05. Changed CDMA2000 to CDMA. 1xEV-DO 2.2, Draft 02.04. Added the following new sections: Terminal Authentication and AN-AAA selection mechanism AT originates 1xEV-DO sessionunsuccessful terminal authentication Connection EstablishmentAN initiated, Fast Connect APPENDIXA12 messages
Updated the following sections: 1xEVDO Data flow February 2005 1xEV-DO 2.2, Draft 02.03. Changed hard disk size to 40 GB. 1xEV-DO 2.2, Draft 02.02. Added correction on hard disk size (32-40 GB). December 2004 1xEV-DO 2.2, Draft 02.01. Changed version and added minor editorial changes. October 2004 September 2004 August 2004 August 2004 1xEV-DO 2.1, Preliminary, 01.01. This is the first release of this document. 1xEV-DO 2.1, Preliminary, 01.02. Made minor changes to text and formatting. 1xEV-DO 2.1, Standard, 01.03. Added CDMA Theory of Operations. 1xEV-DO 2.1, Standard, 01.04. Reformatted per Nortel standards. Reverse link data flow SC Module RNSM module C-PCI bandwidth
411-2133-514
Preliminary
03.06
October 2005
v Copyright 2004-2005 Nortel Networks
Contents
About this document
Audience for this document ix Organization of this document ix Indication of hypertext links ix Related documents x
1
ix
Introduction
1xEV-DO network configuration 1-2 1xEV-DO protocol overview 1-3
1-1
DO-RNC hardware architecture

Hardware architecture overview 2-2 DO-RNC hardware modules 2-2 System controller module 2-3 Hot swap controller module 2-3 Base I/O module 2-3 Radio network server module 2-3 Power supply 2-4 Alarm panel 2-4 Hard disk 2-4 C-PCI bus 2-4 DO-RNC external interfaces 2-5
2-1
DO-RNC software architecture

Software architecture overview 3-2 Fast path and slow path 3-2 System services 3-3 Protocol stack 3-3 Physical interfaces 3-3 Ethernet interface 3-3 System controller daughter card Ethernet interface Serial port driver 3-4 System bus driver 3-4 Link layer 3-4 TCP/IP 3-5 IP routing table 3-5 Socket interface 3-6
3-1
3-4
CDMA
1xEV-DO 3.0
vi Contents Nortel Networks Confidential
System controller board 3-6 Resource control 3-6 PCF functionality 3-6 System management 3-9 SNTP timing functionality 3-9 DO-RNC reset mechanism 3-10 DOM homing on the DO-RNC 3-10 Radio network server module (RNSM) board 3-12 Call control 3-12 Resource control 3-16 BTS manager 3-16 BTS mapping table 3-17 PCF functionality 3-17 Selection and distribution unit 3-18 1xEV-DO layer processing 3-18 Abis signaling 3-19 Abis data processing 3-19 A13 interface protocol 3-20 Terminal authentication 3-21 AN-AAA selection mechanism 3-23 Operation without terminal authentication 3-24 Base I/O (BIO) board 3-26 IP forwarder 3-26 Abis data demux processing 3-27 A10 demux processing 3-27 Address translator 3-28
End-to-end call flow

1xEV-DO Signaling flow 4-1 Data call setup flow 4-2 Session setup flow with A10 connection minimization 4-4 AT originates 1xEV-DO sessionunsuccessful terminal authentication Connection setup/open flow 4-7 Connection establishmentAN initiated, fast connect 4-9 Connection close flow 4-11 Reverse soft/softer handoff call flow 4-13 Sector switching 4-15 Inter DO-RNC dormant handoff without A13 support 4-17 Successful regular A13 dormant handoff 4-19 Unsuccessful regular A13 dormant handoff 4-22 Successful prior A13 dormant handoff 4-23 Unsuccessful prior A13 dormant handoff 4-25 Inter RNC active handoff using multi-homing 4-27 Inter-technology handoff call flow 4-29 1xEV-DO Data flow 4-30 Forward link data flow 4-30 Reverse link data flow 4-32
4-1
4-6
411-2133-514
Preliminary
03.06
October 2005
Contents vii Copyright 2004-2005 Nortel Networks
DO-RNC redundancy
DO-RNC redundancy model 5-1 System controller module redundancy RNSM module redundancy 5-2 BIO module redundancy 5-2 Hard disk 5-2 5-1
5-1
DO-RNC capacity
System controller module 6-1 Radio node server module 6-2 Basic input/output module 6-2 Compact peripheral component interconnect bandwidth
6-1
6-2
DO-RNC OA&M
DO-EMS and NE interface 7-1 DO-EMS to DO-RNC traffic 7-2 DO-RNC to DO-EMS traffic 7-3 Data collection 7-3
7-1
Appendix: A12 Messages

Radius message format A-2 Code field A-2 Identifier field A-2 Length field A-2 Authenticator field A-3 Request Authenticator A-3 Response Authenticator A-3 Access-Request attributes A-3 Access-Accept attributes A-5 Access-Reject attributes A-5
A-1
Acronyms Figures
Figure 1-1 Figure 1-2 Figure 2-1 Figure 2-2 Figure 3-1 Figure 3-2 Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 Figure 4-5 Figure 4-6 Figure 4-7 Figure 4-8
B-1
1xEV-DO network configuration 1-2 Protocol view of 1xEV-DO user plane 1-3 Logical diagram of a fully loaded DO-RNC 2-2 DO-RNC external interfaces 2-5 DO-RNC software architecture 3-2 Terminal authentication model 3-23 1xEV-DO Data call setup flow diagram 4-2 1xEV-DO session setup flow with A10 connection minimization 4-4 Initial AT originationunsuccessful terminal authentication 4-6 1xEV-DO Connection setup flow diagram 4-7 1xEV-DO fast connect setup flow diagram 4-9 1xEV-DO connection close flow diagram 4-11 1xEV-DO reverse soft/softer handoff call flow diagram 4-13 1xEV-DO sector switching flow diagram 4-15
CDMA
1xEV-DO 3.0
viii Contents Nortel Networks Confidential Figure 4-9 Figure 4-10 Figure 4-11 Figure 4-12 Figure 4-13 Figure 4-14 Figure 4-15 Figure 4-16 Figure 4-17
Copyright 2004-2005 Nortel Networks 1xEV-DO inter DO-RNC dormant handoff without A13 flow diagram 4-17 Successful regular A13 dormant handoff call flow diagram 4-19 Unsuccessful regular A13 dormant handoff call flow diagram 4-22 Successful prior A13 dormant handoff call flow diagram 4-23 Unsuccessful prior A13 dormant handoff call flow diagram 4-25 Inter RNC active handoff call flow diagram 4-27 Inter-technology dormant handoff flow diagram 4-29 1xEV-DO data flow diagram 4-30 1xEV-DO Reverse link data flow diagram 4-32
Tables
Table 3-1 Conversion table to map the most significant 8-bits of the ESN 3-25
411-2133-514
Preliminary
03.06
October 2005
ix Copyright 2004-2005 Nortel Networks
About this document
This document briefly describes the architecture of different modules of the DO-RNC and how these modules interact with each other in order to establish a data call. Various call flow scenarios are also discussed. The document also describes the capacity of different modules in the DO-RNC and identifies the bottlenecks. DO-RNC redundancy for each module and the interaction between the DO-RNC and DO-EMS for the OAM tasks is also discussed.
Audience for this document
This guide is intended for individuals responsible for planning the deployment of a CDMA 1xEV-DO network. It can also be used in conjunction with the CDMA 1xEV-DO Deployment Planning, 411-2133-932, and other related configuration tools. The reader should have a base understanding of 1xEV-DO technology and data network practices.
Organization of this document

This guide is organized into chapters as follows: Introduction on page 1-1 DO-RNC hardware architecture on page 2-1 DO-RNC software architecture on page 3-1 End-to-end call flow on page 4-1 DO-RNC redundancy on page 5-1 DO-RNC capacity on page 6-1 DO-RNC OA&M on page 7-1
Indication of hypertext links

Hypertext links in this document are indicated in blue. If viewing a PDF version of this document, click on the blue text to jump to the associated section or page.
CDMA
1xEV-DO 3.0
x About this document Nortel Networks Confidential
Related documents
CDMA Release Delta for 1xEV-DO 2.2 to 3.0, 411-2133-109. This document describes new and changed managed objects Logs, operational measurements and alarms. CDMA 1xEV-DO System Overview, 411-2133-012. This document contains high-level descriptions of all nodes new to 1xEV-DO. CDMA 1xEV-DO DO-EMS Software Installation, 411-2133-126. This document contains DO-EMS licensing information and explains the software and hardware requirements. It also describes how to install the DO-EMS server software, including guidelines for installing the Oracle* and VERITAS software required to support the DO-EMS, in the event there is a need to reinstall the DO-EMS to recover from a catastrophic system failure. CDMA 1xEV-DO DO-EMS Administration, 411-2133-529. This document is written for system administrators responsible for maintaining the DO-EMS server. This guide describes how to administrate, configure, and maintain the DO-EMS server. CDMA-NBSS Shasta PDSN/FA and HA 2.2 Customer Information Guide, 411-2133-802. Shasta PDSN/FA & HA Procedures Reference Manual, 411-2133-803. CDMA 1xEV-DO Radio Access Network Engineering, 411-2133-814. This document contains the IP routing and addressing solutions for Nortel Networks 1xEV-DO radio access networks (RANs). CDMA 1xEV-DO DO-RNC Hardware, 411-2133-817. This document describes all LEDs associated with the DO-RNC and its components and describes how to replace and hot-swap all field replaceable units (FRUs). CDMA 1xEV-DO Configuration Parameters Reference, 411-2133-822. This document provides configuration parameter reference information for CDMA 1xEV-DO. CDMA 1xEV-DO Performance Measurements Reference, 411-2133-924. This document assists Network Engineering teams in determining CDMA 1xEV-DO network performance. Formulas needed to derive various performance metrics such as session setup, paging, and resource allocation performance are provided in this document. CDMA 1xEV-DO CLI Reference, 411-2133-925. This document describes the command line interface (CLI) and the functions of every CLI command. CDMA 1xEV-DO Logs Reference, 411-2133-926. This document describes all log messages and explains what each message means, suggests possible causes, and provides guidelines for responding to each error message.
03.06 October 2005
411-2133-514
Preliminary
About this document xi Copyright 2004-2005 Nortel Networks
CDMA 1xEV-DO Using the DO-EMS Interface, 411-2133-927. This document describes how to use the DO-EMS to manage the IP-RAN. Documents all DO-EMS functions, except those performed by the DOEMS server administrator. This NTP was previously titled CDMA 1xEVDO EMS User Interface. CDMA 1xEV-DO Operational Configuration Tools, 411-2133-929. This document describes how to generate scripts with the two tools used to create per-network element configuration scripts: the Merge Tool and the Script Generation Tool. It explains where these tools fit into the IP-RAN deployment process, how they interact with other planning tools and the planning process, what input files are required to use these tools, the format of the input files, and how the tools are used to generate configuration scripts for network elements. CDMA 1xEV-DO Deployment Planning, 411-2133-932. This document is a high-level engineering planning guide that covers RF planning and network-architecture planning to help operators plan to deploy a Nortel IP-RAN. This guide focuses on planning at the network-wide level, covering all CDMA 1xEV-DO IP-RAN components: DOM, DO-RNC, the 1xEV-DO Element Management Subsystem, backhaul capacity, etc.
Standard references
TIA/EIA/IS-2001-A, Interoperability Specification (IOS) for CDMA Access Network Interfaces, Nov, 2001 TIA/EIA/IS-856, CDMA High Rate Packet Data Air Interface Specification, February, 2001 TIA/EIA/IS-890-1, Test Application Specification (TAS) for High Rate Packet Data Air Interface, October 24, 2002 RFC 2865, Remote Authentication Dial In User Services (RADIUS), June 2000. 3GPP2 A.S0008-0 v3.0 (TIA-878-1), Interoperability Specification (IOS) for High Rage Packet Data (HRPD) Access Network Interface, May 2003.
CDMA
1xEV-DO 3.0
xii About this document Nortel Networks Confidential
411-2133-514
Preliminary
03.06
October 2005
1-1 Copyright 2004-2005 Nortel Networks
Introduction
This chapter contains the following information: 1xEV-DO network configuration on page 1-2 1xEV-DO protocol overview on page 1-3
CDMA
1xEV-DO 3.0
1-2 Introduction Nortel Networks Confidential
1xEV-DO network configuration
A high level overview of the 1xEV-DO architecture is presented in Figure 1-1. The architecture shows the 1xEV-DO channel element Module (DOM) is plugged into the Nortel Networks base station and is connected to the DO-RNC through the IP network. The other required nodesPDSN, DO-EMS and AAAfor 1xEV-DO system can also be connected through the IP network.
Figure 1-1 1xEV-DO network configuration
CDMA2000 1X User
CDMA2000 1xEV-DO Network

XC EM
MTX/D
MS-10
0W
CDMA2000 1xEV-DO User Me etro Ce Cell BTS S

S
BSC
M DO
1x 1 /E T1 l O -D au EV ackh B
ES
EL
Home Agent (HA)

when deploying eploying Mobile IP
CDMA2000 1X User
BSSM Manager
E XC
Carrier's Private Data Network
Packet Data Network P PDSN
1 1/E OT l u V-D 1xE ackha B
D DO-RNC CDMA2000 1xEV-DO User SCS (Shasta OAM) DO-EMS Client
D DO-EMS AN-AAA/ AAA (RADIUS)
M DO
Me etro Cell BTS
CDMA2000 1X Network CD DMA2000 1xEV-DO Network
411-2133-514
Preliminary
03.06
October 2005
Introduction 1-3 Copyright 2004-2005 Nortel Networks
1xEV-DO protocol overview
Figure 1-2 shows the Protocol stacks for the user plane between different nodes in the network. IP packets are exchanged between the TE (terminal equipment such as a laptop, etc.) and IP host at the other end of the core network; for example, internet server (not shown in Figure 1-2). The TE and PDSN are PPP peers and are considered as one IP hop. PPP is relayed over the following: A10 using the generic routing encapsulation (GRE) tunnel Airlink using RLP AT to TE using serial or USB
RLP is relayed over the following: Abis transport network using the GRE tunnel Airlink using the 1xEV-DO physical layer
Figure 1-2 Protocol view of 1xEV-DO user plane

IP host
PPP USB or serial
Terminal Equipment - PC hardware
IP routing relay
USB or serial RLP MAC 1xEV-DO Layer 1
Access Terminal
relay
RLP GRE IP 100 B-TX
PPP GRE IP Ethrenet 100 B-TX
Ethernet 100 B-TX
relay
1xEV-DO Layer 1 GRE IP PPP T1/E1
DOM
MAC... GRE IP PPP T1/E1 Ethernet 100 B-TX

IP Router ABIS transport network
IP Ethernet 100 B-TX
PDSN A10 transport network
DO-RNC
CDMA
1xEV-DO 3.0
1-4 Introduction Nortel Networks Confidential
411-2133-514
Preliminary
03.06
October 2005
DO-RNC hardware architecture

This chapter contains the following information: Hardware architecture overview on page 2-2 DO-RNC hardware modules on page 2-2
CDMA
1xEV-DO 3.0
2-2 DO-RNC hardware architecture Nortel Networks Confidential
Hardware architecture overview
The BIO, RNSM and SC modules are all based on the Motorola 750 Power PC. The BIO and RNSM modules are identical and only differentiated by software and the connection of the Ethernet port (BIO uses the rear transition module). Figure 2-1 shows a logical diagram of fully populated DO-RNC.
Figure 2-1 Logical diagram of a fully loaded DO-RNC
DO-RNC hardware modules

The DO-RNC consists of a 16-slot Motorola NEBS compliant chassis containing the following modules: System controller module on page 2-3 Hot swap controller module on page 2-3 Base I/O module on page 2-3 Radio network server module on page 2-3 Power supply on page 2-4 Alarm panel on page 2-4
411-2133-514
Preliminary
03.06
October 2005
DO-RNC hardware architecture 2-3 Copyright 2004-2005 Nortel Networks
Hard disk on page 2-4 C-PCI bus on page 2-4
System controller module The system controller (SC) on the DO-RNC contains a 366MHz MPC750 responsible for routing protocols, system configuration, network management, and centralized signaling activities. The SC runs the TCP/IP protocol stack over Ethernet to communicate on the management interfaces and over a backplane bus layer to communicate with the RNSM and BIO modules. There are two serial connectors for the local management (CLI interface) with the SC/RNC. On the front panel of the SC, there is a DB9 connector and on the rear transition module there is a RJ-45 interface. Only one of the front or rear connectors may be used at any given time, not both. Each DO-RNC supports 1+1 redundancy for system controllers (as defined in System controller module redundancy on page 5-1). Hence, two per chassis in the redundant configuration, occupies four slots with the required hot swap controller (see Figure 2-1). DO-RNC chassis has slots 7 and 9 reserved for two SC modules. Hot swap controller module The hot swap controller (HSC) module is only a rear transition module in the DO-RNC chassis. The module works in combination with the SC module. The HSC in slot 10 works with the SC in slot 7 and the HSC in slot 8 works with the SC in slot 9. HSC module helps the SC during switch over and also provides a bridge between two domains in the DO-RNC chassis as shown in Figure 2-1. Base I/O module The base I/O (BIO) module on the DO-RNC contains a 450MHz (or 500 MHz) MPC750 supporting two 100BaseT ports using a rear Transition Module. It runs the TCP/IP protocol stack over Ethernet for communication with the PDSN and the backhaul network (connected to the DOMs). The DO-RNC supports up to 4 BIO modules. Placement of the BIO modules is restricted to slots 1, 2, 11 and 12. When physically connecting the DO-RNC to the access network, it is recommended that it be configured in such a fashion that each BIO interface be provisioned to talk to both the RAN and PDSN. This approach leads to better distribution of processing load across BIOs in that the asymmetric forward and reverse link loads will balance when combined in opposite directions on the BIO. Radio network server module The radio network server module (RNSM) on the DO-RNC contains a 450MHz (or 500 MHz) MPC750 responsible for terminating the signaling
CDMA 1xEV-DO DO-RNC Theory of Operations 1xEV-DO 3.0
and data plane components of the 1xEV-DO protocol. The DO-RNC supports up to eight RNSM modules. Placement of the RNSM modules is restricted to slots 3, 4, 5, 6, 13, 14, 15, and 16. Note: Unlike the BIO module, the RNSM module does not require a rear transition module. Power supply The DO-RNC can be configured to support either AC or DC power using a different type of power distribution panel and power supply modules. The power supplies have auto-ranging capability, supporting a wide range of voltages. Nortel Networks supports only DC power supply. DC power mode In this mode, the DO-RNC supports dual input DC power for maximum redundancy. Voltage range of 36 Vdc to 72 Vdc is supported. The power supplies are fully hot swappable and supporting N+1 redundant capability. Alarm panel There is an alarm panel located on the front of the DO-RNC chassis. The alarm panel contains three system status LEDs, three Telco alarm status LEDs, two slot status LEDs for each slot, and an RJ-45 connector for Telco alarm status output to an external interface. Hard disk The hard disk on the DO-RNC is a standard IDE drive. Each SC module has an associated hard disk. These hard disks are synchronized with each other. Each hard drive on the DO-RNC must contain 40 GB space. C-PCI bus The DO-RNC is based upon a standard Motorola Compact-PCI chassis, and that's the basic topology of the hardware: there are 2 PCI domains, with a bridge joining them. Figure 2-1 shows a logical diagram of the DO-RNC chassis.
411-2133-514
Preliminary
03.06
October 2005
DO-RNC hardware architecture 2-5 Copyright 2004-2005 Nortel Networks
DO-RNC external interfaces Figure 2-2 shows the DO-RNC external interfaces. The DO-RNCs communicate with the radio nodes and the PDSNs through a network using multiple 100Mb Ethernet links. The same Ethernet link can be connected to both the packet core (PDSN) and the radio networks. The interface to the DOMs uses a proprietary IP Abis protocol while the interface to the PDSNs is via a standard R-P interface as defined in 1xEV-DO TIA-878 standard. When co-located, the DO-RNC can be connected to the PDSN directly using the Ethernet interface. Alternatively, when the PDSN is remote, an external router can be used.
Figure 2-2 DO-RNC external interfaces
Radio Network Interface
100 Base T N
100 Base T
RNC
Core Network Interface
RS-232
Craft Interface
Management Interface (on daughter card)
100 Base T
DC Power
CDMA
1xEV-DO 3.0
411-2133-514
Preliminary
03.06
October 2005
DO-RNC software architecture

This chapter contains the following information: Software architecture overview on page 3-2 Physical interfaces on page 3-3 Link layer on page 3-4 TCP/IP on page 3-5 Socket interface on page 3-6 System controller board on page 3-6 Radio network server module (RNSM) board on page 3-12 Terminal authentication on page 3-21 Base I/O (BIO) board on page 3-26
CDMA
1xEV-DO 3.0
3-2 DO-RNC software architecture Nortel Networks Confidential
Software architecture overview
The data only radio network controller (DO-RNC) software architecture is distributed among several board types: the System Controller (SC), the radio network server module (RNSM) boards and the base I/O (BIO) boards. The function of each module and the software components and services implemented by each module are described. Figure 3-1 shows the high-level architecture for various modules in the DO-RNC.
Figure 3-1 DO-RNC software architecture
Active SC
Resource Control PCF A11
Standby SC
System Services
Protocol Stack
C-PCI
BIO
Net i/f Driver
Bus Driver
IP Forwarder A Interface Demux Fast Path Slow Path

Physical Layer Device Driver Protocol Stack
S Y S T E M
SM
Bus Driver Abis Data SDU 1xEV-DO Layer Processing PCF (GRE)
Table Distribution
R S T E O R S V I C E S
S Y S T E M S E R V I C E S
Fast Path Slow Path

1xEV-DO Layer Processing SLP
RLP Protocol Stack Abis Signaling Call Control Resource Control Mapping Table Distributor
R T O S
Fast path and slow path BIO and RNSM modules have fast path and slow path components. The fast path component is a separate task with the task priority being higher than all other application tasks but lower than that of some system tasks like watchdog timer, etc. The fast path task can tie up the CPU for up to 80% of the execution time, provided there are packets/events to be processed.
411-2133-514
Preliminary
03.06
October 2005
DO-RNC software architecture 3-3 Copyright 2004-2005 Nortel Networks
Fast path can be conceptually viewed as a layer between the driver module and the upper layer functions. The fast path receives packets from device drivers and, if they are to be forwarded rather than locally terminated, performs protocol processing and forwards the packet out to another device. If the packet is destined for a local application, fast path queues it to the appropriate slow path task and moves on to the next packet. In this manner, packets destined for the slow path will only be processed at the priority level of the slow path tasks as they have opportunity to run and process their input queue. The slow path is a set of tasks that run at a lower priority than the fast path, comparable to other management tasks in the system. The tasks in the slow path process packets that are to be locally terminated rather than forwarded to another card/system. Each of these tasks may have its own priority as long as all such tasks are at a lower priority than the fast path task. System services The real-time operating system (RTOS) utilized on all the boards is VxWorks. It provides basic OS services such as task scheduling and synchronization. A set of platform independent services are implemented, some built on top of the services provided by VxWorks. Examples of system services are inter-process communication, event notification, timer services and memory management. Protocol stack The protocol stack consists of the following: Physical interfaces on page 3-3 Link layer on page 3-4 TCP/IP on page 3-5 Socket interface on page 3-6
Physical interfaces
The physical layer consists of the following: Ethernet interface on page 3-3 System controller daughter card Ethernet interface on page 3-4 Serial port driver on page 3-4 System bus driver on page 3-4
Ethernet interface The system controller (SC) has a 10/100Mbps Ethernet port used for redundancy support. A cross-over cable between the active SC and the standby SC carries heartbeat signals between the two cards. If the heartbeat is
lost, the standby SC will shoot the active SC and reboot the DO-RNC. It essentially means that it will force the card for a hardware reset (with the presumption that card is in some kind of hung state); see System controller module redundancy on page 5-1 for more details. System controller daughter card Ethernet interface The SC also supports the use of a PMC daughter card which provides an additional 10/100 Mbps Ethernet port. Starting in Release 2.2, this port can be used to manage the system. Management packets arriving on the Ethernet are passed by the driver to the link layer and ultimately to the IP protocols and applications. The Ethernet port is configured with an IP address, either through the CLI or the DO-EMS. Serial port driver The SC supports one RS232 serial port for managing and debugging the system. By default, the port is automatically bound to the CLI such that all characters received on the port are forwarded to the CLI for processing. System bus driver The system-bus driver represents the physical connection to other boards in the system. All interprocessor communications across the PCI bus for messaging between various processors use IP as the networking layer protocol using the unique per processor IP address.
Link layer
3
The link layer provides an interface between the network protocols and the device drivers. Interface objects are created to provide a representation of physical and virtual interfaces. These interfaces have the ability to be stacked on top of each other to represent a particular protocol stack. An interface object is used to transmit internally generated packets as well as receive packets returned by Fast Path processing. Applications that generate packets internally will use the appropriate interface object to transmit the packet. These applications will hold a reference to the interface object. For example, when an interface is configured with an IP address, the router will send out a router announcement. The router will create and transmit the packet out through the newly configured interface by calling the object's transmit method. Any needed encapsulation will be added as the packet gets delivered to the physical device. When a packet is returned from the fast path to the slow path for local delivery processing (i.e. signaling, ICMP, SNMP, HTTP, TELNET, FTP, etc.), the packet is posted to the Slow Path packet engine. The packet engine will call the physical interface object to return the packet. The packet will propagate up the interface stack, removing any encapsulation on the way to
411-2133-514
Preliminary
03.06
October 2005
the interface owner. The owner, for instance, could be the IP stack for local management. The link layer also provides for link state propagation. Callback support will exist to provide applications with link or operational status callbacks.
TCP/IP
3
The DO-RNC runs a standard TCP/IP protocol stack, sourced from Wind River and fully integrated with VxWorks. The stack will run in the background on all boards in the system, allowing for maximum distribution of IP application processing. On the SC, the TCP/IP stack receives management packets from either the serial port or forwarded over the system bus from one of the BIOs. It receives A11 signaling packets only via the system bus from one of the BIOs. In order for all the stacks in the system to operate correctly, an internal addressing scheme must be utilized. Each stack in the system is statically assigned an IP address. The address utilizes the standard IP loopback address 127, as well as the chassis, slot and processor number. The format of the IP address is: 127.chassis#.slot#.processor#. For example, if the SC is in slot number 7, the IP address of its stack would be 127.1.7.1. By convention, addresses in the 127 network are never advertised and packets sent to this address are never transmitted externally. This addressing scheme supports interprocess communication within and across boards. Each external interface in the DO-RNC is assigned an IP address. The address is used as the source IP address of packets sent out through that interface. Internally, packets sourced by a TCP/IP application will contain the IP source address of its board. The packet is forwarded to the BIO for transmission, where the source address must be changed to the address of the interface on which it is being transmitted. The task of performing the translation is done by the address translator (please see Address translator on page 3-28). In addition, the address translator must modify the destination IP address of received packets to that of the destination board.
IP routing table The IP routing table is populated with IP addresses for the forwarding of IP datagrams. The table is populated by using one of the following methods: configuration of static routes routes learned through routing protocols
The first case is performed through a management interface. In the latter case, the routing protocol supported in the first release is RIP-2. If a default route
exists in the routing table (through configuration or learned through RIP), it is used to route IP packets for which no specific route is found in the routing table. The routing table built and maintained on the SC is the master routing table for the DO-RNC. The routing table information is distributed to all the other boards on the system.
Socket interface
The socket interface implements the standard Berkeley socket interface. It provides a generic, industry standard interface for applications to use when accessing networking protocols. Initially, sockets can be created for using TCP, UDP, IP or the distribution protocol. The distribution framework provides mechanisms to handle dynamic loading, creation and removal of components, and remote procedure calling. The socket interface can easily be extended to support any network protocols implemented in the future.
System controller board

The system controller (SC) is responsible for the following system-level functionalities: Resource control on page 3-6 PCF functionality on page 3-6 System management on page 3-9 SNTP timing functionality on page 3-9
Resource control In the DO-RNC, there are two levels of resource control: SC-level and RNSM-level. Currently, the 1xEV-DO session number (UATI) number space and the PCF session ID (PSI) are managed at the SC-level. PCF functionality The PCF functionality spans across the SC and RNSM cards. The SC cards PCF functionality consists of: PCF signaling on page 3-7 PDSN selection on page 3-8 AT mapping table on page 3-8 Accounting on page 3-8
PCF Signaling is responsible for setting up, updating and releasing the A10 connections with the PDSN based on the events it receives from call control. PDSN Selection implements the IOS standard PDSN selection algorithm. The AT mapping table is a mapping between the AT UATI, its airlink connection status, the PCF session ID (PSI) and the outgoing interface number to reach a specific PDSN. It is updated by PCF signaling and used by PCF data residing in the RNSM card. The accounting functionality is responsible for sending
411-2133-514 Preliminary 03.06 October 2005
the airlink information to the PDSN as per TIA-878. RNC release 3.0 provides the ability to send the airlink information through R-P interface in different formats compatible with TIA-878-Ballot and TIA-878-1. To configure the R-P interface for different TIA-878 formats on the DO-RNC, refer to the CDMA 1xEV-DO Deployment Planning, 411-2133-932. PCF signaling The PCF signaling interfaces with call control and PCF data in the RNSM card. The DO-RNC could have more than one RNSM card. This implies that there may be more than one instance of PCF data. PCF signaling receives events from the call control and sets up and releases A10 connections with the PDSN. Based on the Call Control events, the PCF signaling populates and updates the AT mapping Table. When the PDSN releases the A10 connection, it interacts with Call Control to release the airlink connection (if one is present) and updates the AT mapping table. The PCF signaling is also responsible for assigning the PSI which is unique within the PCF entity. This implies that when there are many PCF data instances in the system, it is the responsibility of PCF signaling to maintain the uniqueness of the PSI across the many PCF data instances. PCF signaling uses UDP/IP for exchanging signaling messages with the PDSN. For this purpose, it utilizes the socket layer interface. In release 2.x, whenever a DO session was setup, the RNC automatically established an A10 Connection. This caused the PDSN to always attempt to setup a PPP session with the AT whenever the AT established a new DO session. When the AT did not have a packet data session present, this became an unnecessary event only resulting in the PDSN repeatedly sending PPP LCP Config Request packets to the AT. These packets would force the RNC to page the AT to setup a DO connection to transmit the PPP LCP packets. Eventually the PPP setup attempt times out since the AT does not have a packet data session causing the PDSN to close the PPP session and also tear down the A10 Connection on the RNC. In release 3.0, there is a feature of A10 Connection Setup Minimization. When this feature is enabled, A10 connection will be setup when it is known the AT has or is initiating a packet data session and consequently needs an A10 Connection to be setup. The A10 Connection Setup Minimization aims to do the following: If the A10Conn Min feature is enabled an A10 Connection will be setup only if the AT has a packet data session present. By setting up an A10 only when a packet data session is present in the AT, A10 connection minimization significantly reduces the number of unnecessary A10 connections setup by the RNC. This also leads to fewer A10s closed by the PDSN.
CDMA
1xEV-DO 3.0
The A10Conn Min feature supports two modes of operation: ULN and QC-MIP mode. In ULN mode, the RANHandoff value is 0x1. In QC-MIP mode, the RanHandoff value is 0x0.
The user can enable or disable the A10 Connection Setup Minimization feature. The user can choose the mode of operation.
PDSN selection The DO-RNC is capable of supporting up to 64 PDSNs and selects them according to the PDSN selection algorithm as defined in TIA/EIA/IS-2001-A, Interoperability Specification (IOS) for CDMA Access Network Interfaces. The maximum number of PDSNs is a configurable parameter at the PCF. Once this parameter is configured, the user is allowed to build the PDSN selection table through the use of the CLI or the DO-EMS. Each entry in the PDSN selection table contains a PDSN number and the PDSN IP address. When setting up an A10 connection, the PCF uses the following formula to select a PDSN:
PDSN number = (least significant 4 digits of IMSI treated as decimal value) modulo (Maximum number of PDSNs)
If the selected PDSN does not respond (even after the configured number of retransmissions), the PCF selects the next available PDSN from the PDSN Selection Table. This process continues until a PDSN accepts the A10 connection or the PCF has tried with all PDSNs in the PDSN selection table. AT mapping table The AT mapping table is a lookup table that maps an ATs UATI, airlink connection status, the PSI and the BIO interface number to reach the PDSN. A copy of the AT mapping table is also maintained in each RNSM card. The AT mapping table utilizes the system services providing functionality to distribute the contents of the AT mapping table to the BIO and RNSM cards. It is updated by PCF signaling (residing on the SC) and used by PCF Data on the RNSM and the A10 demux function on the BIOs. Note that PCF data and A10 demux have read-only access to the AT mapping table. Accounting At IOS defined trigger points, accounting records will be formed and sent to the PDSN through R-P interface. Triggering events include the opening of A10 sessions, and (based on messages received from call control) the opening and closing of 1xEV-DO connections.
411-2133-514
Preliminary
03.06
October 2005
System management The DO-RNC can be fully managed and configured using either the command line interface or the DO-EMS, which communicates with an XML agent implemented in the SC. In addition, there is support for accessing observables (operational measurements) by SNMP (please see DO-RNC OA&M on page 7-1 for details). Each method accesses the same set of configuration data through a common configuration framework. Command line interface The command line interface (CLI) is accessed either directly from the serial port or through the Telnet application. It provides a means for administrative control and management of the DO-RNC. For example, CLI can be used to provision and configure the network elements in the absence of backhaul (and therefore DO-EMS connectivity). XML agent XML is a standard language used to communicate text based commands. The DO-EMS uses XML to send commands for configuration and query for status. These XML commands are sent using the HTTP protocol. There is an XML agent on the SC which interprets these commands and interacts with the configuration framework described below. SNMP agent SNMP is a UDP based standard protocol used to manage and monitor the DO-RNC. Version SNMPv2c is supported. SNMP and XML allow the DO-EMS to manage the nodes. Configuration framework The configuration framework provides a unified view of configuration data. It consists of the following functionality: provides generic interface to SNMP, XML and CLI represents any manageable piece of data in a generic format maps requests by SNMP, XML and CLI to individual component action routines
SNTP timing functionality In order to have accurate time synchronization across the network SNTP derives its timing from a SNTP timing source. This timing source can be an external stratum clock or a DOM within the network. It is recommended that the DO-RNC SNTP timing be derived from the DOM's GPS timing source. The reason for this recommendation is timing accuracy. Timing accuracy The DO-RNC counts on a +/- 50ms propagation delay when receiving timing from an external source when the source is a GPS Timing Source (Stratum 0).
When the timing is derived from an external non-GPS source (Stratum 3), the source will introduce additional drift to the DO-RNC timing. Therefore, in order to achieve the most accurate timing source to the DO-RNC, it is recommended that the DO-RNC point to a GPS timing source. Timing source redundancy Although the DO-RNC can be configured with primary and secondary timing sources, it is recommended that both of these parameters are left unconfigured. In this case, the DO-RNC will AUTOMATICALLY select a timing source from one of the DOMs that is homed to the DO-RNC. If this DOM fails for any reason, the DO-RNC will automatically select another DOM to receive timing. This results in having a redundant timing source equivalent to the number of DOMs which are homed to the DO-RNC DO-RNC reset mechanism The DO-RNC supports independent reset of each slot in the system from the active SC. When the active SC is reset, all slots in the chassis are also reset. The software strategy is that the module monitor function performs a heartbeat of each hardware module in the system. If a module fails the heartbeat poll, it is reset. If a board is reset repeatedly 10 times, it will refuse to reset any further. When software on a particular board detects a hard failure condition, it resets that board in an attempt to recover, subject to the limitation on the maximum number of resets in close succession. DOM homing on the DO-RNC When a DOM is administered up, it tries to home to its configured parent DO-RNC. The DOM's topology manager communicates with the SC's topology manager. Configuration information is exchanged, and the SC's topology manager assigns the DOM to a RNSM. Subsequently, a link (Abis signaling) is established between the DOM and the RNSM for the purposes of exchanging signaling information between the RNSM and the DOM (more on this later). Note: Topology manager is a software component which resides on the DOM, SC and RNSM modules. Some of topology manager functions include configuring the node while powering up, updating other modules for any configuration changes, homing the DOMs to the DO-RNC, and informing peers about the capabilities of its modules. The SC topology manager distributes all the DOMs to available RNSM cards in the DO-RNC according to the following algorithm: it will assign DOMs to the first available RNSM up to a configured committed value before assigning DOMs to the next available RNSM. Once all RNSMs are at their committed level, any additional DOMs will get assigned on a rotating basis up to a configured maximum.
411-2133-514
Preliminary
03.06
October 2005
Once a DOM is homed (or Abis is established) then all DO sessions requested by that DOM/sector are established on the RNSM card. The PCF entities for all these DO sessions exist on the same RNSM card. In release 3.0, Nortels solution for the Inter-RNC Active Handoff requires that an RN be able to home to zero or more (up to a maximum of 8) Secondary RNCs in addition to the Parent (Primary) RNC, this is called Multi-Homing. The Node IP addresses of zero or more Secondary RNCs shall be configured on the RN. The RN will open Topology Manager connections (TCP connections to port 9444) and Abis connections (TCP connections to port 5604) to the Secondary RNCs. Unlike the Primary RNCs, no priority is associated with the Secondary RNCs. If the RN loses homing to the Parent RNC, it shall close Topology Manager and Abis Signaling connections to all Secondary RNCs as well (because the configuration information it had received from the Parent RNC is no longer valid). If however, it loses homing to one of the Secondary RNCs, it shall close all forward and reverse traffic channels that originated from that RNC. When an RNC closes the Topology Manager/Abis Signaling channel to a Secondary RN, it shall cleanup resources that were in use with the RN. If the RN is already homed to a Parent RNC, it shall periodically try to home to any Secondary RNCs that it is not homed to. If a Secondary RNC is configured after the RN has already homed to the Primary RNC, it shall immediately try to home to the Secondary RNC. The RNC shall be able to accept incoming homing requests for Primary RNs (on TCP port 7007) and for Secondary RNs (on TCP port 9444). It shall send color code, Subnet mask and length to the Primary RNs. It shall not send this information to the Secondary RNs. It shall continue to allocate Sector-IDs (24 least significant bits) for the sector-carriers of Primary RNs. It shall not allocate Sector-IDs for the sector-carriers of Secondary RNs. TM (on both RN and RNC) will provide an additional observable parameter to indicate the type of homing for each of its connections. Abis component (on both RN and RNC) will also provide an observable parameter to indicate the type of homing for each of its connections. With the introduction of Multi-Homing, each RN will potentially be homed to more than one RNC and different ATs may have connection through an RN to different RNCs. Therefore information about the total number of active connections in each of the sectors will only be available on the RN. For this reason, admission control will be deprecated and done only by the Call Control Agent component on the RN. Note: Not that as soon as the RNC and the RN software are upgraded, this will be the default behavior, i.e. call admission control will be performed on the RN after the software on the RNC and the RN has been upgraded. It cannot be explicitly enabled or disabled. The RNC will
CDMA
1xEV-DO 3.0
continue to perform admission control for RNs running an older version of the software. A RNC will have sessions for ATs that were opened by the ATs through one of its Primary RNs, or were transferred to the RNC as a result of A13 dormant handoff. If an AT is active, it does not need to be paged. If an AT is dormant and crosses the RNCs subnet boundary, its session will be transferred to the new RNC. Therefore, the Call Control component will send Page messages only to Primary RNs and never to Secondary RNs. The Topology Manager component on the RNC-SC homes an RN to an RNSM card in the RNC. As each RN will potentially be homed to more than one RNC, the information about the total number of active connections in each of the sectors will only be available on the RN. The RN will periodically send this information (number of active connections in the sector) to the RNCs. This information will be sent to all RNCs (Primary and Secondary). The HDRFastpath component on the RNC continually uses this information to dynamically size its pre-RLP buffers and MAC and RLP history buffers.
Radio network server module (RNSM) board
The software components contained on the RNSM board are discussed below. Call control on page 3-12 Resource control on page 3-16 BTS manager on page 3-16 BTS mapping table on page 3-17 PCF functionality on page 3-17 Selection and distribution unit on page 3-18 1xEV-DO layer processing on page 3-18 Abis signaling on page 3-19 Abis data processing on page 3-19
Call control The call control subsystem is used for the following tasks: set-up and release mobile 1xEV-DO sessions (see Session management on page 3-13) set-up and release mobile 1xEV-DO connections (see Connection management on page 3-13) provide 1xEV-DO airlink and packet zone mobility management (see Airlink mobility management on page 3-14)
411-2133-514
Preliminary
03.06
October 2005
A session is long-lived and, for example, is set-up when a mobile first powers on. It is not released until the mobile either releases it or it times out. A connection is relatively short-lived, and is only active long enough to support the transmission of a data burst (in either the up or down direction). A mobile with an open connection is said to be active; otherwise it is dormant. Airlink mobility management refers to the process of adjusting an active mobile's links to the air network to adapt to its changing position. Such adjustments take the form of using different sectors within currently utilized DOMs, and/ or using different DOMs. Packet zone mobility management refers to exchanging information with the AT to facilitate inter-system handoffs, for example, 1xRTT to or from 1xEV-DO. The call processing subsystem handles 1xEV-DO sessions, connections & handoffs, in conjunction with resource control, the PCF and the DOM. A connection is defined as one or more airlink channels, Abis channels, an SDU instance. Session management The call processing subsystem interacts with the 1xEV-DO slow path, resource control (on the SC), and PCF in order to manage 1xEV-DO sessions. A session is homed on an RNSM card, though not necessarily that on which the DOM is homed. A session does not move between RNSM cards within an DO-RNC during handoff. Rather, the BIO receives a table entry in its forwarding table mapping the user's UATI to a specific RNSM card. When an RNSM card is removed from the system or fails, it results in the loss of all sessions & connections homed on that card. Connection management The call processing subsystem interacts with the 1xEV-DO slow path, 1xEV-DO fast path, SDU, resource control and PCF in order to manage 1xEVDO connections. The AT is transitioned from dormant to active state under the following conditions: when the AT decides to make a connection due to user activity when a page from the PDSN triggers the AT to request a connection
The AT is transitioned from active to dormant state once it exceeds a configured Connection Inactivity time-out. The valid range for this parameter is 0 to 70 seconds, where 0 corresponds to no time-out. This configured value affects all connections on that DO-RNC. Each connection, however, maintains its own current inactivity time, defined as the time elapsed since last forward or reverse traffic was sent for that connection. When this value exceeds the configured inactivity time threshold, the connection transitions from active to dormant. For loading considerations, the complete list of active connections is only swept every five seconds for expired connections. Thus, it
CDMA
1xEV-DO 3.0
may take up to five seconds longer than the configured Connection Inactivity time-out for an idle connection to be timed out. Airlink mobility management In addition to configuring the active set during connection setup, call control will make adjustments to the active set, adding and removing pilots, as required, based on route update information received from the AT while it is in a connected state. When determining or adjusting the active set, call control will interact with resource control to allocate (or release) the appropriate airlink resources, and communicate with the DOMs through Abis signaling to open (or close) the associated traffic channels on the DOMs. Packet zone mobility management The AT maintains information on which packet zone (for example, which serving PDSN) it is utilizing. When it is switching DO-RNCs (for example, handing off between 1xRTT and 1xEV-DO) this information can be utilized to preserve continuity in the PDSN session wherever possible, thus minimizing handoff times. Call Control facilitates this process by exchanging (and updating) the packet zone information with the AT, and passing this information on to PCF Signaling. Session configuration options Session configuration is part of the call control subsystem. Session configuration manager (SCM) within the session configuration subsystem interacts with the CLI component to accept user configurations for session configuration options. Session configuration subsystem also interfaces with the A13 dormant handoff component, the Session component, and the SNP/ HDRSlowPath component. The messages exchanged between the RNC and the AT are carried over the Signaling Network Protocol (SNP) and is serviced by the HDRSlowPath component. All components that either manage a particular 1xEV-DO protocol or are otherwise dependent on the protocols configuration attributes also use session configuration subsystem. These components may query the SCM for operator-preferred values of the protocols configuration attributes, or to query the in-use values of the protocols configuration attributes. In A13 component after the session information is transferred, the new RNCs SCM needs to determine if the sessions protocols and parameters are acceptable. If the protocols and/or parameters are not acceptable, SCM will renegotiate the unacceptable protocols and/or parameters. DO Repage A page results when data arrives for a dormant AT (i.e., without an open connection). A few applications on the RNSM card (PCF, TA and TAP) issue
a Page Request to the connection state machine (CSM). The CSM responds that the Page Request either succeeded or failed. Page Success Indication is provided by the CSM if a Connection was successfully opened in response or was already open; all other cases result in a Page Fail Indication. The DO RePage feature is implemented with the goal to achieve higher page success rate in 1xEV-DO implementation, comparable to page success rate as seen in 1xRTT networks. This feature enables the RNC to transmit a Page Message to the Access Terminal (AT) more than once (number of times as configured by the operator, up to a maximum of three times) before declaring a Page failure. In the following description, we use the term Paging Cycle to imply the set of actions that follow when the AN sends a Page Message to the AT. This feature proposes to send the Page Message to the AT multiple times during a single Paging Cycle. In a paging cycle the configured timeout periods used by these successive page retries can be fixed or, varying in nature (by default the all the Page timeout values are set to the 4 seconds). The Paging Cycle is initiated when the first Page Message is sent to the AT. The Paging Cycle terminates when any of the following events occur: Connect Request(with AT initiated or AN initiated code point set) message is received from the AT. Page timer expires after the Page Message has been sent configurable number of times to the AT. Any error scenarios that cause the AN to decide that it should not wait for either a response from the AT or for the Page timer to expire (in other words, abort the Paging Cycle).
The timeout value for the Page timer is configurable and can have any value in the range of 1 to 18 seconds. If the configured timeout value for a page or, a RePage is T seconds, the actual time duration that the page timer will wait before declaring a timeout is (T + Tcch) seconds. The value Tcch will be implicitly added to the configured timeout value. The timeout values for the first Page Message and each of the successive RePages (aka Page retries) will be configurable and hence can be varying in nature (the default timeout values for the first Page Message and successive RePages are set to the same value as there is no proof that configuring different timeout values improves the performance of Paging mechanism. Note: Though the recommendation is to have same timeout values for the first page message and the successive RePages, these timeout values have been made configurable to give the operator the flexibility to tweak these timeout values depending on the performance of the radio network. We do not enforce any kind of relationship between timeout values for the successive page messages.
Resource control In the DO-RNC, there are two levels of resource control: SC-level, and RNSM level. The resource control subsystem at each RNSM has ownership of the air-link resources of the DOMs assigned to (homed on) that RNSM. It will also act as proxy for any resource requests that need to be sent to other RNSM cards. That is, if the 1xEV-DO session resides on one RNSM card (termed the session homing card) needs air-link resources managed by another RNSM card (termed the resource homing card) due to user mobility, call control sends all air-link related requests to resource control on the session homing RNSM, which will, in turn, forward the relevant subsets of the request over to resource control on the relevant resource homing RNSM. BTS manager The BTS manager (BTSM) is a subcomponent of the RNSM resource control (SMRC) and runs on each RNSM card on the DO-RNC. The BTSM on the RNSM communicates with the RN controller running on the BIO/SC card on the DOM. There is 1-to-n relationship between the BTSM and RN Controller whereby a BTSM instance talks to n different RN Controllers on n different DOMs homed on the RNSM card (Primary and Secondary home). Each BTSM instance is responsible for the set of DOMs that is homed on the same RNSM card as itself. The role of the BTSM begins when a new DOM is homed to an RNSM card, on addition or removal of sector-carriers to a homed DOM, and on the end of the homing of a DOM on an RNSM card. On an ongoing basis, the BTSM handles the notifications of changes in operational and administrative status of sector-carriers, from the RN controller. In addition, if the RN homes to a new Secondary RNC, TM (on RN) will trigger BTS Controller to send the SectorCarrierStatusUpdate message for sector-carriers on the RN (the ones that have been configured by the Parent RNC) to the new RNC. For the process of homing a DOM on a RNSM card, adding/removing sector-carriers on a homed DOM, and terminating homing of a DOM, the BTSM interfaces with topology manager on the DO-RNC SC card and topology manager on the DO-RNC RNSM card. The BTSM is also involved in the process of setting up CCH/ACH Abis data channels. It uses the services of connection block manager on the RNSM card to create/delete the Abis data channel connection blocks. From a high-level view, the BTSM has the following major functions: allocation of CCH/ACH DO-RNC connection-IDs for sector-carriers and creation of CCH/ACH Abis data channels
411-2133-514
Preliminary
03.06
October 2005
deallocation of CCH/ACH DO-RNC connection-IDs for sector-carriers and deletion of CCH/ACH Abis data channels interfacing between RN controller on DOM and RNSM resource control on DO-RNC to enable handling of changes in operational and administrative status of DOM sector-carriers by the DO-RNC
For the process of opening of control and access channels, the RN controller on the DOM is the peer of the BTSM. The communication between the BTSM and RN Controller goes over the common Abis signaling channel between the DO-RNC and the DOM. This Abis signaling channel is setup by the topology manager as a part of the homing process. Message routers on the DOM and DO-RNC abstract the Abis signaling channel and supports exchange of messages between BTSM and RN controller. BTS mapping table The BTS mapping table (BMT) indicates where (on which RNSM) a DOM's air link resources are homed. It is used by both resource control and call control. PCF functionality The PCF functionality spans across the SC card and the RNSM card. The RNSM card's PCF functionality consists of PCF data. The PCF data is responsible for relaying the PPP frames between the RLP and the PDSN of the RNSM card. The PCF data is also responsible for storing the PPP frames, while the AT is being paged, in a page data buffer. PCF data The PCF data interfaces with the RLP, local call control and the PDSN. When PPP octets are received from the RLP, PCF data encapsulates them in GRE and transmits the packets to the PDSN. The key field in the GRE header contains the PSI, which uniquely identifies the AT. When packets are received from the PDSN, PCF data removes the GRE header and uses the PSI to lookup the AT mapping table. If the table lookup indicates that the AT associated with the PSI has an airlink connection, PCF data passes the PPP data to the RLP. If the table look up indicates that the AT has no airlink connection, the PCF Data buffers the PPP frame in the page data buffer and informs call control (located in the same RNSM card) about the need to page the AT. Note: The buffering is really conceptual: the data is not copied anywhere but merely added to the appropriate link list rather than being passed to the next stage of processing (or released to the free list). Eventually, when the airlink connection is established, the PCF signaling updates the AT mapping table and informs PCF data. The PCF data removes the PPP frame from the queue and forwards it to the RLP.
CDMA
1xEV-DO 3.0
Selection and distribution unit The selection and distribution unit (SDU) is responsible for selecting a single good incoming air interface reverse link frame from all the traffic channels involved in a soft handoff. Unlike the voice world, in the data world, there is no concept of quality; a frame is either good or bad. In the forward direction, in the case of a softer handoff (sector switching), it switches forward link air interface frames to the best channel, based on commands received from the DOMs (which, in turn, are based on its processing of the DRC channel) as follows: 1. DO-RNC receives a stopped indication from the DOM currently owning the serving sector. Transmission of frames to the DOM is halted. This stopped indication contains information on the last frames that were successfully transmitted to the AT. 2. The last frames transmitted information is used to back up the fast path's transmission buffer. 3. DO-RNC receives a desired indication from the DOM at which the AT is now pointing its DRC (for example, the new serving sector). Transmission commences to the new DOM. Call control is responsible for setting up the underlying channel binding information needed by the SDU, such as which air link traffic channels go with which air network (Abis data) connections. The SDU function resides on RNSM cards and is instantiated once for each session at connection establishment time. 1xEV-DO layer processing 1xEV-DO layer processing is implemented in both the fast path, to handle 1xEV-DO signaling and data riding on the per-user Abis data connections, and the slow path, to handle 1xEV-DO signaling riding on the common Abis data connections used for access channel and control channel packets. 1xEV-DO layer processing is responsible for performing the user data processing associated with the various layers of the 1xEV-DO air interface protocol: stream layer, connection layer, security layer and MAC layer. The prime function of the stream layer is to provide support for multiplexing multiple application streams over the air interface. Stream 0 is always used for (in band) signaling, and relays frames to/from the SLP layer. The other streams can be assigned to other (user) applications with different QoS (Quality of Service) requirements. IS-856 (found in the TIA/EIA/IS-856, CDMA high rate packet data air interface specification) defines application sub-type 1 as the default packet application (RLP) bound to the radio access network (for terminal authentication via the A12 interface) and application sub-type 2 as the default packet application (RLP) bound to the service application network (for user data to the PDSN). The test application
specification (3GPP2 C.S0029) [TIA/EIA/IS-890-1, Test Application Specification (TAS) for High Rate Packet Data Air Interface] defines application subtype 3 for the test application protocols (TAP). The binding of streams to applications occurs as part of the session configuration negotiation process. Typically, streams 1, 2 and 3 are bound to applications sub-types 1, 2 and 3, respectively. The connection layer prioritizes and encapsulates transmitted data received from the stream layer and forwards it to the security layer; in the reverse direction, it decapsulates data received from the security layer and forwards it to the stream layer. The security layer is used only to provide authentication for the access channel (the uplink control channel used by mobile stations when they don't have an open connection.) Currently, neither authentication nor encryption is performed on any of the other channels. In the forward (downlink) direction, the MAC layer is used to encapsulate user and control packets in preparation for transmission over the physical layer. In the reverse (uplink) direction, the MAC layer header information is used to convey side information about the upper layer processing, as demuxing capability for the access channel. Abis signaling Abis Signaling is primarily used to support the setup and release of Abis traffic channels, which are employed to convey user data between the DOM and the DO-RNC. Abis signaling runs over TCP Abis data processing Abis data processing performs all the protocol processing (header encapsulation/decapsulation, muxing/demuxing for multiple independent data streams, sequencing to guarantee in-order delivery of packets, etc.) associated with the proprietary variant of the Abis protocol. Abis data processing is used to convey 1xEV-DO air interface data between the DOM and the DO-RNC. A dedicated Abis connection (and connection ID) is provided per user air link data stream (forward traffic channel/reverse traffic channel pair). In addition common Abis connections (and connection IDs) are provided per sector, for the purposes of transporting access channel and control channel frames. A13 interface protocol The A13 interface protocol is used for inter-RNC communications. This interface is used from Release 3.0 onwards for transferring session information from one RNC to another when an AT is performing a dormant handoff from one RNCs domain to another. The A13 protocol consists of two
major components: the network interface to the source/target RNC, and the A13 state machine. Note: The A13 state machine is not independent and is embedded within the session state machine. Each RNC has a node IP address by which it is addressed in the source/ destination field of the packet. The A13 procedures are triggered when an Access Channel packet is received with a UATI-32 whose color code does not match the local subnet. The 8-bit color code (i.e. 8 MSBs) of the received UATI-32 is mapped to a 104-bit subnet, concatenated with the lower 24-bits of the UATI to form UATI-128. This mapping is not guaranteed to be unique. However, the authentication of the A13-Request will fail in this case if the wrong source RNC is selected. The UATI-128, security layer packet, and Sector ID of the access channel on which the packet was received, are all sent in the A13-Session Information Request Message to the source RNC. A timer (1 sec default) is started on the target to wait for a response from the source RNC. If no response (either success or reject) is received, then A13 Session Information Request is retried up to two more times until a response is received. If no response is received after all the retries, the target RNC closes the DO session with the AT, which causes it to start a new one. At the source RNC, the security layer packet received in the A13 Session Information Request is authenticated. If the result is successful, an A13 Session Information Response is sent back to the target, which contains the session state information record. The SessionConfigurationToken on the target must be updated to be in sync with the AT. Note that private keys (i.e. session key) are exchanged in the clear within the A13-Session Information Response message. Therefore, a secure/private network should be used between RNCs. If the source RNC is still in a connected state with that AT when it moved away, the RNC will shortly disconnect due to either inactivity or reverse link loss (more likely), and go to a disconnected state. The RNC and RN resources will be cleaned up. If authentication failed, or if the session information for that UATI cannot be retrieved, an A13 Session Information Reject is sent back to the target, along with the failure reason. The target RNC will send a SessionClose message to the AT if an A13-Session Information Reject is received. The SessionClose message must be sent on all twelve sleep cycle phases because the target does not know the ATs sleep cycle. This will cause the AT to close its present session and request a new one. The timer that started when the Request was sent is stopped when the A13 Response is received. The target RNC populates the session with parameters retrieved from the source when an A13-Session Information Response is
received. However, if some of the parameters are unacceptable to the target, they must be renegotiated with the AT. Renegotiation of session config parameters is conducted the next time a DO-Connection is opened at the target. In this case, the target sends ConfigurationStart to ensure that the AT starts the configuration phase. While the A13 transfer is in progress, the target must temporarily associate packets that use the old UATI as well as new UATI (assigned by the target) with the same session. The association with the old UATI can be removed after the AT responds with UATIComplete following assignment of the new UATI. Typically, Terminal authentication is not required at the target in the case of an A13 session transfer. The retrieved MN ID, retrieved PDSN address (used to select the PDSN), and Access Network Identifiers (use the retrieved value only if the AT cannot provide the PANID) are used when establishing the A10 connection at the target in order to avoid PPP and mobile IP re-establishment. A Session Information Confirm is sent back to the source to notify it to remove the session information from its database. In addition, any associated connections (both 1xEV-DO and A10) must be removed at the source. Terminal authentication Terminal authentication is an optional requirement as specified in the TIA-878 standard. It requires the use of an AN-AAA server. If customers chose not to deploy this function, then user level authentication occurs at the PDSN or PDSN-AAA server. The A12 interface is the interface between the DO-RNC and the AN-AAA server and it is used only if terminal authentication functionality is used. The A12 messages are essentially the same messages used in the well known RADIUS protocol as defined in RFC2865. The specific attributes used in the messages are defined by the TIA-878 specifications. Consequently, the details of the basic message format is defined in RFC2865 while, the details of terminal authentication specific aspects are defined in TIA-878. The terminal authentication is intended to validate that a particular access terminal attempting to use the RAN. The function executes entirely on the RNC and uses the A12 interface to communicate with an external AN-AAA function. Figure 3-2 shows the main architectural components related to terminal authentication and the interfaces between them. If HRPD Terminal Authentication is enabled at the AN, the AT must authenticate with the AN using the following steps: 1. The AT opens a PPP connection (the AN-PPP connection) with the RNC on the access stream. During the PPP LCP phase the RNC requires that PPP authentication be done and that the CHAP protocol be used.
2. The AT performs CHAP-based authentication during the PPP authentication stage. 3. The RNC sends the authentication information from the CHAP protocol (which is information received from the AT), including the ATs Network Access Identifier (access NAI), to the AN-AAA over the A12 interface. 4. If the AT is authenticated, the AN-AAA provides the RNC with an IMSI for the user's packet data service. Note: The IMSI is not sent over the airlink to the AT; it is kept at the RNC and used for registration with the PDSN over the A11 interface and to identify DO sessions tied this AT on the specific RNC. 5. If the AT is not authenticated, the RNC removes the HRPD session for that user. Thus, HRPD terminal authentication protects the RNC and PDSN from access by unauthenticated ATs. In the RAN, the terminal authentication is implemented by the TermAuth module on the RNC. In the RNC, the TermAuth module is responsible for terminating the AN-PPP connection with the AT, initiating terminal authentication of the AT through the use of the CHAP authentication option during the setup of the AN-PPP connection, and controlling the A12 interfaces between the RNC and the AN-AAA. Note: The CHAP protocol and use of the A12 interface (based on RADIUS) implies that the AT and AN-AAA server are configured with the same information regarding the ATs NAI and password (secret key). If the ATs (NAI/password) is not configured in the AN-AAA user database or if the AT itself is not configured with the correct (NAI/password), the
411-2133-514
Preliminary
03.06
October 2005
AT will fail authentication. That is, fall into the if AT is not authenticated case in the previous steps.
Figure 3-2 Terminal authentication model
AT
1xEVDO signaling
RNC
A12 RADIUS
AN-AAA
AN-PPP
RLP over application access stream
AN-AAA selection mechanism The terminal authentication solution is based on the concept of AAA groups which consist of multiple AAA servers. When the RNC selects an AAA server to request authentication, it first chooses an AAA group based on the load balancing configuration and information it has received from the AT. Once the AAA group has been chosen, the RNC selects a specific AAA server from the chosen AAA group. Thus selection of AAA servers is implemented as a two-tier approach where the first tier, group selection, is used for load balancing authentication requests and the second tier, AAA selection, is used for fault tolerance. The following methods of AAA group selection are supported: NAI realm-based selectionIn this method, the realm part of the ATs NAI, that is, the part following the @ in atname@wirelessoperator.com, is used to choose the AAA group to which the request is to be sent. This decision is based on an AAA NAI routing table that must be configured by the operator. This table provides a lookup capability where a supplied realm results in the return of an AAA group for use in the actual server selection phase. When this option is used, it is important to supply a default lookup entry to be used when no matching realm is found in the table. Round robin selectionIn this method, the RNC routes each new request in a round robin manner to a new group. Thus, if the first request went to AAA Group 1, the next would be sent to AAA Group 2 and so on. When round robin selection is used there is no need to configure a default lookup entry as the next AAA group will always be used.
CDMA
1xEV-DO 3.0
The method used for selecting an AAA server is based on the fail over fault tolerance method, that is, the RNC tries the first server in the group and, if it fails and another server is requested, the next server in the group is tried. There is a configured number of allowable authentication requests for a group and for an RNC as a whole this must be configured to be consistent with the number of AAA servers configured in that group. Note: The algorithm does not keep history of failed AAA servers in a group so subsequent requests will have to try a previously failed AAA before moving on to another. The reason is that cause for the failure is unknown consequently and we assume the fault was transient. This approach allows flexible configuration of AAA selection policies. For example, if the operator is concerned more with load balancing than faulttolerance, the operator can configure some number of groups, each with one AAA server. If the operator is only concerned with fault-tolerance, the operator can configure a single group with multiple AAA servers. The operator may select a mode with both characteristics by selecting the number of groups and the number of servers in each group appropriately. Finally, one more items to consider is that if the operator wants to support roaming agreements with other operators, the operator must decide whether to use a proxy AAA server to route the authentication requests to the appropriate operator's AAA servers or use the NAI realm-based routing ability of the RNC to directly route the requests. Operation without terminal authentication If the terminal authentication function is bypassed, the RNC locally assigns an IMSI for the AT without any authentication. The basic idea is to synthesize an IMSI (pseudo IMSI) from the HardwareID of the AT. The constraint is that the pseudo-IMSI generated from the HardwareID must be unique if possible, so that no two different HardwareIDs results in the same IMSI. Uniqueness is important as the IMSI is used in inter-RNC hand off situations by the PDSN to track users and also by the RNC to identify duplicate DO sessions for the same AT. The format for an IMSI is 15 decimal digits. The first 3-digits are Mobile Country Code (MCC), the next 3-digits are Mobile Network Code (MNC) and the final 9-digits are the unique number assigned to the user. The algorithm maps the HardwareID to these 9-digits. The MCC and MNC are configurable on the RNC through the CLI only. Uniqueness of the pseudo-IMSI may only be guaranteed if the AT manufacturers do not exceed more than 58 for a network. Table 3-1 is hard coded in the RNC which serializes the ATs manufacturer codes (the most significant 8-bits of the ESN) and uses the serial number M in the pseudo-
411-2133-514
Preliminary
03.06
October 2005
IMSI generation algorithm for the user. This ensures the uniqueness of the derived pseudo-IMSI. If the ESN reported by the AT does not have a manufacturer code which falls in the Table 3-1, then the RNC assigns the default manufacturer code value of M equals 0. Consequently, if the AT vendor is not identified in Table 3-1, there is a higher probability the uniqueness of the generated pseudo-IMSI is not ensured.
Table 3-1 Conversion table to map the most significant 8-bits of the ESN Manufacturer Code [HEX] 0x00 0x74 0x01 0x51 0x65 0xb0 0xe9 0x60 0x6b 0x75 0x8d 0xc9 0xb3 0xbe 0xfe 0xc6 0x04 Assigned M Value 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
sheet 1 of 2
TIA assigned company Qualcomm, Sony Qualcomm Samsung, Sony Samsung Samsung Samsung Samsung Airprime GTran LG-IC LG-IC LG-IC Kyocera Kyocera Kyocera HongSheng Electronics Company
Notes TIA assigned 14 bit manufactur code starts with these 8 bits Currently CHESTER uses this value TIA assigned 14 bit manufactur code starts with these 8 bits
Needed only because HORNET always uses 0xc6
CDMA
1xEV-DO 3.0
Table 3-1 Conversion table to map the most significant 8-bits of the ESN (continued) Manufacturer Code [HEX] 0x05 0x23 0x27 0x29 Assigned M Value 18 19 20 21 LG Electronics Inc. LG Electronics Inc. Samsung Telecommunications America Curitel Communications, Inc. High Tech Computer Corporation Novatel Wireless, Inc. Pantech Co., Ltd.
sheet 2 of 2
TIA assigned company
Notes
0x2a 0x36 0x5b 0xf4
22 23 24 25
Base I/O (BIO) board
The BIO module is an I/O processor board that contains the following functional components: IP forwarder on page 3-26 Abis data demux processing on page 3-27 A10 demux processing on page 3-27 Address translator on page 3-28
On the receive side, the primary focus of the BIO software is to look at the appropriate protocol header (example, Abis, A10, IP) of incoming packets and forward the packets to the appropriate RNSM, BIO or SC for further processing. IP forwarder The IP forwarder runs in the fast path and performs fast IP forwarding of packets received from the link layer and transmission of packets received from Abis, A10, or any future IP-based interface.
411-2133-514
Preliminary
03.06
October 2005
The IP forwarder performs the following general steps upon receiving a packet from the link layer (this is not intended to be the complete forwarding algorithm, but instead give an indication of the interactions between various components): 1. Validate IP header. 2. Route table lookup. 3. If no match is found, post to IP stack in background to send ICMP host unreachable. 4. If the destination IP address matches the receiving IP interface, the following applies: If the protocol type is GRE, pass up to Abis demux (section 3.4.3.2) or A10 demux (section 3.4.3.3) based on the protocol in the GRE header. If ICMP packet, post to IP stack in background. Otherwise, perform Address Translator lookup (section 3.4.3.4) to determine the correct board for forwarding. Abis data demux processing The Abis data demux processing is used for uplink 1xEV-DO data frames only. The connection ID in the Abis data header is examined to determine (using a table lookup) which RNSM should be used to process the packet. The header is left intact; processing on the RNSM will perform the actual protocol termination. A10 demux processing The PCF data instances reside in the RNSM cards. A PPP packet arriving at the BIO card from the PDSN must be forwarded to the correct PCF data instance located in a RNSM card. The A10 demux processing entity is responsible for this task. The PPP data packets received from the PDSN are encapsulated in GRE. The GRE header's key field is the PCF session ID (PSI). The PSI is unique within a PCF domain and it uniquely identifies an access terminal (AT). The PCF signaling entity (residing in the SC card) manages the assignment of PSI. When the PCF signaling assigns a PSI for an AT, it adds the PSI to the AT mapping table. In the same entry, it also adds the RNSM card slot number to which the PPP packet received from the PDSN would be forwarded. PCF signaling knows the slot number information because the call control entity in that slot initiated setting up the A10 connection. The AT mapping table is distributed to all the RNSM cards and BIO cards through the distribution framework. When GRE packets arrive from the PDSN, the A10 Demux processing entity looks at the GRE header's key (which is also the PSI). It uses the PSI as the key to lookup the RNSM slot number in the AT mapping table. It then sends the GRE packet to that RNSM card through the system bus. The PCF data
CDMA
1xEV-DO 3.0
instance residing in that RNSM card is responsible for sending the PPP packet to the RLP entity. Address translator The address translator is responsible for translating the IP address of transmitted and received packets that correspond to UDP or TCP based applications running on the NE (for example, Abis signaling, topology manager, and PCF signaling). The address translator runs on each BIO in the system. When a packet is transmitted from a SC or RNSM board, the packet is forwarded to the address translator on the proper BIO. The translator modifies the packet and creates a translation table entry. The entry is used in the reverse direction to modify the packet and forward it to the proper board. Entries in the table are distributed so that each BIO contains identical tables.
411-2133-514
Preliminary
03.06
October 2005
End-to-end call flow

This chapter contains the following information: 1xEV-DO Signaling flow on page 4-1 1xEV-DO Data flow on page 4-30
This chapter covers the end-to-end signaling and data call flows for forward link and reverse link. 1xEV-DO session setup and connection setup are also discussed. Call flows for various handoff scenarios are briefly described.
1xEV-DO Signaling flow

The following signaling flows are described in this section: Data call setup flow on page 4-2 Session setup flow with A10 connection minimization on page 4-4 AT originates 1xEV-DO sessionunsuccessful terminal authentication on page 4-6 Connection setup/open flow on page 4-7 Connection establishmentAN initiated, fast connect on page 4-9 Connection close flow on page 4-11 Reverse soft/softer handoff call flow on page 4-13 Sector switching on page 4-15 Inter DO-RNC dormant handoff without A13 support on page 4-17 Successful regular A13 dormant handoff on page 4-19 Unsuccessful regular A13 dormant handoff on page 4-22 Successful prior A13 dormant handoff on page 4-23 Unsuccessful prior A13 dormant handoff on page 4-25 Inter RNC active handoff using multi-homing on page 4-27 Inter-technology handoff call flow on page 4-29
CDMA
1xEV-DO 3.0
4-2 End-to-end call flow Nortel Networks Confidential
Data call setup flow Figure 4-1 illustrates the1xEV-DO call setup flow.
Figure 4-1 1xEV-DO Data call setup flow diagram
The call flow interactions are described as follows: 1. The AT sends a UATI request over the access channel to the DOM, which relays it over Abis to the DO-RNC. The BIO relays the message to the call control function on the RNSM card. (The RNSM is determined from the particular access channel that carried the request.) 2. Call control establishes a context for the user, and requests the SC's Resource control entity to assign a UATI using the GenUATIReq message. 3. The SC returns the UATI.
411-2133-514
Preliminary
03.06
October 2005
End-to-end call flow 4-3 Copyright 2004-2005 Nortel Networks
4. The RNSM generates a UATI assignment message and sends it to the DOM over Abis. The DOM sends it to the AT over the control channel. 5. The AT opens a connection. The primary peers in this interaction are the AT and the call control. As part of the process, call control will request & receive airlink resources from the resource control component. Call control will also interact with the DOM to open the appropriate traffic channels. 6. The AT and call control negotiate the overall session configuration. During this process, the mapping of 1xEV-DO applications (for example, RLP) to streams is negotiated. Other attributes may be negotiated as well. 7. After the session configuration has been negotiated, the AT closes the connection. This is required to commit the negotiated attributes. 8. If terminal authentication is used, the following steps apply: a. The DO-RNC pages the AT to open a new connection for the terminal authentication PPP application stream; b. The DO-RNC issues a PPP challenge authentication protocol (CHAP) challenge; c. The AT replies with a CHAP Response; d. The DO-RNC relays the information from the CHAP response over the A12 protocol to the AN-AAA in an A12 Access-Request message; e. Assuming that the AT has provided valid authentication information, the AN-AAA responds to the DO-RNC with an A12 access-accept message; f. The DO-RNC responds to the AT with a CHAP authentication success message. 9. Call control requests and receives the HardwareID from the AT on the traffic channel. 10. Call control relays the HardwareID information to resource control on the SC, so the HardwareID - UATI association can be made available. This information is also used to detect and recover from the same AT inadvertently having a previous (stale) session on the DO-RNC. 11. Call control solicits the previous location (SID, NID and PZID) from the AT. Once it gets this information, it sends the AT the current location information associated with this DO-RNC. 12. The RNSM signals the PCF entity on the SC to set up the R-P channel for this session with the PcfCcOpenSessionReq message. This message will contain the previous location for the user (if any), to facilitate intersystem handoff. 13. The PCF-SC requests resource control on the SC to allocate a PSI with the PsiAllocReq message.
14. Resource control responds with the PsiAllocRsp message allocating a unique PSI. 15. PCF-SC sends an A11RegRequest message to the PDSN over the A11 interface. This message contains the previous location for the user (if any), to facilitate inter-system handoff. 16. The PDSN responds with the A11-RegReply message, setting up the A10 channel for this session. 17. The PCF, after setting up its side of the A10, sends a CcPcfOpenSessionRsp to the RNSM indicating that the A10 is ready. 18. The PDSN and the AT can now initiate a PPP session with each other. Session setup flow with A10 connection minimization Figure 4-2 illustrates the1xEV-DO call setup flow.
Figure 4-2 1xEV-DO session setup flow with A10 connection minimization
Call Control RNSM Resource Control RNSM Resource Control SC
AT
DOM
PCF SC
PDSN
AN-AAA
UATI Request
GenUATIReq
UATI Assignment UATI Complete DO Connection Open
GenUATIRsp
DO Session Config Process DO Connection Close
Page AT DO Connection Open
Term Auth only
CHAP Challenge CHAP Response CHAP Auth Success HW ID exchange internal HW ID exchange A12 Access Request A12 Access Accept
Session Open Connection close
Term Auth only
411-2133-514
Preliminary
03.06
October 2005
If A10 connection minimization feature is not enabled, A10 will be opened after the session opened same as in Data call setup flow. If the AT has no packet data session and no data to send, PDSN attempts to setup PPP session with the AT. It will send 10 LCP config requests, and eventually A10 is closed by the PDSN after PPP setup attempt by the PDSN times out. If the A10 connection minimization feature is enabled, A10 will not be opened after the session setup. The scenario describes a session setup with A10 connection minimization feature enabled when the AT has no packet data session and no data to send. Session setup starts the same way as in data call setup up to session configuration After session configuration, if Terminal Authentication is used, the RNC pages the AT to open a new connection for the terminal authentication. The HardwareID exchange occurs on the traffic channel since a DO Connection is opened for Terminal Authentication. If Terminal Authentication is not used, the connection will not be opened after the session configuration, and the HardwareID exchange occurs on the Control channel and Access channel. Location Update Protocol is not initiated. It will be initiated if RLP data is detected from the AT, if Terminal Authentication is enabled. After session setup, the connection will be closed (the connection opened for Terminal Authentication), and A10 Connection is not opened.
CDMA
1xEV-DO 3.0
AT originates 1xEV-DO sessionunsuccessful terminal authentication Figure 4-3 shows the call flow for an unsuccessful AT call origination in the AN, due to terminal authentication failure.
Figure 4-3 Initial AT originationunsuccessful terminal authentication
Call Control RNSM Resource Control RNSM PCF SC Resource Control SC
AT
DOM
PDSN
AN-AAA
UATI Request
GenUATIReq
UATI Assignment UATI Complete DO Connection Open
GenUATIRsp
DO Session Config Process DO Connection Close
DO Connection Open
CHAP Challenge CHAP Response CHAP Auth Failure DO Connection Close A12 Access Request A12 Access Reject
Term Auth only
SessionClose SessionClose
The AT and the AN initiate DO session establishment. Protocols and protocol configurations are negotiated during the session configuration stage, stored and used for future communications between the AT and the AN. The AT indicates that it is ready to exchange data on the access stream For example, the flow control protocol for the default packet application bound to the AN is in the open state. The AT and the AN initiate PPP and LCP negotiations for access authentication. The AN generates a random challenge and sends it to the AT in a CHAP Challenge message. When the AN receives the CHAP response message from the AT, it sends an Access-Request message on the A12 interface to the AN-AAA.
411-2133-514
Preliminary
03.06
October 2005
The AN-AAA looks up a password based on the NAI (which is contained in the user-name attribute in the Access-Request message) and checks the CHAP response value. If the access authentication fails, the AN-AAA sends an Access-Reject message on the A12 interface. The AN returns an indication of CHAP access authentication failure to the AT. The AN sends a SessionClose message to the AT to close the DO session. The AT responds with a SessionClose message.
Connection setup/open flow Figure 4-4 illustrates the 1xEV-DO connection setup flow. Note: In this particular example, pilots from more than one DOM are being employed; the connection is said to be coming up in soft handoff.
Figure 4-4 1xEV-DO Connection setup flow diagram
CDMA
1xEV-DO 3.0
The connection setup is described as follows: 1. AT sends the AN a connection request. Lower layers are processed by DOM, and sent to the DO-RNC via the Abis channel associated with the access channel the request came on. The BIO peeks into the DO packet header, and from the UATI, determines which RNSM to forward the request. 2. Based upon the embedded route update information, call control determines which airlink resources will be needed, and sends the associated request to resource control (on the same RNSM). It also requests Abis data connection IDs, which will be used to identify the traffic flows for this AT. 3. Resource control responds with the airlink and Abis connection ID allocations. 4. Call control sends a request (through Abis signaling) to each DOM to open traffic channel for this AT; embedded in the request, it tells the DOM the Abis connection ID to use for identifying the traffic flows. 5. The DOM responds. Included in the response is information (for example, MAC indices) that will be needed for the TCA message. 6. Call control sends the AT a traffic channel assignment message, indicating the pilots the AT can use. 7. The AT starts the reverse traffic channel pilot. It also sends DRC information, such as the indication of which pilot it wants to receive the forward traffic channel to the relevant DOM (in this example it is DOM2). 8. The DOMs detects the presence of the reverse traffic channel signal for this AT, and an indication is sent to call control on the DO-RNC using the Abis signaling channel. 9. DOM2 decodes the DRC, and sends the appropriate message to call control on the DO-RNC. 10. Upon receiving this desired sector message, Call control notifies the SDU where to steer forward link data. 11. Call control also notifies the RLP and PCF RNSM components that data flow can start. 12. Call control sends a message to the AT acknowledging that the reverse traffic pilot has been detected. This message is carried over a traffic channel dedicated to this AT, and is sent over the Abis data channel, using the appropriate connection ID for that AT (previously negotiated with the DOM). 13. The AT responds with a traffic channel complete message, indicating it considers the DO connection to be open. Once demodulated by the DOM, this message will be sent to the DO-RNC over the Abis data channel,
using the appropriate connection ID for that AT (previously negotiated with the DO-RNC). At the DO-RNC, the BIO uses the Abis connection ID to determine which RNSM to relay the packet. 14. If an A10 is already open for the AT, call control sends an indication to the PCF Signaling component on the SC that the airlink is open. 15. The PCF signaling component receives this indication and sends an Active Start accounting record to the PDSN. 16. The PDSN acknowledges receipt of the accounting record. Connection establishmentAN initiated, fast connect Figure 4-5 shows the connection establishmentAN initiated, fast connect.
Figure 4-5 1xEV-DO fast connect setup flow diagram
AT RN Call Control -RNSM Resource Control -RNSM SDU - RNSM PCF -RNSM FastPath -RNSM PDSN
User data PageRequested AirLinkResourceReq AirLinkResourceRsp AddTcReqMsg AddTcRspMsg TrafficChannelAssignment pilot, DRC RtcAcquiredIndMsg FtcDesiredIndMsg "set sector"
"start"
RTC Ack TrafficChannelComplete PageSuccess
PPP Traffic
CDMA
1xEV-DO 3.0
The 1xEV-DO fast connect setup flow is described as follows: The AT is not connected when the PDSN sends user data to the PCF over the A10 channel. The PCF buffers the incoming data and sends a PageRequested message to Call Control. Assuming the AT is still in suspend mode and the Route Update Validity timer on the RNC is not expired, the Call Control does not page the AT and immediately requests Resource Control to allocate airlink resources using the AirLinkResourceReq message. Resource Control responds with the AirLinkResourceRsp message, indicating the resources that are used for this connection. Call Control sends an Add Traffic channel Request message (AddTcReqMsg) to the RN over the Abis signaling channel. The RN allocates the local resources and indicates status to the RNC using the AddTcReqRsp message. The RNC sends the Traffic Channel Assignment message over the control channel to the AT. The AT begins to transmit pilot and DRC subchannels of the reverse traffic channel. When the RN has locked onto the AT, it sends an RTC Acquired Indication message to the RNC over the Abis signaling channel. When the RN is ready to transmit data to the AT, it sends an FTC Desired Indication message to the RNC over the Abis signaling channel. Call Control requests the SDU to add this sector to its list of sectors participating in this connection. Call Control requests the fast path to start serving this sector. Call Control sends an RTC Ack message to the AT over the forward traffic channel. The AT responds with a traffic channel complete message over the reverse traffic channel. Call Control notifies the PCF entity on the RNSM that the page is successful. End-to-end PPP traffic may flow.
411-2133-514
Preliminary
03.06
October 2005
Connection close flow Figure 4-6 illustrates the 1xEV-DO connection close flow.
Figure 4-6 1xEV-DO connection close flow diagram
The 1xEV-DO connection close flow is described as follows: 1. Call control sends a connection close (request) to the AT indicating that it wishes to close the DO connection (for example, if the connection has been dormant for too long). This message is sent through the Abis data channel associated with that AT. (If the AT is initiating the close, this step is skipped) 2. The AT responds with connection close. Once demodulated by the DOM, this message will be sent to the DO-RNC over the Abis Data channel, using the appropriate connection ID for that AT (previously negotiated with the DO-RNC). At the DO-RNC, the BIO uses the Abis connection ID to determine which RNSM to relay the packet. 3. If an A10 is already open for the AT, call control sends an indication to the PCF Signaling component on the SC that the airlink is now closed.
CDMA
1xEV-DO 3.0
4. The PCF signaling component receives this indication, and sends an active stop accounting record to the PDSN. 5. The PDSN acknowledges receipt of the accounting record. 6. Call control also notifies the RLP and PCF components (on the same RNSM) that data flow must stop. 7. Call Control sends messages via Abis Signaling to all DOMs with traffic channels open for this AT that it should close them. 8. The DOM(s) responds back acknowledging that it has closed the traffic channel. 9. At this point, call control can now release the resources associated with the connection (airlinks, Abis data connection IDs), and notifies resource control (on the same RNSM) that it wishes to do so. 10. Resource control acknowledges.
411-2133-514
Preliminary
03.06
October 2005
Reverse soft/softer handoff call flow Reverse link soft/softer handoff refers to the addition or removal of pilots in the active set. If the pilots being added (or removed) are associated with a DOM for which another sector is in use for that user, the operation is considered to be a softer handoff; if not, then the operation is considered to be soft handoff. For a given active set change, both softer handoff and soft handoff operations may be involved. The Soft/Softer handoff call flow is illustrated in Figure 4-7.
Figure 4-7 1xEV-DO reverse soft/softer handoff call flow diagram
The 1xEV-DO reverse soft/softer handoff call flow is described as follows (the AT already has a connection, and user data is flowing): 1. The AT sends a Route Update message embedded in the Reverse Traffic Channel to the DOM which relays it to the DO-RNC over the Abis connection. The route update identifies pilots are to be added (and dropped) from the active set. 2. Call control processes the route update and requests resource control to allocate airlink resources for the pilots to be added using the
CDMA
1xEV-DO 3.0
AirLinkResourceReq message. Note that at this point, it does NOT yet release the resources for the pilots to be dropped. 3. Resource control responds with the AirLinkResourceRsp message, indicating the additional resources that should be used for this connection. 4. Call control sends an add traffic channel request message (AddTcReqMsg) to each DOM with a sector that the AT is requesting a new pilot over the Abis signaling channel. 5. Each DOM allocates local resources and indicates status to the DO-RNC using the AddTcReqRsp message. 6. The DO-RNC sends the traffic channel assignment (TCA) message indicating the new active set. This TCA includes the previous pilots already in use, plus the new pilots being added, minus the pilots that are to be dropped. Since the AT already has a connection, the message is conveyed over the forward traffic channel. 7. The AT begins to transmit pilot and DRC subchannels of the reverse traffic channel. 8. When the DOMs associated with the new pilots have locked onto the AT, they send an RTC acquired indication message to the DO-RNC over the Abis signaling channel. 9. The AT sends a traffic channel complete message over the reverse traffic channel. 10. At this point, call control sends a remove traffic channel request message (RemoveTcReqMsg) to each DOM with a sector that has been dropped from the active set. 11. Each DOM releases local resources and responds back to the DO-RNC using the RemoveTcRsp message. 12. At this point, call control can now release the resources associated with the removed pilots, and notifies resource control (on the same RNSM) that it wishes to do so. 13. Resource control acknowledges.
411-2133-514
Preliminary
03.06
October 2005
Sector switching Figure 4-8 illustrates the 1xEV-DO sector switching flow. Note: Sector switching for pilots in softer handoff is processed entirely by the DOM modem driver. No DO-RNC processing is involved.
Figure 4-8 1xEV-DO sector switching flow diagram
1xEV-DO Sector Switching between two pilots in soft handoff is described as follows: 1. The AT has been pointing the DRC toward a pilot associated with DOM1. 2. The AT stops pointing the DRC toward DOM1. The DOM detects this, and sends an FTC stopped message to the DO-RNC, through the Abis signaling channel. Embedded in that message is an indication of the last MAC frames sent out over the air. 3. This message is processed by call control, which commands the fastpath to stop sending forward traffic.
4. PPP traffic still flows in the reverse direction. 5. The AT starts pointing the DRC toward a pilot associated with DOM2. The DOM detects this, and sends an FTC desired message to the DO-RNC, using the Abis Signaling channel. 6. This message is processed by call control, which commands the SDU to set/reset the sector that it is sending forward traffic toward. Call control also commands the fastpath to backup the (MAC packet) transmission buffer (based on the previous FTC stopped message) and start sending data. 7. PPP traffic can now flow in both directions once again.
411-2133-514
Preliminary
03.06
October 2005
Inter DO-RNC dormant handoff without A13 support Figure 4-9 illustrates the 1xEV-DO inter DO-RNC dormant handoff without A13 flow.
Figure 4-9 1xEV-DO inter DO-RNC dormant handoff without A13 flow diagram
CC, RC, - RNSM1, SC1 PCF, - RNSM1, SC1 CC, RC, - RNSM2, SC2 PCF, - RNSM2, SC2
AT
AN-AAA
PDSN
PPP / RLP Traffic

UATI Request w/ UATI Session Close
PPP / A10 Traffic
UATI Assignment (starts with RATI)
Session Configuration
Authentication
Location Request Location Notification Location Assignment
A12 Access Request / Response
PcfCcCloseA10Log Location Complete PcfCcCloseA10Rsp A11 - Reg Update
A11 - Req Request (MEI, PANID = 0, CANID) A11 - Reg Reply
Immediately, PDSN initiated A10 connection closed
PcfCcCloseA10Log PcfCcCloseA10Rsp
A11 - Reg Ack A11 - Reg Request A11 - Reg Reply (Lifetime = 0)
PPP / A10 Traffic
PPP / RLP Traffic
The 1xEV-DO inter DO-RNC dormant handoff without A13 call flow is described as follows: 1. The AT has a previous connection with the PDSN through RNC1. 2. The AT crosses over into another subnet, AN2, finds AN1's signal is too weak and decides to start handoff to AN2. 3. The AT will initially send a UATI request. As A13 is not supported, the DO-RNC will reply with a close session message to the AT.
CDMA
1xEV-DO 3.0
4. The AT will try to setup a new DO session. The AT carries out UATI assignment, session configuration and terminal authentication (if configured). 5. The AN sends a location request and the AT tries to send a location notification. As the session has been reset, the PANID will be null and the AT will not include a PANID in the location notification. The AN assigns a new ANID to the AT by sending a LocationAssignment, and the AT updates its ANID with AN2's ID. The AT responds with a LocationComplete. 6. The RNC2 sets up a new A10 connection with a PDSN based on the IMSI of this AT. The PDSN selected is the same as the one that the AT was connected to previously. The A11 reg req contains a critical vendor specific extension (CVSE) with a mobility event indicator (MEI). The A11 Reg Req also contains a normal VSE (NVSE) with the previous ANID (PANID) and current ANID (CANID), and the CANID will be set to the ANID of the DO-RNC. 7. The PDSN realizes that a handoff has occurred by comparing the IMSI values, and starts to remove the old A10 connection (R-P session) by sending an A11 registration update to the old DO-RNC's PCF. 8. RNC1 removes the A10 connection and goes into the no A10 connection state upon receiving the A11 Registration Update from the PDSN. The DO-RNC does not remove the 1xEV-DO session itself. 9. PDSN should send a MIP agent advertisement, as PANIDs do not match. PPP renegotiation is also a possible reaction by the PDSN, but may be extreme as there are various cases where the PANID will simply be unknown.
411-2133-514
Preliminary
03.06
October 2005
Successful regular A13 dormant handoff Figure 4-10 illustrates the 1xEV-DO successful regular A13 dormant handoff.
Figure 4-10 Successful regular A13 dormant handoff call flow diagram
AT
SlowPath
getSession() AC Packet
CallControl (target)
socket (target)
CallControl (source)
PDSN
dispatch message A13-SIRequest A13-SIResponse post message to process Response UATIAssignment UATIComplete reconfigure later (next time connection is opened) if needed
HardwareID
Location Update Protocol Open A10 with PCF A13-SIConfirm
Close A10 with PCF
The call flow is described as follows: 1. The A13 handoff procedure starts when the AT sends a UATIRequest message on the Access Channel to the target RNC, with a UATI Colorcode that doesnt match that of the target RNC. The call to getSession() will create a session, and call Topology Manager to determine if the source RNC belonging to that ColorCode is available. If available, the mbuf containing the security layer packet is cloned and the SectorID (both passed in the function argument) are both saved, and eventually used in the A13 Session Information Request message. 2. HDRSlowPath will dispatch the message to CallControl, which posts a message to be processed in its own context. HDRSlowPath will check a
flag in Session to determine if the A13 procedures will occur (i.e. cloned security layer packet saved). If so, ACPacket processing will ignore any AC authentication. The dispatched message is most likely either a Route Update or UATIRequest message. CallControl must process every message that is dispatched to it. 3. When a UATIRequest is received, the Session State Machine will transition to a state that sends an A13-Session Information Request to be sent if the source RNC was previously found. A timer TA13req (1 sec default) is started to wait for a response from the source RNC. If the source RNC was not found, the session will attempt to be closed. If no UATIRequest is received after a timeout, the session will be closed as well. In either case, the SessionClose message must be sent on all 12 sleep cycles because there is no information regarding the ATs sleep cycle. 4. Source RNC returns A13-Session Information Response Message (assumes successful authentication & valid session protocols stored at the source) to the target. This response contains UATI-128, MN ID, PDSN address, PANID, and session state information record. The MessageSequence to be used in the UATIAssignment is also retrieved. Target A13 stops TA13req timer. If A13 scalar setting for sending HardwareID in A13 Response is enabled on source RNC, the A13 response will contain the AT HardwareID as well. 5. Target socket callback posts the A13-Session Information Response message to the CallControl message queue. CallControl processes A13Response in its own context. The target checks the received configuration to determine whether reconfiguration is needed. 6. Send UATIAssignment to the AT using the MessageSequence retrieved from the source RNC. This message is sent on the retrieved sleep cycle on the Control Channel. The Assignment should also request that the AT report 13 bytes (104 bits) of the old UATI (i.e. assigned by the source RNC). 7. AT sends UATIComplete and reports upper bits of old UATI. If the reported bits do not match that of the source RNC from which the session was retrieved using A13, then close the session. 8. If the upper UATI-104 bits reported in UATIComplete matches that of the source RNC, check the parameters retrieved via A13 for acceptability. If the UATI-104 does not match the subnet ID of the source RNC, the session is closed. If the parameters retrieved via A13 are unacceptable to the target RNC, the session is closed. If the session parameters retrieved via A13 do not match the operator settings at the target RNC, but are still useable, the target session uses those parameters until the next time the connection is open; at which time the session parameters are reconfigured to match the operator settings. The RNC does not specially solicit a connection to be opened for the sole purpose of reconfiguration.
411-2133-514
Preliminary
03.06
October 2005
9. If the A13Response message from Source RNC does not contain the HardwareID, retrieve the HardwareID from the AT. 10. Retrieve the PANID from the AT. If the AT cannot provide one, then the one retrieved from A13 is used when opening the A10. Assign the CANID of the target RNC to the AT. 11. Open an A10 (if necessary) with the PDSN selected by the address retrieved using A13. However, if that PDSN is not reachable by the target, then it will select an alternate one. The MEI bit is always set to 1 when opening an A10. 12. After receiving a successful A11 Response, wait 5 sec before sending A13-Session Information Confirm to the source RNC, requesting it to delete the session and close any open A10 or DO-connections. This 5 sec timer is added as a safeguard against deleting the A10 on the source before the PDSN completed switching the PPP session over to the target. The timer value is hard-coded to a conservative value of 5 sec, so it not necessary to configure it. However, a hidden command is available to do so. 13. For an intra-PDSN handoff, the A10 on the source RNC is closed by the PDSN once it switches the PPP session for that user to the target RNC. For an inter-PDSN handoff, the A10 on the source RNC is closed by the RNC once it receives the A13-Confirm message to remove the session.
CDMA
1xEV-DO 3.0
Unsuccessful regular A13 dormant handoff

Figure 4-11 illustrates the 1xEV-DO inter DO-RNC dormant handoff without A13 flow.
Figure 4-11 Unsuccessful regular A13 dormant handoff call flow diagram
AT
SlowPath
getSession()
AC Packet
socket (target)
dispatch message A13-SIRequest A13-SIReject post message to process Reject close session
open new session
The following scenario describes the unsuccessful retrieval of session during A13 dormant handoff: 1. A13 dormant handoff procedure starts the same way as in Successful regular A13 dormant handoff up to the A13-Session Information Request. 2. Source returns A13-Session Information Reject Message to the target. This response contains the reason for the rejection. The reason could be that the session was not found, session packet authentication failed, or problems with the configuration protocols. Target A13 stops TA13req timer. Note that if no response (either positive or negative) was received from the source RNC after expiration of the TA13req timer, the target resends the A13-Session Information Request up to two more times. If still no response is received after all the retries, the target RNC closes the DO session with the AT, which causes it to start a new one. 3. Target socket callback posts the A13-Session Information Reject message to the CallControl message queue. CallControl processes A13-Reject in its own context. The reason code is logged. 4. Close session. The SessionClose message must be sent on all 12 sleep cycles because the ATs sleep phase is unknown. 5. AT opens a new DO-session
Successful prior A13 dormant handoff

Figure 4-12 illustrates the successful prior A13 dormant handoff call flow on target DO-RNC (successful retrieval of prior session A13).
Figure 4-12 Successful prior A13 dormant handoff call flow diagram
AT
SlowPath
getSession() AC Packet
socket (target)
PDSN
dispatch message UATIAssignment UATIComplete
AT-initiated session config A13-SIRequest A13-SIResponse post message to process Response
AN-initiated session config
reconfigure later (next time connection is opened) if needed HardwareID
Location Update Protocol Open A10 with PCF A13-SIConfirm
Close A10 with PCF
The call flow is described as follows: 1. The AT sends a route update and UATIRequest message, using a new RATI for its ATI. 2. HDRSlowPath will dispatch the message to CallControl, which posts a message to be processed in its own context. The dispatched message is either a Route Update or UATIRequest message. CallControl must process every message that is dispatched to it. 3. The AN assigns a new UATI to the AT
4. The AT responds with UATIComplete 5. The AT opens a new connection and starts AT-initiated session configuration. The Session Config Protocol proposes a Prior Session attribute. The AN accepts it. The AT then sends Configuration Complete 6. The target RNC sends an A13-Request to the source RNC 7. Source RNC returns A13-Session Information Response Message (assumes successful authentication & valid session protocols stored at the source) to the target. This response contains UATI-128, MN ID, PDSN address, PANID, and session state information record. The MessageSequence to be used in the UATIAssignment is also retrieved. Target A13 stops TA13req timer. If A13 scalar setting for sending HardwareID in A13 Response is enabled on source RNC, the A13 response will contain the AT HardwareID as well. 8. Target socket callback posts the A13-Session Information Response message to the CallControl message queue. CallControl processes A13Response in its own context. Save retrieved parameters. Check configuration records to determine whether reconfiguration is needed. 9. AN sends Configuration Complete to finish AN-initiated session configuration. The connection is then closed by the AT. 10. If the parameters retrieved via A13 are unacceptable to the target RNC, the session is closed. If the session parameters retrieved via A13 do not match the operator settings at the target RNC, but are still useable, the target session uses those parameters until the next time the connection is open; at which time the session parameters are reconfigured to match the operator settings. The RNC does not specially solicit a connection to be opened for the sole purpose of reconfiguration. 11. If the A13Response message from Source RNC does not contain the HardwareID, retrieve the HardwareID from the AT 12. Retrieve the PANID from the AT. If the AT cannot provide one, then the one retrieved from A13 is used when opening the A10. Assign the CANID of the target RNC to the AT. 13. Open an A10 (if necessary) with the PDSN selected by the address retrieved using A13. However, if tvhat PDSN is not reachable by the target, then it will select an alternate one. The MEI bit is always set to 1 when opening an A10. 14. After receiving a successful A11 Response, wait 5 sec before sending A13-Session Information Confirm to the source RNC, requesting it to delete the session and close any open A10 or DO-connections. This 5 sec timer is added as a safeguard against deleting the A10 on the source before the PDSN completed switching the PPP session over to the target. The timer value is hard-coded to a conservative value of 5 sec, so it is not
411-2133-514
Preliminary
03.06
October 2005
necessary to configure it. However, a hidden command is available to do so. 15. For an intra-PDSN handoff, the A10 on the source RNC is closed by the PDSN once it switches the PPP session for that user to the target RNC. For an inter-PDSN handoff, the A10 on the source RNC is closed by the RNC once it receives the A13-Confirm message to remove the session. Unsuccessful prior A13 dormant handoff Figure 4-13 illustrates the unsuccessful retrieval of prior session A13 dormant handoff call flow on target DO-RNC.
Figure 4-13 Unsuccessful prior A13 dormant handoff call flow diagram
AT
SlowPath
getSession()
AC Packet
socket (target)
dispatch message UATIAssignment UATIComplete
AT-initiated session config A13-SIRequest A13-SIReject post message to process Response Close Session
open new session
The call flow is described as follows: 1. The AT sends a route update and UATIRequest message, using a new RATI for its ATI. 2. HDRSlowPath will dispatch the message to CallControl, which posts a message to be processed in its own context. The dispatched message is either a Route Update or UATIRequest message. CallControl must process every message that is dispatched to it. 3. The AN assigns a new UATI to the AT
CDMA
1xEV-DO 3.0
4. The AT responds with UATIComplete 5. The AT opens a new connection and starts AT-initiated session configuration. The Session Config Protocol proposes a Prior Session attribute. The AN accepts it. The AT then sends Configuration Complete 6. The target RNC sends an A13-Request to the source RNC 7. Source returns A13-Session Information Reject Message to the target. This response contains the reason for the rejection. The reason could be that the session was not found, session packet authentication failed, or problems with the configuration protocols. Target A13 stops TA13req timer. Note that if no response (either positive or negative) was received from the source RNC after expiration of the TA13req timer, the target resends the A13-Session Information Request once more. If still no response is received after several retries, the session will be closed. 8. Target socket callback posts the A13-Session Information Reject message to the CallControl message queue. CallControl processes A13-Reject in its own context. The reason code is logged. 9. Close session. The SessionClose message must be sent on all 12 sleep cycles. 10. AT opens a new DO-session
411-2133-514
Preliminary
03.06
October 2005
Inter RNC active handoff using multi-homing Figure 4-14 shows a call flow for reverse link soft handoff where the RNC is a primary RNC for RN-2 and a secondary RNC for RN-1; and the AT is requesting to add a pilot on RN-1 and remove a pilot on RN-2.
Figure 4-14 Inter RNC active handoff call flow diagram
AT
RN-1 (RNC-1 is a Secondary RNC for RN-1)
RN-2 (RNC-1 is a Primary RNC for RN-2)
RNC-1 Call Control RNSM
PDSN
PPP Traffic
Route Update
AddTcReqMsg
AddTcRspMsg
TrafficChannelAssignment
pilot RtcAcquiredIndMsg TrafficChannelComplete RemoveTcReq RemoveTcRspMsg
PPP Traffic
Nortels Inter-RNC Active Handoff feature is implemented using the multihoming approach. Each RN will home to a Parent RNC and zero or more Secondary RNCs. The RNC will have enough information about sectorcarriers of all RNs homed to it (primary and secondary) to be able to add any of them to an ATs active-set. Therefore, an RNC that contains the session for
an active call will be able to add soft handoff legs to its Primary RNs, as well as to its Secondary RNs if the AT moves into the coverage area of one of its Secondary RNs. The AT has an active connection in Subnet-1. As the AT moves from Subnet-1 to Subnet-2 and starts seeing the pilots from the RNs in Subnet-2, itll send a Route-Update message to RNC-1 requesting that those pilots be added to its Active Set. Even though RNC-1 is not the Primary RNC for RNs in Subnet-2, RNC-1 has sufficient information about them to be able to add them to the ATs active set as in a normal soft handoff scenario. Thus the AT can execute a reverse link soft handoff and maintain its connection. Subsequently if/when the connection goes dormant, the AT will initiate an A13 handoff between RNC-2 and RNC-1 so that the ATs session information can be transferred from RNC-1 to RNC-2.
411-2133-514
Preliminary
03.06
October 2005
Inter-technology handoff call flow Figure 4-15 illustrates the inter-technology handoff call flow.
Figure 4-15 Inter-technology dormant handoff flow diagram
1xRTT, BSC/ BTS PCF, 1xRTT CC, RC, -RNSM, SC PCF - SC, RNSM
AT
PDSN1
PDSN2
AN-AAA
PPP / RLP Traffic
PPP / A10
UATI Assignment
Session Configuration
Authentication
Location Request Location Notification Location Assignment Location Complete
A12 Access Request / Response
A11 - Req Request PcfCcOpenA10Req (MEI, PANID = 1xRTT, CANID) PcfCcOpenA10Rsp A11 - Reg Reply
PPP / RLP Traffic
PPP / A10
PPP / RLP Traffic
PPP / A10
A11 - Reg Update
A9 Close Req A9 Close Rsp
A11 - Reg Ack A11 - Reg Request (Lifetime = 0) A11 - Reg Reply
After Idle, PPP Timeout, PDSN Initiated A10 Connection Close
The call flow is described as follows: 1. The AT crosses over into a 1xEV-DO subnet, AN2, and decides to start handoff to AN2. 2. The AT carries out UATI assignment, session configuration and terminal authentication. 3. The ANC will send a Location Request and retrieve the AT's previous ANID and updates the AT's ANID with AN2's ANID. The PANID is the ANID of the 1xRTT system. 4. The RNC2 sets up a new A10 connection with a PDSN based on the IMSI of this AT. The PDSN selected is a different one from the one that the AT was connected to previously.
CDMA
1xEV-DO 3.0
5. The PDSN2 sets up a new A10 connection and PPP connection. 6. PDSN1 times out the idle PPP session and sends an A11 registration update to the RNC1. 7. RNC1 removes the A10 connection and goes into the no A10 connection state upon receiving the A11 registration update from the PDSN. The DO-RNC does not remove the 1xEV-DO session itself
1xEV-DO Data flow

The following signaling flows are described in this section: Forward link data flow on page 4-30 Reverse link data flow on page 4-32 Forward link data flow Figure 4-16 illustrates the 1xEV-DO data flow.
Note: This call flow assumes that the PPP session exists between the AT and the PDSN.
Figure 4-16 1xEV-DO data flow diagram
The call flow is described as follows: 1. PDSN sends the data packet on A10 interface to the BIO port of the DO-RNC. 2. After checking PSI information, the BIO forwards it to the PCF entity residing on the appropriate RNSM module. 3. The PCF entity in the RNSM checks if the airlink connection for the AT is active or dormant by using the lookup table. If the airlink is dormant then the PPP data is buffered and RNSM call control is asked to send page to the AT and establish the connection.
411-2133-514
Preliminary
03.06
October 2005
4. Airlink connection setup is negotiated between the RNSM call control and the AT. Eventually when the airlink connection is established, the look-up table is updated. This triggers the RNSM PCF that the buffered data packet can be processed further. If the airlink connection is denied then the buffered data packet is discarded by the RNSM PCF. 5. The PCF dequeues the data, strips the header, and sends it to RLP component. From there it goes to SDU and then to Abis. All these components reside on the same RNSM. The Abis component does a route lookup, and forwards the data to the appropriate BIO port. 6. The fastpath on the BIO card forwards the data packet to the AT using the DOM. For inter-RNSM handoff scenario the data or signaling flow in the forward direction is as follows. Assuming that an AT had a DO session and data connection with a DOM homed on the RNSM-1 and then it moved to a DOM which is homed to the RNSM-2 in the same RNC. PPP packet arrives to BIO-1 port-1. The BIO-1 checks the PSI and forwards it to RNSM-1. RNSM-1 checks the lookup table (all of the RNSMs/BIOs/SC share the same lookup table), if the airlink is open with the AT. Assuming it is open, the packet is stored in the rep-RLP Q on RNSM-1. The data is then processed for RLP, 1xEV-DO layers and SDU in the RNSM-1. Multiplexing the MAC packets and forming an Abis packet are performed in RNSM-1. From there, the packets are sent to the BIO, and out to the DOM. Note that the bearer traffic goes directly from RNSM-1 to the outbound BIO-1, regardless of whether or not the destination DOM is homed to RNSM-1. For RNC-DOM signaling, the path is indirect. So, if Call Control needs to open a traffic channel, the Abis component on RNSM-1 does a route lookup and relays the associated Abis signaling message to RNSM-2 (TCP endpoint resides). RNSM-2 then forwards it to an appropriate BIO port.
CDMA
1xEV-DO 3.0
Reverse link data flow Figure 4-17 illustrates the reverse link data flow. Note: This data flow diagram assumes the PPP session exists between the AT and the PDSN. If the connection does not exist or the airlink is dormant, the AT opens the airlink connection before sending any data to the AN.
Figure 4-17 1xEV-DO Reverse link data flow diagram
The data flow is described as follows: 1. AT sends the data packet to the DOM. The DOM demodulates the data, performs the MAC layer processing, adds the appropriate Abis header (based on the MAC index) and forwards the data to the DO-RNC-BIO. 2. At the DO-RNC BIO, the Abis component determines the proper RNSM to relay the data, based upon the Abis header. The RNSM receives the packet and send it to the SDU component. From there it goes to RLP and then to the PCF. All these components reside on the same RNSM; the Abis header is used to determine the proper per-user context. 3. The RNSM identifies the correct BIO port from the database (A10 lookup table) and sends the packet to the BIO. This BIO could be different from the one where the Abis data was received from the DOM. The above figure shows an example where it is the same. 4. The fastpath on the BIO card forwards the data packet to the PDSN. For inter-RNSM handoff scenario the data or signaling flow in the reverse direction is as follows. Assuming that an AT had a DO session and data connection with a DOM homed on the RNSM-1 and then it moved to a DOM which is homed to the RNSM-2 in the same RNC. BIO receives an Abis packet and checks if it is ACH or traffic. If it is ACH, and based on UATI info, the BIO sends it to RNSM-1 (DO session resides). If it is traffic, it looks at the Abis connection ID, and sends it directly to
RNSM-1. RNSM-1 demultiplexes the packet and sends the MAC packets to the SDU which resides in the RNSM-1. Once the packet arrives on RNSM-1, everything (SDU processing, RLP, header swap to put on PSI) is done in the fastpath task context. For RNC-DOM signaling, the path can be indirect. So, if a DOM homed on RNSM-2 needs to send a signaling message relevant to a connection homed on DOM-1 (for example, a response to an open traffic channel request), the DOM will send an Abis signaling message which will initially arrive at RNSM-2 (since that's where the TCP endpoint resides). The Abis component will inspect the message header, to determine if the message is for a user homed on RNSM-1 and relay the message to RNSM-1.
CDMA
1xEV-DO 3.0
411-2133-514
Preliminary
03.06
October 2005
DO-RNC redundancy
This chapter contains the following information: DO-RNC redundancy model on page 5-1 System controller module redundancy on page 5-1 RNSM module redundancy on page 5-2 BIO module redundancy on page 5-2 Hard disk on page 5-2
DO-RNC redundancy model
The DO-RNC redundancy model is based on following concepts: Active-standby 1+1 redundancyIn this mode, the protected element is running in service while the standby element is an identical configuration that is strictly monitoring the health of the active element and mirroring its configuration. Load sharing N+1 redundancyIn this variant, there is no designated standby but the protected elements are provisioned such that there is one more element than needed to provide the base service. All elements are actively participating in providing service and, if any single element fails, the system is capable of relocating the services provided by the failed element to the remaining elements without overloading them.
System controller module redundancy
The system controller (SC) module will have a 1+1 redundancy. At anytime, one SC module operates in active mode and the other in standby mode. As shown in figure 3, SC-A and HSC-A modules are operated in active mode. When a failure (or intentionally/forced switchover) occurred, SC-B and HSC-B modules located in slot 8 and 9, will switchover and become the active SC module. The following steps take place in case of SC switchover: 1. The standby SC monitors whether the active SC is operational by checking the heart beats of the active SC.
CDMA
1xEV-DO 3.0
5-2 DO-RNC redundancy Nortel Networks Confidential
2. If the standby SC detects that eight consecutive heart beats are missing from the active SC, it shoots the active SC. The time period between each heart beat is two seconds. 3. The complete DO-RNC is rebooted once the standby SC takes over and becomes the active SC. For RNC 2.2, the fully-loaded RNC reboot takes three-minutes to bring all cards to active state. After all cards are active, most of the DOMs home within average 30-seconds, and sector blossoming takes 25-seconds. Overall the typical expected total average timing from switchover to connection established is about 4-minutes. The SC works in conjunction with a hot swap controller (HSC) to bridge data between two independent bus systems further enhancing system reliability. This SC/HSC function is also fully redundant. Note in this example, the SC-A and HSC-A modules located in slot 7 and 10, respectively, together are the paired modules that required for supporting both C-PCI bus domains (domains A & B). Likewise, SC-B and HSC-B modules located in slot 8 and 9 are paired. The slot numbers for SC-A, HSC-A, SC-B and HSC-B are permanently assigned and can not be re-configured.
RNSM module redundancy
The DO-RNC distributes traffic across all provisioned RNSM modules in a load-sharing configuration. Should a RNSM module fail, the DOMs homed on that RNSM module will be rehomed on the remaining RNSMs (DOM homing on the DO-RNC on page 3-10) and all traffic will be redistributed across the remaining RNSM modules. In order to provision adequate capacity to sustain an RNSM module failure, an N+1 redundancy schedule is used.
BIO module redundancy
BIO module has domain N+1 redundancy. BIO is used as an interface to connect the DO-RNC with the DOMs and the PDSN. In the DO-RNC, if a BIO fails, all traffic will be re-distributed across the remaining BIO modules within the domain. If no BIO modules remain within the domain, the load will be distributed to the BIOs in the other domain. If a BIO module fails the sessions that are going through that particular module will get torn down and A10 will re-establish with a different card.
Hard disk
5
The hard disks have 1+1 redundancy. Each hard disk is associated with a SC card. For example: If SC7 (slot 7) is active and has a hard disk A and SC9 is standby with hard disk B. Both hard disks are synchronized with each other. In case of the failure of hard disk A, SC7 will switch to hard disk B without any service outage.
411-2133-514
Preliminary
03.06
October 2005
DO-RNC capacity
System controller module on page 6-1 Radio node server module on page 6-2 Basic input/output module on page 6-2 Compact peripheral component interconnect bandwidth on page 6-2
This section discusses the capacity of each module and card of the DO-RNC and the C-PCI bus bandwidth utilization.
System controller module
The system controller (SC) module controls the resource for the UATI and PSI number space. The assignable UATI number space is 261143 (from 1001 to 218-1). The PSI number space is 1 to 228, but the maximum number of RP sessions supported is the same as the number of 1xEV-DO sessions (160,000 per DO-RNC). The number of DOMs homed on the DO-RNC is also limited by the number of sockets available on the SC module. For software release 3.0 the number of DOMs that can be homed on the DO-RNC is up to 200 for primary home and up to 400 for primary and secondary home combined. The SC module does not get involved in data processing, therefore, the loading on the SC does not affect user throughput. The SC card is involved with session setup signaling and the session setup times could slightly increase as the SC loading increases. The load on the SC due to session setups is very low, however 20K session setups per hour result in about 5% CPU processing load on the SC. In practice, with current settings (54 hours session time-out) and current call models, we expect to see less than 4K session setups in a busy hour with 160K subscribers. This translates to about 1% SC loading due to session setup activity. The SC CPU occupancy is about 20-30% during log file uploads. As the total number of log files to be uploaded increases, the total time it takes to upload these files increases proportionally, but the CPU usages stays around 20-30% during the upload. Higher CPU utilization is expected during OM Data
CDMA
1xEV-DO 3.0
6-2 DO-RNC capacity Nortel Networks Confidential
Collection (OM data pushed from the NE to the DO-EMS). There is a dependency between the OM data collection and amount of time the processor is at an elevated level. Operators can monitor this CPU usage to the task level on the SC card by just typing show utilization task. For software release 2.2 the CPU utilization interval is set to 5 seconds as default. In other words, every time (every sampling interval; for example, every 30 seconds) the CPU utilization is sampled, it records the last 5 seconds average. This results in more spikes observed on the CPU usage. The CPU utilization interval is a configurable parameter. If it were set to 30 seconds, it would result in fewer spikes observed on the CPU usage. In the upcoming software releases (for example, Release 2.2) more flexibility is provided to the operator by making the averaging intervals and alarm trigger threshold parameters configurable.
Radio node server module
The data throughput of the radio node server module (RNSM) is about 28 Mbps including both the forward and the reverse throughputs. This is an engineering limit of 70% CPU loading. If 4:1 forward to reverse throughput ratio is assumed, then 22.4 Mbps corresponds to forward link throughput only. This does not mean that there is any hard processing budget split between forward and reverse. Theoretically, 28 Mbps forward and 0 reverse throughputs can be supported. However, the opposite mix (28 Mbps reverse, 0 Mbps forward) could likely not be supported, since it takes more CPU power to process a given bps in the reverse direction, since (typically) the packets are smaller. RNSM can support maximum of 20,000 DO sessions and 1500 active connections. The provisioning recommendation is 25 DOMs/RNSM based on if RNSM redundancy is not used and 29 DOMs/RNSM is RNSM (N+1) redundancy is used. This recommendation is based on CPU considerations. However, in worst-case RNSM (or DO-RNC) failure scenarios, this could result in 50 DOMs/RNSM and internal data structures and memory pools have been scaled to accommodate this maximum size.
Basic input/output module
Basic input/output (BIO) module is designed to handle two RNSM cards. The limit for BIO throughput is 100Mbps with 80% CPU loading. There are no constraints with respect to the number of sessions, connections or DOMs.
Compact peripheral component interconnect bandwidth

Figure 2-1 shows a logical diagram of the DO-RNC chassis. SC cards have their assigned slots and can not be re-configured. When allocating non-SC cards, they should be allocated symmetrically across the C-PCI domains in
DO-RNC capacity 6-3 Copyright 2004-2005 Nortel Networks
the DO-RNC chassis, (for example, put the first BIO/2RNSM set in the left side, the second set in the right side, the third set in the left side and the fourth set in the right side). This allows the most bus bandwidth headroom for each of the partial configurations. C-PCI bus is 64-bit * 33 MHz for each domain. Buses are intrinsically half-duplex (only one sender is active during a given transaction). Thus, a single BIO/RNSM transaction is 35-Mbit/s from BIO to RNSM and 35-Mbit/s back, resulting in total bus utilization of 70-Mbit/s, as an example.
CDMA
1xEV-DO 3.0
6-4 DO-RNC capacity Nortel Networks Confidential
411-2133-514
Preliminary
03.06
October 2005
DO-RNC OA&M
This section discusses the DO-RNC's OAM (operation, administration and maintenance) operation. The DO-RNC is managed by the DO-EMS and this section describes the type of traffic between the DO-RNC and the DO-EMS. DO-EMS and NE interface on page 7-1 DO-EMS to DO-RNC traffic on page 7-2 DO-RNC to DO-EMS traffic on page 7-3 Data collection on page 7-3
DO-EMS and NE interface
The interface between the DO-EMS and the network element (NE) consists of the following: XML over httpfor full status polling, configuration and synchronization activities (medium volume traffic, performed periodically) SNMPquick polling and live data graph and charts activities. (light volume traffic, not a daily operation) FTPfor SW images and configuration upload. (light volume traffic, only needs to be done occasionally) and log and debug file transfer from NEs to DO-EMS (medium volume traffic) TCPfor periodic data collection of items like performance statistics (heavy volume traffic)
In addition, a telnet interface is provided for remote access to the commandline interface. Prior to Release 2.2, each NE was added to DO-EMS using its Node IP Address. The Node IP address is the IP address configured on the Virtual Node Interfacenode1/0/1. DO-EMS used the Node IP Address as the primary IP address identifying each NE. All communication between DOEMS and the NE used the NE Node IP Address.
CDMA
1xEV-DO 3.0
7-2 DO-RNC OA&M Nortel Networks Confidential
Starting from Release 2.2, the Management IP Address is fully supported on the DO-RNC. The Management IP address is the IP address configured on the Virtual Management Interface-mgmt1/0/1. The Management IP Address can be used optionally as the primary IP address by which the DO-RNC is added to DO-EMS. Because the Management IP Address is not used for other purposes (such as Abis communications), this allows for the following: Cleaner IP network design with an IP address that is dedicated for DORNC management only Optional out-of-band management of the DO-RNC
DO-EMS to DO-RNC traffic
This includes traffic between DO-EMS and DO-RNC such as XML, SNMP and FTP. Since a minimum volume of traffic flows from the DO-EMS to the DOM, this won't present a problem. An exception is during an FTP transfer. This should not be a problem, for the following reasons: This occurs during software download and should be a rare occurrence. It is expected that software upgrades will be performed during maintenance windows. It is expected that the router will be able to classify and de-prioritize FTP traffic over regular data traffic on the backhaul, based on the DiffServ marking in the packet headers. Packets transmitted by the DO-EMS require the nearest router to classify them and mark them with the appropriate DSCP. Packets transmitted out of the DO-RNC will have their DiffServ code points set to values based on the type of traffic. This allows traffic prioritization to be maintained by third party routers in the backhaul and R-P networks.
In the forward direction, the main DO-EMS activities are as follows: Periodic status polling data polling alarm polling quick polling Data and alarm synchronizations data synchronization alarm synchronization Software image download using FTP
411-2133-514
Preliminary
03.06
October 2005
DO-RNC OA&M 7-3 Copyright 2004-2005 Nortel Networks
For DO-EMS generated traffic, the assumption is that an intervening router will classify and mark packets based on a multi-field classifier. Therefore, DO-EMS critical traffic will always be prioritized and marked with a higher priority DiffServ code point than non-critical traffic. The priority of DO-EMS critical traffic will also be higher than that of signaling and data marked by the network elements, while the non-critical DO-EMS traffic's priority will be lower than those marked for user and signaling traffic.
DO-RNC to DO-EMS traffic
This includes traffic between DO-RNC and DO-EMS such as XML, SNMP and FTP. For all of these, traffic is forwarded over the same T1/E1 link. Since the bandwidth requirement for this type of data is small, this shouldn't present a problem. Exceptions to this are the upload of large log files via FTP and periodic upload of operational measurements (OMs). The DO-RNC will classify, de-prioritize and mark these traffic types over regular data traffic and critical OA&M traffic. It is expected that the intervening routers will be able to do the same using either the DSCP or multi-field classification. In the reverse direction, the main DO-EMS activities are as follows: Periodic status polling data polling alarm polling quick polling Data and alarm synchronizations data synchronization alarm synchronization SNMP traps Performance data collection Getting log data using FTP
Data collection
Operational measurements (OMs) are collected periodically using the data collection mechanism implemented by a data collection agent on the network element. The OMs are described in CDMA 1xEV-DO Performance Measurements Reference, 411-2133-924. The data collection agent is responsible for collecting the data for specified attributes (OIDs) of a network device and sending it to the DO-EMS. Thus, all OM identifiers must be specified in the MIB. The data collection configuration manager initializes the data collection agent in a network element when it is discovered by the DO-EMS. It uses specific buffers for each data collection configuration.
7-4 DO-RNC OA&M Nortel Networks Confidential
Depending on parameters like: sampling rate and buffer size, the data collection agent uses one or more buffers to collect the data. Whenever a specified criterion is met like buffer is full or specified time is elapsed, the data collection agent sends the data to DO-EMS using an HTTP POST request or a socket connection. After sending the data successfully, it empties the buffer and continues the data collection into the same buffer. It also supports backup of the collected data in case any failures in pushing the data to the DO-EMS. It stores the data as disk files to the flash. It also regularly checks for any such file(s) and tries to push the data to DO-EMS.
411-2133-514
Preliminary
03.06
October 2005
A-1 Copyright 2004-2005 Nortel Networks
Appendix: A12 Messages

The A12 interface consists of the following RADIUS messages: Access-Request Access-Accept Access-Reject
This chapter contains the following information: Radius message format on page A-2 Code field on page A-2 Identifier field on page A-2 Length field on page A-2 Authenticator field on page A-3 Access-Request attributes on page A-3 Access-Accept attributes on page A-5 Access-Reject attributes on page A-5
CDMA
1xEV-DO 3.0
A-2 Appendix: A12 Messages Nortel Networks Confidential
Radius message format

The RADIUS messages format is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Authenticator | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code field
The Code field is one octet, and identifies the type of RADIUS packet. When a packet is received with an invalid Code field, it is silently discarded. RADIUS Codes (decimal) for A12 interface are assigned as follows: 1. Access-Request 2. Access-Accept 3. Access-Reject
Identifier field
The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server detects a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.
Length field
The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field is treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it is silently discarded. The minimum length is 20 and maximum length is 4096.
Appendix: A12 Messages A-3 Copyright 2004-2005 Nortel Networks
Authenticator field
The Authenticator field is 16 octets. The most significant octet is transmitted first. This value is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. Request Authenticator In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. The value is unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. The Request Authenticator field is exhibit global and temporal uniqueness since it is expected that the same secret may be used to authenticate with servers in disparate geographic regions. The Request Authenticator value in an Access-Request packet is unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access-Request. Although protocols such as RADIUS are incapable of protecting against theft of an authenticated session by real time active wiretapping attacks, generation of unique unpredictable request authenticator values may protect against a wide range of active attacks against authentication. Response Authenticator The value of the Authenticator field in Access-Accept, and Access-Reject packets is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Access-Request packet, and the response Attributes, followed by the shared secret. That is,
ResponseAuth=MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + denotes concatenation
RADIUS attributes carry the specific authentication, authorization, information and configuration details for the request and reply. The RNC sends the following RADIUS attributes in the A12 interface messages.
Access-Request attributes
User-Name Type: 1 (decimal) Length: >=3 (decimal)
CDMA
1xEV-DO 3.0
Value: string It contains the Network Access Identifier (NAI). CHAP-Password Type: 3 (decimal) Length: 19 (decimal) Value: ID + string It contains 1-octet CHAP-ID plus 16-octets CHAP-Response. NAS-IP-Address Type: 4 (decimal) Length: 6 (decimal) Value: 4 (octets) It contains node IP address of RNC. CHAP-Challenge Type: 60 (decimal) Length: >=7 (decimal) Value: string Vendor-Specific: HRPD Access Authentication Type: 26 (decimal) Length:12 (decimal) Value: N/A Vendor-ID: 5535 (decimal) Vendor-Type: 60 (decimal) Vendor-Length: 6 (decimal) Vendor-Value:1 (decimal)
411-2133-514
Preliminary
03.06
October 2005
Appendix: A12 Messages A-5 Copyright 2004-2005 Nortel Networks
Any extra attribute will be silently ignored by the RNC and the remaining messages will be processed.
Access-Accept attributes
Callback-ID Type: 20 (decimal) Length: >=3 (decimal) Value: string It contains a 16 ASCII character string. The first character is the MN_ID_Type set to 0 indicating a type of IMSI. The following 15-characters contain the decimal digits of the IMSI encoded as ASCII. When interoperating with a Nortel 1x packet network, the leading 5-digits are set to 00000 followed by the 10-digit MIN used in 1x. The Callback-ID containing the IMSI is a REQUIRED attribute. If the RNC does not get an IMSI, it can not go any further in the session setup. So, if the IMSI is not in the Access Accept message then, RNC will 1) flag the message as being MALFORMED; 2) update the A12 MALFORMED Message OM; 3) send back a CHAP failure to the AT; 4) close the DO session. Any extra attribute are silently ignored by the RNC and the remaining messages are processed.
Access-Reject attributes
Any attribute in Access-Reject are silently ignored by the RNC and the remaining Access-Reject messages are processed.
CDMA
1xEV-DO 3.0
411-2133-514
Preliminary
03.06
October 2005
B-1 Copyright 2004-2005 Nortel Networks
Acronyms
1xEV-DO 1x Evolution Data Only ACH Access Channel AN Access Network see RAN AT Access Terminal BIO Basic Input/Output BSC Base Station Controller BTS Base Transceiver Station CCH Control Channel CLI Command Line Interface CN Core Network C-PCI Compact PCI see PCI CPU Central Processing Unit
CDMA 1xEV-DO DO-RNC Theory of Operations
1xEV-DO 3.0
B-2 Acronyms Nortel Networks Confidential
DC Data Collection DOM Data only module same as RN EMS Element Management System FTC Forward Traffic Channel FTP File Transfer Protocol GRE Generic Routing Encapsulation HRPD High Rate Packet Data IP Internet Protocol MIB Management Information Base NAT Network Address Translation NE Network Element OAM Operations, Administration and Maintenance OID Object Identifier OM Operational Measurement PCF Packet Control Function
411-2133-514
Preliminary
03.06
October 2005
Acronyms B-3 Copyright 2004-2005 Nortel Networks
PCI Peripheral Component Interconnect PDSN Packet Data Serving Node RAN Radio Access Network RN Radio Node RNC Radio Network Controller RNSM Radio Node Server Module same as SM RTC Reverse Traffic Channel SC System Controller SDU Selection/Distribution Unit SM Server Module abbreviation for RNSM SNMP Simple network Management Protocol TCP Transport Control Protocol TE Terminal Equipment XFH eXtended Frame Header XML eXtensible Markup Language
CDMA
1xEV-DO 3.0
B-4 Acronyms Nortel Networks Confidential
411-2133-514
Preliminary
03.06
October 2005
test
Family Product Manual Contacts Copyright Confidentiality Legal
CDMA
1xEV-DO DO-RNC
To order documentation from Nortel Networks Global Wireless Knowledge Services, call (1) (877) 662-5669 To report a problem in this document, call (1) (877) 662-5669 or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at http://www.nortel.com/td Copyright 2004-2005 Nortel Networks, All Rights Reserved
NORTEL NETWORKS CONFIDENTIAL

The information contained herein is the property of Nortel Networks and is strictly confidential. Except as expressly authorized in writing by Nortel Networks, the holder shall keep all information contained herein confidential, shall disclose it only to its employees with a need to know, and shall protect it, in whole or in part, from disclosure and dissemination to third parties with the same degree of care it uses to protect its own confidential information, but with no less than reasonable care. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. * Nortel Networks, the Nortel Networks logo, the Globemark, and Unified Networks are trademarks of Nortel Networks. CDMA2000 is a trademark of Telecommunications Industry Association (TIA). CDMA2000 1X is a trademark of the CDMA Development Group. Internet Explorer is a registered trademark of Microsoft Corporation. Netscape is a registered trademark of Netscape CommunMotorola 750 Power PC is a trademark of Motorola.Solaris, Sun, Sun Fire, Sun StorEdge, and Ultra Enterprise are trademarks or registered trademarks of Sun Microsystems, Inc. VxWorks is a trademark of WindRiver.All other trademarks are the property of their respective owners. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document. Document number: 411-2133-514 Product release: 1xEV-DO 3.0 Document version: Preliminary 03.06 October 2005 Originated in the United States of America/Canada

NT-CDMA 1xEV-DO DO-RMC Theory of Operations

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NT-CDMA 1xEV-DO DO-RMC Theory of Operations

Uploaded by

Copyright:

Available Formats

411-2133-514

Copyright Country of printing Confidentiality Legal statements Trademarks

ii Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

Nortel Networks Confidential

iii Copyright 2004-2005 Nortel Networks

1xEV-DO DO-RNC Theory of Operations

iv Publication history Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

Nortel Networks Confidential

v Copyright 2004-2005 Nortel Networks

DO-RNC hardware architecture

DO-RNC software architecture

1xEV-DO DO-RNC Theory of Operations

vi Contents Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

End-to-end call flow

Nortel Networks Confidential

Contents vii Copyright 2004-2005 Nortel Networks

Appendix: A12 Messages

1xEV-DO DO-RNC Theory of Operations

Nortel Networks Confidential

ix Copyright 2004-2005 Nortel Networks

About this document

Audience for this document

Organization of this document

Indication of hypertext links

1xEV-DO DO-RNC Theory of Operations

x About this document Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

Nortel Networks Confidential

About this document xi Copyright 2004-2005 Nortel Networks

1xEV-DO DO-RNC Theory of Operations

xii About this document Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

Nortel Networks Confidential

1-1 Copyright 2004-2005 Nortel Networks

1xEV-DO DO-RNC Theory of Operations

1-2 Introduction Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

1xEV-DO network configuration

CDMA2000 1xEV-DO Network

CDMA2000 1xEV-DO User Me etro Ce Cell BTS S

Home Agent (HA)

Carrier's Private Data Network

Packet Data Network P PDSN

1 1/E OT l u V-D 1xE ackha B

D DO-RNC CDMA2000 1xEV-DO User SCS (Shasta OAM) DO-EMS Client

D DO-EMS AN-AAA/ AAA (RADIUS)

Me etro Cell BTS

CDMA2000 1X Network CD DMA2000 1xEV-DO Network

Nortel Networks Confidential

Introduction 1-3 Copyright 2004-2005 Nortel Networks

1xEV-DO protocol overview

Figure 1-2 Protocol view of 1xEV-DO user plane

PPP GRE IP Ethrenet 100 B-TX

Ethernet 100 B-TX

MAC... GRE IP PPP T1/E1 Ethernet 100 B-TX

IP Ethernet 100 B-TX

PDSN A10 transport network

1xEV-DO DO-RNC Theory of Operations

1-4 Introduction Nortel Networks Confidential

Copyright 2004-2005 Nortel Networks

Nortel Networks Confidential