1. Proximal IoT Interworking solution discussion
Group Name: ARC/MAS
Source: Jiaxin Yin, Huawei Technologies Co., Ltd.
Meeting Date:

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

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

4. OSGi Device Abstraction Layer
Device information model defined in OSGi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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