To write policy rules, it is important to understand how they are evaluated by the Policy Rules Engine contained within the MPE device, and how the engine fits into the protocol message processing within the MPE device.
If you look at the policy conditions that are available, you will see that many are not protocol specific. Although you can write protocol-specific policy rules, the Policy Rules Engine does not have any protocol knowledge. Instead, it deals with a set of abstractions that are mapped to the underlying protocol messages that are being processed. This allows the same policy rules to be used across multiple protocols.
When the MPE device receives a protocol message, it performs the initial processing of that message and then determines whether or not the message should be processed by the Policy Rules Engine. Generally, protocol messages that are either requesting bandwidth or modifying previous requests for bandwidth are processed by the Policy Rules Engine. Most other protocol messages are not. For example, a protocol message that releases bandwidth is typically not processed by the Policy Rules Engine because there is no reason to prevent or modify that action.
After a message is identified as a candidate for the policy rules, the
MPE device attempts to associate as much information with the request as possible. For example:
- Which network elements will be impacted if the request is allowed to proceed?
- Which subscriber is associated with the request? What services is that subscriber entitled to?
- Which application is associated with the message?
- What time zone is the user equipment located in?
The reason for collecting this information is to make it available to the policy rules. The information that can be associated varies and depends on a number of factors, including:
- The protocol in question and how much information is provided in the protocol message
- The amount of network topology information that has been provisioned into the MPE device
- Whether there are other protocol sessions that can be associated with this message
- Whether there are external data sources configured that the MPE device can use to associate information with the message
When the process of associating information with the request is complete, the
MPE device analyzes the information and maps it into several important abstractions that are central to the functioning of the Policy Rules Engine:
- A list of network devices that the request affects. A network device is any network element, any logical or physical sub-component of a network element, or any other network equipment.
- A list of flows associated with the request. A flow is a logical grouping of one or more packet filters and associated information such as QoS, charging, or service information. A flow can be in a single direction (either upstream or downstream). A flow can be a collection of bandwidth parameters. Different protocols can have a different number of flows associated with a message.
For example:
- In Cable mode, the PCMM messages have only one flow per request.
- In Wireless mode, the DQoS messages have one or two flows per request (for each direction).
- A list of policies associated with the request. This includes policy groups and reference policies called by the parent policy.
After constructing these lists, the Policy Rules Engine applies the policy rules according to the following algorithm:
For each network device:
For each flow that is being created or modified:
For each policy that is being evaluated:
Evaluate all policy rules
End
End
End
A device refers to any device that creates a Gx session, such as a PGW or GGSN; the enforcement device associated with the corresponding Gx IP-CAN session; or any device that creates a Gxx session, such as an HSGW.
It should be clear from this algorithm that a single message can result in multiple policies being evaluated, and a policy rule being evaluated multiple times. This is important to understand to ensure that the policy rules you write operate in the way you intended.
By using parent policies, reference policies, and policy groups, you can control the order of policy execution. For example, assume there are four policies: two parent policies, policy1 and policy4, and two reference policies, policy2 and policy3 that are in a policy group, group1. The hierarchy is as follows:
policy1
policy2
policy3
policy4
The order of execution can vary, depending on how each policy evaluates and what actions each contains:
- The normal order of execution would be policy1, policy2, policy3, policy4.
- If the conditions in policy1 evaluate to false, the order of execution would be policy1, policy4.
- if policy2 includes the mandatory action break from policy level, the order of execution would be policy1, policy2, policy4.
If the optional 3GPP-MS-TimeZone AVP is available over the Gx protocol from a PCEF, the MPE device can compute the local time for user equipment, even if the user enters a different time zone or the time offset changes because of Daylight Saving Time.
Note: Policies created using a more recent version of the CMP software may not evaluate and execute as intended on an MPE device running an older version of the MPE software. To ensure that policies are evaluated and executed as intended, update all systems to the same version of the software.