Service exposure: innovating for growth in asset profitability

Transcription

1 The communications technology journal since 1924 Service exposure: innovating for growth in asset profitability June 19,

2 Open the window to your assets 2 Service exposure: innovating for growth in asset profitability Just a couple of years ago, the concept of allowing third-party access to operator assets was practically unheard of in the telecom industry. Today, the picture is quite different. Service exposure is about to create a whole new set of business possibilities for operators, developers and content providers. ULF OLSSON, MATS PERSSON AND CLAES CEGRELL Service exposure, sometimes referred to as network exposure or capabilities exposure, is attracting considerable attention, both inside and outside the operator community. Operators are creating a new ecosystem by building and developing proof-of-concept solutions that include components provided by both traditional vendors and companies active in the space between the traditional operator and web developers. The business case for serviceexposure solutions has yet to be proven conclusively. However, operators seem to be investing in the idea as part of their strategy to meet over-the-top (OTT) players with a view to cooperation placing themselves in the OTT value chain so they can provide more than just IP connectivity. Exposing assets through APIs is nothing new. Some operators have been doing this for a number of years, BOX A Terms and abbreviations 3PP API third-party provider application programming interface ASN.1 Abstract Syntax Notation One B2B2C business-to-business-toconsumer HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDE Integrated Development Environment M2M machine-to-machine OSS/ operations and business BSS support systems exposing assets through solutions customized for individual capabilities mainly for messaging, payment and location-based services. Some initiatives have been taken to standardize service-exposure methods, with early developments based on Parlay and Parlay X, and later developments in the form of GSMA OneAPI and WAC. But so far, these initiatives have had only a limited degree of success. The connected marketplace of the Networked Society brings with it the next generation of unified API exposure solutions. In this environment, operators are keen to find new revenue streams and move up in the value chain from being suppliers of communications and connectivity services to being business partners and enablers. Next-generation service exposure transforms traditional capabilities into combinations of APIs with embedded business logic relating to the context of subscribers their apps, devices and service provider. In the marketplace formed by the players providing these OTT over-the-top PaaS platform as a service PHP PHP: HyperText Preprocessor REST Representational State Transfer SDK software development kit SLA Service Level Agreement SMSC Short Message Service Center SOAP simple object access protocol WAC Wholesale Applications Community XML Extensible Markup Language XSD XML Schema Definition capabilities, assets are made available for revenue generation. These assets include network policy control rules, network and subscriber data, OSS/ BSS capabilities (such as subscription management, order management and assurance), M2M device information and enterprise information. Where s the money? Ericsson s experience in talking with operators indicates that the incentive to invest in exposure solutions is not based on the exposure of single APIs. Instead, the main incentive to invest is likely to come from the establishment of a service-exposure platform, stimulating revenue generation through a fully-fledged portfolio of services based on combined capabilities. A secondary incentive for investment lies in the stickiness of a serviceexposure platform, the goal of which is to ensure that developers find it usable, reusable and convenient supporting revenue generation. As illustrated by Figure 1, this article outlines how, within their particular context, every player can establish an active role in the broader context of the Networked Society. Who will benefit from service exposure? The players in the service-exposure landscape include: the network provides a selection of the capabilities created by the operator, including bundled capabilities from partners; the users need products and services and provide the motivation for enriching the application experience;

3 3 the developer creates services and applications; could be an independent software vendor, a long-tail developer, or a service developer working for the operator; and the service provider hosts and executes the server-side part of applications built by developers. FIGURE 1 The players in context Service user (consumer, corporate, cloud...) Developer (internal or independent) Their roles can be matched with business relationships in several ways. For example, the developer could be employed by the service provider, or may simply resell software licenses. In some cases, the operator can also be the service provider. APIs Design Deploy Code Execution scenarios Applications tend to be divided into two parts: one running on the device and the other residing on a server somewhere on the internet. Traditionally, the device-side component is an installed piece of software (an app), but today this function is more often implemented in the form of JavaScript downloaded as needed. Given the broad range of technologies available, execution scenarios can become quite complex. But it is, to a large degree, this flexibility that has led to the rapid and creative development of the web domain. What is service exposure? The Ericsson concept of service exposure is about making it possible for the players in the Networked Society to access operator assets easily and in a way that generates revenue for all parties. By making assets (including ecosystem support such as documentation, SDKs and test environments) available to developers, enterprises and service providers, new applications, bundles, products and services can be created to support many different business models and user needs as they continue to evolve. Through exposure, operators can provide additional value to service providers, enhancing their offerings in terms of quality of experience, functionality and convenience. In essence, this is the operator response to the web phenomenon of collaborative, API-driven development. By exposing its assets, the operator will be recognized as a partner, and a partner that simplifies the job of developers and provides value to the service provider. The architecture Figure 2 illustrates a simple architecture for exposing services. The design features a clear line of separation between service exposure (the act of providing a service, paid or not) and exposable services (the capabilities that network elements can provide). The architecture illustrates that consumers of services vary greatly: from users buying communication, content and applications, to service providers buying communication and connectivity wholesale, to enterprise verticals incorporating operator capabilities into their business support solutions. The Developer reach box represents the environments typically used by developers. To implement this architecture, the interfaces to this box need to be closely integrated with the environments typically used by developers today. Some operators will provide these interfaces with the help of vendors like Ericsson. Additional support is provided through a number of Execute Protocols Service provider developer communities for specific device platforms communities that are moving towards the use of toolkits that provide code portability across device platforms. Integrating operator capabilities into such environments is potentially a powerful way to put operator assets into the developer s preferred set of tools. Phrased slightly differently, with service exposure the same technology base can be used to support a number of different business models: B2C exposure of operator assets to users and enterprises that are part of a retail business model; B2B exposure of operator assets (typically traditional operator capabilities) to enterprises and service providers for business purposes; and B2B2C exposure of assets (mainly a combination of capabilities) that can provide value to the consumers of products and services created by enterprises and service providers. A few examples of relevant capabilities are shown just below Exposable services in Figure 2. This is not an exhaustive list by any means; other services

4 Open the window to your assets 4 FIGURE 2 Simple architecture for asset exposure Consumers/retail Communication Connectivity that are openly available on the web or implemented by partners could also be included here. The service exposure architecture works on the key principle that each node (or subsystem) delivering a capability operates as a black box keeping its inner structure hidden (protected). Whatever functionality or asset the subsystem provides access to is strictly controlled and defined by the node designers who in turn provide developers with a conceptual model of the system s domain of operation. For example, the exposed interfaces of a Short Message Service Center (SMSC), would support short messaging, and expose assets such as subscriber phone numbers, time stamps and delivery receipts. The main focus of the rest of this article is the group of functions hidden inside the Service enablement box. These functions provide the operator with the means to turn internal capabilities into external assets. Guiding principles The dashed red line in Figure 3 Service providers Developer reach Service enablement Content and data M2M Enterprise verticals 3PP indicates two possible types of endpoints: a device carried by a user (a consumer or an employee of an enterprise) for the main purpose of interaction with that person; or a server somewhere in the network that can host those parts of an application that for reasons of performance or trust are best kept network-based. Device-side applications are not necessarily user oriented (automatic data collection, for example), and server-side applications may well represent a user in a business-to-consumer scenario the on-behalf model. Consider, for example, a Facebook application that uses location information to connect friends in the same geographical area assuming that the appropriate privileges have been granted. The technologies that are involved in this type of application are converging towards the web: using HTTP and secure HTTP for transport, and HTML moving towards HTML5 for content delivered over REST interfaces, with traditional web services still being used, for example, in the B2B world. Service exposure Exposable services Using these protocols, which are also the tools used by traditional web developers, for content and transport brings an application beyond the constraints of a browser-based user experience, while still benefiting from emerging web technologies and services. Whatever services or assets are opened up to the developer data access, messaging, call setup or policy requests they need to be simple, clean and relevant. The actual service down in the network is typically complex, but developers rarely need such low-level implementation details; this frees them up to spend their time on solving the problem the application is designed to address. The dashed lines in Figure 3 separate the developer s world from the internal workings of the network and its assets. In deployment, the interfaces between the two are implemented as protocols for system integrators and as APIs for programmers. Protocols tend to be specified in formal notation such as ASN.1, SOAP/ XML or XSD. These specifications define the full set of messages that can be exchanged between end points, a description of the protocol state machines and the valid set of signaling sequences. API libraries, on the other hand, contain the routines, data structures and variables needed to translate a function call into the correct protocol messages. Simple libraries perform just the language binding to say Java, C++, C#, Python, PHP, Ruby and ECMAScript. More complex libraries will also provide client-side state machines, sparing programmers the trouble. Referring back to Figure 1, developers work with APIs in their integrated development environments (IDEs); and service providers see protocol messages on the links that connect the deployed system components. Interface control The first layer of protection is reached by drilling down another level, to the area enclosed by the dashed lines in Figure 3. In general, the provider and the consumer of a service belong to different trust domains, where the obligations of each party are defined by a mutually agreed contract.

5 5 As the operator s primary revenuegenerating engine, it is vital to ensure that network interfaces are protected and the reliable operation of the network is not jeopardized by external activity that could be unintentionally or even intentionally harmful. Application developers are experts in their respective domains, and they may not necessarily be as well versed in the finer points of communications network architecture and indeed they should not need to be telecom experts on top of everything else. The interface control component provides the functionality needed to protect the integrity of the network, such as authentication, authorization and SLA monitoring. It also provides protocol adaptation for service users (server or client based). By properly applying the architectural principle of separating semantics (what a service actually does) from syntax (how it is formally presented), it is possible to ensure that the selection of a protocol is no longer the most critical issue when providing an exposed service. Implementing a new protocol is a lot easier than designing a new service, and this can be achieved with relatively little effort. Service adaptation Located at the heart of service enablement, this component executes business logic such as transaction handling, charging, adaptation logic and servicespecific SLA enforcement. It contains a range of functions that filter out irrelevant or potentially damaging service usage. This component aggregates individual services into higher-order ones, which might appear to be simple on the outside (the whole point of service exposure) but in reality they can be quite complex as they may depend on several internal components. Service adaptation enables the critical ability to groom services to what developers want, substantially reducing the amount of information needed to understand and start using a capability a factor essential to facilitating the acceptance of the exposed service by developer communities. To make it easy and efficient to build business logic, this layer is constructed as a framework that supports many FIGURE 3 The moving parts Web based Classical 3GPP clients Web based Communication Service adaption Connectivity Interface control implementation technologies including plain Java objects, Enterprise Java Beans and service compositions. Network adaptation This component sits underneath service adaptation and provides the functionality to encapsulate the protocols provided by network equipment. In an ideal world, all network nodes would provide web-service interfaces that are well-defined, formally specified and discoverable. However, due to the need to interface with legacy systems as well as the need to manage potential issues created by multi-vendor solutions, the network-adaptation layer contains the code to normalize formats so that higher layers can treat all sources efficiently. In the long term, as legacy systems are phased out and standards begin to emerge, the need for this type of network adaptation will diminish. But for the time being, this component contains the format and protocol converters as well as the framework into which they fit. Network adaption Service enablement Content and data Business management M2M Service exposure Exposable services 3PP Business management This component handles the vital capability of signing up the users service providers in this case that will use the exposed services and have a commercial relationship with the operator. The component provides the ability to charge or share revenue with service providers, as well as other aspects of maintaining the business relationship including usage statistics, deeper analytics, mobility patterns and management of service subscriptions and SLAs. A significant element of this component is the set of portals that provide support to both service providers and users to help get them up and running with new services. This is a vital function, as self-service capabilities are an essential part of maintaining minimal operational costs. The business management component takes care of a number of essential commercial objects including user subscriptions, partner (developers and service providers) contracts and other business agreements. It is a flexible integration component to back-end service fulfillment and settlement

6 Open the window to your assets 6 FIGURE 4 1 A Management versus traffic execution Context RAN 1. A user clicks call specialist on a web page or app. 2. The server issues a conditional call setup. 3. Service adaptation queries the position, skills database and presence functions. It contains contract templates that create the business logic and traffic execution policy settings in the interface control and service adaptation functions. Putting it all into context The architecture illustrated in Figure 3 might indicate that the set of network capabilities which feed into service enablement could be anything that the network can produce. This is, however, not the case. Service exposure is not about opening up everything to every app; strict control needs to be maintained over what services are available and who or what can access them. Consequently, even though the architecture described in this article provides the technical basis for doing (almost) anything, there are business 3 2 Servic daption Interface control Network adaption Service enablement 4 Core 5 Business man gement Fixed information to determine the best responder. 4. The two parties are connected. 5. The call is charged to the external company. decisions that have to be made relating to what is actually exposed, to whom, to what extent, how fast and at what price. These decisions are taken on a variety of levels: vendor, system integrator, operator and partner enforced by all of the service-enablement components: interface control, service adaptation, network adaptation and business management. Use cases Architectures such as the one discussed above are theoretical descriptions, forming the basis for understanding. However, use cases that show the theory in application can be helpful. Smart customer support Consider an operator that provides a platform-as-a-service (PaaS) offering Service exposure B for retail businesses. The PaaS includes functions such as employee presence information, store inventory management and back-office integration. It also supports call-forwarding and this service can, for example, be invoked by a user browsing the retailer s online store. The steps involved in this scenario are illustrated in Figure 4. The user is window-shopping, using their smartphone browser or app, on the website of their favorite retail store and wants some additional information relating to a product. The user wants to talk to someone, so they click on the call specialist button provided by the application. This action is caught and processed in the user s device by way of a JavaScript procedure that sends a message to the server (1). This message contains the additional context information related to the call. The server uses an exposed service (2), which essentially requests a call setup without specifying a number for the recipient of the call. The aim of the business logic in service adaptation (3) is to find the best responder for the user. It achieves this by first issuing a location query; stores that are physically close to the caller will be given preference. The best responder is selected based on availability information in the presence database and skills from the personnel database. The call is then set up with the best responder (4), who is automatically provided with the context of the user query. The final step in this use case is the generation of charging information (5). All costs are billed to the retail enterprise and the caller pays for nothing. The contract between the operator and the retail enterprise will determine the finer billing details. Service enablement contributes the machinery that makes it easy for the operator to provide an adaptable set of services. Enhancing content delivery Another scenario, illustrated in Figure 5, shows how to enhance interaction with an OTT content provider and delivery of the content. Looking closer at the details of this scenario, a user wants to watch a video, with the highest possible quality on a mobile phone. The user browses the content

7 7 provider s website and chooses a video (1). To enable and enhance video delivery the operator offers a set of exposed services to the content provider, where each service is bound by a previously agreed business contract between the two parties. To identify the user, the content provider uses the identity management function provided by the operator (2). However, to access this service (or anything else) in the first place, the content provider must be authenticated and authorized by the service enablement interface-control component. This component performs an SLA check to ensure that the content provider s application does not violate business agreements. The network adaptation function converts the request from the content provider to the protocol used to connect with the network enabler handling user data. Next, the content provider requests information about the user s subscription and current capabilities of the network (3). The service adaptation function gathers relevant contextual information about the user from several sources in the network and presents this as one combined result to the content provider. Based on the user s subscription data and current and network information, the content provider offers the user a number of customized viewing options such as a free low-quality version and a premium one (4). The user selects the premium version (5), the application requests enhanced streaming QoS from the operator, and in turn service adaptation converts the simplified QoS request parameters for the application into detailed ones used by the policy and control function in the network (6). Finally, streaming starts (7). Once the content is delivered, the content provider uses the operator s payment service to charge for the video session to the user s account (8). This use case can be varied in many ways. The key aspect to all variations is that the third party is provided with the capability to programmatically influence how content is delivered, while the operator maintains full control over policy definition and execution. FIGURE 5 Enhancing OTT content delivery A 2 User data RAN 1. A user wants to watch a video offered by a content provider; the user browses a content provider s website and selects a video. 2. The content-provider server verifies the user s identity through their operator. 3. Once verified, the contentprovider server requests the user s subscription and network capabilities: service adaptation then requests relevant contextual Service adaption 3 7 Interface control Other use cases There are many potential ways of making the most of services through exposure. In a sense, the whole point of service exposure is to build a framework that will then be used to build new services and applications by bringing existing ones together in a way that is difficult to predict. Some examples include: communication services presented in a WebRTC-enabled browser (as demonstrated at the Mobile World Congress ); in a variant on the case illustrated in Network adaption Service enablement Context Business 8 man gement information about the user from several sources in the network. 4. The content provider presents several quality alternatives to the user. 5. The user selects the premium version. 6. The content provider server requests enhanced QoS for streaming from the operator for this user. 7. Streaming starts. 8. The operator charges the user s account. Service exposure 6 Policy control Core Figure 5, the QoS change can be triggered by detection of a specific flow (implicit service exposure); identity management (and federation): information exposure based on networkderived data (for example, collective behavior such as vehicle traffic); and the classics location, messaging and payment services. Extended scope of service enablement To expose services, a number of capabilities need to be implemented; everything from describing what users

8 Open the window to your assets 8 need to do to use a service (documentation) to having the right policy enforcement in place to ensure that a service is not misused. This article has focused on the generic parts of service exposure architecture; however, the full scope of what Ericsson refers to as service enablement encompasses additional capabilities, such as functions for customizing and personalizing consumer experience, partner setup and M2M application enablement. Service exposure: looking ahead Having described the machinery that can enable service exposure, it is vital to repeat the point that a top-down approach is key when defining what assets to expose. Success will depend on providing the interfaces that developers need to do their job and make their job easier. Become the developer s best friend, meet them where they work in their development environments and present capabilities in such a way that can be quickly understood, tested and integrated. One of the primary motivations for developing service exposure is to support enterprises and service providers as they constantly widen their business reach and at the same time need to keep the user experience in line with expectations. In particular, this includes making the enterprise mobile supporting mobile users and providing the employees with an efficient mobile working environment. Service exposure should initially be steered according to what capabilities can be derived and synthesized from the traditional operator resources of connectivity, communication, mobility, charging and billing, and identity management. Once operators have established their role in the serviceenablement ecosystem, additional capabilities can be added directly by the operator or through partners. This article has not touched on the cloud aspect of service exposure this is not accidental. Services can be exposed to and consumed by both classical and cloud-based architectures. That said, it is likely that cloud technologies will significantly lower the barriers for creating and using exposed services. Many of the capabilities and aggregated applications can and will be compelling components of an operator s (potential) PaaS offerings. To conclude, a way of harmonizing the diverse landscape of apps, devices, products, services and subscriptions is needed. This will be an important way of enhancing the user experience for consumers, enterprise employees, developers and content providers. Service exposure implemented properly through the careful consideration of the varying needs of all the ecosystem s stakeholders and operators in particular promises to bring the required harmonization, securing revenue generation in the future of the communications industry. References 1. Ericsson, 2013, Press Release, Ericsson, Mozilla and AT&T demonstrate WebRTC solution to illustrate seamless web and mobile integration, available at: Ulf Olsson has a background in software architecture for distributed military command and control systems. He joined Ericsson in 1996, working mainly with packet-based systems, such as Packet PDC, GPRS, UMTS and the CDMA2000 packet core network. He is a senior expert at Group Function Technology, where his focus is on overall system architecture issues and how they relate to the different industry areas Ericsson operates in. He holds an M.Sc. in engineering physics from the KTH Royal Institute of Technology in Stockholm, Sweden. Mats Persson is a senior specialist in systems architecture working at the Systems & Technology unit at Solution Area Media, Business Unit Support Solutions. He holds an M.Sc. in computer science from Linköping University, Sweden. He joined Ericsson in 1988 and in his current position he has been working with service-enablement platforms, covering service exposure and M2M. Claes Cegrell is Head of Technology, Content and Enablers at Solution Area OSS, Business Unit Support Solutions. His background is in the IT sector, but for the past 15 years he has worked with development, sales, delivery and management of value added services, OSS/BSS and service enablement platforms focusing on the telecommunications industry. Telefonaktiebolaget LM Ericsson SE Stockholm, Sweden Phone: Fax: Uen ISSN Ericsson AB 2013