WO2014040254A1

WO2014040254A1 - Policy coordination between policy enforcement points

Info

Publication number: WO2014040254A1
Application number: PCT/CN2012/081332
Authority: WO
Inventors: Martin SCHWARZE; Mu-jin LIU; Zhi-jie DAI; Bo Wang
Original assignee: Hewlett-Packard Development Company, L. P.
Priority date: 2012-09-13
Filing date: 2012-09-13
Publication date: 2014-03-20

Abstract

A UPM system may include a session manager module to establish interface sessions with a policy enforcement point (PEP) and a policy decision point (PDP). A notification manager module forward event information received from the PEP to the PDP and receive a policy decision from the PDP. A policy engine may determine, based on the event information, whether to forward the policy decision to the PEP, to ignore the policy decision or to modify the policy decision.

Description

POLICY COORDINATION BETWEEN POLICY ENFORCEMENT POINTS

BACKGROUND

[0001] Data traffic growth is very rapid in networks, especially in mobile networks, such as 3G, Long Term Evolution (LTE), and emerging mobile networks. Service providers often seek updated solutions that are capable of enforcing policies to manage consumption of network resources, and attempt to combine existing and updated solutions in their networks.

BRIEF DESCRI PTION OF DRAWINGS

[0002] The embodiments are described in detail in the following description with reference to examples shown in the following figures.

[0003] Figure 1 illustrates a unified policy management (UPM) system.

[0004] Figure 2 illustrates a U PM system in a general packet radio system network.

[0005] Figures 3-9 illustrate methods.

[0006] Figure 10 illustrates a computer system that may be used for the method and systems.

DETAILED DESCRIPTION OF EMBODIMENTS

[0007] For simplicity and illustrative purposes, the principles of the

embodiments are described by referring mainly to examples thereof. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It is apparent that the embodiments may be practiced without limitation to all the specific details. Also, the

embodiments may be used together in various combinations.

[0008] According to an embodiment, a UPM system manages information and messages directed to a policy decision point (PDP) from network elements, which may include policy enforcement points (PEPs). For example, the U PM system receives messages and information from a PEP and sends it to the PDP. The PDP may make a policy decision based on the information. The policy decision may be for a policy enforced or to be enforced by the PEP. The UPM system receives the policy decision and decides whether to forward the policy decision to the PEP, to modify the policy decision or to ignore the policy decision.

[0009] The PDP is a functional element that makes policy control decisions and may be considered a policy decision point for network elements. The policy decisions may be for policies related to the management of consumption of network resources, such as quality of service (QoS), service level policies for applications, etc. The PEP is an enforcement point for enforcing the policies.

[0010] In one example, the PDP may be a legacy PDP which may reside on a server external to the UPM system. The legacy PDP may have limited policy decision capabilities. For example, the legacy PDP may be a first generation PDP that focuses on metric level policies but does not take into account application level policies or subscriber level policies, such as policies for implementing subscriber tier-based quality of service (QoS) policies. The UPM system includes an extended PDP to provide extended policy decisions and to operate with the legacy PDP to provide the desired policy decision making. [0011] In one example, the UPM system, the PEP and the PDP are employed in a 3rd Generation Partnership Project (3GPP) network to enforce subscriber level or service level policies. The UPM system may be used in a General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS) or a Long Term Evolution (LTE) network. The PEP may be a policy and charging enforcement function (PCEF) and the PDP may be a policy and charging rules function (PCRF). Examples of the policies may include enforcing different QoS limitations for different subscribers (e.g., bearer level QoS). For example, bearer level QoS policies define the policies for all of the packets passing through the bearer. Other policies may be service level policies

associated with layers 1 -3 of the Open Systems Interconnection (OSI) model or associated with layers 4-7 with the help of deep packet inspection. These policies may include peer-to-peer (P2P) service policies. In the 3GPP network, the PEP may be a policy and PCEF is a functional element that encompasses policy enforcement and charging functionalities. The PCEF may reside at a gateway node and manage traffic at the gateway node and QoS. The PCRF encompasses policy control decision and flow based charging control functionalities. The PCRF makes policy decisions for policies enforced by the PCEF. For example, the PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging towards the PCEF, and provisions policies to the PCEF.

[0012] Figure 1 illustrates a U PM system 100. The UPM system 100 includes an extended PDP 101 that interacts with PDP 102 and PEP 130. In one example, the PDP 102 is a legacy PDP, which may have been installed prior to the extended PDP 102. The extended PDP 101 may include a session manager module 1 10, a notification manager module 1 1 1 and a policy engine 1 12. The UPM system 100 may include a data storage 120. The data storage 120 may include a database or another type of data storage system that stores any information used by the UPM system 100. Examples of some of the information stored in the data storage 120 may include policies, rules, and session information. The UPM system 1 00 may comprise hardware, machine readable instructions or a combination of hardware and machine readable instructions. The machine readable instructions may be stored on a storage device and executed by one or more processors. [0013] Network traffic 140 for one or more networks may be received by the PEP 130. The PEP 130 may enforce different polices for the network traffic 140, such as subscriber-based QoS polices, charging policies, etc. The session manager 1 10 establishes interface sessions 1 31 and 132 with the PEP 1 30 and the PDP 102, respectively. Session information is stored in the data storage 120 for each interface session 131 and 132. The session information may include one or more of a session identifier, subscriber identifier, etc. The i nterface sessions 131 and 1 32 may be for the same subscriber and carry policy-related information for traffic for the same subscriber. The interface sessions 131 and 1 32 may use a protocol to communicate between the extended PDP 101 and the PEP 1 30 and the PDP 102. In one example, the protocol used by the interface sessions is the diameter protocol. The interface sessions 131 and 1 32 may be Gx sessions for Gx reference points in a 3GPP core network as described in further detail below. The interface sessions 131 and 1 32 may carry signaling data for policy and charging rules for a particular subscriber. [0014] The session manager module 1 10 also manages the interface sessions 131 and 132. For example, when establishing the interface session 131 , the session manager module 1 10 also establishes the interface session 132.

Furthermore, if the interface session 1 31 times out or is otherwise terminated, the session manager module 1 10 terminates the interface session 132. [0015] The notification manager module 1 1 1 sends and receives messages for the extended PDP 101 . The messages may be from or to the PEP 130 or the PDP 102, and may be sent via the interface sessions 131 and 132. The

notification manager module 1 1 1 may receive event notifications including event information about events detected at the PEP 1 30. The events may be associated with policies enforced by the PEP 1 30 and conditions for triggering enforcement of different policies. For example, an event may be a change in location of a subscriber, or a change in QoS tier for a subscriber. Many more types of events may be subscribed to by the notification manager module 1 1 1 . When, these events are detected, a policy change may be facilitated by the extended PDP 101 and the PDP 102. For example, the extended PDP 101 receives an event notification from the PEP 130 via interface session 132. The notification manager module 1 1 1 sends the event information to the PDP 102 via the interface session 132. The PDP 102 makes a policy decision based on the event information. For example, the PDP 102 decided to reduce the QoS for the subscriber. The policy decision is sent to the extended PDP 1 02 via the interface session 1 32. The policy engine 1 1 2 decides whether to ignore, modify or forward the policy decision based on the rules stored in the data storage 1 20 and/or subscriber profile information retrieved from the subscriber profile repository (SPR) 121 . A modified policy decision or the same policy decision from the PDP 102 may be sent to the PEP 130 for enforcement via the interface session 131 . The extended PDP 1 01 mayy operate as an intermediary between the PEP 130 and the PDP 102 and make addition policy decisions that are not supported by the PDP 102.

[0016] Figure 2 shows an example of the UPM system 100 used in a General Packet Radio Service (GPRS) network. For example, PEP 130 may be PCEF 130a and resides in a gateway service node. The gateway service node may be a routing point between mobile network 220, such as a Global System for Mobile (GSM) network (e.g., 2G, 3G, 4G), and the Internet 221 or some other Internet Protocol (IP) network. In the example shown in figure 2 the gateway service node is GPRS support node (GGSN) 230. Also, PDP 101 and PDP 1 02 may be a PCRF 101 a and a PCRF 102a as shown in figure 3. PCEF 130 in the GGSN 230 may enforce subscriber-based QoS policies or other types of policies. For example, user equipment (UE) 240 is for a particular subscriber and maximum uplink and downlink bandwidths are enforced for the UE 240. Also, Gx sessions 232 and 233 may be established by the session manager module 1 10 for communicating between the extended PCRF 101 and the PCEF 130 and the PCRF 102. In this example, the interface sessions 131 and 132 are the Gx sessions 232 and 233 for Gx reference points. The Gx sessions 232 and 233 carry policy control and charging control signaling data. For example, the Gx sessions 232 and 233 carry signaling data for provisioning and removal of Policy and Charging Control (PCC) rules from the extended PCRF 101 to the PCEF 1 3- and the transmission of traffic plane events from the PCEF 130 to the extended PCRF 101 . The Gx sessions 232 and 233 can be used for charging control, policy control or both by applying Attribute Value Pairs (AVPs) relevant to an application.

[0017] Serving GPRS support node (SGSN) 250 delivers data packets from and to mobile stations within its geographical service area. Its tasks include packet routing and transfer, mobility management (attach/detach and location

management), logical link management, and authentication and charging functions. Instead of GGSN 230 and SGSN 250, the system shown in figure 2 may include a PGW for the GGSN 230 and a Serving Gateway (SGW) instead of the SGSN 250 for a 4G LTE network.

[0018] The policy engine 1 12 facilitates policy management between the extended PCRF 101 , the PCRF 102 and the PCEF 1 30. For example, the GGSN 230 may detect a radio access technology (RAT) change from 3G to 2G and sends a notification event message via Gx session 232 to the extended PCRF 1 01 . The notification manager module 1 1 1 sends the event information to the PCRF 102 and may receive a policy decision from the PCRF 102. The policy engine 1 1 2 may send the policy decision to the PCEF 130 or send a modified policy decision or not send any change in policy to the PCEF 130 depending on policy rules.

[0019] Figure 3 illustrates a method 300. The method 300 is described with respect to the UPM system 100 shown in figures 1 and 2 by way of example. At 301 , interface sessions are established between the PEP 130 and the extended PDP 101 , and between the extended PDP 1 01 and the PDP 102. For example, interface sessions 131 and 132 are established. Establishing the interface sessions may be facilitated by the session manager module 1 10. The interface sessions, for example, are for the same subscriber. The interface sessions 1 31 and 1 32 may include Gx sessions for 3GPP Gx reference points as shown in figure 2. As part of 301 , an initial policy rule may be provisioned to the PEP 130.

[0020] At 302, the extended PDP 1 01 receives event information from the PEP 130. The event information may include information about network traffic 140 received at the PEP 130. The event information may include events detected by the PEP 130, such as a location change of a subscriber, RAT change, or some other events associated with the network traffic 140 for a particular subscriber. The network traffic 140 may include a service data flow for the subscriber that is received at the PEP 130. The service data flow may include IP packets related to a user service, such as web browsing, email, etc. The PEP 130 may also determine information about the subscriber. [0021] At 303, the extended PDP 1 01 sends the event information to the PDP 102. For example, the notification manager module 1 1 1 sends the event information to the PDP 102.

[0022] At 304, the extended PDP 1 01 receives a policy decision from the PDP 102. The policy decision may be related to the subscriber, subscriber services, QoS, etc. The policy decision may be based on the event information. For example, if the event is a change in subscriber location, the policy decision may be to downgrade the subscriber QoS at the PEP 130. Another policy decision may be to do nothing based on the event. Policy decisions of the PDP 1 02 may be related to a PCC rule, QoS per QoS Class Identifier (QCI), QoS per I P- Connectivity Access Network (CAN) bearer, QoS per Access Point Name (APN), Event Trigger, Revalidation-Time, etc.

[0023] At 305, the extended PDP 1 01 determines whether to forward the policy decision from the PDP 102, modify the policy decision or ignore the policy decision. The determination, which may be performed by the policy engine 1 1 2, and may be based on rules stored in the data storage 120. The rules may specify conditions for implementing different polices and in some instances the policy decisions differ from the decisions that are made by the PDP 101 based on the same event. For example, the extended PDP 1 01 may implement subscriber tier- based QoS policies that are not done by the PDP 1 02.

[0024] If the policy decision of the PDP 102 is ignored at 305, a message is sent to the PDP 1 02 from the extended PDP 101 at 306. The message may acknowledge that the extended PDP 101 received the policy decision from the PDP 102 and may indicate that the policy decision was administered by the PEP 130 even though it was actually ignored. Thus, the PDP 102 continues to function as if its policy decision was enforced at the PEP 130.

[0025] If the policy decision of the PDP 102 is modified at 305, the modified policy decision is sent to the PEP 130 for execution at 307, and the

acknowledgement message is sent to the PDP 101 at 306. [0026] If the policy decision of the PDP 102 is to be implemented, the policy decision made by the PDP 102 is sent from PCEF 1 01 to the PEP 130 for execution at 308. The acknowledgement message is sent to the PDP 101 at 306.

[0027] Figures 4-9 show methods that are described by way of example with respect to figure 2. Figure 4 illustrates establishing Gx sessions 232 and 233. At 401 , the PCEF 1 30 sends a Credit Control Request (CCR-I because it's

"lnitial_Request") to the extended PCRF 101 to establish the Gx session 232. At 402, the extended PCRF 101 sends a subscriber profile request to the SPR 1 21 , whereby the subscriber may be the user of the UE 240. At 403, the SPR 121 sends a profile response back to the extended PCRF 101 that includes information for the subscriber, i.e., subscriber profile. At 404, the extended PCRF 101 sends a CCR-I to the PCRF 102. At 405, the PCRF 102 responds with a Credit Control Answer (CCA-I) which may indicate that the Gx reference point is acknowledged and the Gx session 233 is established between the extended PCRF 101 and the PCRF 102. At 406, the extended PCRF 101 sends a CCA-I to the PCEF 1 30 to establish the Gx session 232. Figure 4 shows that the Gx session 233 is first attempted to be established in response to the CCR-I from the PCEF 130. If the Gx session 233 is established, then the Gx session 232 is established. If for some reason, the Gx session 233 is unable to be established, the extended PCRF 101 may not establish the Gx session 232.

[0028] Figure 5 shows a client-initialized modification to a Gx session after the GX sessions 232 and 233 are established such as described in figure 4. At 501 , the PCEF 1 30 sends CCR update request (CCR-U) via Gx 232 to the extended PCRF 101 . The CCR-U may be sent, for example, if policies, such as policy control and charging (PCC) rules, need to be updated. At 502, the extended PCRF 101 sends a profile request to the SPR 1 21 for the subscriber, which may be the user of the UE 240. At 503, the SPR 121 sends a profile response back to the extended PCRF 101 that includes information for the subscriber. The profile information may be used to determine whether to update a policy. The extended PCRF 101 may determine the policy is to be updated. At 504, the extended PCRF 101 sends CCR-U via Gx 233 to the PCRF 102. At 505, the PCRF 1 02 sends a Credit Control Answer Update (CCA-U) to the extended PCRF 101 via GX session 233. The CCA-U may indicate the update was performed at the PCRF 102. At 506, the extended PCRF 101 sends CCA-U to the PCEF 1 30 via Gx session 232, for example, to indicate the update was performed.

[0029] Figure 6 shows an internally triggered Gx session modification by the extended PCRF 101 . The PCRF 1 02 is not involved. An internal trigger in the extended PCRF 101 may be caused by a variety of reasons. For example, the extended PCRF 101 may get subscriber profile information from the SPR 121 at 601 and 602. The profile information may indicate a change in the subscription, such as the subscriber has subscribed to a higher QoS. The extended PCRF 101 sends a Re-Auth-Request (RAR) to the PCEF 130 via Gx session 232 to change the QoS policy enforced by the PCEF at 603. At 604, PCEF 130 responds with a Re-Auth-Acceptance (RAA), which, for example, indicates that the policy change was implemented.

[0030] Figure 7 illustrates termination of Gx session. For example, if the subscriber drops a data session on the UE 240 or some other termination event occurs, the PCEF 130 sends terminate request (CCR-T) to the extended PCRF 101 via Gx session 232 at 701 . The extended PCRF 101 then terminates Gx session 233. For example, at 702, the extended PCRF 1 01 sends CCR-T to the PCRF 102 via Gx session 233 and the PCRF 102 responds with CCA-T at 703 to terminate Gx session 233. Once Gx 233 is terminated, the extended PCRF 101 terminates Gx session 232 by sending CCR-T to PCEF 130 at 704.

[0031] Figure 8 illustrates a re-authorization request from the PCRF 102.

For example, the PCRF 102 may detect a network level event. For example, the PCRF 102 gets congestion information from a monitoring system and decides to change policies in the network that are enforced by the PCEF 130 based on the congestion. At 801 , the PCRF 102 sends RAR to the extended PCRF 101 via Gx session 233. At 802-803, the extended PCRF 101 gets profile information for the subscriber to decide whether to change the policy at the PCEF 130. If the policy is to be changed, at 804-805, the extended PCRF 1 01 sends the RAR to the PCEF 130 and receives an answer (RAA) from the PCEF 1 30 via Gx session 232. At 806, the extended PCRF 101 sends RAA to the PCRF 1 02, for example, to indicate a policy update was performed at the PCEF 130.

[0032] Figure 9 illustrates a Gx session timeout. For example, a Gx session may timeout if the PCEF 130 has not received an update in a certain amount of time. Then, Gx session 233 may be terminated. For example, after a timeout, the extended PCRF 101 sends RAR to the PCEF 130 at 901 . If RAA is not received within a predefined time period, then at 902, the extended PCRF 102 sends CCR- T to the PCRF 102 to terminate Gx session 233. At 903, the PCRF 1 02 responds with CCA-T. [0033] Figure 10 shows a computer system 1 000 that may be used with the embodiments described herein. The computer system 1000 represents a generic platform that includes components that may be in a server or another computer system. The computer system 1000 may be used as a platform for the data storage system 100. The computer system 1000 may execute, by one or more processors or other hardware processing circuits, the methods, functions and other processes described herein. These methods, functions and other processes may be embodied as machine readable instructions stored on computer readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory).

[0034] The computer system 1000 includes a processor 1002 that may implement or execute machine readable instructions performing some or all of the methods, functions and other processes described herein. Commands and data from the processor 1002 are communicated over a communication bus 1 013. The computer system 1000 also includes a main memory 101 1 , such as a random access memory (RAM), where the machine readable instructions and data for the processor 1002 may reside during runtime, and a secondary data storage 1008, which may be non-volatile and stores machine readable instructions and data. For example, machine readable instructions for the U PM system 100 may reside in the memory 101 1 during runtime. The memory 101 1 and secondary data storage 1008 are examples of computer readable mediums.

[0035] The computer system 1000 may include an I/O device 1 010, such as a keyboard, a mouse, a display, etc. For example, the I/O device 1 010 includes a display to display drill down views and other information described herein. The computer system 1000 may include a network interface 1012 for connecting to a network. Other known electronic components may be added or substituted in the computer system 1000. [0036] While the embodiments have been described with reference to examples, various modifications to the described embodiments may be made without departing from the scope of the claimed embodiments.

Claims

What is claimed is:

1 . A unified policy management (UPM) system comprising: a session manager module to establish a first interface session with a policy enforcement point (PEP) and to establish a second interface session with a policy decision point (PDP) ; a notification manager module to receive, from the PEP via the first interface session, event information associated with network traffic received at the PEP, and to send the event information to the PDP via the second interface session; and a policy engine, executed by a processor, to receive a policy decision from the PDP and determine, based on the event information, whether to forward the policy decision to the PEP, to ignore the policy decision or to modify the policy decision, wherein an answer message is sent from the UPM system to the PDP via the second interface session to acknowledge the policy decision received from the PDP.

2. The UPM system of claim 1 , wherein if the policy engine determines the policy decision is to be forwarded to the PEP, the notification manager is to send the policy decision to the PEP, if the policy engine determines the policy decision is to be modified, the notification manager module is to send a modified policy decision to the PEP, and if the policy engine determines the policy decision is to be ignored, no message is sent to the PEP for modifying a policy enforced at the PEP.

3. The UPM system of claim 1 , wherein the answer message is sent from the UPM system to the PDP regardless of whether the policy engine determines to forward the policy decision, to ignore the policy decision or to modify the policy decision .

4. The UPM system of claim 1 , wherein the session manager module is to establish the second interface session prior to the first interface session.

5. The UPM system of claim 1 , wherein if the UPM system receives a policy update request from the PEP, the notification manager module it to first send the request to the PDP prior to sending an update answer message to the PEP.

6. The UPM system of claim 1 , wherein if the UPM system receives a terminate request message from the PEP for the first interface session, the UPM system is to terminate the second interface session.

7. The UPM system of claim 1 , wherein if the first interface session times out, the UPM system is to terminate the second interface session.

8. The UPM system of claim 1 , wherein the first and second interface sessions are Gx sessions.

9. The UPM system of claim 8, comprising an extended PDP providing policy decision capabilities not performed by the PDP.

10. A non-transitory computer readable medium including machine readable instructions executable by at least one processor to: establish a first interface session with a PEP and to establish a second interface session with a PDP; receive, from the PEP via the first interface session, event information associated with network traffic received at the PEP ; send the event information to the PDP via the second interface session; receive a policy decision from the PDP; and determine, based on the event information, whether to forward the policy decision to the PEP, to ignore the policy decision or to modify the policy decision.

1 1 . The non-transitory computer readable medium of claim 10, wherein the machine readable instructions are executable by the at least one processor to: forward the policy decision to the PEP if the policy decision is determined to be forwarded ; send a modified policy decision to the PEP if the policy decision is determined to be modified ; and not to send a message to the PEP to modifying a policy enforced at the PEP if the policy decision is determined to be ignored.

12. The non-transitory computer readable medium of claim 10, wherein the machine readable instructions are executable by the at least one processor to: send an answer message to the PDP via the second interface session regardless of whether the policy decision is determined to be forwarded to the PEP, to be ignored or to be modified.

13. The non-transitory computer readable medium of claim 1 0, wherein the second interface session is established prior to the first interface session.

14. The non-transitory computer readable medium of claim 1 0, wherein the machine readable instructions are executable by the at least one processor to: terminate the second interface session in response to receiving a termination request for the first interface session or in response to a time out of the first interface session.

15. A method comprising: establishing a first interface session between a U PM system and a PEP; establishing a second interface session between the UPM system and a PDP residing on a computer system external to the UPM system; receiving, from the PEP via the first interface session, event information associated with network traffic received at the PEP ; sending the event information to the legacy PDP via the second interface session; receiving a policy decision from the legacy PDP; and determining, based on the event information, whether to forward the policy decision to the PEP, to ignore the policy decision or to modify the policy decision.