CMDH Policies Contribution: ARC-2014-0098R03-CMDH_Policies.ppt Source: Josef Blanz, Qualcomm UK,...
-
Upload
edwin-robbins -
Category
Documents
-
view
219 -
download
1
Transcript of 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)
Response with or without Result
ARC-2014-0098R03-CMDH_Policies
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
ARC-2014-0098R03-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 CSE3CSE1
Mca_1
CMDH CMDH CMDH
XMcc_2Mcc_1
ARC-2014-0098R03-CMDH_Policies
CMDH related Parametersin Requests
• Request Expiration Time rqet• Result Expiration Time rset• Event Category ec• Delivery Aggregation da
ARC-2014-0098R03-CMDH_Policies
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
Response CSE1 to AE1
CSE1 triggers forwarding request to CSE3
Request buffered on CSE1
CSE1 purges request
ARC-2014-0098R03-CMDH_Policies
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
Response CSE1 to AE1
CSE1 purgesrequest contextRequest AE1 to CSE1
T0
Response CSE1 to AE1
CSE3 receives original Request
Delivery of original request “in flight” to CSE3
t T2 T1
Delivery of Result “in flight” to CSE1
CSE3 sends Result
CSE1 receives Result
CSE1 purgesrequest contextRequest AE1 to CSE1
T0
Response CSE1 to AE1
CSE3 receives original Request
Delivery of original request “in flight” to CSE3
ARC-2014-0098R03-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-0098R03-CMDH_Policies
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
New measurement #2 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
New measurement #24 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
ARC-2014-0098R03-CMDH_Policies
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)
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
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)
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
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)
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
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)
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)
ARC-2014-0098R03-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-0098R03-CMDH_Policies
Example CMDH Policies: Defaults
ARC-2014-0098R03-CMDH_Policies
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
ARC-2014-0098R03-CMDH_Policies
Example CMDH Policies: Limits
ARC-2014-0098R03-CMDH_Policies
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:
[App-ID | App-Inst-ID |
Any Local AE | CSE Internal]
Applicable ContextCondition
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
ARC-2014-0098R03-CMDH_Policies
Example CMDH Policies: Network
ARC-2014-0098R03-CMDH_Policies
‘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
Back-off 2 min initial, add 2 min/failure12 min max
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
Back-off 1 min initial, add 1 min/failure10 min max
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
ARC-2014-0098R03-CMDH_Policies
‘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
ARC-2014-0098R03-CMDH_Policies
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
[App-ID | App-Inst-ID |
Any Local AE | CSE Internal]
Applicable ContextCondition
ec 0..N
rqet {duration}
rset {duration}
da On/Off
Scope Context Condition Parameter Limits
[App-ID | App-Inst-ID |
Any Local AE | CSE Internal]
Applicable ContextCondition
ec [N..M, X, Z …]
rqet {duration range}
rset {duration range}
da [On | Off | On/Off]
Related Requirements (1)
ARC-2014-0098R03-CMDH_Policies
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)
ARC-2014-0098R03-CMDH_Policies
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.