Managed Network Mashup

http://www.networkmashups.com/Mashup.aspx
 
Business drivers for any new architectural initiative would have to be strong to get buy-in from all related stakeholders. This is true even in case of SOA, mashups and Web 2.0. Article in this URL outlines some of the business drivers for these architecture and are summarized below (but with Microsoft going out of its service delivery platform (SDP), it is a pradox now on whether Microsoft realized that these business drivers are not strong enough to continue supporting these architectural principles).
 
- SOA is not just an effective methodology to implementing enterprise application integration (EAI) but also a means to rationalizing cost. However SOA helps in bringing the network effect, it can take advantage of The Long Tail phenomenon to improve top-line of an organization. But will the organziation wants to embrace network effect is something that organization will have to decide as part of its strategy (also in the long tail it is important to identify niche products/services that can move up the demand curve with certain catalysts).
- Mashups – advertising based revenue models and plan for sticky content and services. How disintermediation & margin rationalization that helped Internet’s near-zero marginal cost of distribution, can also help business to adopt these models?
 
Now how a service provider take cue from above business drivers to monetize components for which they are the custodians. These components are subscriber location/presence information, security, identity management, quality of service, troubleshooting, customer care, centralized bililng/metering and service provisioning. These can be key offering from operator and can be useful in creating managed network mashups.
 
This article also highlights some of the key differences between an enterprise based mashup application v/s communication service provider network based applications. Couple of key differences that I can pick are:
- asynchronous invocation in case of communications based application – which compared with synchronous nature of invocation in enterprise applications (like monthly/daily processing of records in an ERP system) makes it a system to be ready 24×7 with required response time
- high frequency of events handled in communication system
- rapid creation and deletion of objects
- multiple data source based decision, often memory database based access
 
Most striking difference mentioned is profit center v/s cost center i.e., each communication element needs to be managed service element with customer being charged for their usage. However in case of enterprise application, their operation cost tend to get treated as part of IT cost center. But since in communication services, many elements get involved in delivery of a service e.g., voice or data or content, separating usage for these elements for services would be necessary to make a certain service as profit center. However I do think that this is a very good approach that an operator can take to create profit centers out of each services and make the network infrastructure as a shared center.

Importance of Orchestrating Subcriber and Network Data

http://downloads.lightreading.com/wplib/openet/
WP_UsingSubandNtwkData_US.pdf
 
With the convergence of information, communication and entertainment industry, operators are looking at combining network capabilities with 3rd party applications and content to create new propositions. And also are looking at delivering services to business and consumers seamless across different network and devices. However service provider will have to understand customer experience and usage pattern to optimize existing service and introduce new services. Offering of this new service can be dynamic service offering through understanding of real time transaction or offline service offering through the network usage. Each of these options have their own challenges.
 
Increased dynamic offerings for differentiation and revenue growth can be achieved through usage of real-time transaction intelligence (like types of services people use, how they access, network status, service experience (mainly how many service consumption aborts might give an insight in this) and consumer preferences for service). Operator can accesses this real-time transaction intelligence through mediation or through an edge DPI enabled service enabler. Data collection (from network) and correlation (from IT) through mediation can be an option for the operator to have access to the complete view of subscriber activity. With this view also operator can plan sales programs, loyalty plans, data integration, revenue assurance and cost management.
 
Whether it through mediation or through DPI enabled real time service enabler, operator will have to use the following assets to deliver a better service to the end user (broadly they are network, service and subscriber related assets)
- Network capabilities – subscriber and session aware access, throttling, qos, charging, rating, promotions, bundles, thresholds, notifications
- Device capabilities – downloadable apps, camera browser, multimedia, network single/dual channel
- User context – location, device on/off, session status, weather, current content being viewed
- User identifiers – phone number, MAC, IM, e-mail
- Basic user data – name, address, geneder, credit payment history, preference, location
- User content – pictures, videos, bookmarks, address book, calender
- User profile – historical usage and profile based on usage
 
But to access these assets, there are certain challenges that operator will have to be aware of:
- Central availability of the data – from different network elements, from IT
- Sanity test of the data consistency across different silos
- Limited set of data sources – increase number of service elements that provide data, is billing only the source of data
- Making analytics functions available for those decision makers who are responsible for customer acquisition/retention, service introduction and marketing (some of these analytics functions are: customer profiling for identifying cross-sell /upsell opportunities, customer value management to determine total value of a customer (map between ARPU and other activities of the subscriber like number of calls to customer care etc), advertising & promotion with specific customer segmentation, product management through usage pattern.

Best of Breed Solution Design

http://downloads.lightreading.com/wplib/enea/Enea_WP_ArchIntegrPlatform.pdf
 
Integration approach requires architecturing the system with an approach to support multiple technologies from multiple vendors. This is a powerful statement and it outlines the basic attitude required in going for an integration of the solution. With each vendor bringing best of their products, for integration to be successful it is important to have the mindset to work together with each of them and bring out a competitive solution (e.g., SDP alliance).
 
Tier 1 NEPs have known for delivering high available network equipment solution handling hardware and software development in house. However to reduce cost & TTM, they are looking at bring-in standard based open COTS building blocks. Value proposition from COTS vendors has been low-cost, low-risk and fast TTM compared with the prioprietary middleware developed by the tier 1 NEPs. But none of these would work if there is a lack of well considered integration paradigm for architecting and executing new network equipment programs. However one can loop up to industry bodies like SCOPE alliance for the inputs and best practices in defining these integration paradigms.
 
SCOPE alliance (scope-alliance.org) defines scope and requirements of a carrier grade platform (CGP) and it has 7 building blocks – hardware, OS, middleware, application server, O&M and tools. Typically NEPs provide 1 or 2 components of this building block and look to  the COTS eco-system for the rest. Here the integration architecture should provide abstration for the proprietary building blocks. However there are certain requirements that the COTS component will have to satisfy before being included in the integration architecture. Most noteable are: redundancy, discovery & inventory management of resources, fault tolerance, component level controls/independence, upgrades & backward compatibility, security and management interfaces.
 
Pattern for defining integration architecture
- Use 5 parametes – modularity, manageability, interoperability, availability and testability as the 5 key attributes to design architecture
- Clearly define functional, non-functional requirements and integration points at the begining of the integration
 
Some of the challenges in integration architecture:
- uniform RAS (reliability, availability and serviceability)
- Ensuring each building block has predictable and well defined behavior in terms of timings/latencies, error codes, memory usage etc
- multiple vendor working together to resolve issues during development and in live network
 
Case study:
- One of the case given by Enea (enea.com) is how a deployable integrated architecture would look like where specialized processing engine (with DSP and NP running applications CODEC, IP forward or VLAN) can work with COTS hardware. This is a classic pattern in most of the telecom applications

Voice Delivery Platform

http://tringswitch.com/

An interesting concept proposed by TringMe where it allows an user to use voice service offered by different VoIP service providers. This service is built using the TringSwitch a platform for providing the web telephony. But in my opinion this platform is an ideal candidate for a “voice delivery platform”. This voice delivery platform is an integral element in the overall service delivery platform and would focus on the voice as a service in the all IP network (or IMS network). Having such a voice delivery platform would enable the operator to offer voice as a service from different Internet provider as well as offering their own premium voice service. Since such a platform offers operators to manage the VoIP services (even it can be made prepaid or pay-as-you-use service), this could be a platform that also provides access to their charging engines like 3GPP online charging system (OCS).

So here are the components in TringSwitch voice delivery platform (note the differentiation on whether a component is a mandatory or optional is not given by TringSwitch, this is my assumption. Also I have not considered telephony gateway component as this may be useful only if it is used as web telephony switch and not as a voice delivery platform)

 
Mandatory elements:
=-=-=-=-=-=-=-=-=-=
- Voice application server interface – interface to the voice application services that send voice over IM – both from Internet as well as operator’s own voice service
- Enablers (these can be just interfaces as operator would be already having these enablers) – TTS & ASR Engines, VXML Server, Voice Mail server
- Device rendering engines – flash server for connecting with the flash client on the mobile device

Optional components:
=-=-=-=-=-=-=-=-=-=-=
- Protocol components (mainly if some voice services are developed by 3rd party) – SIP for signaling and voice processing engine supporting various Codecs (G711, G723, G729, GSM etc). However it should also be possible to have access to the operator’s infrastructure elements like media gateways and in my opinion these components need not be part of the voice delivery platform
- Customer usage analytics and ad engine also their interfaces with external VAS enablers like SMSC

However I guess following components are also mandatory to be included as part of this voice delivery platform.
- QoS enforcing and monitoring element
- Identity federation i.e., single identity to log into multiple voice service accounts
- Interface to presence, location
- Interface for the operator’s IN/billing and OSS components
- Interface with OTA as device configuration will have to be managed for the voice services

Now when the operator wants to integrate the premium voice service offered by them, then it can either integrate using voice over IM or provide some kind of service brokering functionality to include operator’s voice AS.

Key Attributes in a Service Delivery Platform

Key attributes to be managed in the network which will be accessed by different services…
- Presence
- Identity
- Authorization
- Location
- Device capability
- Per application QoS
- Per subscriber QoS
- Security
- Service brokering

In order to use these attributes in a service delivery platform, the infrastructure should be:

- Application aware & Support service differentiation
- Deliver targetted service for subscriber based on usage pattern
- Faster & low cost application creation technology platform
- Integration of the open source platform

Need for Service Delivery Transformation

http://www.lightreading.com/servsoftware/details.asp?sku_id=2162&skuitem_itemid=1082

Two strands for the telecom transformation – business transformation – identification of new business models and making money and other is the infrastructure transformation which involves making changes to the network and IT infrastructure so that it is ready to support new business models. I guess identification of such new business models and identifying changes in the infrastructure would both drive the existing operator for the transformation whereas for the greenfield operator it is the identification of business model that would drive the decision for the infrastructure selection.

However the whole transformation started with development of the all-IP networks that brought out new service providers who were part of the Internet. This forced the telecom operators to sit-up and take a look at emulating the Internet business model  (i.e., a business model in which a network of different actors and their resources are linked together by the internet technology) to get share of revenue from IP services value chain. Now let me dissect the meaning of “Internet business model” for telecom service provider.

Business model is the product/services offered to creat revenue and hence value to the share holders. Now while doing so it should be cost effective and should provide differentiation with the competitors. Now for the telecom service providers, providing plain voice services is not the product/service. It should be providing always-on kind of link to connect with their work, friends & faimily, entertainment. Now how does this generate revenue; may be by becoming a trusted party who manages all the service providers providing different kind of service, providing a unified platform for storing their information, unified identity platform and offer flexibility for making payment. Since end user is getting the flexibility of anytime, anywhere access of these services, and is independent of devices, operator would have to collect for this service from the end user. To become cost effective, the service creation has to be flexible, get developed from internal/external developers to reduce cost of creation of service. To create competitive advantage, the service assurance and making the service available on any device from anywhere could be critical. Also close tracking of the consumer behavior and doing a targetted advertisement and upsaling of the other services could bring additional revenue. To handle the multiple service providers, have the business platform to support the required workflow and the charging – modification in the eTOM framework adopted?

For the service creation unified subscriber data view and service data view is essential where different services will have to be orchestrated to provide service to the end user. Since operator own the subscriber, orchestrating the service will become a critical service in their offering. In terms of services it should be able to offer independent of the access and things like voice call continuity and data call continuity between the access should become a reality. For voice operator can themselves offer the voice (with committed QoS) but also should allow other providers like Skype to offer the service.

Revenue model in this new world will have to be built around the affliate marketing model. In this model, a business rewards one or more affiliates for each customer brought about the affiliate’s marketing effort. But in the case of operator, this can be because customer using the service say from Google when compared to Microsoft. This model could also include the advertising to bring business for the other service providers operating using Internet. In this model operator can have a single web page which aggregates all other service provider. Then may be based on the content accessed (including Voice), it can be charged or a flat fee.

On the infrastructure side, since for each of the service providers the quality of service is delivered, the network infrastructure should be aware of the services (e.g., it should be able to give differential treatment based on the port, service type, URL etc).

Service Broker – Necessary component in SDP

http://www.stratus.com/download/index.cfm/pdf/telecom/CSB-white-paper.pdf

Subscriber expectation – have multiple services and multiple devices, so they expect to access any services & content from anywhere on any device. So having IP backbone is essential to achieve such a need. So it is essential to have converged routing, messaging, content and centralized subscriber profile information. This is nothing but having a unified service delivery platform catering to different networks. In this service delivery platform, Stratus network is focusing on creating a service broker which can mediate in a multi service, multi access and multi network environment.

Stratus service broker consists of two part. One is the signaling gateway that converts and handles different protocols and the other is a mobile call converge device which takes care of handling call and call handover  between different networks (like WiFi, Celluar, TDM etc); also it handles service interactions by connecting to external subscriber database lookup. Below is the architecture of this service broker.

 

Now this service broker would also provide an IDE to create relationship between the services and create service rules (in the same lines as business rule creation in an SOA environment). Service rules thus created will have to have a service rule execution environment similar to SLEE. But now will be the interaction between such a service rule engine and an independent service execution environment be handled? i.e., if there is already established legacy IN services and SIP application server, can the service rule engine work with this service broker. It is possible to achieve this only if the service broker can sit between the core network elements and the application servers (which is already proposed as SCIM in IMS architecture). But with all network service traffic hitting the service broker, it is essential for the service broker to make some kind of distiction whether the service requested by the end user is a straight forward one or has some interaction. So the transaction processing capability of service broker will have to be really good and should not introduce any additional delays. On the other hand, such service brokers would really help in avoiding the interoperability issues as it can have agreement with NEPs to support their proprietary protocols (INAP/CAP/SIP) and on the AS side it can publish its own protocol or can work as proxy/protocol coverter based on the actual need. Following is the architecture of the Stratus service broker solution.

 

SINAP – Stratus integrated network application platform
C-SLEE – converged SLEE

Interesting point to note here is the Stratus T series hardware. I wonder whether it an ATCA blade server built by Stratus. Overall I think this is a necessary component in the overall service delivery platform of an operator who is in the path of evolution to an IMS based network. And for the greenfield operators, this element could help them to explore the possiblity of using a shared application server either from an existing operator or use a hosted application server from the vendor.

Building Service Factory

How will it be if new telco product/service can automatically populate the data in the OSS/BSS applications (like customer relationship management, billing, order management and provisioning etc)? Because without this, now 60% of the cost of a new teleco product/service can be traced directly to the time and effort involved in plugging that product into the network operator’s OSS/BSS. So a central repository of the product data is essential.

Why now all of a sudden there is a focus on creating such a central repository to manage the service? This is due to the nature of the next generation service environment, where telcos will have to manage large number of services (as there is no killer service and hence operator will have to maintain long tail of services). So a factory kind of setup with the flexibility to create products from set of components is the need of the hour. Product data management system (PDM) suppose to help operator to build the automated service factory. Following table from Lightreading shows categories of PDM and their proponents.

 It is interesting to see why there are different approaches. One is from the OSS/BSS perspective i.e., vendors like Amdoc with their understanding of the BSS space, can easily identify and expose the information that they require from the new services. So for them it is a mere exposure of the product data that they expect from the service components.

Now for companies like Accenture, IBM, they should come out with a framework that can patch up the teleco products/services with the OSS/BSS. Because in many a instances operators can not just bring in new systems that supports the PDM way of managing the service. May be in case of IBM, it is bringing SOA into picture to gain more market traction. However it would be interesting to see how the PLM (product life cycle management) suites from Ceon and Tribold help in doing the portfolio management?

Service Delivery Platform

http://www.lightreading.com/servsoftware/document.asp?doc_id=141937

History repeats – was it just a cliche? Not according to the article ‘Beyond SDP: building service factory’. in 19th century industrial age the factory mode of manufacturing helped the industries to standardize manufacturing environment to quickly produce and reduce the waste. Now even in the telco environment the service providers are looking at creating standardized, interchangeable and interoperable elements in an environment where such elements can be used to create unique products. These service elements contain data/interfaces for create, provision, maintain and bill. This is nothing but the product data. Product data management system (PDSM) provides a 360 degree view of the product data from management perspective. But are there standards to create such a view? There should be some patterns (is it SOA?) which drive such product element design and help in decide the boundary for such products.

In the existing service delivery environment of the telcos, hundreds of services/products contain product data in a desperate manner. Dispersed nature of the product data is stalling time to market, stalling their ability to deploy complex products and prevent the reuse of products. So centralizing PDM is seen as the key to cost efficiencies, process automation and next genration service creation.

Now I need to find more details on what are the standards or the best practices that are available for the PDM and also its relationship with SOA. Need to find is there anything specific SOA patterns available for telecom? Also whether eTOM SID (shared information data) is nothing but the PDM? But with eTOM focusing on the operations, may be it will not define how the products inside the telecom service provider domain should look like.

Other thing to figure out is; relationship between SDP, BSS/OSS consolidation (or convergent billing) and how they impact each other. One thing that is obvious is – if the components or the products have to be created, provisioned, managed and billed, the OSS will have to take care of the first 3 parts and billing should be taken care by the BSS. Now if there is a conflict in the way these products function, then there has to be some orchestration mechanism built in the SDP that can resolve these conflicts before interacting with OSS/BSS.

However the article carries a table of the preintegrated SDP which is according to TMForum’s SDF (this needs to be checked). But looking at this table it appears that the SDP is the service creation and execution point, these services could be voice services, data services or content based services. But how about the add on functions like the management interface for managing the data in these services, subscriber data management, content storage/management, self service by the end user etc. Are they also considered to be services that can be generated from these service creation environments?