The document discusses how telecommunications companies can capture future revenue growth through the use of application programming interfaces (APIs). It argues that APIs will allow telecom companies to address markets beyond direct communications and participate in the growing "apps economy." Specifically: 1) Telecom APIs can expose network capabilities to developers, allowing telecom companies to participate in new services and address markets beyond basic connectivity. 2) Access-interoperable APIs that work across networks have the most potential for new revenue but are also the most complex to implement. 3) To succeed, telecom companies need operations that can deliver APIs at scale to developers while also facilitating interoperability and settlement between networks.

1. 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 The telecommunication sector is the next
growth. Be prepared!
industry to receive massive levels of
Just as in the recording, film and newspaper industries before it, the innovation, disruption and none traditional
telecommunication industry is being disrupted by the massive innovation
growth. Be prepared!
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 ”By 2015 the apps economy
to generate $38 billion in sales” [ref]. The combination of mobility, broadband and is projected to generate
cloud is driving lower price points and a transformation in society and business $38 billion in sales”
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.
1|Page

2. 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 A global inter-operability model
through a closed eco-system of network providers and device manufacturers. exists with aligned global
These services have been delivered as a direct sales model, both to consumers or
1
enterprises . A global inter-operability model exists with aligned global settlement settlement process. This way of
process, which has enabled the largest inter-operable machine to exist in the world. working is an industry asset that
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 needs leveraging in the new
has secured the growth of the overall industry through inter-operator settlements. economy
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 We call these new services
network beneficial services. We call these new services “Network As a Platform
Services”. They target the new addressable markets, which are diverse from a “Network as a Platform Services”.
business value, business model, and business process point of view. Devices and They target the new addressable
client needs are disparate even within the same industries. For example there is no
such thing as a healthcare industry. Each healthcare organization, hospital,
markets beyond direct
insurance provider etc works according to their own operating procedures and their communication spend
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 Figure 1- Courtesy of Vision Mobile
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.
2|Page

3. 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 Service Exposure
ever since communications moved to Key Principles – From Old to new
digital. The traditional architecture
that for example created SMS, has Closed Traditional Bus iness Architecture
been closed from an API, client point
C lose d Pla tform Clos ed API Inte r-op
of view and has followed telecom SMS Client N etwor k Ne twork s
standards. However it is API driven,
just not “open web” API driven and Open Business Architecture 1 - Access Dependant
there are fundamental business “Open” Plat for m Public API
R e-use
s ame
N etwor k
operations that were created to Inte rne t Clie nt a ppr oa ch
support the closed eco-system, which
can be replicated in the open eco- Open Business Architecture 2 – Access Inter-operable
system. These are global inter- “Open” Plat for m
Inte rne t Clie nt
Public API
N etwor k
Inte r-op
Ne twork s
operability and associated global
settlement.
Open Business Architecture 3 - Access Independent or “Telco-OTT”
“Open” Plat for m Public API A cce ss Agnostic
In the new service exposure world to Inte rne t Clie nt Se rvice Exposure
address the new markets there are N etwor k IP Ne twork s
three complementary types of API. It is
3|Page

4. 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 Access inter-operable API’s are the
can be found in the traditional telecom services domain of SMS and voice, using
inter-operability agreements and associated settlement. This model enables most complicated but also
unique network value to be exposed to the total market. In the past we have seen potentially the most lucrative and
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 differentiated type of API and thus
open competition in the marketplace (e.g. avoiding any regulatory concerns) while is the main focus of this paper.
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 The winning landscape shall be
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
defined by those who can deliver
operator API eco-system. APIs, which respond to and
These are
anticipate the market requirements
from the developer and
• The developer (or developing company)
applications community,
• The Application (or service)
• The Inter-operability and Settlement entity independently of access network
The developer (or developing company) is the entity that will create the new finished application or service, using the
published APIs.
4|Page

5. 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 Understanding the API-lead
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
economy and how to place API
industry has only addressed 10% of possible spend. The future market driven business practice into
opportunity allows network services to address the other 90% as well. We call operation is key to enabling
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 any organization to be able to
prepared to scale to the same levels as the Internet leaders already see. The deliver on the future growth
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.
potential beyond direct
However to address the new growth opportunities with disparate client and value communication.
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.
5|Page

6. 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.
6|Page

7. 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.
7|Page

8. 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
2
• Business Model for usage
Figure 3 - BlueVia Required Tax Information
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
8|Page

9. • 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).
9|Page

10. 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.
10 | P a g e

11. 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
11 | P a g e

12. 3
• Southbound delivering API URL and response
The operator chooses to take part in an inter-operable transaction. By selecting the transaction they commit to
4
having implemented the south bound API and associated response . 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
12 | P a g e