1. CMDH Policies Contribution: ARC-2014-xxxx
Source: Josef Blanz, Qualcomm UK,
Meeting Date: ARC 9.0,
Agenda Item: ARC (CMDH, Policies)

2. Clarification Response / Result
ARC CMDH_Policies

3. Response with or without Result
ARC CMDH_Policies

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

5. Example Configuration
AE1 trying to access remote resource
Resource hosted on CSE3, Mcc_1/Mcc_2 may be off-line
CSE1, CSE2 and CSE3 need to get involved
Multiple steps needed
Infrastructure Node
Middle Node
Application Service Node
AE1
CSE2
CSE3
CSE1
Mca_1
CMDH X
Mcc_1
Mcc_2
ARC CMDH_Policies

6. CMDH related Parameters in Requests
Request Expiration Time rqet
Result Expiration Time rset
Event Category ec
Delivery Aggregation da
ARC CMDH_Policies

7. Request Expiration Time
Acronym in request parameters is ‘rqet’
Definition in TS-0001: “optional request expiration timestamp”
rqet is the time after which a request is stale and can be purged
ARC CMDH_Policies

8. Result Expiration Time
Acronym in request parameters is ‘rset’
Definition in TS-0001: “optional result expiration timestamp”
rset is the time after which the result of an earlier requested operation is stale and can be purged
ARC CMDH_Policies

9. Event Category Acronym in request parameters is ‘ec’
Definition in TS-0001: “optional event category: Indicates the event category that should be used to handle this request. Event categories are impacting how Requests to access remotely hosted resources are processed in the CMDH CSF. Selection and scheduling of connections via CMDH are driven by policies that can differentiate event categories.”
A means to categorize the events that triggered a request
Each category has its own restrictions on how requests are buffered, 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
ARC CMDH_Policies

10. Delivery Aggregation ‘da’
IN (Infrastructure)
MN (Gateway)
IN-CSE
3G Network
ADN (Device) C
Local Connectivity
MN-CSE
M2M customer’s AE
AND-AE
CMDH
CMDH
New measurement #2 taken Originator: AND-AE; Receiver: MN-CSE; Target: IN-CSE Update //IN/C, ec = 3, rqet = 4:00 am
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, rqet = 4:00 am
Policies on MN say: For ec=3 => only from 2 am to 5 am
MN-CSE accepts and buffers request in CMDH
New measurement #24 taken Originator: AND-AE; Receiver: MN-CSE; Target: IN-CSE Update //IN/C, ec = 3, rqet = 4:00 am
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
CMDH in IN-CSE unwraps the contained requests, passes them to other CSFs (DMR)
IN-CSE produces all the requested UPDATES to C
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>, attributes: event category=3, lifespan={soonest of all buffered}
IN-CSE finds out it is the final target
Accepts request in IN-CSE’s CMDH
10:05 pm
10:00 pm
11:55 pm
02:00 am
Container Resource
ARC CMDH_Policies

11. Applying CMDH Policies (1)
MN (Gateway)
Rationale:
AE programmer should not be forced to know/understand rqet, rset, ec, da
AE can be very simple and not be burdened to include any of those parameters
Default values can be configured by experts in the actual deployed system
Advanced AE able to use specific parameter
ADN (Device)
Local Connectivity
MN-CSE
AND-AE
CMDH
Originator issues request that addresses a remote resource (not hosted on MN-CSE). Before MN-CSE can accept request, MN-CSE checks
if CMDH related parameters are set (rqet, rset, ec, da) ?
if (some) default values are needed ?
=> Which defaults should be used? Need policies to define defaults
ARC CMDH_Policies

12. Applying CMDH Policies (2)
MN (Gateway)
Rationale:
Requests must not be allowed to use arbitrary CMDH parameters
There needs to be a mechanism to provision what are allowed ranges
Otherwise there is no way to control what an Originator can ask for
ADN (Device)
Local Connectivity
MN-CSE
AND-AE
CMDH
desired values for rqet, [rset], ec, da
Now the desired CMDH related parameters (rqet, rset [if a result is needed], ec, da) for the current request are clear. But still, before MN-CSE can accept the request, it needs to further check
if CMDH related parameters are within allowed limits?
=> Which limits should be allowed? Need policies to define which allowed ranges
ARC CMDH_Policies

13. Applying CMDH Policies (3)
Rationale:
Local storage in MN-CSE may get full
Need to define how to handle buffering/purging of requests
Usage of underlying networks may be costly
Need to define when it is OK to use which network for which type of requests
May depend on schedules and other conditions
MN (Gateway)
ADN (Device)
Local Connectivity
MN-CSE
AND-AE
CMDH
applicable values for rqet, [rset], ec, da
Now the applicable CMDH related parameters (rqet, rset [if a result is needed], ec, da) for the current request are clear. But still, before MN-CSE can accept the request, it needs to further check
if request can be buffered locally?
if it is allowed to forward the request to the next CSE via any underlying network ?
=> Need policies to define the limits in usage of local storage and underlying networks
ARC CMDH_Policies

14. Applying CMDH Policies (4)
MN (Gateway)
3G Network
ADN (Device)
Local Connectivity
MN-CSE
AND-AE
CMDH
applicable values for rqet, [rset], ec, da
When all the checking is done and was successful
Request gets buffered
At an appropriate time the request will be forwarded
If forwarding is not successful, may get purged (rqet expired)
If buffer memory is exhausted, may get purged (storage priority)
ARC CMDH_Policies

15. Policies needed
Policies that define what are the appropriate default values in requests that do not set values for ec, rqet, rset, da. (provisioning of AE-specific, CSE-specific defaults needed)
Policies that define what are allowed limits for ec, rqet, rset, da. (provisioning of AE-specific, CSE-specific defaults needed)
Policies that express what are the boundaries for each event category that drive storage and scheduling decisions
Buffering
Storage priority (in what order do items get purged when needed)
Maximum amount of buffering allowed for a given event category
Minimum amount of buffering to trigger communication request
Network usage
Context conditions (e.g. minimum available battery level battery)
Allowed schedules for using underlying network communication technologies (LAN, WLAN, 2G, 3G, 4G etc)
Back-off timers in case of failed attempts (avoid flood of failing attempts)
ARC CMDH_Policies

16. CMDH Policy Types
ARC CMDH_Policies

17. CMDH-Policies Default Values
Define what CMDH parameters should be used for request if the Originator is not setting them
Defaults should be consolidated in a 3-tiered manner
Specific for a given AE
E.g. AE #3 is supposed to use ec=X, rqet=Y…
Specific for a particular CSE
apply to all entities making requests to this CSE that have no specific defaults
Common to a M2M SP
apply to all Originators that do not have any specific defaults
ARC CMDH_Policies

18. Example CMDH Policies: Defaults
Scope
Context Condition
Parameter
Default Value
App-Inst-ID “ ”
Battery < 10% ec 5
rqet 2h
rset 4h da On
Battery >= 10% 3 1h
Generically:
[App-ID |
App-Inst-ID | Any Local AE | CSE Internal]
Applicable Context Condition
0..N
{duration}
On/Off
ARC CMDH_Policies

19. CMDH-Policies Limit Values
Limits on what AEs (or CSFs) are allowed to request
Limits should be consolidated in a 3-tiered manner
Specific for AE
AE #3 is allowed to use ec=X, rqet=Y …
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
Originators can only expresses preferences that get checked against limits before becoming effective
ARC CMDH_Policies

20. Example CMDH Policies: Limits
Scope
Context Condition
Parameter
Limits
App-Inst-ID “ ”
Battery < 10% ec
5…10
rqet
1h…4h
rset
2h…4h da On
Battery >= 10%
3…10
30min…4h
On/Off
Generically:
[App-ID |
App-Inst-ID | Any Local AE | CSE Internal]
Applicable Context Condition
[N..M, X, Z …]
{duration range}
[On | Off | On/Off]
ARC CMDH_Policies

21. Buffering and 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)
May depend on context conditions
Buffering limits
e.g. minimum amount of data for certain ‘ec’ before forwarding
Maximum amount of data that can be buffered for certain ‘ec’
Storage priority in case requests need to be purged
ARC CMDH_Policies

22. Example CMDH Policies: Network
Context
Condition
Rule
2G Cellular
3G Cellular
4G Cellular
WLAN 1
Battery<=
10%
Schedule
never
always
Back-off
N/A
None
Min Volume
inf
0 KB
Battery>
All days, 2am – 5 am
5 min initial, add 5 min/failure
30 min max
8 KB 2
All days , 10 pm – 8 am
All days , 2am – 5 am
2 min initial, add 2 min/failure
12 min max
4 KB 3
Always
All days, 10 pm – 8 am
1 min initial, add 1 min/failure
10 min max
2 KB
ARC CMDH_Policies

23. Example CMDH Policies: Buffers
Rule
Value 1
Max Buffer
128 KB
Storage Priority 2
256 KB 5 3
512 KB 10
ARC CMDH_Policies

24. Proposal
Define 4 types of policy resources which are subject to provisioning
Scope
Context Condition
Parameter
Default Value
[App-ID |
App-Inst-ID | Any Local AE | CSE Internal]
Applicable Context Condition ec
0..N
rqet
{duration}
rset da
On/Off
Request Defaults
Scope
Context Condition
Parameter
Limits
[App-ID |
App-Inst-ID | Any Local AE | CSE Internal]
Applicable Context Condition ec
[N..M, X, Z …]
rqet
{duration range}
rset da
[On | Off | On/Off]
Request Limits
Event category / NW / Conditions
Rule
Value
0..N,
<NSE-ID/scope>, [Context Conditions]
schedule
<schedule>
backOff
{back-off rule}
minReqVolume
{data volume}
Network Usage Limits
Event category
Rule
Value
0..N
maxBuffer
{data volume}
Storage Priority P
Buffering Limits
ARC CMDH_Policies

25. Thank You
ARC CMDH_Policies

26. Additional Information
ARC CMDH_Policies

27. Related Requirements (1)
Req-ID
Description
OSR-011
The M2M System shall be able to request different communication paths, from the Underlying Network based on Underlying Network Operator and/or M2M Service Provider policies, routing mechanisms for transmission failures or request from M2M Applications.
OSR-013
The M2M System shall be aware of the delay tolerance acceptable by the M2M Application and shall schedule the communication accordingly or request the Underlying Network to do it, based on policies criteria.
OSR-015
The M2M System shall support different communication patterns including infrequent communications, small data transfer, large file transfer, streamed communication.
OSR-019
The M2M System shall support the capabilities for data repository (i.e. to collect/store) and for data transfer from one or more M2M Devices or M2M Gateways, for delivery to one or more M2M Gateways, M2M Services Infrastructure, or M2M Application Infrastructure, in ways requested by the M2M Application Infrastructure as listed below:
action initiated either by an M2M Device, M2M Gateway, M2M Services Infrastructure, or M2M Application Infrastructure
when triggered by schedule or event;
for specified data
OSR-020
The M2M System shall be able to support policies and their management regarding the aspects of storage and retrieval of data/information.
OSR-032
The M2M System shall be able to support Event Categories (e.g., normal, urgency) associated with data for M2M Applications when collecting, storing and reporting that data.
Note: Based on the Event Categories and via interworking with Underlying Networks, the M2M System can support differentiated services (by providing Quality-of-Service) requested by M2M Applications.
ARC CMDH_Policies

28. Related Requirements (2)
Req-ID
Description
OSR-033
Based on the Dynamic Device/Gateway Context of the M2M Gateway and/or Device and the defined Event Categories, the M2M System shall provide the capability to dynamically adjust the scheduling of reporting and notification of the M2M Device/Gateway.
Note: For example, if the battery of Gateway is remained only 10% or below, the Gateway notifies the M2M service platform of the status. The M2M Application in the Infrastructure node will adjust the scheduling of reporting and notification based on the Event Categories associated with each message. Consequently, the M2M Gateway operates longer.
OSR-044
The M2M System shall support communication with M2M Devices which are reachable based on defined time schedules (e.g. periodic) as well as M2M Devices which are reachable in an unpredictable and spontaneous manner.
OSR-063
The M2M System shall be able to manage the scheduling of M2M Service Layer connectivity and messaging between the Infrastracture Domain and M2M Devices/Gateways.
OSR-064
The M2M System shall be able to aggregate messages depending on message delay tolerance and/or category.
CRPR-002
The M2M System shall be able to support forwarding buffered messages depending on communication policies and based on service preference associated with the buffered messages.
CRPR-003
The M2M System shall enable an M2M Application to send a communication request with the following service preference:
QoS parameters, including delay tolerance, for initiating the delivery of data
categorizing communication requests into different levels of priority or QoS classes
CRPR-004
The M2M System shall be able to support concurrent processing of messages within M2M Gateways and/or M2M Devices from different sources with awareness for the service preference associated with the messages while observing the provisioned communication policies.
ARC CMDH_Policies