Apparatus and method for supporting common channel packet data service in a cdma2000 RAN

FIELD OF THE INVENTION

[0001] The invention relates to the field of communication systems, and more particularly, to a Code Division Multiple Access (CDMA) communications system.

BACKGROUND OF THE INVENTION

[0002] Data services are generally grouped into two categories: circuit-oriented (which includes Asynchronous Data and Group-3 Fax services) and packet. For calls that support packet data services, a Packet Data Serving Node (PDSN) serves as an interface between the transmission of data in a fixed network and the transmission of data over an air interface. The PDSN interfaces to a base system (BS) through a Packet Control Function (PCF), which may or may not be co-located with the BS.

[0003] As defined in the 3^rdGeneration Partnership Project 2; 3GPP2 Access Network Interfaces Interoperability Specification (hereinafter referred to as 3GPP2 A.S0001-A), which is herein incorporated by reference, there are three packet data service states: Active/Connected, Dormant, and Null/Inactive. (The 3GPP2 specification is the same in content as TIA/EIA/IS-2001-A June 2001.) When a MS station (MS) originates a packet data call to the current cdma2000 Radio Access Network (RAN), a traffic channel is allocated to establish a point-to-point protocol (PPP) connection and perform Mobile Internet protocol (IP) Registration procedures. Upon successful completion of these procedures, the MS's packet data service transitions from a Null to an Active/Connected state and the network and MS exchange packet data over a traffic channel. After a predefined period of inactivity, the MS's packet data service transitions from an Active to a Dormant state, however it may become Active again if the MS or network has data to send. Inter-PDSN Dormant mode handoffs also require the allocation of a traffic channel to support the setup of a new PPP connection and Re-Registration.

[0004] In the Active/Connected State, a physical traffic channel exists between a MS and a BS, and either unit may send data. In the Dormant State, no physical traffic channel exists between the MS and BS, but the PPP link between the MS and the PDSN is maintained. In the Null/Inactive State, there is no traffic channel between the MS and BS and there is no PPP link between the MS and the PDSN.

[0005] A1 through A11 interfaces are defined in Section 1.7.2 of 3GPP2 A.S0001-A. 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. As part of the support for the Dormant State, the cdma2000 air interface (TIA/EIA-IS-2000) supports a Data Ready to Send (DRS) indicator that is used on Origination. When a MS sends an origination request with a packet data service option specified, the request includes the DRS bit. This indicator is set to 1 on initial call setup when the MS wishes to transition from Dormant to Active because it has data to send and is requesting the establishment of a traffic channel. Subsequently, the DRS bit is set to 0 to indicate that the MS has transitioned a packet zone boundary (see section 2.14.1 of 3GPP2 A.S0001-A) while Dormant, and is sending the origination request to update the network as to its current location.

[0006] Upon receipt of an origination request with the DRS bit set to 1, the BS initiates the call setup procedure as shown in Section 2.14.7.1 of 3GPP2 A.S0001-A, which normally results in the establishment of a traffic channel and in the A8 and A10 bearer connections being established. The procedures for the A8 and A10 bearer connections are defined in 3GPP2 A.S0001 -A, Sections 2.14 and 2.15, respectively. When the BS receives an origination with the DRS bit set to 0, the BS delays the establishment of a traffic channel until after the A8 and A10 bearer connection establishment procedures are complete. During the A8 bearer connection establishment procedure, the BS indicates to the PCF that a DRS=0 has been received through the use of the Data Ready Indicator element in the A9-Setup-A8 message (as defined in Section 2.14.4.1.1. of 3GPP2 A.S0001-A). If the PCF has data from the network to deliver to the MS, it indicates this by setting the cause element in the A9-Connect-A8 message (as defined in Section 2.14.4.1.2 of 3GPP2 A.S0001-A) to the Data Ready to Send value. The BS then establishes a traffic channel to the MS and completes a normal call setup procedure as specified in Section 2.14.7.10 of 3GPP2 A.SO001-A. If the PCF does not have data, it indicates that the A8 connection is not being established by sending the A9-Release-A8 Complete message (as defined in Section 2.14.5.4 of 3GPP2 A.S0001-A) to the BS. The BS then returns an Assignment Failure message to the MSC with the cause value set to Packet Call Going Dormant. Upon receipt of the Assignment Failure message, the MSC returns a Clear Command to the BS with the cause value set to Do Not Notify Mobile. The BS sends a Clear Complete message to the MSC upon receipt of the Clear Command message.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0007[0007]FIG. 1 is a block diagram showing the relationship among network components in support of the apparatus and method for supporting CCPD service of the present invention.

P-0008[0008]FIG. 2 is a block diagram of the preferred embodiment of a process for a MS initiated CCPD call in accordance with the present invention.

P-0009[0009]FIG. 3 is a block diagram of the preferred embodiment of a process for a MS terminated packet data transfer to a CCPD device with the MS in a Dormant packet data state in accordance with the present invention.

P-0010[0010]FIG. 4 is a block diagram of the preferred embodiment of a process for a successful inter-PCF/intra-PDSN CCPD MS Dormant mode handoff in accordance with the present invention.

P-0011[0011]FIG. 5 is a block diagram of the preferred embodiment of a process for a successful inter-PCF/inter-PDSN CCPD MS Dormant mode handoff in accordance with the present invention.

P-0012[0012]FIG. 6 is a block diagram of the preferred embodiment of a process for the receipt of packet data from a PDSN and its SDB delivery to a MS in accordance with the present invention.

P-0013[0013]FIG. 7 is a block diagram of the preferred embodiment of a process for a MS initiated CCPD call wherein the BS and the PCF of FIG. 1 are configured as a single unit in accordance with the present invention.

P-0014[0014]FIG. 8 is a block diagram of the preferred embodiment of a process for CCPD MS inter-PCF Dormant handoff when the MS is served by the same PDSN in accordance with the present invention.

P-0015[0015]FIG. 9 is a block diagram of the preferred embodiment of a process for CCPD MS inter-PCF Dormant handoff when the MS is served by a new PDSN in accordance with the present invention.

P-0016[0016] DESCRIPTION OF THE PREFERRED EMBODIMENTS

P-0017[0017] The present invention proposes an apparatus and method for supporting common channel packet data (CCPD) services in a cdma2000 RAN without the use of a traffic channel. Packet data sessions may be initiated, Dormant mode handoffs performed, and packet data may be exchanged all without the use of traffic channels. Furthermore, an A8 connection between the PCF and PDSN is not required to support packet data service once the MS has successfully registered in the network. This invention may also be applied to current cdma2000 MSs to support Dormant mode handoffs and data transmission without the use of a traffic channel. The CCPD feature supports packet data call setup, Dormant mode handoff and data transmission using short data bursts (SDBs) over common channels.

P-0018[0018] The CCPD feature is required to support a CCPD device. A CCPD device is a data-only device that does not support cdma2000traffic channels. Any signaling or data to be exchanged between a CCPD device and the network must occur over cdma2000 common channels. Although the invention may be embodied in numerous types of CCPD devices, the invention is particularly suited for use in a MS. Thus, the preferred embodiment of the invention will be described with reference to a MS.

P-0019[0019] 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 Dormant mode handoffs. Since CCPD devices communicate over common channels rather than expensive traffic channels, these devices are relatively inexpensive to create both for the user and the network operator. Furthermore, due to their limited functionality, they are expected to be less expensive than currently available cdma2000 MSs. Potential applications for CCPD devices include: (1) telemetry—CCPD devices may be deployed at utility meters (water, electric gas); (2) vending machines—CCPD devices may be used to alert suppliers of low inventory; (3) auto/home security—CCPD devices may be used to alert authorities of a break in; (4) taxi meters; and (5) stock quotes. For simplicity of explanation, a MS that supports only CCPD services (does not support cdma2000 traffic channels) and a MS capable of supporting CCPD services and cdma2000 traffic channels is collectively referred to herein as a CCPD MS.

P-0020[0020]FIG. 1 is a block diagram showing the relationship among network components in support of the apparatus and method for supporting CCPD service of the present invention. As shown, a target BS <b>102</b> is coupled to a source BS <b>104</b> through an A3 interface <b>112</b> and an A7 interface <b>114</b> for the exchange of traffic and signaling information. The A3 and A7 interfaces <b>112</b>, <b>114</b>, respectively, are not particularly relevant to the present invention and are not further described herein. The source BS <b>104</b> is coupled to a PCF <b>106</b> through an A8 interface <b>116</b> and an A9 interface <b>118</b>. The A8 interface <b>116</b> is used to provide a path for user traffic between the base station controller (BSC) in the source BS <b>104</b> and the PCF <b>106</b> for packet data services. The A9 interface <b>118</b> is used to provide a signaling connection between the source BSC and the PCF <b>106</b> for packet data services. The PCF <b>106</b> is coupled to a PDSN <b>108</b> through an A10 interface <b>120</b> and an A11 interface <b>122</b>. The A10 interface <b>120</b> is used to provide a path for user traffic between the PCF <b>106</b> and the PDSN <b>108</b> for packet data services. The A11 interface <b>122</b> is used to provide a signaling connection between the PCF <b>106</b> and the PDSN <b>108</b> for packet data services. The MSC <b>110</b> is coupled to the source BS <b>104</b> through an Al interface <b>124</b>, an A2 i nterface <b>126</b> and an A5 interface <b>128</b>. The A1, A2 and A5 interfaces <b>124</b>,<b>126</b>,<b>128</b>, respectively, are not particularly relevant to the present invention and are not further described herein.

P-0021[0021] Messages and data between the network and a CCPD MS are exchanged over common channels encapsulated in SDBs. This includes PPP Connection, MIP Registration, and Packet data. A BS may initiate CCPD service for a CCPD MS even though the MS may not have explicitly requested the service by setting the SDB_DESIRED_ONLY bit to 1 in the Origination message. This could be used for Dormant mode handoffs. The BS may do this by responding to the MS's Origination with a SDB over the common channel rather than assigning a traffic channel for the call. Subsequent communication between the MS and the network would occur using SDBs over common channels.

P-0022[0022] A CCPD device requests CCPD service from the network by sending an Origination message to the BS with the SDB_DESIRED_ONLY bit set to 1 and the FCH_SUPPORTED bit and DCCH_SUPPORTED bits set to 0. Upon successful authentication of the device, a PPP connection setup and Mobile IP Registration are performed using SDBs over common channels to exchange the messages. The first SDB sent to the CCPD device by the BS serves as an acknowledgement to the device's request for CCPD service. If the BS is unable to support the CCPD service request from the CCPD device, no SDB is sent and the call attempt fails. The CCPD device may resend the CCPD service request.

P-0023[0023] A CCPD MS may request CCPD service from the network by sending an Origination message to the BS with the SDB_DESIRED_ONLY bit, FCH_SUPPORTED bit and DCCH_SUPPORTED bit set to 1. If the BS agrees to support a MS's request for CCPD Service, the MS is first authenticated. Upon successful authentication of the MS, the PCF is informed that CCPD services are being used for the call. PPP connection setup and Mobile IP Registration (if required) are performed using SDBs over common channels to exchange the messages. Messages and data between the BS and PCF are passed over the A9 signaling channel. The first SDB sent to the CCPD MS serves as an acknowledgment for the request for CCPD service. The network may also deny a CCPD MS's request for CCPD services and apply normal packet data procedures to setup the packet data call or transmit packet data. Upon the successful completion of PPP Connection and Mobile IP Registration, the CCPD MS's packet data service transitions from a Null/Inactive state to a Dormant state and the A8 connection between the BS and PCF is released.

P-0024[0024] In a first aspect of the present invention, the preferred embodiment of a process for a MS initiated CCPD call is provided. When a CCPD MS <b>202</b> initiates a packet data call and Mobile IP Registration has not been performed, a PPP connection setup and Mobile IP Registration are performed using SDBs over common channels. Once the PPP connection setup and Mobile IP Registration have been completed, packet data may be exchanged between the MS <b>202</b> and the network using SDBs over common channels. All messages specifying SDB format are as specified in chapter 12, section 2.2.10 of TIA/EIA/ IS-707-A-2; Ballot Resolution Version; June, 2000 (IS-707A-2).

P-0025[0025] Referring to FIG. 2, at step a, the CCPD MS <b>202</b> transmits an Origination Message to the BS <b>104</b> over the access channel of the air interface with Layer <b>2</b> acknowledgment required to request packet data service. The MS <b>202</b> indicates its desire for CCPD service to the network by setting the SDB_DESIRED_ONLY bit in the message to 1. At step b, the BS <b>104</b> acknowledges receipt of the Origination Message by sending a Base Station Acknowledgment Order to the CCPD MS <b>202</b>. At step c, the BS <b>104</b> sends an ADDS Transfer message (described in section 2.6.2.2 of 3GPP2 A.S0001-A) to the MSC <b>110</b>. The message contains the authentication parameters received from the CCPD MS <b>202</b>, the BS computed authentication data element, and the data burst type field of the ADDS User Part element set to SDB. The BS <b>104</b> starts timer T<b>60</b>. If the MS <b>202</b> supports traffic channels and the BS <b>104</b> decides not to support the request for CCPD services, the call is treated as a normal MS originated packet data call (as specified in section 2.14.7.1 of 3GPP2 A.S0001-A). If the BS <b>104</b> is unable to support the CCPD Service request from a CCPD device, the call fails.

P-0026[0026] At step d, the MSC <b>110</b> sends the result of authentication for the MS <b>202</b> back to the BS <b>104</b> in the ADDS Transfer Ack message (described in section 2.14.8.1.2 of 3GPP2 A.S0001-A). At step e, the BS <b>104</b> sends an A9-Setup-A8message (described in section 2.14.4.1.1 of 3GPP2 A.S001-A) to the PCF <b>106</b> to initiate PPP connection setup and mobile IP registration (if required) procedures for the CCPD MS <b>202</b>. The BS <b>104</b> sets the CCPD Service bit in the message to 1 to indicate to the PCF <b>106</b> that an A8 connection is not required. If the MS <b>202</b> is a CCPD device, the BS <b>104</b> sets the CCPD bit in the message to <b>1</b> to indicate to the PCF <b>106</b> that the data session is for a CCPD device. The BS <b>104</b> then starts timer TA8-Setup. At step f, the A10/A11 connection establishment procedure is performed. At step g, upon establishment of the A10/A11 connection, the PDSN <b>108</b> and the CCPD MS <b>202</b> exchange messages over the air using SDBs over common channels to set up the PPP connection and perform MIP registration (if required). All messages exchanged between the network and MS <b>202</b> are in SDB format. The PCF <b>106</b> formats messages for the MS <b>202</b> into SDB format before sending them to the BS <b>104</b>. The BS <b>104</b> sends messages from the MS <b>202</b> to the PCF <b>106</b> in SDB format. The PCF <b>106</b> converts the messages into packet data format before transmitting the data to the PDSN <b>108</b>. The first SDB sent from the BS <b>104</b> to the MS <b>202</b> serves as an acknowledgment to the MS's request for CCPD service. At step h, the PCF <b>106</b> sends an A9-Release-A8 complete message (described in section 2.14.5.4 of 3GPP2 A.S0001-A) to the BS <b>104</b> with a successful cause value. The BS <b>104</b> stops timer TA<b>8</b>-setup. At step i, the MS <b>202</b> sends its packet data in a SDB over the common channel to the BS <b>104</b>.

P-0027[0027] At step j, the BS <b>104</b> acknowledges receipt of the SDB from the MS <b>202</b> by sending a BS Ack order to the MS <b>202</b>. At step k, the BS <b>104</b> sends an A9-Short Data Delivery message containing the packet data in SDB format to the PCF <b>106</b>. At step <b>1</b>, the PCF <b>106</b> sends the data to the PDSN <b>108</b> as normal packet data. At step m, the PCF <b>106</b> sends an A-<b>11</b> Registration request message (described in section 3.3 of Network Working Group; Request for Comments: 2002; C. Perkins, Editor; IBM; October 1996 and section 6.1.11.1 of 3GPP2 A.S0001-A) with the SDB Airlink record (described in section 2.15.4.4 of 3GPP2 A.S0001-A) for accounting to the PDSN <b>108</b>. At step n, the PDSN <b>108</b> responds with an A11 Registration Reply message (described in section 3.4 of Network Working Group; Request for Comments: 2002; C. Perkins, Editor; IBM; October 1996 and section 6.1.11.2 of 3GPP2 A.S0001-A) to the PCF <b>106</b>.

P-0028[0028] In a second aspect of the present invention, a preferred embodiment of a process for a MS terminated packet data transfer to a CCPD device with the MS <b>202</b> in a Dormant packet data state is provided. If the network has data to send to a Dormant CCPD device, the PCF <b>106</b> sends the data to the BS <b>104</b> in the A9-Short Data Delivery message. The PCF <b>106</b> is informed that the MS <b>202</b> is a CCPD device at the time the MS <b>202</b> initiates a CCPD Service Request to the network. Since the data is for a CCPD device, the PCF <b>106</b> does not need to buffer the data for the MS <b>202</b>, and therefore does not require an acknowledgement from the BS <b>104</b> after the data has been sent. The BS <b>104</b> sends the data to the CCPD device in SDBs as specified in IS-707-A-2. If the BS <b>104</b> does not receive an acknowledgement from the MS <b>202</b> after sending the SDB to the MS, the BS <b>104</b> may retry sending the data and/or invoke ADDS Procedures to deliver the data. See section 2.14.8.6 of 3GPP2 A.S0001-A for the ADDS procedure.

P-0029[0029]FIG. 3 shows the logical flow for the preferred embodiment of a process for a MS terminated packet data transfer to a CCPD device with the MS <b>202</b> in a Dormant packet data state. The PCF <b>106</b> has been informed that the MS <b>202</b> is a CCPD Device during the initial packet data session setup. All messages specifying SDB format are as specified in IS-707-A-2. At step a, PPP connection setup and Mobile IP Registration have previously been performed between the network and the MS <b>202</b>. The CCPD MS <b>202</b> is currently in a Dormant packet data service state. At step b, the PDSN <b>108</b> sends packet data from the network for the CCPD MS <b>202</b>. At step c, the PCF <b>106</b> sends the packet data in SDB format in the A9-Short Data Delivery message to the BS <b>104</b>. At step d, the BS <b>104</b> sends the packet data to the CCPD MS <b>202</b> in a SDB over the common channel. At step e, the MS <b>202</b> acknowledges receipt of the SDB by sending a layer <b>2</b> ack to the BS <b>104</b>. If a layer<b>2</b> ack is not received from the MS <b>202</b>, the BS <b>104</b> may resend the SDB to the MS <b>202</b>. Alternatively, the BS <b>104</b> may use the ADDS procedure to deliver the SDB to the MS <b>202</b>.

P-0030[0030] At step f, the BS <b>104</b> sends an A9-Update-A8 message (described in section 2.14.5.6 of 3GPP2 A.S0001-A) to the PCF <b>106</b> to indicate the successful transmission of the SDB to the MS <b>202</b>. The BS <b>104</b> starts timer Tupd<b>9</b>. At step g, the PCF <b>106</b> sends an A-<b>11</b> Registration Request message with the SDB Airlink record for accounting to the PDSN <b>108</b>. At step h, the PDSN <b>108</b> responds with an A11 Registration Reply message to the PCF <b>106</b>. At step i, the PCF <b>106</b> responds to the BS <b>104</b> with an A9-Update-A8 Ack message (described in section 2.14.5.7 of 3GPP2 A.S0001A). Upon receipt of this message, the BSC stops timer Tupd<b>9</b>.

P-0031[0031] Third and fourth aspects of the present invention provide Dormant handoff procedures for CCPD MSs. Upon detection of a new packet zone identifier (PZID), system identifier (SID), or network identifier (NID) a CCPD MS sends an Origination message to the BS <b>104</b> with the SDB_DESIRED_ONLY bit set to 1. 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. If as a result of the Dormant mode handoff a new PDSN is selected for the call, a PPP connection is setup and Mobile IP Registration is performed using SDBs over common channels. Note, the BS <b>104</b> may refuse a CCPD MS's request for CCPD service by applying normal packet data Dormant mode handoff procedures.

P-0032[0032] The BS may also initiate CCPD service for a CCPD MS which has no data to send, even though the MS may not have explicitly requested CCPD service from the BS by setting the SDB_DESIRED_ONLY bit to 1 in the Origination message. The BS may optionally use this procedure to support Dormant mode handoffs (e.g. if a traffic channel is not available). Upon detection of a new PZID, SID, or NID, a CCPD MS sends an Origination message to the BS with the SDB_DESIRED _ONLY bit set to 0, and the DRS bit set to 0. Instead of initiating the normal Dormant mode handoff procedures, the BS authenticates the MS and informs the PCF that CCPD Service shall be used to support the Dormant mode handoff. The first SDB sent to the MS indicates that CCPD procedures shall be used to support the Dormant mode handoff. Subsequent communication between the MS and the network occurs using SDB over common channels.

P-0033[0033] Referring to the third aspect of the present invention, a process for a successful inter-PCF/intra-PDSN CCPD MS Dormant mode handoff is provided. It is assumed that the PCF is uniquely identified by the Current Access Network Identifiers (CANID). Upon detection of a new PZID, NID or SID, the CCPD MS sends an Origination Message to the target BS with the packet data service option and the SDB_DESIRED_ONLY bit set to 1. If the call is from a CCPD device, the FCH_SUPPORTED bit and DCCH_SUPPORTED bit are also set to 0. The Origination Message includes the previous PZID, NID and SID when any of these parameters change during the Dormant handoff. Based on the IDs (PZID, NID and/or SID) in the Origination Message, the target PCF sends the Previous Access Network Identifiers (PANID) of the source PCF and the CANID of the target PCF to the serving PDSN. The serving PDSN uses this information to determine if Mobile IP Registration is required. All messages specifying SDB format in the process are as specified in IS-707-A-2. This process may also be used if the network decides to use CCPD Service for the Dormant mode handoff. In such a case, the MS sends an Origination message with the SDB_DESIRED_ONLY bit set to 0. The first SDB sent to the MS indicates that CCPD procedures shall be used to support the Dormant mode handoff.

P-0034[0034] Referring to FIG. 4, the preferred embodiment of the process for a successful inter-PCF/intra-PDSN CCPD MS Dormant mode handoff is provided. At step a, the CCPD MS <b>202</b> has previously performed PPP connection establishment and MIP Registration with the PDSN <b>108</b> and is in the Dormant state. At step b, the CCPD MS <b>202</b> detects a change of PZID, SID or NID while monitoring the broadcast channel and sends an Origination message with the SDB_DESIRED_ONLY bit set to 1. At step c, the target BS <b>102</b> acknowledges receipt of the Origination message with a Base Station Acknowledgement Order to the CCPD MS <b>202</b>. At step d, the target BS <b>102</b> sends an ADDS Transfer message to the MSC <b>110</b> containing the authentication parameters received from the MS <b>202</b>, the BS computed authentication data element and the data burst type field of the ADDS User Part element set to SDB. If the BS <b>102</b> determines that the CCPD MS <b>202</b> supports traffic channels, the BS <b>102</b> may alternatively execute the MS Dormant mode handoff procedure described in section 2.14.7.9 of 3GPP2 A.S0001-A. The target BS <b>102</b> starts timer T<b>60</b>. At step e, the MSC <b>110</b> sends the ADDS Transfer Ack message to the target BS <b>102</b> with no cause value present. The target BS <b>102</b> cancels timer T<b>60</b>. If authentication of the MS <b>202</b> fails, the MSC <b>110</b> includes a cause value set to ‘authentication failure’ in the message and the CCPD call fails.

P-0035[0035] At step f, the target BS <b>102</b> sends an A9-Setup-A8 message, with Data Ready Indicator and Handoff Indicator bits set to 0, to the target PCF <b>402</b>. The BS <b>102</b> sets the CCPD Service bit in the message to 1 to indicate to the PCF <b>402</b> that an A8 connection is not required. If the MS <b>202</b> is a CCPD device, the target BS <b>102</b> sets the CCPD bit in the message to 1 to indicate to the target PCF <b>402</b> that the data session is for a CCPD MS <b>202</b>. The target BS <b>102</b> starts timer TA<b>8</b>-setup. At step g, the target PCF <b>402</b> establishes an A10/A11 link with the PDSN <b>108</b>. The PDSN <b>108</b> disconnects the A10/A11 link with the source PCF <b>106</b>. If the PDSN <b>108</b> has data for the MS <b>202</b>, it responds to the PCF <b>402</b> with a Registration Reply message with the Data Available Indicator in the Vendor/Organization Specific Extension (described in section 6.2.2.166 of 3GPP2 A.S0001-A).

P-0036[0036] At step h, the target PCF <b>402</b> sends an A9-Release A8 Complete message to the target BS <b>102</b> with a successful cause value. The target BS <b>102</b> cancels timer TA<b>8</b>-setup. At step i, if the PDSN <b>108</b> has data from the network for the CCPD MS <b>202</b>, the target PCF <b>402</b> sends the data in SDB format in the A9-Short Data Delivery message to the BS <b>102</b>. If the MS <b>202</b> supports traffic channels, the PCF <b>402</b> buffers the data and follows the procedure for Short Data Delivery from the PCF <b>402</b> to the MS <b>202</b> (see 2.14.8.6/7 of 3GPP2 A.S0001-A for the process). If the data is for a CCPD MS <b>202</b>, the PCF <b>402</b> discards the data. At step j, if the PCF <b>402</b> sent data for the MS <b>202</b> in the A9-Short Data Delivery message to the target BS <b>102</b>, the BS <b>102</b> sends the data in a SDB to the MS <b>202</b>. The SDB serves as an acknowledgement for CCPD service from the BS <b>102</b>. If no data was sent from the PCF <b>402</b>, an empty SDB is sent to the MS <b>202</b>. At step k, the CCPD MS <b>202</b> acknowledges receipt of the SDB by sending a layer <b>2</b> ack to the BS <b>102</b>. If data was sent in the SDB, the A9 update procedure for Accounting (as shown in section 2.14.9.2 of 3GPP2 A.S0001-A) is performed.

P-0037[0037] Referring to the fourth aspect of the present invention, a process for a successful inter-PCF/inter-PDSN CCPD MS Dormant mode handoff is provided. When a MS in Dormant state moves into a different packet zone and ends up being Connected to a different PDSN, the target PCF is required to forward the Access Network Identifiers (ANID) of the source PCF (PANID) and the ANID of the target PCF (CANID) to the serving PDSN. PPP connection setup and Mobile IP Registration are performed using SDBs over common channels. All messages specifying SDB format in the process are as specified in IS-707-A-2. The process may also be used if the network decides to use CCPD Service for the Dormant mode handoff. In such a case, the MS sends an Origination message with SDB_DESIRED_ONLY bit set to 0. The first SDB sent to the MS indicates that CCPD procedures shall be used to support the Dormant mode handoff.

P-0038[0038] Referring to FIG. 5, the preferred embodiment of the process for a successful inter-PCF/inter-PDSN CCPD MS Dormant mode handoff is provided. At step a, the CCPD MS <b>202</b> detects a change of PZID while monitoring the broadcast channel and sends an Origination message with the SDB_DESIRED_ONLY bit set to 1. At step b, the target BS <b>102</b> acknowledges receipt of the Origination message with a BS Ack order to the CCPD MS <b>202</b>. At step c, the BS <b>102</b> sends an ADDS Transfer message to the MSC <b>110</b>. The message contains the authentication parameters received from the MS <b>202</b>, the BS computed authentication data element, and the data burst type field of the ADDS User Part element set to SDB. If the BS <b>102</b> determines that the CCPD MS <b>202</b> supports traffic channels, the BS <b>102</b> may alternatively execute the MS Dormant mode handoff procedure described in section 2.14.7.9 of 3GPP2 A.S0001-A. The target BS <b>102</b> starts timer T<b>60</b>. At step d, the MSC <b>110</b> sends the ADDS Transfer Ack message to the target BS <b>102</b> with no cause value present. The target BS <b>102</b> cancels timer T<b>60</b>. If authentication of the MS <b>202</b> fails, the MSC <b>110</b> includes a cause value set to ‘authentication failure’ in the message and the CCPD call fails.

P-0039[0039] At step e, the target BS <b>102</b> sends an A9-Setup-A8 message to the target PCF <b>402</b> with Data Ready Indicator and Handoff Indicator bits set to 0. The BS <b>102</b> sets the CCPD Service bit in the message to <b>1</b> to indicate to the PCF than an A8 connection is not required. If the MS <b>202</b> is a CCPD device, the BS <b>102</b> also sets the CCPD bit in the message to 1 to indicate to the PCF <b>402</b> that the data session is for a CCPD MS <b>202</b>. The BS <b>102</b> starts timer TA<b>8</b>-setup. At step f, the procedure for establishing A10/A11 is performed. At step g, upon establishment of the A10/A11 connection, the PDSN <b>108</b> and the CCPD MS <b>202</b> 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 MS <b>202</b> are in SDB format. The PCF <b>402</b> formats messages for the MS <b>202</b> into SDB format before sending them to the BS <b>102</b>. The BS <b>102</b> sends messages from the MS <b>202</b> to the PCF <b>402</b> in SDB format. The PCF <b>402</b> converts the messages into packet data format before transmitting the data to the PDSN <b>108</b>. The first SDB sent from the BS <b>102</b> to the MS <b>202</b> serves as an acknowledgment to the MS's request for CCPD service. At step h, the PCF <b>402</b> sends an A9-Release-A8 complete message to the BS <b>102</b> with a successful cause value. The BS <b>102</b> stops timer TA<b>8</b>-Setup. If the call is for a CCPD Capable MS <b>202</b> and the PDSN <b>108</b> has data for the MS <b>202</b>, depending on the amount of data, the PCF <b>402</b> may respond to the BS <b>102</b> with cause value indicating failure, followed by a network initiated call reactivation.

P-0040[0040] A fifth aspect of the present invention provides a preferred embodiment of a process for the receipt of packet data from a PDSN and its SDB delivery to a MS. In this embodiment, the BS and the PCF as shown in FIG. 1 are configured as a single unit. Referring to FIG. 6, at step a, the PCF <b>602</b> receives packet data from the PDSN <b>108</b> and determines that this data can be delivered to the Dormant packet data service instance. The BS <b>602</b> may send a SDB directly to the MS <b>202</b>. If the received data is for a CCPD device, the packet data shall always be sent to the MS <b>202</b> in a SDB. At step b, the MS <b>202</b> sends a layer <b>2</b> acknowledgement in response to the SDB from the BS <b>602</b>. If a layer <b>2</b> ack is not received from the MS <b>202</b>, the BS <b>602</b> may attempt to re-send the data to the MS <b>202</b>. At step c, alternatively, the BS <b>602</b> may send the data in SDB format as specified in IS-707-A-2 to the MSC <b>110</b> in the BS Service Request message. The BS <b>602</b> sets timer T<b>311</b>. If timer T<b>311</b> expires, the SDB information will not be sent to the MS <b>202</b>. This step may also occur if the BS <b>602</b> fails to successfully deliver the SDB to the MS <b>202</b>. At step d, the MSC <b>110</b> acknowledges the reception of the BS Service Request message by sending a BS Service Response message to the BS <b>602</b>. The BS <b>602</b> cancels timer T<b>311</b>. At step e, the MSC <b>110</b> sends an ADDS Page message to the BS <b>602</b> with the data burst type field in the ADDS User Part element set to SDB, and the SDB in the Application Data Message field. The BS <b>602</b> forwards the SDB on to the MS <b>202</b>.

P-0041[0041] At step f, the MS <b>202</b> sends a layer <b>2</b> acknowledgement after receiving the SDB from the BS <b>602</b>. If the MSC <b>110</b> included a Tag element in the ADDS Page message, the BS <b>602</b> will return an ADDS Page Ack message to the MSC <b>110</b> after receiving the layer <b>2</b> ack from the MS <b>202</b>. The Tag element received from the MSC <b>110</b> is included in the message. At step g, the BS/PCF <b>602</b> sends an A11-Registration Request with the SDB Airlink record to the PDSN <b>108</b>. At step h, the PDSN <b>108</b> responds with the A11-Registration Reply message.

P-0042[0042] A sixth aspect of the present invention provides a preferred embodiment of a process for a MS initiated CCPD call. In this embodiment, the BS and the PCF as shown in FIG. 1 are configured as a single unit. 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 over common channels. Once a PPP connection is setup, packet data is exchanged between the MS and the network with SDBs over common channels.

P-0043[0043] Referring to FIG. 7, a flow diagram of the preferred embodiment of the process for a MS initiated CCPD call is shown. At step a, a MS <b>202</b> transmits an Origination Message to the BS <b>602</b> over the access channel of the air interface with Layer <b>2</b> acknowledgment required to request packet data service. The MS <b>202</b> indicates its desire for CCPD service to the network by setting the SDB_DESIRED_ONLY bit in the message to 1. At step b, the BS <b>602</b> acknowledges the receipt of the Origination Message with a Base Station Ack Order to the MS <b>202</b>. At step c, the BS <b>602</b> sends an ADDS Transfer message to the MSC <b>110</b>. The ADDS Transfer message contains the authentication parameters received from the CCPD MS <b>202</b>, the BS computed authentication data element, and the data burst type field of the ADDS User Part element is set to SDB. The BS <b>602</b> starts timer T<b>60</b>. If the MS <b>202</b> supports traffic channels and the BS <b>602</b> decides not to support the CCPD Services request, the call is treated as a normal MS originated packet call setup (as specified in section 2.15.5.1 of 3GPP2 A.S0001-A). If the BS <b>602</b> is unable to support the CCPD service request from a CCPD device, the call fails.

P-0044[0044] At step d, the MSC <b>110</b> sends the result of authentication for the CCPD MS <b>202</b> back to the BS <b>602</b> in the ADDS Transfer Ack message. At step e, the PCF <b>602</b> recognizes that no Al <b>0</b> connection associated with the MS <b>202</b> is available and selects a PDSN <b>108</b> for the call. The PCF <b>602</b> sends an A11-Registration Request message to the selected PDSN <b>108</b> and starts timer Tregreq. At step f, the A11-Registration Request is validated and the PDSN <b>108</b> accepts the connection by returning an A11-Registration Reply message with an accept indication and the Lifetime field set to the configured T_rpvalue. The PCF <b>602</b> stops timer Tregreq.

P-0045[0045] At step g, the MS <b>202</b> and the PDSN <b>108</b> exchange SDBs over common channels to establish the link layer (PPP) connection and then perform MIP registration procedures (if required). The first SDB sent from the BS <b>602</b> to the MS <b>202</b> serves as an acknowledgement to the MS's request for CCPD services. At step h, the MS <b>202</b> sends its data in a SDB over the common channel to the BS <b>602</b>. At step i, the BS <b>602</b> acknowledges receipt of the SDB from the MS <b>202</b> by sending a BS Ack order to the MS <b>202</b>. At step j, the PCF <b>602</b> sends the packet data to the PDSN <b>108</b>. At step k, the PCF <b>602</b> sends an A11-Registration Request message with an SDB Airlink record to the PDSN <b>108</b>. At step <b>1</b>, the PDSN <b>108</b> updates the accounting data and responds to the PCF <b>602</b> with an A11 Registration Reply.

P-0046[0046] A seventh aspect of the present invention provides a preferred embodiment of a process for CCPD MS inter-PCF Dormant handoff when the MS is served by the same PDSN. In order to obtain packet data services, a CCPD MS performed registration with the packet network. Both the A10 connection and the link layer (PPP) connection are maintained. The source PCF continues to perform re-registrations for the A10 connection with the PDSN by the exchange of A11-Registration Request and A11-Registration Reply messages before expiration of A10 connection Lifetime timer T_rp. While in the Dormant mode, the CCPD MS detects a change of PZID, SID or NID. Upon detection of a new PZID, SID or NID, the MS sends an Origination Message to the target BS <b>102</b> with a packet data service option and the SDB_DESIRED_ONLY bit set to 1. If the call is for a CCPD device, the FCH_SUPPORTED bit and DCCH_SUPPORTED bit are also set to 0. The Origination Message includes the previous PZID, SID and NID when any of these parameters change during the Dormant handoff. The target PCF establishes an A10 connection with the PDSN. Based on the IDs (PZID, NID and/or SID) in the Origination Message, the target PCF sends the PANID of the source PCF and the CANID of target PCF to the serving PDSN. The serving PDSN uses this information to determine whether Mobile IP registration is required. If the PDSN has data, the PDSN returns the ‘Data Available Indicator’ in the Vendor/Organization Specific Extension within the Registration Reply to the BS/PCF. The source PDSN releases the A10 connection with the source PCF.

P-0047[0047] The process described may also be used if the network decides to initiate CCPD Service for the Dormant mode handoff. In such a case, the MS sends an Origination message with the SDB_DESIRED_ONLY bit set to 0. The first SDB sent to the MS indicates that CCPD procedures will be used to support the Dormant mode handoff.

P-0048[0048] Referring to FIG. 8, a flow diagram of the preferred embodiment of the process for CCPD MS inter-PCF Dormant handoff is shown. In this embodiment, the source BS and source PCF are configured as a single unit. The target BS and target PCF are also configured as a single unit. The process assumes that the CCPD MS <b>202</b> has previously performed PPP connection establishment and Mobile IP Registration with the PDSN <b>108</b> and is currently maintaining a Dormant packet data service instance. At step a, upon detection of a new Packet Zone ID, a CCPD MS <b>202</b> sends an Origination Message with the SDB_DESIRED_ONLY bit set to 1. At step b, the target BS <b>602</b> acknowledges receipt of the Origination Message with a BS Ack Order to the MS <b>202</b>. At step c, the BS sends an ADDS Transfer message to the MSC <b>110</b>. The message contains the authentication parameters received from the MS <b>202</b>, the BS computed authentication data element, and the data burst type field of the ADDS User Part element set to SDB. If the BS determines that the CCPD MS <b>202</b> supports traffic channels, it may alternatively execute the MS Dormant mode handoff procedure described in section 2.15.5.8 of 3GPP2 A.S0001-A. The target BS <b>802</b> starts timer T<b>60</b>. At step d, the MSC <b>110</b> sends the ADDS Transfer Ack message to the target BS <b>802</b> with no cause value present. The target BS <b>802</b> cancels timer T<b>60</b>. If authentication of the MS <b>202</b> fails, the MSC <b>110</b> includes a cause value set to ‘authentication failure’ in the message and the CCPD call fails.

P-0049[0049] At step e, the target PCF <b>802</b> sends an A11-Registration Request message to the PDSN <b>108</b>. The Registration Request message includes the Mobility Event Indicator within the Vendor/Organization Specific Extension. The PCF starts timer Tregreq. At step f, the A11-Registration Request is validated and the PDSN <b>108</b> accepts the connection by returning an A11 Registration Reply with an accept indication. If the PDSN <b>108</b> has data to send, it includes the Data Available Indicator within the Vendor/Organization Specific Extension. If the data is for a CCPD capable MS <b>202</b>, a network initiated call re-origination may occur. The A10 connection binding information at the PDSN <b>108</b> is updated to point to the target PCF <b>802</b>. The target PCF <b>802</b> stops timer Tregreq. At step g, the BS sends an empty SDB to the CCPD MS <b>202</b> to acknowledge acceptance of the CCPD service request. If the PDSN <b>108</b> sent data for the MS <b>202</b>, the data is included in the SDB. At step h, the CCPD MS <b>202</b> responds with a layer <b>2</b> ack to acknowledge receipt of the SDB. The MS's packet data service instance resumes a Dormant state. If the network or MS <b>202</b> has any data to send, the data may be sent using SDBs over common channels using the CCPD procedures.

P-0050[0050] At step i, the PDSN <b>108</b> initiates closure of the A10 connection with the source PCF <b>602</b> by sending an A11-Registration Update message. The PDSN <b>108</b> starts timer Tregupd. At step j, the source PCF <b>602</b> responds with an A11-Registration Acknowledge message. The PDSN <b>108</b> stops timer Tregupd. At step k, the source PCF <b>602</b> sends an A11-Registration Request message to the PDSN <b>108</b> with Lifetime set to zero. The PCF starts timer Tregreq. At step <b>1</b>, the PDSN <b>108</b> sends the A11-Registration Reply message to the source PCF <b>602</b>. The source PCF <b>602</b> closes the A10 connection for the MS <b>202</b>. The source PCF <b>602</b> stops timer Tregreq. At step m, the target PCF <b>802</b> sends an A11-Registration Request message to the PDSN <b>108</b> before expiration of the registration Lifetime timer (T_rp) for refreshing registration of the A10 connection with the PDSN <b>108</b>. The A11-Registration Request message is also used to send accounting related and other information to the PDSN <b>108</b>. The accounting related and other information is sent at system defined trigger points. The PCF starts timer Tregreq.

P-0051[0051] At step n, for a validated A11-Registration Request, the PDSN <b>108</b> returns an A11-Registration Reply message with an accept indication and a configured Lifetime value. The PDSN <b>108</b> stores the accounting data (if received) for further processing, before returning the A11-Registration Reply. The PCF stops timer Tregreq.

P-0052[0052] An eighth aspect of the present invention provides a preferred embodiment of a process for CCPD MS inter-PCF Dormant handoff when the MS is served by a new PDSN. While the packet data session is in Dormant mode, the MS detects a change of PZID, SID or NID. Upon detection of a new, PZID, SID, or NID, the MS sends an Origination Message to the target BS that includes the packet data service option and the SDB_DESIRED_ONLY bit set to 0. If the call is for a CCPD device, the FCH_SUPPORTED bit and DCCH_SUPPORTED bit are also set to zero. The target PCF establishes an A10 connection with the target PDSN. The target PCF is required to forward the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. PPP Connection Setup and Mobile IP Registration occur using SDBs over the common channels. The source PDSN releases the A10 connection with the source PCF upon expiration of the MIP registration timer. The target PCF periodically reregisters with the PDSN by the use of A11-Registration Request message before the A10 connection Lifetime expires.

P-0053[0053] The described process may also be used if the network decides to initiate CCPD service for the Dormant mode handoff. In such a case, the MS sends an Origination message with the SDB_DESIRED_ONLY bit set to 0. The first SDB sent to the MS indicates that CCPD procedures will be used to support the Dormant mode handoff.

P-0054[0054] Referring to FIG. 9, a flow diagram of the preferred embodiment of the process for CCPD MS inter-PCF Dormant handoff when the MS <b>202</b> is served by a new PDSN <b>902</b> is shown. In this embodiment, the source BS and source PCF are configured as a single unit. The target BS and target PCF are also configured as a single unit. The process assumes that the CCPD MS <b>202</b> has previously performed PPP connection establishment and Mobile IP Registration with the PDSN <b>904</b> and is currently maintaining a Dormant packet data service instance. At step a, upon detection of a new PZID, the CCPD MS <b>202</b> sends an Origination Message to the target BS <b>802</b> with the SDB_DESIRED_ONLY bit set to 1. At step b, the target BS <b>802</b> acknowledges the receipt of the Origination Message by sending a BS Ack Order to the MS <b>202</b>. At step c, the BS <b>802</b> sends an ADDS Transfer message to the MSC <b>110</b>. The message contains the authentication parameters received from the MS <b>202</b>, the BS computed authentication data element, and the data burst type field of the ADDS User Part element set to SDB. If the target BS <b>802</b> determines that the CCPD MS <b>202</b> supports traffic channels, the target BS <b>802</b> may alternatively execute the MS Dormant mode handoff procedure as described in section 2.15.5.9 of 3GPP2 A.S0001-A. The target BS <b>802</b> starts timer T<b>60</b>.

P-0055[0055] At step d, the MSC <b>110</b> sends the ADDS Transfer Ack message to the target BS <b>802</b> with no cause value present. The target BS <b>802</b> cancels timer T<b>60</b>. If authentication of the MS <b>202</b> fails, the MSC <b>110</b> includes a cause value set to ‘authentication failure’ in the message. At step e, the target PCF <b>802</b> initiates establishment of the A10 connection by sending an A11 Registration Request message to the target PDSN <b>902</b>. The Registration Request message includes the Mobility Event Indicator within the Vendor/Organization Specific Extension. The PCF <b>802</b> starts timer Tregreq. At step f, the A11-Registration Request is validated and the target PDSN <b>902</b> accepts the connection by returning an A11-Registration Reply with an accept indication and Data Available Indicator within the Vendor/Organization Specific Extension. The PCF <b>802</b> stops timer Tregreq.

P-0056[0056] At step g, the MS <b>202</b> and the target PDSN <b>902</b> exchange SDBs over common channels to establish the link layer (PPP) connection and then perform MIP registration procedures over the link layer (PPP) connection. The first SDB sent from the BS <b>802</b> to the MS <b>202</b> serves as an acknowledgement to the MS's request for CCPD services. The MS's packet data service instance resumes a Dormant state. If the network or MS <b>202</b> has any data to send, the data is sent using SDBs over common channels using the CCPD procedures.

P-0057[0057] At step h, upon expiration of the MIP registration timer, the source PDSN <b>108</b> initiates closure of the A10 connection with the source PCF <b>602</b> by sending an A11-Registration Update message. The source PDSN <b>108</b> starts timer Tregupd. At step i, the source PCF <b>602</b> responds with an A11 Registration Acknowledge message. The source PDSN <b>108</b> stops timer Tregupd. At step j, the source PCF <b>602</b> sends an A11-Registration Request message to the source PDSN <b>108</b> with accounting related information and with Lifetime set to zero. The source PCF <b>602</b> starts timer Tregreq. At step k, the source PDSN <b>108</b> stores the accounting related information for further processing before returning A11-Registration Reply message. The source PCF <b>602</b> closes the A10 connection for the MS <b>202</b>. The source PCF <b>602</b> stops timer Tregreq. At step <b>1</b>, the target PCF <b>802</b> sends A11-Registration Request message before expiration of registration Lifetime timer (T_rp) for refreshing registration for the A10 connection with the target PDSN <b>902</b>. A11-Registration Request message is also used to send accounting related and other information to the target PDSN <b>902</b>. The accounting related and other information is sent at system defined trigger points. The target PCF <b>802</b> starts timer Tregreq. At step m, for a validated A11-Registration Request, the target PDSN <b>902</b> returns an A11-Registration Reply message with an accept indication and a configured Lifetime value. The target PDSN <b>902</b> stores the accounting related and other information (if received) for further processing, before returning the A11-Registration Reply. The target PCF <b>802</b> stops timer Tregreq.

P-0058[0058] As previously described, the embodiments of the present invention for supporting common channel packet data (CCPD) services in a cdma2000 RAN provide a means of transmitting data between the network and a MS without the use of a traffic channel. Packet data sessions may be initiated, Dormant mode handoffs performed, and packet data may be exchanged all without the use of traffic channels. Furthermore, an A8 connection between the PCF and PDSN is not required to support packet data service once the MS has successfully registered in the network.

P-0059[0059] While the invention may be 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. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. Rather, the invention is to cover all modification, equivalents and alternatives falling within the spirit and scope of the invention as defined by the following appended claims.