2000 Method for supporting common channel packet data service in a CDMA2000 RAN

[0002] RDMD A method for supporting common channel packet data service in a RDA 2000 RAN

1 is a block diagram illustrating the relationship between network components supporting the apparatus and method for supporting the CCPD service of the present invention;

Figure 2 is a block diagram of a preferred embodiment of processing for a CCPD call initiated by an MS in accordance with the present invention;

Fig. 3 is a block diagram of a preferred embodiment of a process for sending an MS incoming packet data by the MS to a CCPD device in an idle packet data state in accordance with the present invention;

Figure 4 is a block diagram of a preferred embodiment of the process for successful inter-PCF/intra-PDSN CCPD MS idle mode handoff in accordance with the present invention;

Fig. 5 is a block diagram of a preferred embodiment of the process for successful inter-PCF/PDSN-to-PDSN CCPD MS idle mode handoff in accordance with the present invention;

Fig. 6 is a block diagram of a preferred embodiment of the process for receiving packet data from a PDSN and forwarding an SDB to the MS in accordance with the present invention;

Fig. 7 is a block diagram of a preferred embodiment of processing for a CCPD call initiated by an MS, wherein the BS and PCF of Fig. 1 are configured as a single device in accordance with the present invention;

8 is a CCPD MS PCF when the MS is serviced by the same PDSN according to the present invention; A block diagram of a preferred embodiment of a process for inter-dormant handoff.

Figure 9 is a block diagram of a preferred embodiment of a process for a CCPD MS PCF dormant handoff when the MS is served by a new PDSN in accordance with the present invention;

* Description of the main parts of the drawing *

104 : BS 106 : PCF

106 : PCF 108 : PDSN

110 : MSC 116 : A8 interface

<background-art><p>FIELD OF THE INVENTION The present invention relates to the field of communication systems, and more particularly, to a Code Division Multiple Access (CDMA) communication system.</p></background-art><tech><p>Data services are generally classified into two categories: circuit-oriented data services (including asynchronous data and group-3 fax services) and packet data services. For calls that support packet data services, a Packet Data Serving Node (PDSN) acts as an interface between data transmission in a fixed network and data transmission over the air interface. The PDSN interfaces with the BS through a Packet Control Function (PCF), which may or may not be co-located with the Base System (BS).</p><p>Third Generation Joint Project 2, which is incorporated herein by reference; As defined in the 3GPP2 Access Network Interface Interoperability Specification (3rd Generation Partnership Project 2; 3GPP2 Access Network Interfacew Interoperability Specification) (hereinafter referred to as 3GPP2 A.S0001-A), active/connection state, dormant state, There are three packet data service states of Null/Inactive state. (3GPP2 specification is the same as that of June 2001 TIA/EIA/IS-2001-A). When an MS station (MS) originates a packet data call to the current CDMA2000 Radio Access Network (RAN), it establishes a point-to-point protocol (PPP) connection and performs mobile Internet protocol (IP) registration procedures on the traffic channel. is assigned When these processes are successfully completed, the packet data service of the MS changes from the null state to the active/connected state, and the network and the MS exchange packet data through the traffic channel. After being inactive for a certain period of time, the MS's packet data service changes from an active state to an idle state, but may become active again if the MS or the network has data to transmit. Also, inter-PDSN idle mode handoffs require allocation of a traffic channel to support the setup and re-registration of a new PPP connection.</p><p>In the active/connected state, a physical traffic channel exists between the MS and the BS, and either device may transmit data. In the dormant state, there is no physical traffic channel between the MS and the BS, but the PPP link is maintained between the MS and the PDSN. In the null/inactive state, there is no traffic channel between MS and BS, and no PPP link between MS and PDSN.</p><p>A1 to A11 interfaces are defined in clause 1.7.2 of 3GPP2 A.S0001-A. A1 connection and A8 connection are maintained when active/connected state, and released when changing to idle state or null/inactive state. In the active/connected state and the idle state, the A10 connection is maintained. As part of the support for the dormant state, the CDMA2000 air interface (TIA/EIA-IS-2000) supports the Data Readuy to Send (DRS) indicator used at the origin. When the MS sends an originating request specifying the packet data service option, the request includes the DRS bit. When the MS wants to change from the dormant state to the active state because it has data to transmit and requests the establishment of a traffic channel, this indicator is set to one during initial call setup. The DRS bit is then set to 0 to indicate that the MS has moved the packet zone boundary while dormant (see section 2.14.1 of 3GPP2 A.S0001-A) and is sending an origination request to update the network for its current location. do.</p><p>When an originating request with the DRS bit set to 1 is received, the BS initiates the call setup process as shown in clause 2.14.7.1 of 3GPP2 A.S0001-A, normally a traffic channel is established and A8 and A10 bearers (bearer) Causes connections to be established. Procedures for A8 and A10 bearer connections are defined in 3GPP2 A.S0001-A, clauses 2.14 and 2.15, respectively. When the BS receives the request with the DRS bit set to 0, the BS delays the establishment of the traffic channel until after the A8 and A10 bearer connection establishment procedures are completed. During the A8 bearer connection establishment process, the BS uses the data ready indicator element in the A9-Setup-A8 message (as defined in clause 2.14.4.1.1 of 3GPP2 A.S0001-A) to indicate that DRS=0 has been received. inform the PCF. If the PCF has data from the network to forward to the MS, the PCF prepares to send the cause element in the A9-connect-A8 message (defined in clause 2.14.4.1.2 of 3GPP2 A.S0001-A). You indicate this by setting it to a data value. The BS then establishes a traffic channel to the MS and completes the regular call setup process as specified in clause 2.14.7.10 of 3GPP2 A.S0001-A. If the PCF has no data, it indicates that the A8 connection has not been established by sending an A9-Release-A8 Complete message (as defined in clause 2.14.5.4 of 3GPP2 A.S0001-A) to the BS. Then, the BS returns an allocation failure message with the cause value set to Packet Call Going Dormant to the MSC. When the assignment failure message is received, the MSC returns a clear command setting the cause value to Do Not Notify Mobile to the BS. When the BS receives the clear command message, it sends a clear complete message to the MSC.</p></tech>

<p>The present invention provides an apparatus and method for supporting Common Channel Packet Data (CCPD) services in a CDMA2000 RAN without using a traffic channel. Packet data sessions may be initiated, idle mode handoffs may be performed, and packet data may all be exchanged without using traffic channels. Also, once the MS has successfully registered with the network, the A8 connection between the PCF and the PDSN is not required to support the packet data service. The present invention may also be applied to current CDMA2000 MSs that support idle mode handoffs and data transmission not using a traffic channel. CCPD The feature supports packet data call setup, idle mode handoff, and data transmission using short data bursts (SDBs) over common channels.</p><p>CCPD features are required to support CCPD devices. A CCPD device is a data-only device that does not support CDMA2000 traffic channels. Any signaling or data to be exchanged between the CCPD device and the network must be exchanged over the CDMA2000 common channels. Although the present invention may be realized in many types of CCPD devices, the present invention is particularly suitable for use in MS. Accordingly, a preferred embodiment of the present invention will be described with reference to the MS.</p><p>A CCPD capable MS is a CDMA2000 MS that supports CCPD services in addition to the current CDMA2000 packet data services. A CCPD capable MS may request CCPD services from the network when the amount of data to be transmitted is expected to be small and infrequent or for idle mode handoffs. Because CCPD devices communicate over common channels rather than expensive traffic channels, they can be made relatively inexpensively for users and network operators. Also, due to their limited functionality, they are expected to be less expensive than the currently available CDMA2000 MSs. Possible applications of CCPD devices include: (1) telemetry - CCPD devices may be deployed in utility instruments (water, electricity and gas); (2) vending machines - CCPD devices may be used to notify suppliers of out of stock; (3) Automatic/Home Security - CCPD devices may be used to notify authorities of home invasions; (4) taxi meters; and (5) stock quotes. For simplicity of explanation, only CCPD services are supported (CDMA2000). An MS that does not support traffic channels) and an MS capable of supporting CCPD services and CDMA2000 traffic channels are collectively referred to herein as a CCPD MS.</p><p>1 is a block diagram showing a relationship between network elements for an apparatus and method for supporting a CCPD service according to the present invention. As shown, target BS 102 is coupled to source BS 104 via A3 interface 112 and A7 interface 114 for exchange of traffic and signaling information. Each of the A3 interface and A7 interface 112, 114 is not particularly relevant to the present invention and therefore will not be described further herein. Source BS 103 is connected to PCF 106 via A8 interface 116 and A9 interface 118 . A8 interface 116 is used to provide a path for user traffic between PCF 106 and base station controller (BSC) in source BS 104 for packet data services. The A9 interface 118 is used to provide a signaling connection between the source BSC and the PCF 106 for packet data services. PCF 106 is coupled to PDSN 108 via A10 interface 120 and A11 interface 122 . A10 interface 120 is used to provide a path for user traffic between PCF 106 and PDSN 108 for packet data services. A11 interface 122 is used to provide a signaling connection between PCF 106 and PDSN 108 for packet data services. MSC 110 is coupled to source BS 104 via A1 interface 124 , A2 interface 126 , and A5 interface 128 . Each of the A1, A2, and A5 interfaces 124, 126, 128 is not particularly relevant to the present invention and therefore will not be described further herein.</p><p>Messages and data between the network and the CCPD MS are encapsulated in SDBs. and exchanged through common channels. This includes PPP connections, MIP registrations, and packet data. The BS may initiate a CCPD service to a CCPD MS even if the MS did not explicitly request the service by setting the SDB_DESIRED_ONLY bit of the originating message to one. This can be used for idle mode handoffs. The BS may do this by using the SDB to respond to the MS's origin on a common channel rather than allocating a traffic channel for the call. Subsequent communication between the MS and the network will be done using SDBs over common channels.</p><p>The CCPD device requests the CCPD service from the network by sending an invocation message in which the SDB_DESIRED_ONLY bit is set to 1 and the FCH_SUPPORTED bit and the DCCH_SUPPORTED bit are set to 0 to the BS. When the device is successfully authenticated, PPP connection setup and Mobile IP registration are performed using SDBs over common channels to exchange messages. The first SDB sent by the BS to the CCPD device is used as an acknowledgment for the CCPD service request of the device. If the BS cannot support the CCPD service request from the CCPD device, no SDB is sent and the call attempt fails. The CCPD device may send the CCPD service request again.</p><p>The CCPD MS may request the CCPD service from the network by sending an invocation message in which the SDB_DESIRED_ONLY bit, the FCH_SUPPORTED bit and the DCCH_SUPPORTED bit are set to 1 to the BS. If the BS chooses to support the MS's CCPD service request, the MS is authenticated first. When the MS has successfully authenticated, it notifies the PCF that CCPD services are being used for the call. through common channels to exchange messages PPP connection setup and Mobile IP registration (if necessary) are performed using SDBs. Messages and data between the BS and the PCF are transmitted through the A9 signaling channel. The first SDB transmitted to the CCPD MS is used as an acknowledgment for the CCPD service request. The network may also reject the CCPD service request of the CCPD MS, and may apply normal packet data procedures to set up a packet data call or transmit packet data. When the PPP connection and mobile IP registration are successfully completed, the packet data service of the CCPD MS changes from the null/inactive state to the idle state, and the A8 connection between the BS and the PCF is released.</p><p>In a first aspect of the present invention, a preferred embodiment of processing for a CCPD call initiated by an MS is provided. When the CCPD MS 202 initiates a packet data call and Mobile IP registration is not performed, PPP connection setup and Mobile IP registration are performed using SDBs over common channels. Once the PPP connection setup and Mobile IP registration are complete, packet data may be exchanged between the MS 202 and the network using SDBs over common channels. All messages specifying the SDB format are as specified in Section 12, Section 2.2.10 of Ballot Resolution Version (IS-707-A-2), TIA/EIA/IS-707-A-2, June 2000.</p><p>In Fig. 2, in step a, the CCPD MS 202 sends an invocation message to the BS 104 over the access channel of the air interface with a layer 2 acknowledgment necessary to request the packet data service. MS 202 indicates to request CCPD service from the network by setting the message SDB_DESIRED_ONLY bit to 1. In step b, the BS 104 has received the originating message by sending a base station acknowledgment order (Order) to the CCPD MS 202. announce the sound In step c, BS 104 sends an ADDS Send message (described in section 2.6.2.2 of 3GPP2 A.S0001-A) to MSC 110 . The message includes the authentication parameters received from the CCPD MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB. BS 104 starts timer T60. If the MS 202 supports the traffic channels and the BS 104 decides not to support the CCPD service request, the call is a regular packet data call originating from the MS (specified in clause 2.14.7.1 of 3GPP2 A.S0001-A). ) is treated as If the BS 104 cannot support the CCPD service request from the CCPD device, the call fails.</p><p>In step d, MSC 110 sends the authentication result for MS 202 back to BS 104 in an ADDS transmit acknowledgment message (described in section 2.14.8.1.2 of 3GPP2 A.S0001-A). do. In step e, BS 104 sends an A9-Setup-A8 message (described in section 2.14.4.1.1 of 3GPP2 A.S0001-A) to PCF 106 to set up PPP connection and set up CCPD MS 202 ) for Mobile IP registration (if necessary). BS 104 sets the CCPD service bit of the message to 1 to indicate to PCF 104 that an A8 connection is not required. If the MS 202 is a CCPD device, the BS 104 sets the CCPD bit of the message to 1 to indicate to the PCF 104 that the data session is for the CCPD device. BS 104 starts a timer (TA8-setup). In step f, an A10/A11 connection establishment process is performed. In step g, when the A10/A11 connection is established, the PDSN 108 and CCPD MS 202 message over the air using SDBs over common channels to set up the PPP connection and perform MIP registration (if necessary). exchange them All messages exchanged between the network and the MS 202 is in SDB format. PCF 106 converts messages to MS 202 to SDB format before sending to BS 104 . BS 104 sends messages from MS 202 to PCF 106 in SDB format. The PCF 106 converts the messages to a packet data format before sending the data to the PDSN 108 . The first SDB sent from BS 104 to MS 202 acts as an acknowledgment for the MS's CCPD service request. In step h, PCF 106 sends an A9-Release-A8 Complete message (described in section 2.14.5.4. of 3GPP2 A.S0001-A) to BS 104 with a success cause value. BS 104 stops the timer (TA8-Setup). In step i, MS 202 sends its packet data in SDB format to BS 104 over a common channel.</p><p>In step j, BS 104 notifies MS 202 of receipt of the SDB by sending a BS acknowledgment order to MS 202 . In step k, BS 104 sends to PCF 106 an A9-short data transfer message containing packet data in SDB format. In step 1, PCF 106 sends data to PDSN 108 as regular packet data. In step m, the PCF 106 sends an A-11 registration request message (October 1996, IBM, C. Perkins, Editor, Request for Comments: 2002, described in Section 3.3 of the Network Working Group and Section 6.1.11.1 of 3GPP2 A.S0001-A) to the PDSN 108 . In step n, the PDSN 108 sends an A11 registration response message (October 1996, IBM, C. Perkins, Editor, Request for Comments: 2002, Section 3.4 of the Network Working Group and 6.1.11.2 of 3GPP2 A.S0001-A). ) in response to the PCF 106.</p><p>In a second aspect of the present invention, a preferred embodiment of a process for sending an MS incoming packet data to a CCPD device by an MS 202 in an idle packet data state is provided. If the network has data to send to the dormant CCPD device, the PCF 106 sends the data to the BS 104 in an A9-short data transfer message. When the MS 202 initiates a CCPD service request to the network, it informs the PCF 106 that the MS 202 is a CCPD device. Because the data is to the CCPD device, the PCF 106 does not need to buffer the data to the MS 202 and thus does not require an acknowledgment from the BS 104 after the data is transmitted. BS 104 transmits data to the CCPD device in the SDB formats specified in IS-707-A-2. If BS 104 does not receive an acknowledgment from MS 202 after sending the SDB to MS, BS 104 may retry sending the data and/or calling ADDS procedures to deliver the data ( can be invoked). For the ADDS process, refer to Section 2.14.8.6 of 3GPP2 A.S0001-A.</p><p>Figure 3 shows a logic flow diagram for a preferred embodiment of the process for sending an MS incoming packet data to a CCPD device by the MS 202 in the idle packet data state. Upon initial packet data session setup, MS 202 informs PCF 106 that it is a CCPD device. All messages specifying the SDB format are as specified in IS-707-A-2. In step a, PPP connection setup and Mobile IP registration have been previously performed between the network and the MS 202 . The CCPD MS 202 is currently in an idle packet data service state. In step b, the PPSN 108 sends packet data from the network to the CCPD MS 202 . In step c, the PCF 106 sends packet data in SDB format to the A9-short data transfer message. transmitted to BS 104 . In step d, BS 104 sends packet data in SDB format to CCPD MS 202 over a common channel. In step e, the MS 202 informs the SDB reception by sending a layer 2 acknowledgment to the BS 104. If a layer 2 acknowledgment has not been received from MS 202 , BS 104 may send the SDB back to MS 202 . Alternatively, BS 104 may use the ADDS process to forward the SDB to MS 202 .</p><p>In step f, BS 104 sends an A9-Update-A8 message (described in section 2.14.5.6 of 3GPP2 A.S0001-A) to PCF 106 so that SDB successfully transmits to MS 202 inform that it has been BS 104 starts timer Tupd9. In step g, the PCF 106 sends an A-11 registration request message to the PDSN 108 along with the SDB airlink record for accounting. In step h, PDSN 108 responds to PCF 106 with an A11 registration response message. In step i, PCF 106 responds to BS 104 with an A9-Update-A8 acknowledgment message (described in clause 2.14.5.7 of 3GPP2 A.S0001-A). When this message is received, the BSC stops the timer Tupd9.</p><p>A third and fourth aspect of the present invention provides dormant handoff procedures for CCPD MSs. When a new packet zone identifier (PZID), system identifier (SID), or network identifier (NID) is detected, the CCPD MS sends an invocation message with the SDB_DESIRED_ONLY bit set to 1 to the BS 104 . The PCF establishes an A10 connection with the PDSN. If the MS continues to be served by the same PDSN, the PDSN releases the A10 connection with the previous PCF. When a new PDSN is selected for the call as a result of the dormant mode handoff, a PPP connection is set up using SDBs over common channels and Mobile IP registration is performed. affection Note that by applying the regular packet data idle mode handoff procedures, the BS 104 may reject the CCPD service request of the CCPD MS.</p><p>In addition, the BS may initiate the CCPD service to a CCPD MS that has no data to transmit even if the MS has not explicitly requested the CCPD service from the BS by setting the SDB_DESIRED_ONLY bit of the originating message to 1. The BS may optionally use this procedure to support idle mode handoffs (eg, if the traffic channel is not available). When detecting a new PZID, SID, or NID, the CCPD MS sends an Invocation message with the SDB_DESIRED_ONLY bit set to 0 and the DRS bit set to 0 to the BS. Instead of initiating regular idle mode handoff procedures, the BS authenticates the MS and informs the PCF that the CCPD service will be used for idle mode handoff support. The first SDB sent to the MS indicates that CCPD procedures will be used for idle mode handoff support. Subsequent communication between the MS and the network occurs using the SDB over common channels.</p><p>In a third aspect of the present invention, a process is provided for successful inter-PCF/intra-PDSN CCPD MS idle mode handoff. It is assumed that the PCF is uniquely identified by current access network identifiers (CANID). When detecting a new PZID, NID or SID, the CCPD MS transmits a packet data service option and an originating message in which the SDB_DESIRED_ONLY bit is set to 1 to the target BS. If the call is from a CCPD device, the FCH_SUPPORTED bit and the DCCH_SUPPORTED bit are also set to zero. The originating message is the previous message when any of these parameters are changed during dormant handoff. Includes PZID, NID and SID. Based on the IDs (PZID, NID, and/or SID) of the originating message, the target PCF sends the source PCF's previous access network identifiers (PANID) and the target PCF's CANID to the serving PDSN. The serving PDSN uses this information to determine if Mobile IP registration is required. All messages specifying the SDB format in processing are as specified in IS-707-A-2. This process may be used when the network decides to use the CCPD service for idle mode handoff. In this case, the MS sends an invocation message with the SDB_DESIRED_ONLY bit set to zero. The first SDB sent to the MS indicates that CCPD procedures will be used to support idle mode handoff.</p><p>In Figure 4, the process for a successful inter-PCF/intra-PDSN CCPD MS idle mode handoff is provided. In step a, the CCPD MS 202 has previously performed PPP connection establishment and MIP registration with the PDSN 108, and is currently in the dormant state. In step b, the CCPD MS 202 detects a change in PZID, SID, or NID while monitoring a broadcast channel, and transmits an invocation message in which the SDB_DESIRED_ONLY bit is set to 1. In step c, the target BS 102 informs the CCPD MS 202 of receipt of the originating message by means of a base station acknowledgment order. In step d, the target BS 102 sends an ADDS transmission message including the authentication parameters received from the MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB to the MSC 110 ) is sent to If BS 102 has determined that CCPD MS 202 supports traffic channels, alternatively BS 102 will execute the MS Idle Mode handoff procedure described in clause 2.14.7.9 of 3GPP2 A.S0001-A. Number there is also The target BS 102 starts a timer T60. In step e, the MSC 110 sends an ADDS transmission acknowledgment message to the target BS 102 without a cause value. The target BS 102 stops the timer T60. If the authentication of the MS 202 has failed, the MSC 110 includes a cause value set to "authentication failure" in the message and the CCPD call is failed.</p><p>In step f, the target BS 102 sends an A9-Setup-A8 message to the target PCF 402 with the data ready indicator bit and the handoff indicator bit set to zero. BS 102 sets the CCPD service bit in the message to 1 to inform PCF 402 that an A8 connection is not required. If the MS 202 is a CCPD device, the target BS 102 sets the CCPD bit of the message to 1 to inform the target PCF 402 that the data session is for the CCPD MS 202 . The target BS 102 starts a timer (TA8-setup). In step g, the target PCF 402 establishes an A10/A11 link with the PDSN 108 . PDSN 108 disconnects the A10/A11 link with source PCF 402 . If PDSN 108 has data for MS 202, indicate data availability in Vender/Organization Specific Extension (described in 6.2.2.166 of 3GPP2 A.S0001-A). It responds to the PCF 402 with a registration response message with a character.</p><p>In step h, the target PCF 402 sends an A9-release A8 complete message including a success cause value to the target BS 102 . The target BS 102 stops the timer (TA8-setup). In step i, if the PDSN 108 has data from the network for the CCPD MS 202, the target PCF 402 sends the data in SDB format to the BS 102 in an A9-short data transfer message. If the MS 202 supports traffic channels, the PCF 402 , followed by a procedure for short data transfer from PCF 402 to MS 202 (see 2.14.8.6/7 of 3GPP2 A.S0001-A for this processing). If the data is for the CCPD MS 202, the PCF 402 discards the data. In step j, when PCF 402 sends data for MS 202 to target BS 102 in a short data transfer message, BS 102 sends the data to MS 202 in SDB. The SDB acts as an acknowledgment for the CCPD service from the BS 102 . If no data has been sent from PCF 402 , an empty SDB is sent to MS 202 . In step k, the CCPD MS 202 informs the reception of the SDB by sending a layer 2 acknowledgment to the BS 102 . If the data has been sent to the SDB, the A9 update process for accounting (as shown in section 2.14.9.2 of 3GPP2 A.S0001-A) is performed.</p><p>In a fourth aspect of the present invention, a process is provided for successful inter-PCF/intra-PDSN CCPD MS idle mode handoff. When the MS in the idle state moves to another packet zone and accesses another PDSN, the target PCF must transmit the access network identifiers (ANID) of the source PCF (PANID) and the ANID of the target PCF (CANID) to the serving PDSN. do. PPP connection setup and Mobile IP registration are performed using SDBs over common channels. All messages specifying the SDB format for processing are as specified in IS-707-A-2. The process may also be used when the network decides to use the CCPD service for idle mode handoff. In this case, the MS sends an invocation message with the SDB_DESIRED_ONLY bit set to zero. The first SDB sent to the MS indicates that CCPD procedures will be used to support idle mode handoff.</p><p>In Figure 5, a preferred embodiment of the process for successful inter-PCF/intra-PDSN CCPD MS idle mode handoff is provided. In step a, the CCPD MS 202 detects a change in PZID while monitoring a broadcast channel and transmits an invocation message in which the SDB_DESIRED_ONLY bit is set to 1. In step b, the target BS 102 informs the CCPD MS 202 of receipt of the originating message by means of a BS acknowledgment order. In step c, BS 102 sends an ADDS Send message to MSC 110 . The message includes the authentication parameters received from the MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB. If BS 102 determines that CCPD MS 202 supports the traffic channel, alternatively BS 102 executes the MS Idle Mode handoff procedure described in clause 2.14.7.9 of 3GPP2 A.S0001-A. may be The target BS 102 starts a timer T60. In step d, the MSC 110 sends an ADDS transmission acknowledgment message to the target BS 102 without a cause value. The target BS 102 stops the timer T60. If the authentication of the MS 202 has failed, the MSC 110 includes a cause value set to "authentication failure" in the message and the CCPD call fails.</p><p>In step e, target BS 102 sends to target PCF 402 an A9-Setup-A8 message with data ready indicator and handoff indicator bits set to zero. BS 102 sets the CCPD service bit in the message to 1 to inform the PCF that the A8 connection is not required. If the MS 202 is a CCPD device, the BS 102 sets the CCPD bit in the message to 1 to inform the PCF 402 that the data session is for the CCPD MS 202 . BS 102 starts a timer (TA8-setup). In step f, the process for establishing the A10/A11 connection This is done. In step g, when the A10/A11 connection is established, the PDSN 108 and CCPD MS 202 exchange messages over the air using SDBs over common channels to set up the PPP connection and perform MIP registration. . All messages exchanged between the network and the MS 202 are in SDB format. PCF 402 converts messages for MS 202 to SDB format before sending to BS 104 . BS 102 sends messages from MS 202 to PCF 402 in SDB format. The PCF 402 converts the messages into packet data before sending the data to the PDSN 108 . The first SDB sent from the BS 104 to the MS 202 is used as an acknowledgment for the CCPD service request of the MS. In step h, the PCF 402 sends an A9-Release-A8 Complete message to the BS 102 together with the success cause value. BS 102 stops the timer (TA8-Setup). If the call is to a CCPD capable MS 202 and the PDSN 108 has data for the MS 202, depending on the amount of data, the PCF 402 will respond to the BS 102 with a cause value indicating a failure. may then be followed by network-initiated call re-activation.</p><p>A fifth aspect of the present invention provides a preferred embodiment of the process of receiving packet data from the PDSN and forwarding the SDB to the MS. In this embodiment, the BS and PCF as shown in Fig. 1 are configured as a single device. 6 , in step a, PCF 602 receives packet data from PDSN 108 and determines whether the data can be delivered to an idle packet data service instance. BS 602 may send the SDB directly to MS 202 . If the received data is for a CCPD device, then the packet data will always be sent to the MS 202 as SDB. In step b, MS 202 sends SDB from BS 602 In response, it sends a layer 2 acknowledgment. If a layer 2 acknowledgment has not been received from MS 202 , BS 602 may attempt to transmit the data back to MS 202 . In step c, alternatively, BS 602 may send data in SDB format as specified in IS-707-A-2 to MSC 110 in a BS service request message. BS 602 starts timer T311. When the timer T311 expires, the SDB information will not be sent to the MS 202 . This step may also occur if BS 602 has not successfully delivered the SDB to MS 202 . In step d, the MSC 110 notifies the reception of the BS service request message by sending a BS service response message to the BS 602 . BS 602 stops timer T311. In step e, the MSC 110 sends an ADDS page message to the BS 602 with the data burst type field of the ADDS user-side element set to SDB, and the SDB of the application data message field. BS 602 sends the SDB to MS 202 .</p><p>In step f, MS 202 sends a layer 2 acknowledgment after receiving the SDB from BS 602. If the MSC 110 includes a tag element in the ADDS page message, then BS 602 will return an ADDS page acknowledgment message to MSC 110 after receiving the layer 2 acknowledgment from MS 202 . The tag element received from the MSC 110 is included in the message. In step g, BS/PCF 602 sends an A11-registration request to PDSN 108 along with an SDB airlink record. In step h, the PDSN 108 responds with an A11-Registration Response message.</p><p>A sixth aspect of the present invention is a preferred aspect of processing for CCPD calls initiated by MS. Examples are provided. In this embodiment, the BS and PCF as shown in Fig. 1 are configured as a single device. When a CCPD MS that has not performed Mobile IP registration initiates a packet data call, PPP connection setup and Mobile IP registration are performed using SDBs through common channels. Once the PPP connection is established, packet data is exchanged between the MS and the network by SDBs over common channels.</p><p>7 shows a flow diagram of a preferred embodiment of processing for a CCPD call initiated by the MS. In step a, the MS 202 sends an originating message to the BS 602 over the access channel of the air interface with a layer 2 acknowledgment necessary to request the packet data service. MS 202 indicates to request CCPD service from the network by setting the SDB_DESIRED_ONLY bit of the message to 1. In step b, BS 602 notifies MS 202 of receipt of the originating message by sending a base station acknowledgment order. In step c, BS 602 sends an ADDS Send message to MSC 110 . The ADDS transmission message includes the authentication parameters received from the CCPD MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB. BS 602 starts timer T60. If the MS 202 supports the traffic channels and the BS 602 decides not to support the CCPD service request, then the call is a regular packet data call setup originating from the MS (specified in clause 2.15.5.1 of 3GPP2 A.S0001-A). are treated as ). If the BS 602 cannot support the CCPD service request from the CCPD device, the call fails.</p><p>In step d, the MSC 110 transmits the authentication result for the CCPD MS 202 to the ADDS transmission acknowledgment In message, it is sent back to BS 104. In step e, PCF 602 recognizes that no A10 connections associated with MS 202 are available and selects PDSN 108 for the call. The PCF 602 sends an A11-registration request message to the selected PDSN 108 and starts a timer (Tregreq). In step f, the A11-registration request is validated and the PDSN 108 indicates acceptance and the configured T_rpAccept the connection by sending back an A11-Registration Response message containing the lifetime field set to the value. The PCF 602 stops the timer Tregreq.</p><p>In step g, MS 002 and PDSN 108 establish a link layer (PPP) connection and then exchange SDBs over common channels to perform MIP registration procedures (if necessary). The first SDB sent from the BS 602 to the MS 202 acts as an acknowledgment for the MS's CCPD service request. In step h, MS 202 sends its data to BS 602 via a common channel as SDB. In step i, BS 602 notifies MS 202 of receipt of the SDB by sending a BS acknowledgment order to MS 202 . In step j, PCF 602 sends packet data to PDSN 108 . In step k, PCF 602 sends an A11-registration request message with SDB airlink record to PDSN 108 . In step 1, PDSN 108 updates accounting data and responds to PCF 602 with an A11 registration response.</p><p>A seventh aspect of the present invention provides a preferred embodiment of a process for a CCPD MS PCF dormant handoff when the MS is being served by the same PDSN. In order to obtain packet data services, the CCPD MS has performed registration with the packet network. Both A10 connections and link layer (PPP) connections are maintained. Source PCF, A10 Connection Lifetime timer (T_rp) continues to perform re-registration for A10 connection with PDSN by exchanging A11-Registration Request and A11-Registration Response messages before expiration. While in idle mode, the CCPD MS detects a change in PZID, SID or NID. When a new PZID, SID or NID is detected, the MS sends an originating message to the target BS 102 with the packet data service option and the SDB_DESIRED_ONLY bit set to 1. If the call is to a CCPD device, the FCH_SUPPRTED and DCCH_SUPPORTED bits are also set to zero. The originating message contains these parameters when any of the previous PZID, SID and NID was changed during dormant handoff. The target PCF establishes an A10 connection with the PDSN. Based on the IDs (PZID, NID and/or SID) of the originating message, the target PCF sends the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. The serving PDSN uses this information to determine whether Mobile IP registration is required. If the PDSN has the data, the PDSN returns a 'data availability indicator' in the vendor/organization specific extension in the registration response. The source PDSN releases the A10 connection with the source PCF.</p><p>The described process may also be used when the network decides to initiate a CCPD service for idle mode handoff. In this case, the MS sends an invocation message with the SDB_DESIRED_ONLY bit set to zero. The first SDB sent to the MS indicates that CCPD procedures will be used to support idle mode handoff.</p><p>8 shows a flowchart of a preferred embodiment of a process for a CCPD MS PCF dormant handoff. In this embodiment, the source BS and the source PCF are configured as a single device. is made up The target BS and target PCF are also configured as a single device. The process assumes that the CCPD MS 202 has previously already performed PPP connection establishment and Mobile IP registration with PDSN 108, and currently maintains an idle packet data service instance. In step a, upon detecting a new packet zone ID, the CCPD MS 202 transmits an origination message with the SDB_DESIRED_ONLY bit set to 1. In step b, the target BS 602 informs the MS 202 that it has received the originating message by the BS acknowledgment order. In step c, the BS sends an ADDS transmission message to the MSC 110 . The message includes the authentication parameters received from the MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB. If BS 102 determines that CCDP MS 202 supports traffic channels, BS 102 alternatively performs the MS Idle Mode handoff procedure described in clause 2.15.5.8 of 3GPP2 A.S0001-A. can also run Target BS 802 starts timer T60. In step d, the MSC 110 sends an ADDS transmission acknowledgment message to the target BS 802 without a cause value. Target BS 802 stops timer T60. If the authentication of the MS 202 fails, the MSC 110 includes the cause value set to "authentication failure" in the message, and the CCPD call fails.</p><p>In step e, the target PCF 802 sends an A11-registration request message to the PDSN 108 . The registration request message includes a mobility event indicator within a vendor/organization specific extension. The PCF starts a timer (Tregreq). In step f, the A11-registration request is validated and the PDSN 108 accepts the connection by returning an A11-registration response with an acceptance indication. If the PDSN 108 has data to transmit, the PDSN will Include a data availability indicator within the significant extension. If the data is for a CCPD capable MS 202 , the network initiated call may be reissued. The A10 connection binding information of the PDSN 108 is updated to specify the target PCF 802 . The target PCF 802 stops the timer Tregreq. In step g, the BS sends an empty SDB to the CCPD MS 202 to indicate that it has accepted the CCPD service request. If PDSN 108 sent data for MS 202, the data is included in the SDB. In step h, the CCPD MS 202 responds with a layer 2 acknowledgment to indicate that it has received the SDB. The MS's packet data service instance goes to sleep again. If the network or MS 202 has some data to transmit, the data may be transmitted using SDBs over common channels using CCPD procedures.</p><p>In step i, PDSN 108 initiates A10 connection termination with source PCF 602 by sending an A11-Registration Update message. The PDSN 108 starts a timer Tregupd. In step j, the source PCF 602 responds with an A11-registration acknowledgment message. The PDSN 108 stops the timer Tregupd. In step k, the source PCF 602 sends an A11-registration request message with the lifetime set to zero to the PDSN 108 . The PCF starts a timer (Tregreq). In step l, PDSN 108 sends an A11-Registration Response message to source PCF 602 . The source PCF 602 disconnects the A10 connection to the MS 202 . The source PCF 602 stops the timer Tregreq. In step m, the target PCF 802 refreshes the A10 connection registration with the PDSN 108 with a registration lifetime timer T_rp) Sends an A11-registration request message to the PDSN 108 before it expires. The A11-Registration Request message is also used to send other information related to accounting to the PDSN 108 . Other information related to accounting is transmitted to trigger points defined in the system. The PCF starts a timer (Tregreq).</p><p>In step n, for an A11-registration request that has been validated, the PDSN 108 returns an A11-registration response message with an indication of acceptance and a configured lifetime value. The PDSN 108, before returning the A11-registration response, stores the accounting data (if received) for further processing. The PCF stops the timer (Tregreq).</p><p>The eighth aspect of the present invention provides a preferred embodiment of the process for CCPD MS PCF dormant handoff when the MS is being served by a new PDSN. When the packet data session is in dormant mode, the MS detects a change in PZID, SID or NID. When a new PZID, SID or NID is detected, the MS sends a packet data service option and an originating message with the SDB_DRSIRED_ONLY bit set to 0 to the target BS 102 . If the call is to a CCPD device, the FCH_SUPPRTED and DCCH_SUPPORTED bits are also set to zero. The target PCF establishes an A10 connection with the target PDSN. The target PCF must transmit the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. PPP connection setup and Mobile IP registration are done using SDBs over common channels. The source PDSN releases the A10 connection with the source PCF when the MIP registration timer expires. The target PCF periodically re-registers with the PDSN using an A11-registration request message before the A10 connection lifetime expires.</p><p>The described process may also be used when the network decides to initiate a CCPD service for idle mode handoff. In this case, the MS sends an invocation message with the SDB_DESIRED_ONLY bit set to zero. The first SDB sent to the MS indicates that the CCPD procedures will be used to support the idle mode handoff.</p><p>9 shows a flow diagram of a preferred embodiment of a process for a CCPD MS-PCF dormant handoff when the MS 202 is being served by the new PDSN 902 . In this embodiment, the source BS and the source PCF are configured as a single device. The target BS and the target PCF are also configured as a single device. The process assumes that the CCPD MS 202 has previously performed PPP connection establishment and Mobile IP registration with the PDSN 108, and currently maintains an idle packet data service instance. In step a, upon detecting a new PZID, the CCPD MS 202 sends an originating message with the SDB_DESIRED_ONLY bit set to 1 to the target BS 802 . In step b, the target BS 802 notifies the MS 202 that it has received the originating message by sending a BS acknowledgment order. In step c, BS 802 sends an ADDS Send message to MSC 110 . The message includes the authentication parameters received from the MS 202, the authentication data element calculated by the BS, and the data burst type field of the ADDS user-side element set in the SDB. If BS 102 has determined that CCDP MS 202 supports traffic channels, alternatively target BS 802 may use the MS idle mode handoff procedure described in clause 2.15.5.9 of 3GPP2 A.S0001-A. can also be run. Target BS 802 starts timer T60. </p><p>In step d, the MSC 110 sends an ADDS transmission acknowledgment message to the target BS 802 without a cause value. Target BS 802 stops timer T60. If the authentication of the MS 202 fails, the MSC 110 includes a cause value set to "authentication failure" in the message. In step e, target PCF 802 initiates A10 connection establishment by sending an A11-registration request message to PDSN 902 . The registration request message includes a mobility event indicator within a vendor/institution specific extension. The PCF 802 starts a timer Tregreq. In step f, the A11-registration request is validated and the target PDSN 902 accepts the connection by returning an A11-registration response with an acceptance indication and a data availability indicator in the vendor/organization-specific extension. The PCF 802 stops the timer Tregreq.</p><p>In step g, MS 202 and target PDSN 902 exchange SDBs over common channels to establish a link layer (PPP) connection and then perform MIP registration procedures over the link layer (PPP) connection. The first SDB sent from the BS 802 to the MS 202 acts as an acknowledgment for the CCPD service request of the MS. The MS's packet data service instance goes to sleep again. If the network or MS 202 has some data to transmit, the data is transmitted using SDBs over common channels using CCPD procedures.</p><p>In step h, when the MIP registration timer expires, the source PDSN 108 initiates an A10 connection termination with the source PCF 602 by sending an A11-Registration Update message. The source PDSN 108 starts a timer Tregupd. In step i, the source PCF 602 responds with an A11-registration acknowledgment message. The source PDSN 108 has stopped the timer Tregupd. all. In step j, the source PCF 602 sends to the PDSN 108 an A11-registration request message with accounting-related information and a lifetime set to zero. The source PCF 602 starts a timer Tregreq. In step k, the source PDSN 108 stores accounting-related information for further processing before returning an A11-registration response. The source PCF 602 terminates the A10 connection to the MS 202 . The source PCF 602 stops the timer Tregreq. In step 1, the target PCF 802 sends a registration lifetime timer (T) to re-register the A10 connection with the target PDSN 902._rp) before the A11-Registration Request message is sent. The A11-Registration Request message is also used to send other information related to accounting to the PDSN 902 . Other information related to accounting is transmitted to trigger points defined in the system. The target PCF 802 starts a timer (Tregreq). In step m, for a valid A11-registration request, the target PDSN 902 returns an A11-registration response message with an acceptance indication and a configured lifetime value. The target PDSN 902, before returning the A11-registration response, stores other information related to accounting (if received) for further processing. The target PCF 802 stops the timer Tregreq.</p><p>As described above, embodiments of the present invention supporting Common Channel Packet Data (CCPD) services in the CDMA2000 RAN provide a means for transmitting data between the network and the MS without using a traffic channel. Packet data sessions may be initiated, idle mode handoffs may be performed, and packet data may all be exchanged without using traffic channels. Also, once the MS has successfully registered with the network, A8 connection between PCF and PDSN is not required to support packet data service.</p><p>While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and have been described in detail herein. It should be understood, however, that the present invention is not limited to the specific form disclosed. Rather, the invention is intended to cover all modifications, equivalents and alternatives within the spirit and scope of the invention as defined by the following claims.</p>

<p>The present invention provides a method capable of supporting Common Channel Packet Data (CCPD) services in a CDMA2000 random access network without using a traffic channel.</p>