1. CMDH and Policies Contribution: oneM2M-ARC-0603
Source: Josef Blanz, Qualcomm UK,
Meeting Date: ARC 8.0,
Agenda Item: ARC (CMDH)
oneM2M-ARC

2. CMDH and Policies Clarification Recap of what CMDH is supposed to do
Request/Response vs. Operation/Result
Recap of what CMDH is supposed to do
Simple UPDATE example, no result expected
Using <delivery> resource
CMDH Parameters: Lifespan, Event Category
When is CMDH forwarding data?
How to organize policies?
How to consolidate policies?
oneM2M-ARC

3. Clarification Response / Result
oneM2M-ARC

4. Response with or without Result
oneM2M-ARC

5. Clarification AEs or CSEs are issuing Requests and get Responses
Originator sends Request
Receiver sends Response to it (blocking, non-blocking)
A Request (normally) asks to perform an Operation
E.g. CREATE a resource, UPDATE a resource
Response to a Request may or may NOT contain a Result of an Operation
Response may just be an ACK that CSE has accepted
Operation Result is not the same thing as a Response
oneM2M-ARC

6. Recap of CMDH Simple UPDATE example, no result expected
Using <delivery> resource
oneM2M-ARC

7. Access to remote resource (1)
AE1 trying to access remote resource: For instance an UPDATE
Resource hosted on CSE3, Mcc_1/Mcc_2 may be off-line
Request contains preferences ‘lifespan’, ‘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
Mca_1
CMDH
Originator: AE1; Receiver CSE1 Req(ReqID=AE1.1,op=UPDATE,to=CSE_3/X,data) X
Mcc_1
Mcc_2
oneM2M-ARC

8. 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
Originator: AE1; Receiver CSE1 Req( ReqID=AE1.1,op=UPDATE,to=CSE_3/X,data)
Infrastructure Node
Middle Node
Application Service Node
AE1
CSE2
CSE3
CSE1
Mca_1
CMDH
CSE1 accepts request
CMDH on CSE1 responsible to deliver X
Mcc_1
Mcc_2
oneM2M-ARC

9. Access to remote resource (3)
CMDH on CSE1 is forwarding data to CSE2
CMDH on CSE1 waits until it is OK to connect to CSE2 (policies)
CSE2 checks request and accepts it (other CSFs involved, target CSE3)
CMDH on CSE2 takes responsibility to deliver it
Originator: CSE1; Receiver CSE2 Req( ReqID=CSE1.1,op=CREATE,to=CSE_2, ty=<delivery>,encapsulated_data)
Infrastructure Node
Middle Node
Application Service Node
AE1
CSE2
CSE3
CSE1
Mca_1
CMDH
CMDH on CSE2 now responsible to deliver
CSE2 accepts request
CSE1 establishes connection to CSE2 X
Mcc_1
Mcc_2
CMDH
oneM2M-ARC

10. Access to remote resource (4)
CMDH on CSE2 is forwarding data to CSE3
CMDH on CSE2 waits until it is OK to connect to CSE3 (policies)
CSE3 checks request and accepts it (other CSFs involved, CSE3 is target)
Local CSE3 unwraps data executes original request (UPDATE)
Originator: CSE2; Receiver CSE3 Req( ReqID=CSE2.1,op=CREATE,to=CSE_3, ty=<delivery>,encapsulated_data)
Infrastructure Node
Middle Node
Application Service Node
AE1
CSE2
CSE3
CSE1
Mca_1
CMDH
CSE3 accepts request
CSE3 executes UPDATE
CSE2 establishes connection to CSE3 X
Mcc_1
Mcc_2
CMDH
oneM2M-ARC

11. Message flow Assumptions: Originator is AE1
Original request is an ‘UPDATE’ to a remote resource on CSE3
‘UPDATE’ options selected such that no result of update operation was requested, i.e. AE1 decided that it does not need to hear back from CSE3 (expressed in parameters)
Delivery related parameters:
Lifespan (ls)
Event Category (ec)
oneM2M-ARC

12. CMDH Parameters
Lifespan
Event Category
oneM2M-ARC

13. Lifespan Acronym in request parameters is ‘ls’
Determines how long the originator of a request is allowing for the delivery of request to the target CSE.
More then one request that need to be forwarded from source CSE to the same target CSE can be combined into a single delivery payload by using the <delivery> resource.
‘payload’ in this context means one or more encapsulated original requests that are then further processed at the target CSE
CMDH obey to ‘ls’ within limits dictated by provisioned CMDH policies
More on policies on later slides
‘ls’ and ‘et’ (expiration time) are different beasts (see next)
Important when a result of an operation needs to travel back
oneM2M-ARC

14. ‘et’ and ‘ls’ relationship
oneM2M-ARC

15. Summary ‘et’ and ‘ls’ Local context will be limited by ‘et’
If a result is expected to come back to local context, it will only be relevant if received before ‘et’ expires
Extension after result is received is possible by use of ‘rp’
‘Buffering & Flight time’ of outgoing request to remote CSE limited by ‘ls’
Needs to reach target CSE by ‘ls’
oneM2M-ARC

16. Timeline in flow chart
oneM2M-ARC

17. Event Category Acronym in request parameters is ‘ec’
A means to categorize the events that triggered a request
Each category has its own restrictions on when traffic for this event category is allowed to use which network
Those restrictions have to be expressed by provisioned CMDH policies per event category
Per underling network or network technology
Allowed schedules (time tables)
Rules to avoid excessive re-trying of delivery request (back-off timers)
Buffering limits per event category (minimum amount of data to justify triggering of connection, maximum amount that can be buffered)
oneM2M-ARC

18. When is CMDH forwarding data?
oneM2M-ARC

19. Scheduling Decisions
Requests will be associated with ‘ec’ and ‘ls’ values
Scheduling decisions should be driven by ‘ec’ & ‘ls’ for individual requests and provisioned CMDH policies
Need to differentiate
Policies that govern request limits
AE must not always ask for the most demanding (ls=now, ec=most costly)
AE need to be restricted in freedom to select
Policies that govern Forwarding and Network usage
CMDH needs to be instructed when it can use which network for what
oneM2M-ARC

20. Request-Limits Policies
Limits on what AEs (or even CSFs) are allowed to request
Limits should be consolidated in a 3-tiered manner
Specific for AE (AE #3 is allowed to use ec and ls of XYZ…)
Specific for a particular CSE (apply to all entities attached to this CSE that have no specific limits)
Common to a M2M SP (apply to all CSE that do not have any CSE-specific limits)
AEs only expresses preferences that get checked against limits of policies before becoming effective
If no preference for ‘ls’ or ‘ec’, default values shall be used
Defaults should also be defined in a 3-tiered manner
AE-specific, CSE-specific, M2M SP common
oneM2M-ARC

21. Example Policies: Request-Limits
Scope
Policy type
Values
AE1
ec-range
1-2
ls-range
>= 8 h
AE2
1-3
>= 15 min.
All other AE on CSE 1
> = 12 h
CSE-Internally generated requests (from other CSFs)
> = 1 min.
This set of policies is provisioned into a MN-CSE or ASN-CSE and was a result of a management entity in the Infrastructure Domain consolidating the 3-tiers for AE-limits
oneM2M-ARC

22. Forwarding-related policies
When are communication resources used
Time tables per underlying network technology when which ‘ec’ can be transported
May also include back-off times for failed attempts (function of number of failures)
Buffering limits (e.g. minimum amount of volume for certain ‘ec’ before forwarding)
oneM2M-ARC

23. Example Policies: Network
‘ec’
Policy type
2G Cellular
3G Cellular
4G Cellular
WLAN 1
Schedule
All days 2am – 5 am
never
always
Back-off
5 min initial add 5 min per failure
30 min max
N/A
None 2
All days 10 pm – 8 am
2 min initial add 2 min per failure
12 min max 3
Always
1 min initial add 1 min per failure
10 min max
oneM2M-ARC

24. Example Policies: Buffers
‘ec’
Policy type
Generic Value 2G 3G 4G
WLAN 1
Min Aggregated Volume To Trigger
2 KB
8 KB
inf
0 KB
Max Buffer
128 KB
N/A 2
2KB
32 KB
256 KB 3
4KB
16 KB
0KB
512 KB
Network specific minimum aggregation limits probably better to go into previous table
oneM2M-ARC

25. CMDH
IN (Infrastructure)
MN (Gateway)
IN-CSE
3G Network
ADN (Device) C
Local Connectivity
MN-CSE
M2M customer’s AE
AND-AE
CMDH
CMDH
CMDH in MN-CSE decides to forward buffered ec=3 requests
Bundles them in a single payload, sends Request to IN-CSE
CREATE ty=<delivery>, ec=3, ls={soonest of all buffered}
IN-CSE finds out it is the final target
Accepts request in IN-CSE’s CMDH
New measurement #24 taken Originator: AND-AE; Receiver: MN-CSE; Target: IN-CSE Update //IN/C, ec = 3, ls = 8h
Policies on MN say: For ec=3 => only from 2 am to 5 am
MN-CSE accepts and buffers request in CMDH
CMDH in IN-CSE unwraps the contained requests, passes them to other CSFs (DMR)
IN-CSE produces all the requested UPDATES to C
New measurement #2 taken Originator: AND-AE; Receiver: MN-CSE; Target: IN-CSE Update //IN/C, ec = 3, ls = 8h
Policies on MN say: For ec=3 => only from 2 am to 5 am
MN-CSE accepts and buffers request in CMDH
New measurement #1 taken Originator: AND-AE; Receiver: MN-CSE; Target: IN-CSE Update //IN/C, ec = 3, ls = 8h
Policies on MN say: For ec=3 => only from 2 am to 5 am
MN-CSE accepts and buffers request in CMDH
IN-CSE (DMR) notifies M2M Customer’s AE about new data in C
11:55 pm
10:00 pm
10:05 pm
02:00 am
Container Resource
oneM2M-ARC

26. <NSE-ID/scope>
Proposal
Define 4 types of policy resources which are subject to provisioning
Can then be used in managed objects by DMG/ASM to provision them into MN/ASN
Scope
Policy type
Value
[AE-ID | local AE | CSE]
ec-default
0..N
ls-default
{duration}
Request Defaults
Scope
Policy type
Value
[AE-ID | local AE | CSE]
ec-range
[u-v, x-y..]
ls-range
[Y<=] ls [<= X]
Request Limits
Event category / NW
Policy type
Value
0..N &
<NSE-ID/scope>
schedule
<schedule>
backOff
{back-off rule}
minReqVolume
{data volume}
Network Usage Limits
Event category
Policy type
Value
0..N
minReqVolume
{data volume}
maxBuffer
Buffering Limits
oneM2M-ARC