1. CMDH Refinement Contribution: oneM2M-ARC-0397R01
Source: Josef Blanz, Qualcomm UK,
Meeting Date: ARC 6.7,
Agenda Item: CSF definitions

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

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

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

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

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

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

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

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

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

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

12. Motivation Resource Type <request>
CMDH description in clause 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 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

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