WO2009065363A1 - Method, apparatus and system for realizing prepayment in the network - Google Patents

Abstract

A method for realizing prepayment in the network is provided, the method includes: sending a switching request from a source anchor DPF to a terminal anchor DPF, the anchor DPF switching request containing quota information; sending an anchor DPF switching determining information to the terminal anchor DPF after the source anchor DPF receipting of the switching respond of the terminal Anchor DPF, the anchor DPF switching determining information containing quota compensate information. The method for realizing prepayment in the network can implement and support prepayment service in the network.

Description

 Method, device and system for realizing prepayment in a network

 The present invention relates to the field of communications, and in particular, to a method, apparatus, and system for implementing prepaid in a network. Background art

 WiMAX (Worldwide Interoperability for Microwave Access), the full name of Chinese is global access microwave interoperability, is a wireless metropolitan area network technology based on IEEE 802.16 standard. The WiMAX network is mainly composed of three parts: user terminal (MS), access service network (ASN), and connection service network (CSN). The ASN includes a base station (BS) and an access service network gateway (ASN GW). The Connected Services Network (CSN) includes logical entities such as Book Policy Server (PF), Authentication, Authorization and Accounting Server (AAA Server), and Application Server (AF). The wireless side of the WiMAX network is a wireless metropolitan area network access technology based on the IEEE 802.16d/e standard. The main focus now is the IEEE 802.16-2004 (802.16d) standard, which was enacted in July 2004. The WiMAX network structure is shown in Figure 1:

 The R1 interface is a wireless air interface and is mainly defined by IEEE802.16d/e. The remaining interfaces are all wired interfaces.

WiMAX NWG (Net Work丄 ng Group, Ρ ⁄ 各 ) ) ) ) ⁄ ⁄ QoS QoS (Quality ty of Service) framework shown in Figure 2:

 The description of each functional entity in this framework is as follows:

 MS (Mobile Station) is a mobile user terminal;

 SFM (Service Flow Management) is a service flow management entity that is responsible for establishing user service flows and allocating radio resources for this service flow. This function exists in the ASN.

 SFA (Service Flow Authorization) is a service flow licensor responsible for authorizing the corresponding service flow. This function exists in the ASN.

 PF (Policy Function) is a policy function entity that provides a policy for a user service flow. This function exists in the NSP. In the roaming scenario, there will be a Visited PF and a Home PF.

 AAA (Authentication, Authorization, and Accounting) is a system that provides authentication, authorization, and accounting services. It is responsible for saving the user's QoS profile and related policy rules.

 AF (Application Function) is an application service function entity. The user terminal MS directly accesses the AF through the application layer protocol. The AF will notify the PF to actively create a service flow for the user. This function exists in the NSP.

Figure 3 is a schematic diagram of the existing WiMAX NWG standard charging architecture. As shown in Figure 3, the MS is equivalent to the user end in charging. The accounting client or the accounting agent is used to collect all accounting information and provide it to the AAA proxy (AAA Proxy) or AAA Server (when the AAA proxy is not present); The PPC is used to interact with the prepaid server to provide prepaid service support for the user. The PPC can be combined with the Accounting Client or the Accounting Agent. The AAA Proxy is an optional intermediate device for receiving the received charging information. After processing, a new accounting information is generated and forwarded to the AAA server, such as the home AAA server or the visited AAA server (Visited AAA Server); the home AAA server is the home AAA server, that is, the user initially registered AAA. The server or the AAA server of the user's home location, the home AAA server stores the user's subscription information, including the charging policy, and the user's charging processing is mainly completed in the home AAA server; the visiting AAA server is the AAA of the user's visited place. The server is used to implement billing information recording, transparent transmission, and forwarding when the user roams.

 In the existing WiMAX NWG protocol, for the implementation of the prepaid function, only the prepaid client PPC and the Authenticator are located in the same entity, and the PPC acts as a prepaid client to exchange prepaid related signaling with the PPS. However, when the PPC is not located in the data plane entity, there may be a case where the prepaid agent (PPA) is located in the data plane entity. At this time, only the function of the PPA for measurement is defined, and the function implementation is not clearly defined. In addition, there is no definition of the signaling interaction and flow between PPA and PPC, and how the prepaid function is implemented. Also, the support of prepaid in the case of Anchor DPF migration or Authenticator migration is not considered. Since the interaction between the PPA and the PPC is not defined, and the migration scenario is not considered, the prepaid service cannot be supported when the PPA and the PPC are separated. Summary of the invention

 In view of this, embodiments of the present invention provide a method, apparatus, and system for implementing prepaid in a network, and the method, apparatus, and system can implement prepaid services in a network.

 A method for implementing prepaid in a network, the method comprising:

 The source Anchor DPF sends an Anchor DPF switch request to the target Anchor DPF, and the Anchor DPF switch request carries the quota information;

 After the source Anchor DPF receives the switch response sent by the target Anchor DPF, it returns to the target Anchor DPF.

The Anchor DPF handover confirmation message carries the quota compensation information.

 A method for implementing prepaid in a network, the method comprising:

 The source prepaid agent PPA sends a handover request to the target PPA, where the handover request carries quota information;

 After receiving the handover response sent by the target PPA, the source PPA sends a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.

A method for implementing prepaid in a network, the method comprising: The target PPC receives the notification message sent by the source PPC, where the notification message carries the session information related to the prepaid service of the source PPC;

 The target PPC sends a request message to the prepaid server PPS to request to establish a new session, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate a new session and source that needs to be established currently. The association of PPC sessions.

 A source prepaid agent PPA, the source PPA includes:

 a sending module, configured to send a handover request to the target PPA, where the handover request carries quota information; and a receiving module, configured to receive a handover response sent by the target PPA;

 After the receiving module receives the handover response sent by the target PPA, the sending module is configured to send a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.

 A system for implementing prepaid in a network, the system includes a source prepaid agent PPA, and the source PPA is configured to send a handover request to a target PPA and receive a handover response sent by a target PPA, where the handover request carries quota information. After receiving the handover response sent by the target PPA, the source PPA is configured to send a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.

 A target prepaid client PPC, the target PPC comprising:

 a notification message receiving module, configured to receive a notification message sent by the source PPC, where the notification message carries session information related to the prepaid service of the source PPC;

 a request message sending module, configured to send a request message to the prepaid server PPS, to request to establish a new session, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate that the current need to be established The association between the new session and the session of the source PPC.

 A system for implementing prepaid in a network, the system comprising a target prepaid client PPC, the target PPC is configured to receive a notification message sent by a source PPC, and send a request message to a prepaid server PPS to request to establish a new The session message, the notification message carries session information related to the prepaid service of the source PPC, the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate a new session that needs to be established currently. The association with the session of the source PPC.

 In the method for implementing the prepaid in the network, the Anchor DPF or the PPA handover request carries the quota information, and the Anchor DPF or the PPA handover confirmation message carries the quota compensation information, so that the prepaid service can be supported in the network. DRAWINGS

1 is a schematic diagram of an existing WiMAX network structure; Figure 2 is a QoS framework diagram of the existing WiMAX NWG standard;

 FIG. 3 is a schematic diagram of an existing WiMAX NWG standard charging architecture;

 4 is a flowchart of a method for prepaid in an Anchor DPF migration scenario according to an embodiment of the present invention;

 5 is a flowchart of a method for prepaid in an Authenticates migration scenario according to an embodiment of the present invention;

 FIG. 6 is a flowchart of a method for prepaid in an Authenticates migration scenario according to an embodiment of the present invention. detailed description

 The technical solutions provided by the embodiments of the present invention are further described in detail below with reference to the accompanying drawings.

 The embodiments of the present invention provide a solution for information query between functional entities in a PCC structure. Referring to FIG. 4, FIG. 4 is a flowchart of a method for querying information in a PCC structure according to an embodiment of the present invention. The process may include the following steps. The present invention is further described below with reference to the accompanying drawings and specific embodiments, but the present invention is not limited thereto. The following examples. The present invention implements a method of prepaid in a network, wherein the network can be various networks such as a GSM network, a CDMA network, a WiMAX network, and the like. In various embodiments of the present invention, a method of implementing prepaid in a WiMAX network is taken as an example for illustration.

 PPC (Prepaid Cl ient) is located in the same physical entity as the authenticator Authenticator.

PPC can interact with PPS (Prepaid Server, Prepaid Server). The PPA (Prepaid Agent) is located on the data plane entity, such as the anchor data path function entity Anchor DPF or the service data path entity Serving DPF or the base station BS. The following takes the PPA in the Anchor DPF as an example.

 The embodiment of the invention provides a method for prepaid in an Anchor DPF migration scenario. There are two scenarios that can occur when Anchor DPF migration occurs:

 (1) The first Anchor DPF migration occurs after the user terminal is initially connected to the network. At this time, the PPC is located in the data path, which can be regarded as a special scenario where the PPC and the PPA are in the same physical entity.

 (2) In the scenario where the user terminal is separated from the Authenticator, the PPC and the PPA are separated, and the Anchor DPF migration occurs again.

 The following describes the prepaid method in the Anchor DPF migration scenario in the PMIPv4 scenario. Referring to FIG. 4, the method includes: Step 401: In the pull mode, the Anchor DPF switching indication is sent by the target Anchor DPF to the source Anchor DPF; if it is the push mode, this step can be omitted, and the process directly proceeds to step 402.

Step 402: The source Anchor DPF sends an Anchor DPF switch request to the lj target Anchor DPF. The Anchor DPF switch request carries the quota information, where the quota information includes the quota identifier, the quota size, the current quota usage, the quota threshold, and the rate information corresponding to the quota. And one or a combination of the service classifier information corresponding to the quota and the service flow information corresponding to the quota (including the service flow identifier or the packet data flow identifier). The Anchor DPF switch request carries Anchor at the same time. Anchored mobility management context Anchor MM Context ₀ required for DPF migration

 Steps 403 to 408: The Anchor DPF migration process for normal PMIPv4. The target Anchor DPF sends an Anchor DPF migration request to the PMIP Client according to the Anchor MM Context. After verifying the validity of the target Anchor DPF, the PMIP client returns an FA registration request message to the target Anchor DPF. After the target Anchor DPF receives the FA registration request message, the target is passed. 405, 406 complete the mobile IP registration process of the new FA, and after receiving the registration response, return an FA registration response message to the PMIP client; the target Anchor DPF notifies the source Anchor DPF migration completion through step 408.

 In the above steps, before the target Anchor DPF completes the mobile IP registration, the data sent by the user terminal is still transmitted through the source Anchor DPF; that is, after the quota information is transmitted in step 402, the quota above the source Anchor DPF is still being used; After the target Anchor DPF registration is completed, the data is transferred to the target Anchor DPF for transmission. The source Anchor DPF/PPA stops the prepaid charging management when receiving the Anchor DPF handover response message in step 408; and the target Anchor DPF/PPA starts prepaid charging for the downlink data after step 405, in step 406. After that, the prepaid billing for the uplink data is started.

 Step 409: After the source Anchor DPF receives the Anchor DPF handover response message sent by the target Anchor DPF, it returns an Anchor DPF handover confirmation message to the target Anchor DPF. The Anchor DPF handover confirmation message carries the quota compensation information, where the quota compensation information is used to indicate the quota consumed by the user terminal service in the foregoing handover process, and the quota compensation information may be used in an incremental manner, or may be completed in step 402. The quota information is passed.

 After the target Anchor DPF/PPA receives the quota compensation information, it uses the quota compensation information to update the prepaid quota it maintains, and deducts the quota consumed during the above switching process.

 After the PPC is separated from the PPA, the PPA is used as the pre-paid execution point. According to the quota information obtained in the foregoing, the Anchor DPF located in the same entity as the PPA collects the charging according to the service classifier and/or service flow information corresponding to the quota in the quota information. Data, deducted from the quota. The PPC acts as an interface entity between the PPA and the PPS, and maintains information required to interact with the PPS, such as user identification and quota identification.

 As described above, in the migration process of the Anchor DPF, after the target Anchor DPF has reported the quota information, the data is still transmitted through the source Anchor DPF for a period of time. There may be two scenarios: The quota usage reaches the threshold and The quota is exhausted.

 The first scenario: quota usage reaches the threshold

Manner 1: The source Anchor DPF/PPA no longer requests the quota, but informs the target Anchor DPF/PPA through the aforementioned quota compensation information after the migration is completed. After the target Anchor DPF/PPA obtains the quota compensation information, it determines whether the quota usage has reached the threshold (but the quota is not exhausted). If the quota usage of the target Anchor DPF/PPA has reached the threshold, then a quota request is initiated to apply for a new quota. If the quota usage of the target Anchor DPF/PPA does not reach the threshold, Then continue the normal process.

 Manner 2: After the source Anchor DPF detects that the quota usage reaches the threshold, it immediately sends the quota compensation information to the target Anchor DPF. After receiving the quota compensation information, the target Anchor DPF determines that the quota usage has reached the threshold, and the target Anchor DPF/PPA. Initiate a quota request process to obtain a new quota.

 If the target Anchor DPF migration process fails, the target Anchor DPF notifies the source Anchor DPF/PPA of its newly requested quota.

 Mode 1 and mode 2 can be merged. The source Anchor DPF notifies the target Anchor DPF immediately after the threshold is reached. The target Anchor DPF can not initiate the quota request temporarily, but after obtaining the quota compensation information, it is judged that the quota usage reaches the threshold. Re-initiate the quota request.

 The second scenario: quota exhaustion

 In the scenario where the quota is exhausted, the difference from the foregoing quota usage threshold is that the target Anchor DPF/PPA directly sends a message to terminate the service instead of requesting the quota again.

 Manner 1: The same processing method as described above can be used. The target Anchor DPF/PPA judges that the quota is exhausted and triggers the termination of service. The source Anchor DPF/PPA can discard data other than the quota.

 Manner 2: During the switchover process, if the source anchor DPF detects that the quota is exhausted, the source anchor DPF/PPA sends the quota compensation information to notify the target that the Anchor DPF quota is exhausted. After the target DPF determines that the quota is exhausted, it starts the process of exhausting the quota, such as triggering the release of the service flow or triggering the user to leave the network.

 The embodiment of the present invention further provides a method for prepaid when the Anchor DPF migration occurs in the process of requesting a quota. This method is roughly the same as the method described in Figure 4, except that:

 After the source anchor DPF detects that the quota usage reaches the threshold, it initiates a quota request to the PPS. The Anchor DPF switch request carries the quota information, and carries the identifier to notify the target Anchor DPF/PPA that the quota request has been initiated. The target Anchor DPF/PPA does not initiate the quota request according to the identifier; after the source Anchor DPF obtains the new quota, The quota compensation information carries the new quota information to inform the target Anchor DPF/PPA.

 If the source anchor DPF/PPA does not get a new quota in the quota request response, it can be processed according to the quota usage mentioned above to reach the threshold/quota exhaustion process.

 An embodiment of the present invention provides a source PPA, where the source PPA includes a sending module and a receiving module. The sending module is configured to send a handover request to the target PPA, where the handover request carries quota information. The receiving module is configured to receive a switching response sent by the target PPA. After the receiving module receives the handover response sent by the target PPA, the sending module is configured to send a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.

Embodiments of the present invention provide a system for implementing prepaid in a network, where the system includes a source PPA. The source PPA is configured to send a handover request to the target PPA and receive a handover response sent by the target PPA, where the handover request carries quota information. In After receiving the handover response sent by the target PPA, the source PPA is configured to send a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.

 In summary, in the embodiment of the present invention, the source Anchor DPF/PPA sends an Anchor DPF handover request to the target Anchor DPF/PPA, and the Anchor DPF handover request carries the quota information, and after the source Anchor DPF/PPA receives the handover response, , Returns the Anchor DPF switch confirmation message to the target Anchor DPF/PPA. The Anchor DPF handover confirmation message carries the quota compensation information, so that the prepaid service can be implemented in the network.

 The embodiment of the invention further provides a method for prepaid in an Authenticates migration scenario.

 Since the PPC is in the same physical entity as the Authenticator, the migration process of the PPC is the same process as the migration of the Authenticator. Figure 5 shows the Authenticator migration in the pull mode. For the push mode, the direction of the trigger is different, and the process is generally the same, and will not be described here.

 Steps 501 to 502: The target Authenticator requests and obtains the authentication context information of the user terminal from the source Authenticator.

 Step 503: The user terminal performs a re-authentication process through the target Authenticator, and the Authenticator of the user terminal migrates to the lj target Authenticates along with the re-authentication process.

 Steps 504~506: After the user terminal completes the re-authentication through the target Authenticator, the target

The Authenticator returns to the source Authenticator to confirm that the migration was successful.

 As mentioned above, the PPC acts as an interface between the PPA and the PPS, and maintains information about the PPS interaction quota request, such as quota identification, rate identification, and service identification. With the Authenticator migration, the above information needs to be migrated along with the PPC. In step 505, the foregoing information needs to be carried, including a quota identifier, a rate identifier, a service identifier, and the like. At the same time, since the PPC has been migrated, it is considered that the validity of the quota identifier needs to be maintained, and the quota identifier is required to be valid within the scope of the user terminal.

 In the embodiment shown in FIG. 5, the Radius protocol is used as a scenario in which the PPC interacts with the PPS. Considering the scenario in which the Diameter protocol is used as the PPC and PPS interaction protocol, the embodiment of the present invention further provides a method for prepaid in the Authenticator migration scenario. Due to the difference between the Diameter and the Radius protocol, the Diameter Session (Diameter Session) between the source PPC and the PPS needs to be released after the PPC migration, and a new Diameter Session needs to be established between the target PPC and the PPS, and between the source PPC and the PPS. The release of the Diameter Session should not affect the current pre-paid service of the user terminal. Therefore, in this embodiment, when establishing a new Diameter Session, the association relationship with the original Diameter Session is specified, so that the PPS can directly directly pre-paid the service. Move to the new Diameter Session.

Since the PPC is located in the same physical entity as the Authenticator, the migration process of the PPC is the same process as the migration of the Authenticator. Figure 6 shows the Authenticator migration in the pull mode. For the push mode, only the direction of the trigger is different, and the process is basically the same, and will not be described here. Steps 601 to 602: The target Authenticator/PPC requests the source Authenticator/PPC and obtains the authentication context information of the user terminal.

 Step 603: The user terminal performs a re-authentication process through the target Authenticator/PPC.

 Step 604: After the re-authentication succeeds, the target Authenticator/PPC sends a Context R ort message to the prepaid proxy PPA to update the Authenticator/PPC information it maintains.

 Step 605: The prepaid agent updates the Authenticator/PPC information that is maintained by the prepaid agent, and returns a Context Ack message to the target Authenticator/PPC. The Context Ack message carries the quota information, where the quota information includes the quota identifier, the quota size, and the current quota usage. The quota threshold, the rate information corresponding to the quota, the service classifier information corresponding to the quota, and one or a combination of the service flow information (including the service flow identifier or the packet data flow identifier) corresponding to the quota.

 Step 606: The target Authenticator/PPC sends a Relocation Complete Req message to the source Authenticator/PPC, and notifies the source Authenticator/PPC: the re-authentication of the user terminal is completed. The Authenticator/PPC can determine whether the quota information needs to be carried in the Relocation Complete Req message according to a policy or the like.

 Step 607: The source Authenticator/PPC returns a Relocation Complete Rsp message to the target Authenticator/PPC, where the Relocation Complete Rsp message carries the current Diameter Session information of the source Authenticator/PPC, and the Diameter Session information is related to the prepaid service, including the quota identifier, the session. Identification Session-ID, Association ID CC-Correlation_ID, Charging Session ID, Service Identity Service_ID, Service Context ID Service-Context-ID, Rate Information Rating-Group, and corresponding Service Flow Information (Service Flow ID or Packet Data Flow Identifier) One or a combination thereof.

Steps 608 to 609: For each prepaid service, the target Authenticator/PPC sends a Credit Control Request message to the prepaid server PPS to request to establish a new Diameter Session. The Credit Control Request message carries the Diameter Session information of the source Authenticator/PPC obtained in step 607, and carries an association indication, which is used to indicate that a new Diameter Session that needs to be established and a Diameter Session of the source Authenticator/PPC are The same prepaid service has an associated session. After receiving the Credit Control Request message, the PPS transfers the prepaid service information on the Diameter Session of the source Authenticator/PPC to the target Authenticator/PPC according to the Diameter Session information of the source Authenticator/PPC and the associated indication carried therein. The new Diameter Session. At the same time, the quota control information obtained in step 605 may be carried in the Credit Control Request message to update the quota resources maintained on the PPS. The PPS returns a Credit Control Answer message to the target Authenticator/PPC to confirm that a new Diameter Session has been established. If the target Authenticator/PPC requests to update the quota resource on the PPS, the Credit Control Answer message may carry a new quota indication, the quota. Indication including service identification Service-ID, rate information Rating_Group, service context ID Service-Context_ID, quota size, one of the quota thresholds, or a combination thereof.

 Steps 610 to 611: If the target Authenticator/PPC updates the quota resource from the PPS in steps 608 to 609, the target Authenticator/PPC needs to deliver the obtained quota to the prepaid agent. In this embodiment, Context Report/Ack is used. The message is described as an example. The foregoing quota information is carried in the Context Report/Ack message. After the prepaid agent obtains the quota information, it updates the prepaid quota maintained by it in combination with the prepaid quota used in the period of steps 605 to 611.

 Step 612: The target Authenticator/PPC returns a Relocation Complete Ack message to the source Authenticator/PPC.

 Step 613-614: The source Authenticator/PPC sends a Credit Control Request message to the PPS to request to release the Diameter Session corresponding to the prepaid service of the user terminal, where the Credit Control Request message indicates that the prepaid service carried by the Diameter Session does not end. , and is inherited by other sessions; PPS does not need to release the prepaid service context corresponding to the Diameter Session, and does not need to revoke the prepaid quota allocated to it. The PPS returns a Credit Control Answer message to the source Authenticator/PPC to confirm the release of the Diameter Session.

 An embodiment of the present invention provides a target PPC, where the target PPC includes a notification message receiving module and a request message sending module.

 The notification message receiving module is configured to receive a notification message sent by the source PPC, where the notification message carries session information related to the prepaid service of the source PPC.

 The request message sending module is configured to send a request message to the prepaid server PPS to request to establish a new session, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate a new The relationship between the session and the session of the source PPC.

 Embodiments of the present invention provide a system for implementing prepaid in a network, where the system includes a target PPC. The target PPC is configured to receive the notification message sent by the source PPC, and send a request message to the prepaid server PPS to request to establish a new session, where the notification message carries the session information related to the prepaid service of the source PPC, where the request message carries the source. The session information of the PPC and the association indication, the association indication is used to indicate the association relationship between the new session that needs to be established and the session of the source PPC.

In summary, in the embodiment of the present invention, during the Authenticator/PPC migration, the Diameter Session information related to the prepaid service is transmitted between the source Authenticator/PPC and the target Authenticator/PPC, and the target Authenticator/PPC is newly established with the PPS. In the Diameter Session, the association relationship with the Diameter Session of the source Authenticator/PPC is specified, so that the PPS can pre-paid the service on the source Diameter Session. The information is migrated to the new Diameter Session to ensure the continuity of the prepaid service of the user terminal, so that the prepaid service can be implemented in the network.

 In conclusion, the above is only a demonstration of the spirit of the present invention, and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim A method for implementing prepaid in a network, the method comprising:  The source anchor DPF sends an Anchor DPF switch request to the target Anchor DPF, where the Anchor DPF switch request carries quota information.  After receiving the handover response sent by the target Anchor DPF, the source Anchor DPF returns an Anchor DPF handover confirmation message to the target Anchor DPF, where the Anchor DPF handover confirmation message carries quota compensation information.  The method for implementing prepaid in a network according to claim 1, wherein the quota information includes a quota identifier, a quota size, a current quota usage amount, a quota threshold, a rate corresponding to the quota, and a quota corresponding to the quota information. One or a combination of the service classifier information and the service flow information corresponding to the quota.  3. The method for implementing prepaid in a network according to claim 1, wherein the quota compensation information is transmitted in an incremental manner or transmitted using a complete quota information.  4. A method for implementing prepaid in a network, the method comprising:  The source prepaid agent PPA sends a handover request to the target PPA, where the handover request carries quota information;  After receiving the handover response sent by the target PPA, the source PPA sends a handover confirmation message to the target PPA, where the handover confirmation message carries quota compensation information.  5. A method for implementing prepaid in a network, the method comprising:  The target prepaid client PPC receives the notification message sent by the source PPC, and the notification message carries the session information related to the prepaid service of the source PPC;  The target PPC sends a request message to the prepaid server PPS to request to establish a new session, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate a new session that needs to be established currently. The association relationship with the session of the source PPC.  The method for implementing prepaid in a network according to claim 5, wherein the session information includes a quota identifier, a session identifier, an association identifier, a charging session identifier, a service identifier, a service context identifier, and a rate. One or a combination of information and corresponding business flow information.  The method for implementing the pre-payment in the network according to claim 5, wherein the association indication is used to indicate that the association relationship between the new session that needs to be established and the session of the source PPC is specifically:  The association indication is used to indicate that the new session that needs to be established is the session associated with the source PPC that is associated with the same prepaid service. The method for implementing pre-payment in a network according to claim 5, wherein the method further comprises the steps of: The target PPC sends a report message to the prepaid agent PPA to update the PPC information it maintains. After the PPA updates the PPC information maintained by the PPA, the target PPC receives the acknowledgement message returned by the PPA, and the acknowledgement message carries the quota information. The quota information includes: a quota identifier, a quota size, a current quota usage, a quota threshold, a rate information corresponding to the quota, a service classifier information corresponding to the quota, and one or a combination of the service flow information corresponding to the quota.  The method for implementing pre-payment in a network according to claim 8, wherein the request message further carries the quota information to update a quota resource maintained on the PPS.  The method for implementing pre-payment in a network according to claim 5, wherein the method further comprises:  The target PPC receives an acknowledgment that the PPS returns an acknowledgment that a new session has been established.  The method for implementing pre-payment in a network according to claim 10, wherein the answer message carries a quota indication, where the quota indication comprises: a service identifier, a rate information, a service context identifier, a quota size, One or a combination of quota thresholds.  12. A source prepaid agent PPA, wherein the source PPA comprises:  a sending module, configured to send a handover request to the target PPA, where the handover request carries quota information; and a receiving module, configured to receive a handover response sent by the target PPA;  After the receiving module receives the handover response sent by the 0-label PPA, the sending module is configured to send a handover confirmation message to the 0-label PPA, where the handover confirmation message carries the quota compensation information.  The source prepaid agent according to claim 12, wherein the quota information includes a quota identifier, a quota size, a current quota usage amount, a quota threshold, a rate information corresponding to the quota, and a service classifier corresponding to the quota. One or a combination of information and service flow information corresponding to the quota.  A system for implementing prepaid in a network, the system includes a source prepaid agent PPA, and the source PPA is configured to send a handover request to a target PPA and receive a handover response sent by the target PPA. The handover request carries the quota information. After receiving the handover response sent by the target PPA, the source PPA is configured to send a handover confirmation message to the target PPA, where the handover confirmation message carries the quota compensation information.  A target prepaid client PPC, wherein the target PPC comprises:  a notification message receiving module, configured to receive a notification message sent by the source PPC, where the notification message carries session information related to the prepaid service of the source PPC; a request message sending module, configured to send a request message to the prepaid server PPS, to request to establish a new session, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate that the current need to be established The association between the new session and the session of the source PPC. The target prepaid client according to claim 15, wherein the session information includes a quota identifier, a session identifier, an association identifier, a charging session identifier, a service identifier, a service context identifier, a rate information, and a corresponding One or a combination of business flow information.  The target prepaid client according to claim 15, wherein the association indication is used to indicate that the association between the new session that needs to be established and the session of the source PPC is specifically:  The association indication is used to indicate that the new session that needs to be established is the session associated with the source PPC that is associated with the same prepaid service.  18. A system for implementing prepaid in a network, the system comprising a target prepaid client PPC, the target PPC for receiving a notification message sent by a source PPC, and sending a request message to a prepaid server PPS. And requesting to establish a new session, where the notification message carries session information related to the prepaid service of the source PPC, where the request message carries session information of the source PPC and an association indication, where the association indication is used to indicate current needs The relationship between the established new session and the session of the source PPC.