On Demand Service Fulfillment - Driving OSS to the Edge
•Télécharger en tant que PPT, PDF•
0 j'aime•756 vues
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (11)
Similaire à On Demand Service Fulfillment - Driving OSS to the Edge
Similaire à On Demand Service Fulfillment - Driving OSS to the Edge (20)
Dernier
Dernier (20)
On Demand Service Fulfillment - Driving OSS to the Edge
- 1. On Demand Service Fulfillment - Driving OSS to the Edge - Preston Gilmer, VP of Product Marketing Sigma Systems
- 9. OSS at the Edge - Architecture Network Elements / App Servers Presence Location QoS / PCMM / Network Policy Billing / Charging Device Capability Traditional OSS In House App 1 In House App 2 Partner App 1 Partner App 2 Subscriber Repositories Partner & Access Control Layer Partner Mgmt OSS at the Edge
- 15. SCTE 130 - SIS System Interactions
- 16. Advanced Advertising – Tru2Way & SCTE 130
- 20. Thank You Preston Gilmer, VP of Product Mktg. Sigma Systems [email_address]
Notes de l'éditeur
- Next slides will show 2 options : Use advertising, or Look for other sources of revenue – try to monetize the enablers, including customer info
- Traditional really means just try ad-supported services, including having an advertiser partner “sponsor” a service – The New Model refers to exposing customer information to allow partners to target their own advertising – which is really an example of the next slide – enabling 3 rd parties
- Looking for new sources of revenue, and realizing that to get cool new apps to market means that operators need to look at this model. It doesn’t eliminate their current, mass-market offerings, but in order to take advantage of more niche offerings. Also, it is more likely that commercial customers will perhaps build apps to do this – so having this type of integration with your commercial customer’s applications will make them much less likely to churn based on price. Called the “2 sided business model” by Telco2.0 thought there was $250B in doing this, but they talk about operators providing very detailed & interesting services, including “ensure customer is home” for delivery services
- Try to play this as the evolution of OSS. My message is around the value proposition of trying to do this in an integrated manner: Don’t create new silos, where trying to bring on a new partner requires configuration across multiple systems. Trying to say “don’t make the same mistakes” as originally happened in the back office, with silos and lack of an integrated model. Need to convince people that just putting together best of breed without overriding control is not the way to go.
- Federated access and control to network capabilities and service enablers
- Partner Access & Control Layer – the standardized APIs and interfaces to access subscriber profiles, network capabilities, authorization and entitlement procedures, etc OSS at the Edge – extending well beyond network & device level provisioning & activation
- Subscriber information, business rules and policy decisions are available in real-time Integration of SDPs and 3 rd party applications delivery Access to key enablers and information Event Handling and fulfillment Subscriber-centric, federated information model with appropriate business rules Infrastructure APIs with appropriate level of service abstraction Ability to reuse existing systems in SOA-based environment
- Here is where you can talk about the partner-driven policy on top. Want to say that operators should try to use this same paradigm for internal applications – British Telecom is trying to do this with its 21 st century API. If operators are able to generate such an eco-system, you will want to automate the on-boarding – e.g. partner goes to a website, maybe downloads the API docs, sample client, etc and signs up for a “package” of what access they want – what type of subscriber information, how many SMS call, etc, and can have it all fulfilled automatically.
- Linear advertising can become more targeted by using dynamic ad insertion at the headend or node (to target geographical zones), or at the STB which can be used to select the appropriate ad from multiple simultaneous ad channels, or from ads that have been downloaded to a STB’s DVR. Additionally overlay graphics can also be used to provide localization and targeting. Unicast advertising opportunities such as VoD and SDV provide unique opportunities for targeting as they can take advantage of the information known about the individual subscriber versus an aggregated profile of a neighborhood. Additionally, new electronic program guide capabilities, as well as bound and unbound tru2way applications, should open the door to new types of ad and branding placements. For example, the opportunity to place targeted ads in the EPG screens, including the ability to press a button for more information or a telescoping ad. Another example is the ability to place interactive ads in video programs (via bound applications) that provide the viewer the ability to interact with the ad to request information to be sent, or to watch a telescope ad which provides more detail on the product or service. This ability to interact with the viewer has high value to advertisers.
- SIS reuses many assets of existing Subscriber Management, OSS and BSS systems Service Management Solutions define the current services (voice, video, hsd, wireless) the subscriber is entitled to a history of previous service requests The CPE capabilities service the subscriber The network capabilities serving the subscriber Geographical Information Systems (GIS) provide the subscriber’s geographical location and proximity to local information Customer Relationship Systems (CRM) and Trouble Ticketing applications provide Detailed Subscriber, past calls or concerns SIS also complements that data with new information Demographics Augment subscriber data with other household ‘cohort’ data including household spending levels, income, and other demographic data. Viewing history for those users to define their interests, habits and behaviors
- Perhaps the first example of how such an architecture could be defined. SCTE 130 describes how subscriber info (SIS) can be used by Ad Decision Servers (ADS) to insert an ad on request by an Ad Decision Manager (ADM). The SIS provides the sub information as a list of Audience Qualifiers. Note that there can be multiple ADSes – either the content owner or the MSO can have responsibility for inserting the ads. OCAP/tru2way now provides the ability to capture how viewers are interacting with the content – what shows were watched, how long viewed an ad, etc through IPDR records. The coordination of the actual viewer information to enrich the subscriber profile – ie did the user respond to such an ad – can use that to perhaps ensure that you don’t show the same ad again if it was not successful. Addition of policy and partner control allows ADS from content owners to get either more or less “deep” information (ie more or fewer audience qualifiers) based on the agreement between the MSO and the content owner. If an advertiser/content owner wanted a “deeper” set of information to guarantee a better targeting decision, they would have to pay for that – e.g. get Audience Qualifiers 1,2,3, while the other ADS only got 4 and 5 since they didn’t pay as much.
- Doesn't IMS or SOA solve this problem ? While SOA provides the likely architecture in which to expose the services, and the likely way for services to communicate it does not address the need to coordination definitions of policy and rules across all the applications IMS also provides an architecture around which services will operate, but again, does not define how the configuration gets expressed across all these different components. Nor the ability to rapidly create agreements with partners OMA OSE talks about how to expose enablers, and the concept of policy-based control IPSphere talks about how to create the interfaces for a marketplace of pan-operator services TMF SDF is also working on the OSS implications of such exposed capabilities
- 1) Can a large enough developer community be built around these concepts ? - need to have standards for these interfaces adopted by a large enough number of providers to allow developers to write their applications - service providers should be looking for their own applications to leverage these interfaces - BTs 21st century API ? 2) Can service providers deliver enough "customers" for this application development community ? - who will create a larger market place - is there a need for a wholesaler/aggregator of these services across larger markets than just a single service provider - e.g. Canoe in Cable - ability to offer US wide advertising opportunities IPSphere defining how you can have pan-operator offerings 3) Can the "integration tax" for expressing this information across all these systems be overcome ? - Common models needed in order to make the process of defining a new partner across this architecture 4) Customer privacy - need to ensure ability for customer to opt-in - service providers need to ensure that information is appropriately "anonymous”