Thanks Matt We have heard a lot about the network infrastructure and how it can be used to help make Cable 3.0 work, I’d like to talk about some of the OSS architectures that I think MSOs need to be implementing in order to realize their position in this potential new value chain as well as providing the ability to deal with the next generation of blended, on-demand services Tom talked in his opening remarks about potential futures for MSOs – being pipe or integrator. In previous presentations, Jack and Steve talked about Web2.0 and compelling applications and the idea of “blending” or mashing up services and how third parties will play an important role in delivering the next generation of applications. We will see that MSOs have the opportunity in this environment to participate in this next generation of applications and services, monetizing the enablers they provide and making them available to a larger development community We will see that a common infrastructure will allow the development of compelling applications and services both from in house development and that done by third party developers
Today, MSOs are currently offering primarily subscription-based services with some on-demand video and content. This is about to change as advancements in network intelligence, the flexibility of all-IP networks and multi-media enabled consumer devices offer an unprecedented opportunity for service and application innovation. Cable services are moving toward a real-time, on-demand mode where service and application delivery will be composed of intelligent transactions that are conducted in milliseconds and governed by specific policies, rules, and information. Some of these services will come from the MSO, while others may be mash-ups of MSO capabilities, partner content, and user preferences. Many of these services will also cross traditional network domains, pulling together the television, mobile and Internet experiences, and will require a much more rapid creation and enablement model than in the past. Whether generating new types of services from their own technology base, or combining MSO services with those of third parties, MSOs will require new service management capabilities that support the real time transactional environment; can integrate with traditional OSS/BSS functions; and that allow internal groups and third parties to create, mash-up and onboard new services into the MSO’s service environment simply and rapidly.
For these new on-demand, dynamic, session-based services, the nature of the service will be modified or will evolve on a real-time basis during a communication session, and include converged or blended services that offer inter-working between voice, data and video. These new classes of services and applications bring an “order it now” paradigm that shortens the “order to consumption” cycle to seconds versus days in the previous subscription-based model. In order to support this new world, MSOs need to take the capabilities that exist in their “back office” OSS layer and extend these capabilities and intelligence to applications at the network edge. This will drive the need for a re-definition of how we currently think about OSS systems. In the real-time environment, services are “on-call” for deployment to any accessible end point. Policy execution based on the subscriber profile, device, and session parameters will drive decisions about service delivery. Each time a subscriber invokes a new service, a series of real-time transactions must take place to authorize the user, validate their permissions/entitlements and service profiles, ensure appropriate network topology and device capabilities, deliver the service and trigger billing. This is a definition of policy that is larger than just what the network can support and policy decisions based just on network capabilities Providing the key information to drive these policies is a federated model of the subscriber – including not only the standard type of information that we are used to, but demographic information MSOs cannot afford to invent new silos for each of these new types of applications – they need to ensure that this information is available based on a common model and interfaces that are available to all applications using the appropriate standards. Steve talked a lot about some very specific interfaces to provide this information
The rise of Web2.0 technology opens up a new range of partners for MSOs. In previous presentations, Jack and Jason talked about this idea of 2.0 mash ups and UGC. Steve talked about the compelling applications These partners are small third party developers, or even the MSO’s customers themselves. They are generating not only their own content, but their own applications – wanting to mash-up their own special content, and applications with the fundamental components MSOs can provide – everything from networks and capabilities like presence and location to billing. Web2.0 applications have become a success because the power of application creation can be put in the hands of a less sophisticated user. Ability to use the MSO’s infrastructure to make a call from their own application, send a SMS, or even have access to appropriate, anonymous subscriber or demographic data to target offerings The panel before talked about the deconstructing the components of the set top – what about deconstructing the capabilities of the network and the back office ? Talked about virtual worlds – I can’t remember the Telco operator that did it, but provided the equivalent of phone booths in Second Life As evidenced by the success of Facebook and Google Maps-based mash ups, these users understand the idea of simplified, Web Services and SOA-type APIs. They will have less knowledge of the intricacies of the telecom environment; they may not want to have to understand the IMS Ro or Sh interfaces, for example. These new partners bring new revenue and customer retention opportunities for the MSOs. They now have the opportunity to monetize their infrastructure in a much more dynamic way, actually charging for this access, or having advertising subsidize these applications This includes engaging with their business customers in a way they could not before. Enabling the IT department of a company to create an application that can allow click to call, or use their current location to identify an opportunistic sales call, can be a powerful retention tool. The number of these new partners could be vast, and in order to cost-effectively “sign up” all these partners, MSOs will need the appropriate infrastructure to on-board the partners, defining what components they wish to access, service level agreements, policies, and settlement infrastructure in a repeatable, automated manner.
In the traditional OSS role, the goal has always been, and continues to be the ability to package these capabilities and be able to offer them to customers as rapidly as possible. This packaging needs to include the ability to describe the service and application access not only across the “back office”, but also through these new models that exist. This is the process for in-house generated applications and services – and indeed, even for these services
We could see is the potential an explosion of silos for all of these types of applications, whether developed in house or not. At the bottom are all the enablers that these types of blended applications need to access. Each silo with its own model of the subscriber, entitlement, device capability, and charging. While network architectures like PacketCable 2.0 and its IMS-based infrastructures support this concept, the issue will be the implementation as operators evolve towards these standards-based architectures. I think third party developers will not want to develop their own infrastructure for their own applications.
What we need are a series of interfaces that allow common, controlled access to these capabilities that can be utilized by all types of services and applications. At the bottom the enablers that can be accessed, then what I’m calling “OSS at the edge” – an api layer that implements appropriate subscriber policies and On top of this you can consider another layer of partner and access control – how an operator will be able to manage these partner relationships and how they access the apis and capabilities covered by the OSS at the Edge layer
OSS in the “delivery path” of the service Providing the interface to allow access to these enablers – how to charge for a session, how to request improved QoS, how to get access to the enablers, how to get access to the subscriber model Really three components: Access to the enablers Access to a federated, unified subscriber model – supporting features such as anonomyzing, providing controlled access A Policy/intelligence layer where the relations between subscriber, service and device reside and can be used to control the behaviour of these applications A capability to fulfill these policy decisions KK talked about the MSO intelligence layer that is required to make these applications go and charge for them. But it needs Although we talk about real time needs, this layer and decision making capability can be used for non-real time applications as well. I believe that one could map the very specific application defined by Rich in the talk following me across this generic model and see how the concept of intelligent policy across services can drive decisions in both the real time and non-real time environments. We talked a lot about advanced advertising in this conference – I encourage you to think about advanced advertising as an application accessing this infrastructure – the information to support the DVS 629 Subscriber Interface would come from this infrastructure. I think if operators begin to look at their internal and trusted partner applications as just a specific type of partner application, they can reuse this architecture seamlessly
Conceptually, one can think of a Partner and access control layer sitting on top of this. We talked about a world where the number of partner developers could skyrocket. These partners are going to require appropriate (Webservices), simplified APIs to allow them to write apps utilizing the enablers provided by MSOs. However, MSOs will need to provide the appropriate safeguards to protect not only their network, but user and operator data control. Here is where applications could be identified as trusted, control what enablers they can access, what type of charging can be used, what categories of subscriber information they have access to. With a potential large number of partners, there will need to be partner management interfaces that could facilitate automated on-boarding – picture a web portal where a development partner can come, identify their application, maybe select from predefined packages controlling what type of access their application woulld like – what type of QoS they would require, if they want the ability to send SMSes or instant messages, and how many such messages they are allowed to send in a particular period, and how the pricing and settlement will be agreed for such access. Cable has a unique opportunity where they can take the spirit of initiatives like tru2way, and its concept of building a developer community by providing common apis into the set-top and device, and extend it to a set of apis that allow access to the MSOs enablers, network capabilities, charging functions, etc that provide a safe, secure and revenue generating environment.
We see this new environment driving new requirements for the OSS layer New types of on-demand and blended services New partners and interactions Key to realizing this value will be the ability for operators to implement and integrate not only the traditional models of OSS, but these future “edge” components to allow them to compete and define their place in the new value chain
1. OSS at the Edge for Service and Application Enablement <ul><li>Brian Cappellani </li></ul><ul><li>CTO </li></ul><ul><li>Sigma System </li></ul>
2. The Evolution of Services <ul><li>The service delivery paradigm is changing… </li></ul><ul><li>Future service offerings will be defined by a different set of characteristics: </li></ul><ul><ul><li>Greater numbers of services </li></ul></ul><ul><ul><li>Shorter service lifecycles </li></ul></ul><ul><ul><li>Personalized : “niche driven” and user-controlled </li></ul></ul><ul><ul><li>On-demand, real-time and session based </li></ul></ul><ul><ul><li>“ Blended” - Delivered across multiple access technologies </li></ul></ul>
3. Service and Application Needs <ul><li>Need not just “VoD”, but “XoD” </li></ul><ul><li>Common Model and Interfaces for: </li></ul><ul><ul><li>Authentication, Authorization and Subscriber Entitlements </li></ul></ul><ul><ul><li>Business Rule based Orchestration/Coordination of Subscriber information and policy </li></ul></ul><ul><ul><li>Ability to access/utilize key network capabilities or enablers such as QoS, presence, etc </li></ul></ul><ul><ul><li>Billing, Payment, key demographic information </li></ul></ul><ul><li>Similar requirements to existing OSS, but to support the application session </li></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Subscriber Information Federation </li></ul></ul><ul><ul><li>SOA </li></ul></ul>
4. Partners and Third Party Application Developers <ul><li>Different types of application developers </li></ul><ul><ul><li>Traditional, “in house” </li></ul></ul><ul><ul><li>“ Web 2.0” Mash-Ups </li></ul></ul><ul><ul><ul><li>Customers themselves – UGC, UGA </li></ul></ul></ul><ul><li>Different characteristics </li></ul><ul><ul><li>Level of trust, access </li></ul></ul><ul><ul><li>Level of telecom knowledge </li></ul></ul><ul><ul><li>Revenue opportunities </li></ul></ul><ul><ul><li>Speed of “on boarding” </li></ul></ul>
5. Traditional OSS Role <ul><li>Define & re-use service & application building blocks </li></ul><ul><li>Assemble blended application bundles </li></ul><ul><li>Make services portable to multiple network and consumer domains </li></ul><ul><li>Integrated orchestration of business rules, policies, entitlements and device/network qualification to network-facing elements and repositories to support service/application execution </li></ul>Increase Velocity of Service/Application Introduction Telecom IT Enabler Building Blocks New Services Months/Years Days/Weeks
6. What we could end up with
7. What we need
8. OSS at the Edge <ul><li>OSS in the “delivery path” of the service </li></ul><ul><ul><li>Subscriber information, business rules and policy decisions are orchestrated in real-time </li></ul></ul><ul><ul><li>Integration of SDPs and 3 rd party applications delivery </li></ul></ul><ul><ul><li>Access to key enablers and information </li></ul></ul><ul><li>Subscriber policies are modeled across service lines – not limited by silo or application </li></ul><ul><li>Subscriber policy execution includes mix of subscriber entitlements, network and device </li></ul><ul><ul><li>Subscriber-centric, federated information model with appropriate business rules </li></ul></ul><ul><ul><li>Infrastructure APIs with appropriate level of service abstraction </li></ul></ul><ul><ul><li>Ability to reuse existing systems in SOA-based environment </li></ul></ul><ul><li>Providing “5 Nines” of On-Demand Reliability </li></ul>
9. Partner and Access Control Layer <ul><li>Authentication </li></ul><ul><li>Security </li></ul><ul><li>User and Operator data protection </li></ul><ul><li>Partner-based Policies for </li></ul><ul><ul><li>Access and Use </li></ul></ul><ul><ul><li>SLA </li></ul></ul><ul><ul><li>Settlement, Reporting </li></ul></ul><ul><li>Appropriate, simplified APIs </li></ul><ul><li>Partner Management interfaces </li></ul><ul><ul><li>Automated on-boarding </li></ul></ul>
10. In Summary <ul><li>New requirements for OSS driven by: </li></ul><ul><ul><li>New on-demand services and applications </li></ul></ul><ul><ul><li>New partners and interactions </li></ul></ul><ul><li>Key to realizing the value of this environment will be OSS that can deliver both current “back office” and future “edge” requirements in an integrated fashion </li></ul>