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

2. Clarification Response / Result ARC-2014-0098R03-CMDH_Policies

3. Response with or without Result ARC-2014-0098R03-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-2014-0098R03-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 CSE2CSE3 CSE1 Mca_1 CMDH X Mcc_2Mcc_1 ARC-2014-0098R03-CMDH_Policies

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

10. CMDH in MN-CSE decides to forward buffered ec=3 requests Bundles them in a single payload, sends Request to IN-CSE CREATE ty=, 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 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 #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 #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 CMDH in IN-CSE unwraps the contained requests, passes them to other CSFs (DMR) IN-CSE produces all the requested UPDATES to C IN-CSE (DMR) notifies M2M Customer’s AE about new data in C 10:00 pm10:05 pm11:55 pm02:00 am Delivery Aggregation ‘da’ MN (Gateway) MN-CSE IN-CSE ADN (Device) Local Connectivity 3G Network AND-AE M2M customer’s AE C Container Resource IN (Infrastructure) CMDH ARC-2014-0098R03-CMDH_Policies

11. Applying CMDH Policies (1) ARC-2014-0098R03-CMDH_Policies 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 MN (Gateway) MN-CSE ADN (Device) Local Connectivity AND-AE CMDH 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

12. Applying CMDH Policies (2) ARC-2014-0098R03-CMDH_Policies 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 MN (Gateway) MN-CSE ADN (Device) Local Connectivity AND-AE CMDH 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 desired values for rqet, [rset], ec, da

13. Applying CMDH Policies (3) ARC-2014-0098R03-CMDH_Policies 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 MN (Gateway) MN-CSE ADN (Device) Local Connectivity 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

14. Applying CMDH Policies (4) ARC-2014-0098R03-CMDH_Policies 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) MN (Gateway) MN-CSE ADN (Device) Local Connectivity AND-AE CMDH applicable values for rqet, [rset], ec, da 3G Network

15. 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.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 2.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-0098R03-CMDH_Policies

16. CMDH Policy Types ARC-2014-0098R03-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-2014-0098R03-CMDH_Policies

18. Example CMDH Policies: Defaults ARC-2014-0098R03-CMDH_Policies ScopeContext ConditionParameterDefault Value App-Inst-ID “98765432”Battery < 10% ec5 rqet2h rset4h daOn App-Inst-ID “98765432”Battery >= 10% ec3 rqet1h rset2h daOn Generically: [App-ID | App-Inst-ID | Any Local AE | CSE Internal] Applicable Context Condition ec0..N rqet{duration} rset{duration} daOn/Off

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-2014-0098R03-CMDH_Policies

20. Example CMDH Policies: Limits ARC-2014-0098R03-CMDH_Policies ScopeContext ConditionParameterLimits App-Inst-ID “98765432”Battery < 10% ec5…10 rqet1h…4h rset2h…4h daOn App-Inst-ID “98765432”Battery >= 10% ec3…10 rqet30min…4h rset30min…4h daOn/Off Generically: [App-ID | App-Inst-ID | Any Local AE | CSE Internal] Applicable Context Condition ec[N..M, X, Z …] rqet{duration range} rset{duration range} da[On | Off | On/Off]

21. Buffering and Forwarding- related 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-0098R03-CMDH_Policies

22. Example CMDH Policies: Network ARC-2014-0098R03-CMDH_Policies ‘ec’Rule2G Cellular3G Cellular4G CellularWLAN 1 ScheduleAll days, 2am – 5 amnever always Back-off5 min initial, add 5 min/failure 30 min max N/A None Min Volume8 KBinf 0 KB 2 ScheduleAll days, 10 pm – 8 amAll days, 2am – 5 amneveralways Back-off2 min initial, add 2 min/failure 12 min max 5 min initial, add 5 min/failure 30 min max N/ANone Min Volume4 KB8 KBinf0 KB 3 ScheduleAlwaysAll days, 10 pm – 8 amneveralways Back-off1 min initial, add 1 min/failure 10 min max 2 min initial, add 2 min/failure 12 min max N/ANone Min Volume2 KB4 KBinf0 KB

23. Example CMDH Policies: Buffers ARC-2014-0098R03-CMDH_Policies ‘ec’RuleValue 1 Max Buffer128 KB Storage Priority1 2 Max Buffer256 KB Storage Priority5 3 Max Buffer512 KB Storage Priority10

24. Proposal ARC-2014-0098R03-CMDH_Policies Define 4 types of resources which are subject to provisioning Event category / NW / ConditionsRuleValue 0..N, schedule backOff{back-off rule} minReqVolume{data volume} Request Limits Network Usage Rules Event categoryRuleValue 0..N maxBuffer{data volume} Storage PriorityP Buffering Rules Request Defaults ScopeContext ConditionParameterDefault Value [App-ID | App-Inst-ID | Any Local AE | CSE Internal] Applicable Context Condition ec0..N rqet{duration} rset{duration} daOn/Off ScopeContext ConditionParameterLimits [App-ID | App-Inst-ID | Any Local AE | CSE Internal] Applicable Context Condition ec[N..M, X, Z …] rqet{duration range} rset{duration range} da[On | Off | On/Off]

25. Thank You ARC-2014-0098R03-CMDH_Policies

26. Additional Information ARC-2014-0098R03-CMDH_Policies

27. Related Requirements (1) ARC-2014-0098R03-CMDH_Policies Req-IDDescription OSR-011The 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-013The 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-015The M2M System shall support different communication patterns including infrequent communications, small data transfer, large file transfer, streamed communication. OSR-019The 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-020The M2M System shall be able to support policies and their management regarding the aspects of storage and retrieval of data/information. OSR-032The 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.

28. Related Requirements (2) ARC-2014-0098R03-CMDH_Policies Req-IDDescription OSR-033Based 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-044The 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-063The 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-064The M2M System shall be able to aggregate messages depending on message delay tolerance and/or category. CRPR-002The 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-003The 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-004The 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.