CMDH Policies Contribution: ARC-2014-xxxx Source: Josef Blanz, Qualcomm UK, jblanz@qti.qualcomm.com Meeting Date: ARC 9.0, 2014-02-17 Agenda Item: ARC (CMDH, Policies)

Clarification Response / Result ARC-2014-0097-CMDH_Policies

Response with or without Result ARC-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

CMDH related Parameters in Requests Request Expiration Time rqet Result Expiration Time rset Event Category ec Delivery Aggregation da ARC-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

CMDH Policy Types ARC-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

Example CMDH Policies: Defaults Scope Context Condition Parameter Default Value App-Inst-ID “98765432” 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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

Example CMDH Policies: Limits Scope Context Condition Parameter Limits App-Inst-ID “98765432” 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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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

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-2014-0097-CMDH_Policies

Thank You ARC-2014-0097-CMDH_Policies

Additional Information ARC-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies

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-2014-0097-CMDH_Policies