CMDH Policies Contribution ARC2014 0098 R 03 CMDHPolicies

CMDH Policies Contribution: ARC-2014 -0098 R 03 -CMDH_Policies. ppt Source: Josef Blanz, Qualcomm UK, jblanz@qti. qualcomm. com Hongbeom Ahn, LG Electronics, hongbeom. ahn@lge. com Meeting Date: ARC 9. 0, 2014 -02 -17 Agenda Item: ARC (CMDH, Policies)

Clarification Response / Result ARC-2014 -0098 R 03 -CMDH_Policies

Response with or without Result ARC-2014 -0098 R 03 -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 -0098 R 03 -CMDH_Policies

Example Configuration • AE 1 trying to access remote resource • Resource hosted on CSE 3, Mcc_1/Mcc_2 may be off-line • CSE 1, CSE 2 and CSE 3 need to get involved • Multiple steps needed Infrastructure Node Application Service Node AE 1 Middle Node Mca_1 CSE 1 CMDH CSE 2 Mcc_1 CMDH ARC-2014 -0098 R 03 -CMDH_Policies CSE 3 Mcc_2 X CMDH

CMDH related Parameters in Requests • • Request Expiration Time rqet Result Expiration Time rset Event Category ec Delivery Aggregation da ARC-2014 -0098 R 03 -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 -0098 R 03 -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 -0098 R 03 -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 -0098 R 03 -CMDH_Policies

Delivery Aggregation ‘da’ IN (Infrastructure) MN (Gateway) IN-CSE 3 G Network ADN (Device) Local Connectivity MN-CSE C M 2 M customer’s AE AND-AE CMDH New CMDH IN-CSE measurement in (DMR) MN-CSE IN-CSE notifies unwraps decides #1 #2 M 2 M #24 taken the to. Customer’s forward contained buffered AE requests, ec=3 passes requests Originator: Bundles them about to new them other data AND-AE; in CSFs in a single C(DMR) Receiver: payload, MN-CSE; sends. Target: Request. IN-CSE to IN-CSE Update CREATEproduces IN-CSE //IN/C, ty=<delivery>, ecall= the 3, rqet attributes: requested = 4: 00 am event UPDATES category=3, to C Policies lifespan={soonest on MN say: of. For all ec=3 buffered} => only from 2 am to 5 am MN-CSE IN-CSE finds accepts out itand is the buffers finalrequest target in CMDH Accepts request in IN-CSE’s CMDH ARC-2014 -0098 R 03 -CMDH_Policies CMDH 10: 05 11: 55 10: 00 pm 02: 00 am Container Resource

Applying CMDH Policies (1) MN (Gateway) Rationale: ADN (Device) Local Connectivity MN-CSE AND-AE CMDH • 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 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 -0098 R 03 -CMDH_Policies

Applying CMDH Policies (2) MN (Gateway) Rationale: ADN (Device) Local Connectivity MN-CSE AND-AE CMDH • 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 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 -0098 R 03 -CMDH_Policies

Applying CMDH Policies (3) MN (Gateway) ADN (Device) Local Connectivity MN-CSE AND-AE CMDH 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 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 -0098 R 03 -CMDH_Policies

Applying CMDH Policies (4) MN (Gateway) 3 G 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 -0098 R 03 -CMDH_Policies

Policies needed A. 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) B. Policies that define what are allowed limits for ec, rqet, rset, da. (provisioning of AE-specific, CSE-specific defaults needed) C. Policies that express what are the boundaries for each event category that drive storage and scheduling decisions 1. 2. 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, 2 G, 3 G, 4 G etc) Þ Back-off timers in case of failed attempts (avoid flood of failing attempts) ARC-2014 -0098 R 03 -CMDH_Policies

CMDH Policy Types ARC-2014 -0098 R 03 -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 M 2 M SP • apply to all Originators that do not have any specific defaults ARC-2014 -0098 R 03 -CMDH_Policies

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

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

Buffering and Forwardingrelated policies • When are communication resources used – Time tables per underlying network technology when which ‘ec’ can be transported – back-off times for failed attempts (function of number of failures) – minimum amount of data for certain ‘ec’ before forwarding • Buffering limits – Maximum amount of data that can be buffered for certain ‘ec’ – Storage priority in case requests need to be purged ARC-2014 -0098 R 03 -CMDH_Policies

Example CMDH Policies: Network ‘ec’ Rule 2 G Cellular 3 G Cellular 4 G Cellular WLAN Schedule All days, 2 am – 5 am never always Back-off 5 min initial, add 5 min/failure 30 min max N/A None Min Volume 8 KB inf 0 KB Schedule All days , 10 pm – 8 am All days , 2 am – 5 am never always Back-off 2 min initial, add 2 min/failure 12 min max 5 min initial, add 5 min/failure 30 min max N/A None Min Volume 4 KB 8 KB inf 0 KB Schedule Always All days, 10 pm – 8 am never always Back-off 1 min initial, add 1 min/failure 10 min max 2 min initial, add 2 min/failure 12 min max N/A None Min Volume 2 KB 4 KB inf 0 KB 1 2 3 ARC-2014 -0098 R 03 -CMDH_Policies

Example CMDH Policies: Buffers ‘ec’ Rule 1 2 3 Value Max Buffer 128 KB Storage Priority 1 Max Buffer 256 KB Storage Priority 5 Max Buffer 512 KB Storage Priority 10 ARC-2014 -0098 R 03 -CMDH_Policies

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

Thank You ARC-2014 -0098 R 03 -CMDH_Policies

Additional Information ARC-2014 -0098 R 03 -CMDH_Policies

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

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