EVDO 1x Rel 0 Stu Notes Book 2

CDMA20001xEV-DO Release 0cdma university

CDMA2000 1xEV-DORelease 0

CDMA2000 1xEV-DORelease 0

Student GuideBook 2

80-31392-2 Rev B

Material Use RestrictionsThese written materials are to be used only in conjunction with the associated instructor-led class. They are not intended to be used solely as reference material.

No part of these written materials may be used or reproduced in any manner whatsoever without the written permission of QUALCOMM Incorporated.

Copyright © 2003 QUALCOMM Incorporated. All rights reserved.

QUALCOMM Incorporated5775 Morehouse DriveSan Diego, CA 92121U.S.A.

Revision History: 80-31392-2 Rev A replaces the previous version, 80-31392-2 X2. The version numbering system was changed for internal tracking purposes only.

Export of this technology may be controlled by the United States Government. Diversion contrary to U.S. law prohibited.

QUALCOMM is a registered trademark and registered service mark of QUALCOMM Incorporated.

cdma2000 is a registered certification mark of the Telecommunications Industry Association. Used under license. All other trademarks and registered trademarks are the property of their respective owners.

CDMA2000 1xEV-DO Release 0 80-31392-2 Rev B

© 2003 QUALCOMM Incorporated

Table of Contents – Book 2

CDMA20001xEV-DO Release 0cdma university

CDMA.HELP

[email protected]

Email hotline resource to assist our CDMA customers worldwide.

Experienced CDMA engineers in our Engineering Services Group will answer your technical questions on topics including:

–Industry Standards

–Infrastructure Design

–Voice Quality

–System Design

–Network Planning

–Network Optimization

–Test Engineering

–Training

iii




This page left blank intentionally.

iv




v

Table of Contents – Book 2 Acronyms and Abbreviations..............................................................ix CDMA2000 1xEV-DO – Book 2 Overview .................................. 8-1 Section 8: Session Layer................................................................. 8-2 Section Introduction ......................................................................... 8-3 Section Learning Objectives ............................................................ 8-4 Session Layer ................................................................................... 8-5 Overview................................................................................ 8-6 Protocols ................................................................................ 8-8 Encapsulation......................................................................... 8-9 Session Management Protocol ....................................................... 8-10 State Diagram (AT).............................................................. 8-12 State Diagram (AN) ............................................................. 8-13 Keep Alive Function ............................................................ 8-14 Messages .............................................................................. 8-15 Address Management Protocol ...................................................... 8-16 State Diagram (AT).............................................................. 8-18 State Diagram (AN) ............................................................. 8-19 Messages .............................................................................. 8-20 Address Assignment ............................................................ 8-22 Subnet .................................................................................. 8-23 Color Codes ......................................................................... 8-24 Color Code and Subnet Mapping......................................... 8-26 Long Code Masks ................................................................ 8-27 Mobility Management and Registration .............................. 8-28 Session Configuration Protocol...................................................... 8-29 State Diagram (AT).............................................................. 8-31 State Diagram (AN) ............................................................. 8-32 Restoring a Prior Session ..................................................... 8-33 Simple Session Negotiation Example.................................. 8-34 Extensive Session Negotiation Example ............................. 8-35 SMP, AMP, and SCP ..................................................................... 8-36 What We Learned in This Section ................................................. 8-37 Session Layer – Review ................................................................. 8-38 Section 9: Stream Layer................................................................. 9-1 Section Introduction ......................................................................... 9-2 Section Learning Objectives ............................................................ 9-3 Stream Layer .................................................................................... 9-4 Overview................................................................................ 9-5 Functions................................................................................ 9-6 Stream Configuration Procedure............................................ 9-7 Encapsulation......................................................................... 9-8 Packet ..................................................................................... 9-9




vi

What We Learned in This Section ................................................. 9-10 Stream Layer – Review .................................................................. 9-11 Section 10: Application Layer ..................................................... 10-1 Section Introduction ....................................................................... 10-2 Section Learning Objectives .......................................................... 10-3 Application Layer........................................................................... 10-4 Default Signaling Application........................................................ 10-5 Signaling Link Protocol (SLP)............................................. 10-7 Message Encapsulation (Non-fragmented).............. 10-8 Message Encapsulation (Fragmented) ..................... 10-9 SLP-D Header........................................................ 10-10 SLP-F Header......................................................... 10-11 SLP-D Transmit Sequence Number Variables ...... 10-12 SLP-D Receive Sequence Number Variables........ 10-13 Fragmentation Layer.............................................. 10-14 Signaling Network Protocol (SNP).................................... 10-15 Signaling Message Requirements .......................... 10-16 Message Information ............................................. 10-17 Packet Structure ..................................................... 10-18 Default Protocol Stack ........................................... 10-19 Default Packet Application .......................................................... 10-22 Radio Link Protocol ........................................................... 10-24 NAK Messages ...................................................... 10-25 Default Packet Application Encapsulation ............ 10-26 Transmit Sequence................................................. 10-27 Receive Sequence .................................................. 10-28 Location Update Protocol .................................................. 10-29 AT Requirements ................................................... 10-30 IS-2000-Compatible Location Subfields ............... 10-31 LocationNotification Message ............................... 10-32 Flow Control Protocol........................................................ 10-33 Messages and States............................................... 10-34 What We Learned in This Section ............................................... 10-36 Application Layer – Review......................................................... 10-37 Section 11: Quality of Service Support....................................... 11-1 Section Introduction ....................................................................... 11-2 Section Learning Objectives .......................................................... 11-3 QoS Functions ................................................................................ 11-4 Admission Control ............................................................... 11-5 Packet Classification............................................................ 11-8 Policing, Marking, and Dropping Packets ........................... 11-9 Marking and Dropping Packets ......................................... 11-10 Flow Control ...................................................................... 11-11 Dropping Non-delay Sensitive Packets Using RED.......... 11-12




vii

Scheduling.......................................................................... 11-14 What We Learned in This Section ............................................... 11-15 Quality of Service Support – Review........................................... 11-16 Section 12: Simple and Mobile IP ............................................... 12-1 Section Introduction ....................................................................... 12-2 Section Learning Objectives .......................................................... 12-3 Standards Status ............................................................................. 12-4 1xEV-DO Network Diagram and Protocol Stacks......................... 12-5 New Network Entities and Interface.................................... 12-6 Simple IP ........................................................................................ 12-7 Basics ................................................................................... 12-8 Initiation (PPP)..................................................................... 12-9 Origination and Resource Allocation................................. 12-10 PPP LCP............................................................................. 12-11 PPP CHAP ......................................................................... 12-13 PPP IPCP ........................................................................... 12-14 TCP/IP Header Compression............................................. 12-15 Termination........................................................................ 12-16 Mobile IP...................................................................................... 12-17 Basics Routing................................................................... 12-18 Registration ............................................................ 12-19 Adaptation to 3GPP2 ......................................................... 12-20 Initiation............................................................................. 12-21 PPP LCP................................................................. 12-22 PPP IPCP ............................................................... 12-23 Registration and Authentication Overview................................................................ 12-24 Message Flow ........................................................ 12-25 Phase 1 ................................................................... 12-26 Phase 2 ................................................................... 12-27 Multiple Addresses ............................................................ 12-28 Home Network Access ..................................................... 12-29 PDSN-HA Security............................................................ 12-30 Reverse Tunneling ............................................................. 12-32 Private Address Support .................................................... 12-34 Simple IP versus Mobile IP.......................................................... 12-35 QoS – Differentiated Services ...................................................... 12-37 Simple and Mobile IP References ................................................ 12-39 What We Learned in This Section ............................................... 12-40 Simple and Mobile IP – Review................................................... 12-41 Section 13: CDMA2000 1X and 1xEV-DO Hybrid Operation. 13-1 Section Introduction ....................................................................... 13-2 Section Learning Objectives .......................................................... 13-3




viii

1X and 1xEV-DO Access Network................................................ 13-4 1X and 1xEV-DO Access Terminal ............................................... 13-5 Acquisition and Synchronization State Operation............... 13-6 Idle State Operation ............................................................. 13-7 Traffic State Operation ...................................................... 13-10 Hybrid AT Responds to Voice Page ............................................ 13-11 Data Session Handoff Idle State 1X to 1xEV-DO................................................. 13-12 Idle State 1xEV-DO to 1X................................................. 13-13 Traffic State 1xEV-DO to 1X............................................ 13-14 What We Learned in This Section ............................................... 13-15 CDMA2000 1X and 1xEV-DO Hybrid Operation – Review ...... 13-16 Section 14: Course Summary ...................................................... 14-1 Course Summary ............................................................................ 14-2 What We Learned Section 1 Introduction......................................................... 14-4 Section 2 Key Concepts of 1xEV-DO ................................ 14-5 Section 3 Protocol Overview ............................................... 14-6 Section 4 Physical Layer..................................................... 14-7 Section 5 MAC Layer .......................................................... 14-8 Section 6 Security Layer................................................... 14-10 Section 7 Connection Layer.............................................. 14-11 Section 8 Session Layer .................................................... 14-12 Section 9 Stream Layer..................................................... 14-13 Section 10 Application Layer ........................................... 14-14 Section 11 Quality of Service Support.............................. 14-15 Section 12 Simple and Mobile IP ..................................... 14-16 Section 13 1X and 1xEV-DO Hybrid Operation .............. 14-17 Appendix A: Coverage Analysis .................................................. A-1 Coverage Analysis........................................................................... A-2 1xEV-DO Forward Link Coverage ................................................. A-4 IS-95A Forward Link Coverage Comparison ................................. A-5 1xEV-DO Reverse Link Coverage.................................................. A-6 IS-95A Reverse Link Coverage Comparison.................................. A-7 Appendix B: Field Trial Results....................................................B-1 Field Trial Overview ........................................................................B-2 San Diego Location ..........................................................................B-3 Test Configurations ..........................................................................B-4 Stationary Locations.........................................................................B-5 Mobile Drive Route..........................................................................B-6 SINR Distribution.............................................................................B-7 Field Trial Throughput Numbers .....................................................B-8




ix

Acronyms and Abbreviations 3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2 AAA Authentication, Authorization, and Accounting AC Access Channel ACK Acknowledgment ACPAC Access Channel MAC Layer Packet Authentication Code AES Advanced Encryption Standard AF Assured Forwarding AIA Air Interface Authentication AMP Address Management Protocol AN Access Network AP Access Point ARQ Automatic Retransmission Request ASIC Application Specific Integrated Circuit AT Access Terminal ATI Access Terminal Identifier AMP Access Management Protocol AWGN Additive White Gaussian Noise bps Bits Per Second BPSK Binary Phase Shift Keying BS Base Station BSC Base Station Controller BTS Base Station Transceiver System C/I Carrier-to-Interference CC Control Channel CCH Control Channel Header CDG CDMA Development Group CDM Code Division Multiplex CDMA Code Division Multiple Access CHAP Challenge Handshake Authentication Protocol CN Core Network COA Care-of Address CRC Cyclic Redundancy Check CSM Cell Site Modem dB Decibel DH Diffie-Hellman DHCP Dynamic Host Configuration Protocol diff-serv Differentiated Service DNS Domain Name System DO Data Optimized DRC Data Rate Control DRS Data Ready to Send DV Data Voice




x

EF Expedited Forwarding EIA Electronics Industry Association ETACS European Total Access Communications System EV Evolution FA Frequency Assignment FCP Flow Control Protocol FCS Frame Check Sequence FIPS Federal Information Processing Standards FIR Finite Impulse Response FL Forward Link FLM Forward Link Modem FTC Forward Traffic Channel GHz Gigahertz GPS Global Positioning System GRE Generic Routing Encapsulation GSM Global System Mobile HA Home Agent HAT Hybrid Access Terminal HDR High Data Rate HPSK Hybrid Quadrature Phase Shift Keying HRPD High Rate Packet Data HTTP HyperText Transfer Protocol HWG HDR Working Group Hz Hertz I In-Phase component ID Identification IETF Internet Engineering Task Force IKE Internet Key Extension IMSI International Mobile Subscriber Identity IMT International Mobile Telecommunication IP Internet Protocol IPCP IP Control Protocol IS Interim Standard ISP Internet Service Provider ITU International Telecommunications Union IV Initialization Vector JTACS Japanese Total Access Communications System kbps Kilobits Per Second kcps Kilochips Per Second KHz Kilohertz ksps Kilosymbols Per Second LCM Long Code Mask LCP Link Control Protocol LSB Least Significant Bit MAC Medium Access Control Mbps Megabits Per Second




xi

Mcps Megachips Per Second MHz Megahertz MPC Modem Pool Controller MPT Modem Pool Transceiver ms Milliseconds MSC Mobile Switching Center MT Mobile Terminated NAI Network Access Identifier NAK Negative Acknowledgment NAS Network Access Server NID Network Identification NMT Nordic Mobile Telephone Node B A logical node responsible for radio transmission/reception

in one or more cells to/from the User Equipment ns Nanosecond OCQPSK Orthogonal Complex Quadrature Phase Shift Keying OHM Overhead Manager OSI Open System Interconnection PA Power Amplifier PCCC Preferred Control Channel Cycle PCF Packet Control Function PCS Personal Communication System PDA Personal Digital Assistant PDSN Packet Data Serving Node PER Packet Error Rate PN Pseudo-noise PPP Point-to-Point Protocol PRL Preferred Roaming List PSK Phase-Shift Keying PSTN Public Switched Telephone Network PTM Push-To-Media PTT Push-To-Talk Q Quadrature-phase component QAM Quadrature Amplitude Modulation QoS Quality of Service QPSK Quadrature Phase-Shift Keying RA Reverse Activity RAB Reverse Activity Bit RAN Radio Access Network RADIUS Remote Authentication Dial-In User Server RF Radio Frequency RL Reverse Link RLM Reverse Link Modem RLP Radio Link Protocol ROT Rise Over Thermal RPC Reverse Power Control




xii

RRI Reverse Rate Indicator RSVP Resource Reservation Protocol RTC Reverse Traffic Channel RUM RouteUpdate Message Rx Receive SC Synchronous Control SCI Slot Cycle Index SCP Session Configuration Protocol SDP Session Description Protocol sec Second SF Selector Function SHA Secure Hash Algorithm SID System Identification SINR Signal-to-Interference plus Noise Ratio SIP Session Initiated Protocol SLP Signaling Link Protocol SLP-D SLP Delivery SLP-F SLP Fragmentation SMP Session Management Protocol SMR Specialized Mobile Radio SNMP Simple Network Management Protocol SNP Signaling Network Protocol SNR Signal-to-Noise Ratio SO Service Option TACS Total Access Communications System TCP Transmission Control Protocol TE Terminal Equipment TIA Telecommunications Industry Association TDM Time Division Multiplex TMSI Temporary Mobile Subscriber Identity Tx Transmit UATI Unicast Access Terminal Identifier UDP User Datagram Protocol UE User Equipment UTC Universal Coordinated Time VJHC Van Jacobsen Header Compression VoIP Voice over Internet Protocol µs Microsecond

CDMA2000 1xEV-DO Release 0

Section 8: Session Layer

© 2003 QUALCOMM Incorporated 8-1

80-31392-2 Rev B

Section 8-1cdma university



Session Layer8SECTION

Notes




80-31392-2 Rev B



SECTION INTRODUCTION

106AC_00.emf

Section Introduction

• Session Layer – Overview

– Protocols

– Encapsulation

• Session Management Protocol (SMP)

• Address Management Protocol (AMP)

• Session Configuration Protocol (SCP)

Notes




80-31392-2 Rev B



• Describe the functions of the Session Layer.

• Define sessions.

• Describe what the Session Management Protocol (SMP) does.

• Define the keep alive mechanism.

• Describe what the Address Management Protocol (AMP) does.

• Explain how UATIs are assigned.

• Discuss subnets and color codes and how they are used.

• Describe what the Session Configuration Protocol (SCP) does.

• Describe how session negotiation takes place.

Section Learning Objectives

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Session Layer

Air LinkManagement

Protocol

OverheadMessagesProtocol

PacketConsolidation

Protocol

Initialization StateProtocol

Idle StateProtocol

Connected StateProtocol

Route UpdateProtocol

SessionManagement

Protocol

SessionConfiguration

Protocol

StreamProtocol

Radio LinkProtocol

Control ChannelMAC Protocol

Access ChannelMAC Protocol

Reverse TrafficChannel MAC

Protocol

Forward TrafficChannel MAC

Protocol

SecurityProtocol

AuthenticationProtocol

EncryptionProtocol

Default PacketApplication

DefaultSignalingApplication

AddressManagement

Protocol

Key ExchangeProtocol

Physical LayerProtocol

ConnectionLayer

SessionLayer

StreamLayer

ApplicationLayer

MACLayer

SecurityLayer

PhysicalLayer

SignalingLink Protocol

SignalingNetwork Protocol

Location UpdateProtocol

FlowControl Protocol

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Session Layer – Overview

• The Session Layer contains protocols to negotiate a session between the Access Terminal (AT) and the Access Network (AN).

• A session is a shared state maintained between the AT and the AN.

• Opening an IS-856 session is analogous to calling your favorite bank for the first time and opening an account.

– You exchange information with the bank, they give you a checkbook, etc.

– Even after hanging up the phone, you still have an account with the bank.

– After opening the account, you may call your bank many times for various transactions, but you don’t have to exchange all the information that you exchanged with the bank on the first day.

Session Layer Overview

Except to open a session, an Access Terminal (AT) cannot communicate with an Access Network (AN) without having an open session.




80-31392-2 Rev B



• The shared state in the session maintains information such as:

– A unicast address (UATI) assigned to the AT

– Protocols and protocol configuration that were negotiated

– An estimate of the current AT location

• Sessions do not end when the connection ends.

• They do end when:

– The AT is unavailable for a period longer than the session timer.

– The AT is moved to a different network.

– The AN is sent a Close message.

• They do not end frequently.

Session Layer – Overview (continued)

Session Layer Overview (continued)

Do not confuse sessions with connections. During a single session, the AT and AN can open and close one connection multiple times. On the other hand, sessions do not end frequently (the default timer is 54 hours).




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Session Layer – Protocols

Session Layer Protocols

Session Management Protocol (SMP) – This high-level protocol provides the means to control the activation of the other Session Layer protocols. It also contains a session “keep alive” mechanism and ensures that the session is still valid, and manages closing of the session.

Address Management Protocol (AMP) – This protocol specifies procedures for the initial UATI assignment and maintenance of the AT addresses.

Session Configuration Protocol (SCP) – This protocol provides the means to negotiate and provision the protocols used during the session. It also negotiates the AT-specific configuration parameters for these protocols. This protocol uses the Generic Configuration Protocol for protocol negotiation.




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Session Layer – Encapsulation

StreamLayerPacket

SessionLayer

Payload

ConnectionLayer

Payload

SessionLayerPacket

Session Layer Encapsulation

The figure shows the relationship between Stream Layer packets, Session Layer packets, and Connection Layer payload. The Session Layer does not modify packets it transmits or receives.




80-31392-2 Rev B



• Introduction

• Protocol State Diagrams for the AT and AN

• Keep Alive Function

• Messages

Session Management Protocol

Notes




80-31392-2 Rev B



• Controls the activation of the Address Management and Session Control Protocols before a session is established.

• Provides a session keep alive mechanism.

• Manages closing of the session.

Session Management Protocol (continued)

Session Management Protocol

The Session Management Protocol (SMP) provides a means to control the activation of the Address Management (AMP) and Session Configuration (SCP) protocols. The actual behavior and message exchanges in each state of this protocol are mainly governed by the AMP and SCP.

This protocol also periodically ensures that the session is still valid (keep alive) and manages the closing of the session.




80-31392-2 Rev B



Session Management Protocol –State Diagram (AT)

State Diagram (AT)

The figure shows the Session Management Protocol state diagram for the AT. The SMP can be in one of three states:

Inactive state – This state applies only to the AT. In this state, the protocol waits for an Activate command, and there is no communication between the AT and the AN. The AT does not maintain any session related state. In addition, the AN may be unaware of the existence of the AT within its coverage area.

AMP Setup state – The AT and AN perform exchanges governed by the AMP, and the AN assigns a UATI to the AT.

Open state – A session is open, and the AT has an assigned UATI.




80-31392-2 Rev B



Session Management Protocol –State Diagram (AN)

State Diagram (AN)

The figure shows the Session Management Protocol state diagram for the AN. The SMP can be in one of three states:

AMP Setup state – The AT and AN perform exchanges governed by the AMP, and the AN assigns a UATI to the AT.

Open state – A session is open, and the AN has assigned a UATI to the AT.

Close state – This state applies only to the AN. The AN waits for a SessionClose message from the AT or an expiration of the Close state timer which is set to TSMPClose or TSMPMinClose, whichever is larger. In this state, if the AN receives any packet from the AT that contains anything but a SessionClose message, it stays in this state, discards the packet, and responds with a SessionClose message.




80-31392-2 Rev B



Session Management Protocol –Keep Alive Function

The keep alive function is a session maintenance mechanism.

• Occurs only if there is no directed traffic to/from the AT/AN.

• The AT and AN exchange KeepAliveRequest and KeepAliveResponse messages.

• Keep alive timer should be much longer than the dormancy timer.

• Keep alive mechanism can be disabled by setting TSMPCloseto 0.

• Session is closed if there is no traffic between the AT and AN for TSMPClose minutes (default is 54 hours).

Keep Alive Function

The AT and AN monitor the traffic flowing on the Forward Channel and Reverse Channel,

respectively, directed to or from the AT. If either the AT or the AN detects a period of inactivity

of at least TSMPClose/NSMPKeepAlive minutes, it may send a KeepAliveRequest message. The

recipient of the message shall respond by sending the KeepAliveResponse message. When a

KeepAliveResponse message is received, the AT shall not send another KeepAliveRequest

message for at least TSMPClose/NSMPKeepAlive minutes. After sending NSMPKeepAlive unacknowledged

KeepAliveRequest messages, the session times out.

The default value for TSMPClose is 54 hours, and for NSMPKeepAlive the default value is 3 hours.




80-31392-2 Rev B



Session Management Protocol –Messages

• SessionClose – Used by an AT or AN to terminate the current session. A CloseReason field is set to indicate the reason.

• KeepAliveRequest – Used by an AT or AN to verify that the peer is still alive.

• KeepAliveResponse – Used by an AT or AN to respond to a KeepAliveRequest message.

Notes




80-31392-2 Rev B



• Introduction


• Messages

• Address Assignment

• Subnets

• Color Codes

• Long Code Masks

• Mobility Management and Registration

Address Management Protocol

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Address Management Protocol (continued)

• Assigns to each AT a 128-bit UATI that is universally unique.

– The 128-bit address is never required to be sent on the Access Channel, and the AN can always send the short (32 bits) version of the UATI.

• Defines the concept of subnets for UATI used in subnet-based location update.

– The subnet concept replaces the need for packet zone ID, registration zones, TMSI zones, etc.

– For example, if a subnet is the footprint of a PCF, the AT sendsa route update message when it crosses PCF boundaries.

• Preserves Long Code Mask (LCM) assignments based on UATI.

Notes




80-31392-2 Rev B



Address Management Protocol –State Diagram (AT)

State Diagram (AT)

The figure shows the Address Management Protocol state diagram for the AT. The AMP operates in one of three states:

Inactive state – No communications between the AT and the AN. The AT does not have an assigned UATI, and the AN does not maintain a UATI for the AT. In addition, the AN may not be aware of the existence of the AT within its coverage area.

Setup state – The AT and the AN perform a UATIRequest/UATIAssignment/UATIComplete exchange to assign the AT a UATI.

Open state – The AT has been assigned a UATI. The AT and the AN may also perform a UATIRequest/UATIAssignment/UATIComplete or a UATIAssignment/ UATICompleteexchange to change the AT’s UATI.




80-31392-2 Rev B



Address Management Protocol –State Diagram (AN)

State Diagram (AN)

The figure shows the Address Management Protocol state diagram for the AN. The AMP operates in one of three states:

Inactive state – No communications between the AT and the AN. The AT does not have an assigned UATI, and the AN does not maintain a UATI for the AT. In addition, the AN may not be aware of the existence of the AT within its coverage area.

Setup state – The AT and the AN perform a UATIRequest/UATIAssignment/UATIComplete exchange to assign the AT a UATI.

Open state – The AT has been assigned a UATI. The AT and AN may also perform a UATIRequest/UATIAssignment/UATIComplete or a UATIAssignment/ UATICompleteexchange to change the AT’s UATI.




80-31392-2 Rev B



Address Management Protocol –Messages

• UpdateUATI – Used only in the Open state to change the current UATI assigned to an AT. If the AT receives this message, it sends a UATIRequest message to request a new UATI. If the AN receives this message, it may send a UATIAssignment message.

• UATIRequest – Used by an AT to request a UATI be assigned or reassigned to it by the AN.

• UATIAssignment – Used by an AN to assign or reassign a UATI to the AT.

Notes




80-31392-2 Rev B



Address Management Protocol –Messages (continued)

• UATIComplete – Used by the AT to notify the AN that it received the UATIAssignment message.

• HardwareIDRequest – Used by the AN to query the AT for its Hardware ID information.

• HardwareIDResponse – Used by the AT to respond to a HardwareIDRequest message, and provide the Hardware ID.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Address Assignment

Address Assignment

The AT uses a 32-bit pseudorandom generator to derive a SessionSeed. This SessionSeed is used as the RATI in the UATIRequest message. The RATI is discarded when the AT receives a “fresh” UATIAssignment message. The AN may include both UATI104 and UATISubnetMaskfields in the UATIAssignment message. If these are not included, the UATI[127:24] is implicitly assigned to be equal to SectorID[127:24], and UATISubnetMask is implicitly assigned to be the SubnetMask of the sector that received the UATIRequest message.




80-31392-2 Rev B



• The subnet for an address is obtained by performing a logical AND of the address and the subnet mask.

• Each sector advertises its SectorID which is also a 128-bit address. This is how the AT knows it has entered the footprint of a new subnet.

Subnet

Notes




80-31392-2 Rev B



• Because the 128-bit UATI does not fit in the LCM, and because sending a 128-bit UATI takes too much space in the Access Channel and Control Channel messages, an 8-bit Color Code (CC) is used as an alias for the subnet address.

• The Color Code "compresses" the subnet part of the SectorID into an 8-bit field.When the subnet of the sector changes, the Color Code changes. The network operator has to adopt a reuse scheme for Color Code to ensure neighboring sectors in different subnets do not advertise the same Color Code.

Color Codes

Notes




80-31392-2 Rev B



• The Color Code is the same within the same subnet and changes when the subnet changes.

• The same Color Code can be reused at a sufficiently large distance (with an 8-bit code, this distance is allowed to be quite large).

• The UATIColorCode is set to the Color Code of the sector on which the AT received the UATIAssignment message.

Color Codes (continued)

Notes




80-31392-2 Rev B



When the AN receives a UATIRequest by a new AT, the AN can optionally request the AT to send it the OldUATI[23+n:24].

• This is useful when the AN does not maintain a table that “translates” Color Code to the corresponding subnet address.

Color Code and Subnet Mapping

Notes




80-31392-2 Rev B



MQ[k] = MI[k-1], for k = 1,…, 41

MQ[0] = MI[0] ⊕ MI[1] ⊕ MI[2] ⊕ MI[4] ⊕ MI[5] ⊕

MI[6] ⊕ MI[9] ⊕ MI[15] ⊕ MI[16] ⊕ MI[17] ⊕

MI[18] ⊕ MI[20] ⊕ MI[21] ⊕ MI[24] ⊕ MI[25] ⊕

MI[26] ⊕ MI[30] ⊕ MI[32] ⊕ MI[34] ⊕ MI[41]

Long Code Masks

Long Code Masks

The UATI, Color Code, and SectorID are also used by the MAC Layer to derive the long code masks for the Reverse Traffic Channel and the Access Channel.




80-31392-2 Rev B



PDSN PDSN

BSC/PCF

Subnet

Sector

BSC/PCF

BSC/PCF

BSC/PCF

1 2 3

Event #1:- Idle handoff occurs.- No subnet change.

Event #2:- Idle handoff occurs.- Subnet change occurs.- AT sends its old UATI to the AN.- New AN retrieves the AT session information from the old AN (using information provided in the old UATI).- New AN establishes a new R-P link to the PDSN.- PDSN tears down the old R-P connection.- New AN assigns a new UATI to the AT.

Event #3:- Same as Event #2.

• Mobile IP finds the current PDSN (Foreign Agent).

• HDR Mobility Management allows the current PDSN to route the packet to the current BSC/PCF.

Mobility Management and Registration

Notes




80-31392-2 Rev B



• Introduction


• Restoring a Prior Session

• Simple and Extensive Session Negotiation Examples

Session Configuration Protocol

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Session Configuration Protocol (continued)

• Negotiates parameters associated with a session.

• For each configurable attribute, a default value is defined.

– If the default values are satisfactory for both sides, no negotiation is necessary.

• Either the AN or the AT can initiate session configuration.– The AT sends a ConfigurationRequest, and the AN sends a

ConfigurationStart.

• The negotiated attributes and protocols take effect only after the connection is dropped.

– This establishes an unambiguous demarcation point for the newly negotiated attributes and protocol to take effect.

Session Configuration Protocol

The default SCP provides for the negotiation and configuration of the set of protocols used during the session.

Two negotiation phases are supported:

AT-initiated negotiation – The AT initiates exchanges. This phase is used to negotiate the protocols that will be used in the session and to negotiate some parameters.

AN-initiated negotiation – The AN initiates exchanges. This phase is typically used to override default values used by the negotiated protocols.

This protocol uses the Generic Configuration Protocol procedures and messages when performing the negotiation in each phase. The SCP can also be negotiated; however, the default SCP must be used to do so.




80-31392-2 Rev B



Session Configuration Protocol –State Diagram (AT)

State Diagram (AT)

This figure shows the Session Configuration Protocol state diagram for the AT. The SCP can be in one of four states:

Inactive state – The protocol waits for an Activate command.

AT-Initiated state – Negotiation is performed at the initiative of the AT.

AN-Initiated state – Negotiation is performed at the initiative of the AN.

Open state – The AT may initiate the session configuration procedure at any time, and the AN may request the AT to initiate the session configuration at any time.




80-31392-2 Rev B



Session Configuration Protocol –State Diagram (AN)

State Diagram (AN)

This figure shows the Session Configuration Protocol state diagram for the AN. The SCP can be in one of four states:

Inactive state – The protocol waits for an Activate command.

AT-Initiated state – Negotiation is performed at the initiative of the AT.

AN-Initiated state – Negotiation is performed at the initiative of the AN.

Open state – The AT may initiate the session configuration procedure at any time, and the AN may request the AT to initiate the session configuration at any time.




80-31392-2 Rev B



Restoring a prior session:• The AT has the option of requesting the AN to restore a prior session.

• This avoids session renegotiation and DH key exchange when there are coverage holes and the AT travels across them.

AT

Coverage areaof HDR RAN 1

Coverage areaof HDR RAN 2

Est

ablis

hes

ase

ssio

n

1

Crosses a "no coverage zone" and moves to RAN 2

23

Get

s a

new

UA

TI

Req

uest

ress

urac

tion

of th

e ol

d se

ssio

n

4

Retrieve the old session

5

Session Configuration Protocol –Restoring a Prior Session

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple Session Negotiation Example

Simple Session Negotiation Example

This figure shows Key Exchange negotiation using only default parameters. Using default parameters greatly reduces session setup time.




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Extensive Session Negotiation Example

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0SMP, AMP, and SCP

Notes




80-31392-2 Rev B



The functions of the Session Layer.

What sessions are.

The functions of the Session Control Management Protocol (SMP).

What the keep alive mechanism is.

The functions of the Address Management Protocol (AMP).

How UATIs are assigned.

What subnets and color codes are and how they are used.

The functions of the Session Configuration Protocol (SCP).

How session negotiation takes place.

What We Learned in This Section

Notes




80-31392-2 Rev B



SECTION REVIEW

105AC_00

• Session Layer – Overview

– Protocols

– Encapsulation

• Session Management Protocol (SMP)

• Address Management Protocol (AMP)

• Session Configuration Protocol (SCP)

Session Layer – Review

Notes




80-31392-2 Rev B

Comments/Notes


Section 9: Stream Layer


80-31392-2 Rev B




Stream Layer9SECTION

Notes




80-31392-2 Rev B




106AC_00.emf

• Overview

• Functions

• Stream Configuration Procedure

• Encapsulation

• Packet


Notes




80-31392-2 Rev B



• Describe the functions of the Stream Layer.

• Describe how the Stream Layer encapsulates packets.

• Describe the procedures for Stream Layer configuration.

Section Learning Objectives

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Stream Layer

Air LinkManagement

Protocol


PacketConsolidation

Protocol


Idle StateProtocol



SessionManagement

Protocol


Protocol

StreamProtocol

Radio LinkProtocol




Protocol


Protocol

SecurityProtocol


EncryptionProtocol



AddressManagement

Protocol



ConnectionLayer

SessionLayer

StreamLayer

ApplicationLayer

MACLayer

SecurityLayer

PhysicalLayer





Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Stream Layer – Overview

Provides a mechanism to tag Application Layer packets

Notes




80-31392-2 Rev B



• Provides a mechanism to tag Application Layer packets by adding a Stream identifier.

• The Connection Layer’s Packet Consolidation Protocol uses tags to prioritize signaling and user traffic.

• Both the user and the signaling traffic are tagged.

• Applications with different QoS can be assigned separate streams.

Stream Layer – Functions

Stream Layer Functions

The Stream Layer provides the following functions:

Multiplexes application streams for one Access Terminal (AT). Stream 0 is always assigned to the Signaling Application and by default to the Default Signaling Protocol. The other streams can be assigned to applications with different Quality of Service (QoS) requirements, or other applications.

Provides configuration messages that map applications to streams.

The Stream Layer Protocol is used to provide these functions.




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Stream Configuration Procedure

• The AT and AN may use the ConfigurationRequestand ConfigurationResponse messages to select the applications carried by each stream.

• The ConfigurationRequest and ConfigurationResponse messages may be exchanged only when the session is set up.

• The AT and AN shall process the messages as specified in the Generic Configuration Protocol.

Stream Configuration Procedure

Applications can be mapped to the different streams during the AT-initiated state of the Session Configuration Protocol, as well as during the AN-initiated state of that protocol.




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Stream Layer – Encapsulation

Session Layer Payload

Stream Layer Payload

Application Layer Payload

Stream Layer Header

Stream Layer Encapsulation

The Stream Layer Protocol receives application packets for transmission from up to four different applications. The protocol adds a 2-bit Stream header that is associated with the application sending the application packet. The protocol forwards the Stream Layer packet to the Session Layer for transmission.

All Stream Layer packets forwarded to the Session Layer are octet aligned.

The protocol receives Stream Layer packets from the Session Layer and removes the Stream Layer header. The application packet obtained in this manner is forwarded to the application indicated by the Stream field of the Stream Layer header.




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Stream Layer – Packet

Application Layer PacketStream Layer

Header

2 Bits

x Bits

x must satisfy the condition, x modulo 8 = 6

Stream Layer Packet

The 2-bit header is used to identify up to four different applications.




80-31392-2 Rev B



The functions of the Stream Layer.

How the Stream Layer encapsulates packets.

The procedures for Stream Layer configuration.

What We Learned in This Section

Notes




80-31392-2 Rev B



SECTION REVIEW

105AC_00

Stream Layer – Review

• Overview

• Functions

• Stream Configuration Procedure

• Encapsulation

• Packet

Notes




80-31392-2 Rev B

Comments/Notes


Section 10: Application Layer

80-31392-2 Rev B




Section 10:Application Layer

Application Layer10SECTION

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Section Introduction


106AC_00.emf

• Default Signaling Application

– Signaling Link Protocol (SLP)

– Signaling Network Protocol (SNP)

• Default Packet Application– Radio Link Protocol (RLP)

– Location Update Protocol

– Flow Control Protocol

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Section Learning Objectives

• Describe the functions of the Application Layer.

• Describe the functions of the Default Signaling Application protocols.

• Describe the functions of the Default Packet Application protocols.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Application Layer

Air LinkManagement

Protocol


PacketConsolidation

Protocol


Idle StateProtocol



SessionManagement

Protocol


Protocol

StreamProtocol

Radio LinkProtocol




Protocol


Protocol

SecurityProtocol


EncryptionProtocol



AddressManagement

Protocol



ConnectionLayer

SessionLayer

StreamLayer

ApplicationLayer

MACLayer

SecurityLayer

PhysicalLayer





Application Layer

The Application Layer consists of two default applications:

Default Signaling Application – Transports 1xEV-DO protocol messages.

Default Packet Application –Transports user data.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Default Signaling Application

• Signaling Link Protocol (SLP)

– Delivery Layer (SLP-D)

– Fragmentation Layer (SLP-F)

• Signaling Network Protocol (SNP)

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Default Signaling Application (continued)

The default Signaling Application consists of the Signaling Link Protocol (SLP) and the Signaling Network Protocol (SNP).

• SLP provides message fragmentation, reliable and best-effort message delivery, and duplicate detection for messages that are delivered reliably.

• SNP is used by 1xEV-DO protocols to exchange messages and application-specific control messages.

Default Signaling Application

Signaling Link Protocol (SLP) – Provides fragmentation mechanisms, as well as reliable and best-effort delivery mechanisms for signaling messages. When used in the context of the Default Signaling Application, SLP carries SNP packets.

Signaling Network Protocol (SNP) – Provides message transmission services for signaling messages.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Signaling Link Protocol (SLP)

Signaling Link Protocol (SLP)

The SLP consists of two sublayers:

Delivery Layer, SLP-D – Provides best-effort and reliable delivery for SNP packets.

Fragmentation Layer, SLP-F – Provides duplicate detection and retransmission for messages using reliable delivery. SLP-F provides fragmentation for SLP-D packets.



80-31392-2 Rev B




Signaling Link Protocol:Message Encapsulation (Non-fragmented)

Signaling Link Protocol: Message Encapsulation (Non-fragmented)

The figure shows the relationship between a message, SNP packets, SLP packets, and Stream Layer Protocol for a case where the SLP does not fragment the SNP packet.



80-31392-2 Rev B




Signaling Link Protocol:Message Encapsulation (Fragmented)

Signaling Link Protocol: Message Encapsulation (Fragmented)

The figure shows the relationship between a message, SNP packets, SLP packets, and Stream Layer Protocol for a case where the SLP does fragment the SNP packet.



80-31392-2 Rev B




Signaling Link Protocol:SLP-D Header

3SequenceNumber

0 or 1SequenceValid

3AckSequenceNumber

0 or 1AckSequenceValid

1HeaderIncluded

Length (bits)Field

Signaling Link Protocol: SLP-D Header

The SLP-D header contains the following fields:

HeaderIncluded – SLP-D included flag

The following fields are included only if the HeaderIncluded field is set to ‘1’:

– AckSequenceValid – Set to ‘1’ if the AckSequenceNumber field is valid; otherwise, the sender sets this field to ‘0’.

– AckSequenceNumber – If the AckSequenceValid field is set to ‘1’, the sender sets this field to the sequence number of the last reliable delivery SLP-D payload it received; otherwise, the sender sets this field to ‘0’.

– SequenceValid – Set to ‘1’ if the SequenceNumber field contains a valid value; otherwise, set to ‘0’.

– SequenceNumber – If the SequenceValid field is set to ‘1’, the sender sets this field to the sequence number of the reliable SLP-D payload; otherwise, the sender sets this field to ‘0’.



80-31392-2 Rev B




Signaling Link Protocol:SLP-F Header

0 or 1OctetAlignmentPad

0 or 6SequenceNumber

0 or 1End

0 or 1Begin

1Fragmented

4Reserved

Length (bits)Field

Signaling Link Protocol: SLP-F Header

The SLP-F header contains the following fields:

Reserved – Sender sets this field to ‘0’.

Fragmented – SLP-F header fragmentation indicator.

Begin – Start of SLP-D packet flag. Set to ‘1’ if the SLP-F payload contains the beginning of an SLP-D packet; otherwise, set to ‘0’. Included only if the Fragmented field is set to ‘1’.

End – End of SLP-D packet flag. Set to ‘1’ if the SLP-F payload contains the end of an SLP-D packet; otherwise, set to ‘0’. Included only if the Fragmented field is set to ‘1’.

SequenceNumber – SLP-F packet sequence number. Sender increments this field for each new SLP-F packet sent. Included only if the Fragmented field is set to ‘1’.

OctetAlignmentPad – Octet alignment padding. Sender sets this field to ‘0’ if the Fragmented field is set to ‘1’ and the Begin field is set to ‘0’; otherwise, the sender omits this field.



80-31392-2 Rev B




Signaling Link Protocol:SLP-D Transmit Sequence Number Variables

Signaling Link Protocol: SLP-D Transmit Sequence Number Variables

SLP-D is ACK-based with a sequence space of S = 3 bits.

SLP-D maintains the following variables for reliable delivery of SLP-D packet payloads:

V(S) is the sequence number of the next SLP-D packet to be sent.

V(N) is the sequence number of the next expected SLP-D packet.

Rx is a 2S-bit vector. Rx[i] = ‘1’ if the SLP-D packet with sequence number i was received.



80-31392-2 Rev B




Signaling Link Protocol:SLP-D Receive Sequence Number Variables

Signaling Link Protocol: SLP-D Receive Sequence Number Variables

The SLP-D reliable-delivery receiver maintains a 2S-1 bit variable, V(N). V(N) contains the sequence number of the next expected SLP-D packet. The receiver also maintains a 2S-bit vector Rx. Rx[k] is set to ‘1’ if the SLP-D packet with sequence number k has been received.



80-31392-2 Rev B




Signaling Link Protocol:Fragmentation Layer

SLP-F is a self-synchronizing, loss detection protocol with a sequence space of S = 6 bits.

SLP-F maintains the following variables for SLP-F packets:

• V(S) – Sequence number of the next SLP-F packet to be sent

• V(N) – Sequence number of the next expected SLP-F packet

• Sync – SLP-F synchronized flag

Signaling Link Protocol: Fragmentation Layer

The sender constructs the SLP-F payload(s) by adding the SLP-F header.

The sender constructs the SLP-F payload(s) from an SLP-D packet. If the SLP-D packet exceeds the current maximum SLP-F payload size, then the sender fragments the SLP-D packet.

If the sender does not fragment the SLP-D packet, then the SLP-D packet is the SLP-F payload. If the sender does fragment the SLP-D packet, then each SLP-D packet fragment is an SLP-F payload.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Signaling Network Protocol (SNP)

SNP is a message-routing protocol that routes messages to protocols according to the Type field provided in the SNP header.

• The actual protocol indicated by the Type field is negotiated during session setup.

• The remainder of the message following the Type field is processed by the protocol specified in the Type field.

Signaling Network Protocol (SNP)

SNP receives messages for transmission from multiple protocols. SNP adds the Type field to each message and forwards it for transmission to the SLP.

SNP receives messages from the SLP and routes these messages to the associated protocols according to the value of the Type field in the SNP header.



80-31392-2 Rev B




Signaling Network Protocol:Signaling Message Requirements

• Messages must be octet aligned.

• The receiver silently discards all unrecognized messages and fields or fields set to invalid values.

• Future revisions will add new fields at the end of the message.

Signaling Network Protocol: Signaling Message Requirements

These signaling message requirements apply to all protocols that carry messages using SNP and that provide for message extensibility.



80-31392-2 Rev B


Each message definition contains the following information:

Physical Layer channel on which the message can be transmitted:– CC – Control Channel (synchronous or asynchronous capsule)– CCsyn – Control Channel synchronous capsule– AC – Access Channel– FTC – Forward Traffic Channel– RTC – Reverse Traffic Channel

SLP requirements:– Best Effort – Message sent once and subject to erasure– Reliable – Erasures detected, and message retransmitted one or more times, if

necessaryAddressing mode:

– Broadcast – If a broadcast address can be used with this message– Multicast – If a multicast address can be used with this message– Unicast – If a unicast address can be used with this message

Priority – A number between 0 and 255, where lower numbers indicate higher priorities. The Connection Layer (specifically, the Packet Consolidation Protocol) uses this to prioritize messages for transmission.



Signaling Network Protocol:Message Definition



80-31392-2 Rev B




Signaling Network Protocol:Packet Structure

Signaling Network Protocol: Packet Structure

This figure shows the SNP packet structure. The protocol constructs a SNP packet by adding the SNP header in front of the payload. The SNP header is one octet in length, and messages are always an integer number of octets in length. For future revisions, the transmitter shall add new fields only at the end of a message.



80-31392-2 Rev B




Signaling Network Protocol:Default Protocol Stack

Type Protocol Constant Name Layer

0x14 Stream 0 Application NAPP0Type Application




0x13 Stream Protocol NSTRType Stream

0x10 Session Management Protocol NSMPType Session

0x11 Address Management Protocol NADMPType Session

0x12 Session Configuration Protocol NSCPType Session

0x0a Air Link Management Protocol NALMPType Connection

0x0b Initialization State Protocol NISPType Connection

Signaling Network Protocol: Default Protocol Stack

This table shows the Type definitions associated with the Default Protocol Stack.



80-31392-2 Rev B




Signaling Network Protocol:Default Protocol Stack (continued)


0x0c Idle State Protocol NIDPType Connection

0x0d Connected State Protocol NCSPType Connection

0x0e Route Update Protocol NRUPType Connection

0x0f Overhead Messages Protocol NOMPType Connection

0x09 Packet Consolidation Protocol NPCPType Connection

0x08 Security Protocol NSPType Security

0x05 Key Exchange Protocol NKEPType Security

0x06 Authentication Protocol NAPType Security

0x07 Encryption Protocol NEPType Security

Notes



80-31392-2 Rev B




Signaling Network Protocol:Default Protocol Stack (continued)


0x01 Control Channel MAC Protocol NCCMPType MAC

0x02 Access Channel MAC Protocol NACMPType MAC

0x03 Forward Traffic Channel MAC Protocol NFTCMPType MAC

0x04 Reverse Traffic Channel MAC Protocol NRTCMPType MAC

0x00 Physical Layer Protocol NPHYType Physical

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Default Packet Application

• Radio Link Protocol (RLP)

• Location Update Protocol

• Flow Control Protocol

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Default Packet Application (continued)

The Default Packet Application provides an octet stream that can be used to carry packets between the AT and the AN.

It consists of

• Radio Link Protocol (RLP)

• Packet Location Update Protocol

• Flow Control Protocol

Default Packet Application

The Default Packet Application consists of:

Radio Link Protocol (RLP) – Provides in-order delivery of RLP packets, retransmission, and duplicate detection, thus reducing the radio link error rate as seen by the higher layer protocols.

Packet Location Update Protocol – Defines location update procedures and messages in support of mobility management for the Packet Application.

Flow Control Protocol – Provides the flow control mechanism for SN and AN streams.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Radio Link Protocol (RLP)

• Provides an octet stream service with acceptably low erasure rate for higher layer protocols such as TCP.

• NAK-based, with one retransmission permitted.

• Unaware of higher layer framing and operates on a featureless octet stream.

• Sequence numbers are 22 bits in length and octet addressable.

• A “flush packet” is sent at the end of a data burst to detect potentially missing data and to create a NAK.

Radio Link Protocol (RLP)

RLP provides an octet stream service with an acceptably low erasure rate for efficient operation of higher layer protocols (for example, TCP). When used as part of the Default Packet Application, the protocol commonly carries variable length PPP packets. When RLP is used with PPP, there is no relationship between the PPP packets and the RLP packets; a large PPP packet may span multiple RLP packets, or a single RLP packet may contain all or part of several small PPP Packets. RLP is unaware of higher layer framing.

RLP uses Negative Acknowledgment (NAK)-based retransmissions. If the receiver fails to receive octets whose retransmission it has already requested once, the receiver forwards the octets it has received to the upper layer, and continues reception beyond the missing octets.

Note: Multiple NAKs are not permitted, because they can cause timeouts of transmit buffers when used with the Transmission Control Protocol (TCP).



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Radio Link Protocol: NAK Messages

A NAK request is specified in terms of the first octet missing from the sequence (FirstErased) and the length of the missing octet sequence(WindowLen).

There are multiple NAK requests per NAK signaling message.

Note



80-31392-2 Rev B




Radio Link Protocol:Default Packet Application Encapsulation

Radio Link Protocol: Default Packet Application Encapsulation

The figure shows the relationship between the octet stream from the upper layer, an RLP packet, and a Stream Layer payload.



80-31392-2 Rev B




Radio Link Protocol:Transmit Sequence

Radio Link Protocol: Transmit Sequence

The RLP transmitter maintains an S-bit variable, V(S), for all transmitted RLP data octets. V(S) is the sequence number of the next RLP data octet to be sent. The sequence number field (SEQ) in each new RLP packet transmitted is set to V(S), which corresponds to the sequence number of the first octet in the packet. The sequence number of the ith octet in the packet (with the first octet being octet 0) is implicitly given by SEQ+i. V(S) is incremented for each octet contained in the packet.

After transmitting a packet, the RLP transmitter starts an RLP flush timer for time TRLPFlush. If the RLP transmitter sends another packet before the RLP flush timer expires, the RLP transmitter resets and restarts the timer. If the timer expires, the RLP transmitter disables the flush timer and sends an RLP packet that contains the octet with sequence number V(S)-1. The RLP transmitter allows sufficient time before deleting a packet transmitted for the first time.

Upon receiving a NAK message, the RLP inserts a copy of the requested octet(s) into its output stream, if those octets are available. If the NAK record includes any sequence number greater than or equal to V(S), RLP performs reset procedures. If the NAK record does not include any sequence number greater than or equal to V(S), but the requested octets are not available for retransmission, RLP ignores the NAK.



80-31392-2 Rev B




Radio Link Protocol:Receive Sequence

Radio Link Protocol: Receive Sequence

The RLP receiver shall maintain two S-bit variables for receiving:

V(R) – Contains the sequence number of the next octet expected to arrive.

V(N) – Contains the sequence number of the first missing octet, as described below.

In addition, the RLP receiver shall keep track of the status of each octet in its resequencing buffer indicating whether or not the octet was received. Three S-bit variables are used:

V(S) – Indicates the sequence number of the next octet to be sent.

V(R) – Indicates the sequence number of the next octet expected to be received.

V(N) – Indicates the sequence number of the first missing octet.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Location Update Protocol

The Location Update Protocol defines location update procedures and messages for mobility management for the Default Packet Application.

• Location Update Protocol provides procedures for the AN to determine the location of the AT.

• These procedure are also used in performing data session handoffs from a 1X to a 1xEV-DO network.

Notes



80-31392-2 Rev B




Location Update Protocol:AT Requirements

• If the AT receives a LocationRequest message, it sends a LocationNotification message. The AT sets the LocationType, LocationLength, and LocationValue fields of the LocationNotification message to its stored values of these fields.

• If the AT receives a LocationAssignment message, it stores the value of the LocationType, LocationLength, and LocationValue fields of the LocationAssignment message. The AT then sends a LocationComplete message.

• If the AT receives a SessionClose indication, it sets LocationValue to NULL.

Notes



80-31392-2 Rev B




Location Update Protocol:IS-2000-Compatible Location Subfields

LocationValue Subfields Number of Bits

SID 15

Reserved 1

NID 16

PACKET_ZONE_ID 8

Location Update Protocol: IS-2000-Compatible Location Subfields

There are two LocationType encoding types: one is for a TIA/EIA-IS-2000-compatible location, and the other is a packet data service identifier. The LocationValue subfields above are compatible with IS-2000.

The LocationValue subfields are:

SID – System identifier for the current AN

NID – Network identifier for the current AN

PACKET_ZONE_ID – Packet zone identifier for the current AN

LocationValue attributes are included in the LocationAssignment message and LocationNotification message.



80-31392-2 Rev B




Location Update Protocol:LocationNotification Message

The AT sends out a LocationNotification message either in response to a LocationRequest message or in an unsolicited manner. The RanHandoff attribute must be set to 1 for this capability.

• This procedure of LocationUpdate is used when the AT performs a dormant packet data session handoff from a CDMA2000 network to a 1xEV-DO network. The assumption is that a 1X-to-1xEV-DO session exists.

• When the AT with a dormant packet data session on a CDMA2000 network detects a 1xEV-DO signal, it sends an unsolicited LocationNotification message to the AN. This allows the AN to set up an A11-A10 connection between the target PCF and the PDSN.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Flow Control Protocol

The Flow Control Protocol provides procedures and messages used by the AT and the AN to perform flow control for the Default Packet Application.

Using the procedures defined in this protocol, the Default Packet Application Protocol controls the flow of packets on the AN and SN streams.

Notes



80-31392-2 Rev B




Flow Control Protocol:Messages and States

The AT uses flow control messages, XonRequest and XoffRequest, to indicate whether it can accept data on a particular stream.

• If the AT can accept data on the (AN or SN ) stream, it sends anXonRequest message to the AN. The state of the stream is changed to “Open.”

• If the AT cannot accept data on the (AN or SN ) stream, it sends an XoffRequest message to the AN. The state of the stream is “Close.”

• When the AT is ready to exchange data, it can also send an RLP packet. This is an implicit XonRequest, and the AN can assume that the state of the stream is “Open.”

The AN cannot send data to the AT on a particular stream unless the AT has specifically opened a stream.

Notes



80-31392-2 Rev B




Flow Control Protocol:Messages and States (continued)

• The AN sends the DataReady message to indicate to the AT that it has data to send.

• The AT responds to a DataReady message by sending a DataReadyAck message.

• The AT then sends XonRequest message when it thinks it can receive data. Unless the AN receives the XonRequest message, it cannot send data to the AT.

States of the streams are persistent across multiple connections. Transitions to dormancy do not affect states of the streams.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0What We Learned in This Section

The functions of the Application Layer.

The functions of the Default Signaling Application protocols.

The functions of the Default Packet Application protocols.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Application Layer – Review

SECTION REVIEW

105AC_00

• Default Signaling Application

– Signaling Link Protocol (SLP)

– Signaling Network Protocol (SNP)

• Default Packet Application– Radio Link Protocol (RLP)

– Location Update Protocol

– Flow Control Protocol

Notes



80-31392-2 Rev B


Comments/Notes


Section 11: Quality of Service Support

80-31392-2 Rev B




Section 11:Quality of Service Support

Quality of Service

Support11SECTION

Notes



80-31392-2 Rev B





106AC_00.emf

• QoS Functions– Admission Control

– Packet Classification

– Policing, Marking, and Dropping Packets

– Flow Control

– Scheduling

Notes



80-31392-2 Rev B




• Describe the QoS functions:

– Admission Control



– Flow Control

– Scheduling

• Discuss where the QoS functions are performed in CDMA2000 packet networks.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0QoS Functions

Quality of Service (QoS) functions ensure that the different elements involved in the QoS delivery are informed of the flow identification and its QoS requirements (QoS signaling).

Each of these functions must do its part in delivering the QoS:

• Admission control• Packet classification • Policing, marking, and dropping packets• Flow control for back-pressure• Scheduling

QoS Functions

A flow is a stream of information from a source to a destination that requires the same level of Quality of Service (QoS) defined.

The network elements involved in QoS delivery include:

Access Terminal (AT)

Base Station Controller (BSC)

Base Station Transceiver System (BTS)

Packet Data Serving Node (PDSN)



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0QoS Functions – Admission Control

• Before a network can give QoS guarantees to a flow, it must make sure it can accept the flow and deliver the required QoS without adversely affecting the QoS of flows already in the system.

• The network needs to know the amount of flow and the type of QoS required.

– Amount of flow is often specified in terms of leaky bucket parameters.

– Required QoS is often specified in terms of data rate requirements, packet delay requirements, and delay jitter requirements.

Admission Control

All systems that claim to provide QoS guarantees in the absolute sense must have admission control. An example of absolute QoS might guarantee that 99% of the packets will see delays of 200 ms or less.

Relative guarantees can be made without admission control. An example of relative QoS might guarantee that user A will get twice as much throughput as user B. Relative guarantees are easier to provide but cannot support applications with specific QoS requirements.



80-31392-2 Rev B




QoS Functions – Admission Control (continued)

QoS Admission Control

1. The bucket fills up at a rate of P tokens per second.

2. The maximum number of tokens the bucket can store is b bits.

3. An incoming packet that is L bits long can go into the network only if the bucket contains L bits of tokens.

4. When the packet that is L bits long enters the network, the number of tokens in the bucket is reduced by L bits.



80-31392-2 Rev B




QoS Functions – Admission Control (continued)

QoS provisioning can occur in two ways:

• QoS signaling – The two end points of the application, or the two end points of the wireless network, exchange signaling messages to indicate to each other and to all the elements in between the QoS requirements of the new flow that needs to come in.

• Policy-based – The network knows that flow between certain end points (IP address, port numbers) or flow that carries a certain type of application needs a certain type of QoS.

QoS signaling is a way to dynamically configure the policy.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0QoS Functions – Packet Classification

Packet classification occurs at the ingress (initial router) of the network.

• Identify packet as belonging to a particular flow, and hence, requiring a particular QoS.

• Packet classification is based on the header information.

• A mapping between the header values and QoS requirements must exist before packets start flowing. Mapping can be done through:

– QoS signaling

– Policy or service-level agreement (SLA)

• Packet classification is done by:– PDSN on the Forward link

– AT on the Reverse link

Packet Classification

Packet classification is the first step in QoS delivery.



80-31392-2 Rev B




QoS Functions – Policing, Marking, and Dropping Packets

The incoming traffic from an admitted flow must be policed, so it does not exceed the negotiated parameters; otherwise, it affects the QoS offered to other flows.

• Policing occurs at the ingress, or entry point, of the network using the leaky bucket parameters.

• A packet that is outside the leaky bucket bounds is either marked or dropped.

– If the flow is delay sensitive, the packet is dropped.

– If the flow is not delay sensitive, the packet is marked as low priority. This lower priority marking usually causes the packet to be treated as best-effort traffic.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Marking and Dropping Packets

Marking and Dropping Packets

When a packet is being marked, it is allowed into the network even if the token bucket does not contain enough tokens.



80-31392-2 Rev B




• Several entities are involved in QoS delivery to a flow on the Forward link:

– PDSN has the IP header information.– BSC has the overall radio channel state.– BTS has the local queue for transmission over the air.

• Even with the best admission control schemes, statistical changes in channel condition sometimes cause queues to back up, and packets must be dropped for non-delay sensitive flows.

• The PDSN is the most appropriate place to drop packets. It knowsthe IP packet boundaries and has IP header information to decidewhich packet to drop.

• To ensure that the packet drop response to air link congestion happens quickly, flow control back-pressure must occur from the BTS to the BSC and then to the PDSN.

QoS Functions – Flow Control

Notes



80-31392-2 Rev B




Dropping Non-delay Sensitive Packets Using RED

Random Early Detection (RED) is used to drop packets.

• RED causes degradation of QoS as congestion approaches.

• When the queue length goes beyond a threshold T, the incoming packets are dropped randomly with probability p that goes up as queue length increases.

• Best effort and marked packets may have a lower threshold T1, while the unmarked QoS packets have a higher threshold T2 (T2 > T1).

• Packet dropping is done on both the Forward link and Reverse link in response to congestion.

Notes



80-31392-2 Rev B




Dropping Non-delay Sensitive Packets Using RED (continued)

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0QoS Functions – Scheduling

Scheduling of packets on the 1xEV-DO Forward link takes advantage of multiuser diversity.

For QoS implementation, the challenge is to deliver QoS guarantees while taking advantage of multiuser diversity where possible.

• For delay-sensitive traffic, the scheduler gives high priority compared to other traffic.

• For other traffic, compute DRC/f(T), where f(T) is a function of the throughput for that flow.

– For best effort traffic, f(T)=T.

– For rate sensitive, f(T) = T-Treq, where Treq is the required throughput.

Scheduling Example

There are two users: user 1 is a best effort user, while user 2 has a minimum rate requirement of 200 kbps. Both users have a fixed Data Rate Control (DRC) of 614.4 kbps. Compare 614.4/T1 to 614.4/(T2-200), where T1 is the throughput of user 1 in kbps, and T2 is the throughput of user 2. If 614.4/T1 is larger than 614.4/(T2-200), user 1 is served; otherwise, user 2 is served.

In the steady state, the users are served such that 614.4/T1 and 614/(T2-200) are equal. This leads to T1=207.2 kbps and T2=407.2 kbps.

Note: The scheduler served the two users so that the 200 kbps minimum requirement of user 2 was met first, and the excess capacity of the system (i.e., 414.4 kbps) was split equally between the two users (i.e., 207.2 kbps to each user).



80-31392-2 Rev B




QoS functions:




– Flow control

– Scheduling

Where the QoS functions are performed in CDMA2000 packet networks.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Quality of Service Support – Review

SECTION REVIEW

105AC_00

• QoS Functions– Admission Control



– Flow Control

– Scheduling

Notes


Section 12: Simple and Mobile IP


80-31392-2 Rev B

cdma university Section 12-1


Section 12:Simple and Mobile IP

Simple and Mobile IP12SECTION

Notes




80-31392-2 Rev B




106AC_00.emf

• Standards Status

• 1xEV-DO Network Diagram and Protocol Stacks

• Simple IP

• Mobile IP

• QoS

Notes




80-31392-2 Rev B



• What is the 3GPP2 Wireless IP Network standard?

• How does Simple IP work?

• How does Mobile IP work?

• How does Simple IP compare to Mobile IP?

• How is QoS supported?

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Standards Status

TSG-X is a 3GPP2 working group responsible for developing 3G wireless IP network architectures and standards based on protocols developed by the Internet Engineering Task Force (IETF).

• TSG-X documents are balloted at regional standards organizations (i.e., TIA, TTC, TTA, CWTS).

TR-45.6 is a TIA subcommittee responsible for balloting the documents produced by TSG-X. TR-45.6 standards include:

• TIA/EIA/TSB115, “Wireless IP Network Architecture based on IETF Protocols,” December 2000

• TIA/EIA/IS-835, “Wireless IP Network Standard,” December 2000

• TIA/EIA/IS-835-A, “Wireless IP Network Standard,” May 2001

• TIA/EIA/IS-835-B, “Wireless IP Network Standard,” September 2002

• TIA/EIA/IS-835-C, “Wireless IP Network Standard,” For Q3 2003 release

Notes




80-31392-2 Rev B



1xEV-DO Network Diagram and Protocol Stacks

Notes




80-31392-2 Rev B



Network Diagram and Protocol Stacks –New Network Entities and Interface

Packet Data Serving Node (PDSN):• Terminates the AT PPP link to support framing IP packets.• Hosts Foreign Agent (FA) to support Mobile IP.• Routes packets between IP AN and IP core network.• Hosts RADIUS client to communicate with AAA server.

AAA performs authentication, authorization, and accounting.

Packet Control Function (PCF): • Provides PPP frame transport (via tunneling) between BSC and PDSN.• Can be integrated with BSC. In this case, no A8/A9 interface.• If not integrated, A8/A9 is the open interface with BSC.

Between PCF and PDSN, A10 connections are IP tunnels carrying PPP frames, and A11 is the signaling interface for managing A10 connections.Between BSC and PCF, A8 connections are IP tunnels carrying PPP frames, and A9 is the signaling interface for managing A8 connections.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP

• Basics

• Initiation

• Origination and Resource Allocation

• Point-to-Point Protocol (PPP)

• TCP/IP Header Compression

• Termination

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – Basics

1. AT establishes a PPP link with PDSN1 and obtains an IP address.2. AT uses this address to communicate with a Correspondent Node (CN).3. AT moves to PDSN2 serving area.4. AT establishes a new PPP link with PDSN2 and obtains a new IP address.5. AT now uses a different address to communicate with the server.

The IP address is associated with PDSN; thus, IP connectivity cannot be maintained across PDSN boundary.

AT PDSN1

PDSN2

Server

AT

1

2

3

4

5Internet

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – Initiation (PPP)

The AT requests the establishment of the channel for purposes ofdata packet exchange.

• If authorized by the AN AAA, the network resource (Traffic Channel, A8/A10 connections) is allocated.

The AT and PDSN establish a PPP link.• PPP Link Control Protocol (LCP):

– CHAP is enabled.

• PPP Challenge Handshake Authentication Protocol (CHAP):– The AT Network Access Identifier (NAI), in the form of user@realm, is

authenticated.

• PPP IP Control Protocol (IPCP):– An IP address is assigned to the AT.

– TCP/IP header compression capability is negotiated.

The AT can now access the Internet.

Notes




80-31392-2 Rev B



Simple IP –Origination and Resource Allocation

If authorized by an AAA, a Traffic Channel is assigned and an A10 connection established via A11 signaling.

A bearer connection is now available between the AT and PDSN for PPP negotiation.

AT BSC/PCF PDSN

A11 Registration Request

A11 Registration Reply (accept)

PPP

Traffic Channel

Establishment

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – PPP LCP

Via the Link Control Protocol (LCP), the following options can be negotiated:

• Maximum Received Unit (e.g., 1500 bytes).

• Address and Control Field Compression (on/off). When enabled, the Address field and Control field can be removed.

• Protocol Field Compression (on/off). When enabled, the MSB of the Protocol field can be removed.

• FCS Alternatives (16-bit CRC, 32-bit CRC, or NULL).

• Authentication Protocol (CHAP or PAP).

Flag ProtocolAddress Frame Check Sum

PPP Payload7E FF

Control03 0021

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – PPP LCP (continued)

• PPP LCP is a symmetric protocol; i.e., both peers (AT and PDSN) send Configure-Request messages.

• Via Configure-Request, PDSN proposes enabling CHAP as the authentication algorithm.

• Via Configure-Ack, the AT accepts the PDSN proposal to enable CHAP.

AT PDSN

Configure-Request (…)

Configure-Ack (Auth=CHAP, …)

Configure-Ack (…)

Configure-Request (Auth=CHAP, …)

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – PPP CHAP

AT PDSN

NAI, CHAP ID, Challenge Response

CHAP ID, Challenge

Access Request

Success

• The AT has a pre-established, shared secret with the RADIUS server.

• The AT uses MD5 to hash the CHAP ID (1 byte), shared secret, andChallenge. The hashing result is the Challenge Response.

• The Access Request contains Network Access Identifier (NAI), CHAP ID, Challenge, and Challenge Response.

• The RADIUS server uses the NAI as the index for obtaining the ATshared secret and uses it to verify the Challenge Response.

RADIUSServer

Access Accept

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – PPP IPCP

1. Via Configure-Request, the AT wants to be assigned an IP address (Address Option equal zero) and to enable Van-Jacobson Header Compression (VJHC).

2. Via Configure-Nak, PDSN assigns an IP address to the AT.3. Via Configure-Request, the AT wants to use the assigned address (Address Option

equal to the assigned address) and to enable VJHC.4. Via Configure-Ack, PDSN agrees to the AT request.

Note:

• PPP IPCP is a symmetric protocol. PDSN also initiates Configure-Request but is not shown in the figure.

• The DNS server address can be assigned during IPCP.

AT PDSN

1. Configure-Request (Addr=0, Comp=VJHC)

4. Configure-Ack (Addr=x, Comp=VJHC)

2. Configure-Nak (Addr=x)

3. Configure-Request (Addr=x, Comp=VJHC)

Notes




80-31392-2 Rev B



Simple IP –TCP/IP Header Compression

Van Jacobson Header Compression (VJHC) is described in RFC 1144.

• VJHC is performed at the PPP endpoints (AT and PDSN).

• VJHC compresses the 40-byte TCP/IP header to 3–5 bytes.

• VJHC is useful for small TCP packets.– Saves air resource.– Reduces transmission latency.

What makes TCP/IP header compression possible?

• Static header fields can be removed.– Example: IP addresses, port numbers, TTL, etc.

• Some header fields can be determined via link-layer assistance.– Example: IP packet length can be determined by PPP framing.

• Some header fields can be generated locally.– Example: IP header checksum (after header decompression).

• For dynamic header fields, only deltas are sent.– Example: IP ID, TCP sequence number, etc.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP – Termination

Graceful PPP Termination • AT may initiate PPP termination by sending LCP-Terminate.

• PDSN may initiate PPP termination.– PDSN has reached a certain capacity level and wants to terminate low priority

users (e.g., free subscription users).

– If PPP inactivity timer expires, PDSN sends LCP-Terminate; however, this message might not reach the AT.

Ungraceful PPP Termination• AT is unable to send LCP-Terminate due to various reasons (e.g., out of

battery, cable disconnection between the AT and the laptop).

• PPP state is retained in PDSN until the PPP Inactivity Timer expires.

It may be desirable for the AT not to terminate PPP gracefully to avoid setting up Traffic channels for LCP-Terminate. This saves air resource.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Mobile IP

• Mobile IP Basics

• Adaptation to 3GPP2

• Initiation

• Mobile IP Registration and Authentication

• Multiple Addresses

• Home Network Access

• PDSN-HA Security

• Reverse Tunneling

• Private Address Support

Notes




80-31392-2 Rev B



Mobile IP – Basics: Routing

AT FA HA

Server

1

Dest=Server Payload

1. AT sends a packet to a server.

2. Server replies a packet routed to the HA, because the AT IP address has the same network address as that of the HA.

3. HA tunnels the packet to the FA.

4. FA removes the tunnel overhead and forwards the inner packet to the AT.

2

3

Src=Server Dest=AT Payload

Src=HA Dest=FA Payload

4



Src=AT

Notes




80-31392-2 Rev B



Mobile IP – Basics: Registration

Mobile IP registration:• AT receives Agent Advertisement from the FA. The advertisement

contains the FA Care-of Address (COA).• AT sends Registration Request to the FA. The request contains AT

IP address, HA address, requested lifetime, authenticator, etc.• FA forwards the request to the HA.• HA authenticates the request and binds the AT address with the FA

COA.• HA sends Registration Reply to the FA. The reply contains the AT

IP address, lifetime, authenticator, etc.• FA adds the AT to the visitor list and forwards the reply to the AT.

AT re-registers when:• Registration lifetime nears expiration, or• AT changes the FA.

Notes




80-31392-2 Rev B



Mobile IP –Adaptation to 3GPP2

• Mobile IP is described in RFC 2002.

• PDSN supports the FA functions.

• Mobile IP runs over the PPP.– The PPP negotiation is different from that of Simple IP.

• Unlike RFC 2002, Agent Advertisements are not multicast periodically from PDSN.– Advertisements are sent in a batch immediately after the PPP link is established, only

destined for the AT.

– Multicasting Advertisements periodically would burden air resource.

• Network Access Identifier (NAI), instead of AT IP address as in RFC 2002, is used to identify the AT in the Mobile IP registration.

– NAI has the format of user@realm.

– Allows HA to assign IP addresses dynamically to the AT on per session basis.

– Based on RFC 2794.

• Home RADIUS server authenticates/authorizes the Mobile IP access request. This is based on RFC 3012.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Mobile IP – Initiation

AT requests the establishment of the channel for purposes of data packet exchange.

• If authorized by the AN AAA, the network resource (Traffic Channel, A8/A10 connections) is allocated.

• Same as Simple IP.

AT and PDSN establish a PPP link.• PPP Link Control Protocol (LCP):

– Authentication algorithm should not be negotiated and performed, because the AT is authenticated via Mobile IP registration.

• PPP IP Control Protocol (IPCP):– TCP/IP header compression capability is negotiated.

– AT does not negotiate for an IP address using IPCP, because the IP address can be assigned to the AT via Mobile IP registration.

• PDSN sends a batch of Agent Advertisements to the AT immediately after the PPP link is established.

AT performs Mobile IP registration.• If the registration is successful, the AT can now access the Internet.

Notes




80-31392-2 Rev B



Mobile IP –Initiation: PPP LCP

• AT proposes options x, y, and z, and the PDSN agrees.

• PDSN proposes options x, y, z, and CHAP, but the AT rejects CHAP.

• PDSN resends Configure-Request to propose options x, y, and z, leaving out CHAP, and the AT agrees.

AT PDSNConfigure-Request (x, y, z)

Configure-Reject (Auth=CHAP)

Configure-Ack (x, y, z)

Configure-Request (Auth=CHAP, x, y, z)

Configure-Request (x, y, z)

Configure-Ack (x, y, z)

Notes




80-31392-2 Rev B



Mobile IP –Initiation: PPP IPCP

• Via Configure-Request, the AT wants to enable VJHC.

• Via Configure-Ack, the PDSN agrees to the request.

Note:

• AT Configure-Request does not include the IP-Address option for address negotiation. This is how the PDSN knows whether the AT wants Mobile IP or Simple IP. PDSN sends a batch of Agent Advertisements only if the AT wants Mobile IP.

• PPP IPCP is a symmetric protocol. Although not shown in the figure, the PDSN also initiates Configure-Request.

• DNS server address can be assigned during IPCP.

AT PDSN

Configure-Request (Comp=VJHC)

Configure-Ack (Comp=VJHC)

Notes




80-31392-2 Rev B



Mobile IP –Registration and Authentication: Overview

Phase 1: AT is authenticated by the home RADIUS server. • AT and RADIUS server have a shared secret indexed by NAI.

• The purpose is to authenticate the AT for access control and accounting.

• This authentication is analogous to CHAP for Simple IP.

Phase 2: AT is authenticated by the HA.• AT and HA have a shared secret indexed by NAI.

– It may be statically configured.

– It may be derived from the AT-RADIUS shared secret.

• The purpose is to authenticate the AT for mobility binding and address allocation.

Notes




80-31392-2 Rev B



Mobile IP – Registration and Authentication: Message Flow

AT BSC/PCF PDSN(FA)

HomeRADIUS

5. Access Accept

3. Access Request

VisitedRADIUS

4. Access Request

6. Access Accept

HA

11. Registration Reply

2. Registration Request

1. Agent Advertisement

Phase 1

Phase 27. Registration Request

9. Registration Reply

10. FA processing

8. HA processing

Notes




80-31392-2 Rev B



Mobile IP –Registration and Authentication: Phase 1

Phase 1: AT is authenticated by the home RADIUS server.

1. AT receives Agent Advertisement. • Advertisement contains the FA COA and FA Challenge.

• If the FA COA has changed, the AT starts Mobile IP registration.

2. AT sends Registration Request. • Request contains NAI, FA Challenge, MN-AAA Authentication Extension

(i.e., Challenge Response), and MN-HA Authentication Extensions.

• AT is required to use a static HA in IS-835-A.

• AT may request a specific home address or dynamic home address.

3–4. PDSN forms an Access Request. • Access Request contains NAI, Challenge, and Challenge Response.

• Access Request is routed to the AT home RADIUS server based on NAI.

5–6. Home RADIUS server verifies the Challenge Responseand replies Access Accept if successful.

Notes




80-31392-2 Rev B



Mobile IP –Registration and Authentication: Phase 2

Phase 2: AT is authenticated by the HA.7. Upon receiving Access Accept, PDSN forwards the Registration Request

to the HA.

8. HA Processing:• Authenticates the AT.

• Assigns an address (if requested by the AT).

• Updates the mobility binding.

– Associates the AT home address with the FA COA.

– The binding has a lifetime.

9. HA sends Registration Reply to PDSN.• The Reply includes MN-HA Authentication Extension, AT home address, lifetime, etc.

10. FA Processing:• The PDSN adds the AT to the visitor list.

• Binds the AT home address and HA address to the AT A10 connection ID.

11. The PDSN forwards Registration Reply to AT that authenticatesthe HA by verifying the MN-HA Authentication Extension.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Mobile IP – Multiple Addresses

AT may obtain multiple IP addresses.

• One IP address per Mobile IP registration

• One IP address per NAI

• Multiple addresses assigned from the same HA or different HAs

Why does the AT need multiple addresses?

• Laptop connecting to the AT, each using separate addresses

• Multiple laptops connecting to the same AT, each using separate addresses

Simple IP cannot support assignment of multiple addresses over the same PPP session.

Notes




80-31392-2 Rev B



Mobile IP –Home Network Access

AT roams to a visited network and wants to access services in its home network.

• The home network assigns an IP address (globally routable or private) to the AT.

• IP packets between the visited and home networks are protected.

Mobile IP may be used to provide home network access for a roaming AT.

• AT establishes a PPP link with a PDSN in the visited network.

• AT registers with the HA in the home network and obtains an IP address.

• AT-originated packets are tunneled from the PDSN to the HA.

• IP packets between the PDSN and HA are protected in both directions.

Notes




80-31392-2 Rev B



Mobile IP –PDSN-HA Security

FA-HA Authentication Extension can be used to protect Mobile IP registration messages between the PDSN and HA.

• Based on RFC 2002.

• Provides integrity protection.

• Requires the PDSN and HA to have a pre-shared secret.

• From PDSN to HA:

– PDSN uses the shared secret to compute the extension and adds it to the Registration Request before forwarding it to the HA.

– HA uses the shared secret to verify the extension, and hence the PDSN.

• From HA to PDSN:– HA uses the shared secret to compute the extension and adds it to the

Registration Reply before sending it to the PDSN.

– PDSN uses the shared secret to verify the extension, and hence the HA.

Notes




80-31392-2 Rev B



Mobile IP –PDSN-HA Security (continued)

IPSec can be used to protect IP packets between the PDSN and HA.

• Based on IPSec standards (IETF).

• Provides encryption and integrity protection.

• Security parameters (e.g., encryption keys, algorithm) are negotiated between the PDSN and the HA via IKE.

– Security parameters are per (PDSN, HA) pair, not per AT.

• Security levels:– No protection.

– Protect Mobile IP registration packets, but not tunnel packets.

– Protect tunnel packets, but not Mobile IP registration packets.

– Protect all packets.

Notes




80-31392-2 Rev B



Mobile IP –Reverse Tunneling

What is reverse tunneling?• RFC 2344.

• FA tunnels all AT-originated packets (except registration packets) to the AT HA.

Why use reverse tunneling?• Ingress filtering

– When the AT is in a visited network and sends packets, the network prefix of the source address is not topologically correct.

– If routers in the visited network perform ingress filtering, these packets would be discarded.

– Via reverse tunneling, the source address of the tunnel packet is FA’s COA and is topologically correct in the visited network.

• Private address– If AT uses private address, without reverse tunneling, AT’s originated packets are

not routable via the Internet.

• PDSN-HA security– The same security parameters used to protect the Forward tunnel may be used to

protect the reverse tunnel.

Notes




80-31392-2 Rev B



Mobile IP –Reverse Tunneling (continued)

How to set up reverse tunneling?

• FA uses the T-bit in the Agent Advertisement to indicate its reverse tunneling capability.

• AT uses the T-bit in the Registration Request to ask the FA to use reverse tunneling.

• If the network requires reverse tunneling, but the AT didn’t set the T-bit, the FA or HA rejects the request with appropriate reply codes. The AT resends the request with the T-bit set.

Notes




80-31392-2 Rev B



Mobile IP –Private Address Support

HA may assign a private IP address to the AT via Mobile IP registration.• Reverse tunneling is required.

• AT accesses servers in the home network.

• AT accesses the Internet via the home network NAT.

Two ATs served by the same PDSN may be assigned with the same private IP address.

• Possible if two HAs coincidentally assign the same address.

• Not possible if two ATs are served by the same HA.

• How does the PDSN resolve the ambiguity?– Via A10 connection establishment and Mobile IP registration, the PDSN knows the mapping

between the 3-tuple (AT address, HA address, A10 connection ID).

– In the Reverse direction, the PDSN receives a packet from an A10 connection, so the PDSN knows the AT address (source address of the packet) and the A10 connection ID. From the 3-tuple, the PDSN obtains the HA address and tunnels the packet to that HA.

– In the Forward direction, the PDSN knows the HA address (source address of the tunnel packet) and AT address (destination address of the inner packet). From the 3-tuple, the PDSN obtains the A10 connection ID and forwards the inner packet to that A10 connection.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple IP versus Mobile IP

Mobile IP

+ Maintains IP connectivity across the PDSN boundary.• Suitable for mobile users in networks with a small PDSN footprint.

• Suitable for AT-terminated services (e.g., push contents).

+ Supports home network access with reverse tunneling.

+ Supports multiple IP addresses assignment.

– Needs additional client software.

– More complexity on the network side than Simple IP.

– Access delay due to registration and authentication.

– Inefficient transport due to triangular routing.

Notes




80-31392-2 Rev B



Simple IP versus Mobile IP(continued)

Simple IP

+ Uses existing client software (e.g., Windows PPP stack).

+ Less complexity on the network side than Mobile IP.

+ Less access delay than Mobile IP.

+ More efficient transport than Mobile IP.

– No IP mobility across the PDSN boundary.

– Needs additional tunneling (e.g., L2TP) for home network access.

– Does not support multiple IP addresses assignment.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0QoS – Differentiated Services

PDSN supports Differentiated Services (diff-serv) as defined by IETF.

The diff-serv field in the IP header indicates the QoS level of a packet.

• Diff-serv field replaces the Type-of-Service field.

QoS levels:

• Best effort, no guarantee on delivery.– Today’s Internet

• Assured Forwarding (AF) classes for providing tiers of services that are better than Best Effort.

– Four AF classes (with decreasing quality): AF class 4, AF class 3, AF class 2, AF class 1.

– Each AF class has three drop precedence levels: low, medium, high.

– Suitable for providing Olympic-like services (e.g., gold, silver, and bronze).

• Expedited Forwarding (EF) for services requiring low latency and low jitter.– Suitable for real-time interactive applications (e.g., VoIP).

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0QoS – Differentiated Services (continued)

• Diff-serv can be used for scheduling priority:– EF packets before AF class 4 packets

– AF class j packets before AF class k packets, for j > k

– AFclass 1 packets before best effort packets

• Diff-serv can be used for discarding priority during congestion (buffer full):– Best effort packets before AF classes packets.– Among AF classes packets, high-drop-rate packets before medium-drop-rate packets before

low-drop-rate packets.

Use weigh factors in scheduling/discarding algorithms to prevent starving and overly penalizing low QoS packets.

• AT may mark the diff-serv field of the IP packet.

• PDSN may re-mark the diff-serv field. – For example, the AT subscribes as a silver user (AF class 3). If the AT sends packets as

AF class 4 (gold user), the PDSN marks the packets down to AF class 3.

• End-to-end diff-serv:– End-to-end diff-serv via the Internet is not available today because diff-serv is not yet deployed

widely in the Internet.

– End-to-end diff-serv within the carrier network is possible with routers that support diff-serv.

Notes




80-31392-2 Rev B


CDMA2000 1xEV-DO Release 0Simple and Mobile IP References

[1] TIA/EIA/IS-835-A, Wireless IP Network Standard Revision A, May 2000.

[2] Perkins, “IPv4 Mobility,” RFC 2002, May 1995.

[3] Simpson, “The Point to Point Protocol (PPP),” RFC 1661, July 1994.

[4] Simpson, “PPP in HDLC-like Framing,” RFC 1662, July 1994.

[5] Simpson, “PPP Challenge Handshake Authentication Protocol (CHAP),” RFC 1994, August 1996.

[6] McGregor, “The PPP Internet Protocol Control Protocol (IPCP),” RFC 1332, May 1992.

[7] Rigney, Rubens, Simpson, and Willens, “Remote Authentication Dial In User Service (RADIUS),” RFC 2138, August 1997.

[8] Jacobson, “Compressing TCP/IP Headers for Low Speed Serial Links,” RFC 1144, February 1990.

[9] Nichols, Blake, Baker, and Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” RFC 2474, December 1998.

[10] Blake, Black, Carlson, Davies, Wang, and Weiss, “An Architecture for Differentiated Services,” RFC 2475, December 1998.

Notes




80-31392-2 Rev B



The 3GPP2 Wireless IP Network standard.

How Simple IP works.

How Mobile IP works.

How Simple IP compares to Mobile IP.

How QoS is supported.

Notes




80-31392-2 Rev B



SECTION REVIEW

105AC_00

Simple and Mobile IP –Review

• Standards Status

• 1xEV-DO Network Diagram and Protocol Stacks

• Simple IP

• Mobile IP

• QoS

Notes




80-31392-2 Rev B

Comments/Notes


Section 13: CDMA2000 1X and 1xEV-DO Hybrid Operation

80-31392-2 Rev B





CDMA2000 1X

and 1xEV-DO

Hybrid Operation13

SECTION

Notes



80-31392-2 Rev B





106AC_00.emf



106AC_00.emf

• 1X and 1xEV-DO− Access Network

− Access Terminal

− State Operation

• Hybrid AT Responds to Voice Page

• Data Session Handoff− Idle State 1X to

1xEV-DO

− Idle State 1xEV-DO to 1X

− Traffic State 1xEV-DO to 1X

Notes



80-31392-2 Rev B




• Describe the AN and AT for 1X and 1xEV-DO hybrid operation.

• Describe hybrid operation of the AT in different states.

• Describe handoffs between 1X and 1xEV-DO networks.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 01X and 1xEV-DO Access Network

1X and 1xEV-DO Access Network

The diagram shows one possible setup of ANs for 1X and 1xEV-DO networks. In this configuration, the 1X and 1xEV-DO networks have separate PDSNs; however, it is possible for both networks to use the same PDSN.

For current hybrid operation, no interaction between 1X and 1xEV-DO networks is needed; although, it is important that both networks derive timing from the same timing source. Future enhancements to hybrid operation will require both networks to support additional features.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 01X and 1xEV-DO Access Terminal

Hybrid AT Purpose

Increase 1X service offerings by adding

1xEV-DO high speed packet data services.

• Support service options on the 1X air interface.

• Add support for packet data services on the 1xEV-DO air interface.

1X and 1xEV-DO Access Terminal (AT)

Hybrid AT is another name for the Access Terminal (AT) that can receive 1X pages while monitoring the 1xEV-DO frequency.



80-31392-2 Rev B




1X and 1xEV-DO AT − Acquisition and Synchronization State Operation

In the Preferred Roaming List (PRL), designate the 1X and 1xEV-DO systems to be used for hybrid operation as colocated systems .

• The hybrid AT:

− Acquires the 1X system.

− Synchronizes its timing.− Enters slotted mode operation.

• After acquiring the 1X system, the hybrid AT:

• Acquires the colocated 1xEV-DO system.

• Synchronizes its timing.

• Enters slotted mode operation.

Acquisition and Synchronization State Operation

The Preferred Roaming List (PRL) used for hybrid operation must be of version IS-683C or above. This version of the PRL includes system records that identify the 1xEV-DO system and additional flags that allow 1X and 1xEV-DO systems to be designated as colocated systems.



80-31392-2 Rev B




1X and 1xEV-DO AT −Idle State Operation

Idle State Operation

The diagram shows how the 1X and 1xEV-DO slots are placed in time for hybrid operation. Slot locations for different Slot Cycle Indices (SCIs) are shown.

The 1X slot cycle is a function of its IMSI. The 1xEV-DO slot is chosen so it does not conflict with the 1X slot location.



80-31392-2 Rev B




1X and 1xEV-DO AT −Idle State Operation (continued)

While in the Idle state, the hybrid AT must monitor the 1X and 1xEV-DO networks to receive overhead messages and pages.

The hybrid AT:

• Takes advantage of slotted mode operation to monitor both the 1X and 1xEV-DO networks.

• Transitions from sleep state to monitor state in the slot assigned to monitor the 1X signal, and then transitions back to sleep state.

• Transitions from sleep state to monitor state in the control channel cycle assigned to monitor the 1xEV-DO signal.

Notes



80-31392-2 Rev B




1X and 1xEV-DO AT −Idle State Operation (continued)

For a successful slotted mode operation in the Idle state, the wake up slot of the 1X must notoverlap with the preferred control channel cycle for the 1xEV-DO.

• The algorithm to choose the preferred control channel cycle that is implemented in the hybrid AT ensures that the wake up slots of the 1X and the preferred control channel cycle for the 1xEV-DO are different.

Idle State Operation (continued)

When a new session is created in a 1xEV-DO-only operation, the AT and the AN perform the session negotiation procedure. During this procedure, the AT and the AN decide which Preferred Control Channel Cycle (PCCC) the AT should use.

For hybrid operation, because the 1xEV-DO AN in not aware of the 1X slot cycle in use, it has to accept the PCCC proposed by the AT.



80-31392-2 Rev B




1X and 1xEV-DO AT −Traffic State Operation

• While performing Traffic state procedures on a 1xEV-DO system, the hybrid AT must perform Idle state procedures on the 1X system.

• The hybrid AT periodically tunes to the 1X frequency to receive the 1X paging channel and to perform Idle state procedures.

• Originations and page matches for 1X services result in the connection of the corresponding service on the 1X system.

• Monitoring the 1X paging channel periodically has negligible (1−2%) impact on sector throughput.

• The hybrid AT accumulates scheduling credit while not being served by 1xEV-DO and becomes more eligible to get served once it tunes back to 1xEV-DO, because the sector can serve other ATs while the hybrid AT is tuned away to the 1X system.

Traffic State Operation

Hybrid Operation in 1xEV-DO Traffic State

When the AT is in 1xEV-DO Traffic state, it periodically tunes away to the 1X frequency to monitor 1X overhead messages and pages. Before tuning away, the AT sets its DRC cover to null and then stops the Reverse link Power Amplifier (PA) after switching to 1X. As a result, the AN stops sending data on the Forward link.



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Hybrid AT Responds to Voice Page

Hybrid AT Responds to Voice Page

Voice Call in Traffic State

If the AT receives a voice page when it is tuned away to 1X, it sets up a voice call on the 1X network. While the voice call is in progress, any data call on the 1xEV-DO network is forced into dormancy. After the voice call ends, if data remains to be transferred, the Traffic Channel is set up on the 1xEV-DO network, and the data call is resumed.



80-31392-2 Rev B




Data Session Handoff −Idle State 1X to 1xEV-DO

Idle State 1X to 1xEV-DO

To avoid interruption of data services, a data session handoff from a 1X to a 1xEV-DO system should take place when the data session is in Dormant state and the hybrid AT is operating in Idle state.

When the hybrid AT tunes to the 1xEV-DO system and acquires it, the AT sends an unsolicited LocationNotification message, so that the PDSN makes the A10/A11 interface.



80-31392-2 Rev B




Data Session Handoff −Idle State 1xEV-DO to 1X

Idle State 1xEV-DO to 1X

Dormant data session handoff takes place when the data session is dormant and the hybrid AT leaves the coverage area of the 1xEV-DO system.

The hybrid AT sends an origination message with the DRS bit set to 0 on the 1X system. This indicates there is no data to send from the AT, and there is no need to set up traffic channel resources.

The PDSN switches the A10/A11 connection from the source AN to the target BSC.



80-31392-2 Rev B




Data Session Handoff −Traffic State 1xEV-DO to 1X

Traffic State 1xEV-DO to 1X

When the hybrid AT leaves 1xEV-DO coverage while in an active data session, it sends an origination message with the DRS bit set to 1 on the 1X network.

DRS = 1 indicates there is data to send and traffic channel resources must be set up.

The PDSN switches the A10/A11 connection from the source AN to the target BSC.

Data transfer is continued on the 1X network.



80-31392-2 Rev B




The AN and AT for 1X and 1xEV-DO hybrid operation.

Hybrid operation of the AT in different states.

Handoffs between 1X and 1xEV-DO networks.

Notes



80-31392-2 Rev B




SECTION REVIEW

105AC_00

CDMA2000 1X and 1xEV-DO Hybrid Operation – Review

SECTION REVIEW

105AC_00

• 1X and 1xEV-DO− Access Network

− Access Terminal

− State Operation

• Hybrid AT Responds to Voice Page

• Data Session Handoff− Idle State 1X to

1xEV-DO

− Idle State 1xEV-DO to 1X

− Traffic State 1xEV-DO to 1X

Notes


Section 14: Course Summary

80-31392-2 Rev B




Section 14:Course Summary

Course Summary –

CDMA2000 1xEV-DO14SECTION

Notes



80-31392-2 Rev B




MJJ97110708Ac-rev2.emf

Course Summary

Book 1

1) Introduction

2) Key Concepts of 1xEV-DO

3) Protocol Overview

4) Physical Layer

5) MAC Layer

6) Security Layer

7) Connection Layer

Notes



80-31392-2 Rev B




MJJ97110708Ac-rev2.emf

Course Summary (continued)

Book 28) Session Layer

9) Stream Layer

10) Application Layer

11) Quality of Service Support

12) Simple and Mobile IP

13) CDMA2000 1X and 1xEv-DO Hybrid Operation

14) Course Summary

Notes



80-31392-2 Rev B




What We Learned – Section 1 Introduction

The many names for 1xEV-DO technology.

The 1xEV-DO related standards.

The evolution of CDMA technology from CDMA2000 1X to 1xEV-DO.

The new terminology used in 1xEV-DO.

The references for this course.

Notes



80-31392-2 Rev B




What We Learned – Section 2 Key Concepts of 1xEV-DO

The 1xEV-DO system and many of its key characteristics.

The key characteristics of the Forward link.

The key characteristics of the Reverse link.

The key features that help optimize 1xEV-DO for data.

Notes



80-31392-2 Rev B




What We Learned – Section 3 Protocol Overview

The function of each layer in the 1xEV-DO protocol stack.

The protocol interfaces.

The differences between a session and a connection.

The signaling that occurs during power up of a 1xEV-DO Access Terminal.

Notes



80-31392-2 Rev B




What We Learned – Section 4 Physical Layer

1xEV-DO packet formats.

Reverse link channel structure.

Forward link channel structure.

How hybrid Automatic Retransmission Request (ARQ) operates.

Notes



80-31392-2 Rev B




What We Learned – Section 5 MAC Layer

The functions of the MAC Layer protocols.

How the MAC Layer packets are encapsulated on different channels.

How the Control Channel cycle differs from the paging cycle.

The structure of Access probes.

How Access probes are power controlled.

Notes



80-31392-2 Rev B




What We Learned – Section 5 MAC Layer (continued)

The important messages in the Access Channel MAC.

The rules that govern DRC.

The different methods to control Reverse link rates.

How an AT determines the maximum data rate and transmit data rate on the Reverse link.

How to implement class of service on the Reverse link.

The meaning of the silence interval.

Notes



80-31392-2 Rev B




What We Learned – Section 6 Security Layer

The Security Layer protocols in 1xEV-DO.

How key exchange works.

The three types of authentication and how they work.

How encryption works, including cryptosync generation.

Notes



80-31392-2 Rev B




What We Learned – Section 7 Connection Layer

The functions of the Connection Layer.

The protocols in the Connection Layer.

The interactions of the protocols.

Notes



80-31392-2 Rev B




What We Learned – Section 8 Session Layer

The functions of the Session Layer.

What sessions are.

The functions of the Session Management Protocol (SMP).

What the keep alive mechanism is.

The functions of the Address Management Protocol (AMP).

How UATIs are assigned.

What subnets and color codes are and how they are used.

The functions of the Session Configuration Protocol (SCP).

How session negotiation takes place.

Notes



80-31392-2 Rev B




What We Learned – Section 9 Stream Layer

The functions of the Stream Layer.

How the Stream Layer encapsulates packets.

The procedures for Stream Layer configuration.

Notes



80-31392-2 Rev B




What We Learned – Section 10 Application Layer

The functions of the Application Layer.

The functions of the Default Signaling Application protocols.

The functions of the Default Packet Application protocols.

Notes



80-31392-2 Rev B




What We Learned – Section 11 Quality of Service Support

QoS functions:




– Flow Control

– Scheduling

Where the QoS functions are performed in CDMA2000 packet networks.

Notes



80-31392-2 Rev B




What We Learned – Section 12 Simple and Mobile IP

The 3GPP2 Wireless IP Network standard.

How Simple IP works.

How Mobile IP works.

How Simple IP compares to Mobile IP.

How QoS is supported.

Notes



80-31392-2 Rev B




What We Learned – Section 13 1X and 1xEV-DO Hybrid Operation

The AN and AT for 1X and 1xEV-DO hybrid operation.

Hybrid operation of the AT in different states.

Handoffs between 1X and 1xEV-DO networks.

Notes



80-31392-2 Rev B


Comments/Notes


Appendix A: Coverage Analysis

80-31392-2 Rev B

© 2003 QUALCOMM Incorporated A-1

Appendix A-1cdma university


Appendix A:Coverage Analysis

Coverage AnalysisAAppendix

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Coverage Analysis

Typical IS-95 Forward link coverage analysis assumes:

• Maximum of 5.3% of total power per voice channel

• 2-way soft combining handoff

• 30% Pilot, Sync, and Paging Channel overhead

For 1xEV-DO, these translate to a user that gets:

• 15.3% of Traffic Channel slots

Or

• 14.3% of the total time slots

Notes



80-31392-2 Rev B




Geometry: {Ior, Ior, 0.25Ior}Channel 1: Ped. A, 3Km/hr, 1 pathChannel 2: Veh. A, 30Km/hr, 2paths

10

100

1000

-12 -10 -8 -6 -4 -2 0 2 4 6 8 10

Ior/No

Sec

tor

Th

rou

gh

pu

t (k

bp

s)channel 1, 1 user, single antenna

channel 2, 4 users, single antenna

channel 2, 4 users, dual antenna

Multiuser diversity improves coverage (~ 2.0 dB).

• 67.1 kbps sector throughput served 14.3% of time ≡ 9.6 kbps user throughput.

Dual receive diversity improves coverage (~ 4.6 dB).

Worst-case channel performance for each scenario

Coverage Analysis (continued)

• Use ITU-R M.1225 recommended channel models and parameters (IMT-2000).

• Forward link variable rate modem:

– Budget for average throughput rather than worst case link.

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 01xEV-DO Forward Link Coverage

• Lognormal std = 8 dB

• 90% probability of cell-edge coverage

• 10 dB penetration loss

• Control Channel coverage:

– Fixed rate transmission

– No multiuser gain

– Receive diversity is much more significant = 12 dB

Traffic single

antenna

Traffic dual

antenna

Control single

antenna

Control dual

antenna Equation

Average Throughput (or data rate) (bps)

9,600 9,600 38,400 38,400

Average Burst Rate (bps) 67,100 67,100 N/A N/A

Serving Time Fraction (%) 14.3 14.3 N/A N/A

Bandwidth (Hz) 1228.8k 1228.8k 1228.8k 1228.8k

Bandwidth (dB-Hz) 60.9 60.9 60.9 60.9 A

BTS Tx Power (Watts) 15 15 15 15

BTS Tx Power (dBm) 41.8 41.8 41.8 41.8 B

BTS Antenna Gain (dBi) 17 17 17 17 C

BTS Cable Loss (dB) 3 3 3 3 D

BTS EIRP (dBm) 55.8 55.8 55.8 55.8 E=B+C-D

MS Rx Antenna Gain (dBi) 0 0 0 0 F

Body Loss (dB) 3 3 3 3 G

Noise Figure (dB) 9 9 9 9 H

Thermal Noise (dBm/Hz) -165 -165 -165 -165 I = -174.0 + H

Target PER (%) 2 2 2 2

(Ior/No)req Per Antenna (dB) -7 -11.6 4 -8 J

Multi-user Diversity Gain (dB) 2 2 N/A N/A

Rx Diversity Gain (dB) N/A 4.6 N/A 12

MS Receiver Sensitivity (dBm) -111.1 -115.7 -100.1 -112.1 K=I+J+A

Log-normal Std. Deviation (dB) 8 8 8 8

Log-normal Fade Margin (dB) 10.3 10.3 10.3 10.3 L

Soft Handoff Gain (dB) 4.1 4.1 4.1 4.1 M

Building Penetration Loss (dB) 10 10 10 10 N

Maximum Pass Loss (dB) 147.7 152.3 136.7 148.7 O=E-K+F-G-L+M-N

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0IS-95A Forward Link Coverage Comparison

Traffic Paging Equation Data Rate (bps) 9,600 9,600

Data Rate (dB-Hz) 39.8 39.8 A

BTS Tx Power (Watts) 15 15

BTS Tx Power (dBm) 41.8 41.8

Max. % Power for Each Channel 5.3 20

Max. Power Allocated per CH (Watts) 0.8 3

Max. Power Allocated per CH (dBm) 29 34.8 B

BTS Antenna Gain (dBi) 17 17 C

BTS Cable Loss (dB) 3 3 D

BTS EIRP per TCH (dBm) 43 48.8 E=B+C-D

MS Rx Antenna Gain (dBi) 0 0 F

Body Loss (dB) 3 3 G

Noise Figure (dB) 9 9 H

Thermal Noise (dBm/Hz) -165 -165 I=-174.0+G

Target PER (%) 3 10

(`Eb/No)req for Single Antenna (dB) 12.3 20.6 J

MS Receiver Sensitivity (dBm) -112.9 -104.6 K=I+J+A

Log-normal Std. Deviation (dB) 8 8

Log-normal Fade Margin (dB) 10.3 10.3 L

Soft Handoff Gain (dB) 5.6 4.1 M

Building Penetration Loss (dB) 10 10 N

Maximum Pass Loss (dB) 138.2 134.2 O=E-K+F-G-L+M-N

IS-95 Paging Channel• 20% power allocation

• 10% frame error rate

• 134.2 dB maximum path loss

1xEV-DO Control Channel• 136.7 dB maximum path loss for

single antenna

• 148.7 dB maximum path loss for dual antenna

IS-95 Traffic Channel• 5.3% power allocation

• 3% frame error rate


1xEV-DO Traffic Channel• 147.7 dB maximum path loss for

single antenna

• 152.3 dB maximum path loss for dual antenna

Notes



80-31392-2 Rev B




++++

+= 101010

0

,

0

1010101log10R

Wlog10

ACKGainDRCGainDataGainpcb

N

E

N

E

Required Eb/No per antenna with no system load:

1xEV-DO Reverse Link Coverage

Assumptions for Reverse link budget:• No closed loop power control

• Dual receive antennas at the Base Station

• 2-way handoff (selection)

• 50% system load

• 2% packet error rate

• Relative DRC channel gain = -3.0 dB

• Relative ACK channel gain = +4.0 dB

Data Rate (bps) 9,600 19,200 38,400 76,800 153,600

DataGain (dB) 3.75 6.75 9.75 13.25 18.5

Required Total Eb/No per Antenna (dB) 6.62 4.98 3.84 3.55 5.27

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0IS-95A Reverse Link Coverage Comparison

IS-95 Reverse link

• 3% target FER

• Required Eb/No = 8 dB


1xEV-DO Reverse link

• 1.5 dB coverage gain for 9.6 kbps

• Supports 19.2 kbps with same link budget as IS-95

1xEV-DO 1xEV-DO IS-95 Equation

Data Rate (bps) 9,600 19,200 9,600

Data Rate (dB-Hz) 39.8 42.8 39.8 A

MS Tx Power (mWatts) 200 200 200

MS Tx Power (dBm) 23 23 23 B

MS Antenna Gain (dBi) 0 0 0 C

Body Loss (dB) 3 3 3 D

MS EIRP for Data Channel (dBm) 20 20 20 E=B+C-D

BTS Rx Antenna Gain (dBi) 17 17 17 F

BTS Cable Loss (dB) 3 3 3 G

BTS Noise Figure (dB) 5 5 5 H

BTS Thermal Noise (dBm/Hz) -169 -169 -169 I=-174.0+H

Target PER (%) 2 2 3

Total (`Eb/No)req per Antenna @ no system load (dB) 6.6 5 8 J

System Load Margin (dB) 3 3 3 K

BTS Receiver Sensitivity (dBm) -119.6 -118.2 -118.2 L=I+J+K+A

Log-normal Std. Deviation 8 8 8

Log-normal Fade Margin (dB) 10.3 10.3 10.3 M

Soft Handoff Gain (dB) 4.1 4.1 4.1 N

Differential Fade Margin (dB) 2.1 2.1 2.1 O

Building Penetration Loss (dB) 10 10 10 P

Maximum Path Loss (dB) 135.3 133.9 133.9 Q=E-L+F-G-M+N-O-P

Notes



80-31392-2 Rev B


Comments/Notes


Appendix B: Field Trial Results

80-31392-2 Rev B

© 2003 QUALCOMM Incorporated B-1

Appendix B-1cdma university


Appendix B:Field Trial Results

Field Trial ResultsBAppendix

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0Field Trial Overview

• Measure 1xEV capacity in a realistic environment.– Fully loaded embedded sector

– Physical Layer and Application Layer throughputs

• Measure ARQ gains.– Validate expected gains in the real world.

• Measure the impact of network loading.

• Measure the impact of dual-antenna receive diversity.

• Use different Access Terminal configurations.– Stationary and fixed locations

– Pedestrian: Same locations as stationary but walking speed

– Mobility: speed range (0–70 km/h)

Notes



80-31392-2 Rev B



CDMA2000 1xEV-DO Release 0San Diego Location

• PCS frequency OTA System

• 3 cells, 7 sectors

• L-γ is the embedded sector

Notes



80-31392-2 Rev B




• Access Terminals connected to: – Laptops running Windows 2000 (TCP window size 32 K)

– Desktop running Linux 2.4 (stationary locations)

• Physical Layer Tests– Test mode → sectors always loaded

– Test packet: sequence numbers, sector ID, etc.

– Offline validation of Physical Layer capacity

• Application Layer Tests– FTP transfer using Chariot tool

– Four parallel TCP connections

– Softer/Soft handoff prorating

Test Configurations

Notes



80-31392-2 Rev B




• 4 groups of 8 terminals

• 2 indoors in each group

• 2 user tests conducted over 16 subgroups

Stationary Locations

Notes



80-31392-2 Rev B




• 7-minute drive route

• 2, 4, and 8 vans evenly separated

• Requested data rates (DRC) for dual-antenna receiver

Mobile Drive Route

Notes



80-31392-2 Rev B




Physical Layer Throughput

SINR Distribution

Embedded Sector Physical Layer

Throughput (kbps)

Single Antenna

Dual Antenna

Stationary – 2 users 972 1211

Stationary – 8 users 1011 1252

Pedestrian – 2 users 772 1121

Pedestrian – 8 users 1034 1304

Mobility – 2 users 532 905

Mobility – 8 users 741 1060

Notes



80-31392-2 Rev B




Application Layer

Hybrid ARQ On/Off Adjacent Sector On/Off

Field Trial Throughput Numbers

Embedded Sector Application Layer Throughput (kbps)

Single Antenna

Dual Antenna

Stationary (8 users) 960 1150

Pedestrian (8 users) 880 1160

Mobility (8 users) 600 930


Throughput (kbps)

Single Antenna

Dual Antenna

ARQ ON (8 users) 741 1060

ARQ OFF (8 users) 431 809


Throughput (kbps)

Single Antenna

Dual Antenna

Idle Gain = 0 dB (8 users)

741 1060

Idle gain = -12 dB (8 users)

810 1170

Notes

Documents

EVDO 1x Rel 0 Stu Notes Book 2