Policy management has been a topic of discussion in telecom networks for over a decade.  The focus of this article is on policy management and consumer services/networks.  Policy management appears in the PDF (Policy Decision Function) of the 3GPP IMS (IP Multimedia Subsystem) specifications, within many SDP (Service Delivery Platform) implementations, and a number of standards bodies such as the DSL Forum, Broadband Forum, etc.  However, given all the specifications and implementations, little consensus exists on what policy management means and what level of policy management is commercially required.  A common mis-conception is to confuse policy management and quality of service (QoS).  Policy is about making a decision (that could involve QoS) and its enforcement.  QoS is a traffic characteristic, e.g. capacity, round-trip delay, availability.

Policy management has two components: decision and enforcement, it determines the degree to which a service/device is allowed to do what it is attempting/requesting (decision), and is then able to enforce the decision (enforcement).  Note, enforcement could be non-real-time, for example excess charges are incurred rather than a service is rejected in real-time.  Some examples of policies include:

• Customer policies: is the customer allowed to use this service?
• Network policies: is there enough capacity to support this new service?
• Service Provider policies: what happens to non-SLA (Service Level Agreement) customers when a node approaches congestion?
• Security policies: is the service request/activity a security threat?

The practical implementation of policy has proved tough for consumer services.  To implement a policy decision the value being watched must be known in real-time, known accurately, be stored (for trouble-shooting), and in some cases have a knowledge of the context within which a policy decision is being made (e.g. customer and network context).  Then there’s the enforcement side of policy management, being able to implement controls.  Which means there can be significant cost in implementing policy, which requires a business case, and this has proven to be a stumbling block for many policy implementations.  To determine if policy is required, the ‘value’ of the threat must be determined, so a commercial decision can be made on whether the threat should be monitored and how it should be enforcement, e.g. QoS control, charging control, aggregate flow controls, static policies, etc.

The conclusion is that for most practical consumer threats, policy management can be implemented through aggregate policing, QoS, at the service layer or by billing.  Fine-grained network enforcement to guard against a DOS (Denial of Service) attack and manage roaming/nomadic customers can be implemented through static, pre-configured policies.  So when an operator sees fine-grain dynamic policies being offered, they should check if the business case for such an implementation makes commercial sense.