nt-cdma 1xev-do do-rmc theory of operations

7/29/2019 NT-CDMA 1xEV-DO DO-RMC Theory of Operations

1/108

CDMA

1xEV-DO DO-RNCTheory 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

411-2133-514


2/108

test


3/108

CDMA

1xEV-DO DO-RNCTheory of Operations

Document number: 411-2133-514Product release: 1xEV-DO 3.0Document 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 par ties 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 r ights 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.


4/108

iiNortel Networks Confidential Copyright 2004-2005 Nortel Networks

411-2133-514 Preliminary 03.06 October 2005


5/108

iiiNortel Networks Confidential Copyright 2004-2005 Nortel Networks

CDMA 1xEV-DO DO-RNC Theory of Operations 1xEV-DO 3.0

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 DO-RNC Theory of Operations.

1xEV-DO 3.0, Draft 03.04. Added standard references to About thisdocument.

August 2005

1xEV-DO 3.0, Draft 03.03. Corrected Unsuccessful prior A13 dormanthandoff 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.


6/108

iv Publication historyNortel Networks Confidential Copyright 2004-2005 Nortel Networks


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

Reverse link data flow SC Module

RNSM module

C-PCI bandwidth

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 20041xEV-DO 2.2, Draft 02.01. Changed version and added minor editorialchanges.

October 2004

1xEV-DO 2.1, Standard, 01.04. Reformatted per Nortel standards.

September 2004

1xEV-DO 2.1, Standard, 01.03. Added CDMA Theory of Operations.

August 2004

1xEV-DO 2.1, Preliminary, 01.02. Made minor changes to text andformatting.

August 2004

1xEV-DO 2.1, Preliminary, 01.01. This is the first release of thisdocument.


7/108

vNortel Networks Confidential Copyright 2004-2005 Nortel Networks


Contents 1

About this document ixAudience for this document ix

Organization of this document ixIndication of hypertext links ixRelated documents x

Introduction 1-11xEV-DO network configuration 1-21xEV-DO protocol overview 1-3

DO-RNC hardware architecture 2-1Hardware architecture overview 2-2

DO-RNC hardware modules 2-2System controller module 2-3Hot swap controller module 2-3

Base I/O module 2-3Radio network server module 2-3

Power supply 2-4Alarm panel 2-4

Hard disk 2-4C-PCI bus 2-4DO-RNC external interfaces 2-5

DO-RNC software architecture 3-1Software architecture overview 3-2

Fast path and slow path 3-2System services 3-3

Protocol stack 3-3Physical interfaces 3-3

Ethernet interface 3-3

System controller daughter card Ethernet interface 3-4Serial port driver 3-4

System bus driver 3-4Link layer 3-4

TCP/IP 3-5IP routing table 3-5

Socket interface 3-6


8/108

vi ContentsNortel Networks Confidential Copyright 2004-2005 Nortel Networks


System controller board 3-6Resource control 3-6

PCF functionality 3-6System management 3-9SNTP timing functionality 3-9

DO-RNC reset mechanism 3-10DOM homing on the DO-RNC 3-10

Radio network server module (RNSM) board 3-12Call control 3-12

Resource control 3-16BTS manager 3-16BTS mapping table 3-17

PCF functionality 3-17Selection and distribution unit 3-18

1xEV-DO layer processing 3-18Abis signaling 3-19

Abis data processing 3-19A13 interface protocol 3-20

Terminal authentication 3-21AN-AAA selection mechanism 3-23Operation without terminal authentication 3-24

Base I/O (BIO) board 3-26IP forwarder 3-26

Abis data demux processing 3-27A10 demux processing 3-27Address translator 3-28

End-to-end call flow 4-11xEV-DO Signaling flow 4-1

Data call setup flow 4-2

Session setup flow with A10 connection minimization 4-4AT originates 1xEV-DO sessionunsuccessful terminal authentication 4-6Connection setup/open flow 4-7

Connection establishmentAN initiated, fast connect 4-9Connection close flow 4-11Reverse soft/softer handoff call flow 4-13

Sector switching 4-15Inter DO-RNC dormant handoff without A13 support 4-17

Successful regular A13 dormant handoff 4-19Unsuccessful regular A13 dormant handoff 4-22

Successful prior A13 dormant handoff 4-23Unsuccessful prior A13 dormant handoff 4-25Inter RNC active handoff using multi-homing 4-27

Inter-technology handoff call flow 4-291xEV-DO Data flow 4-30

Forward link data flow 4-30Reverse link data flow 4-32


9/108

Contents viiNortel Networks Confidential Copyright 2004-2005 Nortel Networks


DO-RNC redundancy 5-1DO-RNC redundancy model 5-1

System controller module redundancy 5-1RNSM module redundancy 5-2

BIO module redundancy 5-2Hard disk 5-2

DO-RNC capacity 6-1System controller module 6-1

Radio node server module 6-2Basic input/output module 6-2

Compact peripheral component interconnect bandwidth 6-2

DO-RNC OA&M 7-1DO-EMS and NE interface 7-1

DO-EMS to DO-RNC traffic 7-2

DO-RNC to DO-EMS traffic 7-3Data collection 7-3

Appendix: A12 Messages A-1Radius message format A-2Code field A-2Identifier field A-2

Length field A-2Authenticator field A-3

Request Authenticator A-3Response Authenticator A-3

Access-Request attributes A-3Access-Accept attributes A-5Access-Reject attributes A-5

Acronyms B-1

FiguresFigure 1-1 1xEV-DO network configuration 1-2

Figure 1-2 Protocol view of 1xEV-DO user plane 1-3Figure 2-1 Logical diagram of a fully loaded DO-RNC 2-2

Figure 2-2 DO-RNC external interfaces 2-5Figure 3-1 DO-RNC software architecture 3-2

Figure 3-2 Terminal authentication model 3-23Figure 4-1 1xEV-DO Data call setup flow diagram 4-2

Figure 4-2 1xEV-DO session setup flow with A10 connection minimization 4-4Figure 4-3 Initial AT originationunsuccessful terminal authentication 4-6Figure 4-4 1xEV-DO Connection setup flow diagram 4-7

Figure 4-5 1xEV-DO fast connect setup flow diagram 4-9Figure 4-6 1xEV-DO connection close flow diagram 4-11

Figure 4-7 1xEV-DO reverse soft/softer handoff call flow diagram 4-13Figure 4-8 1xEV-DO sector switching flow diagram 4-15


10/108

viii ContentsNortel Networks Confidential Copyright 2004-2005 Nortel Networks


Figure 4-9 1xEV-DO inter DO-RNC dormant handoff without A13 flowdiagram 4-17

Figure 4-10 Successful regular A13 dormant handoff call flow diagram 4-19Figure 4-11 Unsuccessful regular A13 dormant handoff call flow diagram 4-22Figure 4-12 Successful prior A13 dormant handoff call flow diagram 4-23

Figure 4-13 Unsuccessful prior A13 dormant handoff call flow diagram 4-25Figure 4-14 Inter RNC active handoff call flow diagram 4-27

Figure 4-15 Inter-technology dormant handoff flow diagram 4-29Figure 4-16 1xEV-DO data flow diagram 4-30

Figure 4-17 1xEV-DO Reverse link data flow diagram 4-32

TablesTable 3-1 Conversion table to map the most significant 8-bits of the ESN 3-25


11/108

ixNortel Networks Confidential Copyright 2004-2005 Nortel Networks


About this document 1

This document briefly describes the architecture of different modules of theDO-RNC and how these modules interact with each other in order to establisha data call. Various call flow scenarios are also discussed. The document alsodescribes the capacity of different modules in the DO-RNC and identifies thebottlenecks. 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 1This guide is intended for individuals responsible for planning thedeployment of a CDMA 1xEV-DO network. It can also be used inconjunction with the CDMA 1xEV-DO Deployment Planning, 411-2133-932,and other related configuration tools. The reader should have a baseunderstanding of 1xEV-DO technology and data network practices.

Organization of this document 1This 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 1

Hypertext links in this document are indicated in blue. If viewing a PDFversion of this document, click on the blue text to jump to the associatedsection or page.


12/108

x About this documentNortel Networks Confidential Copyright 2004-2005 Nortel Networks


Related documents 1 CDMA Release Delta for 1xEV-DO 2.2 to 3.0, 411-2133-109. This

document describes new and changed managed objects Logs, operationalmeasurements and alarms.

CDMA 1xEV-DO System Overview, 411-2133-012. This documentcontains high-level descriptions of all nodes new to 1xEV-DO.

CDMA 1xEV-DO DO-EMS Software Installation, 411-2133-126. Thisdocument contains DO-EMS licensing information and explains thesoftware and hardware requirements. It also describes how to install theDO-EMS server software, including guidelines for installing the Oracle*and VERITAS software required to support the DO-EMS, in the eventthere is a need to reinstall the DO-EMS to recover from a catastrophicsystem failure.

CDMA 1xEV-DO DO-EMS Administration, 411-2133-529. Thisdocument is written for system administrators responsible for maintainingthe 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 InformationGuide, 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 NortelNetworks 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 anddescribes 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 informationfor CDMA 1xEV-DO.

CDMA 1xEV-DO Performance Measurements Reference, 411-2133-924.This document assists Network Engineering teams in determining CDMA1xEV-DO network performance. Formulas needed to derive variousperformance metrics such as session setup, paging, and resourceallocation 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 everyCLI command.

CDMA 1xEV-DO Logs Reference, 411-2133-926. This documentdescribes all log messages and explains what each message means,suggests possible causes, and provides guidelines for responding to eacherror message.


13/108

About this document xiNortel Networks Confidential Copyright 2004-2005 Nortel Networks


CDMA 1xEV-DO Using the DO-EMS Interface, 411-2133-927. Thisdocument describes how to use the DO-EMS to manage the IP-RAN.Documents all DO-EMS functions, except those performed by the DO-EMS server administrator. This NTP was previously titled CDMA 1xEV-DO EMS User Interface.

CDMA 1xEV-DO Operational Configuration Tools, 411-2133-929. Thisdocument describes how to generate scripts with the two tools used tocreate per-network element configuration scripts: the Merge Tool and theScript Generation Tool. It explains where these tools fit into the IP-RANdeployment process, how they interact with other planning tools and theplanning process, what input files are required to use these tools, theformat of the input files, and how the tools are used to generateconfiguration scripts for network elements.

CDMA 1xEV-DO Deployment Planning, 411-2133-932. This documentis a high-level engineering planning guide that covers RF planning and

network-architecture planning to help operators plan to deploy a NortelIP-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 InterfaceSpecification, 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), June2000.

3GPP2 A.S0008-0 v3.0 (TIA-878-1),Interoperability Specification (IOS)for High Rage Packet Data (HRPD) Access Network Interface, May 2003.


14/108

xii About this documentNortel Networks Confidential Copyright 2004-2005 Nortel Networks



15/108

1-1

Nortel Networks Confidential Copyright 2004-2005 Nortel Networks


Introduction 1

This chapter contains the following information:

1xEV-DO network configuration on page 1-2

1xEV-DO protocol overview on page 1-3


16/108

1-2 IntroductionNortel Networks Confidential Copyright 2004-2005 Nortel Networks


1xEV-DO network configuration 1A high level overview of the 1xEV-DO architecture is presented inFigure 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 throughthe IP network.

Figure 1-11xEV-DO network configuration

CDMA2000 1xEV-DO Network

tro CellMeBTS

-

DMA2000 1xEV-DO NetworkC

CDMA2000 1X Network

DSNP

Home Agent (HA)when de Mobile IP

AN-AAA/

AAA(RADIUS)

M

BSC

tro CellMeBTS

CDMA20001xEV-DO

User

O T1/E1

1xEV-

Backha

u

1xEV-DOT1/E

1

BackhaulCDMA2000

1X User

CDMA20001X User

CDMA20001xEV-DO

User

DO-EMSClient

SCS (ShastaOAM)

O-RNCD

ML

BSSMManager

M

Carrier's

Private Data

Network

PacketData

Networ


17/108

Introduction 1-3Nortel Networks Confidential Copyright 2004-2005 Nortel Networks


1xEV-DO protocol overview 1Figure 1-2 shows the Protocol stacks for the user plane between differentnodes in the network. IP packets are exchanged between the TE (terminalequipment 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 andPDSN 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-2Protocol view of 1xEV-DO user plane

IP host

PPP

USB orserial

USB orserial

relay

RLP

MAC

1xEV-DOLayer 1

1xEV-DOLayer 1

relay

relay

MA ...

IP routing

100 B-TX

Ethernet

TerminalEquipment

- PC hardware

AccessTerminal

DOM IP Router DO-RNC

PDSN

R

B-T

R

Ethrene

B-TR

1/E

Ethernet

B-T1/E

R

Ethernet

B-T

ABIStransportnetwork

A10transportnetwork


18/108

1-4 IntroductionNortel Networks Confidential Copyright 2004-2005 Nortel Networks



19/108

2-1



DO-RNC hardware architecture 2


Hardware architecture overview on page 2-2

DO-RNC hardware modules on page 2-2


20/108

2-2 DO-RNC hardware architectureNortel Networks Confidential Copyright 2004-2005 Nortel Networks


Hardware architecture overview 2The BIO, RNSM and SC modules are all based on the Motorola 750 PowerPC. The BIO and RNSM modules are identical and only differentiated bysoftware 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 2The DO-RNC consists of a 16-slot Motorola NEBS compliant chassiscontaining 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

BB


21/108

DO-RNC hardware architecture 2-3Nortel Networks Confidential 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 MPC750responsible for routing protocols, system configuration, networkmanagement, and centralized signaling activities. The SC runs the TCP/IPprotocol stack over Ethernet to communicate on the management interfacesand over a backplane bus layer to communicate with the RNSM and BIOmodules. There are two serial connectors for the local management (CLIinterface) with the SC/RNC. On the front panel of the SC, there is a DB9connector and on the rear transition module there is a RJ-45 interface. Onlyone 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 inSystem controller module redundancy on page 5-1). Hence, two per chassis inthe redundant configuration, occupies four slots with the required hot swap

controller (see Figure 2-1). DO-RNC chassis has slots 7 and 9 reserved fortwo SC modules.

Hot swap controller module

The hot swap controller (HSC) module is only a rear transition module in theDO-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 workswith the SC in slot 9. HSC module helps the SC during switch over and alsoprovides a bridge between two domains in the DO-RNC chassis as shown inFigure 2-1.

Base I/O moduleThe base I/O (BIO) module on the DO-RNC contains a 450MHz (or 500MHz) MPC750 supporting two 100BaseT ports using a rear TransitionModule. It runs the TCP/IP protocol stack over Ethernet for communicationwith the PDSN and the backhaul network (connected to the DOMs). TheDO-RNC supports up to 4 BIO modules. Placement of the BIO modules isrestricted to slots 1, 2, 11 and 12.

When physically connecting the DO-RNC to the access network, it isrecommended that it be configured in such a fashion that each BIO interfacebe provisioned to talk to both the RAN and PDSN. This approach leads to

better distribution of processing load across BIOs in that the asymmetricforward and reverse link loads will balance when combined in oppositedirections on the BIO.

Radio network server moduleThe radio network server module (RNSM) on the DO-RNC contains a450MHz (or 500 MHz) MPC750 responsible for terminating the signaling


22/108



and data plane components of the 1xEV-DO protocol. The DO-RNC supportsup to eight RNSM modules. Placement of the RNSM modules is restricted toslots 3, 4, 5, 6, 13, 14, 15, and 16.

Note: Unlike the BIO module, the RNSM module does not require a reartransition module.

Power supplyThe DO-RNC can be configured to support either AC or DC power using adifferent type of power distribution panel and power supply modules. Thepower supplies have auto-ranging capability, supporting a wide range ofvoltages. Nortel Networks supports only DC power supply.

DC power modeIn this mode, the DO-RNC supports dual input DC power for maximumredundancy. Voltage range of 36 Vdc to 72 Vdc is supported. The power

supplies are fully hot swappable and supporting N+1 redundant capability.

Alarm panelThere is an alarm panel located on the front of the DO-RNC chassis. Thealarm panel contains three system status LEDs, three Telco alarm statusLEDs, two slot status LEDs for each slot, and an RJ-45 connector for Telcoalarm status output to an external interface.

Hard diskThe hard disk on the DO-RNC is a standard IDE drive. Each SC module hasan 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, andthat's the basic topology of the hardware: there are 2 PCI domains, with abridge joining them. Figure 2-1 shows a logical diagram of the DO-RNCchassis.


23/108

DO-RNC hardware architecture 2-5Nortel Networks Confidential Copyright 2004-2005 Nortel Networks


DO-RNC external interfaces

Figure 2-2 shows the DO-RNC external interfaces. The DO-RNCscommunicate with the radio nodes and the PDSNs through a network usingmultiple 100Mb Ethernet links. The same Ethernet link can be connected to

both the packet core (PDSN) and the radio networks. The interface to theDOMs uses a proprietary IP Abis protocol while the interface to the PDSNs isvia a standard R-P interface as defined in 1xEV-DO TIA-878 standard. Whenco-located, the DO-RNC can be connected to the PDSN directly using theEthernet interface. Alternatively, when the PDSN is remote, an externalrouter can be used.

Figure 2-2

DO-RNC external interfaces

RNC

Radio Network

InterfaceCore Networ

Interface

DC Power

Craft Interface

ManagementInterface

(on daughter card)

100 Base T

RS-232

N

100 Base T

M

100 Base T


24/108




25/108

3-1



DO-RNC software architecture 3


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


26/108

3-2 DO-RNC software architectureNortel Networks Confidential Copyright 2004-2005 Nortel Networks


Software architecture overview 3The data only radio network controller (DO-RNC) software architecture isdistributed among several board types: the System Controller (SC), the radionetwork server module (RNSM) boards and the base I/O (BIO) boards. The

function of each module and the software components and servicesimplemented by each module are described.

Figure 3-1 shows the high-level architecture for various modules in theDO-RNC.

Figure 3-1DO-RNC software architecture

Fast path and slow path

BIO and RNSM modules have fast path and slow path components. The fastpath component is a separate task with the task priority being higher than allother application tasks but lower than that of some system tasks likewatchdog timer, etc. The fast path task can tie up the CPU for up to 80% ofthe execution time, provided there are packets/events to be processed.

-P

BIO

IP Forwarder

A Interface Demux

Bus DriverNet i/fDriver

RT

OS

SY

STEM

S

ERVIC

ES

Fast Path

Slow Path

Physical LayerDevice Driver

Protocol Stack

TableDistribution

SM

Fast Path

Slow Path

RTO

S

SY

STE

M

SER

VICE

S

Bus Driver

Abis Data

SDU

1xEV-DO LayerProcessing

PCF(GRE)

RLP

1xEV-DO LayerProcessing

SLP

Protocol Stack

Abis Signaling

Call Control

ResourceControl

MappingTable

Distributor

Active SC

Resource

Control

PCF

Protocol StackSystem Services

A11

Standby SC


27/108

DO-RNC software architecture 3-3Nortel Networks Confidential Copyright 2004-2005 Nortel Networks


Fast path can be conceptually viewed as a layer between the driver moduleand the upper layer functions. The fast path receives packets from devicedrivers 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 theappropriate 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 levelof the slow path tasks as they have opportunity to run and process their inputqueue.

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 slowpath process packets that are to be locally terminated rather than forwarded toanother card/system. Each of these tasks may have its own priority as long asall such tasks are at a lower priority than the fast path task.

System servicesThe 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 ofthe services provided by VxWorks. Examples of system services areinter-process communication, event notification, timer services and memorymanagement.

Protocol stackThe 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 3The 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 interfaceThe system controller (SC) has a 10/100Mbps Ethernet port used forredundancy support. A cross-over cable between the active SC and thestandby SC carries heartbeat signals between the two cards. If the heartbeat is


28/108



lost, the standby SC will shoot the active SC and reboot the DO-RNC. Itessentially means that it will force the card for a hardware reset (with thepresumption that card is in some kind of hung state); see System controllermodule redundancy on page 5-1 for more details.

System controller daughter card Ethernet interfaceThe SC also supports the use of a PMC daughter card which provides anadditional 10/100 Mbps Ethernet port. Starting in Release 2.2, this port can beused to manage the system. Management packets arriving on the Ethernet arepassed by the driver to the link layer and ultimately to the IP protocols andapplications. The Ethernet port is configured with an IP address, eitherthrough the CLI or the DO-EMS.

Serial port driverThe SC supports one RS232 serial port for managing and debugging thesystem. 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 driverThe system-bus driver represents the physical connection to other boards inthe system. All interprocessor communications across the PCI bus formessaging between various processors use IP as the networking layerprotocol using the unique per processor IP address.

Link layer 3The link layer provides an interface between the network protocols and thedevice drivers. Interface objects are created to provide a representation of

physical and virtual interfaces. These interfaces have the ability to be stackedon top of each other to represent a particular protocol stack. An interfaceobject is used to transmit internally generated packets as well as receivepackets returned by Fast Path processing.

Applications that generate packets internally will use the appropriate interfaceobject to transmit the packet. These applications will hold a reference to theinterface object. For example, when an interface is configured with an IPaddress, the router will send out a router announcement. The router willcreate and transmit the packet out through the newly configured interface bycalling the object's transmit method. Any needed encapsulation will be addedas the packet gets delivered to the physical device.

When a packet is returned from the fast path to the slow path for localdelivery processing (i.e. signaling, ICMP, SNMP, HTTP, TELNET, FTP, etc.),the packet is posted to the Slow Path packet engine. The packet engine willcall the physical interface object to return the packet. The packet willpropagate up the interface stack, removing any encapsulation on the way to


29/108



the interface owner. The owner, for instance, could be the IP stack for localmanagement.

The link layer also provides for link state propagation. Callback support willexist to provide applications with link or operational status callbacks.

TCP/IP 3The DO-RNC runs a standard TCP/IP protocol stack, sourced from WindRiver and fully integrated with VxWorks. The stack will run in thebackground on all boards in the system, allowing for maximum distribution ofIP application processing. On the SC, the TCP/IP stack receives managementpackets from either the serial port or forwarded over the system bus from oneof the BIOs. It receives A11 signaling packets only via the system bus fromone 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 staticallyassigned an IP address. The address utilizes the standard IP loopback address127, as well as the chassis, slot and processor number. The format of the IPaddress is: 127.chassis#.slot#.processor#. For example, if the SC is in slotnumber 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 thisaddress are never transmitted externally. This addressing scheme supportsinterprocess communication within and across boards.

Each external interface in the DO-RNC is assigned an IP address. The addressis 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 sourceaddress 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 onwhich it is being transmitted. The task of performing the translation is doneby the address translator (please see Address translator on page 3-28).

In addition, the address translator must modify the destination IP address ofreceived packets to that of the destination board.

IP routing tableThe IP routing table is populated with IP addresses for the forwarding of IPdatagrams.

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


30/108



exists in the routing table (through configuration or learned through RIP), it isused to route IP packets for which no specific route is found in the routingtable. The routing table built and maintained on the SC is the master routingtable for the DO-RNC. The routing table information is distributed to all theother boards on the system.

Socket interface 3The socket interface implements the standard Berkeley socket interface. Itprovides a generic, industry standard interface for applications to use whenaccessing networking protocols. Initially, sockets can be created for usingTCP, UDP, IP or the distribution protocol. The distribution frameworkprovides mechanisms to handle dynamic loading, creation and removal ofcomponents, and remote procedure calling. The socket interface can easily beextended to support any network protocols implemented in the future.

System controller board 3The system controller (SC) is responsible for the following system-levelfunctionalities:

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 controlIn the DO-RNC, there are two levels of resource control: SC-level andRNSM-level. Currently, the 1xEV-DO session number (UATI) number spaceand 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 cardsPCF 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 A10connections with the PDSN based on the events it receives from call control.PDSN Selection implements the IOS standard PDSN selection algorithm. TheAT mapping table is a mapping between the AT UATI, its airlink connectionstatus, the PCF session ID (PSI) and the outgoing interface number to reach aspecific PDSN. It is updated by PCF signaling and used by PCF data residingin the RNSM card. The accounting functionality is responsible for sending


31/108



the airlink information to the PDSN as per TIA-878. RNC release 3.0provides the ability to send the airlink information through R-P interface indifferent formats compatible with TIA-878-Ballot and TIA-878-1. Toconfigure 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 signalingThe PCF signaling interfaces with call control and PCF data in the RNSMcard. The DO-RNC could have more than one RNSM card. This implies thatthere may be more than one instance of PCF data. PCF signaling receivesevents from the call control and sets up and releases A10 connections with thePDSN. Based on the Call Control events, the PCF signaling populates andupdates the AT mapping Table. When the PDSN releases the A10 connection,it interacts with Call Control to release the airlink connection (if one ispresent) and updates the AT mapping table. The PCF signaling is alsoresponsible 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 theresponsibility of PCF signaling to maintain the uniqueness of the PSI acrossthe many PCF data instances. PCF signaling uses UDP/IP for exchangingsignaling messages with the PDSN. For this purpose, it utilizes the socketlayer interface.

In release 2.x, whenever a DO session was setup, the RNC automaticallyestablished an A10 Connection. This caused the PDSN to always attempt tosetup a PPP session with the AT whenever the AT established a new DOsession. When the AT did not have a packet data session present, this becamean unnecessary event only resulting in the PDSN repeatedly sending PPPLCP 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 apacket data session causing the PDSN to close the PPP session and also teardown 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 knownthe AT has or is initiating a packet data session and consequently needs anA10 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 setuponly if the AT has a packet data session present. By setting up an A10only when a packet data session is present in the AT, A10 connectionminimization significantly reduces the number of unnecessary A10connections setup by the RNC. This also leads to fewer A10s closed bythe PDSN.


32/108



The A10Conn Min feature supports two modes of operation: ULN andQC-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 Minimizationfeature.

The user can choose the mode of operation.

PDSN selectionThe DO-RNC is capable of supporting up to 64 PDSNs and selects themaccording 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 PDSNselection table through the use of the CLI or the DO-EMS. Each entry in thePDSN selection table contains a PDSN number and the PDSN IP address.

When setting up an A10 connection, the PCF uses the following formula toselect 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 ofretransmissions), the PCF selects the next available PDSN from the PDSNSelection Table. This process continues until a PDSN accepts the A10connection or the PCF has tried with all PDSNs in the PDSN selection table.

AT mapping tableThe AT mapping table is a lookup table that maps an ATs UATI, airlinkconnection 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. TheAT mapping table utilizes the system services providing functionality todistribute 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 onthe RNSM and the A10 demux function on the BIOs. Note that PCF data andA10 demux have read-only access to the AT mapping table.

AccountingAt IOS defined trigger points, accounting records will be formed and sent tothe PDSN through R-P interface. Triggering events include the opening ofA10 sessions, and (based on messages received from call control) the openingand closing of 1xEV-DO connections.


33/108



System management

The DO-RNC can be fully managed and configured using either thecommand line interface or the DO-EMS, which communicates with an XMLagent implemented in the SC. In addition, there is support for accessing

observables (operational measurements) by SNMP (please see DO-RNCOA&M on page 7-1 for details). Each method accesses the same set ofconfiguration data through a common configuration framework.

Command line interfaceThe command line interface (CLI) is accessed either directly from the serialport or through the Telnet application. It provides a means for administrativecontrol and management of the DO-RNC. For example, CLI can be used toprovision and configure the network elements in the absence of backhaul (andtherefore DO-EMS connectivity).

XML agent

XML is a standard language used to communicate text based commands. TheDO-EMS uses XML to send commands for configuration and query forstatus. These XML commands are sent using the HTTP protocol. There is anXML agent on the SC which interprets these commands and interacts with theconfiguration framework described below.

SNMP agentSNMP is a UDP based standard protocol used to manage and monitor theDO-RNC. Version SNMPv2c is supported. SNMP and XML allow theDO-EMS to manage the nodes.

Configuration framework

The configuration framework provides a unified view of configuration data. Itconsists 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 actionroutines

SNTP timing functionalityIn order to have accurate time synchronization across the network SNTPderives 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 thatthe DO-RNC SNTP timing be derived from the DOM's GPS timing source.The reason for this recommendation is timing accuracy.

Timing accuracyThe DO-RNC counts on a +/- 50ms propagation delay when receiving timingfrom an external source when the source is a GPS Timing Source (Stratum 0).


34/108



When the timing is derived from an external non-GPS source (Stratum 3), thesource will introduce additional drift to the DO-RNC timing. Therefore, inorder to achieve the most accurate timing source to the DO-RNC, it isrecommended that the DO-RNC point to a GPS timing source.

Timing source redundancyAlthough the DO-RNC can be configured with primary and secondary timingsources, it is recommended that both of these parameters are leftunconfigured. In this case, the DO-RNC will AUTOMATICALLY select atiming source from one of the DOMs that is homed to the DO-RNC. If thisDOM fails for any reason, the DO-RNC will automatically select anotherDOM to receive timing. This results in having a redundant timing sourceequivalent to the number of DOMs which are homed to the DO-RNC

DO-RNC reset mechanismThe 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 aheartbeat of each hardware module in the system. If a module fails theheartbeat poll, it is reset. If a board is reset repeatedly 10 times, it will refuseto reset any further. When software on a particular board detects a hard failurecondition, it resets that board in an attempt to recover, subject to the limitationon the maximum number of resets in close succession.

DOM homing on the DO-RNCWhen a DOM is administered up, it tries to home to its configured parentDO-RNC. The DOM's topology managercommunicates with the SC's

topology manager. Configuration information is exchanged, and the SC'stopology manager assigns the DOM to a RNSM. Subsequently, a link (Abissignaling) is established between the DOM and the RNSM for the purposes ofexchanging signaling information between the RNSM and the DOM (more onthis later).

Note: Topology manager is a software component which resides on theDOM, SC and RNSM modules. Some of topology manager functionsinclude configuring the node while powering up, updating other modulesfor any configuration changes, homing the DOMs to the DO-RNC, andinforming peers about the capabilities of its modules.

The SC topology manager distributes all the DOMs to available RNSM cardsin the DO-RNC according to the following algorithm: it will assign DOMs tothe first available RNSM up to a configured committed value before assigningDOMs to the next available RNSM. Once all RNSMs are at their committedlevel, any additional DOMs will get assigned on a rotating basis up to aconfigured maximum.


35/108



Once a DOM is homed (or Abis is established) then all DO sessions requestedby that DOM/sector are established on the RNSM card. The PCF entities forall these DO sessions exist on the same RNSM card.

In release 3.0, Nortels solution for the Inter-RNC Active Handoff requiresthat 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 calledMulti-Homing. The Node IP addresses of zero or more Secondary RNCs shallbe configured on the RN. The RN will open Topology Manager connections(TCP connections to port 9444) and Abis connections (TCP connections toport 5604) to the Secondary RNCs. Unlike the Primary RNCs, no priority isassociated with the Secondary RNCs. If the RN loses homing to the ParentRNC, it shall close Topology Manager and Abis Signaling connections to allSecondary RNCs as well (because the configuration information it hadreceived from the Parent RNC is no longer valid). If however, it loses homingto one of the Secondary RNCs, it shall close all forward and reverse traffic

channels that originated from that RNC. When an RNC closes the TopologyManager/Abis Signaling channel to a Secondary RN, it shall cleanupresources that were in use with the RN. If the RN is already homed to aParent RNC, it shall periodically try to home to any Secondary RNCs that it isnot homed to. If a Secondary RNC is configured after the RN has alreadyhomed to the Primary RNC, it shall immediately try to home to the SecondaryRNC.

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 sendcolor code, Subnet mask and length to the Primary RNs. It shall not send thisinformation to the Secondary RNs. It shall continue to allocate Sector-IDs

(24 least significant bits) for the sector-carriers of Primary RNs. It shall notallocate Sector-IDs for the sector-carriers of Secondary RNs. TM (on bothRN and RNC) will provide an additional observable parameter to indicate thetype of homing for each of its connections. Abis component (on both RN andRNC) will also provide an observable parameter to indicate the type ofhoming for each of its connections.

With the introduction of Multi-Homing, each RN will potentially be homed tomore than one RNC and different ATs may have connection through an RN todifferent RNCs. Therefore information about the total number of activeconnections in each of the sectors will only be available on the RN. For thisreason, 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 beperformed on the RN after the software on the RNC and the RN has beenupgraded. It cannot be explicitly enabled or disabled. The RNC will


36/108



continue to perform admission control for RNs running an older versionof the software.

A RNC will have sessions for ATs that were opened by the ATs through oneof 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 dormantand crosses the RNCs subnet boundary, its session will be transferred to thenew RNC. Therefore, the Call Control component will send Page messagesonly to Primary RNs and never to Secondary RNs.

The Topology Manager component on the RNC-SC homes an RN to anRNSM card in the RNC. As each RN will potentially be homed to more thanone RNC, the information about the total number of active connections ineach of the sectors will only be available on the RN. The RN willperiodically send this information (number of active connections in thesector) to the RNCs. This information will be sent to all RNCs (Primary and

Secondary). The HDRFastpath component on the RNC continually uses thisinformation to dynamically size its pre-RLP buffers and MAC and RLPhistory buffers.

Radio network server module (RNSM) board 3The 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 (seeAirlink mobility management on page 3-14)


37/108



A session is long-lived and, for example, is set-up when a mobile first powerson. It is not released until the mobile either releases it or it times out. Aconnection is relatively short-lived, and is only active long enough to supportthe transmission of a data burst (in either the up or down direction). A mobilewith an open connection is said to be active; otherwise it is dormant. Airlinkmobility management refers to the process of adjusting an active mobile'slinks to the air network to adapt to its changing position. Such adjustmentstake the form of using different sectors within currently utilized DOMs, and/or using different DOMs. Packet zone mobility management refers toexchanging information with the AT to facilitate inter-system handoffs, forexample, 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 managementThe 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 whichthe DOM is homed. A session does not move between RNSM cards within anDO-RNC during handoff. Rather, the BIO receives a table entry in itsforwarding table mapping the user's UATI to a specific RNSM card. When anRNSM card is removed from the system or fails, it results in the loss of allsessions & connections homed on that card.

Connection managementThe call processing subsystem interacts with the 1xEV-DO slow path,1xEV-DO fast path, SDU, resource control and PCF in order to manage 1xEV-DO connections. The AT is transitioned from dormant to active state under thefollowing 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 aconfigured Connection Inactivity time-out. The valid range for this parameteris 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 sincelast forward or reverse traffic was sent for that connection. When this valueexceeds the configured inactivity time threshold, the connection transitionsfrom active to dormant. For loading considerations, the complete list of activeconnections is only swept every five seconds for expired connections. Thus, it


38/108



may take up to five seconds longer than the configured Connection Inactivitytime-out for an idle connection to be timed out.

Airlink mobility managementIn addition to configuring the active set during connection setup, call controlwill make adjustments to the active set, adding and removing pilots, asrequired, based on route update information received from the AT while it isin a connected state. When determining or adjusting the active set, call controlwill interact with resource control to allocate (or release) the appropriateairlink resources, and communicate with the DOMs through Abis signaling toopen (or close) the associated traffic channels on the DOMs.

Packet zone mobility managementThe AT maintains information on which packet zone (for example, whichserving 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, thusminimizing handoff times. Call Control facilitates this process by exchanging(and updating) the packet zone information with the AT, and passing thisinformation on to PCF Signaling.

Session configuration optionsSession configuration is part of the call control subsystem. Sessionconfiguration manager (SCM) within the session configuration subsysteminteracts with the CLI component to accept user configurations for sessionconfiguration options. Session configuration subsystem also interfaces withthe A13 dormant handoff component, the Session component, and the SNP/HDRSlowPath component.

The messages exchanged between the RNC and the AT are carried over theSignaling Network Protocol (SNP) and is serviced by theHDRSlowPathcomponent.

All components that either manage a particular 1xEV-DO protocol or areotherwise dependent on the protocols configuration attributes also usesession configuration subsystem. These components may query the SCM foroperator-preferred values of the protocols configuration attributes, or toquery 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 areacceptable. If the protocols and/or parameters are not acceptable, SCM willrenegotiate the unacceptable protocols and/or parameters.

DO RepageA page results when data arrives for a dormant AT (i.e., without an openconnection). A few applications on the RNSM card (PCF, TA and TAP) issue


39/108



a Page Request to the connection state machine (CSM). The CSM respondsthat the Page Request either succeeded or failed. Page Success Indication isprovided by the CSM if a Connection was successfully opened in response orwas already open; all other cases result in a Page Fail Indication.

The DO RePage feature is implemented with the goal to achieve higher pagesuccess rate in 1xEV-DO implementation, comparable to page success rate asseen in 1xRTT networks. This feature enables the RNC to transmit a PageMessage to the Access Terminal (AT) more than once (number of times asconfigured by the operator, up to a maximum of three times) before declaringa Page failure.

In the following description, we use the term Paging Cycle to imply the set ofactions that follow when the AN sends a Page Message to the AT. This featureproposes to send the Page Message to the AT multiple times during a singlePaging 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 thePage timeout values are set to the 4 seconds). The Paging Cycle is initiatedwhen 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 configurablenumber of times to the AT.

Any error scenarios that cause the AN to decide that it should not wait foreither 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 valuein 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 waitbefore declaring a timeout is (T + Tcch) seconds. The value Tcch will beimplicitly added to the configured timeout value. The timeout values for thefirst Page Message and each of the successive RePages (aka Page retries) willbe configurable and hence can be varying in nature (the default timeout valuesfor the first Page Message and successive RePages are set to the same value asthere is no proof that configuring different timeout values improves theperformance of Paging mechanism.

Note: Though the recommendation is to have same timeout values for thefirst page message and the successive RePages, these timeout values havebeen made configurable to give the operator the flexibility to tweak thesetimeout values depending on the performance of the radio network. We donot enforce any kind of relationship between timeout values for thesuccessive page messages.


40/108



Resource control

In the DO-RNC, there are two levels of resource control: SC-level, andRNSM level.

The resource control subsystem at each RNSM has ownership of the air-linkresources of the DOMs assigned to (homed on) that RNSM. It will also act asproxy 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 thesession homing card) needs air-link resources managed by another RNSMcard (termed the resource homing card) due to user mobility, call controlsends all air-link related requests to resource control on the session homingRNSM, which will, in turn, forward the relevant subsets of the request over toresource control on the relevant resource homing RNSM.

BTS managerThe 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 theRNSM communicates with the RN controller running on the BIO/SC card onthe DOM. There is 1-to-n relationship between the BTSM and RN Controllerwhereby a BTSM instance talks to n different RN Controllers on n differentDOMs homed on the RNSM card (Primary and Secondary home). EachBTSM instance is responsible for the set of DOMs that is homed on the sameRNSM card as itself. The role of the BTSM begins when a new DOM ishomed to an RNSM card, on addition or removal of sector-carriers to a homedDOM, 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 inoperational and administrative status of sector-carriers, from the RN

controller. In addition, if the RN homes to a new Secondary RNC, TM (onRN) will trigger BTS Controller to send the SectorCarrierStatusUpdatemessage for sector-carriers on the RN (the ones that have been configured bythe Parent RNC) to the new RNC.

For the process of homing a DOM on a RNSM card, adding/removingsector-carriers on a homed DOM, and terminating homing of a DOM, theBTSM interfaces with topology manager on the DO-RNC SC card andtopology manager on the DO-RNC RNSM card.

The BTSM is also involved in the process of setting up CCH/ACH Abis datachannels. It uses the services of connection block manager on the RNSM cardto 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 andcreation of CCH/ACH Abis data channels


41/108



deallocation of CCH/ACH DO-RNC connection-IDs for sector-carriersand deletion of CCH/ACH Abis data channels

interfacing between RN controller on DOM and RNSM resource controlon 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 controlleron the DOM is the peer of the BTSM. The communication between theBTSM and RN Controller goes over the common Abis signaling channelbetween the DO-RNC and the DOM. This Abis signaling channel is setup bythe topology manager as a part of the homing process. Message routers on theDOM and DO-RNC abstract the Abis signaling channel and supportsexchange of messages between BTSM and RN controller.

BTS mapping tableThe 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 callcontrol.

PCF functionality

The PCF functionality spans across the SC card and the RNSM card. The RNSMcard's PCF functionality consists of PCF data. The PCF data is responsible forrelaying 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 isbeing paged, in a page data buffer.

PCF dataThe 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 GREand transmits the packets to the PDSN. The key field in the GRE headercontains the PSI, which uniquely identifies the AT. When packets are receivedfrom the PDSN, PCF data removes the GRE header and uses the PSI tolookup the AT mapping table. If the table lookup indicates that the ATassociated with the PSI has an airlink connection, PCF data passes the PPPdata to the RLP. If the table look up indicates that the AT has no airlinkconnection, the PCF Data buffers the PPP frame in the page data buffer andinforms call control (located in the same RNSM card) about the need to pagethe 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 tothe next stage of processing (or released to the free list).

Eventually, when the airlink connection is established, the PCF signalingupdates the AT mapping table and informs PCF data. The PCF data removesthe PPP frame from the queue and forwards it to the RLP.


42/108



Selection and distribution unit

The selection and distribution unit (SDU) is responsible for selecting a singlegood incoming air interface reverse link frame from all the traffic channelsinvolved 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), itswitches forward link air interface frames to the best channel, based oncommands received from the DOMs (which, in turn, are based on its processingof the DRC channel) as follows:

1. DO-RNC receives a stopped indication from the DOM currently owningthe serving sector. Transmission of frames to the DOM is halted. Thisstopped indication contains information on the last frames that weresuccessfully 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 bindinginformation needed by the SDU, such as which air link traffic channels gowith which air network (Abis data) connections. The SDU function resides onRNSM cards and is instantiated once for each session at connectionestablishment time.

1xEV-DO layer processing1xEV-DO layer processing is implemented in both the fast path, to handle1xEV-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 Abisdata connections used for access channel and control channel packets.1xEV-DO layer processing is responsible for performing the user dataprocessing associated with the various layers of the 1xEV-DO air interfaceprotocol: stream layer, connection layer, security layer and MAC layer.

The prime function of the stream layer is to provide support for multiplexingmultiple application streams over the air interface. Stream 0 is always usedfor (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 applicationsub-type 1 as the default packet application (RLP) bound to the radio accessnetwork (for terminal authentication via the A12 interface) and applicationsub-type 2 as the default packet application (RLP) bound to the serviceapplication network (for user data to the PDSN). The test application


43/108



specification (3GPP2 C.S0029) [TIA/EIA/IS-890-1, Test ApplicationSpecification (TAS) for High Rate Packet Data Air Interface] definesapplication subtype 3 for the test application protocols (TAP). The binding ofstreams to applications occurs as part of the session configuration negotiationprocess. Typically, streams 1, 2 and 3 are bound to applications sub-types 1, 2and 3, respectively.

The connection layer prioritizes and encapsulates transmitted data receivedfrom the stream layer and forwards it to the security layer; in the reversedirection, it decapsulates data received from the security layer and forwards itto the stream layer.

The security layer is used only to provide authentication for the accesschannel (the uplink control channel used by mobile stations when they don'thave an open connection.) Currently, neither authentication nor encryption isperformed on any of the other channels.

In the forward (downlink) direction, the MAC layer is used to encapsulateuser and control packets in preparation for transmission over the physicallayer. In the reverse (uplink) direction, the MAC layer header information isused to convey side information about the upper layer processing, asdemuxing capability for the access channel.

Abis signalingAbis Signaling is primarily used to support the setup and release of Abistraffic channels, which are employed to convey user data between the DOMand the DO-RNC. Abis signaling runs over TCP

Abis data processingAbis data processing performs all the protocol processing (headerencapsulation/decapsulation, muxing/demuxing for multiple independentdata 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 betweenthe DOM and the DO-RNC. A dedicated Abis connection (and connectionID) is provided per user air link data stream (forward traffic channel/reversetraffic channel pair). In addition common Abis connections (and connectionIDs) are provided per sector, for the purposes of transporting access channeland control channel frames.

A13 interface protocolThe A13 interface protocol is used for inter-RNC communications. Thisinterface is used from Release 3.0 onwards for transferring sessioninformation from one RNC to another when an AT is performing a dormanthandoff from one RNCs domain to another. The A13 protocol consists of two


44/108



major components: the network interface to the source/target RNC, and theA13 state machine.

Note: The A13 state machine is not independent and is embedded withinthe 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 receivedwith a UATI-32 whose color code does not match the local subnet. The 8-bitcolor code (i.e. 8 MSBs) of the received UATI-32 is mapped to a 104-bitsubnet, concatenated with the lower 24-bits of the UATI to form UATI-128.This mapping is not guaranteed to be unique. However, the authentication ofthe 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 theA13-Session InformationRequest Message to the source RNC. A timer (1 sec default) is started on thetarget to wait for a response from the source RNC. If no response (eithersuccess or reject) is received, thenA13 Session Information Requestis retriedup to two more times until a response is received. If no response is receivedafter all the retries, the target RNC closes the DO session with the AT, whichcauses it to start a new one.

At the source RNC, the security layer packet received in theA13 SessionInformation Requestis authenticated. If the result is successful, anA13Session Information Response is sent back to the target, which contains thesession 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 theA13-Session InformationResponse message. Therefore, a secure/private network should be usedbetween RNCs. If the source RNC is still in a connected state with that ATwhen it moved away, the RNC will shortly disconnect due to either inactivityor reverse link loss (more likely), and go to a disconnected state. The RNCand RN resources will be cleaned up. If authentication failed, or if the sessioninformation for that UATI cannot be retrieved, anA13 Session InformationRejectis sent back to the target, along with the failure reason.

The target RNC will send a SessionClose message to the AT if anA13-SessionInformation Rejectis received. The SessionClose message must be sent on all

twelve sleep cycle phases because the target does not know the ATs sleepcycle. This will cause the AT to close its present session and request a newone.

The timer that started when the Request was sent is stopped when the A13Response is received. The target RNC populates the session with parametersretrieved from the source when an A13-Session Information Response is


45/108



received. However, if some of the parameters are unacceptable to the target,they must be renegotiated with the AT. Renegotiation of session configparameters is conducted the next time a DO-Connection is opened at thetarget. In this case, the target sends ConfigurationStart to ensure that the ATstarts the configuration phase.

While the A13 transfer is in progress, the target must temporarily associatepackets 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 removedafter the AT responds with UATIComplete following assignment of the newUATI. Typically, Terminal authentication is not required at the target in thecase of an A13 session transfer.

The retrieved MN ID, retrieved PDSN address (used to select the PDSN), andAccess Network Identifiers (use the retrieved value only if the AT cannotprovide the PANID) are used when establishing the A10 connection at the

target in order to avoid PPP and mobile IP re-establishment. A SessionInformation Confirm is sent back to the source to notify it to remove thesession 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 theTIA-878 standard. It requires the use of an AN-AAA server. If customers chosenot to deploy this function, then user level authentication occurs at the PDSNor PDSN-AAA server. The A12 interface is the interface between the DO-RNCand the AN-AAA server and it is used only if terminal authenticationfunctionality is used.

The A12 messages are essentially the same messages used in the well knownRADIUS protocol as defined in RFC2865. The specific attributes used in themessages are defined by the TIA-878 specifications. Consequently, the detailsof the basic message format is defined in RFC2865 while, the details of terminalauthentication specific aspects are defined in TIA-878.

The terminal authentication is intended to validate that a particular accessterminal attempting to use the RAN. The function executes entirely on theRNC and uses the A12 interface to communicate with an external AN-AAAfunction.

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 mustauthenticate with the AN using the following steps:

1. The AT opens a PPP connection (the AN-PPP connection) with the RNCon the access stream. During the PPP LCP phase the RNC requires thatPPP authentication be done and that the CHAP protocol be used.


46/108



2. The AT performs CHAP-based authentication during the PPPauthentication 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 IMSIfor the user's packet data service.

Note: The IMSI is not sent over the airlink to the AT; it is kept at the RNCand used for registration with the PDSN over the A11 interface and toidentify DO sessions tied this AT on the specific RNC.

5. If the AT is not authenticated, the RNC removes the HRPD session forthat user. Thus, HRPD terminal authentication protects the RNC andPDSN from access by unauthenticated ATs.

In the RAN, the terminal authentication is implemented by the TermAuthmodule on the RNC. In the RNC, the TermAuth module is responsible forterminating the AN-PPP connection with the AT, initiating terminalauthentication of the AT through the use of the CHAP authentication optionduring the setup of the AN-PPP connection, and controlling the A12interfaces between the RNC and the AN-AAA.

Note: The CHAP protocol and use of the A12 interface (based onRADIUS) implies that the AT and AN-AAA server are configured withthe same information regarding the ATs NAI and password (secret key). Ifthe 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


47/108



AT will fail authentication. That is, fall into the if AT is not authenticatedcase in the previous steps.

Figure 3-2Terminal authentication model

AN-AAA selection mechanismThe terminal authentication solution is based on the concept of AAA groupswhich consist of multiple AAA servers. When the RNC selects an AAAserver to request authentication, it first chooses an AAA group based on theload balancing configuration and information it has received from the AT.Once the AAA group has been chosen, the RNC selects a specific AAAserver from the chosen AAA group. Thus selection of AAA servers isimplemented as a two-tier approach where the first tier, group selection, isused for load balancing authentication requests and the second tier, AAAselection, 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 ATsNAI, that is, the part following the @ in [email protected], isused to choose the AAA group to which the request is to be sent. Thisdecision is based on an AAA NAI routing table that must be configuredby the operator. This table provides a lookup capability where a suppliedrealm results in the return of an AAA group for use in the actual serverselection phase. When this option is used, it is important to supply adefault 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 toAAA Group 1, the next would be sent to AAA Group 2 and so on. Whenround robin selection is used there is no need to configure a defaultlookup entry as the next AAA group will always be used.

AT RNC AN-AAA1xEVDO

signaling

A12

RADIUS

AN-PPP

RLP over application

access stream


48/108



The method used for selecting an AAA server is based on the fail over faulttolerance method, that is, the RNC tries the first server in the group and, if itfails and another server is requested, the next server in the group is tried.There is a configured number of allowable authentication requests for a groupand for an RNC as a whole this must be configured to be consistent with thenumber of AAA servers configured in that group.

Note: The algorithm does not keep history of failed AAA servers in agroup so subsequent requests will have to try a previously failed AAAbefore moving on to another. The reason is that cause for the failure isunknown consequently and we assume the fault was transient.

This approach allows flexible configuration of AAA selection policies. Forexample, if the operator is concerned more with load balancing than fault-tolerance, the operator can configure some number of groups, each with oneAAA server. If the operator is only concerned with fault-tolerance, the

operator can configure a single group with multiple AAA servers. Theoperator may select a mode with both characteristics by selecting the numberof groups and the number of servers in each group appropriately.

Finally, one more items to consider is that if the operator wants to supportroaming agreements with other operators, the operator must decide whetherto use a proxy AAA server to route the authentication requests to theappropriate operator's AAA servers or use the NAI realm-based routingability of the RNC to directly route the requests.

Operation without terminal authenticationIf the terminal authentication function is bypassed, the RNC locally assigns

an IMSI for the AT without any authentication. The basic idea is to synthesizean IMSI (pseudo IMSI) from the HardwareID of the AT. The constraint is thatthe pseudo-IMSI generated from the HardwareID must be unique if possible,so that no two different HardwareIDs results in the same IMSI. Uniqueness isimportant as the IMSI is used in inter-RNC hand off situations by the PDSNto track users and also by the RNC to identify duplicate DO sessions for thesame AT.

The format for an IMSI is 15 decimal digits. The first 3-digits are MobileCountry Code (MCC), the next 3-digits are Mobile Network Code (MNC)and the f