Smart Accessory Interface 1.0 Proposal

OMA-TP-2013-0XXX-WID_XXX_SAI_V1_0_Presentation
Presentation of WID Information:
Smart Accessary Interface v1.0

Submitted To: TP
Date: XX June 2013
Availability: X Public OMA Confidential
Contact: Jonghong Jeon (hollobit@etri.re.kr)
Source: ETRI

USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE
AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE
TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT.
THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

Intellectual Property Rights
Members and their Affiliates (collectively, "Members") agree to use their reasonable endeavours to inform timely the Open Mobile Alliance of Essential IPR as they become
aware that the Essential IPR is related to the prepared or published Specification. This obligation does not imply an obligation on Members to conduct IPR searches. This
duty is contained in the Open Mobile Alliance application form to which each Member's attention is drawn. Members shall submit to the General Manager of Operations of
OMA the IPR Statement and the IPR Licensing Declaration. These forms are available from OMA or online at the OMA website at www.openmobilealliance.org.

© 2013 Open Mobile Alliance Ltd. All Rights Reserved.
Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2013-0XXX Slide #1
[OMA-Template-WIDpresentation-20120101-I]

General information about the Work Item
• WID Information
• WID XXX - SAI 1.0 (registered label) – Smart Accessary Interface 1.0
@@@ TBD URL @@@
• Short description
• This WI will define the requirements and consequent TSs for a SAI enabler aimed
at improving the information exchanging between Smart Accessary and Smart
Devices, and usability of Smart Accessary. Please refer to the outlined use case
• WG Handling Proposal
• To be handled by REQ WG
• Status of WID socialisation:
• submission for TP approval


Problem / Opportunity Statement (1/2)
• The explosion of the Smartphones and Tablets Devices has made a dramatic impact on our mobile
lives. Smart devices and applications are providing incredibly rich experiences for users.

• A new class of smart devices that wirely/wirelessly link to smartphones and tablets will begin to gain
traction over the next few years, with health, fitness and assistant leading the way. Increasingly smart
accessories that focus on trekking, communication, weight management and healthcare monitoring of
chronic disease will dominate the market.

• Whilst the Smart Accessory is becoming increasingly, Smart Accessory services is heavily fragmented
due to the multitude of disparate services, implementing a “walled garden” approach.

• Up to today, there is no existing standard or de facto standard for Smart Accessory Interface.
Application Developer and Accessory Manufacturer have to develop and use different and dedicated
interface method and data format.

• This proposed work item to define an Smart Accessory Interface(SAI) is the opportunity to resolve the
situation and to produce a standard relevant for the all industry.

Problem / Opportunity Statement (2/2)

AS IS TO BE
Mobile Device Mobile Device
Information & H/W Information & H/W
Capabilities Capabilities
own logic &
Standardized Interfaces
knowledge
App A App B App A App B

Application Standardized Interfaces
Dedicated
accessary

Accessaroy A Accessaroy C
Accessaroy A

Accessaroy B Accessaroy B


Main market benefits
• Benefits for all involved players:
Customers:
• Device Apps and Accessory has higher interoperability and usability
• Subscribers / end users will have more options and freedom to use the Smart Accessory &
applications
Applications Developers
• Developers don’t have to think: How my apps can be access the Smart Accessories and
control that. And how can exchange the data/control message between the Smart
Accessory and the Smart Devices. Developers will also benefit this value chain by providing
richer applications or widgets according to the SAI APIs.
Device and OS Vendors
• Accessory Device Manufacturers don’t‘ have to think about their own access protocol and
method. OS vendors can be provide various data/messaging/information with standardized
interface for Smart Accessories.
Operators
• operators will also be able to improve ARPU by offering unique, differentiated value of their
smart accessory based service (e.g. mHealth, training) to subscribers.

Use Case: Multi Accessory
• This scenario aims at enabling a user using multiple smart accessory or
supplementary devices to gather his health data.
• A user would like to access the multiple sensing data from different accessory
devices, such as using Smart Watch, Glasses and Health monitor. A user may also
use multiple accessories to gather various sensing data and exchange the control
messages between accessory and smart devices.
• The smart accessory applications need to be provided as other mobile services
which are independent of the accessory devices.
• Some of the operations that users can carry out in multiple accessory scenario are:
1.user A gather the heart rate sensing data by hear-rate monitoring accessory.
2.user A accesses the mobile AR service through his Smart Glass Accessory and Smart phone.
3.user A gather the training data through his sports band accessory.
4.user A get the notification via Smart Watch that his Smartphone get the messages.
5.user B get the notification via Smart Watch that his tablet get the messages.
6.user A want to manage how many accessory is connected with his smartphone, and how it working.


Use Case: Multi Accessory

Smart Watch

Sports
band
John

Glass
Smith

Heart rate
Monitor


Use Case: Multi Accessory Collaboration


Use Case: Open Accessory Interfaces


Use Case: Open Accessory Interfaces
• A Connection manager is basically composed of 2 parts:
• The hardware & connectivity engine part to manage the device with the necessary functions relevant for
the user/customer of the connection manager
• The user experience presented to the customer and composed mainly of the UI, the profiles and the
services offered to the user based on actions and answers from the hardware engine part.

User Interface (UI)
User Interface&
Operator/OEM

Service/Profile
proprietary

Management
Languages
Languages Profiles Management Services
Languages (priority, Bluetooth, NFC, WiFi..) Enabler Presentation
Languages
Layer

OPEN Accessory Interface
Generic API

Functional Layer
(OPEN)

OS
Accessory Interface Engine
Profile abstraction
Management
layer

USB Host/ Audio Wi-Fi Other Accessory Interface
proprietary

Bluetooth NFC/Felica
Device

TMIM engine
Hardwareengine
TMIM Device MCU Power Amp Engine Engines
TMIM engine
Engines


How OMA can help
• OMA can help with this Work Item covering the following aspects:
• to define the requirements and reference architecture to allow interoperability between accessories & devices
and accessories-server
• to specify the interface between an SAI Client entity and an SAI Accessory entity that support the identified
features;
• to specify the interface between SAI Client entity and device capability that support the identified features;
• As outcome of the activity of this Work Item, a new “SAI Enabler” is expected to be
specified.
• Main objective is to provide a rapid specification of an SAI Enabler that achieves the minimum goals of achieving
interoperability and usability


Impacts, relationships and dependencies

• State (potentially) related/impacted:
• OMA OpenCM, AOI, DM, M2M, COM-ISC
• Bluetooth

• State potential and identified dependencies:
• None

• Describe impacts on different system elements:
• None


Supporting Companies
• The companies supporting this work item are:

Company name Membership type
ETRI Associate
LG Electronics Full
Samsung Electronics Full
SK Telecom Associate


Proposed Resources
• The companies supporting this work item are proposing the following resources:
Deliverable/Role Proposed volunteer
editor/champion
Requirements Document (RD)
Requirements Document Review Report (RDRR)
Architecture Document (AD)
Architecture Document Review Report (ADRR)
Technical Specification (TS)
Enabler Test Requirements (ETR)
Enabler Test Requirements Review Report (ETRRR)
Enabler Release Definition (ERELD)
Consistency Review Report (CONRR)
WID/WISPR Champion
ARC Champion
IOP Champion

Smart Accessory Interface 1.0 Proposal

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (10)

Destaque

Destaque (9)

Semelhante a Smart Accessory Interface 1.0 Proposal

Semelhante a Smart Accessory Interface 1.0 Proposal (20)

Mais de Jonathan Jeon

Mais de Jonathan Jeon (20)

Último

Último (20)

Smart Accessory Interface 1.0 Proposal