CD MA MO BILE PACKET DATA S ER VIC ES

Mobile P ac ket 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 lo w C DMA2000 – 1x ( da ta )

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 P acket s witc h cor e netw or k dom ain

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 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.