01-03 CDMA2000 1xEV-DO Service Procedure

01-03 CDMA2000 1xEV-DO Service Procedure

ContentsAirbridge BSC6680Technical Manual - Interfaces and Protocols

Airbridge BSC6680Technical Manual - Interfaces and Protocols Figures

Contents3-13 CDMA2000 1xEV-DO Service Procedure

3-23.1 UATI Assignment Procedure

3-33.2 Data Service Procedure

3-33.2.1 AT-Originated Data Service

3-63.2.2 Call Reactivation Initiated by the AT

3-73.2.3 Call Activation Initiated by the Network

3-83.2.4 Connection Release Initiated by the AT

3-93.2.5 Connection Release Initiated by the AN

3-103.2.6 Session Release Initiated by the AT (with A8 Connection)

3-103.2.7 Session Release Initiated by the AT (without A8 Connection)

3-113.2.8 Session Release Initiated by the AN (with A8 Connection)

3-123.2.9 Session Release Initiated by the AN (without A8 Connection)

3-133.2.10 Packet Data Session Release Initiated by the PDSN

3-143.3 Handoff Procedure

3-143.3.1 Intra-CDMA2000 1xEV-DO Network Handoff

3-193.3.2 Handoff Between CDMA2000 1X Network and 1xEV-DO Network

Figures3-2Figure 3-1 UATI assignment procedure

3-4Figure 3-2 Procedure of AT originated data service

3-6Figure 3-3 Call activation initiated by the AT

3-7Figure 3-4 Call activation initiated by the network

3-8Figure 3-5 Connection release initiated by the AT

3-9Figure 3-6 Connection release initiated by the AN

3-10Figure 3-7 Session release initiated by the AT (with A8 connection)

3-10Figure 3-8 Session release initiated by the AT (without A8 connection)

3-11Figure 3-9 Session release initiated by the AN (with A8 connection)

3-12Figure 3-10 Session release initiated by the AN (without A8 connection)

3-13Figure 3-11 Packet data session release initiated by the PDSN

3-14Figure 3-12 CDMA2000 1xEV-DO soft handoff and softer handoff of reverse link

3-15Figure 3-13 Forward virtual soft handoff/softer handoff

3-17Figure 3-14 Inter-AN dormant-state HRPD handoff

3-19Figure 3-15 Dormant handoff from the CDMA2000 1X network to the CDMA2000 1xEV-DO network (session already exists)

3-20Figure 3-16 Dormant handoff from 1xEV-DO to CDMA2000 1X

3-22Figure 3-17 Receiving the voice page in the CDMA2000 1xEV-DO network

3 CDMA2000 1xEV-DO Service ProcedureAbout This Chapter

The following table lists the contents of this chapter.

SectionDescribes

3.1

REF _Ref140984975 \h UATI Assignment ProcedureThe CDMA2000 1xEV-DO UATI assignment procedure.

3.2

REF _Ref140984976 \h Data Service ProcedureThe CDMA2000 1xEV-DO data service procedure.

3.3

REF _Ref140984980 \h Handoff ProcedureThe CDMA2000 1xEV-DO handoff procedures.

This chapter describes the following CDMA2000 1xEV-DO service procedures: XE "service procedure:1xEV-DO" \i

XE "1xEV-DO:service procedure" \i

UATI Assignment Procedure Data Service Procedure Handoff ProcedureThe NEs (such as ATs and ANs) in the CDMA2000 1xEV-DO network perform these procedures through message exchange.

3.1 UATI Assignment Procedure

The session is a shared state between the AT and the AN. In a session, the AT and AN negotiate the address, protocol, and configuration parameters for communication. In such a session, the AT and AN make preparation for the service transmission between them. The session negotiation includes UATI assignment, connection setup, key exchange, and negotiation of parameters and protocols.

The UATI assignment is an important and independent procedure. XE "procedure:UATI assignment" \i In the UATI assignment procedure, the AN assigns an UATI as the identifier of the AT. When the AT accesses the AN for the first time or its subnet changes, the AT sends to the AN the UATI Request message to initiate the UATI assignment process.

Figure 3-1 shows the UATI assignment when the AT accesses the AN.

Figure 3-1 UATI assignment procedure

Hardware ID = ESNThe procedure of UATI assignment is described as follows:

Step 2 The AT sends an UATI Request message over the access channel to the AN to request UATI, initiating the UATI assignment procedure.

Step 3 The AN sends a Hardware ID Request message to the AT to request hardware ID (ESN) of the AT.

Step 4 The AT responds with a Hardware ID Response message. The AN records the ESN in this message.

Step 5 The AN assigns a UATI and sends the UATI Assignment message to the AT.

Step 6 The AT responds to the AN with a UATI Complete message. The UATI assignment is completed.----End3.2 Data Service ProcedureIn the CDMA2000 1xEV-DO data service procedure, the AT may be in any of the following three states: XE "procedure:data service" \i

XE "data service:1xEV-DO" \i

XE "1xEV-DO:data service" \i Active state: A TCH is set up between the AT and the BTS. The A8 and A10 connections exist.

Dormant state: No TCH is set up between the AT and the BTS, but a PPP link is set up between them. The A8 connection is released, while the A10 connection exists.

Null state: Neither the TCH nor PPP link is set up between the AT and the BTS. The A8 and A10 connections are released. 3.2.1 AT-Originated Data ServiceThis section describes the procedure of AT originated data service after the authentication succeeds, as shown in Figure 3-2.Figure 3-2 Procedure of AT originated data service

The procedure of AT originated data service is described as follows:

Step 7 The AT sends a Connection Request message and a Route Update message to the AN, initiating the setup of the connection.

Step 8 The AN sends a Traffic Channel Assignment message to the AT.

Step 9 The AT sends messages over the reverse pilot channel and Data Rate Control channel.

Step 10 The AT sends a Traffic Channel Complete message to acknowledge the setup of Um interface connection.

Step 11 The AT is ready to negotiate and exchange data on the access stream.

Step 12 The AT and AN initiate PPP and LCP negotiations for access authentication.

Step 13 The AN generates a random challenge and sends it to the AT in a CHAP (Challenge Handshake Authentication Protocol) CHAP Response messageStep 14 The AN sends to the AN AAA an A12 Access-Request message on the A12 interface to request the access to the AN AAA.

Step 15 The AN AAA responds with an A12 Access-Accept message on the A12 interface to allow the access.

Step 16 The AN sends access success indication to the AT.

Step 17 The AN sends to the AT a Location Request message to request for location update.

Step 18 The AT sends a Location Notification message to the AN, initiating the location update.

Step 19 The AN sends to the AT a Location Assignment message to update access network identifiers (ANID).

Step 20 The AT responds with a Location Complete message, indicating the completion of the location update.

Step 21 The AT is ready to exchange data on service stream.

Step 22 The AN sends to the PCF an A9-Setup-A8 message to request to set up an A8 connection.

Step 23 The PCF sends to the PDSN an A11-Registration-Request message to request the setup of an A10 connection.

Step 24 The PDSN responds with an A11-Registration-Response message.

Step 25 The PCF responds with an A9-Connect-A8 message to the AN, indicating that the A8 and A10 connections are successfully established.

Step 26 The AT negotiates with the PDSN to establish the PPP connection. For mobile IP access mode, mobile IP connection must be established. Step 27 After a PPP connection is successfully set up, the data service enters into the connected state.----End3.2.2 Call Reactivation Initiated by the AT

An AT in the dormant state reactivates the data connection for any data transmission, that is, it reestablishes the air interface connection and the A8 connection, as shown in Figure 3-3.

Figure 3-3 Call activation initiated by the AT

The procedure of call activation initiated by the AT is described as follows:

Step 28 The AT is in the dormant state.

Step 29 The AT sends a Connection Request message and a Route Update message to the AN to request to set up an air interface connection.

Step 30 The AN sends an A9-Setup-A8 message to the PCF to request the setup an A8 connection.

Step 31 The PCF sends an A11-Registration-Request message to the PDSN to request recording billing information.

Step 32 The PDSN responds with an A11-Registration-Reply message.

Step 33 The PCF responds with an A9-Connect-A8 message to the AN, indicating that the A8 connection is successfully set up.


Step 35 The AT sends a Traffic Channel Complete message to acknowledge the setup of the air interface connection.

Step 36 The packet data service enters into the activated state.----End3.2.3 Call Activation Initiated by the Network

This section describes the procedure of a call activation initiated by the network, as shown in Figure 3-4. XE "network:call activation initiated" \i XE "network call activation initiated" \i

XE "call activation initiated:network" \i

Figure 3-4 Call activation initiated by the network

The procedure of a call activation initiated by the network is described as follows:Step 37 The AT is in the dormant state.

Step 38 The PDSN sends packet data to the PCF on the A10 connection.

Step 39 Finding that the packet data call is in the dormant state, the PCF sends an A9-BS Service Request message to the AN to request for the packet data service.

Step 40 The AN responds with an A9-BS Service Response message.

Step 41 The AN sends a Page message to the AT.

Step 42 The AT sends a Connection Request message and a Route Update message to the AN to set up an air interface connection.

Step 43 The AN sends the PCF an A9-Setup-A8 message to request to set up an A8 connection.

Step 44 The PCF sends the PDSN an A11-Registration-Request message to request recording the billing information.


Step 46 The PCF responds with an A9-Connect-A8 message, indicating that the A8 connection is successfully set up.

The AN sends an A9-Setup-A8 message to the PCF, requesting the air interface connection setup.


Step 48 The AT sends a Traffic Channel Complete message to acknowledge the setup of air interface connection.

Step 49 The packet data service enters into the activated state.----End3.2.4 Connection Release Initiated by the AT

This section describes the procedure of a connection release initiated by the AT, as shown in Figure 3-5. XE "connection release initiated:AT" \i

XE "AT:connection release initiated" \i Figure 3-5 Connection release initiated by the AT

The procedure of a connection release initiated by the AT is described as follows:Step 50 The AT sends a Connection Close message on the reverse channel, initiating the connection release.

Step 51 The AN sends an A9-Release-A8 message to request the PCF to release the A8 connection. The cause value is set to Packet call going dormant.

Step 52 The PCF sends an A11-Registration-Request message to send an Active Stop accounting record to the PDSN.


Step 54 The PCF acknowledges the A8 connection release with an A9-Release-A8 Complete message.----End3.2.5 Connection Release Initiated by the AN

This section describes a connection release initiated by the AN, as shown in Figure 3-6. XE "connection release initiated:AN" \i

XE "AN:connection release initiated" \i Figure 3-6 Connection release initiated by the AN

The procedure of a connection release initiated by the AN is described as follows:Step 55 The AN sends an A9-Release-A8 message to request the PCF to release A8 connection. The cause value is set to Packet call going dormant.

Step 56 The PCF sends the PDSN an Active Stop accounting record through the A11-Registration-Request message.


Step 58 The PCF acknowledges A8 connection release with an A9-Release-A8 Complete message.

Step 59 The AN sends a Connection Close message to the AT, initiating the connection release.

Step 60 The AT sends the Connection Close message to the AN, acknowledging the connection release.----End3.2.6 Session Release Initiated by the AT (with A8 Connection)

This section describes a session release initiated by the AT XE "session release initiated:AT" \i

XE "AT:session release initiated" \i when the A8 connection exists, as shown in Figure 3-7.

Figure 3-7 Session release initiated by the AT (with A8 connection)

The procedure of a session release initiated by the AT when the A8 connection exists is described as follows:Step 61 The AT sends a Session Close message on the reverse channel, initiating the session release.

Step 62 The AN sends an A9-Release-A8 message to request the PCF to release the A8 connection. The cause value is set to Normal call release.

Step 63 The PCF sends an A11-Registration-Request message, requesting the A10 connection release. The Lifetime is set to 0.

Step 64 The PDSN acknowledges the A10 connection release with an A11-Registration-Reply message.

Step 65 The PCF acknowledges A8 connection release with an A9-Release-A8 Complete message.----End3.2.7 Session Release Initiated by the AT (without A8 Connection) This section describes a session release initiated by the AT XE "session release initiated:AT" \i

XE "AT:session release initiated" \i when the A8 connection does not exist, as shown in Figure 3-8.

Figure 3-8 Session release initiated by the AT (without A8 connection)

The procedure of a session release initiated by the AT when the A8 connection does not exist is described as follows:Step 66 The AT sends a Session Close message on the reverse channel, initiating the session release.

Step 67 The AN sends an A9-Update-A8 message to the PCF to request the PCF to release the resources and the A10 connection. The cause value is set to Power down from dormant state.

Step 68 The PCF sends an A11-Registration-Request message to release the A10 connection. The Lifetime value is set to 0.


Step 70 The PCF acknowledges A10 connection release with an A9-Update-A8 Ack message.----End3.2.8 Session Release Initiated by the AN (with A8 Connection) This section describes a session release initiated by the AN XE "session release initiated:AN" \i

XE "AN:session release initiated" \i when the A8 connection exists, as shown in Figure 3-9.

Figure 3-9 Session release initiated by the AN (with A8 connection)

The procedure of a session release initiated by the AN when the A8 connection exists is described as follows:Step 71 The AN sends a Session Close message to the AT, initiating the session release.

Step 72 The AT sends a Session Close message to the AN, acknowledging the session release.

Step 73 The AN sends an A9-Release-A8 message to request the PCF to release the A8 connection. The cause value is set to Normal call release.

Step 74 The PCF sends an A11-Registration-Request (Lifetime = 0) message to release the A10 connection.


Step 76 The PCF acknowledges the A8 connection release with an A9-Release-A8 Complete message.----End3.2.9 Session Release Initiated by the AN (without A8 Connection) This section describes a session release initiated by the AN XE "session release initiated:AN" \i

XE "AN:session release initiated" \i when the A8 connection does not exist, as shown in Figure 3-10.

Figure 3-10 Session release initiated by the AN (without A8 connection)

The procedure of a session release initiated by the AN when the A8 connection does not exist is described as follows:Step 77 The AN sends a Session Close message to the AT, initiating the session release.

Step 78 The AT sends a Session Close message to the AN, acknowledging the session release.

Step 79 The AN sends an A9-Update-A8 message to the PCF to request the PCF to release the resource and the A10 connection. The cause value is set to Power down from dormant state.

Step 80 The PCF sends an A11-Registration-Request (Lifetime = 0) message to release the A10 connection.


Step 82 The PCF sends an A9-Update-A8 Ack message.----End3.2.10 Packet Data Session Release Initiated by the PDSN

This section describes a packet data session release initiated by the PDSN, as shown in Figure 3-11.

Figure 3-11 Packet data session release initiated by the PDSN

The procedure of a packet data session release initiated by the PDSN is described as follows:Step 83 The AT and PDSN release the PPP session.

Step 84 The PDSN sends an A11-Registration-Update message to request for the release of A10 connection.

Step 85 The PCF acknowledges the A10 connection release request with an A11-Registration Ack message.

Step 86 The PCF sends an A11-Registration-Request message to release the A10 connection.

Step 87 The PDSN acknowledges the A10 connection release with an A11-Registration Reply message.

Step 88 The PCF sends an A9-Disconnect-A8 message to the AN to request the release of the A8 connection. If the A8 connection is not set up, skip steps 59.

Step 89 The AN sends an A9-Release-A8 message to the PCF to release the A8 connection.

Step 90 The PCF acknowledges the A8 connection release with an A9-Release-A8 Complete message.

Step 91 The AN sends a Connection Close message to the AT to release the connection.

Step 92 The AT sends a Connection Close message to the AN, acknowledging the connection release.----End3.3 Handoff Procedure In the CDMA2000 1xEV-DO system, the handoff includes: Intra-CDMA2000 1xEV-DO Network Handoff Handoff Between CDMA2000 1X Network and 1xEV-DO Network XE "procedure:handoff" \i 3.3.1 Intra-CDMA2000 1xEV-DO Network Handoff In the CDMA2000 1xEV-DO system, handoff can be divided into the following according to its function: Soft Handoff/Softer Handoff of Reverse Link Forward Virtual Soft Handoff/Softer Handoff Inter-AN Dormant-State HRPD HandoffSoft Handoff/Softer Handoff of Reverse LinkIn the CDMA2000 1xEV-DO system, the softer handoff procedure of reverse link is the same as its soft handoff procedure.

Figure 3-12 shows the CDMA2000 1xEV-DO soft handoff and softer handoff.

Figure 3-12 CDMA2000 1xEV-DO soft handoff and softer handoff of reverse link

The procedure of the CDMA2000 1xEV-DO soft handoff/softer handoff of reverse link is described as follows:Step 2 The AT sends a Route Update message. The BSC decides whether to initiate a reverse link soft handoff or softer handoff.

Step 3 The AN sends a Traffic Channel Assignment message to instruct the AT to use the new active set.

Step 4 The AT sends a Traffic Channel Complete message, acknowledging the setup of air interface connection. The soft handoff/softer handoff complete.----EndForward Virtual Soft Handoff/Softer Handoff

The feature of the virtual soft/softer handoff is that only one sector or active set branch transmits forward data for the AT. During the soft handoff, the AT selects the best forward active set branch and informs the AN to send forward data from the selected sector over the Data Rate Control (DRC) channel and the Data Source Control (DSC) channel.

The BTS decodes the DRC channel and the DSC channel. During the soft handoff, when the serving branch changes, the BTS notifies the original branch to stop sending data on the Abis interface and the new branch to request data transmission. Suppose the AT active set only includes BTS 1 and BTS 2.Figure 3-13 shows a forward virtual soft/softer handoff.

Figure 3-13 Forward virtual soft handoff/softer handoff

The procedure of a forward virtual soft/softer handoff is described as follows:Step 2 The AT sends a rate control message and a data source control message to BTS 1 on the reverse DRC channel and the reverse DSC channel.

Step 3 The BSC sends an Abis-Do Forward Traffic message including forward traffic data to BTS 1. The BTS 1 provides forward service for the AT.

Step 4 The AT sends a data source control message to BTS 2 on the reverse DSC channel to request forward traffic data.

Step 5 BTS 1 sends an Abis-Do DscSwitchInd message to the BSC, informing the BSC that the AT requests for a soft handoff.

Step 6 The BSC sends an Abis-DO FlushQueues message to BTS 2, informing BTS 2 to clear the forward traffic data it sent to the AT.

Step 7 On receipt of the DSC channel message, BTS 2 sends an Abis-DO ForwardRequest message to the BSC to request the forward data to be sent to the AT.

Step 8 The BSC sends an Abis-Do ForwardTraffic message and forward traffic data to BTS 2.

Step 9 BTS 1 receives the rate control message from the DRC channel.

Step 10 BTS 2 sends to the AT the forward traffic data it has received from the BSC.

Step 11 BTS 1 sends an Abis-DO Forward Stopped message to the BSC, requesting the BSC to stop receiving the forward traffic data to be sent to the AT.

Step 12 After the BSC hands off the forward data to the AT from BTS 1 to BTS 2, the BSC sends the Abis-DO Flush Queues message, informing BTS 1 to clear the forward data that has not been sent to the AT.

Step 13 The BSC sends the Abis-Do Forward Traffic message including forward data to BTS 2, which provides forward service for the AT.----EndInter-AN Dormant-State HRPD HandoffThe BSC supports inter-AN dormant-state HRPD handoff, as shown in Figure 3-14. XE "handoff:intra-1xEV-DO network:dormant handoff" \i

XE "handoff:dormant handoff:between ANs" \i

XE "dormant handoff:between ANs" \i The target AN obtains the session information from the source AN on the A13 interface, realizing the session transition. In such case, the AN does not need to establish the session with the AT and negotiate the configuration again. Figure 3-14 Inter-AN dormant-state HRPD handoff

The procedure of an inter-AN dormant-state HRPD handoff is described as follows: Identification of the source Radio Network Controller (RNC) is done based on KTF specified rules that use the Color Code that is received in the UATI Request. This implies that:

Each RNC will maintain a table with the Color Code and IP address for at least 64 neighbor RNCs

An A13 Information Request is sent using the IP address corresponding to the Color Code of the source RNC. Addition of the ESN to the A13-Session Information Response. The source RNC uses the ESN and the MN ID that are retrieved via the A12 interface. Use of the Message Sequence parameter. The source RNC will send the Message Sequence parameter in the A13-Session Information Response message, the target RNC uses this information to construct the message sequence for the UATI-Assignment that is sent to the AT. Packet Data Serving Node (PDSN) selection at the source RNC is done based on the PDSN IP address that is received in the A13-Session Information Response message.Step 2 The AT sends a UATI Request to the target AN using the UATI assigned by the source AN over the access channel, triggering the session establishment process in the target AN.

Step 3 Upon receiving session information of the source AN, the target AN sends a Hardware ID Request message to request hardware ID (ESN) of the AT.

Step 4 The AT responds with a Hardware ID Response message. The AN records the ESN in this message.

Step 5 After initiating the session establishment in the target AN, the AT sends an A13-Session Information Request message to the source AN to request the session information between the AT and the source AN.

Step 6 The source AN acknowledges the request by sending an A13-Session Information Response message, which includes the session information requested by the target AN.

Step 7 The target AN reassigns and sends the UATI to the AT by using the UATI Assignment message.

Step 8 The AT responds to the target AN with a UATI Complete message. The session between the AT and the target AN is established.

Step 9 The target AN sends the Location Request message to the AT, initiating location update.

Step 10 The AT sends a Location Notification message to the target AN, initiating the location update.

Step 11 The target AN sends a Location Assignment message to the AT to update ATID.

Step 12 The AT responds with a Location Complete message, completing the location update.

Step 13 The target AN sends an A13-Session Information Confirm message to the source AN. The source AN deletes session information of the AT after receiving that message.

Step 14 The target AN sends an A9-Setup-A8 message to the target PCF to request for setup of an A8 connection.

Step 15 The target PCF sends an A11-Registration-Request message to the PDSN to request for the setup of an A10 connection.

Step 16 The PDSN responds an A11-Registration-Reply message, acknowledging the A10 connection setup with the target PCF.

Step 17 The PDSN sends an A11-Registration-Update message to the source PCF to request for the release of A10 connection with the source PCF.

Step 18 The source PCF responds with an A11-Registration-Ack message.

Step 19 The target PCF sends an A11-Registration-Request (lifetime = 0) message to the PDSN.

Step 20 The PDSN sends an A11-Registration-Reply message, releasing the A10 connection with the source PCF.

Step 21 Because there is no data transmission in the dormant state, the target PCF sends an A9-Release-A8 Complete message to the target AN, releasing the A8 connection. The dormant handoff is completed.----End3.3.2 Handoff Between CDMA2000 1X Network and 1xEV-DO Network The handoff between the CDMA2000 1X network and the 1xEV-DO network are as follows: XE "handoff: between 1X and 1xEV-DO networks" \i Dormant Handoff Between CDMA2000 1X Network and 1xEV-DO Network Receiving Voice Page When Connecting with CDMA20001xEV-DODormant Handoff Between CDMA2000 1X Network and 1xEV-DO Network

When an MS or an AT is in the dormant state and moves on the border between a CDMA2000 1X and a CDMA2000 1xEV-DO network, the dormant handoff may be triggered XE "handoff:dormant handoff:between 1X and 1xEV-DO networks" \i

XE "dormant handoff:between 1X and 1xEV-DO Networks" \i The dormant handoff between the CDMA2000 1X network and CDMA2000 1xEV-DO network can occur whether the session exists or not.If the session does not exist, set up a session.

Figure 3-15 shows a dormant handoff when the session already exists.

Figure 3-15 Dormant handoff from the CDMA2000 1X network to the CDMA2000 1xEV-DO network (session already exists)

The procedure of a dormant handoff from CDMA2000 1X to 1xEV-DO when the session already exists is described as follows:

Step 2 The AT/MS sends a Location Notification message to the AN, initiating the location update.

Step 3 The AN sends a Location Assignment message to the AT/MS, updating the parameter ATID.

Step 4 The AT/MS responds with a Location Complete message, completing the location update.

Step 5 The target AN sends an A9-Setup-A8 message to the target PCF to request for the setup of an A8 connection.

Step 6 The target PCF sends an A11-Registration-Request message to the PDSN to request for the setup of an A10 connection.

Step 7 The PDSN responds with an A11-Registration-Reply message, acknowledging the A10 connection setup with the target PCF.

Step 8 The PDSN sends an A11-Registration-Update message to the source PCF to request for the release of A10 connection with the source PCF.

Step 9 The source PCF responds with an A11-Registration Ack message.

Step 10 The target PCF sends an A11-Registration-Request (lifetime = 0) message to the PDSN.

Step 11 The PDSN sends an A11-Registration-Reply message, releasing the A10 connection with the source PCF.

Step 12 Because there is no data transmission in the dormant state, the target PCF sends an A9-Release-A8 Complete message to the target AN, releasing the A8 connection. The dormant handoff from CDMA2000 1X to 1xEV-DO is completed.----EndFigure 3-16 shows a dormant handoff from 1xEV-DO to CDMA2000 1X.

Figure 3-16 Dormant handoff from 1xEV-DO to CDMA2000 1X

The procedure of a dormant handoff from 1xEV-DO to CDMA2000 1X is described as follows:Step 13 The AT/MS sends an Origination Message (DRS = 0) message to the target BSC/PCF.

Step 14 The target BSC/PCF responds with a BS Ack Order message to the AT/MS.

Step 15 The target BSC/PCF sends an A11-Registration-Request message to the PDSN to request for the setup of the A10 connection.

Step 16 The PDSN responds an A11-Registration-Reply message, acknowledging the A10 connection setup with the target BSC/PCF.

Step 17 The PDSN sends an A11-Registration-Update message to the source AN/PCF to request for the release of the A10 connection with the source PCF.

Step 18 The source AN/PCF responds with an A11-Registration Ack message.

Step 19 The target BSC/PCF sends an A11-Registration-Request message to the PDSN.

Step 20 The PDSN sends an A11-Registration-Reply message, releasing the A10 connection with the source BSC/PCF.----EndReceiving Voice Page When Connecting with CDMA20001xEV-DO

When an AT/MS connects with the CDMA2000 1xEV-DO network, it can receive the page from the CDMA2000 1X network; that is, the AT/MS can intercept the public channel of the CDMA2000 1X network. In such case, the AT/MS has the following options: Staying in the CDMA2000 1xEV-DO network and ignores the voice page.

Stopping the transmission in the CDMA2000 1xEV-DO network and goes to the CDMA2000 1X network to establish a call.

Figure 3-17 shows the process of the second option.

Figure 3-17 Receiving the voice page in the CDMA2000 1xEV-DO network

The procedure of receiving the voice page when connecting with CDMA2000 1xEV-DO is described as follows:Step 2 The packet data connection between the AT/MS and the source AN is activated.

Step 3 The target BSS sends a Page message to the AT/MS over the paging channel.

Step 4 The AT/MS stops transmitting data to the AN.

Step 5 The source AN sends an A9-AL Disconnected message to the source PCF, stopping the data stream transmission.

Step 6 The source PCF responds an A9-AL Disconnected message, acknowledging stopping data stream transmission.

Step 7 The AT/MS sends a Page Response message to the target BSS. (This can occur at any time between step 3 and step 7).

Step 8 The target BSS sets up the traffic channel.

Step 9 BSS sends an Alert with Info message to instruct the AT/MS to ring.

Step 10 The AT/MS sends a Connect Order message.

Step 11 The source AN sends an A9-Release-A8 message to the source PCF to request the release of A8 connection.

Step 12 The target PCF sends an A11-Registration Request (lifetime = 0) message to the PDSN.

Step 13 The PDSN sends an A11-Registration Reply message, releasing the A10 connection with the source PCF.

Step 14 The source PCF responds with an A9-Release-A8 Complete message, acknowledging the release of the A8 connection.----EndRequired Feature (in R21.1)

Optional Feature (starting in R22.0 and later)

This feature implements the 1xEV-DO Radio Access Network (RAN)

Authentication feature which allows authentication of the Access Terminal (AT)

before connecting to the data network. The feature is based on the new A12

interface that is defined in IS-878.

RAN-level device authentication uses the Challenge Handshake Authentication

Protocol (CHAP) and requires an Authentication, Authorization, and Accounting

(AAA) server that is connected to the Access Network via the A12 interface that is

defined in IS-878. This feature includes Radio Network Controller (RNC) changes

to support RAN-level authentication and the A12 interface, but does not include

the required A12-AAA server. The RAN-level device authentication provided by

this feature applies to both hybrid terminals (3G1x and 1xEV-DO) and Data Only

(DO) terminals.

In addition to allowing RAN-level authentication of the AT, the feature also provides a way of obtaining the Mobile Node Identifier (MN-ID) used on the A10- A11 interface to facilitate handoffs between 1xEV and IS-2000 systems.

The feature can be used by Wireless Service Providers that require authentication

of the terminal (AT) before connecting to the data network. This feature also

provides a way to obtain the MN-ID as previously stated.Required Feature (in R21.1)

This feature includes changes to the 1xEV-DO Radio Network Controller (RNC) to

allow A10 and A11 interfaces to have one IP address.

Benefits

Allowing the use of one IP address for both A10 and A11 interfaces simplifies the RNC-Packet Data Serving Node (PDSN) interface.

Page 28iiHuawei Technologies ProprietaryIssue 01 (2007-05-21)

Issue 01 (2007-05-21)Huawei Technologies Proprietaryiii

Documents

01-03 CDMA2000 1xEV-DO Service Procedure