Proximal IoT Interworking solution discussion Group Name: ARC/MAS Source: Jiaxin Yin, yinjiaxin@huawei.com, Huawei Technologies Co., Ltd. Meeting Date: 2017-5-22

Background oneM2M service layer is dealing with two directions Connect devices into the CSE Exposing device functions to the AEs All oneM2M defined CSFs are dealing with common services around connected devices oneM2M need resources to represent devices Resources need to be organized to be mapable to devices’ information model. Digital twins, Digital shadow, Device abstraction etc In oneM2M, let’s call it device representation

SmartHome Device Template Device template designed by HGI and transferred to oneM2M Strong proven of usage in SmartHome area

OSGi Device Abstraction Layer Device information model defined in OSGi

Device representation in oneM2M Core concept: Represent devices in oneM2M uniformly. No matter it’s oneM2M native device or oneM2M legacy device (NoDN). CSEBase Other resources that can be used to map to extended functions AccessControlPolicy AE container CSEBase subscription remoteCSE container group container pollingChannel contentInstance m2mServiceSubscriptionProfile subscription flexContainer request node timeSeries mgmtObj

Similarity and mapping among device templates Entity HGI SDT OSGi Suggested mapping in oneM2M Device Device, sub-device AE, remoteCSE, node Services ModuleClass Function Container, flexContainer - Actions Action FunctionOperation - Data reporting Data point FunctionData - Events Event FunctionEvent Subscription - Management and configuration deviceProperty Dmt Admin Service Device.property mgmtObj -

Mapping architecture IPE CSE CSE AE NoDN NoDN IPE Hosting CSE of the device representation NoDN IPE CSE non-oneM2M interface Mca CSE NoDN IPE non-oneM2M interface Mca AE Mcc Interworking mode Integration mode

Suggested mapping principle in oneM2M Mapping of device Use AE and remoteCSE for service plane Use node for management plane Not in favor of introducing a new resource type Overlapping with AE, remoteCSE and node resource Little value added on top of existing resources Regard sub-device as services provided by the device Nested Container and flexContainer for services provided by sub-device CSEBase AE container subscription Service plane container remoteCSE Sub-device as Service provided by the device container contentInstance subscription flexContainer node Management plane mgmtObj

Why reuse AE and CSE <AE> and <CSEBase> resource are used to represent oneM2M native device. <AE> or <container> resource are used to represent oneM2M legacy device. One IPE multiple AE, device is represented by AE One IPE multiple container, device is represented by container Seen from the application developer, it’s not important if the device is native or not. The only key part is: I see them uniformly.

Mapping principle for interworking mode Each NoDN is represented in Hosting CSE as AEs. NoDN is using IPE/Mca to sync up with Hosting CSE May have sync issues if Mca is remote Data reporting is mapped to container And data instance is mapped to contentInstance Action service is mapped via subscription and notification More efficient for sensor devices NoDN IPE Hosting CSE CSEBase AE registration AE Data reporting service container container Action service container Action callback Subscription Events Subscription Management node Management capabilities deviceInfo

Mapping principle for integration mode NoDN is syncing up with Hosting CSE using internal interfaces NoDN is expected to be collocated with Hosting CSE for sync up More efficient for actuating type of devices NoDN Hosting CSE CSEBase Data reporting service container container Action service container Events Subscription Management node Management capabilities deviceInfo

Mapping of service container -> General service May reserve some label to indicate difference of service Sub-device Action Data reporting flexContainer -> domain specific data models timeSeries -> series data reporting event -> subscription mgmtCmd -> RPC command mapping mgmtObj -> device/software management group -> group based operation locationPolicy -> location update policy Request, delivery -> CMDH pollingChannel -> long polling to solve NAT problem

Relationship with Proximal Interworking and other technical specific interworking Proximal IoT Interworking Methodology for device representation Using SDT as the target mapping information model Investigate how existing resources can be used for enforce SDT Technical Specific Interworking How to map information model used in “protocol” in device representation in oneM2M. OSGi Interworking Mapping of OSGi DAL, dmt admin to device representation OPC-UA interworking Modbus interworking OCF Interworking …

Conclusion Device representation in oneM2M Use AE and CSEBase/remoteCSE for service plane Use node for management plane Use container/ flexContainer for services provided by NoDN (data reporting, action, etc.) Use container/ flexContainer for sub-device Use nested container/ flexContainer for services provided by sub-device Use subscription for events

R01 added discussion points Start from an example A review of oneM2M defined AE and CSE Principle for device representation Conclusion

Example of smart home gateway Home gateway box device SmartHome APP Data reporting Smart home gateway device grouping Access control Actuating

Device representation in oneM2M CSEBase SmartHome AE Device AE Data reporting container Device AE Actuating container Group Access Control Policy

How interworking is done? oneM2M compliant NOT oneM2M compliant MN ADN ADN ? =

An overview of oneM2M defined AE and CSE AE is the abstraction of Application, the application could be application from device or application from IN-AE. AE is subject to service enrollment and assigned with an unique identifier which is further used for access control and service subscription CSE is the abstraction of common services provided by oneM2M. CSE is the common services provided to multiple AEs that may be shared or common to multiple AEs

Resource relationship principles If the service is for common usage, for example, commonly used group, rule engine, or context information using container, they should be represented under CSEBase If the service is pertaining to one application, and they are pertaining to one single enrollment identity, they should be created under AE.

Which is to say – for a device All devices should be represented using AE resource Same service enrollment identity High level wrapper of application logic Services provided by the device should be sub-resources of AE resource. Lifecycle pertaining to AE Ownership belong to AE <container> for data reporting of AE <subscription> for events of AE A node resource can be used to represent the metadata/ property of the device. Multiple AEs can be linked to node.

For device/gateway that provides common services Some of the industry gateways may provide common services that is reusable by multiple AEs Rule engine, access control policies, group managements etc. Which are not subject to any of the applications Independent lifecycle, ownership, enrollment It’s suggested to map such common services under <CSEBase> The gateway itself will be mapped to CSEBase

Where is IPE? IPE itself is an AE, may be registered as an <AE> resource for management purpose. IPE itself may register on behalf of other AEs to represent interworked NoDNs. How IPE is implemented is out of scope of oneM2M.

Conclusion Devices without common service is represented using AE as ADN Devices with common service is represented using CSE as ASN-CSE or MN-CSE Devices with both common service as well as dedicated service is represented using AE plus CSE as ASN or MN