ESG 1x EV DO Rev A Session Negotiation

1xEV-DO REVISION A SESSION NEGOTIATION EXAMPLE

October 11, 2007

80-W1259-1 Rev A

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page ii

QUALCOMM is a registered trademark of QUALCOMM Incorporated in the United States and may be registered in other countries. Other product and brand names may be trademarks or registered trademarks of their respective owners. CDMA2000 is a registered certification mark of the Telecommunications Industry Association, used under license. ARM is a registered trademark of ARM Limited. QDSP is a registered trademark of QUALCOMM Incorporated in the United States and other countries.

This technical data may be subject to U.S. export, re-export or transfer (“export”) laws. Diversion contrary to U.S. law is prohibited. QUALCOMM is a registered trademark and registered service mark of QUALCOMM Incorporated. Other product and brand names may be trademarks or registered trademarks of their respective owners.

This technical data may be subject to U.S. export, re-export or transfer (“export”) laws. Diversion contrary to U.S. law is prohibited.

QUALCOMM Incorporated 5775 Morehouse Drive

San Diego, CA 92121-1714 U.S.A

Copyright © 2007 QUALCOMM Incorporated

All rights reserved

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page iii

Table of Contents 1. Introduction.......................................................................................................................................1

1.1 Purpose ............................................................................................................................................1

1.2 Scope ...............................................................................................................................................1

1.3 Document Organization ...................................................................................................................1

1.4 Conventions .....................................................................................................................................1

1.5 Revision History ...............................................................................................................................2

1.6 References .......................................................................................................................................2

1.7 Acronyms .........................................................................................................................................2

2. Session Negotiation .........................................................................................................................5

2.1 1xEV-DO Session Overview ............................................................................................................5

2.2 Difference between an EV-DO Session, Connection and a PPP Session ......................................7

2.3 Lifetime of a 1xEV-DO Session........................................................................................................7

2.4 Generic Configuration Protocol ........................................................................................................7

2.5 Types of Attributes and their use .....................................................................................................8

2.6 SNP header and Use of Protocol Instance ......................................................................................8

2.7 Example log and high level Session Negotiation call flow ...............................................................8

3. Session Setup ................................................................................................................................11

3.1 Obtain Unicast Access Terminal Identifier (UATI) .........................................................................11

3.1.1 AT requests UATI in an Access Channel capsule.................................................................11

3.1.2 AN assigns UATI to the AT....................................................................................................14

3.1.3 AT sends UATI Complete in an Access Channel Capsule ...................................................16

4. Session Configuration phase – Negotiation of Multiple Personalities............................................19

4.1 Establishment of Air Link resources...............................................................................................20

4.1.1 AT requests Air Link resources .............................................................................................21

4.1.2 AN allocates Air Link resource ..............................................................................................21

4.1.3 AN acknowledges establishment of Reverse Air Link ...........................................................23

4.1.4 AT acknowledges TCA and establishment of Forward Link..................................................24

4.2 Configuration of First (Main) Personality........................................................................................24

4.2.1 AT conveys protocol and application subtypes that it supports ............................................25

4.2.2 AT initiated configuration of Default Idle State Protocol ........................................................28

4.2.3 AT initiated configuration of Stream Protocol ........................................................................29

4.2.4 Completion of AT initiated configuration of First Personality.................................................34

4.2.5 AN initiated configuration of Session Configuration Protocol................................................34

4.2.6 AN initiated configuration of Access Channel MAC Protocol ................................................35

4.2.7 AN initiated configuration of Forward Traffic Channel MAC Protocol ...................................37

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page iv

4.2.8 AN initiated configuration of Reverse Traffic Channel MAC Protocol ...................................38

4.2.9 AN initiated configuration of Route Update Protocol .............................................................40

4.2.10 AN initiated configuration of Session Management Protocol ................................................42

4.2.11 AN initiated configuration of Stream Protocol........................................................................43

4.2.12 Completion of First Personality Negotiation ..........................................................................45

4.3 Second Personality Negotiation .....................................................................................................47

4.3.1 AT initiated negotiation of Protocol subtypes for the Sesond Personality.............................48

4.3.2 AT initiated configuration of Idle State Protocol ....................................................................50

4.3.3 AT initiated configuration of Stream Protocol ........................................................................51

4.3.4 AT initiated configuration of Route Update Protocol .............................................................52

4.3.5 AT initiated configuration of RTCMAC Subtype 3 Protocol ...................................................53

4.3.6 AT initiated configuration of Enhanced Multi-Flow Packet Application .................................55

4.3.7 Completion of negotiation of parameters for Second Personality from AT side ...................58

4.3.8 AN initiated configuration of Session Configuration Protocol................................................59

4.3.9 AN initiated configuration of Enhanced FTCMAC .................................................................63

4.3.10 AN initiated configuration of RTCMAC Subtype 3.................................................................64

4.3.11 AN initiated configuration of Enhanced Multi-Flow Packet Application subtype ...................76

4.3.12 AN initiated configuration of Stream Protocol........................................................................77

4.3.13 Negotiation of Second Personality Complete........................................................................78

4.3.14 Commit the parameters of the personality in use..................................................................81

5. Session Authentication...................................................................................................................83

5.1 AT initiated Session Authentication................................................................................................83

5.1.1 AT opens Stream01 stream for AN authentication................................................................84

6. Appendix ........................................................................................................................................87

6.1 Personality Switch ..........................................................................................................................87

6.1.1 AN sends GAUP message to switch personality...................................................................87

6.2 Closing A Session ..........................................................................................................................88

6.2.1 AT sends SessionClose to delete a 1xEV-DO Session ........................................................88

6.3 Start Configuration or change parameters of an existing Session.................................................89

7. Best Practices ................................................................................................................................91

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page v

List of Figures

Figure 1: 1xEV-DO Protocol Stack Reference Architecture 5

Figure 2: 1xEV-DO Session, Connection and PPP Session 7

Figure 3: Phases of Session Negotiation 9

Figure 4: Session Setup 11

Figure 5: Construction of UATI when 104 MSB are not provided in the UATIA 15

Figure 6: High level call flow of Protocol Negotiation 19

Figure 7: Traffic Channel establishment call flow 20

Figure 8: Authentication Call flow 83

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page vi

List of Tables

Table 1: Revision history...............................................................................................................................2

Table 2: Reference documents and standards .............................................................................................2

Table 3: Default Protocols in 1xEV-DO stack architecture ...........................................................................6

Table 4: Stream Application and the Protocol IDs ......................................................................................30

Table 5: Summary of Protocols negotiated for First Personality.................................................................46

Table 6: Application subtypes supported by AT..........................................................................................47

Table 7: Stream Application bindings..........................................................................................................47

Table 8: Protocols available at the Flow Protocol in EMFPA......................................................................57

Table 9: Protocols available at the Route Protocol in EMFPA....................................................................57

Table 10: Mapping of t2p_frab_axi to combination of t2p_axi and frab_axi ...............................................68

Table 11: Summary of protocol subtypes and parameters configured for Second Personality..................79

Table 12: Application subtypes to Stream mapping for Second Personality ..............................................81

1x1XEV-DO Revision A Session Negotiation Example

80-W1259-1 Rev A MAY CONTAIN U.S. EXPORT CONTOLLED INFORMATION Page 1

1. Introduction

1.1 Purpose The purpose of this document is to provide a descriptive walkthrough of a CDMA2000 1xEV-DO Revision A Over-The-Air (OTA) Session Negotiation. This document will explain the various components of a Session Negotiation, each step in the call flow (signaling messages) and a brief explanation of concepts coupled with the configuration of attributes and their associated values.

1.2 Scope This document is intended for CDMA industry professionals looking to obtain a better understanding of the OTA signaling between the Access Terminal (AT) and the Access Network (AN) when establishing a 1xEV-DO Session. This document is an illustrative guide and should not serve as a design document. This document is based on [S1], [S2], [S3] and [S4]. For additional call flows, please refer to [Q1] and [Q2]. For more details on the use of parameters and their recommended values, please refer to [Q4].

1.3 Document Organization This document is organized in the following manner.

Chapter 2 provides a high level overview of Session Negotiation and the different phases involved in the negotiation process. It discusses the initial state of the device, the protocols used by the AT during negotiation and methods used to configure the parameters using different types of attributes. It also provides call flows with messages during the different phases of Session Negotiation.

Chapter 3 provides a detailed description of the first phase of the 1xEV-DO Session Negotiation. This phase is known as Session Setup, where the AT obtains a Unicast Access Terminal Identifier (UATI) from the AN. The Session Setup phase is executed in the ‘Setup state’ of the Default Address Management Protocol.

Chapter 4 provides a detailed description of the second phase of the 1xEV-DO Session Negotiation. This phase is known as Session Configuration and during this phase, the AT and the AN begins with the negotiation of the protocol and the application subtypes. Subsequently, the related parameters for the negotiated protocol and application subtypes are configured. This chapter also discusses the concept of multiple personalities and HardLink subtypes.

Chapter 5 discusses the third phase of the Session Negotiation. This phase is known as 1xEV-DO Session Authentication and is used to perform the AAA-A12 authentication of the AT.

In Chapter 6 (Appendix), the other relevant procedures such as closing the 1xEV-DO Session, switching the 1xEV-DO personality etc., are discussed in detail.

Finally, Chapter 7 summarizes the best practices for the Session Negotiation process.

1.4 Conventions Attribute names appear in angle italics.

Flow identifiers, log packet titles, and line numbers appear color coded and in bold.

Line numbers designated in bold correspond to the line number of the previous and most immediate log output in that sub-section.

Shading indicates content that has been added or changed in this revision of the document.



1.5 Revision History The revision history for this document is shown in Table 1.

Table 1: Revision history

Version Date Description

A Oct 11, 2007 Initial release

1.6 References Reference documents, which may include QUALCOMM, standards, and resource documents, are listed in Table 2.

Table 2: Reference documents and standards

Ref. Document

QUALCOMM

Q1 1xEV-DO Release A Multiple Personality Management Feature Definition Document

80-V9475-1 F

Q2 1xEV-DO Release A Air Interface Feature Definition Document 80-V8409-1

Q3 Application Note: Software Glossary for Customers CL93-V3077-1

Q4 1xEV-DO Revision A Parameter Setting Guidelines 80-W0904-1 Rev B

Q5 Enhanced Multi-Flow Packet Application Feature Definition Document

80-V7647-1 F

STANDARDS

S1 cdma2000® High Rate Packet Data Air Interface Specification 3GPP2 C.S0024-A ver 3.0 (IS-856A)

S2 cdma2000 High Rate Packet Data Supplemental Services

3GPP2 C.S0063-A ver 2.0

S3 Administration of Parameter Value Assignments for TIA/EIA Wideband Spread Spectrum Standards

C.R1001-E v. 1.0 (TSB-58E)

S4 Band Class Specification for cdma2000 Spread Spectrum Systems 3GPP2 C.S0057-A ver 1.0

S5 Test Application Specification (TAS) for High Rate Packet Data Air Interface

C.S0029-0 v3.0

S6 Test Application Specification (TAS) for High Rate Packet Data Air Interface

C.S0029-A v1.0

OTHER

1.7 Acronyms For definitions of additional terms and abbreviations, please refer to [Q3].



Abbreviations Definition

1xEV-DO Evolution-Data Optimized

AAA Authentication, Authorization, and Accounting

AN Access Network

AT Access Terminal

BTS Base Transceiver Station

EMFPA Enhanced Multi-flow Packet Application

FTCMAC Forward Traffic Channel MAC

GAUP Generic Attribute Update Protocol

HA Home Agent

HDLC High-level Data Link Control

MAC Media Access Control

MFPA Multi-flow Packet Application

OTA Over-the-Air

PDSN Packet Data Serving Node

PPP Point-to-Point Protocol

QCAT QUALCOMM CDMA Analysis Toolkit

QTP QUALCOMM Test Phone

QXDM QUALCOMM Extensible Diagnostic Monitor

RNC Radio Network Controller

RoHC Robust Header Compression

RSP Route Selection Protocol

RTCMAC Reverse Traffic Channel MAC

UATI Unicast Access Terminal Identifier



This page intentionally left blank.



2. Session Negotiation

A 1xEV-DO Rev A capable device supports all the Release 0 protocol and application subtypes. In addition to that, it also support a number of new protocol subtypes and application subtypes. A 1xEV-DO device qualifies as Rev A capable when the AT and the AN supports and use the following protocols, at a minimum:

• Subtype 2 Physical Layer Protocol

• Enhanced Forward Traffic Channel MAC Protocol (Enhanced FTCMAC)

• Subtype 3 Reverse Traffic Channel MAC Protocol (RTCMAC Subtype 3)

Optionally, the device may support

• Enhanced Control Channel MAC Protocol

• Enhanced Access Channel MAC Protocol

• Enhanced Idle State Protocol

• Multi-Flow Packet Application (MFPA)

• Enhanced Multi-Flow Packet Application

Effectively there are a number of protocols that the AT and the AN can use to communicate with each other. 1xEV-DO Session Negotiation is the process to allow the AT and the AN to agree on a set of protocols to use.

2.1 1xEV-DO Session Overview In CDMA2000 1xEV-DO, the AT is required to establish a 1xEV-DO Session before it can begin to use the network resources for any higher layer user data transmission. A 1xEV-DO Session is a shared state between the AT and the AN, and it includes an agreement on the protocol subtypes, application subtypes and the configuration of related parameters of the 1xEV-DO protocol stack. This negotiated set of parameters is used by the AT and the AN for communication between the two entities and for relaying the higher layer user data. The 1xEV-DO Protocol Stack reference architecture is shown below in Figure 1.

Transport

ApplicationPresentationSession

Network

Data Link

Physical

Application

Stream

Security

Physical

Session

Connection

MAC

RLP

Application

TCP/UDP

IP

Upper Layer

Application

Stream

Security

Physical

Session

Connection

MAC

RLP

Access Network (AN)

Laptop

Application

TCP/UDPIP

Upper Layer

OSI Reference Model

Access Terminal (AT)

Figure 1: 1xEV-DO Protocol Stack Reference Architecture

There are three phases of 1xEV-DO Session Negotiation:



1. Session Setup: The AT requests an identifier, UATI from the AN. This identifier allows the AN to uniquely identify an AT within a subnet1 of the 1xEV-DO network. The UATI is used by the AN to send the directed signaling messages. Similarly, the AT includes the UATI whenever it sends the access request.

2. Session Configuration: The AT and the AN negotiate a set of protocol subtypes, application subtypes and the relevant parameters for each personality.

3. Session Authentication: The AAA-AN uses the A12 interface to authenticate the AT. Only after the successful authentication, the AT is allowed to access the 1xEV-DO network resources. This phase is optional, but recommended.

Until the AT and the AN have completed the 1xEV-DO Session Negotiation, the AT uses the default set of protocol subtypes, application subtypes and the default values of the related parameters to communicate with the AN. The default set of protocol subtypes and application subtypes are shown in the Table 3.

Table 3: Default Protocols in 1xEV-DO stack architecture

1xEV-DO Protocol Stack Default Protocols

Application Layer Default Signaling Application, Default Packet Application

Stream Layer Default Stream Protocol

Session Layer Default Session Management Protocol, Default Session Configuration Protocol and Default Address Management Protocol

Connection Layer Default Air Link Management Protocol, Default Initialization State Protocol, Default Idle State Protocol, Default Connected State Protocol, Default Overhead Messages Protocol, Default Packet Consolidation Protocol, Default Route Update Protocol

Security Layer Default Security Protocol, Default Key Exchange Protocol, Default Authentication Protocol, Default Encryption Protocol

MAC Layer Default Control Channel MAC Protocol, Default Forward Traffic Channel MAC Protocol, Default Reverse Traffic Channel MAC Protocol (Subtype 0) and Default Access Channel MAC Protocol

Physical Layer Physical Layer Protocol Subtype 0

In the first message of the Session Configuration phase, the AT conveys to the AN the non-default/Rev A protocol subtypes and all application subtypes that the device supports. It is at the reception of this message the AN determines that the AT is Rev A capable, assuming the RNC software is upgraded to understand the non-default/Rev A protocol subtypes and application subtypes conveyed in this message. Subsequently, the AN decides whether or not it shall negotiate the non-default/Rev A protocols and parameters with the AT, and how to negotiate them (See the concept of Multiple Personalities in 1xEV-DO Rev A later in this chapter).

1 A subnet has a footprint of an RNC, where all the sectors have the same subnet mask and the logical AND operation of the SectorID and the subnet mask results in the same value.



2.2 Difference between an EV-DO Session, Connection and a PPP Session It shall be noted that a 1xEV-DO Session is different from 1xEV-DO Air-link connection and the PPP session. A 1xEV-DO Air-link connection is the allocation of traffic channel resources, in the BTS and the RNC to enable the AT to send and receive the 1xEV-DO signaling messages and higher layer user data (OSI application data). A PPP session allows the AT to obtain an IP address from the PDSN or HA. The establishment of PPP session and the use of the PPP/HDLC framing enable the AT and the PDSN to send and receive the higher layer user data with the IP servers using the IP based applications. These applications reside outside of 1xEV-DO network. The difference between the 1xEV-DO Session, connection and PPP Session is shown in Figure 2.

Over the lifetime of a 1xEV-DO Session, the AT and the AN can open and close a 1xEV-DO Air-Link connection multiple times to transmit higher layer application data. The Air-link connection can be closed explicitly by the AN when the RLP inactivity timer expires (or other reasons), or it can be lost due to bad RF conditions. The PPP Session remains in either Active or Dormant (no air-link resources assigned) state once it is established. The PPP Session may be closed due to the PPP inactivity timer, or closed explicitly by the AN or the user.

1xEV-DO Session is negotiated once and stored by the AN and the AT

PPP Session exists between the AT and the PDSN

Application

Stream

Security

Physical

Session

Connection

MAC

RLP

Application

TCP/UDP

IP

Upper Layer

Application

Stream

Security

Physical

Session

Connection

MAC

RLP

Application

TCP/UDP

IP

ATBTS/RAN PDSN

1xEV-DO Connection

PPP free

PPPPPP free

PPP

Figure 2: 1xEV-DO Session, Connection and PPP Session

2.3 Lifetime of a 1xEV-DO Session Typically, the 1xEV-DO Session is governed by a rolling timer called TSMPClose (another parameter negotiated between the AN and the AT during the Session Negotiation phase); the timer defines the maximum amount of inactivity time between the AT and the AN before the Session is reclaimed The Session Management Protocol in the Session Layer also provides a keep alive mechanism for the 1xEV-DO Session when a period of inactivity on the FL and RL is observed. However, there are occasions when the Sessions are lost. These include, the AT leaving the 1xEV-DO coverage area for prolonged periods, or moving from the footprint of one 1xEV-DO Subnet into another 1xEV-DO Subnet.

2.4 Generic Configuration Protocol The AT and the AN use the Generic Configuration Protocol to negotiate the protocol subtypes, application subtypes and associated parameters during the Session Configuration phase. This protocol defines two messages: ConfigurationRequest and ConfigurationResponse.

The procedure consists of the initiator sending attributes with one or more allowed values in the ConfigurationRequest message. The initiator must list the offered values in descending order of preference. The responder then selects one of the offered values and sends it back to the initiator in the



ConfigurationResponse message. Each parameter has a well defined fall back value (also known as default values). If the responder does not select any of the offered values, the fall back values are selected. This protocol is available to all the protocols in the 1xEV-DO protocol stack. Each ConfiurationRequest message is sent by one 1xEV-DO protocol or application subtype.

2.5 Types of Attributes and their use There are three types of attributes that are used during the Session Configuration [S1]. These are:

1. Simple attribute with single value

2. Attribute-list for a single parameter with a list of offered values (in order of preference)

3. Complex attribute, which binds a number of related parameters together.

Generic Configuration Protocol allows the AT and the AN to include a mix of these attributes in a single ConfigurationRequest message, but all the attributes must belong to a single 1xEV-DO protocol subtype or application subtype. Each attribute is identified by a unique identifier within a 1xEV-DO protocol. It is possible to have the same identifier for different attributes (simple or complex), but these two attributes must belong to different 1xEV-DO protocol subtypes or application subtypes. The responder (sender of the ConfigurationResponse message) accepts an attribute and its proposed value from ConfigurationRequest message by sending

(i) the attribute_identifier and proposed value (sent as value_id) if it is a simple attribute,

(ii) the attribute_identifier and the selected value (sent as value_id) if it is an attribute list,

(iii) the attribute_identifier and the value_id which identifies the set proposed by the initiator, in case it is a complex-attribute

2.6 SNP header and Use of Protocol Instance The SNP header is included in every 1xEV-DO signaling message exchanged between the AN and the AT. This header contains two fields. These are (i) the protocol type and (ii) the protocol instance.

A 1xEV-DO protocol can have two instances at any given time: the ‘In Config’ and the ‘In Use’. When a given instance of a protocol subtype is negotiating the parameter values, it is in the ‘In Config’ state. Once it has completed the configuration and committed the new negotiated values, that instance is changed to the ‘In Use’ state. Thereafter, the AT uses the ‘In Use’ instance of the protocol subtype for exchanging the 1xEV-DO signaling messages and the higher layer application data. The protocol_instance field in the messages is used to indicate which instance is sending a message. When the protocol_instance is set to 1, it implies the ‘In Config’ instance of the protocol. The 0 implies the ‘In Use’ instance of the protocol is sending the message.

The protocol_type field is used to identify the 1xEV-DO protocol sending the signaling message. These fields are used by the Default Signaling Application to route the message to the appropriate protocol in the 1xEV-DO stack.

In 1xEV-DO Rev A, several new subtypes with enhanced capabilities were introduced in addition to the existing default protocols in the 1xEV-DO Release 0. The default subtypes are identified as subtype 0. Qualcomm chipsets add the subtype field to the logged OTA message. The subtype field identifies the protocol subtype of the protocol. The subtype field is not a part of the OTA message.

2.7 Example log and high level Session Negotiation call flow The log file examples in this document use the parsed output of a binary log file. The log file was captured via QUALCOMM Extensible Diagnostic Monitor (QXDM) version 3.11.00 using a QUALCOMM Test Phone (QTP). The parsed output shown in this document was obtained using the QUALCOMM Log Analysis Tool (QCAT) version 5.7.00.



The call flows in this document focus on the high-level OTA Session Negotiation. In the next three chapters, the document discusses the 3 phases of the Session Negotiation as shown in Figure 3.

Phase 1: Session Setup (UATI Assignment)

Phase 2: Session Configuration (Multiple Personalities)

Phase 3: Session Authentication

ANAT

Figure 3: Phases of Session Negotiation



3. Session Setup

This is the first phase of the Session Negotiation process. In this phase, the AT requests a Unicast Access Terminal Identifier (UATI) from the AN.

The signaling messages involved for assigning a UATI to the AT are shown in Figure 4. In this example there are additional messages included in the Access Channel Capsule and the Control Channel Capsule or Traffic Channel to obtain the HardwareID and establishing the Air Link resources, but they are not considered part of 1xEV-DO Session Setup phase.

RouteUpdate/UATIRequest

ACAck

UATIAssignment

RouteUpdate/UATIComplete

ANAT

Session is open with default protocols, application subtypes and their default attribute values

ACAck

HardwareIDRequest

HardwareIDResponseConnectionRequest

Optional Messages, if included

Figure 4: Session Setup

3.1 Obtain Unicast Access Terminal Identifier (UATI) The Address Management Protocol in the Session Layer is responsible for obtaining it. The AT generates a 32 bit random number (also known as Session Seed) and includes it in the UATIRequest message sent to the AN. This session seed is identified as the Random Access Terminal Identifier (RATI) in the UATIRequest message.

3.1.1 AT requests UATI in an Access Channel capsule The AT requests the UATI from the AN by sending the UATIRequest message in an Access Channel capsule.

When the AT is in the idle 1xEV-DO Air Link state, it uses the Access Channel to send messages to the AN. The AT uses the access parameters specified in the AccessParameters message on the Forward Link, for sending the Access Channel capsule. Since the AT uses the default protocols and parameters pertaining to 1xEV-DO Release 0 Session in the initial stages, it is only able to understand the Release 0 specific parameters in the AccessParameters message.

The AT is required to include the RouteUpdate message every time it sends an Access Channel capsule. The RouteUpdate message provides the AN with the information about the serving pilot PN and the other pilots whose measured signal strength is strong enough to be considered for inclusion in the AT’s active set. The reception of the Access Channel capsule is acknowledged by the BTS by ACAck message.



The timestamp information for the OTA message can be used to identify the messages sent in the same Access Channel capsule.

3.1.1.1 Message and content – RouteUpdate Message from AT

This message is sent by the ‘In Use’ instance of the Default Route Update Protocol.

0x1076 1xEV Signaling Access Channel -- RouteUpdate Msg 1

2

header_rev = 1 (0x1) 3

num_options = 0 (0x0) 4

subtype = 0 (0x0) (subtype 0) 5

protocol_instance = 0 (0x0) (In Use) 6

protocol_type = 14 (0xe) (Route Update Protocol) 7

message_id = 0 (0x0) (RouteUpdate) 8

route_update 9

update 10

message_sequence = 0 (0x0) 11

reference_pilot_pn = 432 (0x1b0) 12

reference_pilot_strength = 1 (0x1) (-0.5 dB) 13

reference_keep = 1 (0x1) 14

num_pilots = 2 (0x2) 15

pilots[0] 16

pilot_pn_phase = 8448 (0x2100) (pilot_pn : 132, chips : 0, 17

pilot_inc : 4) 18

channel_included = 0 (0x0) 19

pilot_strength = 17 (0x11) (-8.5 dB) 20

keep = 1 (0x1) 21

pilots[1] 22

pilot_pn_phase = 26311 (0x66c7) (pilot_pn : 412, chips : -57, 23

pilot_inc : 4) 24


pilot_strength = 15 (0xf) (-7.5 dB) 26

keep = 1 (0x1) 27

3.1.1.2 Description of message

Line 5 to Line 7: As discussed in the Section 2.6, (i) the subtype field is used to identify the subtype of the protocol sending this message, (ii) the protocol_instance is used to identify the instance of the protocol sending the message, and (iii) the protocol_type is used to identify the 1xEV-DO protocol sending the message.

Line 8: The message_id field identifies the RouteUpdate message.

Line 11: The message_sequence is used by the AN to flag the duplicates and the stale messages. The first RouteUpdate message sent by the AT after powering up always has the message_sequence of 0. Subsequently, the AT increases the message_sequence by 1 every time it sends a new RouteUpdate message until it wraps around at 255.

Line 12: The reference_pilot_pn refers to the Pilot for which the AT sees the earliest multipath during the pilot search. This pilot may not be the Pilot with the strongest signal strength when the AT is monitoring the multiple pilots and hence may not be the serving Pilot. But frequently the serving pilot and the reference_pilot_pn are the same. Refer to Section 8.7.6.2.1 in [S1] for the decoding of OTA values for various fields in this message.

Line 13: The AT sets the reference_pilot_strength field to the reference pilot’s measured signal strength in dB.



Line 14: The reference_keep field is used by the AT to inform the status of the PilotDropTimer for the reference pilot at the AT. The value of 1 signifies that either the PilotDropTimer has not been started by the AT or otherwise, it has not expired. In other words, the pilot is good to remain in the Active Set.

Line 15: The num_pilots informs that the AT is including the information about 2 more pilots in the RouteUpdate message.

Line 17: The pilot_pn_phase field codes the information about the other pilots that are the likely candidate to be included in the AT’s Active and the Candidate Set. The AT measures the arrival time of the earliest usable multipath component (in terms of chips) for each pilot with reference to the AT’s time reference and report it to the AN. The AN uses this value and Pilot_Increment to compute the Pilot PN sequence code. The Pilot PN sequence code is 132 when computed using the Pilot Increment of 4.

Line 19: The channel_included field is used by the AT to include the channel information if the channel for the pilot specified in pilot_pn_phase is not the same as for the reference pilot. If set to 1, an additional field ‘Channel’ (24 bits) is included in the message. This Channel field contains the ‘System Type’, ‘Band Class’ and ‘Channel Number’ information [S1].

Line 20: The pilot_strength field reports the strength of the pilot (in dB) for the pilot_pn_phase in Line 17.

Line 21: The keep field is used by the AT to inform the status of the PilotDropTimer for this pilot at the AT.

Line 23, 25, 26 and 27: These fields are used to include the Pilot PN phase, pilot strength information for the second pilot included in this message. The Pilot PN phase value is 23611, which computes to PN code 412.

3.1.1.3 Message and content – UATIRequest Message from AT

The AT includes a RATI (Random ATI) in the UATIRequest when the AT does not have a valid 1xEV-DO Session. However, when the AT moves from one subnet to another and a new 1xEV-DO Session is established, the AT sends a UATIRequest message and it includes the current UATI in the MAC layer header.

In this example, the AT does not have a valid 1xEV-DO Session and hence it includes RATI in the MAC layer header (not shown in the message) of the Access Channel capsule. This message is sent by the ‘In Use’ instance of the Address Management Protocol in the Session Layer.

0x1076 1xEV Signaling Access Channel -- UATIRequest Msg 1

2





protocol_type = 17 (0x11) (Address Management Protocol) 7

message_id = 0 (0x0) (UATIRequest) 8

address_mgmt 9

uati_req 10

transaction_id = 1 (0x1) 11


Line 8: The message_id field identifies the UATIRequest message.

3.1.1.5 Message and content – ACAck Message from AN (BTS)

This message is sent by the Access Channel MAC Protocol at the BTS (AN) to acknowledge the reception of Access Channel capsule.



The AN shall respond within 96 slots (TACMPANProbeTimeout) to acknowledge the reception of the Access Channel capsule. Once the probe is transmitted, the AT uses the timer, TACMPATProbeTimeou (128 slots) and executes the inter-probe backoff procedure to derive the Access Channel Cycle for the transmission of the next probe. If the AT receives the response with in TACMPATProbeTimeout of the transmission of the probe, it cancels the transmission of next probe. Otherwise, the AT sends the next Access Channel probe of the same Access Sequence or the new Access Sequence in the derived Access Channel Cycle.

0x1078 1xEV Signaling Control Channel Directed -- ACAck Msg 1

2





protocol_type = 2 (0x2) (Access Channel MAC Protocol) 7

message_id = 0 (0x0) (ACAck) 8

ac_mac 9


Line 8: The message_id field identifies the ACAck message.

3.1.2 AN assigns UATI to the AT The AN sends the UATIAssignment message to the AT to assign the UATI. This is a directed signaling message and the AN schedules it to be sent in the Asynchronous Control Channel capsule. If the transmission of this message coincides with the broadcasting of the Synchronous Control Channel Capsule, the AN sends the message in that capsule. The AN includes the RATI sent by the AT in the MAC header. If there are sufficient unused bits in the Asynchronous Control Channel capsule, then the AN can use it to include additional messages such as HardwareIDRequest message in the same capsule.

3.1.2.1 Message and content – UATIAssignment Message from AN The UATIAssignment message is sent by the In Use instance of the Address Management Protocol in the AN.

0x1078 1xEV Signaling Control Channel Directed -- UATIAssignment Msg 1

2






message_id = 1 (0x1) (UATIAssignment) 8

address_mgmt 9

uati_assign 10


sub_net_included = 0 (0x0) 12

uati_color_code = 79 (0x4f) 13

uati_024 = 14785407 (0xe19b7f) 14

upper_old_uati_length = 0 (0x0) 15


Line 8: The message_id field identifies the UATIAssignment message.



Line 11: The message_sequence in the UATIAssignment is used by the AT to flag the duplicates. The very first UATIAssignment received by the AT shall have message_sequence of 0. Subsequent to that, the AN must increment the message_sequence by 1, every time it sends a new UATIAssignment message. If the same UATIAssignment message is transmitted, the AN shall not increment the message_sequence number.

Line 12: The sub_net_included field is set to 1 if the UATISubnetMask and UATI104 fields are included. When set to 0, the AT shall use the Subnet Mask (a mask of 1’s) and the SectorID field in the SectorParameters message to derive the SubnetMask Length most significant bits (typically 104 bits) of the UATI as shown in Figure 5. When the Sector whose Control Channel the AT is monitoring changes, the AT reads the new SectorParameters message and compares the 104 most significant bits of the UATI with the SectorID transmitted in the SectorParameters message. If they don’t match, the AT knows that the Subnet has changed and the AT requests a new UATI from the new Subnet.

0010101101101101101100101101 110101

Length of Subnet mask (‘n’ MSBs)

8 bit SubnetMask fromSectorParameters

128 bit Sector ID from SectorParameters

0010101101101101101100101101Subnet Address

1111111111111111111111111111

010111

24 bits (UATI_024)Subnet Address acts as

UATI_104

0010101101101101101100101101010111

128 bit UATI

0010101101101101101100101101 110101

Length of Subnet mask (‘n’ MSBs)

8 bit SubnetMask fromSectorParameters

128 bit Sector ID from SectorParameters

0010101101101101101100101101Subnet Address

1111111111111111111111111111

010111

24 bits (UATI_024)Subnet Address acts as

UATI_104

0010101101101101101100101101010111

128 bit UATI

Figure 5: Construction of UATI when 104 MSB are not provided in the UATIA

Line 13: The field specifies the color code associated with the subnet to which UATI belongs. The Color Code is included in the Access Channel MAC header along with the 24 least significant bits of the UATI in the signaling messages between the AT and the AN.

Line 14: The uati_024 is the 24 least significant bits of the UATI assigned to the AT. These bits are concatenated with either the uati_104 transmitted in this message or the derived 104 most significant bits from the SectorParameters message if the uati_104 field is not present in the UATIAssignment, to form the complete UATI.

Line 15: The upper_old_uati_length field specifies the number of least significant octets of UATI[127:24] that the AT shall send in the UATIComplete message.

3.1.2.3 Message and content – HardwareIDRequest Message from AN HardwareIDRequest message is sent by the ‘In Use’ instance of the Address Management Protocol in the AN. The AN might use the HardwareID for book-keeping purposes.

0x1078 1xEV Signaling Control Channel Directed -- HardwareIDRequest Msg 1

2








message_id = 3 (0x3) (HardwareIDRequest) 8

address_mgmt 9

hw_id_req 10



Line 8: The message_id field identifies the HardwareIDRequest message.

3.1.3 AT sends UATI Complete in an Access Channel Capsule The AT responds to UATIAssignment and HardwareIDRequest by sending UATIComplete and HardwareIDResponse messages. Since the AT has not established Air Link resources as yet, these messages are sent in an Access Channel capsule along with the RouteUpdate message. The reception of the UATIComplete message at the AN signals that the AT and the AN has established a 1xEV-DO Session. Subsequent to this, the AT and the AN can proceed to the second phase of the Session Negotiation, known as Session Configuration. The AT requires a traffic channel for the Session Configuration phase, for the optimal use of the Air-Link bandwidth. The AT sends the ConnectionRequest message to request the traffic channel in the same Access Channel capsule. The details of the Air Link traffic establishment are covered in Section 4.1.


This message is sent by the ‘In Use’ instance of the Route Update Protocol.


2







route_update 9

update 10







Line 8: The message_id field identifies the RouteUpdate message.

Line 11: Notice that the AT increases the message_sequence by 1 in this message. This is an indication to the AN that it is a new RouteUpdate message from the AT.

For the description of the remaining fields, refer to Section 3.1.1.1



3.1.3.3 Message and content – UATIComplete Message from AT

This message is sent by the ‘In Use’ instance of the Address Management Protocol in the AT. It includes the least significant octets of the UATI[127:24], if the AN requests it in the UATIAssignment message.

0x1076 1xEV Signaling Access Channel -- UATIComplete Msg 1

2






message_id = 2 (0x2) (UATIComplete) 8

address_mgmt 9

uati_comp 10


upper_old_uati_length = 0 (0x0) 12


Line 8: The message_id field identifies the UATIComplete message.

Line 11: The message_sequence is set to 0 in this message by the AT. This is first transmission of the UATIComplete message by the AT. It must be incremented (by 1) by the AT when it transmits the next UATIComplete message.

Line 12: The AT must set this field to 1 if the AN request the inclusion of the least significant octet of the old UATI[127:24]. Since the AN did not request it, the AT sets upper_old_uati_length to 0.

3.1.3.5 Message and content – HardwareIDResponse Message from AT

This message is sent by the In Use instance of the Address Management Protocol in the AT.

0x1076 1xEV Signaling Access Channel -- HardwareIDResponse Msg 1

2






message_id = 4 (0x4) (HardwareIDResponse) 8

address_mgmt 9

hw_id_resp 10


hardware_id_type = 65536 (0x10000) 12

hardware_id_length = 4 (0x4) 13

hardware_id_value[0] = 116 (0x74) 14


hardware_id_value[2] = 209 (0xD1) 16



Line 8: The message_id field identifies the ‘HardwareIDResponse’ message.

Line 12: The hardware_id_type specifies the type of the Hardware ID sent by the AT in the HardwareIDResponse. There are multiple options including ESN and MEID. In this case, AT includes ESN (type: 0x10000).



Line 13: The hardware_id_length specifies the length of the Hardware ID in number of octets.

Line 14 to Line 17: The hardware_id[0] to hardware_id[3] carries the 4 octet long ESN, hardware_id[0] carries the most significant and hardware_id[3] carries the lease significant octet.


This message is sent by the ‘In Use’ instance of the Access Channel MAC Protocol in the AN (BTS).


2







ac_mac 9





4. Session Configuration phase – Negotiation of Multiple Personalities

1xEV-DO Rev A introduced the concept of negotiating multiple sets of protocols, application subtypes and their parameters during the Session Configuration phase [S1] and [Q1]. Each negotiated set of protocols can be identified as personality. The AT and the AN can negotiate multiple personalities during the Session Configuration phase but they use only one of the personalities at any given time. The AN controls how many personalities will be negotiated, and the personality that is in use.

There are two stages in the negotiation of a single personality as shown in Figure 6:

• AT initiated stage

• AN initiated stage

ConfigurationRequests

SoftConfigurationCompletePersonalityIndexStore = ‘0’ (main), Continue = ‘1’

ConnectionClose

ConfigurationComplete


AT AN

AT Initiated Phase

AN Initiated Phase

ConfigurationResponses

Establish Air Link resources

Session is OPEN with default protocols, application subtypes & their default attribute values



SoftConfigurationCompletePersonalityIndexStore = ‘0’ (main), Continue = ‘1’,

SessionConfigToken = 0x1b7f

ConfigurationComplete




Session is OPEN with protocols, application subtype configured for Personality Index 1

Configuration of First (Main) Personality

Configuration of Second Personality

Number of ConfigurationRequest/ConfigurationResponse

messages are exchanged to negotiate Protocol Subtypes and the relevant attributes

Figure 6: High level call flow of Protocol Negotiation

For each personality that is configured the AT always sends ConfigurationRequest messages first, conveying information to the AN about the protocol subtypes and application subtypes it supports. The AN then chooses the protocol subtypes, and application subtypes it wants to negotiate. The ‘In



Use’ instance of the Session Configuration Protocol in the Session Layer provides the means to negotiate the protocol and application subtypes for each personality. Once the AT and the AN has agreed on the protocol subtypes for a given personality, different protocols in the AT proceed by proposing the non-default values for the attributes pertaining to the protocol subtypes.

It shall be noted that all attributes and their parameters have a well defined default values and the AT may choose to use those for the agreed set of protocol subtypes. But there are few parameters, where the default values cannot be used and these needs to be communicated to the AN. These include the parameters that the AT may assign every time it establishes a new 1xEV-DO Session (e.g., Preferred Control Channel Cycle) and the ones that provides the AT’s band support information to the AN. Only non-default parameters are negotiated or conveyed between the AT and the AN.

When the AT is finished with the configuration at its end, it communicates to the AN by sending the ConfigurationComplete message. Consequently, the AN begins to configure the non-default values of the various attributes of the negotiated protocol subtypes. The AN completes the configuration of the protocol subtypes (i.e., this personality) by sending the SoftConfigurationComplete message. If the AN wishes to negotiate protocol and application subtypes for another personality, it is communicated to the AT in the same SoftConfigurationComplete message. The generic call flow is shown in Figure 6.

4.1 ESTABLISHMENT OF AIR LINK RESOURCES The AT and the AN setup the Air Link traffic channel before starting the Session Configuration phase. The Session Setup and Session Configuration phase may be carried out back to back and hence the AT sends the ConnectionRequest message to set up the Air Link traffic channel along with the UATIComplete (belong to Session Setup) message in the same Access Channel capsule.

The call flow for the establishment of the Air-Link traffic channel is shown in Figure 7.

Traffic Channel is setup to Negotiate the protocols and configure the parameters

RouteUpdate/ConnectionRequest

ANAT

ACAck

TrafficChannelAssignment

RTCAck

Pilot and DRC

TrafficChannelComplete

Figure 7: Traffic Channel establishment call flow



4.1.1 AT requests Air Link resources The AT uses the ConnectionRequest message to establish the Air-Link traffic channel.

4.1.1.1 Message and content – ConnectionRequest Message from AT

This message is sent by the ‘In Use’ instance of the Idle State Protocol to request the Air Link resources from the AN.

0x1076 1xEV Signaling Access Channel -- ConnectionRequest Msg 1

2





protocol_type = 12 (0xc) (Idle State Protocol) 7

message_id = 1 (0x1) (ConnectionRequest) 8

idle_state 9

connect_req 10


request_reason = 0 (0x0) 12


Line 8: The message_id field identifies the ConnectionRequest message.

Line 12: The request_reason is used to notify the reason for the connection request. An AT can initiate the connection request either when the 1xEV-DO protocol stack in the AT wishes to exchange signaling messages with the AN or the AT wants to exchange user data with the IP servers in the packet data network. The AT can also initiate the connection request when it receives a Page message from the AN. The request_reason is set to 1 when the AT sends the connection request in response to a Page message. In other scenarios, it is set to 0.


This message is sent by the In Use instance of the Access Channel MAC Protocol in the AN (BTS).


2







ac_mac 9



4.1.2 AN allocates Air Link resource The AN allocates the resources for the traffic channel to the AT. It offers MAC Index, DRC Cover and the pilots to be included in the Active Set in the TrafficChannelAssignment message.



4.1.2.1 Message and content – TrafficChannelAssignment Message from AN This message is sent by the ‘In Use’ instance of the Route Update Protocol in the AN.

0x1078 1xEV Signaling Control Channel Directed -- TrafficChannelAssignment Msg 1

2






message_id = 1 (0x1) (TrafficChannelAssignment) 8

route_update 9

tc_assign 10



channel 13

system_type = 0 (0x0) 14

band_class = 1 (0x1) 15

channel_number = 50 (0x32) 16

frame_offset = 12 (0xc) 17

drc_length = 1 (0x1) 18

drc_channel_gain = 61 (0x3d) (-1.5 dB) 19

ack_channel_gain = 8 (0x8) (4.0 dB) 20


pilots[0] 22

pilot_pn = 432 (0x1b0) 23

softer_handoff = 0 (0x0) 24

mac_index = 61 (0x3d) 25

drc_cover = 1 (0x1) 26

rab_length = 2 (0x2) 27

rab_offset = 0 (0x0) 28


Line 8: The message_id field identifies the TrafficChannelAssignment message.

Line 11: Once again, the message_sequence is used by the AT to flag the duplicates. The first TrafficChannelAssignment sent by the AN in the Idle State carries the message_sequence of 0 and subsequently, it is incremented by 1 for every new transmission of TrafficChannelAssignment message in the Connected State.

Line 12: The channel_included field is set to 1 if the Channel information is included in this message. This is used to provide the RF channel information on which the traffic resources are offered.

Line 14: The system_type is used to identify the system. Refer to Section 14.1 in [S1] for more information on this.

Line 15: The band_class and channel_number are used to specify the Band Class and Channel Number on which the AT is assigned resources. Refer to [S4] for more information on this. In this example, the AT is assigned resources in Band Class 1, which is a PCS 1900 MHz band (1.8 GHz to 2.0 GHz). The Channel number assigned is 50 which is a 1.25MHz sub band with a center frequency of 1852.5 MHz. (1850 MHz + 0.050N, where N is the Channel Number).

Line 17: This field specifies the Frame Offset that the AT uses when transmitting the Reverse Traffic Channel. This offset is used by the AT to identify the slots in which it is allowed to change the DRC, DSC, RRI values and begin a new Reverse link physical layer payload (sub-packet) transmission. Refer to Section 8.7.6.2.2 in [S1] for the decoding of OTA values for various fields in this message.



Line 18: The drc_length specifies the number of slots over which the AT shall send the same DRC value. Refer to Table 8.7.6.2-1 in [S1] for the decoding of OTA values for DRCLength.

Line 19: The drc_channel_gain specifies the ratio of the power of the DRC channel to the power of the Reverse Pilot Channel. The DRC channel is used to report the SINR condition of the forward link at the AT and the sector in the Active set from which the AT wants to be served on the forward link.

Line 20: The ack_channel_gain specifies the ratio of the power of the ACK channel to the power of the Reverse Pilot Channel. The ACK channel is used to acknowledge the reception on the forward link.

Line 21: The num_pilots specify the count of the pilots to be included in the Active Set of the AT for this connection. The AN has included only one pilot.

Line 23: The pilot_pn identifies the Pilot’s PN code.

Line 24: The softer_handoff field is used by the AN to inform if the forward MAC channel associated with this pilot will communicate the same closed loop power control bit information as that of the previous pilot in this message. The first pilot in the message always has this field set to 0. If the next pilot belongs to the same cell, then this field is set to 1.

For example, if there are 5 pilots (1A, 1B, 2A, 2B, 2C; 1A, 1B belong to Cell 1 and 2A, 2B and 2C belong to Cell 2) in the Active Set of the AT, then these pilots must be included in the following order: 1A, 1B, 2A, 2B and 2C and the soft_handoff field shall be set as 0, 1, 0, 1, 1. This means that closed loop power control bit from 1A and 1B can be soft combined but not the others where the sector 1A belonging to Cell 1 is serving the AT.

Line 25: The mac_index field is used by the AN to send the directed forward link user data, RPC channel, ARQ and DRCLock channel to the AT. There are 63 MAC indices available in Release 0 (6 bits of this field) and 127 MAC indices are available in Rev A. MAC index in Rev A is formed by concatenating the 6 bits of this field with one bit of MACIndexMSB. This MACIndexMSB field is only included in the TrafficChannelAssignment by the Rev A AN if the AT is communicating in the Rev A mode.

It shall be noted that an AT is assigned a MAC index for each sector in the Active Set and it is possible that these MAC indices are different, but they may also be the same.

Since currently the AT is operating in the Release 0 mode, it can only be assigned a MAC index lower than or equal to 63.

Line 26: The drc_cover is an index associated with a sector. An AT is assigned a different DRCCover for each sector included in the TrafficChannelAssignment message. The AT applies the Walsh Code associated with the DRC cover to the DRC channel to point to the sector from which it wants to be served on the forward link.

Line 27: The rab_length is used by the AT if the resources assigned uses RTCMAC subtype 0 or 1. Refer to Table 8.7.6.2-2 in [S1] for the decoding of OTA values for RABLength.

Line 28: This field is only used with RTCMAC subtype 0 and 1. This parameter is set by the AN to indicate to the AT the starting slot of the Reverse Activity Bits from sectors.

4.1.3 AN acknowledges establishment of Reverse Air Link Once the AT receives the TrafficChannelAssignment, it begins to transmit the Pilot and the DRC channel on the Reverse Link. The DRC Channel conveys the DRC Rate that can be achieved in the current channel conditions for the serving forward link and the sector the AT wants to be served from. When the BTS receives the Pilot and DRC Channel, it sends back the RTCAck message on the Forward Traffic Channel to acknowledge the establishment of the Reverse Link. The RTCAck is the first message sent by the AN on the Forward Traffic Channel.

Note that the Pilot and the DRC channel transmissions by the AT are not described as these are not signaling messages.



4.1.3.1 Message and content – RTCAck Message from AN This message is sent by the ‘In Use’ instance of the Reverse Traffic Channel MAC Protocol in the AN.

0x1079 1xEV Signaling Forward Traffic Channel -- RTCAck Msg 1

2





protocol_type = 4 (0x4) (Reverse Traffic Channel MAC Protocol) 7

message_id = 0 (0x0) (RTCAck) 8

rtc_mac 9


Line 8: The message_id field identifies the RTCAck message.

4.1.4 AT acknowledges TCA and establishment of Forward Link Once the AT receives the RTCAck on the Forward Traffic Channel, it sends the TrafficChannelComplete message to the AN. Note that the AT also sends the first ConfigurationRequest message with the TrafficChannelComplete message in the same MAC packet but in this document the two messages are intentionally separated to differentiate between the 1xEV-DO Air Link connection establishment and Personality Negotiation parts of Session Configuration phase.

4.1.4.1 Message and content – TrafficChannelComplete Message from AT

This message is sent by the In Use instance of the Route Update Protocol in the AT.

0x1077 1xEV Signaling Reverse Traffic Channel -- TrafficChannelComplete Msg 1

2






message_id = 2 (0x2) (TrafficChannelComplete) 8

route_update 9

tc_complete 10



Line 8: The message_id field identifies the TrafficChannelComplete message.

4.2 Configuration of First (Main) Personality When the multiple personalities are configured between the AT and the AN, the first personality is always identified as the Main personality. When the multiple personalities are negotiated such that the protocol subtypes with their attributes are the same in the Main and another personality, then 1xEV-DO Rev A allows the protocol subtypes to be mapped to the Main Personality. This concept is known as HardLink and is discussed further during the configuration of Second Personality.



4.2.1 AT conveys protocol and application subtypes that it supports The Session Configuration Protocol in the AT sends the first ConfigurationRequest message, including all the protocol subtypes that it supports at lower 6 layers (see Figure 1) of 1xEV-DO protocol stack, the application subtypes it supports at 1xEV-DO application layer and the count of the personalities that it can configure and store. The protocol subtypes are uniquely identified by the attribute ID.

It shall be noted that the AT will not send a new ConfigurationRequest until it has received a response for this message. It may retransmit the same message if the response is not received after an implementation dependent timer. In other words, the AT must wait for the response from the AN for accepted protocol subtypes before configuring the parameters for the protocols.

4.2.1.1 Message and content – ConfigurationRequest Message from AT

This message is sent by the ‘In Use’ instance of the Session Configuration Protocol.

0x1077 1xEV Signaling Reverse Traffic Channel – ConfigurationRequest Msg 1





protocol_type = 18 (0x12) (Session Configuration Protocol) 6

message_id = 80 (0x50) (ConfigurationRequest) 7

8

ConfigurationRequest 9


num_attribs = 10 (0xa) 11

attribs[0] 12

attribute_id = 12 (0xc) (IdleStateProtocol Attribute) 13

num_recs = 1 (0x1) 14

protocol_subtype[0] = 1 (0x1) 15

attribs[1] 16

attribute_id = 0 (0x0) (PhysicalLayerProtocol Attribute) 17

num_recs = 1 (0x1) 18


attribs[2] 20

attribute_id = 3 (0x3) (ForwardTrafficChannelMACProtocol 21

Attribute) 22

num_recs = 1 (0x1) 23


attribs[3] 25

attribute_id = 4 (0x4) (ReverseTrafficChannelMACProtocol 26

Attribute) 27

num_recs = 2 (0x2) 28



attribs[4] 31

attribute_id = 27 (0x1b) (MultiModeCapabilityDiscovery 32

Attribute) 33

num_recs = 1 (0x1) 34


attribs[5] 36

attribute_id = 5 (0x5) (KeyExchangeProtocol Attribute) 37

num_recs = 1 (0x1) 38


attribs[6] 40

attribute_id = 6 (0x6) (AuthenticationProtocol Attribute) 41



num_recs = 1 (0x1) 42


attribs[7] 44

attribute_id = 8 (0x8) (SecurityProtocol Attribute) 45

num_recs = 1 (0x1) 46


attribs[8] 48

attribute_id = 4097 (0x1001) (ATSupportedApplicationSubtypes 49

Attribute) 50

num_recs = 1 (0x1) 51

at_supported_app_subtype_attrib[0] 52

value_id = 0 (0x0) 53

num_app_subtypes = 6 (0x6) 54

app_subtypes[0] = 1 (0x1) 55





app_subtypes[5] = 10 (0xa) 60

attribs[9] 61

attribute_id = 272 (0x110) (PersonalityCount Attribute) 62

num_recs = 1 (0x1) 63

personality_cnt[0] = 4 (0x4) 64

4.2.1.2 Description of message Line 7: The message_id = 0x50 indicates that this message is a ConfigurationRequest message.

Line 10: The transaction_id is used to keep track of the response tied to a request. It is always included in the ConfigurationRequest and ConfigurationResponse messages. In this example call flow, the increment of the transaction_id is protocol and message specific i.e. every time a new ConfigurationRequest is sent by a given protocol in the AT, the protocol increases the value by 1. If the same protocol sends a different message i.e. ConfigurationComplete, it starts afresh. The value of 0 for the first message is valid and in this specific flow, some protocol starts with 0 and some with 1. The AN can use the same logic for incrementing the transaction_id but in this example, the AN increments the transaction_id by 1 for every new ConfigurationRequest regardless of the protocol initiating the message.

Line 11: The num_attribs = 10 field indicates the number of attributes that are contained in this ConfigurationRequest message. First 8 attributes are simple attributes (4th is an attribute-list) and they describe the non-default protocol subtypes supported by the AT for different protocols. 9th attribute is a complex attribute and it lists the application subtypes supported by the AT. 10th attribute is a simple and it informs the maximum number of personalities that can be stored by the AT.

Line 13 to Line 47: The protocols are identified by a unique attribute_id in the Session Configuration Protocol. For the full list of Protocol IDs, Protocol and Application subtypes, refer to Table 11.1-1 and Table 11-1-2 in [S3]. The num_recs specifies the number of records for an attribute (protocol) and the protocol subtypes for a given protocol are specified in the order of preference. The list of the non-default protocol subtypes that the AT supports in first 8 attributes are:

• Enhanced Idle State Protocol (attribute_id = 0xc)

• Physical Layer Subtype 2 (attribute_id = 0x0)

• Enhanced Forward Traffic Channel MAC Protocol (attribute_id = 0x3)

• Subtype 3 RTCMAC and Subtype 1 RTCMAC, in order of preference (attribute_id = 0x4)

• Generic Multimode Capability Discovery Protocol (attribute_id = 0x1b)



• DH Key Exchange Protocol (attribute_id = 0x5)

• SHA-1 Authentication Protocol (attribute_id = 0x6)

• Generic Security Protocol (attribute_id = 0x8)

Line 49 to Line 53: The ninth attribute is a complex attribute and it identifies the AT Supported Application Subtypes and the AT assigns a value_id of 0 to the only record of application subtypes.

Line 54: The num_app_subtypes = 0x6 mentions the number of application subtypes supported by the AT other than Default Signaling Application. Note that the Default Packet Application is also included in this record.

Line 55 – 60: These application subtypes are

• 0x1: Default Packet Application bound to the radio network

• 0x2: Default Packet Application bound to the service network

• 0x3: Test Application [S5]

• 0x5: Multi-Flow Packet Application bound to the service network

• 0x9: Enhanced Multi-Flow Packet Application bound to the service network

• 0xa: Enhanced Test Application [S6]

Line 62: The tenth attribute identifies the Personality Count attribute and specifies that the AT can store a maximum of 4 personalities. When the Enhanced FTCMAC is supported by the AT, it is required that AT shall support a maximum of 4 personalities.

Note: In the subsequent messages description,

• The protocol_instance will identify the instance (‘In Use’ or ‘In Config’) sending the message

• The protocol_type will identify the protocol sending the message

• The subtype will identify the protocol subtype

• The num_recs will indicate the number of records included for an attribute. If it is a simple attribute with one value, then num_record will always be 1. If the num_record is used for a list attribute, then it will indicate the size of the list. If the num_record is used for the complex attribute, then it will indicate how many set of the complex attribute identified by the attribute_id are included.

In the subsequent descriptions, these 4 fields and the transaction_id will not be discussed.

4.2.1.3 Message and Content – ConfigurationResponse Message from AN The AN processes the ConfigurationRequest message and sends ConfigurationResponse message to the AT. The AN must respond within 2 second (TTurnaround) of receieving the ConfigurationRequest message. The AN specifies the protocol subtypes that it has accepted by including them explicitly in the response. Unaccepted attributes are not included in the response. It is possible that the AN may not accept any attribute or values proposed by the AT. In that case, the AN must send a ConfigurationResponse indicating that it has received the message but it is not accepting/negotiating the parameters.

Since the AN received this message from the Session Configuration Protocol in the AT, the ConfigurationResponse is sent by the ‘In Use’ instance of the Session Configuration Protocol at the AN.

0x1079 1xEV Signaling Forward Traffic Channel -- ConfigurationResponse 1








message_id = 81 (0x51) (ConfigurationResponse) 7

8

ConfigurationResponse 9


num_attribs = 2 (0x2) 11

attribs[0] 12

attribute_id = 272 (0x110) (PersonalityCount Attribute) 13

value_id = 4 (0x4) 14

attribs[1] 15

attribute_id = 4097 (0x1001) (ATSupportedApplicationSubtypes 16

Attribute) 17

value_id = 0 (0x0) 18


Line 7 and Line 11: The message_id = 0x51 indicates that this message is a ConfigurationResponse message and the AN has included 2 attributes (num_attribs = 2) in this message. This message only includes the attributes/parameters that it wants to negotiate/accept for this personality.

Line 13 and Line 14: The AN has accepted the Personality Count attribute. Note that the AN uses the value_id field to convey that it has accepted the proposed support of 4 simultaneous personalities by the AT.

Line 16 to Line 18: The second attribute included by the AN is the ATSupportedApplicationSubtypes. The AN chose the value_id that is acceptable and sends it in the ConfigurationResponse.

Additional note on value_id: In the case of attribute-list, the value_id assumes significance, when the initiator proposes multiple values. For example, in the previous message the AT included two values for RTC MAC protocol: Subtype 1 RTCMAC and Subtype 3 RTCMAC. If the AN wants to negotiate one of these, it would pick the value associated with the chosen protocol_subtype and set it to value_id.

In the case of complex attributes, the value_id identifies the record accepted by the receiver. The initiator ties a value_id to each record of a complex attribute in the ConfigurationRequest message. The receiver chose the acceptable record, picks the value_id associated with it and conveys it in the ConfigurationResponse back to the initiator. The use of the value_id allows the responder to include the single number as against the whole set of parameters in the response and thus optimizing the use of Air-Link resources.

4.2.2 AT initiated configuration of Default Idle State Protocol In 1xEV-DO system, there are 12 Control Channel (CC) Cycles and each AT hashes to one of the CC Cycles. A CC cycle is of 256 slots duration (426.67 ms) and these 12 CC cycles wraps around every 5.12 seconds. The AT wakes up in the assigned CC cycle to update the overhead information and receive pages. The assigned CC is derived by applying the Session Seed to a hashing algorithm. The session seed is sent to the AN (as RATI) in the UATIRequest message, which allows the AN to derive the designated CC by applying the same hashing algorithm.

However, for a hybrid device the derived CC cycle may overlap with the 1x Paging Slot during tune-always to the 1X system. The Hybrid AT chooses an alternative CC and uses the PreferredControlChannelCycle attribute to explicitly convey the CC cycle to the AN.

4.2.2.1 Message and Content – ConfigurationRequest Message

This message is sent by the ‘In Config’ instance of the Idle State Protocol.

0x1077 1xEV Signaling Reverse Traffic Channel -- ConfigurationRequest Msg 1

2






protocol_instance = 1 (0x1) (In Config) 6



9




attribs[0] 13

attribute_id = 0 (0x0) (PreferredControlChannelCycle) 14

num_recs = 1 (0x1) 15

pref_con_chn_cycle[0] 16

value_id = 1 (0x1) 17

pref_con_chn_cyc_enable = 1 (0x1) 18

pref_con_chn_cycle = 5 (0x5) 19


Line 8 and Line 14: The ConfigurationRequest message includes an attribute PreferredControlChannelCycle.

Line 18 and Line 19: The pref_con_chn_cycle_enable flag provides the information if the Preferred Control Channel Cycle is included or not. If it is set to 1, the Preferred Control Channel Cycle is included in the field, pref_con_chn_cycle.

4.2.2.3 Message and Content – ConfigurationResponse Message

This response is sent by the ‘In Config’ instance of the Idle State Protocol.

0x1079 1xEV Signaling Forward Traffic Channel -- ConfigurationResponse Msg 1

2







9




attribs[0] 13


value_id = 1 (0x1) 15

4.2.2.4 Description

Line 7 to Line 14: The ConfigurationResponse message conveys that the AN has accepted the value proposed by the AT for the Preferred Control Channel Cycle.

4.2.3 AT initiated configuration of Stream Protocol Stream Protocol support simultaneous existence of 4 streams between the AT and the AN to transport signaling messages, A12 access authentication data and higher layer user data (1xEV-DO packet application subtypes). The four streams are identified as Stream 0, 1, 2 and 3 Applications and they have an associated Protocol ID as shown in Table 4.



Table 4: Stream Application and the Protocol IDs

Stream Application Protocol ID Default Application binding (if any)

Stream 0 Application 0x14 Default Signaling Application2

Stream 1 Application 0x15 -



Stream 0 Application is always open, the rest of the streams are explicitly opened before they can carry the data, after the bindings have been established. The Protocol Ids discussed above, are used when messages are used to open these streams.

The StreamConfiguration attribute is used to establish the mapping between the 1xEV-DO application subtypes and the Stream Applications at the Stream Layer. Stream 0 Application is bound to the Default Signaling Application, the rest of the streams can be mapped to any application subtype. Refer to Table 11-1-2 in [S3] for the complete list of application subtypes.

For each personality negotiation, the AN must accept the ATs requested StreamApplication bindings if it intends to use the Application proposed by the AT. This allows the AT an opportunity to propose non-default values for configurable attributes of those applications.


This message is sent by the ‘In Config’ instance of the Stream Protocol.

2 Data carried by the Stream 0 Application has the highest priority.




2





protocol_type = 19 (0x13) (Stream Protocol) 7


9




attribs[0] 13

attribute_id = 0 (0x0) (StreamConfiguration) 14

num_recs = 3 (0x3) 15

stream_config[0] 16

value_id = 0 (0x0) 17

stream0_app = 0 (0x0) (Default Signaling Application) 18

stream1_app = 65535 (0xffff) (Stream not used) 19

stream2_app = 9 (0x9) (Enhanced Multiflow Packet Application 20

for Service Network) 21


stream_config[1] 23

value_id = 1 (0x1) 24



stream2_app = 5 (0x5) (Multiflow Packet Application for 27

Service Network) 28


stream_config[2] 30

value_id = 2 (0x2) 31



stream2_app = 2 (0x2) (Default Pkt App Bound to Service 34

Network) 35


4.2.3.2 Description of message Line 8, Line 14 and Line 15: The ConfigurationRequest message carries 3 records for attribute StreamConfiguration.

Line 17: The AT assigns a unique value ID to each set of stream configuration bindings. The initiator of the request always proposes the sets in order of preference and the first one has the higher preference than the following ones.

Line 18: The AT must use the field, stream0_app to establish the binding with the Default Signaling Application.

Line 19: The AT shall set this field to the subtype of the application (except Default Signaling Application) used over Stream 1 Application. Value of 0xffff implies that the stream will not be used.

Line 20: The AT specifies that the Stream 2 Application shall be bound to ‘Enhanced Multiflow Packet Application for Service Network’ to carry the Enhanced Multi Flow Packet Application data between the AT and the PDSN.

Line 22: The AT shall set this field to the subtype of the application used over Stream 3 Application and no mapping has been specified in this case.



Line 24 to Line 29: In the second set of proposed mappings (value_id of 1), the AT proposes a mapping of Stream 2 Application to carry the Multi Flow Packet Application data between the AT and the PDSN. The rest of the mappings are the same as in the first binding.

Line 31 to Line 36: In the third set of proposed mappings (value_id of 2), the AT proposes a mapping of Stream 2 Application to carry the Default Packet Application data between the AT and the PDSN. The rest of the mappings are the same as in the first binding.

4.2.3.3 Message and Content – ConfigurationResponse message

This response is sent by the ‘In Config’ instance of the Stream Protocol.


2










4.2.3.4 Description

Line 8 and Line 11: The ConfigurationResponse message indicates that there isn’t any attribute contained in this message. In other words, the AN has not accepted any bindings proposed by the AT.

It is important to know that the responder can only accept or reject the proposed values in the ConfigurationRequest message. It can not propose a new value or in this case, the bindings in the ConfigurationResponse. If it has different proposals, it must propose/configure in its designated stage of the Session Configuration. Typically, if the responder does not accept the proposed values and also does not propose a new value later for an attribute, then the default values are used. However, in the case of Stream Protocol, the AN must establish a binding for transporting the higher layer user data.AT initiated configuration of Route State Protocol

In certain network topologies, the AN may use multiple carriers in different bands to support the user traffic in a given sector. However, before the AN can allocate resources on the other available carriers and channels than the AT is using currently to communicate with the AN, it must know if the AT supports these channels or not. The AT uses the SupportedCDMAChannels attribute to convey this information to the AN.

4.2.3.5 Message and Content – ConfigurationRequest Message This response is sent by the ‘In Config’ instance of the Route Update Protocol.


2







9






attribs[0] 13

attribute_id = 4 (0x4) (SupportedCDMAChannels) 14

num_recs = 1 (0x1) 15

cdma_chans[0] 16

value_id = 0 (0x0) 17

band_class_count = 2 (0x2) 18

band_class[0] 19

bandclass = 0 (0x0) 20

band_sub_class_count = 2 (0x2) 21

band_sub_class[0] = 0 (0x0) 22


band_class[1] 24



4.2.3.6 Description of message Line 8 and Line 14: The ConfigurationRequest message is used to include the complex attribute SupportedCDMAChannels.

Line 18: The AT shall set this field to the number of occurrences of the Band Class field in this message.

Line 19 and Line 20: The band_class[0] refer to the first occurrence of Band Class and it identifies the Band Class 0 i.e., the 800 MHz (Cellular) band. Refer to [S4] for more information about the bands, the sub-bands and the channel numbers in Cellular and PCS bands.

Line 21: The access terminal shall set this field to the number of band sub classes supported by the access terminal in the 800 MHz Band Class.

Line 22: This refers to the first band sub class = 0 in which the RL and FL frequency pairs are:

• MS: 824.025 to 835.005 MHz; BS: 869.025 to 880.005 MHz

• MS: 844.995 to 846.495 MHz; BS: 889.995 to 891.495 MHz

Line 23: This refers to the second band sub class = 1 in which the RL and FL frequency pairs are:

• MS: 824.025 to 835.005 MHz; BS: 869.025 to 880.005 MHz

• MS: 844.995 to 848.985 MHz; BS: 889.995 to 893.895 MHz

Line 25: This identifies the second Band Class, which is 1800 MHz (PCS) band.

Line 26: There is no specific band sub class for this Band.


This response is sent by the ‘In Config’ instance of the Route Update Protocol.


2







9






4.2.3.8 Description

Line 7 to Line 12: The ConfigurationResponse message conveys that the AN has not accepted any attribute values proposed by the AT.

Note that the three ConfigurationRequest messages sent by the AT in the Section 0, 4.2.3.1 and 4.2.3.5 are sent by three different protocols but they can be bundled in a single transmission by the RTCMAC on the reverse link provided there are sufficient bits available in the payload.

4.2.4 Completion of AT initiated configuration of First Personality Once the AT has completed the configuration of protocols at its end, it sends a ConfigurationComplete message to the AN.

4.2.4.1 Message and Content – ConfigurationComplete Message


0x1077 1xEV Signaling Reverse Traffic Channel -- ConfigurationComplete Msg 1

2






message_id = 0 (0x0) (ConfigurationComplete) 8

9

session_config 10

config_comp 11


token_incl = 0 (0x0) 13


Line 8: The message_id = 0x0 indicates that this message is a ConfigurationComplete message.

Line 13: The token_incl =0 implies that the session configuration token is not included in this message. The AT never includes a token in the ConfigurationComplete message.

4.2.5 AN initiated configuration of Session Configuration Protocol After the AT initiated phase of the protocol configuration is completed, the AN begins to negotiate the attributes for protocol and application subtypes. It only configures the parameters pertaining to protocol and application subtypes, which were agreed during the AT initiated phase of the personality negotiation.

In this example, the AN begins with the configuration of the SupportGAUPSessionConfigToken attribute. The configuration of this attribute allows the AN and the AT to switch the personality later, when necessary. The AN and the AT uses Generic Attribute Update Protocol (GAUP) to switch the personality.



0x1079 1xEV Signaling Forward Traffic Channel -- ConfigurationRequest Msg 1



2







9




attribs[0] 13

attribute_id = 257 (0x101) (SupportGAUPSessionConfigToken) 14

num_recs = 1 (0x1) 15

support_gaup_session_config_token[0] = 1 (0x1) 16

4.2.5.2 Description Line 8 to Line 16: The ConfigurationRequest message includes an attribute, SupportGAUPSessionConfigToken to specify that the AN may choose to change the personality.


This response is sent by the ‘In Use’ instance of the Session Configuration Protocol.

0x1077 1xEV Signaling Reverse Traffic Channel -- ConfigurationResponse Msg 1

2







9




attribs[0] 13

attribute_id = 257 (0x101) (SupportGAUPSessionConfigToken) 14

value_id = 1 (0x1) 15

4.2.5.4 Description of message Line 7 to Line 15: The ConfigurationResponse message specifies that the AT has accepted the configuration of SupportGAUPSessionConfigToken.

4.2.6 AN initiated configuration of Access Channel MAC Protocol The AT uses the parameters received in the AccessParameters message for sending individual Access probes in the Access Channel Capsules. There are additional parameters which the AT requires for the Inter-Probe and Inter-Sequence Probe transmissions when the Access Probe transmissions are not acknowledged by the AN. These parameters assist the AT in deriving the time (in slots) between the two Access probes of the same/different sequence and the number of probe sequences [S1]. These parameters are configured by the AN using the Access Channel MAC Protocol during the Session Configuration phase.




This message is sent by the ‘In Config’ instance of the Access Channel MAC Protocol.


2







9




attribs[0] 13

attribute_id = 0 (0x0) (InitialConfig) 14

num_recs = 1 (0x1) 15

rec0[0] 16

value_id = 0 (0x0) 17

probe_sequence_max = 2 (0x2) 18

probe_backoff = 4 (0x4) 19

probe_sequence_backoff = 8 (0x8) 20

4.2.6.2 Description of message Line 8 to Line 17: The ConfigurationRequest message includes an attribute, InitialConfig, sent by the Access Channel MAC Protocol. The set of parameters are assigned a value_id of 0 by the AN.

Line 18: The probe_sequence_max specifies the maximum number of probe sequences for a single access attempt. The range of this parameter is 1 to 15 and the AN has proposed a value of 2 Probe sequences.

Line 19: The probe_backoff is the maximum backoff in units of AccessCycleDuration that the AT uses between the access probes within the same sequence. The AccessCycleDuration is specified in the AccessParameters message.

Line 20: The probe_sequence_backoff is the maximum backoff in units of AccessCycleDuration that the AT uses between two sequences of access probes.


This response is sent by the ‘In Config’ instance of the Access Channel MAC Protocol.


2







9




attribs[0] 13



attribute_id = 0 (0x0) (InitialConfig) 14

value_id = 0 (0x0) 15

4.2.6.4 Description Line 14 and Line 15: These fields specify that the AT has accepted the values conveyed in the complex attribute to set the Access Channel MAC protocol parameters

4.2.7 AN initiated configuration of Forward Traffic Channel MAC Protocol

The AT changes the DRC cover when it handoffs from one sector to another. Depending on the handoff, the data source can be switched within the BTS (Softer handoff) or across the BTSs (Soft Handoff). The AN processes the handoff requests by acting on the DRC cover and it involves a processing delay in setting up those queues and hence results in an outage for data transmission between the AT and the AN. The HandoffDelays attribute provides the information about the minimal delay in transferring the queues in different handoff situations.


This message is sent by the ‘In Config’ instance of the Forward Traffic Channel MAC Protocol.


2





protocol_type = 3 (0x3) (Forward Traffic Channel MAC Protocol) 7


9




attribs[0] 13

attribute_id = 0 (0x0) (HandoffDelays) 14

num_recs = 1 (0x1) 15

handoff_delays[0] 16

value_id = 0 (0x0) 17

softer_handoff_delay = 8 (0x8) 18

soft_handoff_delay = 16 (0x10) 19

4.2.7.2 Description of message Line 8 to Line 17: The ConfigurationRequest message includes an attribute, HandoffDelays, sent by the Forward Traffic Channel MAC Protocol. The set of parameters are assigned a value_id of 0.

Line 18: The softer_handoff_delay specifies the minimum interruption that the AT should expect when switching DRC within the same BTS. This parameter specifies the outage in terms of slots (unit of 8 slots) and it does not include the time the AT sends the Null DRC cover during the sector switching. In this case, it is 64 slots = 106.67ms.

Line 19: The soft_handoff_delay specifies the minimum interruption that the AT should expect when switching DRC across Base Stations. This parameter specifies the outage in terms of slots (unit of 8 slots) and it does not include the time the AT sends the Null DRC cover during the sector switching. In this case, it is 128 slots = 213.34ms.




This response is sent by the ‘In Config’ instance of the Forward Traffic Channel MAC Protocol.


2





protocol_type = 3 (0x3) (Forward Traffic Channel MAC Protocol) 7


9




attribs[0] 13


value_id = 0 (0x0) 15

4.2.7.4 Description of message Line 7 to Line 15: These fields specify that the AT has accepted the values conveyed in the complex attribute to set the Forward Traffic Channel MAC protocol parameters.

4.2.8 AN initiated configuration of Reverse Traffic Channel MAC Protocol

The RTC MAC Subtype 0 allows the AT to transmit the user data at 5 different bit rates: 9.6 kbps, 19.2 kbps, 38.4 kbps, 76.8 kbps and 153.kbps. The ATs initial maximum transmission rate is 9.6 kbps when it is assigned resources and later the maximum transmission rate is increased by including the assigned MAC index and revised maximum transmission rate in the BroadcastReverseRateLimit message, or by sending a UnicastReverseRateLimit message to the AT. Subsequent to that, the AT’s reverse maximum transmission rate takes into consideration the RAB bits sent by the AN. The AT interprets the RAB bit and given the current loading status, it either increases, decreases or maintains the maximum transmission data rate. Basically, if the RAB bit indicates that the sector is loaded, then the AT either decreases the maximum transmission rate or does not change it at all. Similarly, if the RAB bit indicates that the sector is unloaded, it may increase the maximum transmission data rate or maintains the same. Whether the AT shall change or not, is a result of the random experiment based on the probability values associated with each data rate transition. It should be noted though that the maximum data rate either doubles (increase) or halves (decrease) as a consequence of a single experiment.


This message is sent by the ‘In Config’ instance of the Reverse Traffic Channel MAC Protocol.


2







9






attribs[0] 13

attribute_id = 1 (0x1) (RateParameters) 14

num_recs = 1 (0x1) 15

rate_params[0] 16

value_id = 0 (0x0) 17

transition009k6_019k2 = 192 (0xc0) 18

transition019k2_038k4 = 192 (0xc0) 19

transition038k4_076k8 = 64 (0x40) 20

transition076k8_153k6 = 32 (0x20) 21

transition019k2_009k6 = 64 (0x40) 22

transition038k4_019k2 = 64 (0x40) 23

transition076k8_038k4 = 128 (0x80) 24

transition153k6_076k8 = 255 (0xff) 25

4.2.8.2 Description of message Line 8 to Line 15: The ConfigurationRequest message includes a complex attribute ‘RateParameters’ to specify the probability values for the maximum rate transitions.

Line 18 to Line 21: The fields transition009k6_019k2, transition019k2_038k4, transition038k4_076k8 and transition076k8_153k6 are used when the RAB channel indicates that the RL is not loaded. These are used during the random experiment to increase the maximum data rate from the current to the next higher transmission data rate. For example, transition009k6_019k2 specifies the probability the AT uses to increase the transmission rate from 9.6 kbps to 19.2 kbps, if the AT is currently transmitting at a maximum data rate of 9.6 kbps.

Line 22 to Line 25: The fields transition019k2_009k6, transition038k4_019k2, transition076k8_038k4 and transition153k6_076k8 are used when the RAB channel indicates that the RL is loaded. These are used during the random experiment to decrease the maximum data rate from the current to the next lower transmission data rate. For example, transition153k6_076k8 specifies the probability the AT uses to decrease the transmission rate from 153.6 kbps to 76.8 kbps, if the AT is currently transmitting at a maximum data rate of 153.6 kbps.


This response is sent by the ‘In Config’ instance of the Reverse Traffic Channel MAC Protocol.


2







9




attribs[0] 13

attribute_id = 1 (0x1) (RateParameters) 14

value_id = 0 (0x0) 15



4.2.8.4 Description of message Line 7 to 15: These fields specify that the AT has accepted the values conveyed in the complex attribute to set the Reverse Traffic Channel MAC protocol transition probabilities.

4.2.9 AN initiated configuration of Route Update Protocol The AT uses the Search Window Size to obtain the multipaths of the pilots in the Active, Candidate, Neighbor and Remaining sets. The AT also needs Pilot Increment to tune the searcher for obtaining the pilot’s multipaths. The Pilot search information is provided by the AN in the SearchParameters attribute. Further, the AN provides threshold values for the PilotAdd, PilotDrop, and PilotCompare parameters which the AT uses to manage the pilots in the various sets (Active, Candidate, etc.) on the same channel as the serving pilot and on the different channel than the serving pilot. These are provided in the SetManagementSameChannelParameters and SetManagementDifferentChannelParameters complex attributes. Lastly, if the AN desires to change these thresholds after the 1xEV-DO Session has been negotiated and committed, it can do so by sending the AttributeOverride message. The values specified in the AttributeOverride message are valid only for the duration of the Air-link connection. The AN must configure the SetManagementOverrideAllowed attribute before it can send that message to change the parameters. All the above discussed attributes are handled by the Route Update Protocol and their configuration is discussed below.

It is recommended that the AN should bundle these attributes in a single ConfigurationRequest message. The bundling is desirable for configuration of attributes belonging to the same protocol.


This message is sent by the ‘In Config’ instance of the Route Update Protocol to configure SearchParameters attribute.


2







9




attribs[0] 13

attribute_id = 0 (0x0) (SearchParameters) 14

num_recs = 1 (0x1) 15

param[0] 16

value_id = 0 (0x0) 17

pilot_increment = 3 (0x3) 18

search_window_active = 8 (0x8) 19

search_window_neighbor = 8 (0x8) 20

search_window_remaining = 0 (0x0) 21

attribs[1] 22

attribute_id = 1 (0x1) (SetManagementSameChannelParameters) 23

num_recs = 1 (0x1) 24

chan_params[0] 25

value_id = 0 (0x0) 26

pilot_add = 18 (0x12) 27



pilot_compare = 2 (0x2) 28

pilot_drop = 22 (0x16) 29

pilot_drop_timer = 3 (0x3) 30

dynamic_thresholds = 0 (0x0) 31

neighbor_max_age = 0 (0x0) 32

attribs[2] 33

attribute_id = 2 (0x2) (SetManagementDifferentChannelParameters) 34

num_recs = 1 (0x1) 35

chan_params[0] 36

value_id = 0 (0x0) 37

pilot_add = 18 (0x12) 38

pilot_compare = 5 (0x5) 39

pilot_drop = 22 (0x16) 40

pilot_drop_timer = 3 (0x3) 41

dynamic_thresholds = 0 (0x0) 42

neighbor_max_age = 0 (0x0) 43

attribs[3] 44

attribute_id = 3 (0x3) (SetManagementOverrideAllowed) 45

num_recs = 1 (0x1) 46

override_allowed[0] = 1 (0x1) 47

4.2.9.2 Description of message Line 8 and Line 12: The ConfigurationRequest message contains four attributes used by the AT for the management of pilots in the Active, Candidate, Neighbor and Remaining sets.

Line 18: The pilot_increment specifies the Pilot Sequence Increment in units of 64 PN chips.

Line 19: This parameter specifies the search window size for the Pilots in the Active and the Candidate Set.

Line 20 and Line 21: These parameters specify the search window sizes for the Pilots in the Neighbor Set and the Remaining Set. Refer to Table 8.7.6.2-4 in [S1] for the decoding of OTA values.

Line 27: The pilot_add is used by the AT to trigger a RouteUpdate in the connected state. Refer to Section 8.7.7.2 of [S1] for more information on the decoding of fields in this attribute.

Line 28: This is used by the AT for comparing the strength of the Pilots in the Active Set and the Candidate Set. The At sends a Route Update message when the strength of the Pilot in the Candidate Set exceeds the strength of the Pilot in the Active Set by this margin.

Line 29: The pilot_drop is used by the AT to start the Pilot Drop Timer for the Pilots in the Active and the Candidate Set.

Line 30: This is the timer which is started by the AT when a Pilot in the Active and the Candidate set when the strength of the pilot drops below the pilot_drop. If the time expires and the strength of the pilot does not go above pilot when the timer is running, the AT send a Route Update message if the Pilot is a member of the Active Set. If the Pilot is a member of the Candidate set, the pilot is moved to the Neighbor set. Refer to Table 8.7.7.2.2-1 for the decoding of OTA values in this field.

Line 31: If dynamic_thresholds is set to 1, this attribute includes additional parameters (SoftSlope, AddIntercept and DropIntercept) that are used by the AT tor pilot set managements. In this case, it is set to 0 and hence parameters are not included.

Line 32: This parameter specifies the maximum age of the Pilot in the Neighbor Set. This parameter is used for managing the pilots in the Neighbor Set.

Line 34 to Line 43: These fields are used to specify the parameters for Pilot on a different carrier. Refer to description in Line 20 to Line 32 above for information about the fields.



Line 44 to Line 47: The AN uses the fourth attribute, SetManagementOverrideAllowed to specify that the AT must act upon the Set Management parameters sent in the AttributeOverride message.


This response is sent by the ‘In Config’ instance of the Route Update Protocol.


2







9




attribs[0] 13

attribute_id = 0 (0x0) (SearchParameters) 14

value_id = 0 (0x0) 15

attribs[1] 16

attribute_id = 1 (0x1) (SetManagementSameChannelParameters) 17

value_id = 0 (0x0) 18

attribs[2] 19

attribute_id = 2 (0x2) (SetManagementDifferentChannelParameters) 20

value_id = 0 (0x0) 21

attribs[3] 22

attribute_id = 3 (0x3) (SetManagementOverrideAllowed) 23

value_id = 1 (0x1) 24


Line 7: The ConfigurationResponse message conveys that the AT has accepted the parameters specified in all four attributes.

4.2.10 AN initiated configuration of Session Management Protocol The AT and the AN negotiates the duration of the 1xEV-DO Session by exchanging the SMP Close Time attribute. Session is expired if no communication between the AT an th AN for TSMPClose time. This attribute is always configured by the AN and defines the maximum time for which the AN maintains the Session information (UATI and Personalities) about the AT, without exchanging any signaling or user traffic. 1xEV-DO also provides a mechanism to restart the SMP Close Timer by sending the KeepAlive messages.


This message is sent by the ‘In Config’ instance of the Session Management Protocol.


2





protocol_type = 16 (0x10) (Session Management Protocol) 7




9




attribs[0] 13

attribute_id = 255 (0xff) (SMP Close Time) 14

num_recs = 1 (0x1) 15

smp_close_time[0] = 720 (0x2d0) 16


Line 8 to Line 16: The ConfigurationRequest message carries simple attribute ‘SMP Close Time’ to specify that the SMP Close (1xEV-DO Session) time is set to 720 minutes.


This response is sent by the ‘In Config’ instance of the Session Management Protocol.


2







9




attribs[0] 13

attribute_id = 255 (0xff) (SMP Close Time) 14

value_id = 720 (0x2d0) 15


Line 7 to Line 15: The ConfigurationResponse message conveys that the AT has accepted the 1xEV-DO Session duration set by the AN.

4.2.11 AN initiated configuration of Stream Protocol Recall that the AN did not accept the proposed bindings during the AT initiated phase of the First Personality negotiation. It is either because the AN wanted the AT to (i) use the default bindings or the AN wanted to (ii) define additional new bindings or (iii) re-define the proposed bindings. In this case, it turns out that the AN wanted to define Stream01 application to carry the AN-AAA authentication data. It is configured using the StreamConfiguration attribute in the Stream Protocol.




2









9




attribs[0] 13


num_recs = 1 (0x1) 15

stream_config[0] 16

value_id = 0 (0x0) 17


stream1_app = 1 (0x1) (Default Pkt App Bound to Access 19

Network) 20

stream2_app = 2 (0x2) (Default Pkt App Bound to Service 21

Network) 22


4.2.11.2 Description of message Line 8 to Line 17: The ConfigurationRequest message carries a complex attribute, ‘StreamConfiguration’ to specify the stream bindings.

Line 18: The AN specifies in stream0_app field that Stream 0 will carry the ‘Default Signaling Application’ data.

Line 19: The AN specifies in stream1_app field that Stream 1 will carry data handled by the ‘Default Packet Application bound to Access Network’. This implies that this stream will carry the authentication messages between the AT and AAA. In this case, the AN-AAA will use the A12 interface to authenticate the AT.

Line 21: The AN specifies in stream2_app field that Stream 2 will carry data handled by the ‘Default Packet Application for Service Network’. In other words, this stream will carry data between the Default packet application at AT and the PDSN.

Line 23: The AN specifies in stream3_app field that Stream 3 (with a value of 0xffff) will not be used for any traffic between the AT and the AN.




2







9




attribs[0] 13


value_id = 0 (0x0) 15



4.2.11.4 Description of message Line 7 to Line 15: The ConfigurationResponse message conveys that the AT has accepted the bindings proposed by the AN.

4.2.12 Completion of First Personality Negotiation When the AN is finished with the configuration of protocols and parameters at its end, it sends a SoftConfigurationComplete message to the AT. In this message, it also indicates to the AT whether to proceed with the negotiation of a second personality or not through the Continue field. Finally, the AN also tags the personality negotiated with the Personality Index number field.

At the reception of the SoftConfigurationComplete message from the AN, AT must check if the personality is valid. The AT must close the 1xEV-DO Session if any of the conditions are true

(i) At least one packet application is not negotiated in the Stream Protocol,

(ii) MFPA or EMFPA is negotiated but RTCMAC Subtype 3 is not negotiated, and

(iii) MFPA or EMFPA is negotiated in the Main Personality, the Stream Protocol is hard-linked in another personality but RTCMAC subtype 3 is not hard-linked [Q1].

Note that in this illustration, the AT and the AN negotiated parameters for a few protocols only. Even for those protocols, not all the parameters were configured. The AT and the AN continue to use the default protocols and parameters for all the protocols and the parameters which are not negotiated during the establishment of this personality. The set of protocols and parameters that are configured may vary from operator to operator and device vendor to vendor.

4.2.12.1 Message and Content – SoftConfigurationComplete Message


0x1079 1xEV Signaling Forward Traffic Channel -- SoftConfigurationComplete Msg 1

2






message_id = 2 (0x2) (SoftConfigurationComplete) 8

9

session_config 10

sft_config_comp 11


personality_index_store = 0 (0x0) 13

cont = 1 (0x1) 14

4.2.12.2 Description of message Line 8: The message_id identifies the SoftConfigurationComplete message.

Line 13: The personality_index_store = 0 indicates the index that the AN has assigned an index 0 to this personality. The AN uses this index in the future communication with the AT.

Line 14: The cont field is used by the AN to signal if it wants the AT to continue negotiation of the next personality. When cont = 1, it implies that the AT must start negotiation of the second personality.

Summary of the protocol subtypes, application subtypes and parameters negotiated for First (Main) personality in shown in Table 5, Table 6 and Table 7.



Table 5: Summary of Protocols negotiated for First Personality

Protocol Type Protocol

Subtypes proposed by AT

Subtypes configured for this

personality Attributes configured

Physical Layer Subtype 2 Subtype 0 -

Control Channel MAC Protocol

- Default CCMAC -

Access Channel MAC Protocol

- Default ACMAC InitialConfig

Forward Traffic MAC Protocol

Enhanced FTCMAC

Default FTCMAC HandoffDelays

Reverse Traffic MAC Protocol

Subtype 3 and Subtype 1

Subtype 0 RateParameters

Key Exchange Protocol DH Key Protocol Default Key Exchange Protocol

-

Authentication Protocol SHA-1 Authentication Protocol

Default Authentication

-

Encryption Protocol Default Encryption Protocol

-

Security Protocol Generic Security Protocol

Default Security Protocol

-

Packet Consolidation Protocol

- Default Packet Consolidation

-

Air Link Management Protocol

- Default Air Link Management

-

Initialization State Protocol

- Default Initialization State Protocol

-

Idle State Protocol Enhanced Idle State Protocol

Default Idle State Protocol

PreferredControlChannelCycle

Connected State Protocol

- Default Connected State Protocol

-

Route Update Protocol - Default Route Update Protocol

SearchParameters

SetManagementSameChannelParameters

SetManagementDifferentChannelParameters

SetManagementOverrideAllowed

Overhead Messages Protocol

- Default Overhead Messages Protocol-

-



Protocol Type Protocol

Subtypes proposed by AT

Subtypes configured for this

personality Attributes configured

Session Management Protocol

- Default Session Management

SMP Close Time

Session Configuration Protocol

- Default Session Configuration

SupportGAUPSessionConfigToken

Address Management Protocol

- Default Address Management

Stream Protocol - Default Stream Protocol

StreamConfiguration

Multimode Capability Discovery Protocol

Generic Multimode Capability Protocol

Multimode Capability Discovery

Table 6: Application subtypes supported by AT

AT Supported Application Subtypes

0x1

0x2

0x3

0x5

0x9

0xa

Default Packet Application bound to the radio network (A12 Authentication)

Default Packet Application bound to the service network

Test Application

Multi-Flow Packet Application bound to the service network

Enhanced Multi-Flow Packet Application bound to the service network

Enhanced Test Application

Table 7: Stream Application bindings

Configured Stream bindings for Application Subtypes

Stream 0 Application Default Signaling Application

Stream 1 Application Default Packet Application bound to the radio network (0x1)

Stream 2 Application Default Packet Application bound to the service network (0x2)

Stream 3 Application Unused (0xffff)

4.3 Second Personality Negotiation The AT begins with the negotiation of the Second Personality when requested by the AN in the SoftConfigurationComplete. As mentioned earlier, there are two stages of a personality negotiation – the AT initiated stage and the AN initiated stage. The AT includes the list of all the non-default protocol subtypes that it supports. This allows the AN to choose the ones to be configured for this personality. It also proposes the HardLink subtype for a given protocol if the subtype and the parameters negotiated



during the Main personality are acceptable to it for the new personality. The Session Configuration Protocol is always hard linked in all personalities with PersonalityIndex greater than 0. The Session Configuration Protocol is a special case that despite being hard-linked, it allows the protocol subtypes to differ between the main personality and the personality under consideration. However, hard linking enables the AT to not include the list of application subtypes supported and the PersonalityCount attribute in the first ConfigurationRequest message, when the configuration of the new personality starts. As far as the application subtypes are concerned, they assume importance when the Stream Applications are bound in the Stream Protocol. The AT and the AN can still proceed with the proposals for different stream bindings during this negotiation of a second personality.

4.3.1 AT initiated negotiation of Protocol subtypes for the Second Personality

Session Configuration Protocol sends the first message, listing the protocol subtypes the AT wants to negotiate for this personality.




2







9




attribs[0] 13


num_recs = 1 (0x1) 15


attribs[1] 17


num_recs = 1 (0x1) 19


attribs[2] 21


Attribute) 23

num_recs = 1 (0x1) 24


attribs[3] 26


Attribute) 28

num_recs = 2 (0x2) 29



attribs[4] 32

attribute_id = 27 (0x1b) (MultiModeCapabilityDiscovery 33

Attribute) 34

num_recs = 1 (0x1) 35




attribs[5] 37


num_recs = 1 (0x1) 39


attribs[6] 41


num_recs = 1 (0x1) 43


attribs[7] 45


num_recs = 1 (0x1) 47


attribs[8] 49

attribute_id = 19 (0x13) (StreamProtocol Attribute) 50

num_recs = 1 (0x1) 51

protocol_subtype[0] = 65535 (0xfffe) 52


Line 14 to Line 48: The AT includes the 9 non-default protocol subtypes that it supports in 8 attributes. These include

• Enhanced Idle State Protocol

• Physical Layer Subtype 2

• Enhanced Forward Traffic Channel MAC Protocol

• Subtype 3 RTCMAC and Subtype 1 RTCMAC (in order of preference)

• Generic Multimode Capability Discovery Protocol

• DH Key Exchange Protocol

• SHA-1 Authentication Protocol

• Generic Security Protocol

Line 50 and 52: Finally the AT proposes to HardLink the Stream Protocol with the first personality. Remember that the AN and the AT negotiated a set of bindings between the application subtypes and the Stream application in Section 4.2.11. By hand linking, the AT is proposing that those bindings are acceptable for this personality as well.




2







9




attribs[0] 13




value_id = 2 (0x2) 15

attribs[1] 16


Attribute) 18

value_id = 1 (0x1) 19

attribs[2] 20


Attribute) 22

value_id = 3 (0x3) 23


Line 8: The message_id = 0x51 indicates that this message is a ConfigurationResponse message.

Line 8 & 11: The AN only accepts 3 attributes in the ConfigurationResponse message.

Line 14 to 23: The AN accepts

• Physical Layer Subtype 2 Protocol

• Enhanced Forward Traffic Channel MAC Protocol

• Subtype 3 RTCMAC Protocol

Note that the AN has not accepted the hard linking of the Stream Protocol. This enables the AT to propose an alternate Stream binding for this personality, than the one configured for the previous personalities.

4.3.2 AT initiated configuration of Idle State Protocol The AT proposes a Preferred Control Channel Cycle of 5 for the Second Personality.




2







9




attribs[0] 13


num_recs = 1 (0x1) 15

pref_con_chn_cycle[0] 16

value_id = 2 (0x2) 17

pref_con_chn_cyc_enable = 1 (0x1) 18

pref_con_chn_cycle = 5 (0x5) 19


Refer to Section 0 for description of the fields in this message.






2







9




attribs[0] 13


value_id = 2 (0x2) 15


Refer to Section 4.2.2.4 for description of the fields in this message.

4.3.3 AT initiated configuration of Stream Protocol The AT uses StreamConfiguration attribute to establish the mappings between the 1xEV-DO application subtypes and the Stream Applications at the Stream Layer. Since the AT and the AN agreed on using the Default Packet Application for transporting the higher layer user data in the First personality and the AN did not accept the hard linking of the bindings with the first personality, the AT only proposes the bindings different than the Default Packet Application in this personality.




2







9




attribs[0] 13


num_recs = 2 (0x2) 15

stream_config[0] 16

value_id = 0 (0x0) 17





stream2_app = 9 (0x9) (Enhanced Multiflow Packet Application 20

for Service Network) 21


stream_config[1] 23

value_id = 1 (0x1) 24



stream2_app = 5 (0x5) (Multiflow Packet Application for 27

Service Network) 28



Refer to the description in Section 4.2.3 for more information on fields in this message.

4.3.3.3 Message and Content – ConfigurationResponse message



2







9




attribs[0] 13


value_id = 0 (0x0) 15

4.3.3.4 Description of message Line 9 to Line 15: The ConfigurationResponse message conveys that the AN has accepted the bindings proposed in the first record by the AT. This allows the AT to configure the parameters for Enhanced Multi-Flow Packet Application.

4.3.4 AT initiated configuration of Route Update Protocol The AT conveys the band and channel information to the AN in the SupportedCDMAChannels attribute.


This message is sent by the ‘In Config’ instance of the Route Update Protocol.


2









9




attribs[0] 13

attribute_id = 4 (0x4) (SupportedCDMAChannels) 14

num_recs = 1 (0x1) 15

cdma_chans[0] 16

value_id = 0 (0x0) 17

band_class_count = 2 (0x2) 18

band_class[0] 19





band_class[1] 24






This message is sent by the ‘In Config’ instance of the Route Update Protocol.


2







9






4.3.5 AT initiated configuration of RTCMAC Subtype 3 Protocol The AT conveys the number of MAC flows that it can support simultaneously in the MaxMACFlows.


This message is sent by the ‘In Config’ instance of the Subtype 3 RTCMAC Protocol.


2







protocol_type = 4 (0x4) (Subtype 3 Reverse Traffic Channel MAC 7

Protocol) 8


10




attribs[0] 14

attribute_id = 20 (0x14) (MaxMACFlows) 15

sub3_rtc_mac 16

num_recs = 1 (0x1) 17

max_mac_flow[0] 18

value_id = 0 (0x0) 19

max_num_mac_flows = 5 (0x5) 20

max_num_active_mac_flows = 5 (0x5) 21


Line 9 to Line 15: The ConfigurationRequest message includes one instance of a complex attribute ‘MaxMACFlows’ in the RTCMAC Protocol.

Line 20: The max_num_mac_flows parameter is used to describe the maximum number of activated and deactivated flows that AT can support.

Line 21: The max_num_active_mac_flows is used by the AT to specify the maximum number of activated MAC flows that AT can support.




2






Protocol) 8


10




attribs[0] 14

attribute_id = 20 (0x14) (MaxMACFlows) 15

value_id = 0 (0x0)16

4.3.5.4 Description of message Line 9 to Line 16: The ConfigurationResponse message conveys that the AN has accepted the information in the MaxMACFlows attribute.



4.3.6 AT initiated configuration of Enhanced Multi-Flow Packet Application

The Enhanced Multi-Flow packet application conveys the number of link flows, reservations, the support for Route Selection Protocol, state of the forward and reverse Flow 00 (Best Effort), the protocols supported at the Flow Protocol and the Route Protocol in 7 different attributes to the AN.


This message is sent by the ‘In Config’ instance of the Enhanced Multi-Flow Packet Application.


2



subtype = 9 (0x9) (subtype 8 or 9 if protocol type is 0x15-0x17) 5


protocol_type = 22 (0x16) (Enhanced Multi-Flow Packet Application) 7





attribs[0] 12

attribute_id = 4 (0x4) (MaxLinkFlows) 13

num_recs = 1 (0x1) 14

Max_link_flow[0] 15

value_id = 1 (0x1) 16

max_num_link_flow_fwd = 31 (0x1f) 17

max_num_link_flow_rev = 31 (0x1f) 18

max_activated_link_flow_fwd = 8 (0x8) 19

max_activated_link_flow_rev = 8 (0x8) 20

attribs[1] 21

attribute_id = 5 (0x5) (MaxReservations) 22

num_recs = 1 (0x1) 23

MaxReservation[0] 24

value_id = 1 (0x1) 25

max_num_reservations_fwd = 15 (0xf) 26

max_num_reservations_rev = 15 (0xf) 27

max_num_open_reservations_fwd = 15 (0xf) 28

max_num_open_reservations_rev = 15 (0xf) 29

attribs[2] 30

attribute_id = 65530 (0xfffa) (TwoRoutesSupported) 31

num_recs = 1 (0x1) 32

two_routes_support[0] = 1 (0x1) 33

attribs[3] 34

attribute_id = 3844 (0x0f04) (ATSupportedFlowProtocolParamsPP) 35

num_recs = 1 (0x1) 36

supported_flow_prot_param_pp_attrib[0] 37

value_id = 1 (0x1) 38

prot_supported = 1 (0x1) 39

param_value_length = 14 (0xe) 40

max_supported_max_cid = 0 (0x0) 41

large_cid_supported = 1 (0x1) 42

max_supported_mrru = 0 (0x0) 43

timer_based_compress_supported = 1 (0x1) 44

supported_profile_cnt = 4 (0x4) 45



supported_profile[0] = 0 (0x0) 46




attribs[4] 50

attribute_id = 4100 (0x1004) (ATSupportedRouteProtocolParamsPP) 51

num_recs = 1 (0x1) 52

supported_flow_prot_param_pp_attrib[0] 53

value_id = 1 (0x1) 54

prot_supported = 1 (0x1) 55

param_value_length = 14 (0xe) 56

max_supported_max_cid = 0 (0x0) 57

large_cid_supported = 1 (0x1) 58

max_supported_mrru = 0 (0x0) 59

timer_based_compress_supported = 1 (0x1) 60

supported_profile_cnt = 4 (0x4) 61





attribs[5] 66

attribute_id = 62209 (0xf301) (FlowNNActivatedFwd) 67

num_recs = 1 (0x1) 68

flow_nn_activated_fwd[0] = 0 (0x0) 69

attribs[6] 70

attribute_id = 61953 (0xf201) (FlowNNActivatedRev) 71

num_recs = 1 (0x1) 72

flow_nn_activated_rev[0] = 0 (0x0) 73


Line 8 to Line 13: The ConfigurationResponse message includes seven attributes to specify the parameters for the configuration of Enhanced Multi Flow Packet Application.

Line 14 and Line 16: The first attribute_id identifies the complex attribute, MaxLinkFlows. This attribute is used by the AT to provide AN with the information about the number of flows that the AT can support in the activate state.

Line 17 and Line 18: The max_num_link_flow_fwd and max_num_link_flow_rev indicates the maximum number of simultaneous activated and deactivated link flows that the AT can support in the forward and reverse direction, respectively

Line 19 and Line 20: The max_activated_link_flow_fwd and max_activated_link_flow_rev indicates the maximum number of simultaneously activated link flows that the AT can support in the forward and reverse direction respectively

Line 22 and Line 24: This attribute_id identifies the complex attribute, MaxReservations. This attribute is used by the AT to provide the AN with the information about the number of reservations (higher layer data flows) the AT can support in the activate state.

Line 26 and Line 27: The max_num_reservations_fwd and max_num_reservations_rev indicates the maximum number of simultaneous activated and deactivated reservations that the AT can support in the forward and the reverse directions.

Line 28 and Line 29: The max_num_open_reservations_fwd and max_num_open_reservations_rev indicates the maximum number of simultaneous activated reservations that the AT can support in the forward and the reverse directions.

Line 31 and Line 33: This attribute, TwoRoutesSupported is used to configure the use of Route Selection Protocol (RSP) by the AT and the AN. The RSP in EMFPA facilitates optimized handoff



between the two RNCs by establishing an additional route with the target RNC. Further, the RSP provides a means to select one of two instances of the Route Protocol to route Flow Protocol PDUs. The configuration of TwoRoutesSupported enables routing of Flow Protocol PDUs to a selected instance of any of the two routes of the link flow by the Route Selection Protocol.

Line 35: This attribute (of the form 0x0fPP), ATSupportedFlowProtocolParamsPP, is used by the AT to inform the supported set of protocols and the parameters to the AN at the Flow Protocol. PP here refers to the ProtocolID number of the Flow Protocol. The options for the PP are shown in the Table 8. In this case, the ProtocolID is set 4 and hence the AT is including the parameters for ROHC.

Table 8: Protocols available at the Flow Protocol in EMFPA

Protocol ID (PP) Protocol

00 NULL

01 PPP/HDLC frames (For BE)

02 IPv4 (For VoIP media)

03 IPv6

04 Robust Header Compression (ROHC)

05 Combination of IPv4 and IPv6

Line 39 to Line 49: For description of fields in these lines, refer to [Q4].

Line 51: This attribute (of the form 0x10PP), ATSupportedRouteProtocolParamsPP, is used by AT to inform the supported set of protocols and the parameters to AN at the Route Protocol. PP here refers to the ProtocolID number of the Route Protocol. The options for the PP are shown in the Table 9. Since the ProtocolID is set 4, the AT includes the parameters for ROHC.

Table 9: Protocols available at the Route Protocol in EMFPA

Protocol ID (PP) Protocol

00 NULL (BE traffic)

01-03 Reserved

04 ROHC (VoIP media)

Line 54 to Line 65: For description of fields in these lines, refer to [Q4].

Line 67 and Line 69: The attribute_id = 0xf3NN embeds the link flow number, NN in the forward direction. The name of the attribute is FlowNNActivatedFwd and is used to activate/deactivate a link flow, NN. Flow NN = 00 is used to carry higher layer octets belonging to Best Effort traffic and Flow NN = 01 is used to carry higher layer packets belonging to Best Effort traffic. These flows are in active state, by default. Here, the AT is proposing to de-activate the Flow NN = 01 in the forward direction.

Line 71 and Line 73: The attribute_id = 0xf2NN embeds the link flow number, NN in the reverse direction. The name of the attribute is FlowNNActivatedRev and is used to activate/deactivate a link flow, NN. Here, the AT is proposing to de-activate the Flow NN = 01 in the reverse direction.




This response is sent by the ‘In Config’ instance of the Enhanced Multi-Flow Packet Application.


2



subtype = 9 (0x9) (subtype 8 or 9 if protocol type is 0x15-0x17) 5


protocol_type = 22 (0x16) (Enhanced Multi-Flow Packet Application) 7


9




attribs[0] 13

attribute_id = 4 (0x4) (MaxLinkFlows) 14

value_id = 1 (0x1) 15

attribs[1] 16

attribute_id = 65530 (0xfffa) (TwoRoutesSupported) 17

value_id = 1 (0x1) 18

attribs[2] 19

attribute_id = 3844 (0x0f04) (ATSupportedFlowProtocolParamsPP) 20

value_id = 1 (0x1) 21

attribs[3] 22

attribute_id = 4100 (0x1004) (ATSupportedRouteProtocolParamsPP) 23

value_id = 1 (0x1) 24

attribs[4] 25

attribute_id = 62209 (0xf301) (FlowNNActivatedFwd) 26

value_id = 0 (0x0) 27

attribs[5] 28

attribute_id = 61953 (0xf201) (FlowNNActivatedRev) 29

value_id = 0 (0x0) 30


Line 8 to Line 24: The ConfigurationResponse message conveys that the AN has accepted the information conveyed in all attributes except MaxReservation.

4.3.7 Completion of negotiation of parameters for Second Personality from AT side

4.3.7.1 Message and Content – ConfigurationComplete Message


0x1077 1xEV Signaling Reverse Traffic Channel -- ConfigurationComplete Msg 1

2






message_id = 0 (0x0) (ConfigurationComplete) 8

9



session_config 10

config_comp 11


token_incl = 0 (0x0) 13


Refer to Section 4.2.4 for description of the fields in this message.

4.3.8 AN initiated configuration of Session Configuration Protocol The AN proceeds with the configuration of protocols at this time, for the second personality. In the first message, the Session Configuration Protocol HardLinks the protocol subtypes that do not change from the Main Personality to this Personality. These are Default Control Channel MAC, Default Access Channel MAC etc. When hardlinked, if any parameter is changed later using GAUP for these protocols, the AN and the AT only need to modify the parameters in the active personality. Changes for the hardlinked protocols are updated across all personalities implicitly.




2







9


transaction_id = 10 (0xa) 11


attribs[0] 13

attribute_id = 1 (0x1) (ControlChannelMACProtocol Attribute) 14

num_recs = 1 (0x1) 15


attribs[1] 17

attribute_id = 2 (0x2) (AccessChannelMACProtocol Attribute) 18

num_recs = 1 (0x1) 19


attribs[2] 21


num_recs = 1 (0x1) 23


attribs[3] 25


num_recs = 1 (0x1) 27


attribs[4] 29

attribute_id = 7 (0x7) (EncryptionProtocol Attribute) 30

num_recs = 1 (0x1) 31


attribs[5] 33




num_recs = 1 (0x1) 35


attribs[6] 37

attribute_id = 10 (0xa) (Air-LinkManagementProtocol Attribute) 38

num_recs = 1 (0x1) 39


attribs[7] 41

attribute_id = 11 (0xb) (InitStateProtocol Attribute) 42

num_recs = 1 (0x1) 43


attribs[8] 45


num_recs = 1 (0x1) 47


attribs[9] 49

attribute_id = 13 (0xd) (ConnectStateProtocol Attribute) 50

num_recs = 1 (0x1) 51


attribs[10] 53

attribute_id = 14 (0xe) (RouteUpdateProtocol Attribute) 54

num_recs = 1 (0x1) 55


attribs[11] 57

attribute_id = 15 (0xf) (OverheadMessagesProtocol Attribute) 58

num_recs = 1 (0x1) 59


attribs[12] 61

attribute_id = 16 (0x10) (SessionManagementProtocol Attribute) 62

num_recs = 1 (0x1) 63


attribs[13] 65

attribute_id = 17 (0x11) (AddressManagementProtocol Attribute) 66

num_recs = 1 (0x1) 67


attribs[14] 69

attribute_id = 18 (0x12) (SessionConfigurationProtocol 70

Attribute) 71

num_recs = 1 (0x1) 72


attribs[15] 74

attribute_id = 24 (0x18) (BroadcastMessagesProtocol Attribute) 75

num_recs = 1 (0x1) 76


attribs[16] 78

attribute_id = 25 (0x19) (GenericVirtualStreamProtocol 79

Attribute) 80

num_recs = 1 (0x1) 81


4.3.8.2 Description of message Line 8 to Line 86: The ConfigurationRequest message is used to configure (HardLink) 18 protocol subtypes by the AN. The AN specifies the value of 0xfffe in order to HardLink a protocol subtype These hard linked protocol subtypes are:

• Default Control Channel MAC Protocol

• Default Access Channel MAC Protocol



• Default Key Exchange Protocol

• Default Authentication Protocol

• Default Encryption Protocol

• Default Security Protocol

• Default Air Link Management Protocol

• Default Initialization State Protocol

• Default idle State Protocol

• Default Connected Protocol

• Default Route Update Protocol

• Default Overhead Messages Protocol

• Default Session Management Protocol

• Default Address Management Protocol

• Default Session Configuration Protocol

• Default Broadcast Messages Protocol

• Default Virtual Stream Protocol

In the case of Default Idle State Protocol, recall that the AT proposed the same value of the PreferredControlChannelCycle attribute in both the personalities. Since the AN accepted in both the cases and has not proposed new values for any other parameters, it is allowed to HardLink this protocol.


This message is sent by the ‘In Use’ instance of the Session Configuration Protocol. Note that the AT only accepts hardlinking of 16 protocol subtypes. It does not hardlink Default Packet Consolidation Protocol and Default Virtual Stream Protocol. Perhaps, the AT does not support Default Virtual Stream Protocol.


2







9


transaction_id = 10 (0xa) 11


attribs[0] 13

attribute_id = 1 (0x1) (ControlChannelMACProtocol Attribute) 14

value_id = 65534 (0xfffe) 15

attribs[1] 16

attribute_id = 2 (0x2) (AccessChannelMACProtocol Attribute) 17


attribs[2] 19





attribs[3] 22



attribs[4] 25

attribute_id = 7 (0x7) (EncryptionProtocol Attribute) 26


attribs[5] 28



attribs[6] 31

attribute_id = 10 (0xa) (Air-LinkManagementProtocol Attribute) 32


attribs[7] 34

attribute_id = 11 (0xb) (InitStateProtocol Attribute) 35


attribs[8] 37



attribs[9] 40

attribute_id = 13 (0xd) (ConnectStateProtocol Attribute) 41


attribs[10] 43

attribute_id = 14 (0xe) (RouteUpdateProtocol Attribute) 44


attribs[11] 46

attribute_id = 15 (0xf) (OverheadMessagesProtocol Attribute) 47


attribs[12] 49

attribute_id = 16 (0x10) (SessionManagementProtocol Attribute) 50


attribs[13] 52

attribute_id = 17 (0x11) (AddressManagementProtocol Attribute) 53


attribs[14] 55

attribute_id = 18 (0x12) (SessionConfigurationProtocol 56

Attribute) 57


attribs[15] 59

attribute_id = 24 (0x18) (BroadcastMessagesProtocol Attribute) 60



Line 8: The ConfigurationResponse message conveys that the AT has accepted the hard linking of 16 protocol subtypes. These are:

• Default Control Channel MAC Protocol

• Default Access Channel MAC Protocol

• Default Key Exchange Protocol

• Default Authentication Protocol

• Default Encryption Protocol

• Default Security Protocol



• Default Air Link Management Protocol

• Default Initialization State Protocol

• Default idle State Protocol

• Default Connected Protocol

• Default Route Update Protocol

• Default Overhead Messages Protocol

• Default Session Management Protocol

• Default Address Management Protocol

• Default Session Configuration Protocol

• Default Broadcast Messages Protocol

In the case of Route Update Protocol, accepting the HardLink implies that the AT will use the values proposed in the SearchParameters, SetManagementSameChannelParameters, SetManagementDifferentChannelParameters and SetManagementOverrideAllowed attributes in the Main Personality.

Similarly, in the case of Session Management Protocol, the AT will use the SMP Close time of 720 minutes negotiated in the Main Personality.

4.3.9 AN initiated configuration of Enhanced FTCMAC The AN conveys the information about the minimal delay in transferring the queues during soft and softer handoff situations using the HandoffDelays attribute.


This message is sent by the ‘In Config’ instance of the Enhanced FTCMAC Protocol.


2



subtype = 1 (0x1) (subtype 1 or 2 if protocol type is 0x15-5

0x17) 6


protocol_type = 3 (0x3) (Enhanced Forward Traffic Channel MAC 8

Protocol) 9


11


transaction_id = 11 (0xb) 13


attribs[0] 15


num_recs = 1 (0x1) 17

ho_delay_attrib[0] 18

value_id = 1 (0x1) 19

softer_handoff_delay = 8 (0x8) 20

soft_handoff_delay = 16 (0x10) 21




Refer to Section 4.2.7 for description of fields in this message.


This message is sent by the ‘In Config’ instance of the Enhanced FTCMAC Protocol.


2




0x17) 6


protocol_type = 3 (0x3) (Enhanced Forward Traffic Channel MAC 8

Protocol) 9


11


transaction_id = 11 (0xb) 13


attribs[0] 15


value_id = 1 (0x1) 17



4.3.10 AN initiated configuration of RTCMAC Subtype 3 RTCMAC subtype 3 uses multiple flows to send the higher layer traffic in the reverse direction. There are default flows for carrying the 1xEV-DO signaling traffic (RTCMAC flow NN = 00) and the octet-based BE traffic (RTCMAC flow NN = 01). If the EMFPA is used at the 1xEV-DO Application layer, then another flow NN = 02 shall be configured for packet-based BE traffic provided that flow is not deactivated at the Application layer. Refer to Section 4.3.6 where the application flow NN = 02 was deactivated by the AT and the AN.

The AT uses the default parameters for the flow NN = 00. The AN configures the parameters for flow NN = 01 using a number of attributes. In this example, the AN uses a number of messages to configure these parameters for flow NN = 01. An optimized approach would be to bundle these attributes in the minimum number of messages possible.


This message is sent by the ‘In Config’ instance of the Subtype 3 RTCMAC Protocol to configure Rate1M8Supported attribute and to configure the common parameters used by the Subtype 3 RTC MAC protocol when allocating power and transmitting the user data on the reverse link.


2








Protocol) 8


10


transaction_id = 12 (0xc) 12


attribs[0] 14

attribute_id = 65523 (0xfff3) (Rate1M8Supported) 15

sub3_rtc_mac 16

num_recs = 1 (0x1) 17

rate_1m8_supp[0] = 1 (0x1) 18

attribs[1] 19

attribute_id = 1 (0x1) (CommonPwrParams) 20

sub3_rtc_mac 21

num_recs = 1 (0x1) 22

ComPowerPar[0] 23

value_id = 1 (0x1) 24

alloc_stagger = 6 (0x6) 25

tx_t2p_min = 15 (0xf) 26

rpc_step = 1 (0x1) (1.0dB) 27

4.3.10.2 Description

Line 9: The ConfigurationRequest message is used to configure the parameters for two attributes, Rate1M8Supported and CommonPowerParameters.

Line 14 to Line 18: The AN specifies that it supports the reception of 1.8 Mbps on the Reverse link. In other words, the AT can transmit the 12288 bit physical layer packet on the reverse if the RTCMAC subtype 3 algorithm permits it to do so.

Line 25: The alloc_stagger field ensures that there is sufficient randomization in the allocation of power across MAC flows in an AT. For more information on the parameters in this message, refer to [Q4].

Line 26: The tx_t2p_min specifies the minimum TxT2P power that the AT is always allowed to transmit. TxT2P is the transmitted Traffic 2 Pilot power ratio. It is specified in units of 0.25 dB.

Line 27: The rpc_step specifies the step that AT shall take when controlling the power on the Reverse Link. Refer to Table 10.10.7.2.3-1 in [S1] for the decoding of OTA values of this field.




2






Protocol) 8


10


transaction_id = 12 (0xc) 12


attribs[0] 14



attribute_id = 65523 (0xfff3) (Rate1M8Supported) 15

value_id = 1 (0x1) 16

attribs[1] 17

attribute_id = 1 (0x1) (CommonPwrParams) 18

value_id = 1 (0x1) 19


Line 9 to Line 19: The ConfigurationResponse message conveys that the AT has accepted the parameters configured by the AN.


This message is sent by the ‘In Config’ instance of the Subtype 3 RTCMAC Protocol to configure the parameters of the T2PTransitionFunctionNN attribute. The NN identifies the MAC flow number. The T2PTransitionFunction is a three dimensional function that determines the change in T2PInflow for an instantaneous T2P in the bucket, the averaged FRAB value over last 384 slots and interpreted QRAB value at the beginning of each sub-frame. The change in the T2PInflow is always relative to the previous addition in the T2P bucket. If the interpreted QRAB implies that the Reverse Link is unloaded, then the T2PInflow increases and values provided for T2PUp for a given combination of T2P and FRAB are used. If the interpreated QRAB implies reverse link is loaded, T2PInflow decreases and the values provided in the T2PDn are used. For more information on this attribute, refer to [Q4].


2






Protocol) 8


10


transaction_id = 13 (0xd) 12


attribs[0] 14

attribute_id = 5633 (0x1601) (T2PTransFuncNN) 15

sub3_rtc_mac 16

num_recs = 1 (0x1) 17

T2p_Trans_FuncNN[0] 18

value_id = 1 (0x1) 19

num_t2p_axi = 3 (0x3) 20

num_frab_axi = 3 (0x3) 21

t2p_axi[0] = 0 (0x0) 22

t2p_axi[1] = 34 (0x22) 23

t2p_axi[2] = 71 (0x47) 24

t2p_axi[3] = 90 (0x5a) 25

frab_axi[0] = 8 (0x8) 26

frab_axi[1] = 11 (0xb) 27

frab_axi[2] = 14 (0xe) 28

frab_axi[3] = 7 (0x7) 29

t2p_frab_axi[0] 30

t2p_up_frab_axi = 29 (0x1d) 31

t2p_dn_frab_axi = 233 (0xe9) 32

t2p_frab_axi[1] 33



t2p_up_frab_axi = 10 (0xa) 34


t2p_frab_axi[2] 36

t2p_up_frab_axi = 254 (0xfe) 37

t2p_dn_frab_axi = 214 (0xd6) 38

t2p_frab_axi[3] 39

t2p_up_frab_axi = 233 (0xe9) 40


t2p_frab_axi[4] 42

t2p_up_frab_axi = 245 (0xf5) 43


t2p_frab_axi[5] 45



t2p_frab_axi[6] 48

t2p_up_frab_axi = 214 (0xd6) 49


t2p_frab_axi[7] 51



t2p_frab_axi[8] 54

t2p_up_frab_axi = 251 (0xfb) 55

t2p_dn_frab_axi = 14 (0xe) 56

t2p_frab_axi[9] 57


t2p_dn_frab_axi = 7 (0x7) 59

t2p_frab_axi[10] 60

t2p_up_frab_axi = 220 (0xdc) 61

t2p_dn_frab_axi = 251 (0xfb) 62

t2p_frab_axi[11] 63

t2p_up_frab_axi = 14 (0xe) 64

t2p_dn_frab_axi = 251 (0xfb) 65

t2p_frab_axi[12] 66

t2p_up_frab_axi = 24 (0x18) 67

t2p_dn_frab_axi = 45 (0x2d) 68

t2p_frab_axi[13] 69

t2p_up_frab_axi = 5 (0x5) 70

t2p_dn_frab_axi = 38 (0x26) 71

t2p_frab_axi[14] 72

t2p_up_frab_axi = 249 (0xf9) 73

t2p_dn_frab_axi = 26 (0x1a) 74

t2p_frab_axi[15] 75

t2p_up_frab_axi = 45 (0x2d) 76



Line 9: The ConfigurationRequest message is used to convey the parameters for T2PTransitionFunction flow NN = 01.

Line 15: The attribute_id is coded as 0x16NN, the 0x16 identifies the complex attribute ‘T2PTransitionFunctionNN’ in the RTCMAC Subtype 3 Protocol and NN is two-digit hexadecimal MAC flow number in the range 0x00 to MaxNumMACFlow -1.

Line 20: The num_t2p_axi field indicates the number of axes on the T2P axis for which the transition function is specified. In this case, it is specified to be 4 (0x3). The more the number of axes, the better the granularity, the more controlled the RL transmission will be. But increase in the granularity increases processing overhead. In this case, it is specified as 4 (0x3)



Line 21: The num_frab_axi defines the granularity for the FRAB axis. In this case, it is specified as 4 (0x3). The num_t2p_axi and num_frab_axi build a grid of num_t2p_axi (4) X num_frab_axi (4) combinations. This implies that there must be 16 set of T2PUp and T2PDn values to be used by the RTCMAC algorithm when allocating the T2PInflow. These values are provided by this attribute itself (see line 30 to 77).

Line 22 to Line 25: The fields, t2p_axi[i] (i being 0 to 3), in these four lines define the axes on the T2P axis. These values are specified in 2’s complement. The engineering values are between -32 and 31.5 dB. In this case, the engineering values are 0 dB (0x0), 8.5 dB (0x22), 17.75 dB (0x47) and 22.5 dB (0x5a). Refer to Table 10.10.7.2.9-1 in [S1] for decoding of OTA values of the fields in these lines.

Line 26 to Line 29: The fields, frab_axi[i] (i being 0 to 3), in these four lines define the axes on the FRAB axis. These values are also specified in 2’s complement. The engineering values are between -1 and 1. In the case, the engineering values are -1 (0x8), -5/8 (0xb), -2/8 (0xe) and 7/8 (0x7). Refer to Table 10.10.7.2.9-2 in [S1] for decoding of OTA values of the fields in these lines.

Line 30: The values for the T2PUp and T2PDn for each box in the grid is specified by t2p_frab_axi[j]. In this case, j is from 0 to 15. The first t2p_frab_axi[0] provides the value for the combination of t2p_axi[0] and frab_axi[0]. The mapping for the other combinations is shown in the Table 10.

Table 10: Mapping of t2p_frab_axi to combination of t2p_axi and frab_axi

t2p_axi (engineering

values)

frab_axi (engineering

values)

t2p_frab_axi

0 (0dB) 0 (-1) 0

0 (0dB) 1 (-5/8) 1

0 (0dB) 2 (-2/8) 2

0 (0dB) 3 (7/8) 3

1 (8.5 dB) 0 (-1) 4

1 (8.5 dB) 1 (-5/8) 5

1 (8.5 dB) 2 (-2/8) 6

1 (8.5 dB) 3 (7/8) 7

2 (17.75 dB) 0 (-1) 8

2 (17.75 dB) 1 (-5/8) 9

2 (17.75 dB) 2 (-2/8) 10

2 (17.75 dB) 3 (7/8) 11

3 (22.5 dB) 0 (-1) 12

3 (22.5 dB) 1 (-5/8) 13



t2p_axi (engineering

values)

frab_axi (engineering

values)

t2p_frab_axi

3 (22.5 dB) 2 (-2/8) 14

3 (22.5 dB) 3 (7/8) 15

Line 31: The t2p_up_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded. The value specified in this field is applied if the instantaneous T2P is between -32 dB and 0 dB and FRAB is between -1 and -5/8. Refer to Table 10.10.7.2.9-3 in [S1] for decoding of OTA values of the fields in these lines.

Line 32: The t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is loaded. The value specified in this field is applied if the instantaneous T2P is between -32 dB and 0 dB and FRAB is between -1 and -5/8. Refer to Table 10.10.7.2.9-4 in [S1] for decoding of OTA values of the fields in these lines.

Line 34 & Line 35: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between -32 dB and 0 dB and FRAB is between -5/8 and -2/8.

Line 37 & Line 38: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between -32 dB and 0 dB and FRAB is between -2/8 and 7/8.

Line 40 & Line 41: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between -32 dB and 0 dB and FRAB is between 7/8 and 1.

Line 43 & Line 44: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 0 dB and 8.5 dB and FRAB is between -1 and -5/8.

Line 46 & Line 47: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 0 dB and 8.5 dB and FRAB is between -5/8 and -2/8.

Line 49 & Line 50: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 0 dB and 8.5 dB and FRAB is between -2/8 and 7/8.

Line 52 & Line 53: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 0 dB and 8.5 dB and FRAB is between 7/8 and 1.

Line 55 & Line 56: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 8.5 dB and 17.75 dB and FRAB is between -1 and -5/8.

Line 58 & Line 59: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded



respectively. The values specified in these fields are applied if the instantaneous T2P is between 8.5 dB and 17.75 dB and FRAB is between -5/8 and -2/8.

Line 61 & Line 62: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 8.5 dB and 17.75 dB and FRAB is between -2/8 and 7/8.

Line 64 & Line 65: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 8.5 dB and 17.75 dB and FRAB is between 7/8 and 1.

Line 67 & Line 68: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 17.75 dB and 22.5 dB and FRAB is between -1 and -5/8.

Line 70 & Line 71: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 17.75 dB and 22.5 dB and FRAB is between -5/8 and -2/8.

Line 73 & Line 74: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 17.75 dB and 22.5 dB and FRAB is between -2/8 and 7/8.

Line 76 & Line 77: The t2p_up_frab_axi and t2p_dn_frab_axi specifies the additional T2P relative to the last T2PInflow when the interpreted QRAB implies RL is unloaded and loaded respectively. The values specified in these fields are applied if the instantaneous T2P is between 17.75 dB and 22.5 dB and FRAB is between 7/8 and 1.




2






Protocol) 8


10


transaction_id = 13 (0xd) 12


attribs[0] 14

attribute_id = 5633 (0x1601) (T2PTransFuncNN) 15

value_id = 1 (0x1) 16


Line 9: The ConfigurationResponse message conveys that the AT has accepted the values proposed in the T2PTransitionFunctionNN attribute.




The Subtype 3 RTCMAC support two transmission modes: Low Latency Mode (LoLat) and High Capacity Mode (HiCap). The modes are typically configured to support different sets of termination targets for data in a MAC flow and the power levels used by the AT during different sub-packet transmissions [Q4]. These targets are determined based on the characteristics of applications and they serve to meet the application flow requirements such as latency and PER, while maintaing system stability and facilitating AT’s power control.

Attribute PowerParametersPS groups together a number of parameters such as termination target, power to use before the target (pre-transition) and after the target (post-transition) for payload of different sizes. PS in PowerParameters identifies the physical layer packet size. These parameters are applied for octet-based Best Effort traffic (RTCMAC flow NN = 01).

This message is sent by the ‘In Config’ instance of the Subtype 3 RTCMAC Protocol to configure the MAC flow for transmitting physical layer payload size of 128 bits, 256 bits, 512 bits, 768 bits, 1024 bits, 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 bits and 12288 bits.


2






Protocol) 8


10


transaction_id = 14 (0xe) 12

num_attribs = 12 (0xc) 13

attribs[0] 14

attribute_id = 5 (0x5) (PwrParams128) 15

sub3_rtc_mac 16

num_recs = 1 (0x1) 17

Power_Param128[0] 18

value_id = 1 (0x1) 19

LoLatT2P_Transition128 = 2 (0x2) 20

LoLatTermTarget128 = 2 (0x2) 21

HiCapT2P_Transition128 = 3 (0x3) 22

HiCapTermTarget128 = 3 (0x3) 23

T2PLoLat_PreTrans128 = 13 (0xd) 24

T2PLoLat_PostTrans128 = 3 (0x3) 25

T2PHiCap_PreTrans128 = 3 (0x3) 26

T2PHiCap_PostTrans128 = 3 (0x3) 27

attribs[1] 28


sub3_rtc_mac 30

num_recs = 1 (0x1) 31


value_id = 1 (0x1) 33





T2PLoLat_PreTrans256 = 26 (0x1a) 38

T2PLoLat_PostTrans256 = 15 (0xf) 39



T2PHiCap_PreTrans256 = 15 (0xf) 40

T2PHiCap_PostTrans256 = 15 (0xf) 41

attribs[2] 42


sub3_rtc_mac 44

num_recs = 1 (0x1) 45


value_id = 1 (0x1) 47





T2PLoLat_PreTrans512 = 38 (0x26) 52

T2PLoLat_PostTrans512 = 28 (0x1c) 53

T2PHiCap_PreTrans512 = 28 (0x1c) 54

T2PHiCap_PostTrans512 = 28 (0x1c) 55

attribs[3] 56


sub3_rtc_mac 58

num_recs = 1 (0x1) 59


value_id = 1 (0x1) 61





T2PLoLat_PreTrans768 = 46 (0x2e) 66




attribs[4] 70


sub3_rtc_mac 72

num_recs = 1 (0x1) 73

pow_param1024[0] 74

value_id = 1 (0x1) 75









attribs[5] 84

attribute_id = 10 (0xa) (PwrParams1536) 85

sub3_rtc_mac 86

num_recs = 1 (0x1) 87

pow_param1563[0] 88

value_id = 1 (0x1) 89






T2PLoLat_PostTrans1536 = 46 (0x2e) 95



T2PHiCap_PreTrans1536 = 46 (0x2e) 96

T2PHiCap_PostTrans1536 = 46 (0x2e) 97

attribs[6] 98

attribute_id = 11 (0xb) (PwrParams2048) 99

sub3_rtc_mac 100

num_recs = 1 (0x1) 101

pow_param2048[0] 102

value_id = 1 (0x1) 103





T2PLoLat_PreTrans2048 = 62 (0x3e) 108




attribs[7] 112

attribute_id = 12 (0xc) (PwrParams3072) 113

sub3_rtc_mac 114

num_recs = 1 (0x1) 115


value_id = 1 (0x1) 117









attribs[8] 126

attribute_id = 13 (0xd) (PwrParams4096) 127

sub3_rtc_mac 128

num_recs = 1 (0x1) 129


value_id = 1 (0x1) 131






T2PLoLat_PostTrans4096 = 62 (0x3e) 137

T2PHiCap_PreTrans4096 = 62 (0x3e) 138

T2PHiCap_PostTrans4096 = 62 (0x3e) 139

attribs[9] 140

attribute_id = 14 (0xe) (PwrParams6144) 141

sub3_rtc_mac 142

num_recs = 1 (0x1) 143


value_id = 1 (0x1) 145





T2PLoLat_PreTrans6144 = 76 (0x4c) 150






attribs[10] 154

attribute_id = 15 (0xf) (PwrParams8192) 155

sub3_rtc_mac 156

num_recs = 1 (0x1) 157


value_id = 1 (0x1) 159





T2PLoLat_PreTrans8192 = 93 (0x5d) 164

T2PLoLat_PostTrans8192 = 74 (0x4a) 165

T2PHiCap_PreTrans8192 = 74 (0x4a) 166

T2PHiCap_PostTrans8192 = 74 (0x4a) 167

attribs[11] 168


sub3_rtc_mac 170

num_recs = 1 (0x1) 171

pow_param12288 [0] 172

value_id = 1 (0x1) 173










Line 10: The ConfigurationRequest message includes 12 complex attributes to specify the Power Parameters for 10 different payload sizes transmitted on the Reverse Link. The attributes for each of the payload size is identified uniquely in the RTCMAC Subtype 3 Protocol

Line 15: The attribute_id = 0x5 identifies the complex attribute ‘PowerParameters’ in the RTCMAC Subtype 3 Protocol for payload size of 128 bits.

Line 20, Line 24 and Line 25: The LoLatT2P_Transition128 specifies the transition target for Low Latency mode transmissions in terms of sub-packets. This transition refers to parameters/values used for pre-transition (T2PLoLat_PreTrans128) and post-transition (T2PLoLat_PostTrans128) sub-packet transmissions. Essentially, the first LoLatT2P_Transition128 +1 sub-packets use the pre-transition values and the rest use the post-transition values. In this case, the value of 2 implies the first 3 sub-packets to use the pre-transition values. Refer to Section 10.11.7.2.8 of [S1] for more information on fields in this attribute.

Line 21: The LoLatTermTarget128 specifies the number of sub-frames required to ensure a 99% physical layer success transmission when the power defined in fields T2PLoLat_PreTrans128 and T2PLoLat_PostTrans128 are used for Low Latency transmission mode MAC flows.

Line 22, Line 26 and Line 27: The HiCapT2P_Transition128, T2PHiCap_PreTrans128 and T2PHiCap_PreTrans128 define the transition target, pre-transition and post-transition values for the High Capacity MAC flow.



Line 23: The HiCapTermTarget128 specifies the number of sub-frames required to ensure a 99% physical layer success transmission when the power defined in fields T2PHiCap_PreTrans128 and T2PHiCap_PostTrans128 are used for High Capacity transmission mode MAC flows.

Line 28 to Line 181: The parameters/values describe in these attribute are applied for physical layer packets of size 256 bits, 512 bits, 768 bits, 1024 bits, 1536 bits, 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 and 12288 bits in that order.




2






Protocol) 8


10


transaction_id = 14 (0xe) 12

num_attribs = 12 (0xc) 13

attribs[0] 14


value_id = 1 (0x1) 16

attribs[1] 17


value_id = 1 (0x1) 19

attribs[2] 20


value_id = 1 (0x1) 22

attribs[3] 23


value_id = 1 (0x1) 25

attribs[4] 26


value_id = 1 (0x1) 28

attribs[5] 29

attribute_id = 10 (0xa) (PwrParams1536) 30

value_id = 1 (0x1) 31

attribs[6] 32

attribute_id = 11 (0xb) (PwrParams2048) 33

value_id = 1 (0x1) 34

attribs[7] 35

attribute_id = 12 (0xc) (PwrParams3072) 36

value_id = 1 (0x1) 37

attribs[8] 38

attribute_id = 13 (0xd) (PwrParams4096) 39

value_id = 1 (0x1) 40

attribs[9] 41

attribute_id = 14 (0xe) (PwrParams6144) 42

value_id = 1 (0x1) 43

attribs[10] 44



attribute_id = 15 (0xf) (PwrParams8192) 45

value_id = 1 (0x1) 46

attribs[11] 47


value_id = 1 (0x1) Description of message 49

Line 9 to Line 49: The ConfigurationResponse message conveys that the AT has accepted the Power Parameters value proposed by the AN for.different payload sizes.

4.3.11 AN initiated configuration of Enhanced Multi-Flow Packet Application subtype

The AN configures the remaining EMFPA parameters. Refer to Table 4-14 in [Q5] for the list of attributes that the AN can configure.

4.3.11.1 Message and Content – ConfigurationRequest Message 0x1079 1xEV Signaling Forward Traffic Channel -- ConfigurationRequest Msg 1

2




0x17) 6


protocol_type = 22 (0x16) (Enhanced Multi-Flow Packet 8

Application) 9



transaction_id = 15 (0xf) 12


attribs[0] 14

attribute_id = 65535 (0xffff) (RANHandoff) 15

num_recs = 1 (0x1) 16

RANHandoff[0] = 1 (0x1) 17

attribs[1] 18


num_recs = 1 (0x1) 20

MaxReservation[0] 21

value_id = 1 (0x1) 22

max_num_reservations_fwd = 11 (0xb) 23

max_num_reservations_rev = 11 (0xb) 24

max_num_open_reservations_fwd = 11 (0xb) 25

max_num_open_reservations_rev = 11 (0xb) 26


Line 8: The ConfigurationResponse message is used by the AN to configure the EMFPA parameters.

Line 15 and Line 17: The RANHandoff attribute defines the ATs behavior in communicating 1xEV-DO Application Layer mobility management information when a handoff occurs between two 1xEV-DO Subnets. Note that for RANHandoff, a value of 0x01 implies that the AT shall send an Unsolicited Location Notification message with SID, NID and PZID information of the source subnet.

Line 19: The MaxReservations attribute is used by the AN to convey to the AT the number of reservations (higher layer data flows) that the AN will support in the active state.Recall that the AN did not accept the AT’s proposal for this attribute earlier in the AT initiated stage.



Line 23 to Line 26: Refer to Section 4.3.6 for more details on the fields.

4.3.11.3 Message and Content – ConfigurationResponse Message 0x1077 1xEV Signaling Reverse Traffic Channel -- ConfigurationResponse Msg 1

2




0x17) 6


protocol_type = 22 (0x16) (Enhanced Multi-Flow Packet 8

Application) 9


11


transaction_id = 15 (0xf) 13


attribs[0] 15

attribute_id = 65535 (0xffff) (RANHandoff) 16

value_id = 1 (0x1) 17

attribs[1] 18


value_id = 1 (0x1) 20


Line 9: The ConfigurationResponse message conveys that the AT has accepted the values proposed by the AN for attributes, RANHandoff and MaxReservations.

4.3.12 AN initiated configuration of Stream Protocol The AN accepted the proposed bindings (Stream2 Application for carrying the EMFPA bound to Service network) during the AT initiated phase of the Second Personality negotiation. However, the mappings were not created for carrying the A12 authentication data during that configuration. The AN creates these by including the new bindings in the StreamConfiguration attribute in the AN designated phase of the Personality negotiation.




2







9




attribs[0] 13




num_recs = 1 (0x1) 15

stream_config[0] 16

value_id = 0 (0x0) 17


stream1_app = 1 (0x1) (Default Pkt App Bound to Access 19

Network) 20

stream2_app = 9 (0x9) (Enhanced MultiFlow Pkt App Bound 21

to Service Network) 22







2







9




attribs[0] 13


value_id = 0 (0x0) 15


Line 7 to Line 15: The ConfigurationResponse message conveys that the AT has accepted the bindings updated by the AN.

4.3.13 Negotiation of Second Personality Complete When the AN has configured parameters for all the negotiated protocols, it sends SoftConfigurationComplete message to the AT. In this message, the AN includes the Personality Index number assigned to the last negotiated personality. It also communicates if the AN wishes the negotiation of another personality, and if not – which Personality to commit.

4.3.13.1 Message and Content – SoftConfigurationComplete Message


0x1079 1xEV Signaling Forward Traffic Channel -- SoftConfigurationComplete Msg 1

2








message_id = 2 (0x2) (SoftConfigurationComplete) 8

9

session_config 10

sft_config_comp 11


personality_index_store = 1 (0x1) 13

cont = 0 (0x0) 14

commit = 1 (0x1) 15

session_config_token = 7039 (0x1b7f) 16


Line 8 to Line 13: The SoftConfigurationComplete message indicates that the AN has assigned an index of 1 (personality_index_store) to the last negotiated personality.

Line 14: The cont = 0 field indicates the AN does not want to negotiate any more personality.

Line 15 and 16: The commit field indicates to the AT that it must commit the parameters negotiated in the personality index given by the four most significant bits of session_config-token. In this case, the AN is requesting the AT to commit the Personality 1 (0x1b7f).

Summary of the protocol subtypes and the parameters for the second personality is shown in Table 11and Table 12.

Table 11: Summary of protocol subtypes and parameters configured for Second Personality

Protocol Type Protocol Subtypes

proposed (AT)

Subtypes configured for

this personality

Attributes configured

Physical Layer Subtype 2 Subtype 2 -

Control Channel MAC Protocol

- HardLink to Main Personality (0xfffe)

-

Access Channel MAC Protocol


-

Forward Traffic MAC Protocol

Enhanced FTCMAC

Enhanced FTCMAC

HandoffDelays

Reverse Traffic MAC Protocol

Subtype 3 and Subtype 1

Subtype 3 MaxMACFlows

Rate1M8Supported

CommonPowerParameters

T2PTransitionFunction

PowerParametersPS (PS = 128, 256, 512, 768, 1024, 1536, 2048, 3072, 4096, 6144 bits, 8192 bits and 12288 bits)

Key Exchange Protocol

DH Key Protocol HardLink to Main Personality (0xfffe)

-




proposed (AT)


this personality


Authentication Protocol

SHA-1 Authentication Protocol

HardLink to Main Personality (0xfffe)

-

Encryption Protocol HardLink to Main Personality (0xfffe)

-

Security Protocol Generic Security Protocol


-

Packet Consolidation Protocol

- Default Packet Consolidation Protocol

-

Air Link Management Protocol


-

Initialization State Protocol


-

Idle State Protocol Enhanced Idle State Protocol


-

Connected State Protocol


-

Route Update Protocol

- Default Route Update Protocol

-

Overhead Messages Protocol


-

Session Management Protocol


-

Session Configuration Protocol


-

Address Management Protocol


-

Stream Protocol - Default Stream Protocol

StreamConfiguration




proposed (AT)


this personality


Broadcast Message protocol


-

1XEV-DO Application Layer

- Enhanced Multi-Flow Packet Application

RANHandoff

MaxReservations

MaxLinkFlows

TwoRoutesSupported

ATSupportedFlowProtocolParamsPP

ATSupportedRouteProtocolParamsPP

FlowNNActivatedFwd

FlowNNActivatedRev

Table 12: Application subtypes to Stream mapping for Second Personality

Configured Stream bindings for Application Subtypes

Stream 0 Application Default Signaling Application

Stream 1 Application Default Packet Application bound to the radio network (0x1)

Stream 2 Application Enhanced Multi-Flow Packet Application bound to the service network (0x9)

Stream 3 Application Unused (0xffff)

4.3.14 Commit the parameters of the personality in use So far during the Session Negotiation, the AT used the default protocol subtypes and their default parameters to communicate with the AN. The AT cannot begin to use the parameters configured during Session Negotiation until it closes the Air Link connection with the AN. The AT sends a ConnectionClose message and puts into effect the protocols, application subtypes and the associated parameters of the personality requested by the AN.

4.3.14.1 Message and Content – ConfigurationClose Message

This message is sent by the ‘In Use’ instance of the Connected State Protocol.

0x1077 1xEV Signaling Reverse Traffic Channel -- ConnectionClose Msg 1

2





protocol_type = 13 (0xd) (Connected State Protocol) 7

message_id = 0 (0x0) (ConnectionClose) 8

connect_state 9



connect_close 10

close_reason = 0 (0x0) 11

suspend_enable = 1 (0x1) 12

suspend_time = 0x27ce4bacd 13


Line 8: The message_id = 0x0 identifies that this message is a ConnectionClose message.

Line 11: The close_reason is used by the sender of this message to convey addition information, if there is any, for closing the connection. In this case, it is ‘Normal Close’.

Line 12 & 13: In 1xEV-DO, the AT is allowed to monitor the Control Channel continuously for a period of time after closing the connection in order to receive the follow-up pages (network initiated re-connections) from the AN and help reduce the connection setup time. If the AT intends to do that, it uses the suspend_enable flag and suspend_time to convey its intention and the time period over which the AT will remain in the suspended state. Subsequent to the expiry of the suspend_time, the AT proceeds to operate in slotted mode.



5. Session Authentication

In this final phase of the Session Negotiation, the AN may authenticate the AT for network access. The authentication is carried by the AAA using the A12 interface between the AAA and the AN. The AT and the AN uses PPP. The AN and the AN-AAA use a well defined UDP port to communicate. Some networks mandate that the AT is authenticated before it can begin to use the network resources. Networks can execute the authentication immediately after the Session Configuration or they may do it later when the AT uses the resources for the first time. It is recommended that the Session Authentication should be executed immediately after the Session Configuration.

Before this authentication can begin, the AT and the AN must have negotiated a flow/stream to transport PPP messages. In this specific call flow example, the AN configured the Stream01 for A12 authentication (See Section 4.2.11 and Section 4.3.12). This flow/stream is then opened for message transport once the protocols and the parameters configured during the Session Configuration phase are committed. The AT sends XonRequest to open the stream/flow. When the AN wants to do the authentication, it pages the AT and prompts it to request the air-link traffic channel establishment. The AN and the AT then uses the traffic channel to perform PPP setup and CHAP message exchange.

During the authentication, the AN and the AT first negotiate the LCP options such as the Authentication Protocol and the algorithm, using the LCP Configuration Request. The authentication protocol is CHAP and the algorithm is MD5. After that, the AN generates a random number and sends it in the PPP CHAP Challenge to the AT. The AT computes response and sends it along with NAI in the PPP CHAP Response to the AN. The AN forwards the response, the NAI along with the random number to the AAA in the A12 Access Request message. If the response matches, the AAA sends back the A12 Access Accept to the AN. The AN then sends PPP CHAP Success to the AT to convey that the authentication is successful.

5.1 AT initiated Session Authentication Figure 8 shows the call flow to open Stream1 to enable the AN to carry out the Session Authentication.

RouteUpdate/XonRequest

ACAck

XonResponse

ANAT

Stream is opened for A12 Authentication by the AN

Figure 8: Authentication Call flow

Since the AT does not have an Air Link connection, it sends an Access Probe in the Access Capsule. In the capsule, it includes the RouteUpdate message and the XonRequest message.



5.1.1 AT opens Stream01 stream for AN authentication


This message is sent by the ‘In Use’ instance of the Route Update Protocol.


2







route_update 9

update 10








5.1.1.3 Message and content – XonRequest Message from AT

This message is sent by the ‘In Use’ instance of the Stream 1 Application. Recall that Stream 1 Application was configured by the AN to carry the A12 authentication data. See Section 4.2.11 and Section 4.3.12.

0x1076 1xEV Signaling Access Channel -- XonRequest Msg 1

2




0x17) 6


protocol_type = 21 (0x15) (Packet Application (Access or 8

Service Network)) 9

message_id = 7 (0x7) (XonRequest) 10

packet_Applications 11


Line 8: The protocol_type field indicates the identity of the protocol, Stream 1 Application, sending this message.

Line 10: The message_id field identifies the XonRequest message.

5.1.1.5 Message and content – ACAck from AN

This message is sent to acknowledge the reception of the Access Capsule by the AN (BTS).


2









ac_mac 9


Line 8: The message_id identifies the ACAck message.

5.1.1.7 Message and content – XonResponse Message from AN

This message is sent by the ‘In Use’ instance of the Stream 1 Application.

0x1078 1xEV Signaling Control Channel Directed -- XonResponse Msg 1

2




0x17) 6


protocol_type = 21 (0x15) (Packet Application (Access or 8

Service Network)) 9

message_id = 8 (0x8) (XonResponse) 10

packet_Applications 11


Line 8: The protocol_type field indicates the identity of the protocol sending this message.

Line 10: The message_id field identifies the XonResponse message.



6. Appendix

6.1 Personality Switch The AT and AN negotiated two personalities during the Session Configuration phase. At any given time, only one personality is used for communication between the AT and the AN. However, depending upon the network topology or to support application requirements, the personality can be switched to enable the AT and the AN to use the protocols and parameters associated with a different personality.

Personality is changed by the AN and the AN only, by exchanging the Generic Attribute Update Protocol (GAUP) messages, AttributeUpdateRequest and AttributeUpdateAccept. However, before these messages can be used, the AT and the AN must negotiate the SupportGAUPSessionConfigToken attribute. See Section 4.2.5.

Recall that the AN tagged the Main (First) Personality with the Personality Index 0 and the Second Personality with the Personality Index 1. The main personality was a Release 0 personality and the second one was a Rev A personality with Enhanced Multi-Flow Packet Application. Finally, the AN requested the AT to use Personality with index 1 after the Session Configuration.

6.1.1 AN sends GAUP message to switch personality

6.1.1.1 Message and content – AttributeUpdateRequest Message from AN

This GAUP message is sent by the ‘In Use’ instance of the Session Configuration Protocol.

0x1079 1xEV Signaling Forward Traffic Channel -- AttributeUpdateRequest Msg 1

2






message_id = 82 (0x52) (AttributeUpdateRequest) 8

9

AttributeUpdateRequest 10



attribs[0] 13

attribute_id = 256 (0x100) (SessionConfigToken Attribute) 14

num_recs = 1 (0x1) 15

config_token[0] = 2998 (0x0bb6) 16


Line 8 and Line 14: The AttributeUpdateRequest message includes the SessionConfigurationToken to convey the Personality to switch to.

Line 16: The most significant nibble (four bits) of the Session Configuration Token (16 bits) convey the new personality that the AT shall switch to.



6.1.1.3 Message and content – AttributeUpdateAccept Message from AT

This GAUP response message is sent by the ‘In Use’ instance of the Session Configuration Protocol.

0x1077 1xEV Signaling Reverse Traffic Channel -- AttributeUpdateAccept Msg 1

2






message_id = 83 (0x53) (AttributeUpdateAccept) 8

9

AttributeUpdateAccept 10



Line 8: The AttributeUpdateAccept message conveys that the AT has accepted the request to switch the personality

Line 11: The transaction_id is used to establish the association between the AttributeUpdateRequest and AttributeUpdateAccept message.

6.2 Closing A Session An existing 1xEV-DO Session between the AT and the AN can be removed by sending the SessionClose message. As a result of this, the UATI assigned to the AT is freed and the AT and the AN purge all information about the 1xEV-DO Session between the AT and the AN. Either the AT or the AN can send this message.

6.2.1 AT sends SessionClose to delete a 1xEV-DO Session

6.2.1.1 Message and content – SessionClose Message


0x1077 1xEV Signaling Reverse Traffic Channel -- SessionClose Msg 1

2






message_id = 1 (0x1) (SessionClose) 8

session_mgmt 9

session_close 10

close_reason = 0 (0x0) (Normal Close) 11

more_info_len = 0 (0x0) 12


Line 8 and Line 11: The ‘SessionClose’ message includes the close_reason to specify the reason for closing the Session.



Line 12: If the sender of the SessionClose message wants to convey additional information for removal of session, it can do so by setting the more_info_len field to a non-zero value. This field carries the value in units of octets and is normally used when there is Protocol Negotiation Error or Protocol Configuration Failure. If more_info_len is set to non-zero value, then SessionClose message must also carry another field more_info.

6.3 Start Configuration or change parameters of an existing Session In certain cases, the AN may request the AT to start the configuration of protocols again to (i) negotiate new protocol subtypes for an existing Personality, (ii) to add a new Personality, or (iii) to change the values of already configured attributes or new attributes. The AN can either use the ConfigurationStart message or the AttributeUpdateRequest message depending on the modification to the existing 1xEV-DO Session. The ConfigurationStart is sent by the Session Configuration Protocol and it uses the Generic Configuration Protocol. The AttributeUpdateRequest can be sent by any Protocol in the 1xEV-DO stack, provided the attribute can be modified using the GAUP. Also, the GAUP does not allow the AT and the AN to negotiate the protocol subtypes.

When the ConfigurationStart is used, the AT must respond by sending a ConfigurationRequest message.



7. Best Practices

This section discusses some of the practices that the AT and the AN should follow to optimize the resources on the air link and minimize the Session Negotiation duration.

• After sending the first ConfigurationRequest message, the AT should wait for the response from the AN to know the Protocol and Packet Application subtypes accepted for a personality before configuring parameters for the Protocol subtypes and Application subtypes itself.

• Once the AT and the AN has agreed on the Protocol and Application subtypes, the AT should attempt to bundle as many as possible ConfigurationRequest messages sent by different Protocol and Application subtypes.

• The AN and the AT should bundle all the pending directed signaling messages in the Access Channel Capsule and Control Channel Capsule.

• The AT and the AN should only configure the non-default parameters.

• The AN should configure the First (Main) personality as the 1xEV-DO Release 0 personality.

• The AT and the AN should always HardLink the Protocol subtypes if same Protocol subtype is used across multiple personalities and the parameter values are the same as well.

ESG 1x EV DO Rev A Session Negotiation

Documents

Transcript of ESG 1x EV DO Rev A Session Negotiation