AllJoyn-Interworking
Discussion
Group Name: TP WG2 ARC
Source: Josef Blanz, Phil Hawkes, Qualcomm Inc., [email protected]
Meeting Date: 2015-05-18
Agenda Item: Alljoyn-Interworking (WI-0018)
Goals
• Quick recap of some AllJoyn concepts
– Peer-to-peer paradigm, proximity
– Advertisement/Discovery
– Gateway Agent Concept
• Rationale for new proposed text in TR-0014
– Explanation of interworking concept
• AJ connector app interacting with oneM2M resources
– Service Objects versus Services Frameworks
• Impact on resource structure
© 2014 oneM2M Partners
<Document number>
2
AllJoyn: Peer-to-Peer
• Runs on local network (proximal network)
• Communicates Peer-to-Peer (Apps talk to Apps with help of AJ Routers)
• Enables Apps to advertise and discover each other
Things describe their capabilities
I can send notifications
I can send notifications.
I have control panel
I have a clock interface
I display notifications.
I have the clock interface!
I display notifications.
I have the clock
interface!
I display notifications.
I have the clock
interface!
I can send notifications
I have control panel
I can send and display
notifications
I have Lighting Interface
Advertisement & Discovery
•
•
•
•
•
Producer Device
Consumer Device
AllJoyn App
AllJoyn App
Service
Object
Proxy
Object
AllJoyn Bus
AllJoyn Bus
One or more Interfaces:
• Methods (RPC)
• Properties (set, get)
• Signals (P→C)
Service Producers and Service Consumers (both are Apps)
Exchange information via Service Objects
Providers: Advertise Names / Do Announcements
Consumer: Discover Names / Read Announcements
Consumer will find Producer(s) & understand service objects
Gateway Agent
• Plugin mechanism
to connect AJ
proximal network
with cloud
• Already defined
framework for
controlling what
can be exposed in
both directions
• Best place for
inserting a
oneM2M IPE as a
connector
Service Provider Hosted
Cloud
Service
AllJoyn
Consumer 1
For
For instance:
instance:
·· Expose
Expose Producer
Producer AA to
to cloud
cloud
·· Expose
a
specific
cloud
Expose a specific cloud service
service to
to
Proximal
Proximal network
network
AllJoyn
Consumer 2
Gateway Agent
Connector
App A
Gateway
Management
App
AllJoyn
Producer B
Control
App
For
For instance:
instance:
·· Allow
Allow Connector
Connector AA to
to expose
expose
Producer
Producer AA to
to cloud
cloud
·· Allow
Allow Connector
Connector AA to
to be
be producer
producer
in
in Proximal
Proximal network
network for
for specific
specific
objects/interfaces
objects/interfaces
AllJoyn
Producer A
Mobile Device
Proximal
Network
AllJoyn-to-oneM2M mapping
Connector
App
AJ
Network
Service
Exposing App
AJ Gateway Agent
with oneM2M AE = IPE
oneM2M
Exposure AE 12
oneM2M IN CSE 3
AJ App 1
Rsc 1
AJ App 2
Rsc 2
oneM2M AE Y
oneM2M AE Z
oneM2M Network
Consume AJ service
Provide AJ service
AllJoyn-to-oneM2M mapping
Connector
App
AJ
Network
Service
Exposing App
AJ Gateway Agent
with oneM2M AE=IPE & CSE
oneM2M
Exposure AE 12
AJ App 1
Rsc srv 1
oneM2M IN CSE 3
Rsc srv 2
Annc Rsc 1
oneM2M AE Y
Annc Rsc 2
AJ App 2
oneM2M AE Z
oneM2M CSE 1
oneM2M AE Z
oneM2M Network
Consume AJ service
Provide AJ service
AllJoyn-to-oneM2M mapping
Connector
Apps
AJ
Network
AJ Gateway Agent
with oneM2M AE=IPE & CSE
oneM2M AE X
Service
Exposing App
oneM2M
Exposure AE 12
mirror App A
oneM2M AE A
mirror App B
oneM2M AE B
AJ App 1
AJ App 2
Rsc srv 1
oneM2M IN CSE 3
Rsc srv 2
Annc Rsc 1
oneM2M AE Y
Annc Rsc 2
oneM2M CSE 1
Annc Rsc A
Annc Rsc B
Connector
Apps
AJ
Network
AJ Gateway Agent
with oneM2M AE=IPE & CSE
Service
Exposing App
oneM2M
Exposure AE AB
AJ App A
mirror App 1
oneM2M AE 1
AJ App B
mirror App 2
oneM2M AE 2
Rsc srv A
oneM2M AE Z
oneM2M Network
Rsc srv B
Consume AJ service
oneM2M CSE 1
Provide AJ service
Impact on TR-0014
• Need to add figure(s) as on previous slides to
explain more details on principle of mapping
between AJ and oneM2M
• Covers multiple – if not all – of the
interworking scenarios defined in TR-0014
• See separate contribution
AllJoyn-to-oneM2M mapping
• Need to develop resource structure to expose
AJ service objects to oneM2M AEs
– Re-use existing resource types versus new types
• Resource structure for provider-specific
services needs to represent serv. objects
– Methods (RPC)
– Properties (just data, set & get)
– Signals (Event, possible payload)
• Serv. Frameworks different from serv. objects
Service Objects vs Frameworks
Uses Service Frameworkspecific API
Examples:
• Notifications
• Control Panel
• Onboarding
• Configuration
Uses Service Objects
for exposure
Example: Notifications
Simple interface for sending and
receiving human-readable
messages, optionally “rich”
Able to assign priority types
Able to configure preferences
Supports interaction in response
to notifications
Freeze
r is
open
Message
from LEE
DVR is 90% full
am
Notification Serv. Framework
Notifications are sent/received as a ntfcnObject which has a number of data members
(text in one or more languages, Icons, audio URL, msgId,…) and a dismiss() function
Producer uses API
function for sending
a notification:
Send(
ntfcnObject)
Also available:
DeleteLastNtfcn(
ntfcnType)
• Serv. Frameworks use APIs (object models & RPCs)
• Simpler than underlying AJ Service Objects
• Purpose-specific (here notification related)
Consumer provides
a callback function to
consume a
notification:
Receive(
ntfcnObject)
Another callback:
Dismiss(
msgId, appId)
dissmisRequest
consumerXXX
<contentInstance>
<subscription>
Impact on Resource Structure
consumerYYY
<subscription>
Resource structure for control panel services framework
controlPanel
allJoynRoot
<container>
<container>
svcFrameWorks
other
<container>
base
Resource structure for connected lighting services framework
<container>
ontectedLighting
Resource structure for notification services framework
notification
<container>
<container>
0000001
<container>
ntfcnObjData
appSpecifcSvcs
<contentInstance>
dismiss
dissmisRequest
0000002
<subscription>
<contentInstance>
Resource structure for service objects of provider YYY
providerYYY
<container>
<contentInstance>
dismiss
<container>
listenerIPE
dissmisRequest
consumerXXX
<subscription>
consumerYYY
<subscription>
<subscription>
<contentInstance>
Resource structure for control panel services framework
<container>
other
Resource structure for connected lighting services framework
ontectedLighting
<container>
<container>
ntfcnObjData
controlPanel
Resource structure for service objects of provider XXX
providerXXX
<container>
listenerIPE
<container>
<container>
For some services frameworks or for some
app-specific services, new resource types
may be needed; for other existing resource
types may be sufficient
Impact on TR-0014
• Need to reflect difference in AllJoyn Services
Frameworks versus app-specific AllJoyn
service providers in resource structure TBD for
exposing/injecting services
• See separate contribution