CD MA MO BILE PACKET DATA S ERVIC ES

Mobile Packet da ta Ser vice St ate s

There are three packet data service states: Active/Connected, Dormant, and

Null/Inactive

Active/Connected State: In this state, a physical traffic channel exists between

the MS and the BS, and either side may send data.

Dormant State: In this state, no physical traffic channel exists between the MS

and the BS, but the PPP link between the MS and the PDSN is maintained.

Null/Inactive State: In this state, there is no traffic channel between the MS and

the BS and no PPP link between the MS and the PDSN.

Figure 4.1: Block diagram of the packet data service transitions

The mobile may cross Packet Zone boundaries while in the Dormant State. This is

referred to as Dormant Handoff. The Dormant handoff procedures allow the A10

connections between the PCF and PDSN to be moved (or established) for the mobile

when it enters a new packet zone. The mobile may re-enter Active state (e.g., if the

user has data to send) at any time. This transition is referred to as Re-Activation

from Dormant, and is not related to Dormant Handoff (i.e., Re-Activation from

Dormant is not related to a mobility event). Packet data is typically transmitted over

the air on dedicated traffic channels. Mechanisms also exist for transmitting data

over the common channels. Short Data Burst (SDB) is a part of the 3G Packet Data

feature that enables small amounts of data to be transmitted over the common

channels. Common Channel Packet Data is a mode of 3G Packet Data where all data

is transmitted using Short Data Bursts. A1 and A8 connections are maintained

during the Active / Connected State and released during transition to Dormant or

Null/Inactive State. The A10 connection is maintained during the Active/Connected

and the Dormant State.

Figure 4.2: Schematic diagram of the packet data service states

As shown in figure 4.2 above, a mobile in the Null state will need to setup traffic

channel on the Um, Abis, A8 and A10 interface to get to the Active state. Similarly, a

mobile in the Active state will need to release traffic channels on the Um, Abis and

A8 interface to get to the Dormant state. Furthermore a mobile in the Dormantstate

will need to release the traffic channel on the remaining A10 interface to get to the

Null state again

Call f low C DMA2000 – 1x ( data )

The main difference between the CDMAOne and CDMA2000 call flow is that, in

CDMA2000 the mobile initiates the decision as to whether the session will be a

packet data session, voice session, or concurrent (meaning voice and data). After

the decision has been made, the mobile sends an origination message on the

access channel that includes an indication that this is a voice or packet data

session.

In this section we will be dealing with Packet data call flow

Figure 4.3: CDMA2000 voice/data call flow

Co nsid erin g the Packet switc h cor e netw or k dom ain

Call scenarios CDMA2000 – 1x (data) – aExample: A mobile accessing a web server.

Figure 4.4: CDMA2000 data call flow diagram - (a)

• The mobile initiates the decision as to whether the session will be a packet data session, voice

session, or concurrent (meaning voice and data).

• After the decision has been made, the mobile sends an origination message

that includes an indication that this is a voice data session.

• The RAN informs the MSC, and the MSC performs an authentication procedure

similar to the circuit switched authentication process.

• Finally, the BSC and BTS allocate radio resources and establish a low data rate

dedicated channel. In contrast to the radio channel used for voice calls, this low

rate data channel uses the Radio Link Protocol (RLP) to provide better error

performance.

• The next step is to allocate resources in the new packet switched core network

domain.

Call scenarios CDMA2000 – 1x (data) - (b)

Figure 4.5: CDMA2000 data call flow diagram - (b)

• The next step in establishing the packet data session is to allocate resources on

the Radio – Packet (R-P) interface.

• Once resources have been established, the mobile communicates with the

PDSN over the allocated channels in order to set up a Point-to-Point Protocol

(PPP) connection.

• During this process, the packet switched core network, specifically the PDSN,

assigns an Internet Protocol (IP) address to the mobile station.

Call scenarios CDMA2000 – 1x (data) - (c)

Figure 4.6: CDMA2000 data call flow diagram - (c)

Before completing the PPP connection, there is another level of authentication.

Authentication has already been performed from a wireless access perspective, now

it will be performed based on the Internet service.

• The PDSN talks to the AAA server using the Remote Access Dial-In User

Service (RADIUS) protocol to authenticate the user. Authorization to access

the requested service is based on the subscriber profile stored in the AAA. If

authorization is successful, the mobile is granted access to the IP network.

AT Origina tes 1x EV-DO Session -Successful A uthentica tion

Figure 4.7: AT Originates 1xEV-DO Session -Successful Authentication diagram

Figure 4.8: Continuation of figure 4.7

A: The AT sends a UATI-Request message to request that a Unicast Access Terminal

Identifier (UATI) be assigned to it by the AN.

B: The AN sends a UATI-Assignment message to assign a UATI to the AT.

C: The AT sends a UATI-Complete message to notify the AN that it has received the

UATI-Assignment message.

D: If no session exists between the AT and AN, a session is established where

protocols and protocol configurations are negotiated, stored and used for

communications between the AT and the AN.

E: The AT indicates that it is ready to exchange data on the access stream (e.g., the

flow control protocol for the default packet application bound to the AN is in the

open state).

F: The AT and the AN initiate Point-to-Point Protocol (PPP) and Link Control Protocol

(LCP) negotiations for access authentication.

G: The AN generates a random challenge and sends it to the AT in a Challenge

Handshake Authentication Protocol (CHAP) Challenge packet.

H: When the AN receives the CHAP response packet from the AT, it sends a RADIUS

Access-Request message packet on the A12 interface to the AN Authentication,

Authorization and Accounting (AAA) entity (which acts as a RADIUS server).

I: The AN-AAA looks up a password based on the User-name attribute in the A12

Access-Request and if the authentication passes, the AN AAA sends an Access-

Accept packet on the A12 interface. The A12 Access-Accept contains a RADIUS

attribute with Type set to 20 (Callback-Id).

J: The AN returns an indication of CHAP authentication success, to the AT.

K: The AT indicates that it is ready to exchange data on the packet data stream.

(e.g., the flow control protocol for the default packet application bound to the packet

data network is in the open state).

L: The AN sends an A9-Setup-A8 message to the Packet Control Function (PCF) and

starts timer TA8-setup, to establish the A8-Connection. The A9-Setup-A8 message is

not sent before the AT indicates that it is ready to exchange data on the access

stream, as identified in step 5.

M: The PCF recognizes that no A10 connection associated with the AT is available

and selects a PDSN. The PCF sends an A11-Registration Request message to the

PDSN, which includes the Mobility Event Indicator (MEI) within the

Vendor/Organization Specific Extension. The PCF starts timer Tregreq.

N: The A11-Registration Request is validated and the PDSN accepts the connection

by returning an A11-Registration Reply with an accept indication and Lifetime set to

the configured Trp. Both the

PDSN and the PCF create a binding record for the A10 connection. The PCF stops

timer Tregreq.

O: When the AN receives the A9-Connect-A8 message it stops timer TA8-setup.

P: PPP connection establishment procedure and optional Mobile IP Registration on

the PPP connection are performed between the AT and the PDSN.

Q: At this point the connection is established and packet data can flow between the

AT and the PDSN.

AT Originates 1x-EV-DO Session – Unsuccessful Authentication

Figure 4.9: AT Originates 1x-EV-DO Session – Unsuccessful Authentication diagram

Figure 4.10: Continuation of figure 4.9

A: The AT sends a UATI-Request message to request that a UATI be assigned to it by

the AN.

B: The AN sends a UATI-Assignment message to assign a UATI to the AT.

C: The AT sends a UATI-Complete message to notify the AN that it has received the

UATI-Assignment message.

D: If no session exists between the AT and AN, a session is established where

protocols and protocol configurations are negotiated, stored and used for

communications between the AT and the AN.

E: The AT indicates that it is ready to exchange data on the access stream (e.g., the

flow control protocol for the default packet application bound to the AN is in the

open state).

F: The AT and the AN initiate PPP and LCP negotiations for access authentication.

G: The AN generates a random challenge and sends it to the AT in a CHAP

Challenge Handshake Authentication Protocol (CHAP) Challenge packet.

H: When the AN receives the CHAP response packet from the AT, it sends a RADIUS

Access-Request message packet on the A12 interface to the AN AAA (which acts as

a RADIUS server).

I: The AN-AAA looks up a password, based on the User-name attribute in the A12

Access-Request and if the authentication fails, the AN AAA sends an Access-Reject

packet on the A12 interface.

Note: For ANs that perform access authentication, the network requires that no use

of a dedicated resource, such as access to a PDSN, be allowed if authentication fails.

J: The AN returns an indication of CHAP authentication failure, to the AT.

K: The AN sends a SessionClose message to the AT, to close the session.

L: The AT responds with a SessionClose message.

AN-AN Dormant Handoff with Successful Session info’ Retrieval

.

Figure4.11: AN-AN Dormant Handoff with Successful Session diagram

Figure4.12 continuation of figure 4.11

A: The target AN receives a UATI-Request from the AT.

B: The target AN sends an A13-Session Information Request message to the

source AN to request the session information for the AT. The A13-Session

Information Request message includes the received UATI, the Security Layer

Packet and Sector ID. The target AN starts timer TA13req.

C: The source AN validates the A13-Session Information Request and sends

the requested session information of the AT to the target AN in an A13-

Session Information Response message.

D: The AN sends a UATI-Assignment to the AT. The AT confirms the receipt of

the UATI with UATI-Complete. The UATI-Assignment may contain a new UATI

or use the UATI received in the UATI-Request message. This step can occur

anytime after receipt of the UATI-Request message.

E: The Location Update procedures may be used to retrieve the PANID

information for sending to the PCF / PDSN.

F: The target AN sends an A13-Session Information Confirm to the source AN

to indicate that the target AN has received the session information. The

target AN stops timer TA13req. Upon receipt of the A13 Session Information

Confirm message, the source AN deletes the AT session information in

question.

G: The target AN sends an A9-Setup-A8 message, with Data Ready Indicator

set to 0, to the target PCF and starts timer TA8-setup.

H: The target PCF selects the PDSN to connect to using the PDSN address

provided in the A13-Session Information Response message or using the

PDSN selection algorithm, and sends an A11-Registration Request message

to the PDSN. The A11-Registration Request

message includes the Mobility Event Indicator (MEI) within the

Vendor/Organization Specific Extension. The target PCF starts timer Tregreq.

Inter-PCF Dormant Handoff - Mobile Continues to be served by the Serving

PDSN.

I: The A11-Registration Request is validated and the PDSN accepts the

connection by returning an A11-Registration Reply with an accept indication

and the Lifetime set to the configured Trp value. If the PDSN has data to

send, it includes the Data Available Indicator

Within the Vendor/Organization Specific Extension. The A10 connection

binding information at the PDSN is updated to point to the target PCF. The

target PCF stops timer Tregreq.

J: The PDSN initiates closure of the A10 connection with the source PCF by

sending an A11-Registration Update message. The PDSN starts timer

Tregupd.

K: The source PCF responds with an A11-Registration Acknowledge message.

The PDSN stops timer Tregupd.

L: The source PCF sends an A11-Registration Request message with

Lifetime set to zero, to the PDSN. The source AN/PCF starts timer Tregreq.

M: The PDSN sends an A11-Registration Reply message to the source PCF.

The source PCF closes the A10 connection for the AT and stops timer Tregreq.

N: The target PCF responds to the target AN with an A9-Release-A8-

complete message. The AN stops timer TA8-setup.

Data Delivery – AT Terminated

Figure 4.13: Data Delivery – AT Terminated diagram

A: The PCF determines that packet data is available for delivery to the AT.

B: The PCF sends an A9-BS Service Request message to the AN in order to

request packet service, and starts timer Tbsreq9.

C: The AN responds with an A9-BS Service Response. The PCF stops timer

Tbsreq9 upon receipt of the A9-BS Service Response message.

D: The AN sends a Page Message to the AT, on the control channel.

E: If the AT has data to send, the AT initiates connection establishment

procedures with the AN. The AN assigns a Forward Traffic Channel, Reverse

Power Control Channel and Reverse Traffic Channel.

F: After the traffic channel is established, the AN sends an A9-Setup-A8 to

the PCF and starts timer TA8-setup, to establish the A8-Connection.

G: When the AN receives the A9-Connect-A8 message it stops timer TA8-

setup.

H: At this point, the connection is established and packet data can flow

between the AT and the PDSN.