Implementing SDPs
Considerable changes in IT and Network architecture are required when implementing real-world, real-time, converged services, operational SDPs. Many SDPs are designed as abstract frameworks with diagrams that use labels such as "Service Abstraction Layer", etc. Within real systems such "layers" do not actually exist. In addition it is difficult to realise from abstract diagrams what the real-world operational data model is and how many servers, databases or directories might be used or integrated to form converged services SDP and self care functions. Operators can be faced with annual multi-millon dollar electricity bills for their systems. It follows that multi-server/multi-database SDPs are not earth-friendly or cost-effective, if the same functions can be integrated and use much less power.
Identity and Information Management: In order to specify or design a SDP we must determine what the customer and device service dimension is. If the SDP design needs to accommodate, say, 1m users as well as manage their devices and each identitified item requires 5 to 10 information objects, the core SDP is probably dealing 20m objects in real time. As the management of these objects dictate the core identity management processes of the platform, critical attention should be applied to the way in which they are implemented. Experience has shown that a single user on a converged services SDP may require 100 objects of information with some objects such as preferences containg 100 attributes. Capacity requirements for 10m users would indicate the platform needs to support 1 billion objects and up to 50 billion attributes.
Group Identity and Entitlement: Traditionally we have dealt with Identity Management as a single user or device logging on with a name and password and have assumed that an Identity Server holding names and passwords solves the issue. Practically though in the MSO world, we have account holders, secondary account holders (the children of the family), guests, gifts, content, devices, preferences which must all link together in order to receive a managed service. The services the grouped identity receives might be authorized via name and passwords, but should only be enabled through entitlements that relate to product provisioning. SDP architectures need to accommodate group identity management and product/service entitlement functions.
Presence and Events: Presence is the status management of all online assets. But what does this mean to system architectures? Traditionally we have applied a "transactional" paradigm where for example a user logs on and creates a transaction onto a network switch, a web server or database application. Presence services means we are managing status events at rates much, much higher than our traditional transactional systems. The question is: how are millions if not billions of events managed in fragmented systems, multiple database architectures or in fact frameworks? SDP architectures should also have a coherent, highly integrated event management system as a core function.
Converged Identities: An operational issue emerges with 3G IMS and SIP and converged services. SIP can apply IP addresses (IPv4 or v6), SIP URIs (email addresses) and SIP TEL URIs (telephone numbers) in its message To, From, Via and Contact fields. Such identifiers can point to a telephone device, a fridge door, a content farm, a single piece of content, a user or even a group of users. This flexibility means that a SIP call can be made from just about anything to any other thing providing it is entitled to do so. As SIP can apply a mixture of these Internet and Telephone system identifiers in the call process, it follows that the SDP must tightly couple its SIP processing with the DHCP/DNS system, the HSS mobile database, the User authorization system, the presence event system, the user's address book, telephone call feature processing and the operator's service/product management with its entitlement system - all in real time. It follows that such functionality would be very difficult to apply across many interconnected functions and fragmented databases using "SOAs".
SDP technologies and tool kits should address three fundamental issues:
- What are the goods and services being offered and managed in a real time fashion by the operator and by the customer self care systems - and this includes the management of presence based services (the world of the event driven internet) and how realtime user entitlements are processed.
- What is the converged services information model used in the SDP design that represents the online business of the operator that has subscribers, devices, phone calls, preferences, entitlements, address books etc. to deal with. In many cases MSOs with just 10 million customers require an SDP with 500 million information items - and for these items to be accessed many thousands of times a second by many different SDP functions.
- What is the event / presence management architecture used in the SDP design that handles the velocity of the online business events. The situation might be that the population of a city arriving home at night might generate billions of online status events. How will these be processed by the SDP?
These three major system requirements actually dictate the architecture of a real world operational SDP regardless of the "abstract labels" one applies to its logical models, SOAs, message bus protocols and server interconnects. If these fundamental requirements are omitted from the SDP design it leaves the operator with many business, service management and operational problems to address, such as:
- identity management (of all the information in the SDP representing the operators online assets),
- the SDP's service agility (that is the product and services being offered are hard coded into the SDP so that new services cause code upgrades) and;
- hard wired self care facilities (no flexibility or consideration of the SDPs users such as language, age, sighted, preferences, etc.).
In some situations MSOs have millions of lines of hard coded product and service management flows in their systems and are unable to move to the newer converged service dimensions easily.
A quick test of an SDP design is to evaluate its information model and see if that is based on the user environments of converged services, and see how that model is used and managed by all the systems that need to including its presence and event management functions.
In support of SDP development and the evolution to real time, agile services-delivery, next-generation systems should be considered.
Read more about this topic: Service Delivery Platform