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


PPT – OneAPI: A standard to simplify crossnetwork development PowerPoint presentation | free to view - id: 20e41f-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

OneAPI: A standard to simplify crossnetwork development


a set of open network enabler APIs (OneAPI) that can be ... The OneAPI is being standardised via the OMA and will reuse parts of the Parlay X definitions ... – PowerPoint PPT presentation

Number of Views:140
Avg rating:3.0/5.0
Slides: 21
Provided by: smi6159


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: OneAPI: A standard to simplify crossnetwork development

  • OneAPI A standard to simplify cross-network

Kevin Smith Vodafone Group RD September 2009
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
  • 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

Network API fragmentation stifles development
Bespoke APIs per operator
  • Mobile and Web developers want to reach the
    largest market of users
  • and each operator has their own bespoke partner
  • 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!

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
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
  • 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!

OneAPI enables a cross-operator 2-sided business
Customers of airport arrive at terminal
See appendix for further details
OneAPI and Service Delivery Platforms
OneAPI phase 1
Public Reference Implementation hosting Messaging
and Location across 10 operators (for
non-commercial testing)
OneAPI phase 2
STARTED MARCH 09 completion by March 10
Go To Market
  • Ensure a robust usable standard
  • Standardise the OneAPI via the OMA
  • Recommend a consistent technical framework for
  • 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
  • Provide materials to promote OneAPI within
  • 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

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

External standards liaisons
Network APIs as complement to Device APIs
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
  • 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,

OneAPI first phase
OMA specification starts End July
2009completion approx end 2009
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

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

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
  • Call a mobile, fixed line or Skype number
  • Use cases
  • Customer support on website click for a
  • Lightweight conferencing

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

OneAPI third phase
Video call   
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

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

Why should an MNO implement OneAPI airport
  • 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
  • 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.

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

The final word.
  • Cross-operator APIs address can stimulate
    convergence applications (PC apps with mobile
  • 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
  • Thanks Mr Carrier, your API is waaaay cool. Its
    just a leeeetle different too every other
    carriers API.. but thanks anyway

Thank You
Placing standard Network APIs in the developers
http// Kevin Smith
(Vodafone Group RD, Project Leader