CMDH and Policies Contribution: oneM2M-ARC-0603 Source: Josef Blanz, Qualcomm UK, jblanz@qti.qualcomm.com Meeting Date: ARC 8.0, 2013-12-09 Agenda Item: ARC (CMDH) oneM2M-ARC-2013-0603

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-2013-0603

Clarification Response / Result oneM2M-ARC-2013-0603

Response with or without Result oneM2M-ARC-2013-0603

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-2013-0603

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

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

CMDH Parameters Lifespan Event Category oneM2M-ARC-2013-0603

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-2013-0603

‘et’ and ‘ls’ relationship oneM2M-ARC-2013-0603

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-2013-0603

Timeline in flow chart oneM2M-ARC-2013-0603

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-2013-0603

When is CMDH forwarding data? oneM2M-ARC-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

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-2013-0603

<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-2013-0603