Subscriber Data And Network Policy Control

-------------------------------------------------------------------------------------------------------------------------------------------

To say that we are entering an era where the key values of an operator are being redefined is an understatement. In fact, we have already entered an era the se key values are going to be in a constant state of change. There are a few strategic defining statements in an operator's “life”. Statements like an all IP network, fixed and mobile convergence, IT and network merger; all contribute to defining how new services and transformational activities are designed and executed, and can be described either as symptoms or enablers of this new era.

At TELUS, we made the decision in 2000 to be an all IP network, in 2004 we created a single IT architecture team for the enterprise and in 2005 we merged the fixed and mobile businesses.

Technology bragging rights have been great. Reality however has dealt us a few tough lessons and forced a number of architecture redesigns and cultural re-alignments.

You would ask how is this related to subscriber policy and control?

We found out that the key to ensure we were focused on creating and maintaining TELUS 2.0 was to harmonize and align our activities around our two major assets. These are the subscriber and the network. Thus the “never changing” part of our transformation has been abstracting the service from the network and likewise abstracting customer information from the workflow. IS projects span many years and it is critical that people do not mistake the IS project (the transformation vehicle) for being the end state (the destination). Actually this becomes more important for people who believe we are in the business of IS transformation; actually we are in the business transformation arena and that is everyone's responsibility.

Easier said than done.

A number of concepts have been floating around that are intended to redefine the operator landscape and help with the transformation; concepts like the IP Multimedia Subsystem (IMS) and Services Oriented Architecture (SOA).

Eight years into IMS standards and deployments, it seems that the killer application is Wireline transformation. Actually IMS is great for Greenfield operators; they do not have to invest in TDM switching. TELUS has been around for a hundred years, so the Class 5 switch replacement and “real estate” reclaiming did not make business sense on their own; developing all broadband systems and processes did. I am a big believer in what IMS is trying to achieve; and some excellent work is underway to deal with charging and policy. The IMS architecture and principles make perfect sense. Specifically, IMS plays a key role in the area of network policy. In a world where service is abstracted from access, most of the services we take for granted today simply will not work properly with a best-effort basis. Network policy is required to allow services to use sophisticated access abilities. Network policy control is required to resolve the new issues which arise in a horizontal world: Optimizing access resources, providing a high-quality service experience, preventing malicious usage and solving the broadband incentive problem.

With regards to Service Oriented Architecture (SOA) I am extremely opinionated. SOA is being heralded as the panacea to develop systems. Service-Oriented Architecture is extremely useful in organizing the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. In this context , w e need to ensure that we do not hard code subscriber information with business processes and network resources, and expose technology constraints which drive assumptions. Proper governance and design to achieve this have been critical to our success, I truly believe proper design on the systems side should always be SOA like, just like proper IP network design and services development should be IMS like. SOA based implementations will hopefully guarantee that we do not get legacy based implementations, however I can cite numerous C++ software implementations that are not object oriented designs.

One of the critical covenants is the proper decomposition of the OSS-BSS stack to expose the fundamental technology aspects that drive the service composition and capability. We are aligning with Telemanagement Forum standards around decomposition into customer management, service management and resource management. There is however, a larger challenge that is not well addressed within the standards bodies and software solution provider domain. That is the actual details of demarcation points to provide robustness and mobility of implementations between vendors and operators. We believe the design principles of SOA and the architectural principles of IMS are the way to go. In addition, our current implementations follow both principles.

Fixed Broadband

Our IPTV deployment forced us to begin examining subscriber policy and control a number of years ago. The stringent network resource requirement for video transmission meant that we had to begin implementing network policy, while the new service mandated we have in place the first part of subscriber data flexibilityd control.

As most other operators guessed; we had to build the first instance ourselves. It was clear there are no standards or a single vendor to help out.

This is one of the areas that having a single systems architecture team across the enterprise proved invaluable. We developed two parallel complementary functionalities. The first is a network abstraction layer that starts the decoupling of vertical stacks to remove the hardcoded integrations that were based on a myopic view of technology evolution. It provides service interfaces to manage the qualification and fulfillment of consumer services independent of the underlying switching vendor, access technology and implementation. The second is resource policy which mediates between the network facing service and the resource management requirements of the broadband connection, bandwidth requirements, Quality of service and IP requirements. Interestingly enough we could decompose our network abstraction layer along IMS architecture principles and our wireline policy engine supports IMS Standards

We had a legacy of home grown systems and poor integrations that reflected the industry evolution, the rapid change of the ‘Internet ERA' and legacy thinking. The reality that the business support systems tied all subscriber information and business policies to a phone number on the broadband network was a key impetus for change. The propagation of phone number is an artefact of the history of PSTN providers operating in a near monopoly environment layering their broadband access onto the existing PSTN service. This combined with assumptions around technology constraints and the roles that staff had accumulated during the maturation of voice services over many years provided a signification challenge to transformation. Driving the decoupling of business support systems involved tackling both people and process changes in addition to technology to be successful.

The key for us was to start the decomposition of the services into the supporting resources and to evolve the TELUS broadband network as a “smart pipe” into the home. This was done without impacting the IS transformation that we were undergoing to decouple customer management from the “telephone number” and the “network”. This was a necessary step in order to support new services which are much more demanding from an engineering and technology perspective.

We worked diligently with our lead partners. In this case, Juniper Networks and Intelliden, to develop the network abstraction and subscriber policy systems. TELUS Broadband today is based on the Juniper ERX BRAS and the ALU 7450 aggregation. We use the SDX product from Juniper for subscriber policy, and coupling it with Intelliden and a workflow and integration engine, provides us with a unique network profile capability. This implementation has enabled us to change IPTV Middleware without impacting major IS systems.

Again this is a real implementation that clearly has dependencies on our hardware vendors. I would say the industry is not sufficiently mature today for generic subscriber policy systems. The issue would be the stand alone revenue versus the pull through revenue that the hardware vendors see.

Mobile Broadband

Our approach on the Mobility side was a bit different: Our Service Delivery Framework (SDF) allows us to expose mobile network capabilities to external service developers

From a newtork policy perspective, the promise of linking QoE with web services is extremely exciting and a differentiator for an operator. Unfortunately while we have made these investments and architectural decisions, however there are no services today to benefit.

From a subscriber data point of view, all API's exposed are currently based on the notion of a mobile subscriber, which very much resembles a user. By indexing all the APIs on a per-user basis (e.g. "provide me the location of user X"), we are inherently offering "subscriber data" as a service in and of itself which the third parties can then use to build a service. While this tempts us to say "mission accomplished", there is a large gap between offering a few APIs of subscriber data and making all subscriber data accessible and available in real-time with all of the necessary controls, privacy mechanisms, consistency-checks, and so on -- all of which are needed to begin using SDF as the basis for all internal and external service development.

Our investments on the mobile broadband side were intended to ensure we are IMS ready to benefit from the emerging standards in common control, policy and charging. We have built a SDF using BEA and Aepona for the workflow and gateway and have built billing APIs to accommodate web-based services. Note traditional telephony billing is being done through standard CDRs.

Conclusion

It is clear that the subscriber policy and control challenges in the fixed and mobile world are different. At TELUS we would like to ensure that next generation networks and systems deliver next generation value rather than mimic what we have today. The key criteria have been abstracting the services from the network, and in abstracting the billing information from the services and network.

To this end, we have built our own adapters for the fixed broadband network and use the Juniper Policy manager, and we built our own billing APIs and use a SOA based SDF for our Mobile Broadband network.

In order to live in a world of change, we need simplicity and flexibility. This means abstracting the services from the access, and network policy and subscriber data are on the critical-path to this abstraction.

Acknowledgments

Many thanks to my colleagues at TELUS, namely Brian Lakey (head of OSS Strategy and architecture) and Said Mokbel (head of mobile strategy and architecture) for their help in providing feedback modifications.

Subsribe Free Newsletter for the latest in Billing OSS Industry. Latest trends and reports from world over: www.BillingOss.com