2000 Method for supporting common channel packet data service in a CDMA2000 RAN
Abstract
This record has no abstract on file.
Term
Term ended
Expired 5 April 2022, 4.5 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
10 claims: 5 independent, 5 dependent
- 1A method of performing packet data call establishment in a base system (104,602) that requires a common channel packet data service.WantedThe step of receiving the called message, the step of confirming and responding to the reception of the called message, the step of determining whether or not to approve the common channel packet data service request, and the step of approving the request are approved. If so, it consists of an authentication parameter received from the mobile unit (202), an authentication data element calculated by the base system, and an additional user part element with a data burst type field set for the short data burst. The step of sending an additional transfer message to the mobile controller (110), the step of receiving the authentication result from the mobile controller (110), and the A8 connection not being requested to request the A10 connection establishment.AndThe step of sending the message to be displayed to the packet control function (106) and at least one message received from the packet control function (106,602) in the short data burst format on a common channel with at least one data burst. Packet control function (Short Data Burst Format) on the A9 signal channel for at least one message sent to the mobile device (202) and received from the mobile device (202) in at least one short data burst. A method consisting of steps to make a PPP connection between a mobile unit (202) and a packet data service node (108) by sending to 106,602). 基地システム(104,602)において、パケット・データ呼の確立を実行する方法であって、 共通チャンネル・パケット・データ・サービス要求から成る発呼メッセージを受信するステップと、 発呼メッセージの受信を確認応答するステップと、 前記共通チャンネル・パケット・データ・サービス要求を承認するか否かを判定するステップと、前記要求が承認された場合に、 移動機(202)から受信した認証パラメータ、基地システムが計算した認証データ・エレメント、およびショート・データ・バーストに設定されたデータ・バースト・タイプ・フィールドを有する追加ユーザー部エレメントから成る追加転送メッセージを移動機コントローラ(110)に送信するステップと、 移動機コントローラ(110)から認証結果を受信するステップと、 A10接続確立を要求するために、A8接続が要求されていないことを表示するメッセージをパケット制御機能(106)に送信するステップと、 パケット制御機能(106,602)からショート・データ・バースト・フォーマットで受信した少なくとも1つのメッセージを、少なくとも1つのデータ・バーストで共通チャンネル上で移動機(202)に送信し、かつ移動機(202)から少なくとも1つのショート・データ・バーストで受信した少なくとも1つのメッセージを、ショート・データ・バースト・フォーマットでA9信号チャンネル上でパケット制御機能(106,602)に送信することにより、移動機(202)とパケット・データ・サービス・ノード(108)間のPPP接続を実行するステップとから成る方法。
- 4In the base system (104,602), a method of establishing a packet data call, the step of receiving the called message, the step of confirming and responding to the reception of the called message, and the common channel packet data service. Steps to determine whether to activate, authentication parameters received from the mobile unit (202) when determined to activate the common channel packet data service, authentication data elements calculated by the base system. , And an additional forwarding message consisting of an additional user part element with a data burst type field set to short data burst, and authentication from the mobile controller (110). The step of receiving the result and at least one message received from the packet control function (106,802) in short data burst format is sent to the mobile unit (202) on a common channel with at least one short data burst. And move by sending at least one message received from the mobile unit (202) in at least one short data burst to the packet control function (106,602) over the A9 signal channel in short data burst format. A method consisting of steps to make a PPP connection between the machine (202) and the packet data service node (108). 基地システム(104,602)において、パケット・データ呼の確立を実行する方法であって、発呼メッセージを受信するステップと、発呼メッセージの受信を確認応答するステップと、共通チャンネル・パケット・データ・サービスを起動するかどうかを判定するステップと、共通チャンネル・パケット・データ・サービスを起動することが判定されたときに、移動機(202)から受信した認証パラメータ、基地システムが計算した認証データ・エレメント、およびショート・データ・バーストに設定されたデータ・バースト・タイプ・フィールドを有する追加ユーザー部エレメントから成る追加転送メッセージを移動機コントローラ(110)へ送信するステップと、移動機コントローラ(110)から認証結果を受信するステップと、パケット制御機能(106,802)からショート・データ・バースト・フォーマットで受信した少なくとも1つのメッセージを少なくとも1つのショート・データ・バーストで共通チャンネル上で移動機(202)に送信し、かつ移動機(202)から少なくとも1つのショート・データ・バーストで受信した少なくとも1つのメッセージをショート・データ・バースト・フォーマットでA9信号チャンネル上でパケット制御機能(106,602)に送信することにより、移動機(202)とパケット・データ・サービス・ノード(108)間のPPP接続を実行するステップとから成る方法。
- 6A method of performing a dormant mode handoff for a mobile unit (202) in a base system (102,802) that requires a dormant mode handoff for a common channel packet data service.WantedA step of receiving a called message consisting of the mobile unit (202), a step of confirming and responding to the receipt of the called message, a step of determining whether or not to approve the request, and a step of moving when the request is approved. Move additional forwarding messages consisting of authentication parameters received from machine (202), authentication data elements calculated by the base system, and additional user part elements with data burst type fields set for short data bursts. A step to send to the machine controller (110), a step to receive the authentication result from the mobile controller (110), and a data ready indicator and handoff indicator bit set to 0 to request an A10 connection. And no A8 connection is requiredAndA method consisting of a step of sending a message to be displayed to the packet control function (402) and a step of receiving a response message from the packet control function (402). 基地システム(102,802)において、移動機(202)のドーマント・モード・ハンドオフを実行する方法であって、 共通チャンネル・パケット・データ・サービスのドーマント・モード・ハンドオフ要求から成る発呼メッセージを移動機(202)から受信するステップと、 発呼メッセージの受信を確認応答するステップと、 要求を承認するかどうかを判定するステップと、要求が承認された場合に、 移動機(202)から受信した認証パラメータ、基地システムが計算した認証データ・エレメント、およびショート・データ・バーストに設定されたデータ・バースト・タイプ・フィールドを有する追加ユーザー部エレメントから成る追加転送メッセージを移動機コントローラ(110)へ送信するステップと、 移動機コントローラ(110)から認証結果を受信するステップと、 A10接続を要求するために、0に設定されたデータ・レディ・インジケータおよびハンドオフ・インジケータ・ビットを有し、A8接続が要求されていないことを表示するメッセージをパケット制御機能(402)に送信するステップと、 パケット制御機能(402)から応答メッセージを受信するステップとから成る方法。
- 9In mobile (202), a method of performing packet data call establishment to send and receive data on a common channel, a call message consisting of a common channel packet data service request in a base system. Send to (104,602), receive an acknowledgment that the outgoing message was received, and send at least one short data burst of data to the base system (104,602) on a common channel, at least. A method consisting of the steps of receiving data from one short data burst on a common channel from the base system (104,602) and establishing a PPP connection. 移動機(202)において、共通チャンネル上でデータを送信および受信するためにパケット・データ呼の確立を実行する方法であって、共通チャンネル・パケット・データ・サービス要求から成る発呼メッセージを基地システム(104,602)に送信するステップと、発呼メッセージが受信されたという確認応答を受信するステップと、少なくとも1つのショート・データ・バーストのデータを基地システム(104,602)に共通チャンネル上で送信し、少なくとも1つのショート・データ・バーストのデータを共通チャンネルで基地システム(104,602)から受信して、PPP接続を確立するステップとから成る方法。
- 10The step of transmitting data from at least one short data burst to the base system (104,602) on the common channel and receiving data from at least one short data burst from the base system (104,602) on the common channel. A further claim 9 comprises a step in which the first burst of at least one short data burst received from the base system (104,602) serves as a confirmation of a common channel packet data service request. The method described. 少なくとも1つのショート・データ・バーストのデータを共通チャンネル上で基地システム(104,602)に送信し、かつ少なくとも1つのショート・データ・バーストのデータを該共通チャンネル上で基地システム(104,602)から受信するステップであって、基地システム(104,602)から受信する前記少なくとも1つのショート・データ・バーストのうちの最初のバーストが共通チャンネル・パケット・データ・サービス要求の確認として機能するステップからさらに成る請求項9に記載の方法。
Independent claims5
71 paragraphs, as filed
The present invention relates to the field of a communication system, and more particularly to a code division multiple access (CDMA) communication system.
[0002] Data services are generally classified into line-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 Service Node (PDSN) between data transmissions on a fixed network and data transmission on an air interface. It is functioning as an interface. The PDSN is interface-connected to the base system (BS: Base System, hereinafter referred to as BS) through the packet control function (PCF: Packet Control Function, hereinafter referred to as PCF), but the PCF may be located in the same location as the BS. And it does not have to be placed.
[0003] Packet data services as defined in 3rd Generation Partnership Project 2 (3GPP2 Access Network Interfaces Interoperability Specification, hereinafter referred to as 3GPP2 A.S0001-A), which is incorporated herein by reference. There are three types of states: Active / Connected, Domant, and Null / Inactive (3GPP2 specification is TIA / EIA / IS-2001-A June 2001). It has the same contents as). When a mobile device (MS: Mobile Station, hereafter referred to as MS) makes a packet data call to the current cdma2000 Radio Access Network (RAN: Radio Access Network, hereafter referred to as RAN), a traffic channel is assigned and point-to-point protocol is assigned. Two-point protocol (PPP: Point-to-Point) A Protocol (hereinafter referred to as PPP) connection is established, and a mobile Internet Protocol (IP: Internet Protocol, hereinafter referred to as IP) registration procedure is performed. Upon successful completion of these steps, the MS packet data service transitions from null to active / connected, and the network and MS exchange packet data on the traffic channel. After a predefined inactivity period, the MS packet data service transitions from the active state to the dormant state, but if the MS or network has transmitted data, it becomes active again. May be good. Handoffs in dormant mode between PDSNs also require traffic channel allocation to support the establishment of new PPP connections and re-registrations.
[0004] In the active / connected state, a physical traffic channel exists between the MS and the BS, and any of the units may transmit data. In the dormant state, there is no physical traffic channel between MS and BS, but the PPP link between MS and PDSN is maintained. In the null / inactive state, there is no traffic channel between MS and BS, and there is no PPP link between MS and PDSN.
The interfaces A1 to A11 are defined in Section 1.7.2 of 3GPP2 A.S0001-A. The connection between A1 and A8 is maintained during the active / connected state, but is released during the transition to the dormant or null / inactive state. A10 connectivity is maintained during active / connected and dormant states. As part of its support for dormant conditions, the cdma2000 air interface (TIA / EIA-IS-2000) has a Data Ready to Send (DRS) indicator used when making calls. Supports. If the MS sends a call request with the specified packet data service option, the request contains the DRS bit. If the MS has outgoing data and is requesting the establishment of a traffic channel and the MS wants to transition from the dormant state to the active state, this indicator is set to 1 when the initial call is established. Then, during the dormant, the MS drops the packet zone boundary (3GPP2 A.S0001-A). The DRS bit is set to 0 to indicate that it is transitioning to (see Section 2.14.1) and is continuing to send call requests to update the network for its current location.
When a call request with the DRS bit set to 1 is received, the BS initiates the call establishment procedure shown in 3GPP2 A.S0001-A Section 2.14.7.1, which results in normal traffic. The channel is established and the bearer connection between A8 and A10 (bearer connection) is established. Procedures for bearer connections for A8 and A10 are defined in 3GPP2 A.S0001-A Sections 2.14 and 2.15, respectively. When the BS receives a call with the DRS bit set to 0, the BS delays the establishment of the traffic channel until the bearer connection establishment procedure for A8 and A10 is completed. During the bearer connection establishment procedure for A8, BS will use the A9-Establishment-A8 (A9-Setup-A8) message (3GPP2 A.S0001-A section). Use the data ready indicator element (defined in 2.14.4.1.1) to indicate to the PCF that DRS = 0 has been received. If the PCF has data from the network to deliver to the MS, the PCF will DRS the reason element for the A9-Connect-A8 (A9-Connect-A8) message (as defined in 3GPP2 A.S0001-A Section 2.14.4.1.2). Set to a value to display this. The BS then establishes a traffic channel to the MS and completes the normal call establishment procedure as defined in 3GPP2 A.S0001-A Section 2.14.7.10. If the PCF has no data, the PCF sends an A9-Release-A8 (A9-Release-A8) termination message (as defined in 3GPP2 A.S0001-A Section 2.14.5.4) to the BS. Indicates that the A8 connection has not been established. BS then Packet Call Going The allocation failure message is returned to the Mobile Switching Center (MSC: Mobile Switching Center, hereinafter referred to as MSC) with the reason value set in Dormant). Upon receiving the allocation failure message, the MSC sets a reason value of Do Not Notify Mobile and returns a clear command to the BS. Upon receiving the clear command message, BS sends a clear completion message to the MSC.
PROBLEM TO BE SOLVED: To provide a device and a method for inexpensively supporting common channel packet data (CCPD) in cdma2000 RAN without using a traffic channel. To do.
[Means for Solving the Problems] In order to solve the above problems, the invention according to claim 1 is a method for establishing a packet data call in a base system, and is a common channel. Packet data service required<u style="single">Wanted</u>The step of receiving the called message, the step of confirming and responding to the reception of the called message, the step of determining whether or not to approve the common channel packet data service request, and the step of approving the request are approved. If so, an additional transfer message consisting of an authentication parameter received from the mobile unit, an authentication data element calculated by the base system, and an additional user part element with a data burst type field set for the short data burst. To the mobile controller, the step to receive the authentication result from the mobile controller, and the A8 connection is not required to request the A10 connection establishment.<u style="single">And table</u>The step of sending the indicated message to the packet control function and at least one message received from the packet control function in the short data burst format is sent to the mobile device on the common channel with at least one data burst. And by sending at least one message received from the mobile device in at least one short data burst to the packet control function on the A9 signal channel in short data burst format, the mobile device and packet data. The gist consists of the steps of making a PPP connection between service nodes.
[0009] The invention according to claim 2 is the method according to claim 1, wherein the first at least one message transmitted to the mobile device in whole or in part is a common channel packet data service of the mobile device. The gist is that it functions as an acknowledgment to a request.
[0010] The invention according to claim 3 is the method according to claim 1, after performing a PPP connection.<u style="single">Of RAN packet data</u>From null state<u style="single">Of RAN packet data</u>To the dormant state<u style="single">Packet data session</u>transition<u style="single">Let</u>The gist is that it consists of more steps.
[0011] The invention according to claim 4 is a method of establishing a packet data call in a base system, which includes a step of receiving a called message and a step of confirming and responding to the reception of the called message. , The step of determining whether to activate the common channel packet data service, and the authentication parameters received from the mobile unit when it is determined to activate the common channel packet data service, the base system A step of sending an additional transfer message to the mobile controller, consisting of a calculated authentication data element and an additional user part element with a data burst type field set to short data burst, and authentication from the mobile controller. The step of receiving the result and at least one message received in short data burst format from the packet control function is sent to and from the mobile on a common channel with at least one short data burst. PPP between the mobile and the packet data service node by sending at least one message received in one short data burst to the packet control function over the A9 signal channel in short data burst format. The gist is that it consists of the steps to make a connection.
[0012] The invention according to claim 5 is the method according to claim 4, wherein all or part of the first at least one message transmitted to the mobile device is called by the common channel packet data service. The gist is to serve as an acknowledgment used to support the establishment.
[0013] The invention according to claim 6 is a method of performing a dormant mode handoff of a mobile device in a base system, which requires a dormant mode handoff of a common channel packet data service.<u style="single">Wanted</u>A step of receiving a call message consisting of the call from the mobile device, a step of confirming and responding to the reception of the call message, a step of determining whether or not to approve the request, and a step of receiving from the mobile device when the request is approved. A step of sending an additional transfer message to the mobile controller consisting of an additional user part element with the authenticated parameters, the authentication data element calculated by the base system, and the data burst type field set for the short data burst. It has a data ready indicator and a handoff indicator bit set to 0 to request an A10 connection, with a step to receive the authentication result from the mobile controller, and no A8 connection is requested.<u style="single">And</u>The gist is that it consists of a step of sending a message to be displayed to the packet control function and a step of receiving a response message from the packet control function.
[0014] The invention according to claim 7 is empty in the mobile device as an acknowledgment of a common channel packet data service request for the mobile device when the request is approved in the method according to claim 6. The gist is that it further comprises a step of transmitting a short data burst and a step of receiving an acknowledgment of receiving a short data burst.
[0015] The invention according to claim 8 receives at least one message in the short data burst format from the packet control function when the request is approved in the method according to claim 6. At least one message sent to the mobile on a common channel in one short data burst and received from the mobile in at least one short data burst in short data burst format on the A9 signal channel. The gist is that it further consists of the steps of making a PPP connection between the mobile and the packet data service node by sending to the packet control function.
[0016] The invention according to claim 9 is a method of executing the establishment of a packet data call in order to transmit and receive data on a common channel in a mobile device, and is a common channel packet data service. Sending a solicited message consisting of a request to the base system, receiving an acknowledgment that the called message was received, and sending at least one short data burst of data to the base system on a common channel. The gist is that it consists of the steps of receiving at least one short data burst of data from the base system over a common channel and establishing a PPP connection.
[0017] The invention according to claim 10 transmits data of at least one short data burst to the base system on a common channel and at least one short data burst in the method of claim 9. The step of receiving burst data from the base system on the common channel, the first of the at least one short data burst received from the base system is the common channel packet data service request. The gist is that it consists of further steps that act as confirmation.
BEST MODE FOR CARRYING OUT THE INVENTION In the present invention, a device and a method for supporting common channel packet data (CCPD) by using a common channel without using a traffic channel in cdma2000 RAN are proposed. To do. Without using the traffic channel, a packet data session is launched, a dormant mode handoff is performed, or all packet data is exchanged. Moreover, once the MS is successfully registered on the network, the A8 connection between the PCF and PDSN no longer needs to support packet data services. The present invention may also be applied to the current cdma2000 MS to support dormant mode handoff and data transmission without the use of traffic channels. The CCPD feature supports establishing packet data calls, dormant mode handoffs, and sending data using short data bursts (SDBs: Short Data Bursts, hereafter referred to as SDBs) on a common channel.
The CCPD function needs to support CCPD devices. CCPD devices are data-only devices that do not support cdma2000 traffic channels. All signals and data to be exchanged between the CCPD device and the network must occur on the cdma2000 common channel. Although many types of CCPD devices are specifically shown in the present invention, the present invention is particularly suitable for use in MS. Therefore, preferred embodiments of the present invention will be described in the context of MS.
[0020] CCPD-capable MSs are cdma2000 MSs that support CCPD services in addition to the current cdma2000 packet data services. A CCPD-capable MS may request CCPD services from the network if the amount of data transmitted is low and expected to be infrequent, or during the Dormant mode handoff. Since CCPD devices communicate through a common channel rather than an expensive traffic channel, these devices are relatively inexpensive to build for users and network operators. In addition, due to its limited functionality, the existing commercial cdma2000 It is expected to be even cheaper than MS. Possible uses for CCPD devices are: (1) Remote measurement-CCPD devices may be used in utility meters (for water, electric gas), (2) Vending machines-CCPD devices for low-stock items May be used to alert suppliers, (3) Automatic / Home Security-CCPD devices could be used to alert administrators to unauthorized intrusions, (4) Taximeters, and (5) Including stock trading. For the sake of brevity, MSs that support only CCPD services (not supporting cdma2000 traffic channels) and MSs that can support CCPD services and cdma2000 are collectively referred to here as CCPD MSs.
[0021] FIG. 1 is a block diagram showing relationships between network components that support devices and methods that support the CCPD service in the present invention. As shown in FIG. 1, the target BS102 is coupled to the source BS104 at A3 interface 112 and A7 interface 114 to exchange traffic and signal information. Interfaces 112 and 114 of A3 and A7 are not particularly relevant to the present invention and will not be described in more detail here. Source BS104 is coupled to PCF106 (packet control function) at A8 interface 116 and A9 interface 118. A8 interface 116 is the base station controller (BSC) of the source BS104 for packet data services. Used to provide a user traffic path between the Controller) and PCF106. A9 interface 118 is used to provide a signal connection between the source BSC and PCF116 for packet data services. PCF106 is coupled to PDSN108 (Packet Data Service Node) with A10 interface 120 and A11 interface 122. A10 interface 120 is used to provide a user traffic path between PCF106 and PDSN108 for packet data services. A11 interface 122 is used to provide a signal connection between PCF106 and PDSN108 for packet data services. The MSC110 is coupled to the source BS104 with A1 interface 124, A2 interface 126, and A5 interface 128. Interfaces 124, 126, and 128 of A1, A2, and A5 are not particularly related to the present invention and will not be described in more detail here.
Messages and data between the network and CCPD MS are encapsulated in SDBs and exchanged on a common channel. This includes PPP connectivity, MIP (Mobile Internet Protocol, hereafter referred to as MIP) registration, and packet data. BS can start the CCPD service to the CCPD MS even if the SDB_DESIRED_ONLY bit in the outgoing message is set to 1 and the MS does not explicitly request the service. This could be used for Dormant mode handoffs. The BS can use the SDB on a common channel to answer and execute MS calls rather than allocating a traffic channel for the call. Subsequent communication between the MS and the network will occur using SDB on a common channel.
The CCPD device sends a call message to the BS with the SDB_DESIRED_ONLY bit set to 1 and the FCH-SUPPORTED and DCCH_SUPPORTED bits set to 0 to request CCPD service from the network. After successful device authentication, the PPP connection establishment and MIP registration required to exchange messages is performed on the common channel using SDB. The first SDB sent by the BS to the CCPD device acts as an acknowledgment of the device's CCPD service request. If the BS cannot support the CCPD service request from the CCPD device, the SDB will not be sent and the call attempt will fail. The CCPD device may retransmit the CCPD service request.
[0024] The CCPD MS may send a call message with the SDB_DESIRED_ONLY bit, the FCH_SUPPORTED bit, and the DCCH_SUPPORTED bit set to 1 to the BS to request CCPD service from the network. If BS accepts MS's support request for CCPD service, MS is authenticated first. After successful authentication of the MS, the PCF will be notified that the CCPD service is being used for the call. PPP connection establishment and MIP registration (if required) are performed on a common channel using SDB to exchange messages. Messages and data between BS and PCF are communicated on the A9 signal channel. The first SDB sent to the CCPD MS acts as an acknowledgment for a CCPD service request. The network may also reject the CCPD service request for CCPD MS and apply normal packet data procedures to establish packet data calls, or may send packet data. After successful PPP connection and MIP registration, CCPD The MS packet data service transitions from a null / inactive state to a dormant state, opening the A8 connection between BS and PCF.
[0025] A first aspect of the present invention provides a preferred embodiment of the MS-initiated CCPD calling process. If CCPD MS202 invokes a packet data call and MIP registration is not performed, PPP connection establishment and MIP registration will be performed using SDB on the common channel. Once PPP connection establishment and MIP registration are complete, packet data may be exchanged between the MS202 and the network using SDB on a common channel. All messages specifying the SDB format are specified in Chapter 12, Section 2.2.10 of TIA / EIA / IS-707-A2 (Ballot Resolution Version June 2000 (IS-707-A-2)). There is.
FIG. 2 will be described. In step a, CCPD MS202 sends an outgoing message to BS104 over the access channel of the air interface with the Layer 2 acknowledgment required for the packet data service request. MS202 sets the SDB_DESIRED_ONLY bit in the message to 1 to indicate that the network wants CCPD service. In step b, the BS 104 sends a base station acknowledgment command to the CCPD MS202 to acknowledge the receipt of the outgoing message. In step c, BS104 sends an ADDS Transfer message (described in 3GPP2 A.S0001-A Section 26.2.2) to MSC110. The message includes the authentication parameters received from CCPD MS202, the authentication data element calculated by BS, and the additional user part (ADDS User) set in the SDB. Part) Contains the element's data burst type field. BS activates timer T60. If the MS202 supports traffic channels and the BS104 decides not to support CCPD service requests, the call is specified in a regular MS-issued packet data call (3GPP2 A.S0001-A Section 2.14.7.1). Is treated as). If BS104 cannot support the CCPD service request from the CCPD device, the call will fail.
[0027] In step d, the MSC110 returns the MS202 authentication result to the BS104 in an additional transfer acknowledgment (ADDS Transfer Ack) message (described in 3GPP2 A.S0001-A Section 2.14.8.1.2). In step e, BS104 sends an A9-establishment-A8 message (described in 3GPP2 A.S0001-A Section 2.14.4.1.1) to PCF106 to establish a PPP connection and MIP registration for CCPD MS202 (if requested). For example, start the procedure. BS104 sets the CCPD service bit of the message to 1 and sets PCF106 to A8. is not requesting an connection. If the MS202 is a CCPD device, BS104 sets the CCPD bit in the message to 1 to indicate to PCF106 that the data session is for the CCPD device. BS104 then activates the timer TA8-Setup. In step f, the A10 / A11 connection establishment procedure is performed. PDSN108 and CCPD when A10 / A11 connection is established in step g The MS202 uses SDB on a common channel to exchange messages on the air to establish a PPP connection and perform MIP registration. All messages exchanged between the network and MS202 are in SDB format. PCF106 formats the message to MS202 in SDB format before sending it to BS104. BS104 sends a message from MS202 to PCF106 in SDB format. The PCF106 translates the message into a packet data format before sending the data to the PDSN108. The first SDB sent from BS104 to MS202 acts as an acknowledgment to the MS CCPD service request. In step h, PCF106 sends an A9-open-A8 completion message (described in 3GPP2 A.S0001-A Section 2.14.5.4) to BS104 with a successful cause value. BS104 stops timer TA8-establishment. In step i, the MS202 sends the packet data to the BS104 over a common channel in the SDB.
[0028] In step j, the BS 104 sends a BS acknowledgment command (Ack order) to the MS 202 to acknowledge the reception of the SDB from the MS 202. In step k, BS104 sends an A9-short data delivery message containing packet data to PCF106 in SDB format. In step l, PCF106 sends the data to PDSN108 as normal packet data. In step m, PCF106 received an A-11 registration request message (Network Working Group, Request for Comments 2002, Editors C. Perkins, IBM, October 1996, section 3.3 of Network Working Group; Request). for Comments; 2002; C. Perkins, Editor; IBM; October 1996), and 3GPP2 A.S0001-A (described in Section 6.1.11.1) for billing SDB Airlink Records (3GPP2 A.S0001-A Section 2.15.4.4). ) To send to PDSN108. In step n, PDSN108 is A11-Registration Reply Message (Network Working Group, Request for Comment 2002, Editors C. Perkins, IBM, October 1996, Section 3.4 of Reply to PCF106 in Network Working Group; Request for Comments; 2002; C. Perkins, Editor; IBM; October 1996), and 3GPP2 A.S0001-A (explained in Section 6.1.11.2).
[0029] A second aspect of the invention provides a preferred embodiment of the process of packet data transfer to a CCPD device where the MS terminates when the MS202 is in the Dormant packet data state. If the network has data to send to a dormant CCPD device, PCF106 sends the data to BS104 in an A9-short data delivery message. When the MS202 invokes a CCPD service request on the network, the PCF106 is notified that the MS202 is a CCPD device. Since the data is for CCPD devices, the PCF106 does not need to buffer the MS202 data and therefore does not require an acknowledgment from the BS104 after the data has been sent. As specified in IS-707-A-2, BS104 sends the data in SDB to the CCPD device. If the BS104 does not receive an acknowledgment from the MS202 after sending the SDB to the MS, the BS104 may retry the data transmission and / or initiate an additional procedure (ADDS procedure) to deliver the data. 3GPP2 A.S0001-A section See 2.14.8.6 ADDS procedure.
FIG. 3 shows a logical flow of a preferred embodiment of the process of packet data transfer to a CCPD device where the MS202 terminates when the MS is in the Dormant packet data state. PCF106 was informed that MS202 was a CCPD device during the initial packet data session establishment. All messages that specify the SDB format are specified in IS-707-A-2. In step a, PPP connection establishment and MIP registration are pre-performed between the network and MS202. CCPD MS202 is currently in Dormant Packet Data Service state. In step b, PDSN108 sends packet data from the network to CCPD MS202. In step c, PCF106 sends packet data in SDB format to BS104 with an A9-Short Data Delivery message. In step d, BS104 CCPD the packet data using a common channel in the SDB. Send to MS202. In step e, the MS202 sends a Layer 2 acknowledgment to the BS104 and acknowledges the reception of the SDB. If the Layer 2 acknowledgment is not received from the MS202, the BS104 may resend the SDB to the MS202. Alternatively, BS104 may use additional steps to deliver the SDB to MS202.
[0031] In step f, BS104 sends an A9-update-A8 message (described in 3GPP2 A.S0001-A section 2.14.5.6) to PCF106 to display the successful transmission of the SDB to MS202. BS104 activates the timer Tupd9. In step g, PCF106 sends an A11-registration request message to PDSN108 on an SDB airlink record for billing. In step h, PDSN108 responds to PCF106 with an A11-registration response message. In step i, PCF106 responds to BS104 with an A9-Update-A8 acknowledgment (3GPP2 A.S0001-A section 2.14.5.7). Upon receiving this message, BSC stops the timer Tupd9.
A third and fourth aspect of the present invention provides a Dormant handoff procedure for CCPD MS. Upon detecting a new packet zone identifier (PZID), system identifier (SID), or network identifier (NID), CCPD MS sends a outgoing message to BS104 with the SDB_DESIRED_ONLY bit set to 1. The PCF establishes an A10 connection with the PDSN. If the MS continues to be serviced from the same PDSN, the PDSN will open the A10 connection with the previous PCF. If a new PDSN is selected for the call as a result of the dormant mode handoff, a PPP connection will be established using SDB on the common channel and MIP registration will be performed. It should be noted that BS104 may reject the CCPD service request of CCPD MS by applying the normal packet data dormant mode handoff procedure.
[0033] Also, even if the MS sets the SDB_DESIRED_ONLY bit of the outgoing message to 1 and does not explicitly request the CCPD service from the BS, the BS will provide the CCPD service to the CCPD MS that has no transmitted data. You may start it. BS can optionally use this procedure to support Dormant mode handoff (for example, if the traffic channel is unavailable). When a new PZID, SID, or NID is detected, CCPD MS sends a call message to BS with the SDB_DESIRED_ONLY bit set to 0 and the DRS bit set to 0. Instead of invoking the normal dormant mode handoff procedure, BS authenticates the MS and informs the PCF that the CCPD service will be used to support dormant mode handoff. The SDB first sent to the MS indicates that the CCPD procedure will be used to support the dormant mode handoff. Subsequent communication between the MS and the network occurs using SDB on a common channel.
[0034] A third embodiment of the present invention will be described. A successful inter-PCF / intra-PDSN CCPD MS dormant mode handoff process is provided. Assume that the PCF is identified as unique with the current Access Network Identifier (CANID). Upon detecting a new PZID, NID, or SID, CCPD MS sends a outgoing message to the target BS with the packet data service option with the SDB_DESIRD_ONLY bit set to 1. FCH_SUPPORTED if the call is from a CCPD device The bit and the DCCH_SUPPORTED bit are further set to 0. If any of these parameters change during the dormant handoff, the outgoing message contains the previous PZID, NID and SID. Based on the outgoing message identifier (PZID, NID, and / or SID), the target PCF sends the source PCF's previous access network identifier (PANID) and the target PCF's CANID to the serving PDSN. The serving PDSN uses this information to determine if MIP registration is required. All messages that specify the SDB format during the process are specified in IS-707-A-2. You may also use this process if the network decides to use the CCPD service for the dormant mode handoff. In such cases, the MS sends a call message with the SDB_DESIRED_ONLY bit set to 0. The SDB first sent to the MS indicates that the CCPD procedure will be used to support the dormant mode handoff.
FIG. 4 will be described. A preferred embodiment of the normal inter-PCF / intra-PDSN CCPD MS dormant mode handoff process is provided. In step a, CCPD MS202 is in a dormant state by preliminarily performing PPP connection establishment and MIP registration with the PDSN. In step b, CCPDMS202 detects a change in PZID, SID, or NID while monitoring the broadcast channel and sends a call message with the SDB_DESIRED_ONLY bit set to 1. In step c, the target BS102 confirms the response of the incoming call message to the CCPD MS202 with the base station confirmation response instruction. In step d, the target BS102 sends an additional forwarding message to the MSC110 containing the authentication parameters received from the MS202, the data elements calculated by the BS, and the data burst type fields of the additional user part elements set in the SDB. To do. If BS102 determines that CCPD MS202 supports traffic channels, the other option is BS102 to 3GPP2. A.S0001-A The MS Dormant Mode handoff procedure described in Section 2.14.7.9 may be performed. Target BS102 activates timer T60. In step e, the MSC110 sends to the target BS102 without displaying the reason value in the additional transfer acknowledgment message. Target BS102 cancels timer T60. If the authentication of MS202 fails, MSC110 puts the reason value of authentication failure in the message and the CCPD call fails.
[0036] In step f, the target BS102 sends an A9-established-A8 message to the target PCF402 with the data ready indicator and handoff indicator bits set to 0. BS102 sets the CCPD service bit in the message to 1 to indicate that the target PCF402 is not requesting an A8 connection. If the MS202 is a CCPD device, the target BS102 sets the CCPD bit of the message to 1 to indicate to the target PCF402 that the data session is for the CCPD device. Target BS102 activates timer TA8-establish. In step g, the target PCF402 establishes an A10 / A11 link with PDSN108. PDSN108 breaks the A10 / A11 link with the source PCF106. If PDSN108 has data to MS202, PDSN108 is Vendor / Organization Specific Extension (3GPP2 A.S0001-A). Respond to target PCF402 with a registration response message with a data availability indicator (described in Section 6.2.2.166).
[0037] In step h, the target PCF402 sends an A9-open-A8 end message to the target BS102 with a normal reason value. Target BS102 cancels timer TA8-establishment. In step i, if PDSN108 has data from the network to CCPD MS202, the target PCF402 sends SDB format data to BS102 in an A9-short data delivery message. If the MS202 supports traffic channels, the PCF402 buffers the data and follows the procedure for short data delivery from the PCF402 to the MS202 (see 3GPP2 A.S0001-A2.14.8.8 / 7). CCPD For data to MS202, PCF402 discards the data. In step j, if PCF402 sends data to MS202 to target BS102 in an A9-short data delivery message, BS102 sends the data to MS202 in SDB. This SDB acts as an acknowledgment for the CCPD service from BS102. If no data is sent from PCF402, an empty SDB is sent to MS202. In step k, CCPD MS202 sends a Layer 2 acknowledgment to BS102 to acknowledge the receipt of the SDB. Once the data is sent in the SDB, the A9 update procedure for billing (shown in 3GPP2 A.S0001-A Section 2.14.9.2) is performed.
[0038] A fourth aspect of the present invention will be described. A normal PCF / PDSN CCPDMS dormant mode handoff process is provided. When a dormant MS moves to a different packet zone and is connected to a different PDSN, the target PCF serves the source PCF (PANID) access network identifier (ANID) and PCF (CANID) ANID. You will be asked to transfer to the PDSN. PPP connection establishment and MIP registration are performed using SDB on the common channel. All messages that specify the SDB format during the process are specified in IS-707-A-2. This process may also be used if the network decides to use the CCPD service for the dormant mode handoff. In such cases, the MS sends a call message with the SDB_DESIRED_ONLY bit set to 0. The SDB first sent to the MS indicates that the CCPD procedure will be used to support the dormant mode handoff.
[0039] FIG. 5 will be described. A preferred embodiment of the normal PCF / PDSN CCPD MS dormant mode handoff process is provided. In step a, CCPD MS202 detects the PZID change while monitoring the broadcast channel and sends a call message with the SDB_DESIRED_ONLY bit set to 1. In step b, the target BS102 confirms the response of the incoming call message to the CCPD MS202 with the base station confirmation response instruction. In step c, BS102 sends an additional forwarding message to MSC110. The message contains the authentication parameters received from MS202, the BS-calculated authentication data element, and the data burst type fields of the additional user part elements set in the SDB. If BS102 determines that CCPD MS202 supports the traffic channel, the other option is BS102 is 3GPP2 A.S0001-A. The MS Dormant Mode handoff procedure described in Section 2.14.7.9 may be performed. Target BS102 activates timer T60. In step d, the MSC110 sends an additional transfer acknowledgment message to the target BS102 without displaying the reason value. Target BS102 cancels timer T60. If the authentication of MS202 fails, MSC110 puts the reason value of "authentication failure" in the message and the CCPD call fails.
[0040] In step e, the target BS102 sends an A9-established-A8 message to the target PCF106 with the data ready indicator and handoff indicator bits set to 0. BS102 sets the CCPD service bit in the message to 1 to indicate that the PCF is not requesting an A8 connection. If the MS202 is a CCPD device, BS102 also sets the CCPD bit in the message to 1 to indicate to PCF106 that the data session is for CCPD MS202. BS102 activates timer TA8-establish. In step f, the A10 / A11 establishment procedure is performed. In step g, when the A10 / A11 connection is established, PDSN108 and CCPD The MS202 uses SDB on a common channel to exchange messages on the air to establish a PPP connection and perform MIP registration. All messages exchanged between the network and MS202 are in SDB format. The PCF40 formats the message to the MS202 in SDB format before sending it to the BS102. BS102 sends the message from MS202 to PCF106 in SDB format. The PCF106 translates the message into a packet data format before sending the data to the PDSN108. The first SDB sent from BS102 to MS202 acts as an acknowledgment to the MS CCPD service request. In step h, PCF106 sends the A9-open-A8 end message to BS102 with a normal reason value. BS102 stops timer TA8-establishment. If the call is to a CCPD-enabled MS202 and the PDSN108 has data to the MS202, the network restarts the call after the PCF106 responds to the BS102 with a reason value of failure, depending on the amount of data. You may.
[0041] A fifth aspect of the present invention provides a preferred embodiment of the process of receiving packet data from a PDSN and delivering an SDB to an MS. In this embodiment, the BS and PCF shown in FIG. 1 are configured as a single unit. FIG. 6 will be described. In step a, PCF602 receives packet data from PDSN108 and determines if this data can be delivered to the Dormant Packet Data Service Instance. BS602 can send SDB directly to MS202. If the received data is to a CCPD device, the packet data is always sent in SDB to MS202. In step b, in response to the SDB from BS602, MS202 sends a Layer 2 acknowledgment. If no Layer 2 acknowledgment is received from the MS202, the BS602 may attempt to retransmit the data to the MS202. In step c, as another option, BS602 may send the data in SDB format specified in IS-707-A-2 to MSC110 in the BS service request message. BS602 sets timer T311. When timer T311 times out, no SDB information is sent to MS202. This process may occur again if BS602 fails to successfully deliver SDB to MS202. In step d, the MSC110 sends a BS service response message to the BS602 to confirm and respond to the receipt of the BS service response message. BS602 cancels timer T311. In step e, the MSC110 sends the SDB in the ADDS Page and Application Data Massage fields to the BS602 in the data burst type field of the additional user part element set in the SDB. .. BS602 transfers SDB to MS202.
[0042] In step f, after receiving the SDB from the BS602, the MS202 sends a layer 2 acknowledgment. If the MSC110's additional page message contains a tag element, BS602 replies to the MSC110 with the additional page acknowledgment message after receiving the Layer 2 acknowledgment from MS202. The tag element received from the MSC110 is included in the message. In step g, BS / PCF602 sends an A-11 registration request message to PDSN108 via an SDB airlink record. In step h, PDSN108 responds with an A11-registration response message.
[0043] A sixth aspect of the present invention provides a preferred embodiment of the MS-initiated CCPD calling process. In this embodiment, the BS and PCF shown in FIG. 1 are configured as a single unit. If a CCPD MS that has not performed MIP registration invokes a packet data call, PPP connection establishment and MIP registration are performed using SDB on the common channel. Once a PPP connection is established, packet data is exchanged between the MS and the network using SDB on a common channel.
[0044] FIG. 7 will be described. A flow diagram of a preferred embodiment of the MS-initiated CCPD calling process is shown. In step a, the MS202 sends the outgoing message to the BS602 over the access channel of the air interface using the Layer 2 acknowledgment required for the packet data service request. MS202 sets the SDB_DESIRED_ONLY bit in the message to 1 to indicate that the network wants CCPD service. In step b, BS602 confirms the response of the incoming call message to MS202 by the base station confirmation response instruction. In step c, BS602 sends an additional forwarding message to MSC110. CCPD for additional forwarding messages Includes authentication parameters received from MS202, BS-calculated authentication data elements, and data burst type fields for additional user elements set in the SDB. BS602 activates timer T60. If the MS202 supports the traffic channel and the BS602 does not support the CCPD service request, the call is specified in 3GPP2 A.S0001-A Section 2.15.5.1 for establishing a packet data call issued by a regular MS. Is processed as). If BS602 cannot support the CCPD service request from the CCPD device, the call will fail.
[0045] In step d, the MSC110 responds and returns the authentication result of CCPD MS202 to the BS602 in the additional transfer confirmation response message. In step e, PCF602 recognizes that the A10 connection associated with MS202 is unavailable and selects PDSN108 for the call. PCF602 sends an A11-registration request message to the selected PDSN108 and activates the timer Tregreq. In step f, the A11-registration request is valid and the PDSN108 accepts the connection by returning an A11-registration response message with an acceptance indication and a Lifetime field with a fixed Trp value. PCF602 stops the timer Tregreq.
[0046] In step g, the MS202 and PDSN108 exchange SDBs on a common channel to establish a link layer (PPP) connection before performing the MIP registration procedure (if required). The first SDB sent from BS602 to MS202 acts as an acknowledgment to the MS CCPD service request. In step h, MS202 transmits the data as SDB to BS602 on a common channel. In step i, the BS602 acknowledges and responds to the MS202 by sending a BS acknowledgment command (Ack order) to the MS202. In step j, PCF602 sends packet data to PDSN108. In step k, PCF602 sends an A-11 registration request message to PDSN108 with an SDB airlink record. In step l, PDSN108 updates the billing data and responds to PCF602 with an A11-registration response.
A seventh aspect of the present invention provides a preferred embodiment of the inter-PCF dormant handoff process for CCPD MS when the MS is serviced by the same PDSN. To get the packet data service, CCPD MS performs packet network registration. Both A10 and Link Layer (PPP) connections are maintained. Before the A10 connection duration timer Trp times out, the source PCF exchanges the A11-registration request and the A11-registration response message to perform a re-registration to the PDSN for the A10 connection. In dormant mode, CCPD MS detects changes in PZID, SID, or NID. Upon detecting a new PZID, NID, or SID, the MS sends a call message with the packet data service option with the SDB_DESIRD_ONLY bit set to 1 to the target BS602. FCH_SUPPORTED if the call is to a CCPD device The bit and the DCCH_SUPPORTED bit are also set to 0. If any of these parameters change during the dormant handoff, the outgoing message contains the previous PZID, SID and NID. The target PCF establishes an A10 connection with the PDSN. Based on the outgoing message identifier (PZID, NID, and / or SID), 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 if MIP registration is required. If the PDSN has data, the PDSN returns a "data availability indicator" to the BS / PCF in the vendor / organization identification extension in the registration response. The source PDSN opens the A10 connection with the source PCF.
[0048] The process described above may also be used if the network decides to start the CCPD service for a dormant mode handoff. In such cases, the MS sends a call message with the SDB_DESIRED_ONLY bit set to 0. The SDB first sent to the MS indicates that the CCPD procedure will be used to support the dormant mode handoff.
FIG. 8 will be described. A flow diagram of a preferred embodiment of the dormant handoff process between CCPD MS PCF 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. This process assumes that CCPD MS202 has previously performed PPP connection establishment and MIP registration with PDSN and is currently maintaining a Dormant Packet Data Service instance. When a new packet zone ID is detected in step a, CCPD The MS202 sends a call message with the SDB_OESIRED_ONLY bit set to 1. In step b, the target BS602 acknowledges the receipt of the outgoing message to the MS202 with a base station acknowledgment instruction. In step c, the BS sends an additional forwarding message to the MSC110. The message contains the authentication parameters received from MS202, the BS-calculated authentication data element, and the data burst type fields of the additional user part elements set in the SDB. If BS determines that the CCPD MS202 supports the traffic channel, the other option is that it is 3GPP2 A.S0001-A. The MS Dormant Mode handoff procedure described in Section 2.15.5.8 may be performed. Target BS802 activates timer T60. In step d, the MSC110 sends to the target BS802 without displaying the reason value in the additional transfer acknowledgment message. Target BS802 cancels timer T60. If the authentication of MS202 fails, MSC110 puts the reason value of "authentication failure" in the message and the CCPD call fails.
[0050] In step e, the target PCF802 sends an A11-registration request message to PDSN108. The registration request message contains a move event indicator within the vendor / organization identification extension. The PCF activates the timer Tregreq. In step f, the A-11 registration request is valid and PDSN108 returns an A-11 registration response indicating acceptance to accept the connection. If PDSN108 has transmitted data, it contains a data availability indicator within the vendor / organization identification extension. If the data is for a CCPD-capable MS202, a re-call may occur that boots the network. The A10 connection binding information on PDSN108 is updated to point to the target PCF802. The target PCF802 stops the timer Tregreq. In step g, BS sends an empty SDB to CCPD MS202 and acknowledges to accept the CCPD service request. When PDSN108 sends data to MS202, the data is contained in SDB. In step h, CCPD The MS202 returns a Layer 2 acknowledgment and acknowledges the receipt of the SDB. Assume that the packet data service instance of the MS is in the dormant state again. If the network or MS202 has transmitted data, the data may be transmitted using SDB on a common channel according to CCPD procedures.
[0051] In step i, PDSN108 sends an A11-registration update message to activate the termination of the A10 connection with the source PCF602. PDSN108 activates the timer Tregupd. In step j, the source PCF602 responds with an A11-registration confirmation response message. PDSN108 stops the timer Tregpd. In step k, the source PCF602 sends the A-11 registration request message to PDSN108 with a duration set to 0. The PCF activates the timer Tregreq. In step l, PDSN108 sends an A11-registration response message to the source PCF602. Source PCF602 terminates the MS202 A10 connection. Source PCF602 stops timer Tregreq. In step m, the target PCF802 sends an A11-registration request message to PDSN108 to refresh the registration of the A10 connection with PDSN108 before the registration duration timer (Trp) times out. A11-Registration request messages are also used to send billing and other information to PDSN108. Billing relationships and other information are sent at system-defined trigger points. The PCF activates the timer Tregreq.
[0052] In step n, to enable the A11-registration request, PDSN108 accepts and displays the A11-registration response message and replies with the set duration value. A11-Before returning the registration response, PDSN108 saves the billing data for the next process (if received). The PCF stops the timer Tregreq.
[0053] An eighth aspect of the present invention provides a preferred embodiment of the inter-PCF dormant handoff process for CCPD MS when the MS is serviced by a novel PDSN. While the packet data session is in dormant mode, the MS detects changes in PZID, SID, or NID. Upon detection of a new PZID, SID, or NID, the MS sends a call message containing the packet data service option and the SDB_DESIRD_ONLY bit set to 0 to the target BS. FCH_SUPPORTED if the call is to a CCPD device The bit and the DCCH_SUPPORTED bit are also set to 0. The target PCF establishes an A10 connection with the target PDSN. The target PCF is required to transfer the PANID of the source PCF and the CANID of the target PCF to the serving PDSN. PPP connection establishment and MIP registration occur using SDB on a common channel. When the MIP registration timer times out, the source PDSN opens the A10 connection with the source PCF. The target PCF periodically re-registers with the PDSN using the A11-registration request message before the A10 connection duration times out.
[0054] The process described above may also be used if the network decides to start the CCPD service for a dormant mode handoff. In such cases, the MS sends a call message with the SDB_DESIRED_ONLY bit set to 0. The SDB first sent to the MS indicates that the CCPD procedure will be used to support the dormant mode handoff.
FIG. 9 will be described. A flow diagram of a preferred embodiment of the CCPD MS PCF inter-dormant handoff process when the MS202 is serviced by the new PDSN902 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. This process assumes that CCPD MS202 has previously performed PPP connection establishment and MIP registration with PDSN904 and is currently maintaining a Dormant Packet Data Service instance. When a new PZID is detected in step a, CCPD The MS202 sends a call message with the SDB_DESIRED_ONLY bit set to 1 to the target BS802. In step b, the target BS802 confirms the response of the incoming call message to the MS202 with the base station confirmation response instruction. In step c, BS802 sends an additional forwarding message to MSC110. The message contains the authentication parameters received from MS202, the BS-calculated authentication data element, and the data burst type fields of the additional user part elements set in the SDB. If the target BS802 determines that the CCPD MS202 supports the traffic channel, the other option is for the target BS802 to perform the MS Dormant mode handoff procedure described in 3GPP2 A.S0001-A Section 2.15.5.9. You may. Target BS802 activates timer T60.
[0056] In step d, the MSC110 sends the reason value to the target BS802 without displaying the reason value in the additional transfer confirmation response message. Target BS802 cancels timer T60. If the authentication of MS202 fails, MSC110 puts the reason value of "authentication failure" in the message. In step e, the target PCF802 sends an A11-registration request message to the PDSN902 to invoke the A10 connection establishment. The registration request message contains a move event indicator within the vendor / organization identification extension. PCF802 activates the timer Tregreq. In step f, the A11-registration request is valid and the target PDSN902 returns an A-11 registration response with an acceptance indication and a data availability indicator in the vendor / organization identification extension to accept the connection. PCF802 stops the timer Tregreq.
[0057] In step g, the MS202 and target PDSN902 exchange SDBs on a common channel to establish a link layer (PPP) connection and perform the MIP registration procedure. The first SDB sent from BS802 to MS202 acts as an acknowledgment to the MS CCPD service request. Assume that the packet data service instance of MS re-enters the dormant state. If the network or MS202 has transmit data, the data will be transmitted using SDB on the common channel according to the CCPD procedure.
[0058] In step h, when the MIP registration timer times out, the source PDSN108 sends an A11-registration update message to initiate the termination of the A10 connection with the source PCF602. The source PDSN108 activates the timer Tregupd. In step i, the source PCF602 responds with an A11-registration confirmation response message. The source PDSN108 stops the timer Tregupd. In step j, the source PCF602 sends an A-11 registration request message with billing-related information and a duration set to 0 to the source PDSN108. The source PCF602 activates the timer Tregreq. In step k, before returning the A11-registration response, the source PDSN108 saves the billing related information for the next data processing. Source PCF602 terminates the MS202 A10 connection. Source PCF602 stops timer Tregreq. In step l, the target PCF802 sends an A11-registration request message to refresh the registration of the A10 connection with the target PDSN902 before the registration duration timer (Trp) times out. A11-Registration request messages are also used to send billing and other information to the target PDSN902. Billing relationships and other information are sent at system-defined trigger points. The target PCF802 activates the timer Tregreq. In step m, to enable the A11-registration request, the target PDSN902 accepts and displays the A11-registration response message and replies with the set duration value. A11-Before returning the registration response, the target PDSN902 saves billing related and other information (if received) for the next process. PCF802 stops the timer Tregreq.
[0059] As described above, an embodiment of the present invention that supports a common channel packet data (CCPD) service in cdma2000 RAN provides a method of transmitting data between a network and an MS without using a traffic channel. It is a thing. Without using the traffic channel, a packet data session can be launched, a dormant mode handoff can be performed, or all packet data can be exchanged. Moreover, once the MS is successfully registered on the network, the A8 connection between the PCF and PDSN no longer needs to support packet data services.
Although various modifications and alternatives are envisioned in the present invention, specific embodiments have been illustrated and described herein as examples. However, it should be understood that the present invention is not limited to the particular form disclosed. Rather, the invention covers all modifications, equivalents and other alternatives within the spirit and scope of the invention as described in the claims.
As described above, according to the present invention, the CCPD service in the CDMA2000 random access network is inexpensively supported by using the common channel without using the traffic channel. ..
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing relationships between devices and network components that support CCPD (Common Channel Packet Data) services in the present invention. is there.
FIG. 2 is a block diagram of a preferred embodiment showing a CCPD calling process initiated by MS in the present invention.
FIG. 3 is a block diagram of a preferred embodiment showing the process of terminating packet data transfer to a CCPD device terminating MS when the MS is in a dormant packet data state in the present invention.
FIG. 4 is a block diagram of a preferred embodiment showing a normal inter-PCF / intra-PDSN CCPD MS dormant mode handoff process in the present invention.
FIG. 5 is a block diagram of a preferred embodiment showing a normal PCF-to-PDSN-to-PDSN CCPD MS dormant mode handoff process in the present invention.
FIG. 6 is a block diagram of a preferred embodiment showing the process of receiving packet data from a PDSN and delivering its SDB to an MS in the present invention.
FIG. 7 is a block diagram of a preferred embodiment showing a CCPD calling process initiated by MS when the BS and PCF of FIG. 1 are configured as a single unit in the present invention.
FIG. 8 is a block diagram of a preferred embodiment showing the process of dormant handoff between CCPD MS PCFs when MS is serviced by the same PDSN in the present invention.
FIG. 9 is a block diagram of a preferred embodiment showing the process of dormant handoff between CCPD MS PCFs when the MS is serviced by the new PDSN in the present invention.
[Code Description] 102, 104 ... Base system, 106 ... (Source) Packet control function, 108 ... Packet data service node, 110 ... Controller, 202 ... Mobile, 402. .. Target packet control function, 108602 ... (source) base system / packet control function, 802 ... target base system / packet control function.
Every citation, both waysCites: the store holds 2 of 3
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO2009147967A1 | Cited by | World Intellectual Property Organization (WIPO) | Applicant |
| JP2001527737A | Cites | Japan | – |
| WO99053695A1 | Cites | World Intellectual Property Organization (WIPO) | – |
45 members in 14 offices
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 28198901 | United States of America | P | |
| 28198901 | United States of America | P | |
| 60281989 | United States of America | – | |
| 10095190 | United States of America | – | |
| 9519002 | United States of America | A | |
| 9519002 | United States of America | A | |
| 2001281989 | – | – | – |
| 2002095190 | – | – | – |
| US20010281989P | – | – | – |
| US20020095190 | – | – | – |
Members45
| Document | Office | Kind | |
|---|---|---|---|
| CA2398642A1 | Canada | A1 | |
| WO0154685A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU3467101A | Australia | A | |
| US2001041685A1 | United States of America | A1 | |
| US2002145990A1 | United States of America | A1 | |
| US2002147216A1 | United States of America | A1 | |
| KR20020077663A | Republic of Korea | A | |
| US2002165244A1 | United States of America | A1 | |
| EP1255544A1 | European Patent Office (EPO) | A1 | |
| CN1380764A | China | A | |
| JP2002338493A | Japan | A | |
| JP2002338494A | Japan | A | |
| JP2002369259A | Japan | A | |
| CA2455975A1 | Canada | A1 | |
| WO03011294A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2003236220A1 | United States of America | A1 | |
| JP2004507444A | Japan | A | |
| WO03011294A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US6737427B2 | United States of America | B2 | |
| EP1418914A2 | European Patent Office (EPO) | A2 | |
| CA2505557A1 | Canada | A1 | |
| WO2004043392A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2003287621A1 | Australia | A1 | |
| KR100439619B1 | Republic of Korea | B1 | |
| WO2004043392A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO2004043392B1 | World Intellectual Property Organization (WIPO) | B1 | |
| US2004254096A1 | United States of America | A1 | |
| CN1184765C | China | C | |
| EP1255544A4 | European Patent Office (EPO) | A4 | |
| AR042578A1 | Argentina | A1 | |
| EP1562903A2 | European Patent Office (EPO) | A2 | |
| JP2006513165A | Japan | A | |
| AU2001234671B2 | Australia | B2 | |
| EP1562903A4 | European Patent Office (EPO) | A4 | |
| EP1255544B1 | European Patent Office (EPO) | B1 | |
| AT355836T | Austria | T | |
| DE60127098D1 | Germany | D1 | |
| US7209462B2 | United States of America | B2 | |
| PT1255544E | Portugal | E | |
| DK1255544T3 | Denmark | T3 | |
| ES2282235T3 | Spain | T3 | |
| DE60127098T2 | Germany | T2 | |
| JP4043827B2This record | Japan | B2 | |
| US7345051B2 | United States of America | B2 | |
| US7504409B2 | United States of America | B2 |
43 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313111S111 | S111 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4043827
- Publication, DOCDB
- 4043827
- Publication, EPODOC
- JP4043827B
- Application
- 103213
- Application, DOCDB
- 2002103213
- Application, EPODOC
- JP20020103213
Titles2
- English
- How to Support Common Channel Packet Data Services in CDMA2000 RAN
- Japanese
- CDMA2000RANにおける共通チャンネル・パケット・データ・サービスをサポートする方法
Classification
- CPC, 6
- H04W76/12
- H04W80/04
- H04W72/0406
- H04W76/18
- H04W72/20
- H04L2012/5603
- IPC, 4
- H04Q7 38
- H04J13 00
- H04L29 08
- H04W36 08