1. Service Framework Proposal
Group Name: WG2 (ARC)
Source: George Foti, Ericsson,
Meeting Date: (ARC 7.0)
Agenda Item: Service Framework Proposal

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

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

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

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

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

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

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