OneAPI: A standard to simplify crossnetwork development - PowerPoint PPT Presentation

Title: OneAPI: A standard to simplify crossnetwork development


1

• OneAPI A standard to simplify cross-network
  development

Kevin Smith Vodafone Group RD September 2009
2
GSMA 3rd Party Access OneAPI

• What? a set of open network enabler APIs (OneAPI)
  that can be supported across mobile operators and
  other networks.
• Why? To unlock valuable network enablers in a
  consistent fashion, and thus reduce the time
  developers spend integrating to multiple
  operators. Initial enablers for the API are
  Charging, Location, Messaging, with more to
  come.
• How? Lightweight RESTful SOAP APIs to encourage
  portability of Mobile apps but still allow for
  competition and differentiation between
  operators also commercial and operational
  facilitators to reduce fragmentation
• Who? GSMA working group of operators, vendors,
  aggregators plus developer collaboration. Aimed
  at small innovators and Web developers who can
  benefit from the reduced integration effort to
  deliver consumer, enterprise and convergence
  applications across operators.
• When? Commercial implementations Q1 2010

3
Network API fragmentation stifles development
Etc..
Bespoke APIs per operator

• Mobile and Web developers want to reach the
  largest market of users
• and each operator has their own bespoke partner
  programmes
• so given a choice of operators, and limited
  resources, should they only choose one sales
  channel? Who wins a fragmentation war? Is there
  also room to share developers?
• The One API allows lightweight development and
  deployment across all operators
• Offering richer APIs as a complement to OneAPI is
  encouraged for competition!

4
Why should Operators support One API?

• Drives convergence applications (PC innovation)
• Built with developer collaboration (Beta portal,
  WIP, developer communities)
• Targets those developers that do not want to
  choose an operator
• A chance to replicate Web success (transparent
  networks) and include network enablers in the
  ecosystem as a standard
• Potential for interoperable cross-operator apps
  see previous success with SMS ?
• Low capex and opex if installed within developer
  gateways (a façade)
• Still allows for differentiation OneAPI can
  attract new developers into the
  mobile/convergence ecosystem once delivering
  successful apps we can upsell them to our richer
  service APIs

Long Tail currently underexploited
Open access to innovative 3rd parties
Current partners
5
OneAPI scope

• Delivers a technical standard that can be
  supported across network operators to allow
  consistent access to enablers
• and hence encourages Web developers to mash-up
  network capabilities in their desktop apps
• and stimulates cross-operator mobile
  applications
• Investigates ways to facilitate deployment across
  multiple operators
• Is not a developer proposition in and of itself
• Is not an app store or sales channel
• Does not allow unhindered access to enablers
• Does not force a commercial model
• Does not try to restrict MNO APIs competition
  is good!

6
OneAPI enables a cross-operator 2-sided business
model
Customers of airport arrive at terminal
See appendix for further details
7
OneAPI and Service Delivery Platforms
Partners
8
Appendix
9
OneAPI phase 1
DELIVERED MARCH 09
Public Reference Implementation hosting Messaging
and Location across 10 operators (for
non-commercial testing)
10
OneAPI phase 2
STARTED MARCH 09 completion by March 10
Workstreams
Technical
Commercial
Go To Market

• Ensure a robust usable standard
• Standardise the OneAPI via the OMA
• Recommend a consistent technical framework for
  implementations
• Evolve the existing APIs
• and produce 2nd phase APIs Charging, Data
  Connection, Click to Call, Personalisation
• Publish SDKs and IDKs
• Continue to provide test bed and forum for
  developer feedback

• Making commercial engagement process easier
  across operators
• Recommending Ts Cs templates
• Investigate a consistent developer/app identity
  across operators
• Implement the ACR as part of OneAPI
• Define principles for inter-operator settlement
  of APIs
• Ensure neither Regulatory nor Antitrust concerns

• Encourages implementations and usage of OneAPI
• Develop business rationale for operators to
  support OneAPI
• Ensure no conflict with operators own
  initiatives
• Provide materials to promote OneAPI within
  operators
• Present and discuss OneAPI at developer events
• Run pilot trial of OneAPI
• Feed trial results back into project
• Competition for best use of OneAPI at MWC 2010

11
OneAPI deliverables in progress

to view
Draft APIs

• Data Connection Profile
• Application Triggers
• API roadmap

Implementation Recommendations

• AAA for implementations
• Regulatory aspects
• Technical Framework overview

Cross-operator pilot
Operator support

• Value Chain analysis
• Business rationale
• for APIs
• for OneAPI
• Potential business models

• Pilot implementation plan

12
External standards liaisons
Network APIs as complement to Device APIs
13
OneAPI functions

• Notes on OneAPI
• Each API comes in a RESTful and SOAP binding
• REST is typically easier to start working with
• SOAP offers more robust transactional
  programming
• The OneAPI is being standardised via the OMA and
  will reuse parts of the Parlay X definitions
• OneAPI utilises the MSISDN anonymisation (ACR)
  to conform to regulation and will drive to
  standardise this protocol via the IETF.
• We recognise that facilitating onboarding across
  operators, and discovery of policies, will
  simplify development. As such we are
  investigating tools such as privacy APIs,
  standardised developer keys and Ts Cs
  templates and recommendations for throttling,
  AAA.

14
OneAPI first phase
OMA specification starts End July
2009completion approx end 2009
Messaging   
via OneAPI
via OneAPI

• Send an SMS/MMS
• Use cases
• on-time Website password
• text/photo/video alerts
• trigger application on handset

• Receive an MO SMS/MMS
• Use cases
• text/ photo/video blogging
• client application updating server (games)
• Get information based on text (e.g. Wikipedia
  definition)

Charging   
Location   
via OneAPI
via OneAPI

• Get location (for individual or group)
• Use cases
• cross-operator buddy finder/LB gaming
• Mash-ups with mapping, reviews services.

• Reserve, Charge, Refund amount to user
• Use cases
• Seamless mobile billing
• Using MNO billing for PC services

15
OneAPI second phase
OMA specification starts TBC Approx Q4 2009
Click to call   
Data Connection Profile   
via OneAPI
via OneAPI

• Get current connection (3GGPRSWiFinone)
• Use cases
• Content adaptation should I stream or send
  images?

• Call a mobile, fixed line or Skype number
• Use cases
• Customer support on website click for a
  callback
• Lightweight conferencing

Privacy   
Personalisation   
via OneAPI
via OneAPI

• (TBC) adapt service based on user context
• Tariff, remaining credits, preferences, activity
  history all important for service delivery
• Expose methods that add value but protect
  privacy, e.g. getAdvertURL, isGoodToStream?

• (TBC) obtain the privacy aspects for each OneAPI
• Use cases
• What does each operator allow/forbid
• What has a user set as their own preference

16
OneAPI third phase
TBC
Video call   
QoS   
via OneAPI
via OneAPI

• Request QoS
• Use cases
• Ensure better UE (smooth streaming)
• Prove delivery of unicast content

• Deliver video via one-way 3G video call channel
• Use cases
• Delivery of video service
• Lightweight video conferencing

Identity   
plus evolution of existing APIs in line with
developer feedback
via OneAPI

• Request QoS
• Use cases
• Network provides identity to website
• Network provides authentication to website

17
Why should an MNO implement OneAPI airport
example

• The GSMA OneAPI project was triggered by an
  investigation which revealed that there is a gap,
  i.e. there are use cases where companies need
  applications that work in the same way across
  different network operators, when the
  application/service makes use of certain network
  enablers.
• A good real-world case is a major transport and
  infrastructure company (anonymised) who want to
  provide a service to "their customers who have
  arrived at an airport terminal.
• The infrastructure company want to detect their
  customers location and provide value-added
  travel services recommend hotels, find trains
  and restaurants, locate visiting business
  contacts in town etc.
• All the customers are on different networks,
  some roaming
• Thus, the companys application has to retrieve
  info via network interfaces from VF, T-Mobile, O2
  etc etc.
• Clearly a common interface is needed and that's
  what a corporate customer is calling
  for explicitly.
• The typical operator by nature likes to "own his
  customers for himself", give them a proprietary
  API to protect churn etc. This often works well
  for a consumer proposition, where operators "own"
  their proposition towards consumers, but not in
  this case where there is one level of B2B
  indirection in between the operators customer
  is a corporate firm whose customers in turn want
  an ubiquitous service and access to enablers via
  an application. That application has to retrieve
  e.g. location info from a VF server as well as
  from a Telefonica server, T-Mobile Server, Orange
  Server, 3 Server etc.
• Considering that operators customers also face a
  pressure concerning cost leadership, we as MNOs
  need to understand we may loose many of those
  customers by not providing easy and consistent
  access to our enablers. Such companies will be
  driven to Over the Top Web solutions.
• LETS GROW THE PIE TOGETHER!

18
GSMA Project participants

• All Major European Operators, plus major Asian
  Operators
• Enterprise and SDP Vendors
• Developer involvement via portal
• Liaisons/collaboration with OMA and OMTP BONDI
  (for united industry front)

19
The final word.

• Cross-operator APIs address can stimulate
  convergence applications (PC apps with mobile
  functionality)
• and provide for developers who do not want to
  have to choose an operator.
• The internet did not grow because of fragmented
  network protocols we need to consider that when
  looking at the growth of the Mobile Web and
  convergence apps
• Quote from www.wipjam.com
• Thanks Mr Carrier, your API is waaaay cool. Its
  just a leeeetle different too every other
  carriers API.. but thanks anyway

20
Thank You
Placing standard Network APIs in the developers
Toolkit
http//www.gsmworld.com/oneapi Kevin Smith
(Vodafone Group RD, Project Leader
kevin.smith_at_vodafone.com