CDMA MOBILE PACKET DATA SERVICES

Mobile Packet data Service States

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 Dormant state will need to release the traffic channel on the remaining

A10 interface to get to the Null state again

Call flow CDMA2000 – 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

Considering the Packet switch core network domain

Call scenarios CDMA2000 – 1x (data) – a

Example: 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 Originates 1xEV-DO Session -Successful Authentication

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.