Policy Management System
An enterprise product cataloging system for all broadband services

By: Bruce Bahlmann - Contributing Author (your feedback is important to us!)

Created: April 27, 1998

Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.

Overview:

Too often in business, advances in technology drive product offerings. Companies take this "raw" technology and suggestions or "hints" from developers and vendors to form new products that it believes will sell. Providing Internet service is one such area where product offerings are driven by technological advances. Much of these advances do not come in any order and, more often than not, companies seeking to benefit financially from it are faced with expensive re-fitting of their infrastructure. Multiple Subscriber Organizations (MSOs) need to be more agile and responsive in the Internet space to expand/retain their growing customer base. Having a policy management system structured around a clear and identifiable business model would enable MSOs to quickly bring new products to market and leverage the readily accessible information about their infrastructure (a by-product of the proposed system) to build and maintain the highest quality of service. The objective of this document is to further previous work by introducing the high-level requirements, initial components, and data elements of the policy management system.

Introduction:

The following architecture would provide the basis on which policy management would evolve. Figure 1.0 shows a hierarchy of databases that together provide much of the policy management system. This system must enable MSOs to standardize their infrastructure, streamline their deployment of new products, and speed outage detection and correction. Building this type of policy management system means that all components of the system as well as their regional differences must be inter-related and managed.

Figure 1.0 Database hierarchy of policy management system

One of the keys to this system is the enterprise database (object) called the Central Policy Database (CPD) shown in Figure 1.1.

Figure 1.1 Central Policy Database (enterprise object)

This database contains some of the basic framework of ALL products maintained by MSOs, ALL product features, ALL devices supported by its infrastructure, and ALL customer types to which it provides service. An overview of the objects contained within both the central and regional and configuration databases are explained in the document Provisioning Strategy, see References section.

Policy Management System Requirements (overview):

In order to build any kind of policy management system there are several requirements that MUST be met before such a system can be developed and sustained. These requirements are as follows:

• Standardized product for the company
• Generalized product descriptions and components
• Standardized billing system interfaces
• Standardized product support system interfaces

Each of these basic requirements will be introduced below in sufficient detail for them to be understood (less actual requirements for it to be built which will be contained in a separate document).

Standardized Product:

Each product sold by the MSO must be the same across the entire company. For example, if a basic residential Internet service is offered in any two (or more) regions, the features, cost, etc. of this product must be the same across all regions which it is being offered.

Generalized Product Descriptions and Components:

Each standardized product that is defined at the enterprise level is void of any regional dependent capability or responsibility. This generalized definition MUST also accommodate any regions that for some reason or other exceed/lack the capability of other regions (systems independence is the key). In other words, the same standard product definition will be generalized enough to accommodate ALL regions capable (one way or another) of deploying this product (unless necessary hardware/software to support that product does not yet exist in a region).

Standardized Billing System Interfaces:

All interfaces to "regional" billing systems will be standardized. Commands to add, modify, or deactivate a billing account will be supported by the Application Programming Interface (API). The standard API will be published for other billing system vendors to support future products and/or releases.

Standardized Policy Support System Interfaces:

Policy support system interfaces such as APIs to provisioning servers, telephony switches, subscriber management systems (SMS), routers, etc. will also be standardized to support this system approach to managing all the components necessary to deliver a product. These interfaces will also be published and made available to vendors in their respective area to support future products and/or releases.

Policy Management System Components:

A single regional "slice" of the policy management system might appear as shown in Figure 2.0. Here several other regionally deployed applications tie into the policy management system for product configuration and support. Policy management provides synchronization between all applications that must be properly configured to support the deployed products.

Figure 2.0 Regional "slice" of policy management system

Each of these components work together as a "system" to provide various access points for MSO tier 1 & installation, network operations, and tier 2 & 3 support. The following provides a brief introduction to the components of the proposed system.

Enterprise Admin Tool:

This tool provides a entry point for enterprise objects to be created, modified, and removed. Through this tool, each product, customer, feature, and device can be maintained. Anything not defined in this database is not supported.

Central Policy Database (CPD):

Repository for high level definitions. The relationship between this model and its children, Regional Policy Databases (RPDs), is that while they both share the same schema definitions, there will be no replication of data from the RPD up to the CPD. Data pertaining to regions will stay within regions and a referral used in the CPD will enable lookups on any regional data from a single point. From that perspective the CPD will act as a pointer to certain public data contained in the RPDs.

Regional Admin Tool:

The regional admin tool will provide an interface to for regional configuration to overwrite those of the CPD. The regional admin tool will be able to map product codes for individual MSO services (and be under the control of the MSO) as well map features to particular applications deployed in the region to support these features.

Regional Policy Database (RPD):

Repository for regional data such as supported subscriber services and features, SMS product code particularities, products supported, and regional applications deployed. Through this database, all day-to-day transactions are managed. When a new product is deployed at the CPD, if it does not have a dependency of something that does not exist in the region it becomes available once the product is mapped to its product code (unless the region supports standardized product codes, in which case it would be immediately available to the region). Other links to the RPD include interfaces to MSO front end applications such as an ETE (Enterprise Ticket Engine). ETE, which is used by Tier 1 representatives (also called CSRs), would utilize the RPD to provide a current listing of available services supported by the network provider.

Provisioning Server(s):

Provisioning servers are any hardware and or software combinations that support some product(s) or feature(s). Some example of provisioning servers are DNS for providing hostnames to CPEs, DHCP servers for providing dynamically assigned IP addresses to hosts, and TFTP servers which provide configuration files for cable modems. Provisioning servers determine what products and features are supported in each and every region. Provisioning servers can utilize data in the RPD to configure its service groups that are allowed in the region. Here, even though other service groups are defined in the CPD, the RPD dictates which ones are correctly mapped to MSO billing codes and thus fully supported.

Tools Interface:

The tools interface is the gateway to troubleshooting and network management. This interface takes data from the provisioning servers, RPD, and the on-line databases to enable quick resolution to customer and network problems. The tools interface may also streamline configuration and or reporting. The tools interface will utilize data from the RPD to enable the tool to work with specific devices supported in the region as well as communicate with these devices via their correct passwords and community strings (where appropriate).

Self Service Interface:

The self service interface enables customers to activate and maintain their Internet account without intervention from the MSO. The RPD provides this interface with the supported service selection as well as regional data it needs to interface with regional specific applications. In this case, the RPD actually provides direction to the self service interface for what is supported within the region and what the standard operating procedure is for carrying out subscriber requests.

API:

The API defined here is a specialized database (or LDAP) client. This client is highly configurable via fields in database which allow it to carry out transactions with an MSO SMS. Its important that this API be hardened such that all its smarts come directly from the database so as to not require any additional development during its deployment. If, for example, a new SMS is encountered during deployment, a new SMS object is defined in the database. The particularities entered into API’s configuration fields in such a way that the front end of the API remains the same while the back end is accommodated by the new database object.

MSO IT (for SMS):

This particular tool is most likely not an actual tool but rather used to signify some amount of MSO configuration that is needed to define new products as they are launched. This kind of model would need to be maintained as long as the MSO remains authoritative in terms of services and features the subscriber has chosen or the MSO continues to map individual services or features to unique billing codes. Improvement of the latter of these operations is most attractive to the network provider because it would not have to map each and every new product service and or feature to a unique MSO billing code. This process also minimizes "some" of the return the network provider can achieve through a product management system. Instead, if the MSO would make available a set of standard billing codes that the network provider could post similarly priced subscribed services and or products, the MSO would not have to administer both the RPD and the SMS.

Subscriber Management System (SMS):

The SMS represents the repository of customer specific data. This database represents the only place where customer name, address, billing info, etc reside. All other systems maintained by the network provider will not contain any duplicate information to that of the SMS except for the account number. The account number will be the network providers single reference back to each and every MSO high speed data customer. By utilizing only the account number, the network provider significantly reduces its risk (if any) of its subscriber data being exposed. This method also prohibits network provider employees from accessing confidential MSO subscriber data and limits the network provider’s responsibility (and liability) to maintaining meaningless data stores of subscriber system configurations.

On-Line Database(s):

The network provider will utilize a number of databases (like LDAP) to store various system/service configurations for its subscribers. These databases will utilize the MSO account number to map each configuration or set of configurations back to specific MSO subscribers. Efforts will be taken to the extreme to avoid any duplication of data that is needed from the MSO SMS and, as stated above, all on line databases will be void of any and all subscriber identifying information except the account number assigned to the subscriber by their MSO.

An example of a working Policy management configuration would be to support a "basic level" of residential Internet service. For this example, the regional configuration database provides service group configuration to the Provisioning Server, makes available this service group offering to the Self Service Interface (and Subscriber Management System), and provides interfaces to/from the Subscriber Management System properly to link this service offering to the appropriate billing code (and corp where appropriate) for customer billing.

Development & Deployment Concerns (work in progress):

• Focus on database administration rather than writing of middle-ware. This system will greatly depend on successful administration in the areas indicated by the various admin tools identified in Figure 2.0. Deployment of new products will focus mainly around ensuring proper mapping of products and optional features are correctly associated with their billing codes.
• Personnel responsible for administration must be database savvy or the administration tools must support novice database knowledge.
• Development of a "standard" set of billing codes that is adopted by all regions would greatly simplify the amount of administration required during deployment of new products. Use of a standard set of billing codes would mean that each code could be re-used for other products (or additional features). This would cause a problem for itemized billing efforts if these systems were not able to communicate with each other. Two models exist that would support standard billing codes. One would empower the on-line database to be responsible for products and features a customer is subscribed to and the SMS would inventory this list during the billing cycle to determine the charge for these services. An advantage of on-line database storage of this information would be the support for periodic changes in services that impact monthly costs (billing variances). The other model would require that the SMS maintain its authority over subscribed services but allow the network provider the ability to invoke service changes and perform all necessary calculations to date on existing services to "close out" that service’s billing period and begin the new service billing period. The "best practice" model would be that the SMS perform all the above functions but this may not be universally supported by all SMSs. In the end, the best system may be the one that the network provider can deploy that a majority of the MSOs can support.
• Handling of billing variance events must be supported by the SMS and any interfaces to it (for example the self service interface) for more information about the self service interface refer to the document Self-Service Strategy: Subscriber Activation Module. A billing variance occurs when a subscriber modifies his service to the extent that it changes the cost of his/her monthly service rate. When this occurs, a billing variance must be calculated and the event is passed to the SMS for itemization. Detecting and processing a billing variance should take place in the subscriber maintenance module. For more information about this system refer the document Self-Service Strategy: Subscriber Maintenance Module.
• Support of above-and-beyond billing variances. The possible options that abound when opening up individual features as add-on options enables a multitude of billing opportunities and challenges for the on-line database model and its interactions with the SMS. This support is critical to expansion of basic services and profitability for the MSO to further capitalize on technology already in place.
• Since billing codes can vary within a region for the same product (for example when database partitions/corps are used), this represents a challenge to this mapping exercise unless subscriber records can be accessed in such a way that the corp (or equivalent) is not needed. If the corp is required, additional qualifiers may be needed before a subscriber record can be obtained from the SMS. One possible set of qualifiers would be the customer address and city, however this would fail for multiple dwelling units (MDUs) which would additionally require apartment/suite numbers. Determining qualifiers that will work for all cases will represent a challenge to any development of an API.

• Synchronization of subscribed packages. Use of LDAP to store the service level that a customer is subscribing presents a challenge to keep service packages the same across SMS and LDAP. The authoritative source for the service package data is the SMS as that is what the customer is being billed. However, duplication of this information gives rise to synchronization problems if either LDAP or SMS was modified and the changes were NOT carried through to the other data store.

• Support for multiple database vendors and enviable transitions. Mapping of database codes must utilize an index rather than directly mapping products to billing codes. The index would allow mappings to utilize an off-set whereby transitions from one billing system would be easily performed by modifying the offset. The use of the offset would also provide ease of recovery during any transition process. To support database vendor transitions, the offset must be associated with each distinct set of billing code qualifiers. This enables partial transitions of SMS systems to take place rather than forcing entire transitions because of lack of flexibility.

These concerns MUST be addressed in the design of the data model for the Regional Configuration Database, the API for the SMS, and duly noted in the SMS such that every possible failure case is satisfactorily handled. If all exit or failure states are not accounted for database synchronization between on-line database and SMS could result as well as billing discrepancies. A complete workflow of the possible data flows for processing an account are required to ensure proper handling.

Data Elements of the Policy Management System:

The data model for the policy management system focuses around creating a standardized environment that is conducive to plug-n-play components all with similarly supported features. The basic idea is that a feature is application independent entity that together along with other features makes up a product. While further details are provided later in this text about features, a high level diagram of the policy management system hierarchy is shown in Figure 3.1.

Figure 3.1 Hierarchy of policy management system

This hierarchy enables individual product features to map to their application supported counterparts which are determined by what is actually deployed in a particular area (or region). For example, say a feature of the "basic" product is that of a service group called "1.5mx300k". This service group is generically defined in both DHCP server objects and associated with the corresponding configuration necessary to configure that feature on that DHCP server type. In the region, the DHCP server deployed allows generically defined product features to map to their correct DHCP supported references and DHCP server is able to pull its service level parameters from the product management system to configure its service groups.

As an introduction to this process a "first draft" of the proposed product associated data models are introduced below. These data models highly leverage a hierarchical method of baseline and inheritance to reduce replication in similar (grouped) product lines as well as simplify management of these grouped product lines.

Product Data Model:

Table 3.0 Data model for a product

Figure 3.0 shows an example of how this data model might be implemented in practice. This tree represents the definition of a "basic" and "symmetric" residential service product. Note that each product is associated with one or more parents and also associated with one or more features. A parent is a higher leveled object that enable global changes to a subset or ALL products. A feature describes some particular functionality associate with a product. For example one feature might be personal web hosting (PWH). Since PWH is associated with residential group, all objects with the parent "residential" will support the feature PWH.

Figure 3.0 Product configuration example

Both products and features must initially be defined in the CPD before they can be used. While the project object is made available to the regional policy database its not administered from anywhere but the CPD. This allows centralized policy management to be maintained. Unlike the product object, features can be regionally administered. This allows them to adhere to any limitations or restrictions that may exist within the region while not obstructing other regions (who perhaps have no limitations) from offering the feature as it is intended.

Separating the product data model from individual features allows the features to evolve with technology while not interfering with the products which they are included. If features were directly part of products each new technological advancement would mean the products would need to be re-worked. Instead, if a new technology improves a feature, the feature model is reworked to accommodate the new technology while leaving the product definition untouched.

One important thing to understand about features is that they are at a lower level than products. Features map "select" application functionality to independent objects. These objects represent the underlying functionality of applications and consequently will have larger dependencies on the hardware and software that is deployed. Therefore, it is at the feature level that "regional" specificity can impact the what features will be part of a product that is defined at the higher level and offered in the region. For example, if a region does not have the capability to provide five email accounts (FFiveEmail) this feature would still exist, however it would not be supported. A feature that is not supported is re-defined or cleared by a regional definition of the same feature. The applying of products and features follows an inheritance model where by anything defined in the CPD can be retained, re-defined, or cleared as these objects enter the regional space.

Another caveat about features is that they are independent objects. Features can be added to any product object to create a variant. These variants enable the network provider to offer highly customizable service that includes allowing customers to add numerous additional features to their service. With the addition of each feature, the cost the service "can" change by the amount associated with that feature.

Feature Data Model:

Table 3.1 Data model for a feature

 References:

Provisioning Strategy, Bruce Bahlmann, April 27, 1998

Self-Service Strategy: Subscriber Activation Module, Bruce Bahlmann, May 27, 1998

Self-Service Strategy: Subscriber Maintenance Module, Bruce Bahlmann, May 27, 1998

Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white papers hot off the presses by adding our RSS feed to your reader.

(C) Copyright Birds-Eye.Net, All rights reserved.
It is against the law to reproduce this content or any portion of it in any form without the explicit written permission of Birds-Eye Network Services, LLC. Federal copyright law (17 USC 504) makes it illegal, punishable with fines up to $100,000 per violation plus attorney's fees.