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

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

OneAPI: A standard to simplify crossnetwork development

Description:

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
Category:

less

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

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
About PowerShow.com