CMDH Refinement Contribution: oneM2M-ARC-0397R01 Source: Josef Blanz, Qualcomm UK, jblanz@qti.qualcomm.com Meeting Date: ARC 6.7, 2013-10-03 Agenda Item: CSF definitions

CMDH: Refined Description Description of what CMDH is supposed to do Starts with simple UPDATE example Proposes Stage-2 message flow Does not cover protocol specific features (to discussed in WG3)

Access to local resource AE1 trying to access local resource: For instance an UPDATE to local resource Assumes that resource is hosted on CSE1 Request can be processed without help of other CSEs No need to involve CMDH on CSE1 or any other CSEs Y2 Infrastructure Node Middle Node Application Service Node AE1 CSE2 CSE3 Y1 CSE1 X CMDH UPDATE

Access to remote resource (1) AE1 trying to access remote resource: For instance an UPDATE to remote resource Assumes resource is hosted on CSE3, connectivity for Y1/Y2 may be off-line Request may contain preferences indicating ‘expiration time’, ‘event category’ CSE1, CSE2 and CSE3 need to get involved Multiple steps needed… see following slides Infrastructure Node Middle Node Application Service Node AE1 CSE2 CSE3 CSE1 X CMDH UPDATE Y1 Y2

Access to remote resource (2) AE1 making request to local CSE (=CSE1), CSE1 checks request and accepts it (other CSFs involved) Request is targeting another CSE (=CSE3) CMDH on CSE1 takes responsibility to deliver it Infrastructure Node Middle Node Application Service Node AE1 CSE2 CSE3 CSE1 X CMDH CSE1 accepts request CMDH on CSE1 responsible to deliver Y1 Y2

Access to remote resource (3) CMDH on CSE1 is forwarding request to CSE2 CMDH on CSE1 waits until it is OK to connect to CSE2 (policies: when/how) CSE2 checks request and accepts it (other CSFs involved) Request is targeting another CSE (=CSE3) CMDH on CSE2 to takes responsibility to deliver it Infrastructure Node Middle Node Application Service Node AE1 CSE2 CSE3 CSE1 X CMDH CMDH on CSE2 responsible to deliver CSE2 accepts request CSE1 establishes connection to CSE2 Y1 Y2

Access to remote resource (4) CMDH on CSE2 is forwarding request to CSE3 CMDH on CSE2 waits until it is OK to connect to CSE3 (policies: when/how) CSE3 checks request and accepts it (other CSFs involved) Request is targeting local CSE (=CSE3) Local CSE3 executes original request (UPDATE) Infrastructure Node Middle Node Application Service Node AE1 CSE2 CSE3 CSE1 X CMDH CSE3 executes UPDATE CSE3 accepts request CSE2 establishes connection to CSE3 Y1 Y2

Message Flow: Example Assumptions: Originator is AE1 Original request is an ‘UPDATE’ to a remote resource on CSE3 ‘UPDATE’ options selected such that no feedback from update operation was requested, i.e. AE decided that it does not need to hear back from CSE3 (expressed in mi) Delivery related parameters (to be discussed separately): Lifespan time (ls in mi) Event Category (ec in mi)

Resource Based CMDH Requesting a CSE to ‘deliver’ something could be done via a resource based service A CSE receiving such requests may have a simple path for that, e.g. /{CSE-base}/dh A resource type <delivery> is proposed to capture relevant delivery data and meta-data Possible actions: Request to Deliver something CREATE(to=/{CSE-base}/dh,fr={requesting-CSE},cn=data,mi={et, lifespan, eventCat, options}) or CREATE(to=/{CSE-base}/dh/{pref-ID},fr={requesting-CSE},cn=data,mi={et, lifespan, eventCat, options}) => If accepted, CSE responds with actual dhr-ID (possibly more data, depends on selected options) and executes on the delivery Request to retrieve status of delivery request RETRIEVE(/{CSE-base}/dh/{dhr-ID}) Request to change delivery parameters UPDATE(/{CSE-base}/dh/{dhr-ID}/lifespan, newLifespanValue, options) Request to delete / cancel a delivery request DELETE(/{CSE-base}/dh/{dhr-ID}, options) Delivery of data can be offered as a resource-based service in a RESTful manner

Message Flow (Resources) Assumptions: Originator is AE1 Original request is an ‘UPDATE’ to a remote resource on CSE3 ‘UPDATE’ options selected such that no feedback from update operation was requested, i.e. AE decided that it does not need to hear back from CSE3 (somehow expressed in mi) Delivery related parameters (to be discussed separately): Lifespan (ls in mi) Event Category (ec in mi)

Resource Type <delivery> Representing a request to deliver data from one CSE to another CSE CMDH on local CSE triggered by another local CSF: Starts delivery process and represents the context of the request in a <delivery> resource CMDH on first CSE forwards data to CMDH on second CSE (next hop): Request from first CSE to second CSE to create <delivery> resource on second CSE <delivery> resources can be managed with normal CRUD operations source: CSE that started delivery process target: Destination CSE for delivery of data lifespan: Time by which delivery should be completed / delivery can be purged eventCat: Category of event that triggered this delivery deliveryMetaData: Meta data on delivery process (status, parameters regarding encryption, tracing information ) data: Data to be delivered (includes original request)

Motivation Resource Type <request> CMDH description in clause 6.2.2.2 of TS 0001 already points out that “The content of the data provided by the requestor shall be opaque to the delivery handling function and shall not influence the behaviour of the CMDH. In particular, the CMDH CSF shall not be aware of the specific destination function (CSF) within the target entity including the parameters of such a function. For instance if the destination of the data to be delivered is a DMR CSF within a target entity (CSE, NSF, AF), the CMDH CSF shall not be aware of the DMR CSF including the specific storage location or other parameters pertaining to that DMR CSF. That means all attributes that are intended to be shared with the destination function (e.g., which CSF is the destination on the target entity, what that CSF should do with the data etc.) should be hidden from the CMDH CSF” Description of “Request Identifier (M2M-Request-ID)” in clause 7.1.7 of TS 0001 “This is an identifier that tracks a Request initiated by a CSE end to end. It is also included in the Response to the Request. The M2M-Request-ID is allocated by the CSE initiating the Request. The Request initiated by the CSE could be the result of an Application Request, or a Request initiated autonomously by the CSE to fulfil a service” When a request is targeting a remote CSE, the request needs to be put inside the data that gets delivered to the target CSE When delivery data reaches a target CSE, it needs to extract what the original request was When a result of a requested operation comes back from a target CSE to the originating CSE, the result may have to be stored for later access by the originator of the triggering request => definition of a resource type <request> CMDH on target CSE can forward the received data to other CSFs for unpacking the original request from the delivery data The target CSE can understand what the original request was and act on it

Resource Type <request> The ID of the <request> resource could simply be the M2M-Request-ID operation: Operation being requested, see op in clause 8.1 target: Targeted resource, see to in clause 8.1 originator: Entity that originated the request, see fr in clause 8.1 metaInformation: Meta information on the request (expiration time etc.), see mi in clause 8.1 Content: Content going to / coming from target, see cn in clause 8.1 requestStatus: Status of the request, see rs in clause 8.1 (e.q. accepted & pending) operationResult: Result of the requested operation, see cs in clause 8.1 (e.g resource created under URI xyz)