Patent Application
20090228954
1. Field of the Invention
The present invention is directed generally to the control of data networks serving mobile wireless users. In particular, the present invention is directed to a system for policy management in a data network that uses policy rules to control service data flows at service gateways.
2. Description of the Related Art
Traditionally, service gateways perform specific functions where they are directly in the user plane traffic. For example, a Wireless Application Protocol (WAP) HTTP server processes WAP web traffic and translates between protocols. However, traditional service gateways have not been policy-enabled. Most of the management functions in the traditional gateways are scattered across the network and are done in localized and static fashion. Traditional service gateways do not have a policy function and are not able to communicate with the logically centralized policy management framework. Therefore, it can be appreciated that there is a significant need for a new type of policy management in edge gateways that will provide a dynamic policy framework. The present invention provides this, and other advantages as will be apparent from the following detailed description and accompanying figures.
As operators begin to deploy a policy management framework (PMF) to tackle network and service management challenges in the mobile data network, they find a need to build policy-enabled service gateways to leverage the PMF. Aside from their traditional functions (e.g., Wireless Application Protocol (WAP) web gateway, IM servers, location servers, etc.), service gateways can be policy-enabled so that the mobile operators can effectively control the behaviors of these gateways through polices. Architecturally, they become consumers and enforcers of policies.
The access gateway 102 has a policy enforcement engine 112 configured to control the service data flows 110 according to control policies. The policy enforcement engine 112 may be loaded with policy decision logic. A policy decision logic is a policy rule that is bound with identifying information for a specific service data flow 110 and identifying information of a specific subscriber (e.g., the subscriber operating the user equipment 108). The policy enforcement engine 112 is configured to examine each packet that flows through the access gateway 102, and look for information that matches service identifying information in one of the policy decisions. If a match is found, the policy enforcement engine 112 executes the associated policy rule. In some embodiments, the access Gateway 102 is a General Packer Radio Service (GPRS) implementation of a Gateway GPRS Support Node (GGSN) and the policy enforcement engine 112 is a policy control and charging enforcement function (PCEF) according to the 3GPP standards. The policy enforcement engine 112 operates within the access gateway 102 to control IP access to the public data network (e.g., communication network 101).
The policy server may serve as a centralized repository of policies used throughout the architecture 100 in an exemplary embodiment, the policy server may also provide policy in charging rules functionality. In one embodiment, the policy server 104 is a Policy and Charging Rules Function (PCRF) according to the 3GPP standards. The PCRF function includes policies relating to charges for particular subscribers and provided services.
The policy server 104 is logically linked to the access gateway 102 via a reference point 120. The reference point 120 serves as a signaling link. Between the access gateway 102 and the policy server 104. The policy server 104 is configured to receive, via reference point 120, information about service data flows 110 from the policy enforcement engine 112 and send policy information to the policy enforcement engine. In some embodiments, the policy information includes policy decisions. The policy server 104 may also provide charging data to the policy enforcement agency 112.
In an exemplary embodiment, the reference point 120 may conform with the 3GPP standard Rx and/or standard Gx reference points. As described above, the policy server 104 may provide operational policies to the policy enforcement engine 112 via the reference point 120 when implemented as, by way of example, the Gx reference point. In addition, the policy server 104 may provide charging policies to the policy enforcement engine 112 via, by way of example, a conventional Rx reference point. Alternatively, the reference point 120 may be implemented as enhanced Rx and/or Gx reference points. In yet another exemplary embodiment, the reference point 120 may conform with the DIAMETER protocol, but not comport with the 3GPP standard for the Gx reference point and/or Rx reference point. Thus, the architecture 100 is not limited by particular form of the communication protocol implemented by the reference 120.
A service gateway 106 can be a policy-enabled service gateway with an addition of a local policy engine 122. In the example of
The service gateways 106 each include one or more gateway functions 124. As will be described in greater detail below, the gateway functions 124 provide user services. In many instances, the services provided by the gateway functions 124 can be handled at the “edge” of the communication network 101. The architecture 100 advantageously shuttles service requests that can be handled at the edge of the communication network 101 to the gateway functions 124. This prevents service data flows 110 from continuing on within the communication network 101 and thus prevents unnecessary data flow within the communication network. Those skilled in the art will appreciate that this architecture 100 provides more efficient data throughput within the communication network 101.
Most service gateways 106 only include a single gateway function 116. For example, service gateway 106b includes a single gateway function 124c. This arrangement economically utilizes system resources. In the example of
Alternatively, a single service gateway may contain more than one gateway function. In the example of
The gateway functions 124a, 124b and 124c in the policy-enabled service gateways 106a and 106b are configured to perform traditional gateway functions, but in a manner controlled by policies in the local policy engines 122a and 122b respectively. For example, gateway function 124a could be a location function that provides the geographical location of mobile user equipment 108. A policy in the local policy engine 122a controls the location gateway function 124a, determining who is allowed to see geographical location information for a particular user equipment 108.
In some embodiments, the local policy engine is configured to enforce charging policies as well as control policies. Charging policies refers to the process of billing customers for the provided services. Alternatively, the charging policies may be implemented by the policy server 104. As previously discussed, the policy server 104 may include functionality, such as PCRF implementation discussed in the 3GPP standard. The operation of charging policy servers is within the scope of knowledge of one of ordinary skill in the art and need not be described in greater detail herein.
The service gateways 106 are logically linked to the policy server 104 via reference point 130. The reference point 130 serves as a signaling link between the policy server 104 and the service gateways 106. The reference point 130 is used to communicate policies between the policy server 104 and the local policy engines 122. As discussed above, the policy server 104 may be configured to provide charging policies to the service gateways 106. This may include the non-policy-enabled service gateway 106c as well as the policy-enabled service gateways 106a and 106b.
In an exemplary embodiment, the reference point 130 may conform with the 3GPP standard Rx reference point. Alternatively, non-standard protocols and reference points may be used. For example, the reference point 130 may be configured as an enhanced Rx reference point. In yet another example embodiment, the reference point 130 may conform with the DIAMETER protocol, but not comport with the 3GPP standard for the Rx reference point. Thus, the architecture 100 is not limited by a particular form of the communication protocol used by the reference point 130.
Policy-enabled service gateways 106a and 106b have an additional reference point 132 to logically link with the policy server 104. Policy-enabled service gateways 106a and 106b are configured to send and receive policy information to and from the policy server 104 via the reference point 132. In an exemplary embodiment, the policy information includes policy decisions, which are policy rules bound with subscriber information and service information. In some embodiments, the policy server 104 is configured to bind service information and subscriber information to policy rules to make policy decisions which are then sent over reference point 132 to one or more of the policy-enabled service gateways 106a and 106b, to be enforced by the local policy engine 114a or 114b, respectively.
In the exemplary embodiment of
In other embodiments, the policy server 104 is configured to send policy rules, via the reference point 132, to one or more of the policy-enabled service gateways 106a and 106b, to be bound by the local policy engine 114a or 114b, respectively, with subscriber information and service information to form policy decisions which the local policy engine 114 then enforces. In an exemplary embodiment, the reference point 132 may conform with the 3GPP standard Gx reference point. In an alternative embodiment, the reference point 132 may be an enhanced Gx reference point. In yet other alternative embodiments, the reference point 132 may conform with the DIAMETER protocol, but not conform with the 3GPP Gx standards.
Service gateways 106 are configured to pass service related information to the policy server 104 via the reference point 132. In addition, policies may be updated centrally at the policy server 104 and relevant policies (i.e., policies related to the particular gateway function) may be routed to the respective local policy engines via the reference point 132. Thus, the local policy engines 122 may be updated as necessary from a centralized source, such as the policy server 104. In addition, there may be circumstances in which the policy-enabled service gateway 106 receives a user service request for which the local policy engine 122 does not have the appropriate policy. For example, a new user may be authorized to access a particular service, but the local policy engine 122 does not have updated information with respect to the new user. In such a situation, the policy-enabled service gateway 106 may request the relevant policy from the centralized policy server 104 via the reference point 132. The requested policy is transferred from the policy server 104 to the local policy engine 122 via the reference point 132.
Each local policy engine 114 is configured to form a signaling loop with the policy server 104 and the policy enforcement engine 110 to effect policy based dynamic service control.
In a similar fashion, the signaling path 142 between the policy server 104 and the policy-enabled gateway 106b may be implemented as the reference point 130 and/or the reference point 132 of
In addition, the signaling path 146 between the access gateway 102 and the policy-enabled gateway 106b enables communication there between. The architecture 100 is designed for dynamic policy enforcement. Thus, while policy enforcement may typically implemented by the local policy engine 122b, under some circumstances the policies may be enforced by the policy enforcement engine 112 in the access gateway 102. For example, load-balancing between the policy engines may be provided whereby some policies may be enforced by the policy enforcement engine 112 in order to achieve better load-balancing between the policy enforcement engine 112 and the access gateway 102 and the local policy engine 122b in the policy-enabled service gateway 106b. Policy enforcement information may be exchanged between the access gateway 102 and the policy-enabled service gateway 106b via the signaling path 146. Similarly, charging policies may be exchange the access gateway 102 and the policy-enabled service gateway 106b via the signaling path 146.
In an exemplary embodiment, the control loop 140 is policy driven and uses standard protocols to communicate service and network policy information. Policy-enabled service gateways 106a and 106b achieve dynamic policy enforcement in that enforcement points, such as policy enforcement engine 112, can concentrate on the task they are designed for, yet at the same time can request and enforce policies that affect services which must be carried together by other network elements, such as the local policy engine 122b. In addition, the local policy engine 122b can, at the same time, enforce and request policies that affect services which must be carried together by the policy enforcement engine 112.
The components described herein in some embodiments are implemented as a computer processor coupled to a memory, the memory containing instructions that when executed by the computer processor, perform the functions as described above. In other embodiments, the components are implemented as hard-wired circuits. The operational steps performed by the hardware circuitry (e.g., computer processor or hard-wired circuits) are described below.
The operation of the architecture 100 to route service requests to a policy-enabled service gateway is illustrated in the flow chart of
If the selected service request received at the access gateway corresponds to the service provided by one of the service gateways, the result of decision 154 is YES. In that event, in step 158, the service request is routed to the corresponding service gateway that provides the requested service. In the example embodiment of
In step 160, the local policy engine 122 will apply the local policy to the service request and process it accordingly. The process ends at 162. As discussed above, application of policy rules by the local policy engine 122 advantageously offloads policy enforcement from a centralized policy enforcement engine (e.g., the policy enforcement engine 112 in
As previously discussed, there may be circumstances under which the local policy engine 122 may not have the appropriate policy to apply to the service data flow. The operation of the architecture 100 to provide the necessary policy to the local policy engine is illustrated in the flow chart of
If the local policy engine (e.g., the local policy engine 122 of
Those skilled in the art will appreciate control of policies within the local policy engine (e.g., the local policy engine 122 of
Returning to
Those skilled in the art will appreciate that a number of different selection criteria may be applied to determine whether or not to store a recently downloaded policy rule. For example, the local policy engine may store a rule if it has been requested a single time before, as illustrated in the flow chart of
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to inventions containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations).
Accordingly, the invention is not limited except as by the appended claims.
| Number | Date | Country | |
|---|---|---|---|
| 61034878 | Mar 2008 | US |
