PATENT DOCUMENT

Abstract:
A method and an apparatus for creating an Internet Protocol Connectivity Access Network (IP-CAN) session are disclosed herein. The method includes: creating, by a First Policy and Charging Enforcement Function entity, PCEFa entity, a session with a Policy and Charging Rules Function entity, PCRF entity; performing, by the PCEFa entity, mobility registration with a second Policy and Charging Enforcement Function entity, PCEFb entity; creating, by the PCEFb entity, a session with the PCRF entity; and sending, by the PCRF entity, a session information to the PCEFa entity and the PCEFb entity. mobility The apparatus includes: a PCEFa entity, a PCEFb entity, and a PCRF entity. The method and the apparatus for creating an IP-CAN session under the present disclosure accomplish the purpose of creating an IP-CAN session in the new PCC architecture.

Full Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 12/704,679, filed on Feb. 12, 2010, which is a continuation of International Application No. PCT/CN2008/071989, filed on Aug. 14, 2008. The International Application claims priority to Chinese Patent Application No. 200710140578.7, filed on Aug. 15, 2007, all of which are hereby incorporated by reference in their entireties. 
     
    
     FIELD 
       [0002]    The present disclosure relates to mobile session technologies, and in particular, to a method and an apparatus for creating an Internet Protocol Connectivity Access Network (IP-CAN) session under a Policy and Charging Control (PCC) architecture. 
       BACKGROUND 
       [0003]    In a 3 rd  Generation Partnership Project (3GPP) system, the policy and charging functions are implemented in a PCC architecture. The PCC architecture implements two functions: policy control and charging. 
         [0004]    The policy control function includes six aspects: (1) monitoring the process of negotiating the service parameters (such as Quality of Service (QoS) parameter) of the user; (2) authorizing the network bearer resources used by the service according to the obtained service information; (3) controlling the pass of the service flow on the data bearer plane in real time; (4) notifying the change of the service plane to the data bearer plane; (5) notifying the change of the data bearer plane to the service plane; and (6) performing policy control based on the subscription profile of the user. 
         [0005]    The charging function includes three aspects: (1) formulating charging rule(s) according to the service information, bearer information and subscription profile; (2) performing correlation between the service-plane charging data and the bearer-plane charging data; and (3) performing credit control in a dynamic charging mode. 
         [0006]      FIG. 1  shows a structure of a PCC architecture in the prior art. As shown in FIG,  1 , the policy control function of the existing PCC architecture involves these logical entities: Application Function (AF) entity, Policy and Charging Rules Function (PCRF) entity, Policy and Charging Enforcement Function (PCEF) entity, and Subscription Profile Repository (SPR) entity. The charging function of the existing PCC architecture involves not only the AF entity, the PCRF entity, the PCEF entity, and the SPR entity, but also other logical entities such as an Online Charging System (OCS) entity and an Offline Charging System (OFCS) entity. 
         [0007]    The functions of the entities are elaborated below. 
         [0008]    The AF entity is configured to provide a service application access point. The network resources used by such service applications need dynamic policy control. In the parameter negotiation on the service plane, the AF entity transfers the relevant service information to the PCRF entity. If such service information is consistent with the policy rule(s) defined on the PCRF entity, the PCRF entity accepts the negotiated service parameters. Otherwise, the PCRF entity rejects the negotiation, and may give a feedback which carries the service parameters acceptable to the PCRF entity. Afterward, the AF entity may return such parameters to the user. The AF entity is interfaced with the PCRF entity through an Rx interface. 
         [0009]    The PCRF entity is a core of the PCC system, and is responsible for formulating the policy decision and charging rule(s). The PCRF entity provides network control rule(s) based on the service data flow. The network control includes: data flow detection, gating, QoS control, and flow-based charging control. The PCRF entity sends the formulated policy and charging rule(s) to the PCEF entity for executing, and ensures that such rule(s) are consistent with the subscription profile of the user. The PCRF entity formulates the policy and charging rule(s) according to the information such as the service-related information obtained from the AF entity, subscription profile-related information obtained from the SPR entity, and the bearer network-related information obtained from the PCEF entity. 
         [0010]    On the bearer plane, the PCEF entity may execute the policy and charging rule(s) formulated by the PCRF entity. The PCRF entity may deliver trigger events to the PCEF entity. The PCEF entity requests PCC rule(s) from the PCRF entity only when such a trigger event occurs. The PCEF entity detects the service data flows according to a traffic filter in the rule(s) sent by the PCRF entity, and performs the policy and charging control formulated by the PCRF entity to such service flows. When creating a bearer, the PCEF entity performs QoS authorization according to the rule(s) sent by the PCRF entity, and performs a gating operation according to the instruction of the AF entity. The PCEF entity executes the service flow charging operation according to the charging rule(s) sent by the PCRF entity. Such a charging operation may be online charging or offline charging. For online charging, the PCEF entity works together with the OCS entity to perform credit management; for offline charging, the PCEF entity exchanges the relevant charging information with the OFCS entity. The PCEF entity is interfaced with the PCRF entity through a Gx interface, interfaced with the OCS entity through a Gy interface, and interfaced with the OFCS entity through a Gz interface. The PCEF entity is generally located in a Gateway (GW) of the network. 
         [0011]    The SPR entity stores the user subscription profile related to policy control and charging, for example, information about services available to the user, information about the QoS available to the user service, user subscription profile related to charging, and group type of the user. By using the information stored in the SPR entity, the PCRF entity may perform policy control and charging operations based on the user subscription profile. The SPR entity is interfaced with the PCRF entity through an Sp interface. 
         [0012]    With evolution of the mobile communication network, a new PCC architecture is currently put forward.  FIG. 2  shows a structure of a new PCC architecture. In the new PCC architecture, the PCEF is divided into a PCEFa entity and a PCEFb entity. The PCEFa entity and the PCEFb entity may be configured respectively into an Access Gateway (A-GW) and an Evolved Packet System (EPS) Home Agent (HA). No bearer exists between the A-GW and the EPS HA. Therefore, the bearer plane-related functions (for example, bearer binding function) of the PCEF entity are configured in the PCEFa entity of the A-GW. An SGi interface exists between the EPS HA and a Packet Data Network (PDN). Therefore, the functions such as the charging function and the gating function are configured in the PCEFb entity of the EPS HA. The A-GW may be a serving GW or a PDN GW, or other core network entity, and the EPS HA may be a PDN GW or other core network entity. 
       SUMMARY 
       [0013]    The solution provided by the embodiments is described below. In a first embodiment, a method for creating an IP-CAN session includes: creating, by a first Policy and Charging Enforcement Function entity, PCEFa entity, a session with a Policy and Charging Rules Function entity, PCRF entity; performing, by the PCEFa entity, mobility registration with a second Policy and Charging Enforcement Function entity, PCEFb entity; creating, by the PCEFb entity, a session with the PCRF entity; and sending, by the PCRF entity, a session information to the PCEFa entity and the PCEFb entity. 
         [0014]    In a second embodiment, a method for creating an Internet Protocol Connectivity Access Network (IP-CAN) session, comprising: accepting, by a second Policy and Charging Enforcement Function (PCEF) entity, mobility registration from a first PCEF entity that has created a session with a Policy and Charging Rules Function (PCRF) entity; creating, by the second PCEF entity, a session with the PCRF entity; and receiving, by the second PCEF entity, an IP-CAN session information and PCC rules from the PCRF entity. 
         [0015]    In a third embodiment, an apparatus for creating an IP-CAN session includes: a First Policy and Charging Enforcement Function entity, PCEFa entity, configured to receive an IP-CAN session creation request, and return an IP-CAN session creation response after receiving an IP-CAN session information; a second Policy and Charging Enforcement Function entity, PCEFb entity, configured to perform mobility registration with the PCEFa entity; and a 
         [0016]    Policy and Charging Rules Function entity, PCRF entity, configured to create sessions with the PCEFa entity and the PCEFb entity, and send IP-CAN session information to the PCEFa entity and the PCEFb entity. 
         [0017]    In a fourth embodiment, an apparatus includes a non-transitory computer readable storage medium storing a set of instructions for creating an Internet Protocol Connectivity Access Network (IP-CAN) session. The set of instructions to direct a processor in a network entity to: accept mobility registration from a first Policy and Charging Enforcement Function (PCEF) entity that which has created a session with a Policy and Charging Rules Function (PCRF) entity; create a session with the PCRF entity; and receive an IP-CAN session information and PCC rules from the PCRF entity. 
         [0018]    According to the method and the apparatus for creating an IP-CAN session in an embodiment of the present disclosure, the PCRF may formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session may be created in the new architecture. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0019]    The following figures describe the exemplary embodiments of the present disclosure in more detail, and make the features and merits of the present disclosure clearer to those skilled in the art: 
           [0020]      FIG. 1  schematically illustrates a structure of a PCC architecture in the prior art; 
           [0021]      FIG. 2  schematically illustrates a structure of a new PCC architecture; 
           [0022]      FIG. 3  schematically illustrates a structure of a new PCC architecture in the first roaming scenario; 
           [0023]      FIG. 4  schematically illustrates a structure of a new PCC architecture in the second roaming scenario; 
           [0024]      FIG. 5  is a schematic flowchart of a method for creating an IP-CAN session in an embodiment of the present disclosure; 
           [0025]      FIG. 6  is a schematic flowchart of a method for creating an IP-CAN session in the first embodiment of the present disclosure; 
           [0026]      FIG. 7  is a schematic flowchart of a method for creating an IP-CAN session in the second embodiment of the present disclosure; 
           [0027]      FIG. 8  is a schematic flowchart of a method for creating an IP-CAN session in the third embodiment of the present disclosure; 
           [0028]      FIG. 9  is a schematic flowchart of a method for creating an IP-CAN session in the fourth embodiment of the present disclosure; 
           [0029]      FIG. 10  is a schematic flowchart of a method for creating an IP-CAN session in the fifth embodiment of the present disclosure; 
           [0030]      FIG. 11  schematically illustrates the first embodiment of the process of credit authorization in the present disclosure; 
           [0031]      FIG. 12  schematically illustrates the second embodiment of the process of credit authorization in the present disclosure; 
           [0032]      FIG. 13  schematically illustrates the third embodiment of the process of credit authorization in the present disclosure; 
           [0033]      FIG. 14  is a schematic flowchart of a method for creating an IP-CAN session in the sixth embodiment of the present disclosure; 
           [0034]      FIG. 15  is a schematic flowchart of a method for creating an IP-CAN session in the seventh embodiment of the present disclosure; 
           [0035]      FIG. 16  is a schematic flowchart of a method for creating an IP-CAN session in the eighth embodiment of the present disclosure; 
           [0036]      FIG. 17  is a schematic flowchart of a method for creating an IP-CAN session in the ninth embodiment of the present disclosure; 
           [0037]      FIG. 18  is a schematic flowchart of a method for creating an IP-CAN session in the 10th embodiment of the present disclosure; 
           [0038]      FIG. 19  schematically illustrates the fourth embodiment of the process of credit authorization in the present disclosure; 
           [0039]      FIG. 20  schematically illustrates the fifth embodiment of the process of credit authorization in the present disclosure; 
           [0040]      FIG. 21  schematically illustrates the sixth embodiment of the process of credit authorization in the present disclosure; 
           [0041]      FIG. 22  is a schematic flowchart of a method for creating an IP-CAN session in the 11th embodiment of the present disclosure; 
           [0042]      FIG. 23  is a schematic flowchart of a method for creating an IP-CAN session in the 12th embodiment of the present disclosure; 
           [0043]      FIG. 24  is a schematic flowchart of a method for creating an IP-CAN session in the 13th embodiment of the present disclosure; 
           [0044]      FIG. 25  is a schematic flowchart of a method for creating an IP-CAN session in the 14th embodiment of the present disclosure; 
           [0045]      FIG. 26  is a schematic flowchart of a method for creating an IP-CAN session in the 15th embodiment of the present disclosure; 
           [0046]      FIG. 27  schematically illustrates the seventh embodiment of the process of credit authorization in the present disclosure; 
           [0047]      FIG. 28  schematically illustrates the eighth embodiment of the process of credit authorization in the present disclosure; 
           [0048]      FIG. 29  schematically illustrates the ninth embodiment of the process of credit authorization in the present disclosure; 
           [0049]      FIG. 30  schematically illustrates the 10th embodiment of the process of credit authorization in the present disclosure; 
           [0050]      FIG. 31  is a schematic flowchart of a method for deleting an IP-CAN session in an embodiment of the present disclosure; 
           [0051]      FIG. 32  is a schematic flowchart of a method for deleting an IP-CAN session in the 16th embodiment of the present disclosure; 
           [0052]      FIG. 33  is a schematic flowchart of a method for deleting an IP-CAN session in the 17th embodiment of the present disclosure; 
           [0053]      FIG. 34  is a schematic flowchart of a method for deleting an IP-CAN session in the 18th embodiment of the present disclosure; 
           [0054]      FIG. 35  is a schematic flowchart of a method for deleting an IP-CAN session in the 19th embodiment of the present disclosure; 
           [0055]      FIG. 36  is a schematic flowchart of a method for deleting an IP-CAN session in the 20th embodiment of the present disclosure; 
           [0056]      FIG. 37  is a schematic flowchart of a method for deleting an IP-CAN session in the 21st embodiment of the schematic present disclosure; 
           [0057]      FIG. 38  is a schematic flowchart of a method for deleting an IP-CAN session in the 22nd embodiment of the present disclosure; 
           [0058]      FIG. 39  is a schematic flowchart of a method for deleting an IP-CAN session in the 23rd embodiment of the present disclosure; 
           [0059]      FIG. 40  is a schematic flowchart of a method for deleting an IP-CAN session in the 24th embodiment of the present disclosure; 
           [0060]      FIG. 41  is a schematic flowchart of a method for deleting an IP-CAN session in the 25th embodiment of the present disclosure; and 
           [0061]      FIG. 42  schematically illustrates a structure of an apparatus for creating an IP-CAN session in the 26th embodiment of the present disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0062]    In order to make the solution, objectives and merits of the present disclosure clearer, the following describes the embodiments of the present disclosure in more detail with reference to accompanying drawings. 
         [0063]      FIG. 3  schematically illustrates a structure of a new PCC architecture in the first roaming scenario. As shown in  FIG. 3 , when the PCEFa entity is located in a visited network, the vPCRF entity located in the visited network performs signaling transfer between the PCEFa entity and the hPCRF entity in the home network, and the vOCS entity located in the visited network performs signaling transfer between the PCEFa entity and the hOCS entity located in the home network. Besides, the PCEFa entity and the PCEFb entity may also perform signaling transfer through the core network entities such as vEPS HA, which is not illustrated in  FIG. 3 . 
         [0064]      FIG. 4  schematically illustrates a structure of a new PCC architecture in the second roaming scenario. As shown in  FIG. 4 , the PCEFb entity may further include an hPCEFb2 entity located in the home network and a vPCEFb1 entity located in the visited network. Signaling transfer is performed between the PCEFa entity and the hPCEFb2 entity through a vPCEFb1 entity. 
         [0065]    As shown in  FIG. 2  and  FIG. 4 , after the new PCC architecture comes forth, the PCEF is divided into two parts. That is, two PCEF logical function entities coexist in the new PCC architecture. Consequently, the method for creating and deleting an IP-CAN session in the existing PCC architecture does not work in the new PCC architecture. Currently, no method for creating or deleting an IP-CAN session in the new PCC architecture is available. 
         [0066]    First, embodiments of a method for creating an IP-CAN session in the present disclosure are described below. 
         [0067]      FIG. 5  is a schematic flowchart of a method for creating an IP-CAN session in an embodiment of the present disclosure. As shown in  FIG. 5 , the method for creating an IP-CAN session in this embodiment includes: 
         [0068]    Step  11 : The PCEFa entity creates a session with the PCRF entity. 
         [0069]    Step  12 : The PCEFa entity performs mobility registration with the PCEFb entity. 
         [0070]    Step  13 : The PCEFb entity creates a session with the PCRF entity. 
         [0071]    Step  14 : The PCRF entity sends session information to the PCEFa entity and the PCEFb entity. 
         [0072]    The PCEFa entity performs mobility registration or creates a bearer with the PCEFb entity, and the PCRF entity formulates PCC rule(s) for the IP-CAN session, and submits the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. 
         [0073]    Further, before step  11 , the PCEFa entity may receive an IP-CAN session creation request. After step  14 , the PCEFa entity may return an IP-CAN session creation response. 
         [0074]    If the IP-CAN session employs an online charging mode, the method in this embodiment may further include a credit authorization step, in which the PCEFa entity and the PCEFb entity request relevant charging credit from the OCS. 
         [0075]    According to the method for creating an IP-CAN session in this embodiment, the PCRF may formulate PCC rule(s) for the IP-CAN session, and provide information of the IP-CAN session and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session may be created in the new architecture. 
         [0076]    In the process of creating an IP-CAN session in an embodiment of the present disclosure, the PCRF and the OCS may deliver the event trigger and the credit re-authorization trigger related to this IP-CAN session to the PCEF. In the new PCC architecture, such triggers are divided into two parts, which are delivered to the PCEFa and the PCEFb respectively. For example, the triggers related to the bearer are delivered to the PCEFa, and the triggers unrelated to the bearer are delivered to the PCEFb. In the new PCC roaming architecture shown in  FIG. 4 , such triggers are divided into three parts, which are delivered to the PCEFa, vPCEFb1, and hPCEFb2 respectively. For example, the triggers related to the bearer are delivered to the PCEFa, the triggers unrelated to the bearer are delivered to the PCEFb1 and PCEFb2. 
         [0077]    In the PCC roaming architecture shown in  FIG. 4 , the vEPS HA entity in the visited network may be capable of judging. That is, when the vEPS HA receives a mobility Registration Request sent by the PCEFa entity, or a bearer creation request sent by the PCEFa entity, or a Gx session creation request sent by the vPCRF entity, the vEPS HA may choose whether to send or not to send a Gx session creation request (response) to the vPCRF according to the preconfiguration. 
       Embodiment 1 
       [0078]      FIG. 6  is a schematic flowchart of a method for creating an IP-CAN session in the first embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 6 , the method for creating an IP-CAN session in this embodiment includes the following steps  101 - 111 . 
         [0079]    Step  101 : The PCEFa entity receives an IP-CAN session creation request. 
         [0080]    Step  102 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an Access Point Name (APN) and a user identifier (user ID) to the PCEFb entity. 
         [0081]    Step  103 : The PCEFb entity allocates an IP address to the user. 
         [0082]    Step  104 : The PCEFb entity sends a Gx session creation request that carries an APN, a user ID, and the allocated IP address to the PCRF entity. 
         [0083]    Step  105 : The PCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFb entity. 
         [0084]    Step  106 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0085]    Step  107 : The PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the PCRF entity. 
         [0086]    Step  108 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0087]    Step  109 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0088]    Step  110 : The PCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0089]    Step  111 : The PCEFa entity returns an IP-CAN session creation response. 
         [0090]    The IP-CAN session creation request received by the PCEFa entity in step  101  may be a GPRS Tunneling Protocol (GTP) message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  102  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  105  and step  110  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the PCRF entity to the PCEFb entity in step  109  may further carry bearer-unrelated event triggers. The PCC decision message sent by the PCRF entity to the PCEFa entity in step  110  may further carry bearer-related event triggers. 
         [0091]    Besides, if the PCRF entity does not store the user subscription profile, an additional step occurs between step  104  and step  105  of the method, and the additional step is: The PCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  110  and step  111  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  110  and step  111  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0092]    In  FIG. 6 , the sequence of step  109  and step  110  is not fixed. 
         [0093]    Therefore, according to the method for creating an IP-CAN session in the first embodiment of the present disclosure, the PCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 2 
       [0094]      FIG. 7  is a schematic flowchart of a method for creating an IP-CAN session in the second embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 7 , the method for creating an IP-CAN session in this embodiment includes the following steps  201 - 212 . 
         [0095]    Step  201 : The PCEFa entity receives an IP-CAN session creation request. 
         [0096]    Step  202 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN, a user ID and the PCEFa entity&#39;s address to the PCEFb entity. 
         [0097]    Step  203 : The PCEFb entity allocates an IP address to the user. 
         [0098]    Step  204 : The PCEFb entity sends a Gx session creation request that carries an APN, a user ID, the PCEFa entity&#39;s address, and the allocated IP address to the PCRF entity. 
         [0099]    Step  205 : The PCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFb entity. 
         [0100]    Step  206 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0101]    Step  207 : The PCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0102]    Step  208 : The PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the PCRF entity. 
         [0103]    Step  209 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0104]    Step  210 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0105]    Step  211 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0106]    Step  212 : The PCEFa entity returns an IP-CAN session creation response. 
         [0107]    The IP-CAN session creation request received by the PCEFa entity in step  201  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  202  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  205  and step  207  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the PCRF entity to the PCEFb entity in step  210  may further carry bearer-unrelated event triggers. The PCC decision message sent by the PCRF entity to the PCEFa entity in step  211  may further carry bearer-related event triggers. 
         [0108]    Besides, if the PCRF entity does not store the user subscription profile, an additional step occurs between step  204  and step  205  of the method, and the additional step is: The PCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  211  and step  212  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  211  and step  212  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. An additional step may occur between step  207  and step  208 , and the additional step is: The PCEFa entity sends a Gx session creation response to the PCRF entity. 
         [0109]    In  FIG. 7 , the sequence of step  205  and step  110  is not fixed, and the sequence of step  210  and step  211  is not fixed. 
         [0110]    Therefore, according to the method for creating an IP-CAN session in the second embodiment of the present disclosure, the PCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 3 
       [0111]      FIG. 8  is a schematic flowchart of a method for creating an IP-CAN session in the third embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 8 , the method for creating an IP-CAN session in this embodiment includes the following steps  301 - 311 . 
         [0112]    Step  301 : The PCEFa entity receives an IP-CAN session creation request. 
         [0113]    Step  302 : The PCEFa entity sends a Gx session creation request that carries an APN, a user ID, and an IP-CAN bearer information to the PCRF entity. 
         [0114]    Step  303 : The PCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFa entity. 
         [0115]    Step  304 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries the APN and the user ID to the PCEFb entity. 
         [0116]    Step  305 : The PCEFb entity allocates an IP address to the user. 
         [0117]    Step  306 : The PCEFb entity sends a mobility registration response or a bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0118]    Step  307 : The PCEFb entity sends a PCC decision request that carries an APN, a user ID, and the allocated IP address to the PCRF entity. 
         [0119]    Step  308 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0120]    Step  309 : The PCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFb entity. 
         [0121]    Step  310 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0122]    Step  312 : The PCEFa entity returns an IP-CAN session creation response. 
         [0123]    The IP-CAN session creation request received by the PCEFa entity in step  301  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  304  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  303  and step  309  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the PCRF entity to the PCEFb entity in step  309  may further carry bearer-unrelated event triggers. The PCC decision message sent by the PCRF entity to the PCEFa entity in step  310  may further carry bearer-related event triggers. 
         [0124]    Besides, if the PCRF entity does not store the user subscription profile, an additional step occurs between step  302  and step  303  of the method, and the additional step is: The PCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  310  and step  311  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  310  and step  311  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0125]    In  FIG. 8 , the sequence of step  306  and step  307  is not fixed, and the sequence of step  309  and step  310  is not fixed 
         [0126]    Therefore, according to the method for creating an IP-CAN session in the third embodiment of the present disclosure, the PCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 4 
       [0127]      FIG. 9  is a schematic flowchart of a method for creating an IP-CAN session in the fourth embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 9 , the method for creating an IP-CAN session in this embodiment includes the following steps  401 - 411 . 
         [0128]    Step  401 : The PCEFa entity receives an IP-CAN session creation request. 
         [0129]    Step  402 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0130]    Step  403 : The PCEFb entity allocates an IP address to the user. 
         [0131]    Step  404 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0132]    Step  405 : The PCEFa entity sends a PCC decision request that carries the APN, user ID, IP-CAN bearer information, PCEFb entity&#39;s address and the allocated IP address to the PCRF entity. 
         [0133]    Step  406 : The PCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFb entity according to the received PCEFb entity&#39;s address. 
         [0134]    Step  407 : The PCEFb entity sends a Gx session creation response to the PCRF entity. 
         [0135]    Step  408 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0136]    Step  409 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0137]    Step  410 : The PCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0138]    Step  411 : The PCEFa entity returns an IP-CAN session creation response. 
         [0139]    The IP-CAN session creation request received by the PCEFa entity in step  401  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  402  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  406  and step  410  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the PCRF entity to the PCEFb entity in step  409  may further carry bearer-unrelated event triggers. The PCC decision message sent by the PCRF entity to the PCEFa entity in step  410  may further carry bearer-related event triggers. 
         [0140]    Besides, if the PCRF entity does not store the user subscription profile, an additional step occurs between step  405  and step  406  of the method, and the additional step is: The PCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  410  and step  411  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  410  and step  411  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0141]    In  FIG. 9 , the sequence of step  409  and step  410  is not fixed. 
         [0142]    Therefore, according to the method for creating an IP-CAN session in the fourth embodiment of the present disclosure, the PCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 5 
       [0143]      FIG. 10  is a schematic flowchart of a method for creating an IP-CAN session in the fifth embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 10 , the method for creating an IP-CAN session in this embodiment includes the following steps  501 - 511 . 
         [0144]    Step  501 : The PCEFa entity receives an IP-CAN session creation request. 
         [0145]    Step  502 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0146]    Step  503 : The PCEFb entity allocates an IP address to the user. 
         [0147]    Step  504 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0148]    Step  505 : The PCEFb entity sends a PCC decision request that carries an APN, a user ID, the PCEFa entity&#39;s address, and the allocated IP address to the PCRF entity. 
         [0149]    Step  506 : The PCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0150]    Step  507 : The PCEFa entity sends a Gx session creation response that carries IP-CAN bearer information to the PCRF entity. 
         [0151]    Step  508 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0152]    Step  509 : The PCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFb entity. 
         [0153]    Step  510 : The PCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0154]    Step  511 : The PCEFa entity returns an IP-CAN session creation response. 
         [0155]    The IP-CAN session creation request received by the PCEFa entity in step  501  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  502  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  506  and step  509  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the PCRF entity to the PCEFb entity in step  509  may further carry bearer-unrelated event triggers. The PCC decision message sent by the PCRF entity to the PCEFa entity in step  510  may further carry bearer-related event triggers. 
         [0156]    Besides, if the PCRF entity does not store the user subscription profile, an additional step occurs between step  505  and step  506  of the method, and the additional step is: The PCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  510  and step  511  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  510  and step  511  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0157]    In  FIG. 10 , the sequence of step  504  and step  505  is not fixed, and the sequence of step  509  and step  510  is not fixed 
         [0158]    Therefore, according to the method for creating an IP-CAN session in the fifth embodiment of the present disclosure, the PCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
         [0159]    The credit authorization process in embodiments 1-5, namely, the process in which the PCEFa and the PCEFb request the relevant charging credit from the OCS, may be the same as the credit authorization process in  FIG. 11 ,  FIG. 12 , or  FIG. 13 . 
         [0160]      FIG. 11  is a flowchart of the first process of credit authorization in this embodiment. As shown in  FIG. 11 , the first process of credit authorization in this embodiment includes the following steps  601 - 603 : 
         [0161]    Step  601 : The PCEFa entity sends a credit request that carries a PCEFb entity&#39;s address to an OCS entity. 
         [0162]    Step  602 : According to the received PCEFb entity&#39;s address, the OCS entity sends a credit response to the PCEFb entity, where the credit response carries an online charging credit and a bearer-unrelated credit re-authorization trigger. 
         [0163]    Step  603 : The OCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0164]    The sequence of step  602  and step  603  is not fixed. 
         [0165]      FIG. 12  is a flowchart of the second process of credit authorization in this embodiment. As shown in  FIG. 12 , the second process of credit authorization in this embodiment includes the following steps  701 - 703 : 
         [0166]    Step  701 : The PCEFb entity sends a credit request that carries a PCEFa entity&#39;s address to an OCS entity. 
         [0167]    Step  702 : The OCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the PCEFb entity. 
         [0168]    Step  703 : The OCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0169]    The sequence of step  702  and step  703  is not fixed. 
         [0170]      FIG. 13  is a schematic flowchart of the third process of credit authorization in this embodiment. As shown in  FIG. 13 , the third process of credit authorization in this embodiment includes the following steps  801 - 804 : 
         [0171]    Step  801 : The PCEFb entity sends a credit request to an OCS entity. 
         [0172]    Step  802 : The OCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the PCEFb entity. 
         [0173]    Step  803 : The PCEFa entity sends a credit request to the OCS entity. 
         [0174]    Step  804 : The OCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0175]    The sequence of step  801  and step  802 , and the sequence of step  803  and step  804  are not fixed. 
       Embodiment 6 
       [0176]      FIG. 14  is a schematic flowchart of a method for creating an IP-CAN session in the sixth embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the first roaming scenario shown in  FIG. 3 . As shown in  FIG. 14 , the method for creating an IP-CAN session in this embodiment includes the following steps  901 - 911 . 
         [0177]    Step  901 : The PCEFa entity receives an IP-CAN session creation request. 
         [0178]    Step  902 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0179]    Step  903 : The PCEFb entity allocates an IP address to the user. 
         [0180]    Step  904 : The PCEFb entity sends a Gx session creation request that carries an APN, a user ID, and the allocated IP address to an hPCRF entity. 
         [0181]    Step  905 : The hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFb entity. 
         [0182]    Step  906 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0183]    Step  907 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the hPCRF entity. 
         [0184]    Step  908 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0185]    Step  909 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0186]    Step  910 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0187]    Step  911 : The PCEFa entity returns an IP-CAN session creation response. 
         [0188]    The IP-CAN session creation request received by the PCEFa entity in step  901  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  902  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  905  and step  910  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the PCEFb entity in step  909  may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in step  910  may further carry bearer-related event triggers. 
         [0189]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  904  and step  905  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  910  and step  911  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  910  and step  911  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0190]    In  FIG. 14 , the sequence of step  909  and step  910  is not fixed. 
         [0191]    Besides, if the PCEFa entity and the PCEFb entity perform signaling transfer through a core network entity such as vEPS HA in the visited network in the new PCC architecture in the roaming scenario shown in  FIG. 3 , all messages between the PCEFa entity and the PCEFb entity in the method in the sixth embodiment are forwarded through this core network entity. 
         [0192]    Therefore, according to the method for creating an IP-CAN session in the sixth embodiment of the present disclosure, the hPCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 7 
       [0193]      FIG. 15  is a schematic flowchart of a method for creating an IP-CAN session in the seventh embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the first roaming scenario shown in  FIG. 3 . As shown in  FIG. 15 , the method for creating an IP-CAN session in this embodiment includes the following steps  1001 - 1012 . 
         [0194]    Step  1001 : The PCEFa entity receives an IP-CAN session creation request. 
         [0195]    Step  1002 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN, a user ID and the PCEFa entity&#39;s address to the PCEFb entity. 
         [0196]    Step  1003 : The PCEFb entity allocates an IP address to the user. 
         [0197]    Step  1004 : The PCEFb entity sends a Gx session creation request that carries an APN, a user ID, the PCEFa entity&#39;s address, and the allocated IP address to the hPCRF entity. 
         [0198]    Step  1005 : The hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFb entity. 
         [0199]    Step  1006 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0200]    Step  1007 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0201]    Step  1008 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the hPCRF entity. 
         [0202]    Step  1009 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0203]    Step  1010 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0204]    Step  1011 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0205]    Step  1012 : The PCEFa entity returns an IP-CAN session creation response. 
         [0206]    The IP-CAN session creation request received by the PCEFa entity in step  1001  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  1002  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  205  and step  207  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the PCEFb entity in step  1010  may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in step  1011  may further carry bearer-related event triggers. 
         [0207]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1004  and step  1005  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1011  and step  1012  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1011  and step  1012  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. An additional step may occur between step  1007  and step  1008 , and the additional step is: The PCEFa entity sends a Gx session creation response to the hPCRF entity through a vPCRF entity. 
         [0208]    In  FIG. 15 , the sequence of step  1005  and step  1007  is not fixed, and the sequence of step  1010  and step  1011  is not fixed. 
         [0209]    Besides, if the PCEFa entity and the PCEFb entity perform signaling transfer through a core network entity such as vEPS HA in the visited network in the new PCC architecture in the roaming scenario shown in  FIG. 3 , all messages between the PCEFa entity and the PCEFb entity in the method in the sixth embodiment are forwarded through this core network entity. 
         [0210]    Therefore, according to the method for creating an IP-CAN session in the seventh embodiment of the present disclosure, the hPCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 8 
       [0211]      FIG. 16  is a schematic flowchart of a method for creating an IP-CAN session in the eighth embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the first roaming scenario shown in  FIG. 3 . As shown in  FIG. 16 , the method for creating an IP-CAN session in this embodiment includes the following steps  1101 - 1111 . 
         [0212]    Step  1101 : The PCEFa entity receives an IP-CAN session creation request. 
         [0213]    Step  1102 : Through a vPCRF entity, the PCEFa entity sends a Gx session creation request that carries an APN, a user ID, and IP-CAN bearer information to the hPCRF entity. 
         [0214]    Step  1103 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFa entity. 
         [0215]    Step  1104 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0216]    Step  1105 : The PCEFb entity allocates an IP address to the user. 
         [0217]    Step  1106 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0218]    Step  1107 : The PCEFb entity sends a PCC decision request that carries an APN, a user ID, and the allocated IP address to the hPCRF entity. 
         [0219]    Step  1108 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0220]    Step  1109 : The hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFb entity. 
         [0221]    Step  1110 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0222]    Step  1111 : The PCEFa entity returns an IP-CAN session creation response. 
         [0223]    The IP-CAN session creation request received by the PCEFa entity in step  1101  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  1104  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  1103  and step  1109  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the PCEFb entity in step  1109  may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in step  1110  may further carry bearer-related event triggers. 
         [0224]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1102  and step  1103  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1110  and step  1111  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1110  and step  1111  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0225]    In  FIG. 16 , the sequence of step  1106  and step  1107  is not fixed, and the sequence of step  1109  and step  1110  is not fixed 
         [0226]    Besides, if the PCEFa entity and the PCEFb entity perform signaling transfer through a core network entity such as vEPS HA in the visited network in the new PCC architecture in the roaming scenario shown in  FIG. 3 , all messages between the PCEFa entity and the PCEFb entity in the method in the sixth embodiment are forwarded through this core network entity. 
         [0227]    Therefore, according to the method for creating an IP-CAN session in the eighth embodiment of the present disclosure, the hPCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 9 
       [0228]      FIG. 17  is a schematic flowchart of a method for creating an IP-CAN session in the ninth embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the first roaming scenario shown in  FIG. 3 . As shown in  FIG. 17 , the method for creating an IP-CAN session in this embodiment includes the following steps  1201 - 1211 . 
         [0229]    Step  1201 : The PCEFa entity receives an IP-CAN session creation request. 
         [0230]    Step  1202 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0231]    Step  1203 : The PCEFb entity allocates an IP address to the user. 
         [0232]    Step  1204 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0233]    Step  1205 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, IP-CAN bearer information, PCEFb entity&#39;s address and the allocated IP address to the hPCRF entity. 
         [0234]    Step  1206 : The hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFb entity according to the received PCEFb entity&#39;s address. 
         [0235]    Step  1207 : The PCEFb entity sends a Gx session creation response to the hPCRF entity. 
         [0236]    Step  1208 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0237]    Step  1209 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFb entity. 
         [0238]    Step  1210 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0239]    Step  1211 : The PCEFa entity returns an IP-CAN session creation response. 
         [0240]    The IP-CAN session creation request received by the PCEFa entity in step  1201  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  1202  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  1206  and step  1210  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the PCEFb entity in step  1209  may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in step  1210  may further carry bearer-related event triggers. 
         [0241]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1205  and step  1206  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1210  and step  1211  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1210  and step  1211  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0242]    In  FIG. 17 , the sequence of step  1209  and step  1210  is not fixed. 
         [0243]    Besides, if the PCEFa entity and the PCEFb entity perform signaling transfer through a core network entity such as vEPS HA in the visited network in the new PCC architecture in the roaming scenario shown in  FIG. 3 , all messages between the PCEFa entity and the PCEFb entity in the method in the sixth embodiment are forwarded through this core network entity. 
         [0244]    Therefore, according to the method for creating an IP-CAN session in the ninth embodiment of the present disclosure, the hPCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 10 
       [0245]      FIG. 18  is a schematic flowchart of a method for creating an IP-CAN session in the 10 th  embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the first roaming scenario shown in  FIG. 3 . As shown in  FIG. 17 , the method for creating an IP-CAN session in this embodiment includes the following steps  1301 - 1311 . 
         [0246]    Step  1301 : The PCEFa entity receives an IP-CAN session creation request. 
         [0247]    Step  1302 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the PCEFb entity. 
         [0248]    Step  1303 : The PCEFb entity allocates an IP address to the user. 
         [0249]    Step  1304 : The PCEFb entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0250]    Step  1305 : The PCEFb entity sends a PCC decision request that carries an APN, a user ID, a PCEFa entity&#39;s address, and the allocated IP address to the hPCRF entity. 
         [0251]    Step  1306 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0252]    Step  1307 : Through the vPCRF entity, the PCEFa entity sends a Gx session creation response that carries IP-CAN bearer information to the hPCRF entity. 
         [0253]    Step  1308 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0254]    Step  1309 : The hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFb entity. 
         [0255]    Step  1310 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0256]    Step  1311 : The PCEFa entity returns an IP-CAN session creation response. 
         [0257]    The IP-CAN session creation request received by the PCEFa entity in step  1301  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  1302  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information sent in step  1306  and step  1309  may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the PCEFb entity in step  1309  may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in step  1310  may further carry bearer-related event triggers. 
         [0258]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1305  and step  1306  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1310  and step  1311  of the method, and the additional step is credit authorization, namely, the PCEFa and the PCEFb request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1310  and step  1311  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0259]    In  FIG. 18 , the sequence of step  1304  and step  1305  is not fixed, and the sequence of step  1309  and step  1310  is not fixed 
         [0260]    Besides, if the PCEFa entity and the PCEFb entity perform signaling transfer through a core network entity such as vEPS HA in the visited network in the new PCC architecture in the roaming scenario shown in  FIG. 3 , all messages between the PCEFa entity and the PCEFb entity in the method in the sixth embodiment are forwarded through this core network entity. 
         [0261]    Therefore, according to the method for creating an IP-CAN session in the 10 th  embodiment of the present disclosure, the hPCRF can identify that the PCEFa and the PCEFb belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa and the PCEFb, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
         [0262]    The credit authorization process in embodiments 6-10, namely, the process in which the PCEFa and the PCEFb request the relevant charging credit from the OCS, may be the same as the credit authorization process in  FIG. 19 ,  FIG. 20 , or  FIG. 21 . 
         [0263]      FIG. 19  is a schematic flowchart of the fourth process of credit authorization in this embodiment. As shown in  FIG. 19 , the fourth process of credit authorization in this embodiment includes the following steps  1401 - 1403 : 
         [0264]    Step  1401 : Through a vOCS entity, the PCEFa entity sends a credit request that carries a PCEFb entity&#39;s address to an hOCS entity. 
         [0265]    Step  1402 : According to the received PCEFb entity&#39;s address, the hOCS entity sends a credit response to the PCEFb entity, where the credit response carries an online charging credit and a bearer-unrelated credit re-authorization trigger. 
         [0266]    Step  1403 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0267]    The sequence of step  1402  and step  1403  is not fixed. 
         [0268]      FIG. 20  is a flowchart of the fifth process of credit authorization in this embodiment. As shown in  FIG. 20 , the fifth process of credit authorization in this embodiment includes the following steps  1501 - 1503 : 
         [0269]    Step  1501 : The PCEFb entity sends a credit request that carries a PCEFa entity&#39;s address to an hOCS entity. 
         [0270]    Step  1502 : The hOCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the PCEFb entity. 
         [0271]    Step  1503 : Through a vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0272]    The sequence of step  1502  and step  1503  is not fixed. 
         [0273]      FIG. 21  is a flowchart of the sixth process of credit authorization in this embodiment. As shown in  FIG. 21 , the sixth process of credit authorization in this embodiment includes the following steps  1601 - 1604 : 
         [0274]    Step  1601 : The PCEFb entity sends a credit request to an hOCS entity. 
         [0275]    Step  1602 : The hOCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the PCEFb entity. 
         [0276]    Step  1603 : Through a vOCS entity, the PCEFa entity sends a credit request to the hOCS entity. 
         [0277]    Step  1604 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0278]    The sequence of step  1601  and step  1602 , and the sequence of step  1603  and step  1604  are not fixed. 
       Embodiment 11 
       [0279]      FIG. 22  is a schematic flowchart of a method for creating an IP-CAN session in the 11 th  embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the second roaming scenario shown in  FIG. 4 . As shown in  FIG. 22 , the method for creating an IP-CAN session in this embodiment includes the following steps  1701 - 1715 . 
         [0280]    Step  1701 : The PCEFa entity receives an IP-CAN session creation request. 
         [0281]    Step  1702 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to a vPCEFb1 entity located in a visited network. 
         [0282]    Step  1703 : Through a vPCRF entity located in the visited network, the vPCEFb1 entity sends a Gx session creation request that carries an APN and a user ID to the hPCRF entity. 
         [0283]    Step  1704 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the vPCEFb1 entity. 
         [0284]    Step  1705 : The vPCEFb1 entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the hPCEFb2 entity. 
         [0285]    Step  1706 : The hPCEFb2 entity allocates an IP address to the user. 
         [0286]    Step  1707 : The hPCEFb2 entity sends a Gx session creation request that carries an APN, a user ID, and the allocated IP address to an hPCRF entity. 
         [0287]    Step  1708 : The hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the hPCEFb2 entity. 
         [0288]    Step  1709 : Through the vPCEFb1 entity, the hPCEFb2 entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0289]    Step  1710 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the hPCRF entity. 
         [0290]    Step  1711 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0291]    Step  1712 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the hPCEFb2 entity. 
         [0292]    Step  1713 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the vPCEFb1 entity. 
         [0293]    Step  1714 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0294]    Step  1715 : The PCEFa entity returns an IP-CAN session creation response. 
         [0295]    The IP-CAN session creation request received by the PCEFa entity in step  1701  may be a GPRS Tunneling Protocol (GTP) message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity to the PCEFb entity in step  1702  may be a Proxy Binding Update message, or Registration Request message, or other MIP registration message. The IP-CAN session information in this method may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the hPCEFb2 entity and the vPCEFb1 entity may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in this method may further carry bearer-related event triggers. 
         [0296]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1703  and step  1704  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1714  and step  1715  of the method, and the additional step is credit authorization, namely, the PCEFa, hPCEFb2, and vPCEFb1 request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1714  and step  1715  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0297]    In  FIG. 22 , the sequence of step  1712 , step  1713 , and step  1714  is not fixed. 
         [0298]    Therefore, according to the method for creating an IP-CAN session in the 11th embodiment of the present disclosure, the hPCRF can identify that the PCEFa, hPCEFb2, and vPCEFb1 belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa, hPCEFb2, and vPCEFb1, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa, hPCEFb2, and vPCEFb  1 . In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 12 
       [0299]      FIG. 23  is a schematic flowchart of a method for creating an IP-CAN session in the 12 th  embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the second roaming scenario shown in  FIG. 4 . As shown in  FIG. 23 , the method for creating an IP-CAN session in this embodiment includes the following steps  1801 - 1816 . 
         [0300]    Step  1801 : The PCEFa entity receives an IP-CAN session creation request. 
         [0301]    Step  1802 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN, a user ID and a PCEFa entity&#39;s address to the vPCEFb1 entity. 
         [0302]    Step  1803 : Through a vPCRF entity, the vPCEFb1 entity sends a Gx session creation request that carries an APN, a user ID, and the PCEFa entity&#39;s address to an hPCRF entity. 
         [0303]    Step  1804 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the vPCEFb1 entity. 
         [0304]    Step  1805 : The vPCEFb1 entity sends a mobility Registration Request or bearer creation request that carries an APN, a user ID and a PCEFa entity&#39;s address to the hPCEFb2 entity. 
         [0305]    Step  1806 : The hPCEFb2 entity allocates an IP address to the user. 
         [0306]    Step  1807 : The hPCEFb2 entity sends a Gx session creation request that carries an APN, a user ID, a PCEFa entity&#39;s address, and the allocated IP address to the hPCRF entity. 
         [0307]    Step  1808 : The hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the hPCEFb2 entity. 
         [0308]    Step  1809 : Through the vPCEFb1 entity, the hPCEFb2 entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0309]    Step  1810 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0310]    Step  1811 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, and IP-CAN bearer information to the hPCRF entity. 
         [0311]    Step  1812 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0312]    Step  1813 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the hPCEFb2 entity. 
         [0313]    Step  1814 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the vPCEFb1 entity. 
         [0314]    Step  1815 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0315]    Step  1816 : The PCEFa entity returns an IP-CAN session creation response. 
         [0316]    The IP-CAN session creation request received by the PCEFa entity in step  1801  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity in this method may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information in this method may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the hPCEFb2 entity and the vPCEFb1 entity may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in this method may further carry bearer-related event triggers. 
         [0317]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1803  and step  1804  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1815  and step  1816  of the method, and the additional step is credit authorization, namely, the PCEFa, hPCEFb2,and vPCEFb1 request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1815  and step  1816  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. An additional step may occur between step  1008  and step  1009 , and the additional step is: The PCEFa entity sends a Gx session creation response to the hPCRF entity through a vPCRF entity. 
         [0318]    In  FIG. 23 , the sequence of step  1813 , step  1814 , and step  1815  is not fixed. 
         [0319]    Therefore, according to the method for creating an IP-CAN session in the 12th embodiment of the present disclosure, the hPCRF can identify that the PCEFa, hPCEFb2, and vPCEFb1 belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa, hPCEFb2, and vPCEFb1, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa, hPCEFb2, and vPCEFb1. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 13 
       [0320]      FIG. 24  is a schematic flowchart of a method for creating an IP-CAN session in the 13th embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the second roaming scenario shown in  FIG. 4 . As shown in  FIG. 24 , the method for creating an IP-CAN session in this embodiment includes the following steps  1901 - 1915 . 
         [0321]    Step  1901 : The PCEFa entity receives an IP-CAN session creation request. 
         [0322]    Step  1902 : Through a vPCRF entity, the PCEFa entity sends a Gx session creation request that carries an APN, a user ID, and IP-CAN session information to the hPCRF entity. 
         [0323]    Step  1903 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the PCEFa entity. 
         [0324]    Step  1904 : The PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the vPCEFb1 entity. 
         [0325]    Step  1905 : The vPCEFb1 entity sends a Gx session creation request that carries an APN and a user ID to the vPCRF entity. 
         [0326]    Step  1906 : The vPCRF entity sends a Gx session creation response that carries IP-CAN session information to the vPCEFb1 entity. 
         [0327]    Step  1907 : The vPCEFb1 entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the hPCEFb2 entity. 
         [0328]    Step  1908 : The hPCEFb2 entity allocates an IP address to the user. 
         [0329]    Step  1909 : The hPCEFb2 entity sends a PCC decision request that carries an APN, a user ID, and the allocated IP address to the hPCRF entity. 
         [0330]    Step  1910 : Through the vPCEFb1 entity, the hPCEFb2 entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0331]    Step  1911 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0332]    Step  1912 : The hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the hPCEFb2 entity. 
         [0333]    Step  1913 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the vPCEFb1 entity. 
         [0334]    Step  1914 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0335]    Step  1915 : The PCEFa entity returns an IP-CAN session creation response. 
         [0336]    The IP-CAN session creation request received by the PCEFa entity in step  1901  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity in this method may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information in this method may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the hPCEFb2 entity and the vPCEFb1 entity may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in this method may further carry bearer-related event triggers. 
         [0337]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  1902  and step  1903  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  1914  and step  1915  of the method, and the additional step is credit authorization, namely, the PCEFa, hPCEFb2, and vPCEFb1 request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  1914  and step  1915  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. An additional step may occur between step  1905  and step  1906 , and the additional step is: The vPCRF entity sends a Gx session creation request that carries an APN and a user ID to the hPCRF entity, and the hPCRF entity sends a Gx session creation response that carries IP-CAN session information to the vPCRF entity. 
         [0338]    In  FIG. 24 , the sequence of step  1912 , step  1913 , and step  1914  is not fixed. 
         [0339]    Therefore, according to the method for creating an IP-CAN session in the 13th embodiment of the present disclosure, the hPCRF can identify that the PCEFa, hPCEFb2, and vPCEFb1 belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa, hPCEFb2, and vPCEFb1, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa, hPCEFb2, and vPCEFb1. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 14 
       [0340]      FIG. 25  is a schematic flowchart of a method for creating an IP-CAN session in the 14th embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the second roaming scenario shown in  FIG. 4 . As shown in  FIG. 25 , the method for creating an IP-CAN session in this embodiment includes the following steps  2001 - 2014 . 
         [0341]    Step  2001 : The PCEFa entity receives an IP-CAN session creation request. 
         [0342]    Step  2002 : Through a vPCEFb1 entity, the PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the hPCEFb2 entity. 
         [0343]    Step  2003 : The hPCEFb2 entity allocates an IP address to the user. 
         [0344]    Step  2004 : Through the vPCEFb1 entity, the hPCEFb2 entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0345]    Step  2005 : Through a vPCRF entity, the PCEFa entity sends a PCC decision request that carries the APN, user ID, IP-CAN session information, vPCEFb1 entity&#39;s address, hPCEFb2 entity&#39;s address, and the allocated IP address to the hPCRF entity. 
         [0346]    Step  2006 : The hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the hPCEFb2 entity according to the received hPCEFb2 entity&#39;s address. 
         [0347]    Step  2007 : The hPCEFb2 entity sends a Gx session creation response to the hPCRF entity. 
         [0348]    Step  2008 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the vPCEFb1 entity according to the received vPCEFb1 entity&#39;s address. 
         [0349]    Step  2009 : Through the vPCRF entity, the vPCEFb1 entity sends a Gx session creation response to the hPCRF entity. 
         [0350]    Step  2010 : The hPCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0351]    Step  2011 : The hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the hPCEFb2 entity. 
         [0352]    Step  2012 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the vPCEFb1 entity. 
         [0353]    Step  2013 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity. 
         [0354]    Step  2014 : The PCEFa entity returns an IP-CAN session creation response. 
         [0355]    The IP-CAN session creation request received by the PCEFa entity in step  2001  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity in step  2002  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information in this method may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the hPCEFb2 entity and the vPCEFb1 entity may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity may further carry bearer-related event triggers. 
         [0356]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  2005  and step  2006  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  2013  and step  2014  of the method, and the additional step is credit authorization, namely, the PCEFa, hPCEFb2, and vPCEFb1 request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  2013  and step  2014  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0357]    In  FIG. 25 , the sequence of step  2011 , step  2012 , and step  2013  is not fixed. 
         [0358]    Therefore, according to the method for creating an IP-CAN session in the 14th embodiment of the present disclosure, the hPCRF can identify that the PCEFa, hPCEFb2, and vPCEFb1 belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa, hPCEFb2, and vPCEFb1, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa, hPCEFb2, and vPCEFb1. In this way, an IP-CAN session is created in the new architecture. 
       Embodiment 15 
       [0359]      FIG. 26  is a schematic flowchart of a method for creating an IP-CAN session in the 15 th  embodiment of the present disclosure. Through the method for creating an IP-CAN session in this embodiment, an IP-CAN session may be created in a new PCC architecture in the second roaming scenario shown in  FIG. 4 . As shown in  FIG. 26 , the method for creating an IP-CAN session in this embodiment includes the following steps  2101 - 2114 . 
         [0360]    Step  2101 : The PCEFa entity receives an IP-CAN session creation request. 
         [0361]    Step  2102 : Through a vPCEFb1 entity, the PCEFa entity sends a mobility Registration Request or bearer creation request that carries an APN and a user ID to the hPCEFb2 entity. 
         [0362]    Step  2103 : The hPCEFb2 entity allocates an IP address to the user. 
         [0363]    Step  2104 : Through the vPCEFb1 entity, the hPCEFb2 entity sends a mobility registration response or bearer creation response that carries the allocated IP address to the PCEFa entity. 
         [0364]    Step  2105 : The hPCEFb2 entity sends a PCC decision request that carries an APN, a user ID, the PCEFa entity&#39;s address, the v PCEFb1 entity&#39;s address, and the allocated IP address to the hPCRF entity. 
         [0365]    Step  2106 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the vPCEFb1 entity according to the received vPCEFb1 entity&#39;s address. 
         [0366]    Step  2107 : Through the vPCRF entity, the vPCEFb1 entity sends a Gx session creation response to the hPCRF entity. 
         [0367]    Step  2108 : Through the vPCRF entity, the hPCRF entity sends a Gx session creation request that carries IP-CAN session information to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0368]    Step  2109 : Through the vPCRF entity, the PCEFa entity sends a Gx session creation response that carries IP-CAN bearer information to the hPCRF entity. 
         [0369]    Step  2110 : The PCRF entity formulates PCC rule(s) according to the received APN, user ID, IP address, IP-CAN bearer information, and the stored user subscription profile. 
         [0370]    Step  2111 : The hPCRF entity sends a PCC decision message that carries IP-CAN session information and the formulated PCC rule(s) to the hPCEFb2 entity. 
         [0371]    Step  2112 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the vPCEFb1 entity. 
         [0372]    Step  2113 : Through the vPCRF entity, the hPCRF entity sends a PCC decision message that carries the formulated PCC rule(s) to the PCEFa entity. 
         [0373]    Step  2114 : The PCEFa entity returns an IP-CAN session creation response. 
         [0374]    The IP-CAN session creation request received by the PCEFa entity in step  2101  may be a GTP message, or a trigger message unrelated to the 3G network. The mobility Registration Request sent by the PCEFa entity in step  2102  may be a Proxy Binding Update message, or Registration Request message, or other mobility IP Registration Request message. The IP-CAN session information in this method may be an OCS/OFCS address, or a default charging mode. The PCC decision message sent by the hPCRF entity to the hPCEFb2 entity and the vPCEFb1 entity may further carry bearer-unrelated event triggers. The PCC decision message sent by the hPCRF entity to the PCEFa entity in this method may further carry bearer-related event triggers. 
         [0375]    Besides, if the hPCRF entity does not store the user subscription profile, an additional step occurs between step  2105  and step  2106  of the method, and the additional step is: The hPCRF entity obtains user subscription profile from the SPR entity and stores the user subscription profile. If the IP-CAN session employs an online charging mode, an additional step occurs between step  2113  and step  2114  of the method, and the additional step is credit authorization, namely, the PCEFa, hPCEFb2, and vPCEFb1 request the relevant charging credit from the OCS. If the IP-CAN session employs a network control mode, an additional step occurs between step  2113  and step  2114  of the method, and the additional step is: The PCEFa initiates creation of an IP-CAN bearer. 
         [0376]    In  FIG. 26 , the sequence of step  2111 , step  2112 , and step  2113  is not fixed. 
         [0377]    Therefore, according to the method for creating an IP-CAN session in the 15th embodiment of the present disclosure, the hPCRF can identify that the PCEFa, hPCEFb2, and vPCEFb1 belong to the same IP-CAN session according to the APN and the user ID information sent by the PCEFa, hPCEFb2, and vPCEFb1, formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa, hPCEFb2, and vPCEFb1. In this way, an IP-CAN session is created in the new architecture. 
         [0378]    The credit authorization process in embodiments 11-15, namely, the process in which the PCEFa, hPCEFb2, and vPCEFb1 request the relevant charging credit from the OCS, may be the same as the credit authorization process in  FIG. 27 ,  FIG. 28 ,  FIG. 29 , or  FIG. 30 . 
         [0379]      FIG. 27  is a schematic flowchart of the seventh process of credit authorization in this embodiment. As shown in  FIG. 27 , the seventh process of credit authorization in this embodiment includes the following steps  2201 - 2204 : 
         [0380]    Step  2201 : Through a vOCS entity, the PCEFa entity sends a credit request that carries an hPCEFb2 entity&#39;s address and a vPCEFb1 entity&#39;s address to an hOCS entity. 
         [0381]    Step  2202 : According to the received hPCEFb2 entity&#39;s address, the hOCS entity sends a credit response to the hPCEFb2 entity, where the credit response carries an online charging credit and a bearer-unrelated credit re-authorization trigger. 
         [0382]    Step  2203 : Through a vOCS entity, the hOCS entity sends a credit response that carries a bearer-unrelated credit re-authorization trigger to the vPCEFb1 entity according to the received vPCEFb1 entity&#39;s address. 
         [0383]    Step  2204 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0384]    The sequence of step  2202 , step  2203 , and step  2204  is not fixed. 
         [0385]      FIG. 28  is a flowchart of the eighth process of credit authorization in this embodiment. As shown in  FIG. 28 , the eighth process of credit authorization in this embodiment includes the following steps  2301 - 2304 : 
         [0386]    Step  2301 : The hPCEFb2 entity sends a credit request that carries a PCEFa entity&#39;s address and a vPCEFb1 entity&#39;s address to an hOCS entity. 
         [0387]    Step  2302 : The hOCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the hPCEFb2 entity. 
         [0388]    Step  2303 : Through a vOCS entity, the hOCS entity sends a credit response that carries a bearer-unrelated credit re-authorization trigger to the vPCEFb1 entity according to the received vPCEFb1 entity&#39;s address. 
         [0389]    Step  2304 : Through a vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0390]    The sequence of step  2302 , step  2303 , and step  2304  is not fixed. 
         [0391]      FIG. 29  is a schematic flowchart of the ninth process of credit authorization in this embodiment. As shown in  FIG. 29 , the ninth process of credit authorization in this embodiment includes the following steps  2401 - 2404 : 
         [0392]    Step  2401 : Through a vOCS entity, the vPCEFb1 entity sends a credit request that carries a PCEFa entity&#39;s address and an hPCEFb2 entity&#39;s address to an hOCS entity. 
         [0393]    Step  2402 : According to the received hPCEFb2 entity&#39;s address, the hOCS entity sends a credit response to the hPCEFb2 entity, where the credit response carries an online charging credit and a bearer-unrelated credit re-authorization trigger. 
         [0394]    Step  2403 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-unrelated credit re-authorization trigger to the vPCEFb1 entity. 
         [0395]    Step  2404 : Through a vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity according to the received PCEFa entity&#39;s address. 
         [0396]    The sequence of step  2402 , step  2403 , and step  2404  is not fixed. 
         [0397]      FIG. 30  is a schematic flowchart of the  10 th process of credit authorization in this embodiment. As shown in  FIG. 30 , the 10th process of credit authorization in this embodiment includes the following steps  2501 - 2506 : 
         [0398]    Step  2501 : The hPCEFb2 entity sends a credit request to an hOCS entity. 
         [0399]    Step  2502 : The hOCS entity sends a credit response that carries an online charging credit and a bearer-unrelated credit re-authorization trigger to the hPCEFb2 entity. 
         [0400]    Step  2503 : Through a vOCS entity, the vPCEFb1 entity sends a credit request to the hOCS entity. 
         [0401]    Step  2504 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-unrelated credit re-authorization trigger to the vPCEFb1 entity. 
         [0402]    Step  2505 : Through a vOCS entity, the PCEFa entity sends a credit request to the hOCS entity. 
         [0403]    Step  2506 : Through the vOCS entity, the hOCS entity sends a credit response that carries a bearer-related credit re-authorization trigger to the PCEFa entity. 
         [0404]    The sequence of step  2501  and step  2502 , the sequence of step  2503  and step  2504 , and the sequence of step  2505  and step  2506  are not fixed. 
         [0405]    Described above is a method for creating an IP-CAN session in an embodiment of the present disclosure. Now, the method for deleting an IP-CAN session in an embodiment of the present disclosure is described below. 
         [0406]      FIG. 31  is a schematic flowchart of a method for deleting an IP-CAN session in an embodiment of the present disclosure. As shown in  FIG. 31 , the method for deleting an IP-CAN session in this embodiment includes: 
         [0407]    Step  21 : The PCEFa entity or PCEFb entity receives an IP-CAN session deletion request. 
         [0408]    Step  22 : The PCEFa entity, or the PCEFb entity, or both of them send an IP-CAN session deletion indication message to the PCRF entity. Mobile deregistration or bearer deletion is performed between the PCEFa entity and the PCEFb entity, and the PCEFa entity and the PCEFb entity delete the stored PCC rule(s). 
         [0409]    Step  23 : The PCEFa entity or PCEFb entity returns an IP-CAN session deletion response. 
         [0410]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa entity and the PCEFb entity delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 16 
       [0411]      FIG. 32  is a schematic flowchart of a method for deleting an IP-CAN session in the 16 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 32 , the method for deleting an IP-CAN session in this embodiment includes the following steps  2601 - 2608 . 
         [0412]    Step  2601 : The PCEFa entity receives an IP-CAN session deletion request. 
         [0413]    Step  2602 : The PCEFa entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0414]    Step  2603 : The PCRF entity searches for the formulated PCC rule(s). 
         [0415]    Step  2604 : Mobile deregistration or bearer deletion occurs between the PCEFa entity and the PCEFb entity. 
         [0416]    Step  2605 : The PCRF entity notifies the PCEFb entity to delete the stored PCC rule(s). 
         [0417]    Step  2606 : The PCEFa entity deletes the stored PCC rule(s). 
         [0418]    Step  2607 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0419]    Step  2608 : The PCEFa entity returns an IP-CAN session deletion response. 
         [0420]    The IP-CAN session deletion request received by the PCEFa entity in step  2601  may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa entity and the PCEFb entity, the PCEFb entity further deletes the stored event triggers and credit re-authorization triggers in step  2605 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  2606 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  2607  and step  2608  in this method, and the additional step is: The PCEFb entity sends a final credit report to the OCS entity. If the PCRF entity has customized subscription notification, the method further includes this step: The PCRF entity sends a subscription notification cancellation message to the SPR entity. After step  2603 , the method may further include this step: The PCRF entity indicates lack of service transfer resources to the AF entity. 
         [0421]    The sequence of step  2604 , step  2605 , and step  2606  is not fixed. 
         [0422]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa entity and the PCEFb entity delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 17 
       [0423]      FIG. 33  is a schematic flowchart of a method for deleting an IP-CAN session in the 17 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 33 , the method for deleting an IP-CAN session in this embodiment includes the following steps  2701 - 2708 . 
         [0424]    Step  2701 : The PCEFb entity receives an IP-CAN session deletion request. 
         [0425]    Step  2702 : The PCEFb entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0426]    Step  2703 : The PCRF entity searches for the formulated PCC rule(s). 
         [0427]    Step  2704 : Mobile deregistration or bearer deletion occurs between the PCEFa entity and the PCEFb entity. 
         [0428]    Step  2705 : The PCEFb entity deletes the stored PCC rule(s). 
         [0429]    Step  2706 : The PCRF entity notifies the PCEFa entity to delete the stored PCC rule(s). 
         [0430]    Step  2707 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFb entity. 
         [0431]    Step  2708 : The PCEFb entity returns an IP-CAN session deletion response. 
         [0432]    The IP-CAN session deletion request in step  2701  may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa entity and the PCEFb entity, the PCEFb entity further deletes the stored event triggers and credit re-authorization triggers in step  2705 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  2706 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  2707  and step  2708  in this method, and the additional step is: The PCEFb entity sends a final credit report to the OCS entity. If the PCRF entity has customized subscription notification, the method further includes this step: The PCRF entity sends a subscription notification cancellation message to the SPR entity. After step  2703 , the method may further include this step: The PCRF entity indicates lack of service transfer resources to the AF entity. 
         [0433]    The sequence of step  2704 , step  2705 , and step  2706  is not fixed. 
         [0434]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa entity and the PCEFb entity delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 18 
       [0435]      FIG. 34  is a flowchart of a method for deleting an IP-CAN session in the 18 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 34 , the method for deleting an IP-CAN session in this embodiment includes the following steps  2801 - 2810 . 
         [0436]    Step  2801 : The PCEFa entity receives an IP-CAN session deletion request. 
         [0437]    Step  2802 : The PCEFa entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0438]    Step  2803 : The PCRF entity searches for the formulated PCC rule(s). 
         [0439]    Step  2804 : Mobile deregistration or bearer deletion occurs between the PCEFa entity and the PCEFb entity. 
         [0440]    Step  2805 : The PCEFb entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0441]    Step  2806 : The PCEFb entity deletes the stored PCC rule(s). 
         [0442]    Step  2807 : The PCEFa entity deletes the stored PCC rule(s). 
         [0443]    Step  2808 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFb entity. 
         [0444]    Step  2809 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0445]    Step  2810 : The PCEFa entity returns an IP-CAN session deletion response. 
         [0446]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa entity and the PCEFb entity, the PCEFb entity further deletes the stored event triggers and credit re-authorization triggers in step  2806 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  2807 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  2809  and step  2810  in this method, and the additional step is: The PCEFb entity sends a final credit report to the OCS entity. If the PCRF entity has customized subscription notification, the method further includes this step: The PCRF entity sends a subscription notification cancellation message to the SPR entity. After step  2803 , the method may further include this step: The PCRF entity indicates lack of service transfer resources to the AF entity. 
         [0447]    The sequence of step  2806  and step  2807  is not fixed. 
         [0448]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa entity and the PCEFb entity delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 19 
       [0449]      FIG. 35  is a schematic flowchart of a method for deleting an IP-CAN session in the 19 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 2 . As shown in  FIG. 35 , the method for deleting an IP-CAN session in this embodiment includes the following steps  2901 - 2909 . 
         [0450]    Step  2901 : The PCEFb entity receives an IP-CAN session deletion request. 
         [0451]    Step  2902 : The PCEFb entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0452]    Step  2903 : The PCRF entity searches for the formulated PCC rule(s). 
         [0453]    Step  2904 : Mobile deregistration or bearer deletion occurs between the PCEFa entity and the PCEFb entity. 
         [0454]    Step  2905 : The PCEFb entity deletes the stored PCC rule(s). 
         [0455]    Step  2906 : The PCEFa entity sends an IP-CAN session deletion indication message to the PCRF entity. 
         [0456]    Step  2907 : The PCEFa entity deletes the stored PCC rule(s). 
         [0457]    Step  2908 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0458]    Step  2909 : The PCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFb entity. 
         [0459]    Step  2910 : The PCEFb entity returns an IP-CAN session deletion response. 
         [0460]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa entity and the PCEFb entity, the PCEFb entity further deletes the stored event triggers and credit re-authorization triggers in step  29056 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  2907 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  2909  and step  2810  in this method, and the additional step is: The PCEFb entity sends a final credit report to the OCS entity. If the PCRF entity has customized subscription notification, the method further includes this step: The PCRF entity sends a subscription notification cancellation message to the SPR entity. After step  2903 , the method may further include this step: The PCRF entity indicates lack of service transfer resources to the AF entity. An additional step may occur between step  2906  and step  2908 , and the additional step may be: The PCRF entity searches for the formulated PCC rule(s), and the sequence of this additional step and step  2907  is not fixed. 
         [0461]    The sequence of step  2903  and step  2905  is not fixed. 
         [0462]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa entity and the PCEFb entity delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
         [0463]    The method for deleting an IP-CAN session in embodiments 16-19 is also applicable to the PCC architecture in the first roaming scenario shown in  FIG. 3 . The difference is: When the IP-CAN session deletion method illustrated in  FIG. 32-FIG .  35  is applied to the PCC architecture shown in  FIG. 3 , the PCEFa entity is located in the visited network, the PCEFb entity is located in the home network, the PCRF entity is the hPCRF entity located in the home network, and messages are transferred between the PCEFa entity and the hPCRF entity through a vPCRF entity located in the visited network. Besides, messages may be further transferred between the PCEFa entity and the PCEFb entity through a core network entity located in the visited network. 
       Embodiment 20 
       [0464]      FIG. 36  is a schematic flowchart of a method for deleting an IP-CAN session in the 20 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 36 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3001 - 3009 . 
         [0465]    Step  3001 : The PCEFa entity receives an IP-CAN session deletion request. 
         [0466]    Step  3002 : Through the vPCRF entity, the PCEFa entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0467]    Step  3003 : The hPCRF entity searches for the formulated PCC rule(s). 
         [0468]    Step  3004 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0469]    Step  3005 : The hPCRF entity notifies the hPCEFb2 entity to delete the stored PCC rule(s). 
         [0470]    Step  3006 : Through the vPCRF entity, the hPCRF entity notifies the vPCEFb1 entity to delete the stored PCC rule(s). 
         [0471]    Step  3007 : The PCEFa entity deletes the stored PCC rule(s). 
         [0472]    Step  3008 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0473]    Step  3009 : The PCEFa entity returns an IP-CAN session deletion response. 
         [0474]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3005 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3006 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3007 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3008  and step  3009  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3003 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. 
         [0475]    The sequence of step  3005 , step  3006 , and step  3007  is not fixed. 
         [0476]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 21 
       [0477]      FIG. 37  is a schematic flowchart of a method for deleting an IP-CAN session in the 21 st  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 37 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3101 - 3109 . 
         [0478]    Step  3101 : The hPCEFb2 entity receives an IP-CAN session deletion request. 
         [0479]    Step  3102 : The hPCEFb2 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0480]    Step  3103 : The hPCRF entity searches for the formulated PCC rule(s). 
         [0481]    Step  3104 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0482]    Step  3105 : The hPCEFb2 entity deletes the stored PCC rule(s). 
         [0483]    Step  3106 : Through the vPCRF entity, the hPCRF entity notifies the vPCEFb1 entity to delete the stored PCC rule(s). 
         [0484]    Step  3107 : Through the vPCRF entity, the hPCRF entity notifies the PCEFa entity to delete the stored PCC rule(s). 
         [0485]    Step  3108 : The hPCRF entity sends an IP-CAN session deletion acknowledgement message to the hPCEFb2 entity. 
         [0486]    Step  3109 : The hPCEFb2 entity returns an IP-CAN session deletion response. 
         [0487]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3105 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3106 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3107 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3108  and step  3109  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3103 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. 
         [0488]    The sequence of step  3005 , step  3006 , and step  3007  is not fixed. 
         [0489]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 22 
       [0490]      FIG. 38  is a schematic flowchart of a method for deleting an IP-CAN session in the 22 nd  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 38 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3201 - 3213 . 
         [0491]    Step  3201 : The PCEFa entity receives an IP-CAN session deletion request. 
         [0492]    Step  3202 : Through the vPCRF entity, the PCEFa entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0493]    Step  3203 : The hPCRF entity searches for the formulated PCC rule(s). 
         [0494]    Step  3204 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0495]    Step  3205 : Through the vPCRF entity, the vPCEFb1 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0496]    Step  3206 : The vPCEFb1 entity deletes the stored PCC rule(s). 
         [0497]    Step  3207 : The PCEFa entity deletes the stored PCC rule(s). 
         [0498]    Step  3208 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the vPCEFb1 entity. 
         [0499]    Step  3209 : The hPCEFb2 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0500]    Step  3210 : The hPCEFb2 entity deletes the stored PCC rule(s). 
         [0501]    Step  3211 : The hPCRF entity sends an IP-CAN session deletion acknowledgement message to the hPCEFb2 entity. 
         [0502]    Step  3212 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0503]    Step  3213 : The PCEFa entity returns an IP-CAN session deletion response. 
         [0504]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3206 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3210 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3207 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3212  and step  3213  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3203 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. After step  3205  and after step  3208 , the method may further include this step: The hPCRF entity searches for the formulated PCC rule(s). 
         [0505]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 23 
       [0506]      FIG. 39  is a schematic flowchart of a method for deleting an IP-CAN session in the 23 rd  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 39 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3301 - 3313 . 
         [0507]    Step  3301 : The hPCEFb2 entity receives an IP-CAN session deletion request. 
         [0508]    Step  3302 : The hPCEFb2 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0509]    Step  3303 : The hPCRF entity searches for the formulated PCC rule(s). 
         [0510]    Step  3304 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0511]    Step  3305 : The hPCEFb2 entity deletes the stored PCC rule(s). 
         [0512]    Step  3306 : Through the vPCRF entity, the PCEFa entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0513]    Step  3307 : The PCEFa entity deletes the stored PCC rule(s). 
         [0514]    Step  3308 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0515]    Step  3309 : Through the vPCRF entity, the vPCEFb1 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0516]    Step  3310 : The vPCEFb1 entity deletes the stored PCC rule(s). 
         [0517]    Step  3311 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the vPCEFb1 entity. 
         [0518]    Step  3312 : The hPCRF entity sends an IP-CAN session deletion acknowledgement message to the hPCEFb2 entity. 
         [0519]    Step  3313 : The hPCEFb2 entity returns an IP-CAN session deletion response. 
         [0520]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3305 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3310 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3307 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3312  and step  3313  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3303 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. After step  3306  and after step  3309 , the method may further include this step: The hPCRF entity searches for the formulated PCC rule(s). 
         [0521]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 24 
       [0522]      FIG. 40  is a schematic flowchart of a method for deleting an IP-CAN session in the 24 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 40 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3401 - 3409 . 
         [0523]    Step  3401 : The vPCEFb1 entity receives an IP-CAN session deletion request. 
         [0524]    Step  3402 : Through the vPCRF entity, the vPCEFb1 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0525]    Step  3403 : The hPCRF entity searches for the formulated PCC rules. 
         [0526]    Step  3404 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0527]    Step  3405 : The vPCEFb1 entity deletes the stored PCC rule(s). 
         [0528]    Step  3406 : The hPCRF entity notifies the hPCEFb2 entity to delete the stored PCC rule(s). 
         [0529]    Step  3407 : Through the vPCRF entity, the hPCRF entity notifies the PCEFa entity to delete the stored PCC rule(s). 
         [0530]    Step  3408 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the vPCEFb1 entity. 
         [0531]    Step  3409 : The vPCEFb1 entity returns an IP-CAN session deletion response. 
         [0532]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3406 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3405 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3407 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3408  and step  3409  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3403 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. 
         [0533]    The sequence of step  3405 , step  3406 , and step  3407  is not fixed. 
         [0534]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 25 
       [0535]      FIG. 41  is a schematic flowchart of a method for deleting an IP-CAN session in the 25 th  embodiment of the present disclosure. Through the method for deleting an IP-CAN session in this embodiment, an IP-CAN session may be deleted in a new PCC architecture shown in  FIG. 4 . As shown in  FIG. 41 , the method for deleting an IP-CAN session in this embodiment includes the following steps  3501 - 3513 . 
         [0536]    Step  3501 : The vPCEFb1 entity receives an IP-CAN session deletion request. 
         [0537]    Step  3502 : Through the vPCRF entity, the vPCEFb1 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0538]    Step  3503 : The hPCRF entity searches for the formulated PCC rule(s). 
         [0539]    Step  3504 : Mobile deregistration or bearer deletion occurs between the PCEFa, vPCEFb1, and hPCEFb2. 
         [0540]    Step  3505 : The vPCEFb1 entity deletes the stored PCC rule(s). 
         [0541]    Step  3506 : Through the vPCRF entity, the PCEFa entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0542]    Step  3507 : The PCEFa entity deletes the stored PCC rule(s). 
         [0543]    Step  3508 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the PCEFa entity. 
         [0544]    Step  3509 : The hPCEFb2 entity sends an IP-CAN session deletion indication message to the hPCRF entity. 
         [0545]    Step  3510 : The hPCEFb2 entity deletes the stored PCC rule(s). 
         [0546]    Step  3511 : The hPCRF entity sends an IP-CAN session deletion acknowledgement message to the hPCEFb2 entity. 
         [0547]    Step  3512 : Through the vPCRF entity, the hPCRF entity sends an IP-CAN session deletion acknowledgement message to the vPCEFb1 entity. 
         [0548]    Step  3513 : The vPCEFb1 entity returns an IP-CAN session deletion response. 
         [0549]    The IP-CAN session deletion request in this method may be a GTP message, or a trigger message unrelated to the 3G network. If event triggers and credit re-authorization triggers are stored in the PCEFa, hPCEFb2, and vPCEFb1, the hPCEFb2 entity further deletes the stored event triggers and credit re-authorization triggers in step  3510 , the vPCEFb1 entity further deletes the stored event triggers and credit re-authorization triggers in step  3505 , and the PCEFa entity further deletes the stored event triggers and credit re-authorization triggers in step  3507 . If the IP-CAN session employs an online charging mode, an additional step occurs between step  3512  and step  3513  in this method, and the additional step is: The hPCEFb2 entity sends a final credit report to the OCS entity. If the hPCRF entity has customized subscription notification, the method further includes this step: The hPCRF entity sends a subscription notification cancellation message to the SPR entity. After step  3503 , the method may further include this step: The hPCRF entity indicates lack of service transfer resources to the AF entity. After step  3506  and after step  3509 , the method may further include this step: The hPCRF entity searches for the formulated PCC rule(s). 
         [0550]    According to the method for deleting an IP-CAN session in this embodiment, the PCEFa, vPCEFb1, and hPCEFb2 delete the stored PCC rule(s) respectively, and the IP-CAN session is deleted in the new architecture. 
       Embodiment 26 
       [0551]      FIG. 42  schematically shows a structure of an apparatus for creating an IP-CAN session in the 26 th  embodiment of the present disclosure. As shown in  FIG. 42 , the IP-CAN session creation apparatus includes: a PCEFa entity  1 , a PCEFb entity  2 , and a PCRF entity  3 . 
         [0552]    The PCEFa entity  1  is configured to receive an IP-CAN session creation request, and return an IP-CAN session creation response after receiving IP-CAN session information. 
         [0553]    The PCEFb entity  2  is configured to perform mobility registration with the PCEFa entity  1 . 
         [0554]    The PCRF entity  3  is configured to create a session with a PCEFa entity and a PCEFb entity, and send IP-CAN session information to the PCEFa entity and the PCEFb entity. 
         [0555]    In practice, the IP-CAN session creation apparatus is operated in the following way. 
         [0556]    After receiving the IP-CAN session creation request, the PCEFa entity  1  creates a session with the PCRF entity  3 , and then the PCEFa entity  1  and the PCEFb entity  2  perform mobility registration. 
         [0557]    The PCEFb entity  2  creates a session with the PCRF entity  3 . 
         [0558]    The PCRF entity  3  sends the IP-CAN session information to the PCEFa entity  1  and the PCEFb entity  2 . 
         [0559]    After receiving the IP-CAN session information, the PCEFa entity  1  returns an IP-CAN session creation response, and the IP-CAN session creation process is complete. 
         [0560]    The detailed process of the PCRF entity  3  sending IP-CAN session information to the PCEFa entity  1  and the PCEFb entity  2  is: The PCRF entity  3  formulates PCC rule(s) for the IP-CAN session, and submits the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity  1  and the PCEFb entity  2 . 
         [0561]    According to the apparatus for creating an IP-CAN session in the 26th embodiment, the PCRF entity may formulate PCC rule(s) for the IP-CAN session, and submit the IP-CAN session information and the formulated PCC rule(s) to the PCEFa entity and the PCEFb entity. In this way, an IP-CAN session is created in the new architecture. 
         [0562]    It is understandable to those skilled in the art that all or part of the steps of the foregoing embodiments may be implemented by hardware such as a computer having a processor instructed by a computer program. The program may be stored in a computer-readable storage medium accessible to the processor. When being executed, the program performs all or part of the steps in foregoing method embodiments. 
         [0563]    All function entities in the embodiments of the present disclosure may be integrated into a processing module, or exist independently, or two or more of such entities are integrated into a module. The integrated module may be hardware or a software module. When being implemented as a software module and sold or applied as an independent product, the integrated module may also be stored in a computer-readable storage medium. 
         [0564]    The storage medium may be a Read-Only Memory (ROM), magnetic disk, or Compact Disk (CD). 
         [0565]    Although the disclosure has been described through some exemplary embodiments, the disclosure is not limited to such embodiments. It is apparent that those skilled in the art can make modifications and variations to the disclosure without departing from the spirit and scope of the disclosure. The disclosure is intended to cover the modifications and variations provided that they fall in the scope of protection defined by the following claims or their equivalents.