Service Framework Proposal Group Name: WG2 (ARC) Source: George Foti, Ericsson, George.Foti@ericsson.com Meeting Date: 2013-10-04 (ARC 7.0) Agenda Item: Service Framework Proposal

Requirement There needs to be a way to profile CSEs so that there is flexibility to cater to devices with different capabilities and vendor proprietary extensions including plugins

Analysis of Potential Options Standardizing a number of CSEs as means to accomplish the previous goals is one approach but is not sufficient. We need to support vendor specific CSFs We need to support plug-ins There needs to be a way to publish and discover these add-on/proprietary capabilities when they are deployed within a CSE

Service Framework Hierarchy (1 of 4) CSE Service Usage 1, API1 > CSF functions, <-> Resources Service Usage 2, API2 > CSF functions <-> Resources Service Usage 3, API3 > CSF functions <-> Resources CSF1 CSF2 CSF3 Function 1 Function 2 Function 3 Function 1 Function 2 Function 3 Function 4 Function 5 Function 1 Function 2 Function 3 Recommendations : A non-standardized CSE can publish its service usages, and APIs through a well known URL so it can be discovered Every CSE service usage must specify the list of CSFs used, as well as the Functions used per CSF. Every CSE must specify the resources managed by the CSE Conclusion: The CSE template must support the above

Service Framework Hierarchy (2 of 4) CSE Service Usage 1, API1 > CSF functions, <-> Resources Service Usage 2, API2 > CSF functions <-> Resources Service Usage 3, API3 > CSF functions <-> Resources CSF1 CSF2 CSF3 Function 1 Function 2 Function 3 Function 1 Function 2 Function 3 Function 4 Function 5 Function 1 Function 2 Function 3 Recommendations : Every service usage is represented by message flow Every message flow shall include in addition to the description of attributes, processing, etc. the following info for the target CSE: - The CSFs - The managed resources Conclusion: The message flow template must support the above

Service Framework Hierarchy (3 of 4) CSE Service Usage 1, API1 > CSF functions, <-> Resources Service Usage 2, API2 > CSF functions <-> Resources Service Usage 3, API3 > CSF functions <-> Resources CSF1 CSF2 CSF3 Function 1 (mandatory) Function 2(optional) Function 3 (optional) Function 1(Mandatory) Function 2 (Mandatory) Function 3 (optional) Function 4 (optional) Function 5 (optional) Function 1 (mandatory) Function 2(optional) Function 3 (optional) Recommendations : Each CSF Function manages one or more resource. These resources have to be clearly specified for every CSF. Each CSF must list the functions supported, whether it is mandatory or optional for the CSF, as well as the resources managed by every function Conclusion: The CSF template must support the above

Service Framework Hierarchy (4 of 4) CSE Service Usage 1, API1 > CSF functions, <-> Resources Service Usage 2, API2 > CSF functions <-> Resources Service Usage 3, API3 > CSF functions <-> Resources CSF1 CSF2 CSF3 Function 1 (mandatory) Function 2(optional) Function 3 (optional) Function 1(Mandatory) Function 2 (Mandatory) Function 3 (optional) Function 4 (optional) Function 5 (optional) Function 1 (mandatory) Function 2(optional) Function 3 (optional) Benefits: A vendor can define own his CSE profile (not defined by oneM2M) Can include proprietary CSFs, and have them discovered, using the above scheme Support Discovery of Plug-ins

Documentation Document *ALL* services usages, each represented by a message flow based on the above template approach. Profile a number of CSEs in terms of the service usages they would support Document Each CSE as described in the template