Proximal IoT Interworking discussion Group Name: ARC#27 Source: Jiaxin Yin, yinjiaxin@Huawei.com, Huawei Technologies Co., Ltd. Meeting Date: 2017-2-13 Agenda Item:TBD

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?

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

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

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..

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?

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…

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

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

Thanks