1. Proximal IoT Interworking discussion
Group Name: ARC#27
Source: Jiaxin Yin, Huawei Technologies Co., Ltd.
Meeting Date:
Agenda Item:TBD

2. Background Current we have: We are about to have: Tip of the iceberg:
AllJoyn Interworking
OIC Interworking
LWM2M Interworking
Generic Interworking
We are about to have:
DDS Interworking
OSGi Interworking
OPC UA
Tip of the iceberg:
Millions of other protocols not defined how to interwork (Z-Wave, ZigBee, mBus …)
Millions of proprietary protocols we don’t even have a starting point
What’s the way forward?

3. Backgroud Proximal IoT Interworking (Scope)
Figure out how the existing interworking solutions in oneM2M can be enhanced in a way to form a high level framework of interworking without need for AE programmers to be aware of any specific external technology.
Define the resource architecture and any other functions needed in oneM2M to represent and interact with a non-oneM2M device in a oneM2M system.
Figure out the missing functional and protocol specifics that are needed for the interworking, and fill in the gaps.
Enhance the oneM2M Home Appliances Information Model (HAIM) to ensure the interworking with different information models

4. Pain points of interworking
Two directions
One: connect a device into oneM2M system (South bound)
Doubt 1: Among all the oneM2M resources, to expose my services, which resources should I use? And what’s their relations?
Doubt 2: With just one resource type, are there any guidelines on how the resources should be organized?
Two: develop an application using oneM2M system (North bound)
Doubt 1: with the resource tree, are there any uniformed rules understand?
Doubt 2: how to guarantee the application developed on SP1 can be used on SP2 seamlessly?
Data report
Actuate
Reboot
container
Factory reset
device
remoteCSE
Triggering
Sleep & Wake up AE
Authentication
Subscription
mgmtObj
Roaming AE

5. A starting point
Guidelines on how devices should expose their services. Examples could be:
One device should create one <AE> or one <remoteCSE> dependently.
One data reporting service should create one <container>
For actuating of ADN, one <container> and one <subscription> should be used together.
Etc..

6. A starting point
Guidelines on the relationship between resources. Examples could be:
<container> related to data reporting should be created under the corresponding <AE> resource instead of under <CSEBase> although it’s allowed by the spec.
In case of service delegated to platform, <container> should be created under <AEAnnc> resource?

7. Scope of Proximal IoT Interworking
With the help of Proximal IoT Interworking:
Device will be connected with oneM2M system in similar manner
Applications easily knows how to consume the services provided by the device
Enhance the plug and play of devices and applications
Not Applicable
Information model ,semantics, TS-0023
Architecture, Resource, TS-0001
Primitives, TS-0004
Bindings, TS-0008/9/10…

8. Scope of Proximal IoT Interworking
Smart Home
Connected Vehicle
Industry
TS-0023
WI-0046
WI-0059
Interoperate
Interwork
TS-0001, Proximal IoT interworking
TS-0004, binding TSes
Interconnect

9. Way forward
Start from Smart Home, build an end to end interworking solution
Devices of Z-Wave, Zigbee, Bluetooth even proprietary protocol can be connected into oneM2M system, UNIFORMLY.
Keep working on information models on Connected Vehicles and Industry domain

10. Thanks