CSE Retargeting to AE, IPE, and NoDN Hosted Resources

Slides:



Advertisements
Similar presentations
Access Control Mechanism Discussion
Advertisements

SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
oneM2M-OIC Interworking Technical Comparison
Announcement Resources ARC Announcement_Issues Group Name: WG2 Source: Barbara Pareglio, NEC Meeting Date: Agenda Item: Input Contribution.
Introduction of PRO WG activities Group Name: TP Source: Shingo Fujimoto, FUJITSU, Meeting Date: Agenda Item:
PRO R01-URI_mapping_discussion Discussion on URI mapping in protocol context Group Name: PRO and ARC Source: Shingo Fujimoto, FUJITSU,
Fuctional Procedure for oiC interworking
Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.
Architectural Principles for Services Group Name: WG2- ARC Source: Tim Carey, ALU, Meeting Date: Agenda Item:
Customized Resource Types MAS Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date:
Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.
An introduction to oneM2M
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
LWM2M Interworking Group Name: Architecture
M2M Service Session Management (SSM) CSF
E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.
AFS/OSD Project R.Belloni, L.Giammarino, A.Maslennikov, G.Palumbo, H.Reuter, R.Toebbicke.
LWM2M Interworking Proxy Procedures ARC Considerations
Clarification of Access Control Mechanism on Rel-1 & Rel-2 Group Name: SEC ( ARC & PRO for information) Source: FUJITSU Meeting Date: Agenda.
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
ARC Possible_Collaboration_Area_with_OSGi.pptx Possible Collaboration Area with OSGi Group Name: ARC WG Source: Hiroyuki Maeomichi, NTT (TTC)
Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.1,
Background Data Transfer
3GPP R13 Small Data Delivery
Status of Active Work Items Level of Completeness
Resource subscription using DDS in oneM2M
oneM2M interop 3 issues and optimizations
IoT Integration Patterns, REST, and CoAP
3GPP MBMS protocol stack
Service Framework Proposal
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
Service Enabled AE (SAE)
End-to-End Security for Primitives
Proximal IoT Interworking discussion
Group multicast fanOut Procedure
WG2 - ARC TP#29 Status Report
2nd Interoperability testing issues
PANA Issues and Resolutions
Possible options of using DDS in oneM2M
Discussion about Use Case and Architecture in Developer Guide
Modbus interworking Group Name: ARC
NIDD Discussion Points
Proposed design principles for modelling interworked devices
Release Timeline Discussion R2 and beyond
oneM2M Service Layer Protocol Version Handling
MAF&MEF Interface Specification discussion of the next steps
WPM ad-hoc group report TP#25
WG2 - ARC TP#29 Status Report
Proximal IoT Interworking solution discussion
Bert Greevenbosch, ACE comparison Bert Greevenbosch, draft-greevenbosch-ace-comparison.
Discussion to clarify online/offline behavior
oneM2M Versioning Next Steps
ARC Proposed design principles for modelling services, datapoints and operations Group Name: ARC Source: Joerg Swetina, NEC
LWM2M Interworking with <mgmtObj> Resources
CMDH Refinement Contribution: oneM2M-ARC-0397R01
Service Layer Dynamic Authorization [SLDA]
Development Guideline for oneM2M Products and Services
An introduction to oneM2M
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Summary of the MAF and MEF Interface Specification TS-0032
oneM2M interop 6 action point
Notification Target Discussion
Presentation transcript:

CSE Retargeting to AE, IPE, and NoDN Hosted Resources Other suggested titles: “Benefits of oneM2M Standardization” Group Name: ARC WG Source: Dale Seed, Convida Wireless (Seed.Dale@ConvidaWireless.com) Meeting Date: 2017-03-16 (ARC27.2)

Currently in oneM2M … A CSE can only send two types of requests to AEs and IPEs  Notifications and IPE Discovery requests An AE or IPE cannot host local resources. It must mirror locally hosted resources into the CSE A CSE cannot send / retarget CRUD requests to an AE or IPE Local Resources CSE AE / IPE Notification IPE Discovery CRUD x

So why do we care? oneM2M developers want more end-to-end transparency in the oneM2M system E.g. They want to be able to host their own resources on their IoT devices just like other RESTful technologies allow them to do Provide more flexibility and optimization for some oneM2M deployments. E.g. For interworking oneM2M with other RESTful technologies that allow devices to host their own resources. E.g. Deployments requiring lower end-to-end latency request handling Examples of some other RESTful technologies that allow device apps to host their own resources include OCF, LWM2M, many CoAP based IoT deployments

So why not just use a ASN-CSE? ASN-AE + ASN-CSE AE MN-CSE  An ASN-CSE can host its own resources and can receive CRUD requests from other CSEs. So why not just use an ASN-CSE + ASN-AE in a device instead of adding support to oneM2M for retargeting CRUD requests to AEs and IPEs?

Comparison MN-CSE MN-CSE IPE Pros: Pros: Cons: Cons: ADN-AE AE AE ASN-AE + ASN-CSE AE MN-CSE Pros: No changes to oneM2M architecture Allows devices to host their own resources Cons: Increased complexity / impact to a device – A device must support at least a minimal set of CSE features Must support CSE-ID, AE-ID and App-ID Must support oneM2M Mcc Security Must support CSE Registration Must support an increased number of oneM2M resource types and logic (CSEBase, remoteCSE, AE, container, contentInstance, flexContainer, …) Must support an increased number of oneM2M primitives types and procedures For any resources that ASN-CSE hosts its responsible for Providing its own ACPs to secure access Providing its own oneM2M resource discovery Providing its own group management Providing its own non-blocking request handling Providing its own sub/not management - MN-CSE Retargeting to ASN-CSE ADN-AE AE MN-CSE IPE NoDN Pros: Allows devices to host their own resources without mirroring and without having to support CSE functionality Allows devices to reap the benefits of oneM2M services without the added overhead Devices can host a minimal set of oneM2M resources (e.g. container, contentInstance, or flexContainer) Provides end-to-end transparency and reduced latency Still allows an MN-CSE to provide value-add oneM2M services to devices such as the following Credential management and authentication of Originators accessing resources hosted on device Authorization of access to resources hosted on device Discovery of resources hosted on device Store and forwarding of requests targeting resources hosted on device based on device’s reachability Fanout of a request targeting a group of resources hosted on a device Sub/Not management of resources hosted on a device Caching of resources hosted on a device Non-blocking request handling for resources on device Cons: Requires some changes to existing oneM2M architecture Changes can be minimal however - MN-CSE Retargeting to AE / IPE / NoDN

Example Use Case ADN-AE AE MN-CSE

Mirroring Example AE MN-CSE Without support for re-targeting requests to AEs, oneM2M can be “chatty” and require increased messaging. This makes oneM2M more complex and less efficient. ADN-AE AE MN-CSE CREATE Door <AE> Response CREATE Door Lock <container> 12 messages required for initialization Response Lack of transparency requires separate containers for command and status CREATE <subscription> on Door Lock Command <container> Response CREATE Door Lock Status <container> Response Discover Door <AE> and <container> resources Response CREATE <subscription> on Door Lock Status <container> Response Create <contentInstance> with Lock Door Command 8 messages required to lock door NOTIFY with Door Lock Command <contentInstance> Response Response CREATE <contentInstance> for Door Lock status Response NOTIFY with Door Lock Status <contentInstance> Response Mirroring of ADN-AE resources into CSE has an overhead associated with it (Complexity & Latency) Not an ideal fit for all use cases

Other Mirroring Concerns Another concern with oneM2M and its ability to scale down for use with lightweight IoT Devices is the message size overhead of oneM2M. Many IoT devices have very small message payload requirements. Adding even a small number of bytes can translate into a significant overhead on the device. Mirroring resources of an IoT device into oneM2M resources typically results in a level of encapsulation and overhead IoT device resource is encapsulated into oneM2M resource (e.g. container, contentInstance, flexContainer, mgmtObj, etc) The use of notifications for relaying updates of mirrored resources back to IoT devices results in yet another layer of encapsulation and added overhead introduced by the elements of the notification. Retargeting of requests to AE / IPE can help minimize encapsulation overhead oneM2M notification elements oneM2M contentInstance attributes Content (IoT resource data)

Retargeting to an ADN-AE MN-CSE Only 4 messages required for initialization CREATE Door <AE> [ADN-AE’s Door Lock flexContainer Info] Response DISCOVER Door <AE> Response [ADN-AE’s Door Lock flexContainer Resource Info] Transparency allows command and status in one request/ response exchange UPDATE Request to ADN-AE’s flexContainer to lock door Retargeted UPDATE Request to ADN-AE’s flexContainer to lock door Retargeting Response [ADN-AE’s Door Lock flexContainer Representation] Retargeted Response [ADN-AE’s Door Lock flexContainer Representation] Only 4 messages required for locking the door Retargeting can also involve value-add services such as ACP checks, store-and-forwarding, scheduling, group fanout, caching, sub/not handling, etc.  Retargeting can reduce the messaging overhead (no notifications needed) and latency in the system  Reducing messaging overhead can make system less complex and provide better performance

Non-oneM2M Device Node (NoDN) Interworking Example Non-oneM2M Device Node (NoDN) IPE MN-CSE AE Retargeting of requests to IPEs can also reduce complexity of IPEs and optimize interworking of oneM2M with other technologies

The CSE can re-target CRUD requests to an IPE and in turn a NoDN Retargeting to an IPE NoDN AE IPE MN-CSE Publish Door Lock Resource Discovery Info CREATE Door <AE> [ADN-AE’s Door Lock flexContainer Info] Response DISCOVER Door <AE> Response Response [ADN-AE’s Door Lock flexContainer Resource Info] The CSE can re-target CRUD requests to an IPE and in turn a NoDN UPDATE Request to ADN-AE’s flexContainer to lock door Retargeted UPDATE Request to ADN-AE’s flexContainer to lock door Retargeted UPDATE Of Door Lock Resource [OCF Compliant Door Lock Resource Representation to unlock door] Retargeting Retargeting Response [OCF Compliant Door Lock Resource Representation] Response: [ADN-AE’s Door Lock flexContainer Representation] Retargeted Response: [ADN-AE’s Door Lock flexContainer Representation]

Link Descriptions (FFS) For RESTful technologies like OCF, LWM2M, CoAP, etc. they are making use of standardized link descriptions coming out of the IETF. Link descriptions describe each resource hosted by a device. E.g. Its URI, its interface (i.e. read only, read/write, etc), it access control policies, its supported protocols Its conceivable that oneM2M could support interworking to this standardized link description format defined by IETF and support retargeting CRUD requests to resources hosted by ADN-AEs, IPEs, NoDN

Retargeting to a NoDN (FFS) In addition to the IPE based approach of interworking, oneM2M could even consider defining functionality native to a CSE to interwork with NoDN IETF Link Descriptions Non-oneM2M Device Node MN-CSE NoDN AE Retargeting AE  Given that many emerging IoT technologies (e.g., OCF, LWM2M, CoAP-based deployments, etc) are aligning themselves with RESTful design principles, it may even be possible for oneM2M to define a generic enough framework within the CSE to allow re-targeting of requests to these types of RESTful NoDN without the need for a technology specific IPEs!!! [Requires further study and analysis]

Retargeting to a NoDN (FFS) MN-CSE NoDN (E.g. OCF) AE NoDN AE Retargeting Publish Door Lock Resource Discovery Info that includes interface definitions Response DISCOVER Door <AE> For RESTful technologies like OCF, LWM2M, CoAP, etc. it may even be possible for a CSE to re-target CRUD requests directly to NoDN without an IPE Response [Door Lock Link Description] UPDATE AE Door Lock Resource [Door Lock Resource Representation compliant with format specified in Link Description (e.g. OCF format)] Retargeted UPDATE Request of Door Lock Resource [OCF Compliant Door Lock Resource Representation to unlock door] Retargeting Response [OCF Compliant Door Lock Resource Representation] Retargeted Response [OCF Compliant Door Lock Resource Representation]

Next Steps? Reach consensus to add support in Rel-3 for re-targeting of requests from a CSE to oneM2M resources hosted by an AE or IPE Proposal is to allow AE or IPE to host a small subset of resource types that are well suited for interaction with telemetry (sensors) and control (actuators) kinds of devices. E.g. containers, contentInstances or flexContainers Proposal is to include this work as part of WI-0056 - Evolution of Proximal IoT Interworking FFS – Have a closer look at Link Descriptions defined by IETF and being used by SDOs like OCF See if support within oneM2M makes sense Could be a simple/lightweight way to enable a oneM2M CSE to interwork with NoDN hosting non-oneM2M resources Proposal is to target this work for Rel-4