WO2012146092A1

WO2012146092A1 - Policy control method and system for ip flow mobility

Info

Publication number: WO2012146092A1
Application number: PCT/CN2012/072330
Authority: WO
Inventors: 周晓云; 毕以峰; 卢飞
Original assignee: 中兴通讯股份有限公司
Priority date: 2011-04-29
Filing date: 2012-03-14
Publication date: 2012-11-01
Also published as: CN102761932B; CN102761932A

Abstract

A Policy control method and system for Internet Protocol (IP) flow mobility are provided, wherein the method comprises: when a Policy and Charging Rules Function (PCRF) entity receives routing rule information of IP flow mobility, which is sent by a Policy and Charging Enforcement Function (PCEF) entity, if the PCRF entity has judged that a part of service data flow of the service provided by an Application Function (AF) entity is required to be transferred, and the AF entity does not support the IP flow mobility, or if the PCRF entity requests for resource acceptance control of a Broad Band Forum (BBF) access network according to the routing rule information of IP flow mobility, and the BBF access network refuses the request, the PCRF entity returns an indication that the routing rule information of IP flow mobility is refused to the PCEF entity.

Description

Strategy control system and system for IP flow migration

Technical field

The present invention relates to the field of communications technologies, and in particular, to a policy control method and system for IP flow migration.

Background technique

The 3rd Generation Partnership Project (3GPP) evolved Evolved Packet System (EPS) is mainly composed of the Evolved Universal Terrestrial Radio Access Network (Evolved Universal Terrestrial Radio Access Network). Referred to as E-UTRAN, Mobility Management Entity (MME), Serving Gateway (S-GW), Packet Data Network Gateway (P-GW or PDN) GW), Home Subscriber Server (HSS), 3GPP Authentication, Authorization and Accounting (AAA), and Policy and Charging Rules (Policy and Charging Rules) Function, abbreviated as PCRF) is composed of entities and other supporting nodes.

Figure 1 is a schematic diagram of the system architecture of EPS. The MME is responsible for control planes such as mobility management, non-access stratum signaling processing, and user mobility management context management; the S-GW is an access gateway device connected to the E-UTRAN, in the E-UTRAN and P-GW forwards data and is responsible for buffering paging waiting data. P-GW is a border gateway between EPS and Packet Data Network (PDN), which is responsible for PDN access and EPS. The function of forwarding data between PDNs; PCRF is a policy and charging rule function entity, which is connected to the service network protocol (Internet Protocol, IP for short) service network through the receiving interface Rx to obtain service information. In addition, the PCRF also passes Gx or The Gxa or Gxc interface is connected to the gateway device in the network, and is responsible for initiating the establishment of the IP bearer, ensuring the quality of service (QoS) of the service data, and performing charging control.

EPS supports interworking with non-3GPP systems, and interworking with non-3GPP systems is implemented through the S2a/b/c interface, which is an anchor point between 3GPP and non-3GPP systems. The EPS system architecture in Figure 1. In the figure, non-3GPP systems are classified into a trusted non-3GPP IP access network and an untrusted non-3GPP IP access network. The trusted non-3GPP IP access network can be directly connected to the P-GW through the S2a interface; the untrusted non-3GPP IP access needs to be connected to the P-GW through an Evolved Packet Data Gateway (E-PDG). The interface between the E-PDG and the P-GW is S2b. The S2c provides user plane-related control and mobility support between the User Equipment (UE) and the P-GW. The supported mobility management. The protocol is IPv6 Support for Dual Stack Hosts and Routers (referred to as DSMIPv6).

In the EPS system, the Policy and Charging Enforcement Function (PCEF) entity exists in the P-GW, and the PCRF and the P-GW exchange information through the Gx interface. When the interface between the P-GW and the S-GW is based on the PMIPv6, the S-GW also has a Bearer Binding and Event Report Function (BBERF) entity for performing QoS control on the service data flow. The S-GW exchanges information with the PCRF through the Gxc interface. When accessed through a trusted non-3GPP access system, the BBERF is also resident in the trusted non-3GPP access gateway. The trusted non-3GPP access gateway exchanges information with the PCRF through the Gxa interface. The service function (Application Function, referred to as AF) for the UE is sent to the PCRF through the Rx interface to send service information for the Policy and Charging Control (PCC) policy. In 3GPP, the corresponding PDN network can be found by the Access Point Name (APN). Typically, a connection from a UE to a PDN network is referred to as an IP Connectivity Access Network (IP-CAN) session.

EPS support The UE accesses a PDN network through multiple access networks at the same time (that is, the network where the operator provides the IP service), which can also be called IP flow mobility. As shown in FIG. 2, the UE accesses the PDN network through the same P-GW through the non-3GPP IP access network and the 3GPP access network under the coverage of the non-3GPP access network and the 3GPP access network.

In this scenario, the P-GW allocates an IP address to the UE, that is, there is only one IP-CAN session between the UE and the PDN. The UE, the P-GW, or the PCRF determines which access network connection the IP data stream is transmitted according to different characteristics of the service. For example, when the non-3GPP access network is Wireless Fidelity (WiFi), the service data stream of the Hyper Text Transfer Protocol (HTTP) and the File Transfer Protocol (FTP) can be used. by The WiFi access network is connected, and at the same time, the Voice Over Internet Protocol (VoIP) service data stream can be sent to the user equipment through 3GPP, so that the real-time requirements such as Http and Ftp are low. The service can take advantage of the lower WiFi tariff; while the services with higher real-time requirements such as VoIP can take advantage of 3GPP QoS control and better mobility management.

FIG. 3 shows a process in which the UE first establishes a PDN connection through a 3GPP access network access and then establishes a PDN connection through non-3GPP access, and simultaneously uses the two access networks to connect using the PDN. Among them, Dynamic Policy and Charging Control (PCC) is deployed in the network. When accessing through trusted non-3GPP, the UE uses the DSMIPv6 protocol.

As shown in Figure 3, the process mainly includes the following steps:

Step S301: The UE accesses an evolved packet core network (Evolved Packet Core, referred to as EPC) through the 3GPP access network.

A tunnel is established between the S-GW and the P-GW through a General Packet Radio Service Tunneling Protocol (GTP) or a Proxy Mobile IPv6 (PMIPv6) protocol, and may have been established. There is traffic on the tunnel. The UE accesses the service provided by the AF through the established IP-CAN session, and the AF request PCRF reports the IP-CAN type of the access network connection through which the service data stream of the AF-provided service passes (further may also include the RAT type), and the PCRF according to the request The IP-CAN type reported to the AF is 3GPP-EPS, and the RAT type is E-UTRAN. Assume that the service provided by the AF contains two service data flows (SDF), which are represented as SDF1 and SDF2, respectively.

Step S302, the UE discovers the non-3GPP access network and decides to initiate multiple access.

Wherein, if the non-3GPP access network is trusted, the UE performs access authentication and authorization in the trusted non-3GPP access network, and the UE performs layer 3 attachment and obtains the local IP address IP Address 1 as the care-of address (Care of Address) , referred to as CoA). If the non-3GPP access network is untrusted, the UE will establish an IPSec (IP Security) tunnel with the ePDG. During the tunnel establishment process, the ePDG assigns the IP address IP Address 1 to the UE as a CoA.

Step S303, the bearer binding and event reporting function (BBERF) located in the trusted non-3GPP access network or the ePDG sends a gateway control session establishment message to the PCRF, and establishes a request to establish a gateway control. Session, carrying the user ID and IP Addressl.

Step S304, the PCRF returns an acknowledgement message to the BBERF.

Step 305: The UE finds the P-GW selected during the 3GPP access by using a mobile IPv6 (Mobile IPv6, MIPv6 for short) self-boot process.

A security association is established between the UE and the PDN. UE uses network key exchange 2 (Internet Key

Exchange2 (referred to as IKEv2) initiates the establishment of a security association. The Extensible Authentication Protocol (EAP) is used for authentication on top of IKEv2. The P-GW interacts with AAA to complete EAP authentication. And in the process, the P-GW returns the IP address IP Address2 allocated by the P-GW when the UE accesses the 3GPP, and the UE uses the IP address as the Home of Address (HoA) when the DSMIPv6 is bound. At this time, the P-GW performs the function of Home Agent (HA).

Step S306: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries a HoA, a CoA, a BID (Banding Identification), and a FID (Flow Identification). Among them, (HoA, CoA, BID, FID) is a correspondence.

The value of the HoA can be determined by the value of the HoA. The value of the CoA is the value of the CoA.

IP Address 1 indicates that the corresponding BID is a binding through non-3GPP access, and a certain data flow of the user access service uniquely identified by the FID is bound to the connection through the non-3GPP access.

Alternatively, the binding update message may be the IP address of the HoA, and the value of the CoA is the IP address2, indicating that the corresponding BID is a binding through the 3GPP access, and the service data flow identified by the FID is bound to the 3GPP. On the connection.

In this flow, it is assumed that the UE requests to migrate a service data stream (SDF1) transmitted through the 3GPP access network connection to the non-3GPP access network connection.

Step S307: After receiving the binding update message, the P-GW/HA performs multiple registration flow binding according to the parameters HoA, CoA, BID, FID, and Routing Filters carried in the message. That is, the P-GW simultaneously maintains the GTP/PMIPv6 tunnel with the S-GW and the DSMIPv6 tunnel with the UE, and binds the service data flow to the 3GPP access or the non-3GPP access. The PCEF located at the P-GW sends an IP-CAN session modification request indication to the PCRF, and the PCEF will send an event trigger routing rule modification (ROUTING_RULE_CHANGE) and IP flow migration routing rule information to the PCRF (for the process) In the case of a migrated IP flow, the IP flow migration routing rule information includes installing and/or modifying an IP flow migration routing rule, where the IP flow migration routing rule is a correspondence between a service data flow and an access, and corresponds to a Routing Address by Routing Filters. The relationship is identified. When the value of the Routing Address is IP Address 1, it indicates that it is through non-3GPP access. When the value of the Routing Address is IP Address2, it indicates that it is accessed through 3GPP. The message includes the default IP flow migration routing rules, namely Routing Filters.

In this process, the UE migrates the service data flow SDF1 from the 3GPP access network connection to the non-3GPP access network connection, and the PCEF will provide the PCRF with the IP flow migration routing rule corresponding to the SDF1 to notify the PCRF of the service data flow. The migration of the route. In the routing rule, Routing Filters is the IP quintuple of the service data flow, and the Routing Address takes the value of IP Address 1.

Step S308: The PCRF reports the IP-CAN type (and possibly the RAT type (radio access type)) of the access network connection that the SDF1 passes to the AF according to the request of the AF. Here, the IP-CAN type takes the value of Non-3GPP-EPS.

Step S309: The AF returns an acknowledgement message to the PCRF.

Step S310, the PCRF installs and/or modifies an IP flow migration routing rule. If the service data flow corresponding to the IP flow migration routing rule is migrated (that is, the migration from the 3GPP access network connection to the non-3GPP access network connection), the PCRF updates the PCC rule correspondingly and returns it to the PCEF. The IP flow migration routing rule modified by the PCRF may cause the service data flow corresponding to the IP flow migration routing rule to be migrated from the source routing path to the new routing path. In this flow, the PCC rules for the service data flow from the transmission of the 3GPP access to the non-3GPP access are updated and returned to the PCEF. The process of updating the PCC rules for transporting the service data stream from the non-3GPP access to the 3GPP access is similar to this process, and therefore will not be described again.

Step S311: The P-GW/HA returns a binding acknowledgement message to the UE, where the message carries the HoA, the CoA, the BID, and the FID to confirm that the UE is successfully registered with multiple registrations, or the multiple registrations are flow binding and the flow migration is successful.

Step S312, since the SDF1 is migrated from the 3GPP access to the non-3GPP access, the PCRF will formulate a QoS rule according to the PCC rule updated by the service data flow, and provide the QoS rule to the trusted non-3GPP access network or the BBERF in the ePDG. . Step S313, the non-3GPP access network performs a specific process for resource allocation or modification.

Step S314, the BBERF returns an acknowledgement message to the PCRF.

Step S315, since the SDF1 is migrated from the 3GPP access to the non-3GPP access, and if the PMIPv6 tunnel is established between the S-GW and the P-GW, the PCRF deletes the QoS rule corresponding to the service data flow. The PCRF provides the QoS rule to be deleted to the BBERF in the S-GW through the gateway control session established by the UE during 3GPP access.

Step S316: The BBERF in the S-GW deletes the QoS rule, performs the bearer modification or release process of the 3GPP, and releases the resource of the migrated service data flow.

Step S317, the BBERF returns an acknowledgement message to the PCRF.

If a GTP tunnel is established between the S-GW and the P-GW, the P-GW will initiate a 3GPP bearer modification or release process after the S10 step, and release the resources of the migrated service data stream. S315-S317 will not be executed.

Step S318: The UE completes the multi-registration flow binding and the possible flow migration. A DSMIPv6 tunnel exists between the UE and the P-GW/HA, and a GTP/PMIPv6 tunnel exists between the S-GW and the P-GW. The UE or the network can determine which access the service data is transmitted according to the policy.

FIG. 4 shows a process in which the UE first establishes a PDN connection through a non-3GPP access network access and then establishes the same PDN connection through 3GPP access, and simultaneously uses the two access networks to connect using the PDN. Dynamic PCC is deployed in the network. The UE uses the DSMIPv6 protocol when trusted non-3GPP access is used.

As shown in FIG. 4, the process mainly includes the following steps S401 to S413:

Step S401: The UE accesses the EPC through the DSMIPv6 protocol through the non-3GPP access network, and the DSMIPv6 tunnel is established between the UE and the P-GW/HA, and the existing service is transmitted on the tunnel.

The address assigned by the non-3GPP access network to the UE is IP Address 1 as the CoA, and the IP address assigned by the P-GW to the UE is IP Address 2 as the HoA. The UE accesses the service provided by the AF through the established IP-CAN session, and the service provided by the AF includes two service data flows (SDF), which are respectively represented as SDF1 and SDF2, and the AF request PCRF reports the service data flow of the service. The IP-CAN type of the access network connection that is transmitted (further may also include the RAT class Type), the IP-CAN type reported by the PCRF to the AF according to the request is 3GPP-EPS, and the RAT type is E-UTRAN.

Step S402, the UE discovers the 3GPP access network and decides to initiate multiple access. The UE establishes a PDN connection to the same PDN through the 3GPP attach procedure. During the establishment process, the P-GW allocates an IP address to the UE as an IP Address2 to ensure that the same PDN connection is established through different accesses.

Step S403: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries (HoA, CoA, BID, FID). (HoA, CoA, BID, FID) is a correspondence.

The message is IP Address 2 and the CoA value is IP Address 1 , indicating that the corresponding BID is a binding through non-3GPP access, and a certain data flow of the user ID access service uniquely identified by the FID is bound to the non-3GPP. On the connection. The message is IP Address2 and the CoA value is IP Address2, indicating that the corresponding BID is a binding through 3GPP access, and the service data flow identified by the FID is bound to the connection through 3GPP access. The UE requests to migrate the service data stream SDF1 transmitted through the non-3GPP access to the 3GPP access network.

Step S404, after receiving the binding update message, the P-GW/HA, according to the carried parameter HoA,

CoA, BID, FID, and Routing Filters perform multiple registration flow bindings.

That is, the P-GW simultaneously maintains the GTP/PMIPv6 tunnel with the S-GW and the DSMIPv6 tunnel with the UE, and binds the service data flow to the 3GPP access or the non-3GPP access. The PCEF located at the P-GW sends an IP-CAN session modification request indication to the PCRF, and the PCEF will send an event trigger ROUTING_RULE_CHANGE and IP flow migration routing rule information to the PCRF (for the case of the migrated IP flow in the flow, IP) The flow migration routing rule information is to install and/or modify the IP flow migration routing rule, and the IP flow migration routing rule is the correspondence between the service data flow and the access, and the correspondence between the Routing Filters and the Routing Address is identified, and the Routing Address takes the value of IP Address. When it is 1, it is indicated that it is through non-3GPP access, and when the value of the Routing Address is IP Address2, it is indicated as access through 3GPP. This message may include the default IP flow migration routing rules, ie Routing Filters is a wildcard. The UE migrates the SDF1 from the non-3GPP access to the 3GPP access, and the PCEF provides the IPF migration routing rule corresponding to the service data flow to the PCRF to notify the PCRF of the migration of the routing of the service data flow. In the IP flow migration routing rule, Routing Filters is the IP quintuple of the service data flow, and the Routing Address takes the value of IP Address2. Step S405: The PCRF reports the IP-CAN type (and possibly the RAT type) of the access network connection that SDF1 passes to the AF according to the request of the AF. Here, the IP-CAN type takes the value of Non-3GPP-EPS.

Step S406: The AF returns an acknowledgement message to the PCRF.

Step S407: The PCRF installs and/or modifies an IP flow migration routing rule.

Since SDF1 has migrated (ie, migrated from non-3GPP access to 3GPP access), the PCRF updates the corresponding PCC rules and returns them to the PCEF. The IP flow migration routing rule that is newly installed in the PCRF may cause the service data flow corresponding to the IP flow migration routing rule to be migrated from the default route to the route specified by the IP flow migration routing rule. For the IP flow migration routing rule modified by the PCRF, the service data flow corresponding to the IP flow migration routing rule may be migrated from the source routing path to the new routing path. In this process, the PCC rules of the service data stream migrated from the non-3GPP access to the 3GPP access are updated and returned to the PCEF.

Step S408: The P-GW/HA returns a binding acknowledgement message to the UE, where the message carries the HoA, CoA, BID, and FID to confirm that the UE has multiple registrations, that is, the flow binding is successful or the multiple registration is flow binding and the flow migration succeeds.

The step S408 is performed after the step S403, and there is no certain order between the steps S404 and S407.

Step S409, since the SDF1 is migrated from the non-3GPP access to the 3GPP access, and if the PMIPv6 tunnel is established between the S-GW and the P-GW, the PCRF will formulate a QoS rule according to the PCC rule updated by the service data flow, and The QoS rule is provided to the BBERF in the S-GW.

Step S410, the BBERF installs the QoS rule, and the S-GW initiates execution of the 3GPP bearer modification or establishment process for resource allocation or modification.

Step S411, the BBERF returns an acknowledgement message to the PCRF.

If a GTP tunnel is established between the S-GW and the P-GW, the P-GW will initiate a 3GPP bearer modification or establishment process after the step S407, and allocate resources of the migrated service data stream. S409-S411 will not be executed.

Step S412, since the SDF1 is migrated from the non-3GPP access to the 3GPP access, the PCRF deletes the QoS rule corresponding to the service data flow in the non-3GPP access network or the ePDG. PCRF The QoS rule to be deleted is provided to the BBERF in the non-3GPP access network or the ePDG by the gateway control session established by the UE during non-3GPP access.

Step S413, the BBERF deletes the QoS rule, and initiates a specific resource tampering or release process of the non-3GPP.

Step S414, the BBERF returns an acknowledgement message to the PCRF.

Step S415: The UE completes the multi-registration flow binding and the flow migration, and the DSMIPv6 tunnel exists between the UE and the P-GW/HA, and the GTP/PMIPv6 tunnel exists between the S-GW and the P-GW. The UE or the network can decide which access the service data is transmitted through according to the policy.

FIG. 5 is a flowchart of data flow migration between two access networks after the UE implements multiple registration flow binding in the related art, where the service data flow migrated by the UE relates to two SDFs of the service provided by the AF ( Represented as one of SDF1 and SDF2 respectively, and a dynamic PCC is deployed in the network.

As shown in FIG. 5, the process mainly includes the following steps S501 to S511:

Step S501: The UE simultaneously connects to the 3GPP access and the non-3GPP access, and performs multiple registration flow binding. And the two SDFs of the UE accessing the service provided by the AF (represented as SDF1 and SDF2, respectively) are transmitted through the non-3GPP access network.

Step S502: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries (HoA, BID, FID). In the message, the UE may request to transmit through the non-3GPP access. The service data stream SDF1 (represented by FID) is migrated to the 3GPP access network (represented by BID). That is, the FID is used to represent the SDF, the BID is used to represent the 3GPP access network, and the binding relationship between the FID and the BID is updated. Indicates that SDF1 is migrated to the 3GPP access network.

Step S503: After receiving the binding update message, the P-GW/HA performs flow binding update, that is, flow migration, according to the carried parameters HoA, BID, and FID. The PCEF located in the P-GW sends an IP-CAN session modification request indication to the PCRF, and the PCEF sends an event trigger ROUTING_RULE_CHANGE and IP flow migration routing rule information to the PCRF, including modifying the IP flow migration routing rule corresponding to SDF1. In the routing rule, IP Address1 indicates that the currently transmitted access network is non-3GPP, and IP Address2 indicates that the currently transmitted access network is 3GPP. Use Routing Filters to represent the business data stream SDF1. Step S504: The PCRF reports the IP-CAN type (and possibly the RAT type) of the access network connection that SDF1 passes to the AF according to the request of the AF. Here, the IP-CAN type takes the value of Non-3GPP-EPS.

Step S505: The AF returns an acknowledgement message to the PCRF.

Step S506, the PCRF modifies the IP flow migration routing rule. The PCRF updates the PCC rules corresponding to SDF1 according to the IP flow migration routing rule.

Step S507: The P-GW/HA returns a binding acknowledgement message to the UE, where the message carries HoA, BID and FID to confirm that the UE routing rule is updated successfully.

Step S508, if a ΡΜΙΡνό tunnel is established between the S-GW and the P-GW, then the PCRF step S509, the BBERF installs a QoS rule, and the S-GW initiates a 3GPP bearer establishment, modification, or deletion process for resource allocation, modification, or release. .

Step S510, the BBERF returns an acknowledgement message to the PCRF.

If a GTP tunnel is established between the S-GW and the P-GW, the P-GW will initiate the establishment and modification of the bearer of the 3GPP after the step S506, and the S508-S510 will not execute.

Step S511: The PCRF deletes the QoS rule corresponding to the SDF1 on the BBERF in the trusted non-3GPP access network or the ePDG according to the rule reported by the PCEF.

Step S512, the BBERF deletes the QoS rule, and initiates a specific resource allocation, tampering or release process of the non-3GPP.

Step S513, the BBERF returns an acknowledgement message to the PCRF.

In the above process, in the case that the UE performs IP flow migration, if multiple IP flows of the service provided by the AF are transmitted through different access network connections, the PCRF needs to transmit the IP-CAN type (or RAT) of each IP flow. The type is notified to the AF separately, so that the AF can provide the charging system with the IP-CAN type (or RAT type) transmitted by different IP flows, thereby implementing differentiated charging, or AF for related policy decisions. In order to realize that the PCRF reports the IP-CAN type (or RAT type) of the access network connection transmitted by different IP flows to the AF, the AF must support the IP flow migration, that is, the AF needs to be able to distinguish the IP corresponding to each IP flow reported by the PCRF. CAN type (or RAT type). However, the following problems exist in the prior art: If the AF does not support the IP flow migration, and the UE performs the IP flow migration process, then the PCRF can only use one IP-CAN type (or RAT type). The IP-CAN type (or RAT type) that will cause the UE to access certain IP flows of the AF service to be transmitted is inconsistent with the IP-CAN type (or RAT type) reported by the PCRF. This inconsistency may result in billing errors.

In addition, many operators pay attention to Fixed Mobile Convergence (FMC) and target 3GPP and Broadband Forum (BBF) interconnection (also known as BBAI, Broadband Access Interworking). the study. For the scenario where the user accesses the mobile core network through the BBF, the QoS on the entire transmission path of the data (the data will pass through the fixed network and the mobile network transmission) needs to be guaranteed. In the current technology, the Broadband Policy Control Framework (BPCF) in the BBF is connected to the BBF through the PCRF to implement QoS guarantee. The BPCF is a policy control architecture in the BBF access. For the resource request message of the PCRF, the BPCF performs resource admission control according to the network policy and the subscription information of the BBF access, or forwards the resource request message to the network element of the other BBF access network ( For example, BNG), and other network elements perform resource admission control (that is, entrust other network elements to perform resource admission control). For example, when the UE accesses the 3GPP core network through a wireless local area network (WLAN), the total bandwidth requirement for all UE access services accessed through one WLAN access line does not exceed the bandwidth of the line (such as the subscription bandwidth or the line support). The maximum physical agent of the PCRF needs to interact with the BPCF when performing QoS authorization, so that the BBF access network performs resource admission control.

FIG. 6 is a schematic diagram of an architecture of a UE accessing a 3GPP core network through a BBF WLAN in the related art. As shown in Figure 6, the BBF WLAN access network acts as an untrusted non-3GPP access. In the architecture shown in Figure 6, after the UE accesses the BBF WLAN access network, the Broadband Access Server (BRAS)/BNG (Broadband Network Gateway) will perform 3GPP-based access. Authentication, while the BPF of the BBF actively initiates the S9* session to interact with the 3GPP PCRF. Thus, the PCRF can interact with the BPCF when performing QoS authorization, and the BPCF performs admission control of resources or entrusts other network elements to perform resource admission control (ie, the BBF access network performs resource admission control). However, when IP flow migration is applied to the technology (for example, when IP flows are migrated from 3GPP to WLAN, the PCRF needs to reserve the IP flow in the BBF access network). Resources), the following problems are not solved: After receiving the IP stream migration request from the UE (for example, migrating IP flows from 3GPP to WLAN), the PCEF provides IP flow routing rule information to the PCRF, and the PCRF requests access to the BBF according to the routing rule. The network requests resource admission control. If the BBF access network refuses at this time, how should the PCRF be handled? The corresponding solution is not given in the prior art.

FIG. 7 is a schematic diagram showing the architecture of a UE through a home base station (H(e)NB) access policy control in the related art. The HeNB usually accesses the core network of the EPS through a leased fixed line (also called Broadband Access (BBF)). The QoS (Quality of Service) of the fixed line connected to the H(e)NB is usually restricted by the contract between the owner of the H(e)NB and the fixed network operator. Therefore, when the 3GPP UE accesses the 3GPP core network access service through the H(e)NB, the required QoS cannot exceed the contracted QoS of the fixed network line that the fixed network operator can provide. Otherwise, the QoS of the UE access service will not be guaranteed, especially the Guaranteed Bitrate (GBR). Therefore, for the 3GPP network, the total QoS requirement for the service access of all UEs accessed through the H(e)NB must not exceed the QoS guarantee of the fixed line subscription of the H(e)NB access. However, when IP flow migration is applied to the technology (for example, when IP flows are migrated from non-3GPP to H(e)NB access, the PCRF needs to reserve the IP flow in the HBF eNodeB-connected BBF access network. The following problems are not solved: After the PCEF receives the IP flow migration request from the UE (for example, when migrating the IP flow from the non-3GPP to the H(e)NB), the PCEF provides the IPF routing rule information to the PCRF, and the PCRF according to the route The rule request requests resource admission control from the BBF access network. If the BBF access network refuses at this time, how should the PCRF be handled, and no corresponding solution is given in the prior art.

Summary of the invention

The technical problem to be solved by the embodiments of the present invention is to provide a policy control method and system for IP flow migration, and provide a policy control processing mechanism in a specific scenario when the IP flow of the AF service is migrated.

To solve the above technical problem, an embodiment of the present invention provides a policy control method for IP flow migration, where the method includes:

When the PCRF entity receives the IP flow migration routing rule information sent by the PCEF entity, if it is determined that part of the service data flow of the service provided by the AF entity needs to be migrated, and the AF entity does not support the IP flow migration; IP flow migration routing rule information is connected to the BBF The network access request resource admission control, when the BBF access network rejects the request,

An indication of interest.

The above method can also have the following characteristics:

The method further includes: the AF entity indicating to the PCRF entity whether the AF has the capability of supporting IP flow migration.

The above method can also have the following characteristics:

The step of the AF entity indicating to the PCRF entity whether the AF has the capability of supporting IP flow migration includes:

When the AF entity indicates the supported function list to the PCRF entity, the indication bit that supports the IP flow migration is included in the list, and the AF entity has the capability of supporting IP flow migration, and is not included in the list. The indicator bit that supports the IP flow migration indicates that the AF entity does not have the capability of supporting IP flow migration.

The above method can also have the following characteristics:

The method further includes: the gateway where the PCEF entity is located, after receiving the PCRF entity, rejecting the

After the IP flow migrates the indication of the routing rule information, an indication of rejecting the IP flow migration routing rule information is returned to the UE.

The above method can also have the following characteristics:

The method further includes: sending, by the gateway where the PCEF entity is located, the IP flow migration routing rule information to the PCRF entity by using a session modification request message when receiving the IP flow migration routing rule information provided by the user equipment (UE);

After receiving the session modification request message, the PCRF entity returns a session modification confirmation message to the PCEF, and includes an indication of accepting or rejecting the IP flow migration routing rule information in the session modification confirmation message;

After receiving the session modification confirmation message returned by the PCRF entity, the gateway where the PCEF entity is located returns an indication of accepting or rejecting the IP flow migration routing rule information to the UE. The above method can also have the following characteristics:

The indication that the gateway that the PCEF entity is located to return to the UE and rejects the IP flow migration routing information is: does not carry a binding confirmation message of HoA, CoA, BID, and FID.

The above method can also have the following characteristics:

The IP flow migration routing rule information includes installing and/or modifying an IP flow migration routing rule. A policy control system for IP flow migration, the system includes an IP flow migration policy control unit in a PCRF entity, where the IP flow migration policy control unit is configured to: when receiving the IP flow migration routing rule information sent by the PCEF entity,

If it is determined that part of the service data flow of the service provided by the AF entity needs to be migrated, and the AF entity does not support IP flow migration; or if the resource admission control is requested from the BBF access network according to the IP flow migration routing rule information, When the BBF access network rejects the request,

Returning an indication to the PCEF entity that the IP flow migration routing rule information is rejected.

The above system can also have the following characteristics:

The IP flow migration policy control unit is further configured to: determine, according to the indication of the received AF entity, whether the AF entity has the capability of supporting IP flow migration.

The above system can also have the following characteristics:

The IP flow migration policy control unit is configured to: determine whether the AF entity indicates that the supported function list includes an indication bit that supports IP flow migration, and if yes, determine that the AF has the capability of supporting IP flow migration, and if not, It is determined that the AF entity has the capability of supporting IP flow migration.

The above system can also have the following characteristics:

The system further includes an IP flow migration indication unit in the PCEF entity,

The IP stream migration indication unit is configured to: when receiving the IP flow migration routing rule information provided by the user equipment (UE), send the IP flow migration routing rule information to the PCRF entity by using a session modification request message; After receiving the session modification confirmation message returned by the PCRF entity, returning an indication to the UE to accept or reject the IP flow migration routing rule information; the IP flow migration policy control unit is configured to: receive the After the session modification request message, returning a session modification confirmation message to the PCEF entity, and packaging the session modification confirmation message Contains an indication to accept or reject the IP flow migration routing rule information.

The above system can also have the following characteristics:

The indication that the IP flow migration indication unit returns the IP flow migration routing rule information returned to the UE is: does not carry a binding acknowledgement message of HoA, CoA, BID, and FID.

The foregoing method and system have at least the following beneficial effects: 1) Resolving the actual transmission of some IP flows caused when the AF does not support IP flow migration and the UE performs the migration operation of the IP flows related to the AF providing services. The IP-CAN type (or further RAT type) is inconsistent with the PCRF reporting the IP-CAN type (or further RAT type) to the AF; 2) When the PCRF migrates the routing rule information according to the IPEF provided by the PCEF, requests the resource from the BBF access network. Upon admission, if the BBF access network rejects the request, it returns a rejection indication to the PCEF; 3) after receiving the binding update message, the P-GW/HA does not immediately return an acknowledgement message to the HAUE, and the PGW/HA may according to the feedback of the PCRF. Decide whether to accept the flow migration of the UE. BRIEF abstract

1 is a schematic diagram of a system architecture of an EPS in the related art;

2 is a schematic diagram of a multi-access scenario of a user equipment in the related art;

3 is a flowchart 1 of establishing an IP flow migration connection in a non-roaming scenario according to the related art; FIG. 4 is a flowchart 2 of establishing an IP flow migration connection in a non-roaming scenario according to the related art; Flowchart 3 of implementing IP flow migration in a roaming scenario; FIG. 6 is a schematic structural diagram of a policy control system for implementing BBF WLAN access in the related art;

7 is a schematic structural diagram of a policy control system for implementing H(e)NB access in the related art; FIG. 8 is a flowchart of a first embodiment of the present invention;

9 is a flow chart according to a second embodiment of the present invention;

Figure 10 is a flow chart according to a third embodiment of the present invention;

FIG. 11 is a schematic structural diagram of a policy control system for IP flow migration according to an embodiment of the present invention. Preferred embodiment of the invention

At present, the related technologies mainly have the following problems:

(1) When the AF entity does not support IP flow migration, and the UE performs the migration operation of the IP flow related to the service provided by the AF entity, the IP-CAN type (or RAT type) actually transmitted by some IP flows is caused. Reporting to the AF entity that the IP-CAN type (or RAT type) is inconsistent with the PCRF;

(2) When the PCRF entity requests resource admission control from the BBF access network according to the IP flow migration routing rule information provided by the PCEF entity, what should be done if the BBF access network rejects the request.

In order to solve the above problem, in the embodiment of the present invention, when the PCRF entity receives the IP flow migration routing rule provided by the PCEF entity, if it is determined that part of the service data flow of the service provided by the AF entity needs to be migrated, the IP is rejected. The flow migration routing rule; or, when requesting the resource admission control from the BBF access network according to the IP flow migration routing rule information, if the BBF access network rejects, the PCRF entity returns a rejection of the IP flow migration routing rule to the PCEF entity. An indication of the information.

The AF entity may indicate to the PCRF entity whether it has the capability of supporting IP flow migration in the process of initially providing service information to the PCRF entity. Specifically, the AF entity may indicate whether it has the capability of supporting IP flow migration by: indicating a supported function list Feature List to the PCRF entity, and including an indication bit supporting IP flow migration in the list, indicating the AF entity IP flow migration is supported. If the indicator bit that supports IP flow migration is not included in the list, it indicates that the AF entity does not support IP flow migration.

In addition, the gateway (such as the P-GW) where the PCEF entity is located does not immediately return an acknowledgment message to the UE when receiving the IP stream migration routing rule information provided by the UE, and waits until the acknowledgment message of the PCRF entity is received, and then returns an acknowledgment to the UE. Message.

Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, in the case of no conflict, the features in the embodiments and the embodiments in the present application may be arbitrarily combined with each other.

Embodiment 1

In this embodiment, the UE first establishes a PDN connection through the 3GPP access network access, and then establishes the same PDN connection through the non-3GPP access, and simultaneously uses the flow of the two accesses to use the PDN connection. Dynamic PCC (Policy and Charging Control) is deployed in the network. When the non-3GPP access is trusted, the UE uses the DSMIPv6 protocol.

As shown in FIG. 8, the process of this embodiment mainly includes the following steps:

Step S801: The UE accesses the EPC through the 3GPP access network, where the S-GW and the P-GW establish a tunnel through the GTP or the PMIPv6 protocol, and the existing service is transmitted on the tunnel.

The UE accesses the service provided by the AF entity through the established IP-CAN session, and the service provided by the AF entity includes two Service Data Flows (SDFs), which are respectively represented as SDF1 and SDF2, and the AF entity requests the PCRF to report the service. The IP-CAN type (which may also include the RAT type) of the access network connection through which the service data stream is transmitted, and the IP-CAN type of the PCRF entity to the PCRF entity according to the request is 3GPP-EPS, and the RAT type is E-UTRAN.

In the process of initially providing the service information to the PCRF, the AF entity indicates to the PCRF entity the feature list Feature List that is supported by the AF entity. If the indicator bit that supports the IP flow migration is included in the list, the AF entity supports the IP flow. Migration, if the indicator bit that supports IP flow migration is not included, indicates that the AF entity does not support IP flow migration.

Step S802, the UE discovers the non-3GPP access network and decides to initiate multiple access.

If the non-3GPP access network is trusted, the UE performs access authentication and authorization in the trusted non-3GPP access network, and the UE performs layer 3 attachment and obtains the local IP address IP Address1 as the care-of address (Care of Address, referred to as CoA). If the non-3GPP access network is untrustworthy, the UE will establish an IPSec tunnel with the ePDG. During the tunnel establishment process, the ePDG allocates the IP address IP Address1 to the UE as a CoA.

Step S803: The bearer binding and event reporting function (BBERF) entity located in the trusted non-3GPP access network or the ePDG sends a gateway control session establishment message to the PCRF entity, establishes a request to establish a gateway control session, and carries the user identifier and the IP Address1.

Step S804, the PCRF entity returns an acknowledgement message to the BBERF entity.

Step S805: The UE finds a P-GW between the UE and the PDN that is selected during the 3GPP access by using the self-starting process of the MIPv6. The UE initiates the establishment of the security association by using the IKEv2. The EAP is used for authentication on the IKEv2. - GW interacts with AAA to complete EAP authentication.

And in the process, the P-GW returns the IP address IP Address2 allocated by the P-GW when the UE accesses the 3GPP, and the UE uses the IP address as the HoA when the DSMIPv6 is bound. At this time, P-GW is in charge It is the function of the home HA.

Step S806: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries (HoA, CoA, BID, FID). (HoA, CoA, BID, FID) is a correspondence.

The value of HoA in the binding update message is IP Address2, and the value of CoA is IP.

Address 1 indicates that the corresponding BID is a binding through non-3GPP access, and a certain data stream uniquely identified by the FID user is bound to a connection through non-3GPP access.

The value of the HoA in the binding update message is IP Address2, and the value of the CoA is IP Address2, indicating that the corresponding BID is a binding through the 3GPP access, and the service data flow identified by the FID is bound to the connection through the 3GPP access. on.

The UE provides IP flow migration routing rule information to the P-GW/HA, requesting to migrate a service data flow (SDF1) transmitted through the 3GPP access to the non-3GPP access network.

Step S807: Different from the prior art, after receiving the binding update message, the P-GW/HA does not immediately return an acknowledgment message to the UE, but determines whether to accept the IP stream migration of the UE according to the feedback of the PCRF entity.

The PCEF entity located at the P-GW sends an IP-CAN session modification request indication to the PCRF entity, and the PCEF will send an event trigger routing rule modification (ROUTING RULE CHANGE) and IP flow migration routing rule information to the PCRF (for the migration IP in the process) In the case of the flow, the IP flow migration routing rule information is to install and/or modify the IP flow migration routing rule, and the IP flow migration routing rule is the correspondence between the service data flow and the access, and is identified by the correspondence between the Routing Filters and the Routing Address. When the value of Address is IP Address 1, it indicates that it is through non-3GPP access, and when the value of Routing Address is IP Address2, it is indicated as access through 3GPP. This message includes the default IP flow migration routing rules, ie Routing Filters are wildcards.

The UE migrates the service data stream SDF1 from the 3GPP access to the non-3GPP access, and the PCEF entity provides the IPF migration routing rule corresponding to the SDF1 to the PCRF to notify the PCRF entity of the migration of the route of the service data flow. In the routing rule, Routing Filters is the IP quintuple of the service data flow, and the Routing Address takes the value of IP Address 1. Step S808: The PCRF entity determines, according to the IP flow migration routing rule, that the UE requests to move one SDF of the two SDFs of the service provided by the AF entity to the non-3GPP access. In this way, the two SDFs that the AF entity provides for the service will be transmitted on different access networks. The PCRF entity further determines, according to the capability of the AF entity, that the AF entity does not support IP flow migration, and therefore the PCRF entity decides to reject the flow migration of the UE. The PCRF entity returns an acknowledgment message to the PCEF entity, and carries an indication that the UE is to perform SML1 flow migration (ie, an indication of refusing the IP flow migrating routing rule information sent by the PCEF entity to the PCRF entity).

Step S809: The P-GW/HA returns a binding acknowledgement message to the UE, and rejects the flow migration request of the UE. The specific implementation is that the message does not carry the HoA, CoA, BID, and FID to notify the UE that the multiple registration and flow binding fails.

Similarly, when the IP stream migration is applied to the BBAI, the PCRF entity receives the IP flow migration rule reported by the PCEF entity to migrate the SDF1 from the 3GPP to the non-3GPP or adds a service data flow to the non-3GPP access network (for the BBAI). When the non-3GPP is a BBF WLAN, the PCRF entity sends a message to the BPCF entity requesting admission control of the BBF access network. If the BBF access network returns a rejection, the PCRF entity will reject the UE's flow migration or new service data flow. The PCRF entity returns an acknowledgment message to the PCEF entity, carrying an indication of rejecting the UE to perform SMF1 flow migration or adding a service data flow (ie, rejecting the indication of the IP flow migration routing rule information sent by the PCEF entity to the PCRF entity). The P-GW/HA returns a binding acknowledgement message to the UE, and the message does not carry the HoA, CoA, BID, and FID to notify the UE that the multiple registration and flow binding fails.

Embodiment 2

In this embodiment, the UE first establishes a PDN connection through a non-3GPP access network, and then establishes the same PDN connection through 3GPP access, and simultaneously uses two accesses to use the PDN connection process. Dynamic PCC is deployed in the network. When the trusted non-3GPP access is used in the figure, the UE uses the DSMIPv6 protocol.

As shown in FIG. 9, the process of this embodiment mainly includes the following steps:

Step S901: The UE accesses the EPC through the DSMIPv6 protocol through the non-3GPP access network, and the DSMIPv6 tunnel is established between the UE and the P-GW/HA, and the existing service is transmitted on the tunnel. The address assigned by the non-3GPP access network to the UE is IP Address 1 as the CoA, and the IP address assigned by the P-GW to the UE is IP Address 2 as the HoA. The UE accesses the service provided by the AF entity through the established IP-CAN session, and the service provided by the AF entity includes two Service Data Flows (SDFs), which are respectively represented as SDF1 and SDF2, and the AF requests the PCRF entity to report the service. The IP-CAN type of the access network connection (which may further include the RAT type) through which the service data stream is transmitted, and the IP-CAN type reported by the PCRF entity to the PCRF entity according to the request is 3GPP EPS, and the RAT type is E-UTRAN. In the process of initially providing the service information to the PCRF entity, the AF entity indicates to the PCRF entity the feature list Feature List that it supports, and the indication bit that does not include the IP flow migration support indicates that the AF entity does not support the IP flow. migrate.

Step S902, the UE discovers the 3GPP access network and decides to initiate multiple access. The UE establishes a PDN connection to the same PDN through the 3GPP attach procedure. During the establishment process, the P-GW allocates an IP address to the UE as an IP Address2 to ensure that the same PDN connection is established through different accesses.

Step S903: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries (HoA, CoA, BID, FID).

(HoA, CoA, BID, FID) is a correspondence. The message is IP Address 2 and the CoA value is IP Address 1 , indicating that the corresponding BID is a binding through non-3GPP access, and a certain data flow of the user ID access service uniquely identified by the FID is bound to the non-3GPP. On the connection. The message is IP Address2 and the CoA value is IP Address2, indicating that the corresponding BID is a binding through the 3GPP access, and the service data flow identified by the FID is bound to the connection through the 3GPP access. The UE provides IP flow migration routing rule information to the P-GW/HA, and requests to migrate the service data flow SDF1 transmitted through the non-3GPP access to the 3GPP access network.

Step S904: After receiving the binding update message, the P-GW/HA does not immediately return an acknowledgement message to the UE. The PCEF located at the P-GW sends an IP-CAN session modification request indication to the PCRF, and the PCEF entity will send an event trigger ROUTING_RULE_CHANGE and IP flow migration routing rule information to the PCRF entity (for the case of the migrated IP flow in the flow) The IP flow migration routing rule information is to install and/or modify the IP flow migration routing rule, and the IP flow migration routing rule is the correspondence between the service data flow and the access, and the correspondence between the Routing Filters and the Routing Address is identified, and the value of the Routing Address is IP Address 1, expressed as non-3GPP access, Routing Address When the value is IP Address2, it is indicated as being accessed through 3GPP.

The UE migrates the SDF1 from the non-3GPP access to the 3GPP access, and the PCEF entity provides the IPF migration routing rule corresponding to the service data flow to the PCRF entity to notify the PCRF entity of the migration of the route of the service data flow. In the IP flow migration routing rule, Routing Filters is the IP quintuple of the service data flow, and the Routing Address value is IP Address2.

Step S905: The PCRF entity determines, according to the IP flow migration routing rule, that the UE requests to move one SDF of the two SDFs of the service provided by the AF to the 3GPP access. In this way, the two SDFs that the AF entity provides for the service will be transmitted on different access networks. The PCRF entity further determines that the AF entity does not support IP flow migration according to the capability of the AF entity. Therefore, the PCRF entity decides to reject the flow migration of the UE. The PCRF entity returns an acknowledgment message to the PCEF entity, carrying an indication that the UE is to perform SDF1 flow migration (ie, an indication of refusing the IPEF migration routing rule information sent by the PCEF entity to the PCRF entity).

Step S906: The P-GW/HA returns a binding acknowledgement message to the UE, and rejects the flow migration request of the UE, which is implemented by not carrying the HoA, CoA, BID, and FID in the message to notify the UE that the multiple registration and flow binding fails.

Similarly, when the IP stream migration is applied to the BBAI, when the PCRF entity receives the IP flow migration rule reported by the PCEF entity, the SDF1 is migrated from the non-3GPP to the 3GPP or a service data flow is added to the 3GPP access network (for the BBAI, When 3GPP is H(e)NB access), the PCRF entity sends a message to the BPCF entity requesting admission control of the BBF access network. If the BBF access network returns a refusal, the PCRF entity will reject the UE's stream migration or add a new service data stream. The PCRF entity returns an acknowledgment message to the PCEF entity, carrying an indication that the UE is to perform SMF1 flow migration or to add a service data flow (ie, an indication of refusing the IP flow migration routing rule information sent by the PCEF entity to the PCRF entity). The P-GW/HA returns a binding acknowledgement message to the UE, and the message does not carry the HoA, CoA, BID, and FID to notify the UE that the multiple registration and flow binding fails.

Embodiment 3

In this embodiment, a flow chart of data flow migration between two access networks after the UE implements multiple registration flow binding, where the service data flow migrated by the UE involves two SDFs of services provided by the AF entity. One of (represented as SDF1 and SDF2, respectively). Dynamic PCC is deployed in the network.

As shown in FIG. 10, the process of this embodiment mainly includes the following steps:

Step S1001: The UE simultaneously connects to the 3GPP access and the non-3GPP access, and performs multi-registration flow binding. And the two SDFs (represented by SDF1 and SDF2, respectively) of the service provided by the UE to the AF entity are transmitted through the non-3GPP access network.

Step S1002: The UE sends a DSMIPv6 binding update message to the P-GW/HA, where the binding update message carries (HoA, BID, FID). In the message, the UE provides IP flow migration routing rule information to the P-GW/HA, and may request to migrate the service data flow SDF1 (represented by FID) transmitted through the non-3GPP access to the 3GPP access network (using the BID) Express).

Step S1003: After receiving the binding update message, the P-GW/HA does not immediately return an acknowledgement message to the HA. The PCEF entity located at the P-GW sends an IP-CAN session modification request indication to the PCRF entity, and the PCEF entity sends an event trigger ROUTING_RULE_CHANGE and IP flow migration routing rule information to the PCRF entity, including modifying the IP flow migration corresponding to the SDF1. Routing rules. In the routing rule, IP Address1 is used to indicate that the currently transmitted access network is non-3GPP, and IP Address2 indicates that the currently transmitted access network is 3GPP. Use Routing Filters to represent the business data stream SDF1.

Step S1004: The PCRF entity migrates the routing rule according to the IP flow, and determines that the UE requests to move one SDF of the two SDFs of the service provided by the AF entity to the 3GPP access. In this way, the two SDFs that the AF entity provides for the service will be transmitted on different access networks. The PCRF further determines that the AF entity does not support IP flow migration according to the capability of the AF entity. Therefore, the PCRF entity decides to reject the flow migration of the UE. The PCRF entity returns an acknowledgment message to the PCEF entity, carrying an indication that the UE is to perform SDF1 flow migration (ie, an indication of refusing the IPEF migration routing rule information sent by the PCEF entity to the PCRF entity).

Step S1005: The P-GW/HA returns a binding acknowledgement message to the UE, and rejects the flow migration request of the UE. The specific implementation is that the message does not carry the HoA, CoA, BID, and FID to notify the UE of multiple registration, that is, the flow binding fails.

Similarly, when IP flow migration is applied to BBAI, the PCRF receives the IP flow migration rule reported by the PCEF to migrate SDF1 from non-3GPP to 3GPP (for BBAI, 3GPP is H(e)NB When accessing, the PCRF entity sends a message to the BPCF entity requesting admission control of the BBF access network. If the BBF access network returns a rejection, the PCRF entity will reject the flow migration of the UE or add a new service data flow to the 3GPP access network. The PCRF entity returns an acknowledgment message to the PCEF entity, and carries an indication that the UE rejects the SDF1 to perform the flow migration or adds a service data flow (that is, the indication of refusing the IP flow migration routing rule information sent by the PCEF entity to the PCRF entity). The P-GW/HA returns a binding acknowledgement message to the UE, and the message does not carry the HoA, CoA, BID, and FID to notify the UE that the multiple registration and flow binding fails.

In addition, the embodiment of the present invention further provides a policy control system for IP flow migration. As shown in FIG. 11, the system mainly includes an IP flow migration policy control unit 1101 in a PCRF entity, where: the IP flow migration policy control The unit 1101 is configured to: when receiving the IP flow migration routing rule information sent by the PCEF entity, if it is determined that part of the service data flow of the service provided by the AF entity needs to be migrated, and the AF entity does not support the IP flow migration; The IP flow migration routing rule information requests resource admission control to the BBF access network, and when the BBF access network rejects the request, returns an indication to the PCEF entity to reject the IP flow migration routing rule information.

Optionally, the IP flow migration policy control unit 1101 is further configured to: determine, according to the indication of the received AF entity, whether the AF entity has the capability of supporting IP flow migration.

Optionally, the IP stream migration policy control unit 1101 is configured to determine whether the AF entity has support according to whether the function list (Feature List) supported by the AF entity indicates that an indicator bit supporting IP flow migration is included. IP flow migration capability.

Optionally, the system further includes an IP flow migration indication unit 1102 in the PCEF entity, where the IP flow migration indication unit 1102 is configured to: when receiving the IP flow migration routing rule information provided by the UE, through the session modification request message. Sending the IP flow migration routing rule information to the PCRF entity; and after receiving the session modification confirmation message returned by the PCRF entity, returning an indication to the UE to accept or reject the IP flow migration routing rule information ;

The IP stream migration policy control unit 1101 is configured to: after receiving the session modification request message, return a session modification confirmation message to the PCEF, and include accepting or rejecting the IP flow in the session modification confirmation message. An indication to migrate routing rule information. Optionally, the indication that the IP flow migration indication unit 1102 returns the IP flow migration routing rule information that is returned to the UE is: does not carry a binding confirmation message of the HoA, CoA, BID, and FID.

The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention, and the present invention is also to be construed as being limited by the scope of the appended claims.

Obviously, those skilled in the art should understand that the above modules or steps of the embodiments of the present invention can be implemented by a general computing device, which can be concentrated on a single computing device or distributed in multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from The steps shown or described are performed sequentially, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software.

Industrial Applicability The embodiments of the present invention have at least the following beneficial effects: 1) Resolving some IPs caused when the AF does not support IP flow migration and the UE performs the migration operation of the IP flow related to the AF providing service. The IP-CAN type (or further RAT type) actually transmitted by the stream is inconsistent with the PCRF reporting the IP-CAN type (or further RAT type) to the AF; 2) When the PCRF migrates the routing rule information according to the IP flow provided by the PCEF to the BBF When the network access request resource is accepted, if the BBF access network rejects the request, it returns a rejection indication to the PCEF; 3) after receiving the binding update message, the P-GW/HA does not immediately return an acknowledgement message to the HAUE, and the PGW/HA may be based on The feedback of the PCRF determines whether to accept the flow migration of the UE.

Claims

Claim

1. A network protocol (IP) flow migration policy control method, comprising:

When the Policy and Charging Rules Function (PCRF) entity receives the IP flow migration routing rule information sent by the Policy and Charging Enforcement Function (PCEF) entity,

If it is determined that part of the service data flow of the service provided by the application function (AF) entity needs to be migrated, and the AF entity does not support IP flow migration; or if the routing rule information is migrated according to the IP flow to the broadband forum (BBF) The access network requests resource admission control, and the BBF access network rejects the indication of the request.

2. The method of claim 1 further comprising:

The AF entity indicates to the PCRF entity whether the AF has the capability of supporting IP flow migration.

3. The method of claim 2, wherein

4. The method of claim 1 further comprising:

After receiving the indication that the PCRF entity rejects the IP flow migration routing rule information, the gateway where the PCEF entity is located returns an indication of rejecting the IP flow migration routing rule information to the UE.

5. The method of claim 4, further comprising:

The gateway where the PCEF entity is located, when receiving the IP flow migration routing rule information provided by the user equipment (UE), sends the IP flow migration routing rule information to the PCRF entity by using a session modification request message; After receiving the session modification request message, the PCRF entity returns a session modification confirmation message to the PCEF, and includes an indication of accepting or rejecting the IP flow migration routing rule information in the session modification confirmation message;

After receiving the session modification confirmation message returned by the PCRF entity, the gateway where the PCEF entity is located returns an indication to the UE to accept or reject the IP flow migration routing rule information.

6. The method according to claim 4 or 5, wherein

The indication that the gateway where the PCEF entity is located returns the IP flow migration routing rule information to the UE is: does not carry a home address (ΗοΑ), a care-of address (CoA), a binding identifier (BID), and a flow A binding confirmation message for the identity (FID).

7. The method of claim 1, 2 or 3, wherein:

The IP flow migration routing rule information includes installing and/or modifying an IP flow migration routing rule.

8. A network protocol flow (IP) flow migration policy control system, the system comprising an IP flow migration policy control unit in a Policy and Charging Rules Function (PCRF) entity, the IP flow migration policy control unit being configured to :

When receiving the IP flow migration routing rule information sent by the Policy and Charging Enforcement Function (PCEF) entity,

If it is determined that part of the service data flow of the service provided by the application function (AF) entity needs to be migrated, and the AF entity does not support IP flow migration; or if the routing rule information is migrated according to the IP flow to the broadband forum (BBF) The access network requests resource admission control, and when the BBF access network rejects the request,

9. The system of claim 8 wherein

10. The system of claim 9, wherein

The IP flow migration policy control unit is configured to: determine that the AF entity indicates supported work The indicator can include an indicator bit for supporting IP stream migration. If yes, it is determined that the AF has the capability of supporting IP stream migration. If not, it is determined that the AF entity has the capability of supporting IP stream migration.

11. The system of claim 8, the system further comprising an IP flow migration indication unit in the PCEF entity, the IP flow migration indication unit configured to: receive the IP flow migration route provided by the user equipment (UE) And sending, by the session modification request message, the IP flow migration routing rule information to the PCRF entity; and receiving the session modification confirmation message returned by the PCRF entity, and then returning the acceptance or rejection to the UE after receiving the session modification request message; The IP flow migration routing rule control unit is configured to: after receiving the session modification request message, return a session modification confirmation message to the PCEF entity, and confirm the session modification The message includes an indication to accept or reject the IP flow migration routing rule information.

12. The system of claim 11 wherein:

The indication that the IP flow migration indication unit returns the IP flow migration routing rule information returned to the UE is: does not carry a home address (ΗοΑ), a care-of address (CoA), a binding identifier (BID), and a flow A binding confirmation message for the identity (FID).