The business of telecom ap is capturing future revenue growth

1 | P a g e

The Business of Telecom APIs – Capturing Future Revenue Growth

By Geoff Hollingworth

Hypothesis – The telecommunications sector is the next industry to

receive massive levels of innovation, disruption and none traditional growth. Be prepared! Just as in the recording, film and newspaper industries before it, the telecommunication industry is being disrupted by the massive innovation and change in business model the Internet provides. Business and technical reengineering of how telecom creates and captures value above basic IP connectivity is required. Those that can respond to and anticipate the market requirements from the developer and application community shall be best positioned to win. Delivery shall require the market requirements be delivered via simple to use interoperable (where necessary) Application Programming Interfaces (APIs). Those that can deliver these APIs with best end user performance and network performance shall win.

Introduction

Telecom operators have provided communication services to consumers and enterprises for the last 130 years. This has lead to the creation of a global 2.4 trillion dollar telecommunication industry. Growth has largely been driven through an industry-closed eco-system delivering limited device choice, service choice and experience choice. In the late 1990’s the Internet and associated software approach started to create alternative experiences. In 2007 apple started to bring this experience to the telecom eco-system with the launch of the iPhone. The rest is history. There has been more innovation and experience creation in “telecom” in the last 5 years than in the previous 30. It is just not being lead by the traditional telecom industry players – either vendors or carriers. This is seriously challenging the long-term growth potential of the telecom industry. Alternative service providers implementing new platforms and new services/experiences are capturing the new revenues. This scenario is well described in the concept of “Peak Telephony” by Martin Geddes [ref]. However the long-term outlook is anything but grim. As stated by Julian

Genachowski at CTIA Wireless 2011 - “By 2015, the “apps economy,” is projected

to generate $38 billion in sales” [ref]. The combination of mobility, broadband and

cloud is driving lower price points and a transformation in society and business

where anything benefiting from a connection will have one. This changes the

addressable market for telecom operators from one constrained by connecting

people (in developed countries an already saturated market) to one constrained by connecting everything for

anything. This new market is exponentially bigger than the people market by a factor of 10, the same way connecting

people (5 billion) was exponentially bigger than connecting locations (fixed telephony – 1 billion). At the same time

speed of adoption is accelerating. It took 100 years to connect 1 billion locations, approximately 30 years to connect

5 billion people and it is predicted it will take 10 years to connect 50 billion devices.

A new operational and business model is required however, to address these opportunities and enable the traditional telecom players (both carriers and vendors) to take part in the revenue growth that is being created above the networks. The opportunity is to take part above the connectivity layer, to take part in new business value creation and capture.

The telecommunication sector is the next

industry to receive massive levels of

innovation, disruption and none traditional

growth. Be prepared!

”By 2015 the apps economy

is projected to generate

$38 billion in sales”

2 | P a g e

Why Do We Need API’s now? – To Address Markets beyond traditional direct communications The telecom industry has been exposing API’s for ten years or more and it has largely been irrelevant. What is suddenly more important now? We must look to the Internet software model to understand both the change in business models and required change in operations to deliver on the opportunity. But first let us understand our traditional business, its strengths and inherent weaknesses going forward. The traditional target market for telecom has been high margin services voice and messaging (up to 70% gross profit margin). These have primarily been delivered through a closed eco-system of network providers and device manufacturers. These services have been delivered as a direct sales model, both to consumers or enterprises

1. A global inter-operability model exists with aligned global settlement

process, which has enabled the largest inter-operable machine to exist in the world. This way of working is an industry asset that needs leveraging in the new economy. Each operator competes according to independent business plans but any success has secured the growth of the overall industry through inter-operator settlements. The traditional model only addresses the communication market however, which represents less than 10% of the total addressable needs market (see Figure 1). As we view the future, the opportunity for the next generation of network services is to address all other markets and adjacent industries, with communication services and also other network beneficial services. We call these new services “Network As a Platform Services”. They target the new addressable markets, which are diverse from a business value, business model, and business process point of view. Devices and client needs are disparate even within the same industries. For example there is no such thing as a healthcare industry. Each healthcare organization, hospital, insurance provider etc works according to their own operating procedures and their own perceived competitive advantage. The current opportunity and what will motivate spend of the trillion dollars the enterprise market currently has in the bank is to help them create new competitive advantages. For example electronic healthcare records simply replace documents and files. But the advantages of electronic healthcare records are much more than storage, retrieval, cost and speed. As a result multiple healthcare professionals can treat the same patient at the same time, from many locations, which optimizes cost, care and well-being of the patient that could not be imagined before. AT&T is pioneering this space [ref]. Scaling the embedding of relevant network services and values within these eco-systems can only be achieved by exposing the network value in easy to use API exposure. These API’s can then be used both internally and if wanted externally. The most successful API driven companies are those that use the same API’s internally (just a superset of what is made public) as noted by this insight into Amazon, quote from Jeff Bezos, 2002 around using API’s. “Anyone who doesn’t do this will be fired.

Thank you; have a nice day!” [ref]

Note the delta between which API’s are available internally and which API’s are exposed externally defines the core business of the operator and thus is strategically highly important to understand in advance and to expose accordingly.

1 Note for later reference in this paper. The real growth in these services happened after the services became inter-operable, thus releasing the network effect across the market and industry.

Figure 1- Courtesy of Vision Mobile

A global inter-operability model

exists with aligned global

settlement process. This way of

working is an industry asset that

needs leveraging in the new

economy

We call these new services

“Network as a Platform Services”.

They target the new addressable

markets beyond direct

communication spend

3 | P a g e

Figure 2 – Courtesy of Alan Quayle

This approach is identical to the new generation of internet players and service providers, such as Netflix etc (see figure 2). Scale and affordable reach of their core business into a disparate consumption landscape is driven by API exposure and management. The telecom industry should embrace the leading companies and practices from this space.

Key Telecom API Concepts It is important to recognize telecom has been using the concept of APIs ever since communications moved to digital. The traditional architecture that for example created SMS, has been closed from an API, client point of view and has followed telecom standards. However it is API driven, just not “open web” API driven and there are fundamental business operations that were created to support the closed eco-system, which can be replicated in the open eco-system. These are global inter-operability and associated global settlement. In the new service exposure world to address the new markets there are three complementary types of API. It is

Service ExposureKey Principles – From Old to new

Closed PlatformSMS Client

Network NetworksClosed API Inter-op

“Open” Plat formInternet Client

Network NetworksPublic API Inter-op

“Open” Plat formInternet Client

Network Networks

Public API

IP

Access AgnosticService Exposure

Closed Traditional Bus iness Architecture

Open Business Architecture 2 – Access Inter-operable

Open Business Architecture 3 - Access Independent or “Telco-OTT”

“Open” Plat form

Internet ClientNetwork

Public API

Open Business Architecture 1 - Access DependantRe-use same

approach

4 | P a g e

important to understand the difference between them. Access Dependent API’s can expose network value but only to customers of the access network. This is the least interesting scenario and shall not be the main focus of this whitepaper (it is assumed an operation that can manage interoperable and independent APIs can also support access dependant APIs as a sub-set of capability). Addressable market is limited to an individual operator reach and any addressable enterprise, wholesale partner spans more than one operator’s population. This type of exposure can enable differentiated finished services to the existing operator’s consumer market to create value add services for direct revenue (history of failing) or more commonly value add services to increase customer retention, stickiness, brand value. At the end of the day consumers are looking to spend less for more experience and the OTT players with different business models are delivering to this need. As for enterprise and wholesale partner markets, these normally span more than one operator’s population. Interestingly currently most M2M management solutions and associated enablers fall into this category of capability exposure (for example Jasper Wireless, nPhase, Ericsson Connected Device Platform). This is not by desire of the enterprise network, which would prefer an access inter-operable approach. Also the majority of connected devices projected will not be wide area connected and thus their management will also not be facilitated by these services. For any global company it is very difficult to deploy one M2M solution that will meet the needs of their total addressable market with this approach. Access Inter-operable API’s can expose network value to any customer irrespective of access network. This is enabled using similar network operations as can be found in the traditional telecom services domain of SMS and voice, using inter-operability agreements and associated settlement. This model enables unique network value to be exposed to the total market. In the past we have seen this to be the stimulus for exponential revenue growth that only the network operators can provide. By copying existing operational models it also allows for open competition in the marketplace (e.g. avoiding any regulatory concerns) while driving overall wealth generation into the total telecom eco-system. Challenges in this model to date have been time to market and cross operator business agreements in the “none-standardized” web API world. The opportunity is to resolve these challenges and build a fast time to market operating model that embraces the new paradigm (see later). This is the most complicated but also potentially the most lucrative and differentiated type of API and thus is the main focus of this paper. Access Independent API’s expose capability to the total market where the capability has no connection to access network capability. For example AT&T offers an API for sharing HIPPA compliant health care records. Clearly this has nothing to do with their traditional network business. However it leverages its other innate strengths such as security and trust (and deep pockets in case of litigation). The operator takes the same role as an OTT player and the term “Telco-OTT” has been coined by Dean Bubbly and his paper “Telco OTT Strategies and Case Studies” is highly recommended for a more detailed understanding [2]. A combination of different API types will deliver the maximum value creation and value capture for any operator. To realize the opportunity, one architecture and operation should be designed to allow maximum potential for inter-operability combined with maximum business independence to compete in the open market.

Building a Successful Operation to Deliver Future API Success and Revenue Generation In the appendix this paper shall use a fictitious case study and propose a blueprint of ideal operational approach and technical architecture for operator plus industry collaboration to deliver on the next generation of revenue growth. The blueprint shall revolve around 3 key actors and their lifetime journey through the telecom operator API eco-system. These are

• The developer (or developing company) • The Application (or service) • The Inter-operability and Settlement entity

The developer (or developing company) is the entity that will create the new finished application or service, using the published APIs.

Access inter-operable API’s are the

most complicated but also

potentially the most lucrative and

differentiated type of API and thus

is the main focus of this paper.

The winning landscape shall be

defined by those who can deliver

APIs, which respond to and

anticipate the market requirements

from the developer and

applications community,

independently of access network

5 | P a g e

The application (or service) is the result of the developer that then is placed into operation and generates API traffic that must be managed appropriately The settlement operating entity handles any required inter-operability routing and any associated financial settlement according to inter-operator agreements. Understanding the Business Model In this section we shall repeatedly talk about accelerating time to “money” for both the developer and the API publisher. It is important to understand that payback on API can come in many forms, depending on the API being exposed. Amongst the alternatives are

• Increased reach (measured in traffic) to increase distribution of content, data and/or brand value • Lowered cost and time to market for new services on new platforms • Release of 3pp innovation to embed/differentiate core offering in experiences beyond the reach of the core

business • Deep integration into enterprise VARs/ISVs for stickiness • Direct revenues for additional services or indirect revenues for market differentiation (bundled in existing

offering)[ref]

This paper suggests the opportunity for the telecom operator is to

• Cost-effectively create new experiences for the consumer channel that lowers churn, increases opportunity for cross sell and differentiates the operator in the saturated market from a brand value perspective. Probably finished services are required with trusted partners using any exposed API’s

• Own the enterprise from an end to end networking needs perspective, from outsourcing existing operations

to the cloud and also embedding the network capabilities into the enterprise business model to create new market capabilities and differentiation for the enterprise. Inter-operable, Independent APIs are a pre-requisite.

• Wholesale partners embedding network capability into their platform offerings for further consumption by

their application developer community. Inter-operable, Independent APIs are a pre-requisite.

Conclusion The next generation of value creation and value capture in the network business shall follow very different business models that are more in line with best practice software transaction models used by the leading internet software companies of today. The future market opportunity is far from grim” [ref]. To date the telecom industry has only addressed 10% of possible spend. The future market opportunity allows network services to address the other 90% as well. We call these new services “Network as a Platform” services. The required operational model and approach needs to be very different from today and needs to be prepared to scale to the same levels as the Internet leaders already see. The operational delivery model is based around performance managed API’s in the scale of billions of calls. Telecom has spoken to APIs for the last 10 years. However to address the new growth opportunities with disparate client and value creation, API’s become the key delivery mechanism that scales with cost. There is a market demand for interoperability of these services across individual operator networks. Re-using existing operational models can achieve this but there is a need to re-position them with faster time to market best practice and open API collaboration. Orchestration of the industry using new interworking approaches will drive time to money both for driving participants as well as following participants. Understanding the API-lead economy and how to place API driven business practice into operation is key in enabling any organization to be able to deliver on the future growth potential beyond direct communication.

Understanding the API-lead

economy and how to place API

driven business practice into

operation is key to enabling

any organization to be able to

deliver on the future growth

potential beyond direct

communication.

6 | P a g e

Appendix A – Fictitious Case Study of Enabling Phedex Shipping Service This fictitious engagement by operator AB&B shall be used to highlight a likely future API engagement scenario. The Opportunity Statement Phedex Shipping is in the business of logistics planning and management for its customers. It ensures packages are delivered as specified and can be traced through the whole operations flow. It currently has a customer service satisfaction problem. It has very complicated package tracking capabilities that can locate any package in real time but it has no capabilities to initiate communication directly with the closest employee to the package at any time. They wish to offer a new premium service to its most valuable customers – “Change on Demand”. Irrespective of where any package is at any time a customer can call and Phedex can locate the package, speak to the Phedex person closest to the package, initiate real time checking, changing, dialogue. The package can be shown to the customer live if wanted. Customers will pay a premium fee for this new level of flexible service that will change expectations in the industry on what is possible or not. Of course the communication needs to be secure and needs to work with quality and reliability – Phedex’s core business will be dependant on the service working. They wish to implement this capability, initially for internal use but potentially to expose the capability in the future for direct customer use. Phedex uses two service providers for its communication services and access – AB&B and Horizon. AB&B has pro-actively approached Phedex to see if they can assist in improving Phedex’s business in any way, unaware of Phedex’s current situation and wanted solution. The Solution Phedex explains it needs to AB&B. AB&B has recently joined the API inter-operability forum where it has secured its ability to deliver quality voice, cross carrier for a termination fee to be paid to the other access operator. Horizon is also a member of the inter-operability forum. AB&B presents its capabilities to Phedex. It explains “Network as a Platform” services, its corresponding API capability set and its ability to integrate real time quality communications into Phedex’s business processes and operations. AB&B presents its secure identity service. For such a service as this to work devices, people and processes have to reach end points independently of the access network or solution provider they reside upon. The provider of such an identity service has to be completely trustworthy, secure and committed to not sharing any information involved in the process. All participants, independently of access, device type, address, register with the secure identity service, announcing their availability and where/how they can be reached. Two potential solutions exist AB&B offers to support Phedex’s IT/VAR organization with the integration of AB&B’ssecure identity service and quality call API set. The end solution can either be integrated into an existing application that Phedex already operates or if no such client exists, AB&B can help Phedex secure the right partner to deliver such a communication application. AB&B offers to provide an end to end fully hosted client application solution. AB&B just needs to provide who needs to communicate with who and the solution can be simply embedded in any website or on any common smart phone or tablet device. Phedex and AB&B realize through these discussions this is only one of many potential collaborations the two organizations could work on together, that could completely change the way the company works in real time, both inside the company employee to employee and also outside the company – customer to company and company to customer. Phedex enter strategic relationships with AB&B to explore outsourcing of all real time communication needs and also re-engineering of real time business processes. This re-structures the relationship and discussion across all IT, wireless and communications needs.

7 | P a g e

The Solution Design and in Operation Cross Carrier Flow As stated the solution has to secure real time quality communication across both AB&B and Horizon devices. Phedex IT organization (or AB&B solutions people themselves) use the following AB&B API in their solution: http://dev.abb.com/v1/qualityConnect?b=<the_secure _identity_of_B> The device making the API call can be a desktop, laptop, tablet or smart phone. Since Phedex uses either AB&B or Horizon for connectivity, the traffic shall come from one of those networks. The person/device we are connecting to similarly shall be connected via one of those networks. All API traffic is routed back to AB&B’s Service Exposure traffic node, irrespective of access network used to connect the originating device. If both the requesting device and terminating device are AB&B access customers then AB&B establishes the quality connect internally. If either or both of the devices are not AB&B access customers then each request is passed onto the brokering/routing/settlement process to establish the quality connect over the other operators access network. AB&B will settle all inter-operability charges related to Phedex since AB&B are the sole billers and hold the total business relationship with Phedex. Therefore at the end of the agreed billing cycle between Phedex and AB&B, Phedex pays AB&B. At the end of the settlement billing cycle, AB&B settles with both its P2P partners directly (if any exist) and any hub connectivity partners (if any exist). The service is delivered. The billing cycles are completely independent as are the chosen business models. Horizon could choose to purely be an inter-operable operator and receive revenue just from P2P and/or hub relationships (as shown here). Or it too could choose to have a network exposure business and also have direct B2B/wholesale/developer clients, if it is willing to make the investment.

8 | P a g e

Appendix B - The Generic Life Time Journey of a Developer in Operation A developer is looking for capabilities or a developer has been targeted with a capability that may be useful to them. They go to the developer portal supporting the API. This portal could be run by

• a telecom operator directly, • an operating entity working on behalf of many operators (aggregator), • a specific development environment (platform independent [cdp] and/or platform specific [ios, android]) • a wholesale partner of either an operator or aggregator

It is important to understand an API is exactly the same as a product and from a business point of view there will be contracts between any operator and any channel partner the operator chooses to utilize to increase their reach. Any reseller shall be on-boarded to the host operator re-using the existing business management processes as for a direct consumer. This optimizes the re-use of tools and operational processes and analytics reporting, consumption management. The developer registers with the developer site. The developer enters their business identity information (business name, tax identity, company information, developer information). The account is then validated for being able to receive any settlement from the API usage or payment for the API usage (if the API is not zero rated). The legal relationship is always between the developer and the operating entity that runs the developer portal. To comply with different country’s privacy laws, the personal developer data must be stored in compliance to that person’s country of residence privacy laws. For example a German citizen cannot have their data stored in the USA. Once a developer is registered and financially validated they can start developing towards the published API’s. To accelerate time to “money”, both for developers and API publishers, any API should be best of class at

• Simple value it exposes • Ease of use • Business Model for usage

2

All three aspects should be as simple as possible. Developer loyalty is tremendously shallow and massive choice combined with easy discovery (internet search) leads to the need to be the best in class. Telecom should embrace and partner with the existing best in class internet API companies in operation that already have years of collective experience. A more detailed analysis of such companies and the capabilities they offer is beyond the scope of this paper but can be made available on request. Assuming the developer completes the application/service with API’s embedded, the developer must distribute their application. Depending on the target audience desired distribution, discovery techniques and management channels will vary. All however will share the same fundamental needs

• Reduction of distance between application publishing and user discovery

• Access/usage management of downloaded/accessed applications

2 Note the most optimal answer for all 3 is very dependent on the capability being exposed

Figure 3 - BlueVia Required Tax Information

9 | P a g e

• Analytics support of usage to enable better application roadmap planning, targeting of new users and in-service performance/quality of service.

The more a developer offering can assist with the above, the more the developer will use the services and the faster the time to “money” for both the developer and the API publisher. At billing period end the developer must either receive a bill for payment or a money settlement for deposit. The operator should re-use their existing business process mechanisms for third party content settlement if they have them.

Appendix C - The Generic Life Time Journey of an Application in Operation This section covers the life of the application once it has been discovered, installed and placed into operation. All application’s end performance depend on the combined performance of the underlying API’s performances it calls. Good application design should use parallel asynchronous coding methods as much as possible then the overall application performance has closer relation to the worst performing API. Obviously any API publisher does not want to be the worst performing API. Let us re-visit the three different API types and analyze each in turn.

• An access dependant API is limited by the geographic footprint the access network covers • An access inter-operable API can be called from anywhere but the response may involve interworking with

other network’s capabilities and associated settlement • An access independent API can be called from anywhere and the response may be able to be delivered

from anywhere

A correctly architectured API delivery network shall maximize performance in all three scenarios. Maximal performance should be measured in terms of

• Quality of experience (lowest possible latency, maximal quality of payload) • Network Yield (minimal usage of network resources to deliver required result) • Monetization of traffic (maximal transactional settlement opportunity for traffic and maximal post traffic

analytics) Telecom operators are uniquely positioned to deliver these results. An API delivery network consists of API incoming traffic management and API result orchestration and delivery. API incoming traffic should be served from a serving node geographically as close as possible to the requesting client. Each operator should have their own serving node to maximize their opportunity for yield management in their own access network and to allow independent operation inside their private footprint, aligned with their own unique operations and business roadmaps. The architecture allows for managed serving nodes however, to accelerate short term time to market if necessary or desired. In a similar way to CDN networks this architecture potentially lowers latency and increases probability of a locally cached response being available, thus effectively increasing quality of experience and effective network yield. Service nodes could be leased inter-operator as part of the settlement process, to increase global performance, lower operating costs, equitable compensation for investment. If a locally cached result is possible then the result is should be delivered directly from the serving node. If no cached response is found then the serving node must identify whether the requesting subscriber is a subscriber of this network. If yes then the request is channeled to the home network and the result is delivered back. If no then the request is forwarded to the interoperability node. If the owning network is not integrated then the interoperability node returns an error message otherwise it returns the result that can be delivered in response Note each operator can choose different interoperability nodes per API if desired or implement their own interoperability node to achieve control of full market coverage and time to market. This might be a viable strategy for well known API sets such as location and messaging. A centralized interoperability node could also use existing aggregators and may be able to leverage larger buying power as a representative of the collective operator community. For new API sets (such as network performance) a time to market advantage may exist if there is one central operating entity orchestrating inter-operability, settlement agreements and software integration. The central operating entity would be driven to best practice on boarding and operation in the space of inter-operable APIs (see next section).

10 | P a g e

Depending on API type, local caching of result may be possible. Results should be cached where possible and caching should follow existing best practice ETag caching rules as implemented in browser/CDN/client architectures. On completion of any API request the serving node shall log the result information for analytics and also send any settlement information necessary to the settlement entity (see next section).

Appendix D - The Generic Life Time Journey of Interoperability and Settlement Interoperability and associated settlement has always driven revenue growth in the telecommunications industry. The second largest revenue source for any operator is other operators. The model allows open competition in the market place for enterprises and consumers alongside fair payment for others resources used in delivering the end solutions. The interoperable API market offers similar (and exponentially larger) opportunities for all participants choosing to take part. The more aggressive members of the industry will directly capture new revenues from other industries. One side effect of this will be the influx of new revenue across the total telecom eco-system and allow others to integrate into the eco-system and also gain benefit from the increased money flow and wealth. This in turn will increase the total market interoperability helping the total industry proposition more and thus driving greater market opportunity (say from national to regional to global coverage). The value of interoperability should not be underestimated. Prior to SMS interoperability in 2001 general discourse explained the lack of use in the USA being a cultural difference/issue. There are now over seven billion SMS messages sent every month in the USA [ref]. The challenges and thus barriers for creating an interoperable API eco-system that replicates the previous industry success are an operational model that allows fast collaboration and time to market without formal standards or bodies. Proposed key success factors are –

• Fast agreement on interoperable transactions, independent of market offering • A distributed integration model that allows existing business practices to be re-used in the delivery and

settlement process • Online self service management following internet model best practice

We recommend the creation of a centralized operating entity that manages the above to accelerate and secure the market opportunity. For the purposes of this paper let us use the example of quality voice exposure and study the life time journey from this perspective. The consortium agrees to create the “quality of voice” transaction. The quality of voice transaction enables an in-application call to be established across the interoperability community. See below figure for indicative simple modeling of market size in North America alone.

11 | P a g e

Figure 4 - Indicative One Transaction Opportunity

The transaction is created and for simplicity let us say the value placed on such a transaction is 10 cents. E.g. operator A enables an enterprise that has both operator “A” subscribers and operator “B” subscribers. When the “create quality call” API is called to an operator “B” subscriber, the API orchestration enables an end to end quality call and operator “B” receives 10 cents for terminating such a call from operator “A”. Operator A can choose to charge the enterprise according to whatever business model they choose. For example they could charge 20 cents per call and make on average 100% margin (depending on mix of operator “A” subscribers versus operator “B” subscribers). Or they could hide the cost in the total enterprise enablement package they provide, the value of the enterprise account being larger than the direct revenue from any API call. Operator “B” could use the same quality of voice transaction but bundle with an advertising pre-roll capability that would allow them to take the same capability, charge nothing, but enforce a 30 second pre-roll to generate revenue. The key points are –

• Participating operators can continue to compete with complete freedom of business model to target customer.

• Differentiation and upside revenue exists from participation even if no direct business channel is created (“all boats rise” as more money enters the eco-system. In the above scenario operator “B” is a differentiated provider simply by supporting the quality of voice transaction and it receives 10 cents per indirect activation).

• Existing business processes and operations can be followed On boarding The operator wishing to participate in the interoperability ecosystem registers and is business validated with the centralized operating entity, in a similar manner to the on boarding process of a developer/company. Once successfully validated, the operator can view the interoperable transactions currently available. The operator can propose new transactions they would like to have as interoperable. Each transaction in the system has the following attributes –

• Description • Transaction price point • Northbound requesting API URL and response

12 | P a g e

• Southbound delivering API URL and response3

The operator chooses to take part in an inter-operable transaction. By selecting the transaction they commit to having implemented the south bound API and associated response

4. The centralized operating entity tests the

exposed interfaces and when validated, adds the routing to the ongoing traffic operation. To accelerate time to market the centralized operating entity can provide translation services in case the operator exposes the capability but not according to the interoperable specification. There would then exist a simple translation proxy. It may also be the case that the required capability has not been engineered to be exposed in the network. The operating entity again could assist any operator in realizing the exposure the most effective and efficient way. Once the implementation had been validated it would be placed “live” in operation. As explained in the previous section traffic would then begin to be routed to the participating operator. Settlement and analytics information would be sent to the central operating system to enable end of cycle payment and performance feedback. All information would be available to the participating operator through the same self service interface. And to repeat, for existing capability exposure existing aggregators may be leveraged to accelerate initial time to market. However this does not focus on the real new opportunity of finding new transactions that are valuable to expose.

3 Goal should be that the Northbound API is identical to the Southbound API and the interoperability node is

transparent in the execution 4 It is recommended the operator tries to re-use existing local exposure business processes and engines to align

total operation irrespective of interoperability or not