cmdh policies contribution: arc-2014-0098r03-cmdh_policies.ppt source: josef blanz, qualcomm uk,...

CMDH PoliciesContribution: ARC-2014-0098R03-CMDH_Policies.pptSource: Josef Blanz, Qualcomm UK, [email protected]

Hongbeom Ahn, LG Electronics, [email protected] Meeting Date: ARC 9.0, 2014-02-17Agenda Item: ARC (CMDH, Policies)

mailto:[email protected]

mailto:[email protected]

Clarification Response / Result

ARC-2014-0098R03-CMDH_Policies

Response with or without Result


Originator Receiver - 1

Request (operation = access resource)

CSE verifies Access Rights

If permitted, the CSE accesses the resouces

and responds with a Success or Failure

Response including result

Response (result = XXX)

Originator Receiver - 1

Request (access resource)

Response (Req-Ref)

More processing needed toget result to Originator….

CSE verifies Access Rights

accepts request

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


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 CSE3CSE1

Mca_1

CMDH CMDH CMDH

XMcc_2Mcc_1


CMDH related Parametersin Requests

• Request Expiration Time rqet• Result Expiration Time rset• Event Category ec• Delivery Aggregation da


Request Expiration TimeAcronym 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

Request AE1 to CSE1

T0 T1

Delivery of original request “in flight” to CSE3

Response CSE1 to AE1

CSE1 triggers forwarding request to CSE3

Request buffered on CSE1

CSE3 receives original Request

& acts on it

Request AE1 to CSE1

At time T0 a request is issued by AE1 to CSE1. Requests targets a resource on CSE3 and sets

‘rqet’ = T1

‘rt’ = ‘Acknowledge’‘rd’ = ‘local CSE’

When CSE1 accepts the request, it needs to establish some local context for it, e.g. in form of a <request> resource. The response to AE1

contains a reference to the local request context, so that AE could fetch a result or the

status of the request later on.

Request AE1 to CSE1

T0 T1

CSE1 is trying to communicate with next CSE but fails to reach it before T1


CSE1 triggers forwarding request to CSE3

Request buffered on CSE1

CSE1 purges request


Result Expiration TimeAcronym 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

t T2 T1

Delivery of Result “in flight” to CSE1

CSE3 sends Result

CSE1 receives Result

Request AE1 to CSE1

AE1 fetches Result


CSE1 purgesrequest contextRequest AE1 to CSE1

T0




t T2 T1

Delivery of Result “in flight” to CSE1

CSE3 sends Result

CSE1 receives Result

CSE1 purgesrequest contextRequest AE1 to CSE1

T0





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


CMDH in MN-CSE decides to forward buffered ec=3 requestsBundles them in a single payload, sends Request to IN-CSECREATE ty=<delivery>, attributes: event category=3, lifespan={soonest of all buffered}IN-CSE finds out it is the final targetAccepts request in IN-CSE’s CMDH

New measurement #1 takenOriginator: AND-AE; Receiver: MN-CSE; Target: IN-CSEUpdate //IN/C, ec = 3, rqet = 4:00 amPolicies on MN say: For ec=3 => only from 2 am to 5 amMN-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 AEabout new data in C

10:00 pm10:05 pm11:55 pm02:00 am

Delivery Aggregation ‘da’

MN (Gateway)

MN-CSE

IN-CSE

ADN (Device)

LocalConnectivity

3G Network

AND-AE

M2M customer’s AE

C

ContainerResource

IN (Infrastructure)

CMDH CMDH


Applying CMDH Policies (1)


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)

LocalConnectivity

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



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)

LocalConnectivity

AND-AE

CMDH

Rationale:

•Requests must not be allowed to use arbitraryCMDH 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 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)

LocalConnectivity

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



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)

LocalConnectivity

AND-AE

CMDH

applicable values for rqet, [rset], ec, da

3G Network

Policies neededA. 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)


CMDH Policy Types


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


Example CMDH Policies: Defaults


Scope Context Condition Parameter Default Value

App-Inst-ID “98765432” Battery < 10%

ec 5

rqet 2h

rset 4h

da On

App-Inst-ID “98765432” Battery >= 10%

ec 3

rqet 1h

rset 2h

da On

Generically:

[App-ID | App-Inst-ID |

Any Local AE | CSE Internal]

Applicable ContextCondition

ec 0..N

rqet {duration}

rset {duration}

da On/Off

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


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

App-Inst-ID “98765432” Battery >= 10%

ec 3…10

rqet 30min…4h

rset 30min…4h

da On/Off

Generically:




ec [N..M, X, Z …]

rqet {duration range}

rset {duration range}

da [On | Off | On/Off]

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


Example CMDH Policies: Network


‘ec’ Rule 2G Cellular 3G Cellular 4G Cellular WLAN

1

Schedule All days, 2am – 5 am never never always

Back-off 5 min initial, add 5 min/failure30 min max

N/A N/A None

Min Volume 8 KB inf inf 0 KB

2

Schedule All days , 10 pm – 8 am All days , 2am – 5 am never always


5 min initial, add 5 min/failure30 min max

N/A None

Min Volume 4 KB 8 KB inf 0 KB

3

Schedule Always All days, 10 pm – 8 am never always


2 min initial, add 2 min/failure12 min max

N/A None

Min Volume 2 KB 4 KB inf 0 KB

Example CMDH Policies: Buffers


‘ec’ Rule Value

1Max Buffer 128 KB

Storage Priority 1

2Max Buffer 256 KB

Storage Priority 5

3Max Buffer 512 KB

Storage Priority 10

Proposal


Define 4 types of resources which are subject to provisioning

Event category / NW / Conditions Rule Value

0..N,<NSE-ID/scope>

schedule <schedule>

backOff {back-off rule}

minReqVolume {data volume}

RequestLimits

NetworkUsageRules

Event category Rule Value

0..NmaxBuffer {data volume}

Storage Priority P

BufferingRules

RequestDefaults

Scope Context Condition Parameter Default Value




ec 0..N

rqet {duration}

rset {duration}

da On/Off

Scope Context Condition Parameter Limits




ec [N..M, X, Z …]

rqet {duration range}

rset {duration range}

da [On | Off | On/Off]

Thank You


Additional Information


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 Infrastructurewhen 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.

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.

cmdh policies contribution: arc-2014-0098r03-cmdh_policies.ppt source: josef blanz, qualcomm uk,...

Documents

arc cmdh

cmdh policiescontribution

cmdh csf

provisioned cmdh policies

request parameters

local request context

optional event category

nonblockinga request