Skip to content
Snippets Groups Projects
Commit 64b3fc53 authored by Andreas Kraft's avatar Andreas Kraft
Browse files

Initial markdown conversion of TS-0002

parent be70ea31
No related branches found
No related tags found
1 merge request!1RDM-2024-0016-TS-0002_New_Baseline_5_2_1_-_Markdown_Conversion
Hide whitespace changes
Inline Side-by-side
TS-0002-oneM2M-Requirements.md
+ 755
− 113
View file @ 64b3fc53
![logo](media/image1.png)
![~~CAPTION~~](media/logo.png)
|oneM2M<br/>Technical Specification |oneM2M<br />Technical Specification |
|-|-|
|Document Number |TS-0002-V-0.0.1 |
|Document Name: |Requirements |
|Date: |&lt;20yy-mm-dd> |
|Abstract: |&lt; An abstract of the specification and information that may be used in subsequent electronic searches> |
|Template Version: | January 2020 (do not modify) |
| **oneM2M**<br />**Technical Specification** | **oneM2M**<br />**Technical Specification** |
| ------------------------------------------- | ------------------------------------------------------------ |
| Document Number | TS-0002-V5.2.1 |
| Document Name: | Requirements |
| Date: | 2023-Dec-14 |
| Abstract: | The present document contains an informative functional role model and normative technical requirements for oneM2M. |
The present document is provided for future development work within oneM2M only. The Partners accept no liability for any use of this specification.
This Specification is provided for future development work within oneM2M only. The Partners accept no liability for any use of this Specification.
The present document has not been subject to any approval process by the oneM2M Partners Type 1. Published oneM2M specifications and reports for implementation should be obtained via the oneM2M Partners' Publications Offices.
The present document has not been subject to any approval process by the oneM2M Partners Type 1. Published oneM2M specifications and reports for implementation should be obtained via the oneM2M Partners' Publications Offices.
<br />About oneM2M
About oneM2M
The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
More information about oneM2M may be found at: http//www.oneM2M.org
More information about oneM2M may be found at: http//www.oneM2M.org
Copyright Notification
(c) 2020, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
No part of this document may be reproduced, in an electronic retrieval system or otherwise, except as authorized by written permission.
All rights reserved.
The copyright extends to reproduction in all media.
The copyright and the foregoing restriction extend to reproduction in all media.
(c) 2016, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
All rights reserved.
Notice of Disclaimer & Limitation of Liability
Notice of Disclaimer & Limitation of Liability
The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied.
The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied.
NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER.
# Contents
# 1 Scope
The present document ...
# Contents
`EXAMPLE: The present document provides the necessary adaptions to the endorsed document.`
<mark>The Scope **shall not** contain requirements.</mark>
# 1 Scope
The present document contains an informative functional role model and normative technical requirements for oneM2M.
# 2 References
## 2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies.
<mark>The following text block applies.</mark>
The following referenced documents are necessary, partially or totally, for the application of the present document. Their use in the context of this TS is specified by the normative statements that are referring back to this clause.
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references,only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
<mark>Clause 2.1 only shall contain normative (essential) references which are cited in the document itself. These references have to be publicly available and in English.</mark>
- <a href="#_ref_1">[1]</a> 3GPP TS 22.368: "Service requirements for Machine-Type Communications (MTC); Stage 1".
The following referenced documents are necessary, partially or totally, for the application of the present document. Their use in the context of this TS is specified by the normative statements that are referring back to this clause.
## 2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies.
- Use the **EX** style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
`EXAMPLE:`
- <a name="_ref_1">[1]</a> ETSI TR 102 473: "&lt;Title>".
- <a name="_ref_i.1">[i.1]</a> oneM2M Drafting Rules.
> NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
- <a name="_ref_i.2">[i.2]</a> oneM2M TS-0011: "Common Terminology".
- <a name="_ref_i.3">[i.3]</a> oneM2M TR-0008: "Security Analysis".
- <a name="_ref_i.4">[i.4]</a> oneM2M TR0001: "Use Cases"
- <a name="_ref_i.5">[i.5]</a> ETSI TR 103 546 "SmartM2M: Requirement & Feasibility study for Smart Lifts in IoT"
- <a name="_ref_i.6">[i.6]</a> ETSI TR 103 714 SmartM2M; Study for oneM2M Discovery and Query use cases and requirements
## 2.2 Informative references
<mark>The following text block applies.</mark>
# 3 Definitions and abbreviations
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references,only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
## 3.1 Definitions
<mark>Clause 2.2 shall only contain informative references which are cited in the document itself.</mark>
For the purposes of the present document, the terms and definitions given in oneM2M TS-0011 <a href="#_ref_i.2">[i.2]</a> apply.
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
## 3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
- Use the **EX** style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references).
- <a href="#_ref_i.1">[i.1]</a> oneM2M Drafting Rules (http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf)
`AE Application Entity`
`API Application Program Interface`
`BBF BroadBand Forum`
`CHA Continua Health Alliance`
`CPU Central Processing Unit`
`DM Device Management`
`GBA Generic Bootstrapping Architecture`
`GSMA Global System for Mobile Communications Association`
`GW Gateway`
`HGI Home Gateway Initiative`
`HSM Hardware Security Module`
`IP Internet Protocol`
`MTC Machine Type Communications`
`OMA Open Mobile Alliance`
`OSR Overall System Requirements`
`OWL Web Ontology Language`
`QoS Quality of Service`
`RDF Resource Description Framework`
`SMS Short Message Service`
`UICC Universal Integrated Circuit Card`
`USIM UMTS Subscriber Identity Module`
`USSD Unstructured Supplementary Service Data`
`WAN Wide Area Network`
`WLAN Wireless Local Area Network`
<mark>Delete from the below heading the word(s) which is/are not applicable.</mark>
# 3 Definition of terms, symbols and abbreviations
# 4 Conventions
## 3.1 Terms
The keywords "shall", "shall not", "should", "should not", "may", "need not" in the present document are to be interpreted as described in the oneM2M Drafting Rules <a href="#_ref_i.1">[i.1]</a>.
<mark>Clause numbering depends on applicability.</mark>
> NOTE: According to oneM2M Drafting Rules <a href="#_ref_i.1">[i.1]</a> in order to mandate a feature in the oneM2M System but allow freedom to the individual deployment whether to use it or not subsequently requirements are often formulated like:
<mark>- A definition shall not take the form of, or contain, a requirement.</mark>
<mark>- The form of a definition shall be such that it can replace the term in context. Additional information shall be given only in the form of examples or notes (see below).</mark>
<mark>- The terms and definitions shall be presented in alphabetical order.</mark>
> - "The oneM2M System shall **support a mechanism** [function, capability...] **to** ..."; or
> - "...shall **be able to** ...".
>
> This does not mandate usage of the required feature in a M2M Solution.
For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:
<mark>Definition format</mark>
# 5 Introduction to the M2M ecosystem
&lt;defined term>: &lt;definition>
## 5.1 Functional roles description
<mark>If a definition is taken from an external source, use the format below where [N] identifies the external document which must be listed in Section 2 References.</mark>
&lt;defined term>[N]: &lt;definition>
![Functional Roles in the M2M Ecosystem](/Users/akr/Sources/git/ts-0002/media/Functional_Roles.png)
example 1: text used to clarify abstract rules by applying them literally
**Figure 1: Functional Roles in the M2M Ecosystem**
> NOTE: This may contain additional information.
1. The **_User_** (individual or company - aka: end-user) fulfils all of the following criteria:
## 3.2 Symbols
- Uses an M2M solution.
<mark>Clause numbering depends on applicability.</mark>
1. The _Application Service Provider_ fulfils all of the following criteria:
For the purposes of the present document, the [following] symbols [given in ... and the following] apply:
- Provides an M2M Application Service.
- Operates M2M Applications.
<mark>Symbol format</mark>
1. The _M2M Service Provider_ fulfils all of the following criteria:
&lt;symbol> &lt;Explanation>
&lt;2nd symbol> &lt;2nd Explanation>
&lt;3rd symbol> &lt;3rd Explanation>
- Provides M2M Services to Application Service Providers.
- Operates M2M Common Services.
1. The _Network Operator_ fulfils all of the following criteria:
## 3.3 Abbreviations
- Provides _Connectivity_ and related services for _M2M Service Provider_ _s_ _._
- Operates an _Underlying Network_ . Such an Underlying Network could e.g. be a telecom network.
<mark>Abbreviations should be ordered alphabetically.</mark>
Any of the above functional roles may coincide with any of the other roles. These functional roles do not imply business roles or architectural assumptions.
<mark>Clause numbering depends on applicability.</mark>
For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:
# 6 Functional Requirements
<mark>Abbreviation format</mark>
## 6.1 Overall System Requirements
**Table 1: Overall System Requirements**<a name="table_1"></a>
&lt;ABREVIATION1> &lt;Explanation>
&lt;ABREVIATION2> &lt;Explanation>
&lt;ABREVIATION3> &lt;Explanation>
# 4 Conventions
|Requirement ID |Description |Release |
|-|-|-|
|OSR-001 |The oneM2M System shall allow communication between M2M Applications by using multiple communication means based on IP access. |Implemented in Rel-1 |
|OSR-002a |The oneM2M System shall support communication means that can accommodate devices with constrained computing (e.g. small CPU, memory, battery) or communication capabilities (e.g. 2G wireless modem, certain WLAN node). |Implemented in Rel-1 |
|OSR-002b |The oneM2M System shall support communication means that can accommodate devices with rich computing capabilities (e.g. large CPU, memory) or communication (e.g. 3/4G wireless modem, wireline). |Implemented in Rel-1 |
|OSR-003<br />See REQ-2015-0626R01 |The oneM2M System shall support the ability to maintain application-to-application communication in coordination with an application session for those M2M Applications that require it. |Not implemented |
|OSR-004 |The oneM2M System shall support session-less application communications for those M2M Applications that require it. |Implemented in Rel-1 |
|OSR-005 |The oneM2M System shall be able to expose the services offered by telecommunications networks to M2M Applications (e.g. SMS, USSD, localization, subscription configuration, authentication (e.g. Generic Bootstrapping Architecture), etc.),subject to restriction based on Network Operator's policy. |Partially implemented <br />(see note 9) |
|OSR-006 |The oneM2M System shall be able to reuse the services offered by Underlying Networks to M2M Applications and/or M2M Services by means of open access models (e.g. OMA, GSMA OneAPI framework). Examples of available services are:<br />- IP Multimedia communications.<br />- Messaging.<br />- Location.<br />- Charging and billing services.<br />- Device information and profiles.<br />- Configuration and management of devices.<br />- Triggering, monitoring of devices.<br />- Small data transmission.<br />- Group management.<br />(see note 1). |Partially implemented <br />(see note 10) |
|OSR-007 |The oneM2M System shall provide a mechanism for M2M Applications to interact with the Applications and data/information managed by a different M2M Service Provider, subject to permissions as appropriate. |Implemented in Rel-1 |
|OSR-008 |The oneM2M System shall provide the capability for M2M Applications to communicate with an M2M Device (i.e. application in the device) without the need for the M2M Applications to be aware of the network technology and the specific communication protocol of the M2M Device. |Implemented in Rel-1<br />(see note 11) |
|OSR-009 |The oneM2M System shall support the ability for single or multiple M2M Applications to interact with a single or multiple M2M Devices/Gateways (application in the device/gateway) (see note 2). |Implemented in Rel-1 |
|OSR-010 |The oneM2M System shall support mechanisms for confirmed delivery of a message to its addressee to those M2M Applications requesting reliable delivery to detect failure of message within a given time interval. |Implemented in Rel-1 |
|OSR-011a |The oneM2M 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. |Implemented in Rel-1<br />(see note 12) |
|OSR-011b |The oneM2M System shall be able to request different communication paths from the Underlying Network based on request from M2M Applications. |Not implemented |
|OSR-012 |The oneM2M System shall support communications between M2M Applications and M2M Devices supporting M2M Services by means of continuous or non-continuous connectivity. |Implemented in Rel-1 |
|OSR-013 |The oneM2M 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. |Implemented in Rel-1 |
|OSR-014 |The oneM2M System shall be able to communicate with M2M Devices, behind an M2M Gateway that supports heterogeneous M2M Area Networks. |Implemented in Rel-1 |
|OSR-015 |The oneM2M System shall be able to assist Underlying Networks that support different communication patterns including infrequent communications, small data transfer, transfer of large file and streamed communication. |Partially implemented <br />(see note 13) |
|OSR-016 |The oneM2M System shall provide the capability to notify M2M Applications of the availability of, and changes to, available M2M Application/management information on the M2M Device/Gateway, including changes to the M2M Area Network. |Implemented in Rel-1 |
|OSR-017 |The oneM2M System shall be able to offer access to different sets of M2M Services to M2M Application Providers. The minimum set of services are:<br />- Connectivity management.<br />- Device management (service level management).<br />- Application Data management.<br />In order to enable different deployment scenarios, these services shall be made available by the oneM2M System, individually, as a subset or as a complete set of services. |Implemented in Rel-1 |
|OSR-018 |The oneM2M System shall be able to offer M2M Services to M2M Devices roaming across cellular Underlying Networks, subject to restriction based on Network Operator's policy (see note 3). |Implemented with some limitations<br />(see note 14) |
|OSR-019 |The oneM2M 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:<br />- action initiated either by an M2M Device, M2M Gateway, M2M Services Infrastructure, or M2M Application Infrastructure;<br />- when triggered by schedule or event;<br />- for specified data. |Implemented in Rel-1 |
|OSR-020 |The oneM2M System shall be able to support policies and their management regarding the aspects of storage and retrieval of data/information. |Implemented in Rel-1 |
|OSR-021 |The oneM2M System shall be able to provide mechanisms to enable sharing of data among multiple M2M Applications. |Implemented in Rel-1 |
|OSR-022 |When some of the components of a M2M Solution are not available (e.g. WAN connection lost), the oneM2M System shall be able to support the normal operation of components of the M2M Solution that are available. |Implemented in Rel-1 |
|OSR-023 |The oneM2M System shall be able to identify the M2M Services to be used by M2M Service Subscriptions (see note 4). |Implemented in Rel-1 |
|OSR-024 |The oneM2M System shall be able to identify the M2M Devices used by M2M Service Subscriptions. |Implemented in Rel-1 |
|OSR-025 |The oneM2M System shall be able to identify the M2M Applications used by M2M Service Subscriptions. |Implemented in Rel-1 |
|OSR-026 |If provided by the Underlying Network, the oneM2M System shall be able to associate the M2M Device used by M2M Service Subscriptions with the device identifiers offered by the Underlying Network and the device. |Implemented in Rel-1 |
|OSR-027 |The oneM2M System shall provide a generic mechanism to support transparent exchange of information between the M2M Application and the Underlying Network, subject to restriction based on M2M Service Provider's policy and/or Network Operator's policy (see note 5). |Not implemented |
|OSR-028 | The oneM2M System shall enable an M2M Application to define trigger conditions in the oneM2M System such that the oneM2M System autonomously sends a series of commands to actuators on behalf of the M2M Application when these conditions are met. |Not implemented |
|OSR-029 |The oneM2M System shall be able to support sending common command(s) to each actuator or sensor via a group. |Implemented in Rel-1 |
|OSR-030 |The oneM2M System shall be able to support the management (i.e. addition, removal, retrieval and update) of the membership of a group. |Implemented in Rel-1 |
|OSR-031 |The oneM2M System shall be able to support a group as a member of another group. |Implemented in Rel-1 |
|OSR-032 |The oneM2M 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 (see note 6). |Implemented in Rel-1 |
|OSR-033 |Based on the Dynamic Device/Gateway Context of the M2M Gateway and/or Device and the defined Event Categories, the oneM2M System shall provide the capability to dynamically adjust the scheduling of reporting and notification of the M2M Device/Gateway (see note 17). |Partially implemented <br />(see note 15) |
|OSR-034 |The oneM2M System shall support seamless replacement of M2M Devices as well as M2M Gateways (e.g. redirecting traffic, connection, recovery, etc.). |Not implemented |
|OSR-035 |The oneM2M System shall support the exchange of non-M2M Application related relevant information (e.g. Device/Gateway classes) between M2M Device/Gateway and M2M Service Infrastructure for the purpose of efficient communication facilitation. This includes the capability for an M2M Device to report its device class to M2M Service Infrastructure and for the M2M Service Infrastructure to inform M2M Device of the M2M Service Infrastructure capabilities. |Not implemented |
|OSR-036 |The oneM2M System should provide mechanisms to accept requests from M2M Application Service Providers for compute/analytics services. |Not implemented |
|OSR-037 |The oneM2M System shall enable an M2M Application to request to send data, in a manner independent of the Underlying Network, to the M2M Applications of a group of M2M Devices and M2M Gateways in geographic areas that are specified by the M2M Application. |Not implemented |
|OSR-038 |The oneM2M System shall support the inclusion of M2M Application's QoS preference in service requests to Underlying Networks. |Not implemented |
|OSR-039 |The oneM2M System shall be able to authorize service requests with QoS preference at service level, but shall pass M2M Application's QoS preference in service requests to Underlying Network for authorization and granting or negotiation of the service QoS requests. |Not implemented |
|OSR-040 |The oneM2M System shall be able to leverage multiple communication mechanisms (such as USSD or SMS) when available in the Underlying Networks. |Not implemented <br />(see note 16) |
|OSR-041 |The oneM2M System shall provide a mechanism, which supports the addition of new M2M Services to the oneM2M System as independent portable modules by means of the oneM2M interfaces. |Partially implemented<br />(see note 21) |
|OSR-042 |The oneM2M System shall be able to support different QoS-levels specifying parameters, such as guaranteed bitrate, delay, delay variation, loss ratio and error rate, etc. |Not implemented |
|OSR-043 |The oneM2M System shall be able to verify that members of a group support a common set of functions. |Implemented in Rel-1 |
|OSR-044 |The oneM2M 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. |Implemented in Rel-1 |
|OSR-045a |The oneM2M System shall be able to receive and utilize information provided by the Underlying Network about when an M2M Device can be reached. |Not implemented |
|OSR-045b |The oneM2M System shall be able to utilize reachability schedules generated by either the M2M Device or the Infrastructure Domain. |Partially implemented <br />(see note 18) |
|OSR-046 |The oneM2M System shall be able to support a capability for the M2M Application to request/disallow acknowledgement for its communication. |Not implemented |
|OSR-047 |The oneM2M System shall be able to support mechanism for the M2M Devices and/or Gateways to report their geographical location information to M2M Applications (see note 7). |Implemented in Rel-1 |
|OSR-048 |The oneM2M System shall provide an M2M Service that allows M2M Devices and/or Gateways to share their own or other M2M Devices' geographical location information (see note 7). |Implemented in Rel-1 |
|OSR-049 |The oneM2M System shall be able to provide the capability for an M2M Application to selectively share data (e.g. access control) among applications. |Implemented in Rel-1 |
|OSR-050 |If communication over one communication channel provided by the Underlying Network can only be triggered by one side (Infrastructure Domain or Field Domain), and alternative channel(s) is (are) available in the other direction, the oneM2M System shall be able to use the alternative channel(s) to trigger bidirectional communication on the first channel. |Implemented in Rel-1 |
|OSR-051 |Depending on availability of suitable interfaces provided by the Underlying Network the oneM2M System shall be able to request the Underlying Network to broadcast/multicast data to a group of M2M Devices in a specified area. |Implemented in Rel-1 |
|OSR-052 |The oneM2M System shall be able to select an appropriate Underlying Network to broadcast or multicast data depending on the network's broadcast/multicast support and the connectivity supported by the targeted group of M2M Devices/Gateways. |Not implemented |
|OSR-053 |The oneM2M System shall provide a means that enables backward compatibility of interfaces among different releases (see note 8). |Not implemented |
|OSR-054 |The oneM2M System shall be able to support an M2M Application, M2M Device, or M2M Gateway to obtain access to resources of another M2M Application, M2M Device, or M2M Gateway. |Implemented in Rel-1 |
|OSR-055 |The oneM2M System shall be able to provide the capability of M2M Applications to exchange data with one or more authorized M2M Applications which are not known in advance. |Implemented in Rel-1<br />(see note 20) |
|OSR-056 |The oneM2M System shall enable discovery of usable M2M Applications on an M2M Gateway or at an M2M Device . |Implemented in Rel-1 |
|OSR-057 |The oneM2M System shall enable discovery of M2M Gateways and M2M Devices available to an M2M Application for data exchange. |Implemented in Rel-1 |
|OSR-058 |The oneM2M System shall be able to provide time stamps as needed by Common Service Functions. |Implemented in Rel-1 |
|OSR-059 |The oneM2M System shall be able to support Role-Based Access Control based on M2M Service Subscriptions. |Implemented in Rel-1 |
|OSR-060 |The oneM2M System should support time synchronization with an external clock source. |Not implemented |
|OSR-061 |M2M Devices and M2M Gateways may support time synchronization within the oneM2M System. |Not implemented |
|OSR-062 |The oneM2M System shall enable means of testing the connectivity towards a set of M2M Applications. |Not implemented |
|OSR-063 |The oneM2M System shall be able to manage the scheduling of M2M Service Layer connectivity and messaging between the Infrastructure Domain and M2M Devices/Gateways. |Implemented in Rel-1 |
|OSR-064 |The oneM2M System shall be able to aggregate messages depending on message delay tolerance and/or category. |Implemented in Rel-1 |
|OSR-065 |The oneM2M System shall provide mechanisms that enable a M2M Service Provider to distribute processing functions to his M2M Devices/Gateways in the Field Domain |Not implemented |
|OSR-066 |The oneM2M System shall be able to support the placement and operation of M2M Applications in selected M2M Nodes per criteria requested by M2M Application Service Providers, subject to access rights. |Implemented in Rel-1 |
|OSR-067 |The oneM2M System shall be able to take operational and management action as requested by M2M Applications. |Implemented in Rel-1 |
|OSR-068 |When available from an Underlying Network, the oneM2M System shall be able to provide the capability to retrieve and report the information regarding whether an M2M Device is authorized to access Underlying Network services. |Not implemented |
|OSR-069 |When available from the Underlying Network, the oneM2M System shall be able to maintain the M2M Service Operational Status of a M2M Device and update it when the Underlying Network connectivity service status changes. |Not implemented |
|OSR-070 |The oneM2M System shall be able to provide the capability to notify an authorized M2M Application when the M2M Service Administrative State or M2M Service Operational Status of an M2M Device changes, if that M2M Application has subscribed for such notifications. |Partially implemented <br />(see note 19) |
|OSR-071 |The oneM2M System shall be able to enable an authorized M2M Application to set the M2M Service Administrative State of a M2M Device. |Implemented in Rel-1 |
|OSR-072 |The oneM2M System shall be able to initiate a set of actions defined by a M2M Application (e.g. trigger upon a threshold, compare a value, ) that impacts another Application |Not implemented |
|OSR-073<br />See REQ-2015-0529R03 |The oneM2M System shall support distributed transactions to multiple devices or applications where the transaction includes the characteristics of atomicity, consistency, isolation and durability. |Not implemented |
|OSR-074<br />See REQ-2015-0529R03 |The oneM2M System shall support the completion of distributed transactions to multiple devices or applications while maintaining the order of the operations and performing the transaction within a given time frame. |Not implemented |
|OSR-75<br />See REQ-2015-0546R01 |The oneM2M System shall be able to collect, store Time Series Data. |Implemented in Rel-2 |
|OSR-76<br />See REQ-2015-0546R01 |The oneM2M System shall be able to detect and report the missing data in time series. |Implemented in Rel-2 |
|OSR-077<br />See REQ-2015-0558R01 |The oneM2M System shall be capable of collecting asynchronous responses pertaining to the broadcasted messages. |Not implemented |
|OSR-078<br />See REQ-2015-573R01 |The oneM2M System shall support gateway-based capabilities for Event management, e.g. capability for arbitration of the resulting processing. |Not implemented |
|OSR-079<br />See REQ-2015-574R01 |The oneM2M System shall provide the capability to notify a device hosting a group of applications when alternative registration points for that group of applications are available (e.g. via different underlying networks) based on the service requirements of each of the applications hosted. |Not implemented |
|OSR-080<br />See REQ-2015-574R01 |The oneM2M System shall provide the capability to register applications in group or independently, based on their service requirements. |Not implemented |
|OSR-081<br />See REQ-2015-0553R02 |The oneM2M System shall be able to collect data that is broadcast (e.g. in industrial bus systems) according to data collection policies. |Not implemented |
|OSR-082<br />See REQ-2015-0553R02 |The oneM2M System shall allow the update, modification, or deletion of data collection policies within an M2M Application. |Not implemented |
|OSR-083<br />See REQ-2015-0593R02 |The oneM2M System shall be able to filter information from oneM2M Devices for a given set of parameters. |Not implemented |
|OSR-084<br />See REQ-2015-0595R04 |The oneM2M System shall be able to handle an event notification from an authorized M2M Application which triggers actions to be performed on the M2M Device (example: Turn on or off the monitoring). |Not implemented |
|OSR-085<br />See REQ-2015-0608 |The oneM2M System shall support resource caching of registered M2M Devices. Resource caching is a mechanism through which the oneM2M System retains resources of a registered M2M Device in temporarily inactive state by moving the resources to a temporary storage e.g. cache bin. |Not implemented |
|OSR-086<br />See REQ-2015-0611R02 |The oneM2M System shall enable M2M Gateways to discover M2M Infrastructure Nodes and M2M Devices available for data exchange. |Implemented in Rel-1 |
|OSR-087<br />See REQ-2015-0611R02 |The oneM2M System shall enable M2M Infrastructure Nodes and M2M Device to discover M2M Gateways available for data exchange. |Implemented in Rel-1 |
|OSR-088<br />See REQ-2015-0611R02 |The oneM2M System shall be able to support the capabilities for data repository (i.e. to collect/store) and for data transfer among authorized M2M Devices and M2M Gateways via M2M Area Networks by only involving the field domain. | Implemented in Rel-1 |
|OSR-089<br />See REQ-2015-0620 |The oneM2M System shall enable the cancellation of continuous data collection and/or the deletion of collected data when pre-defined conditions are met. |Not implemented |
|OSR-090<br />See REQ-2015-0622R02 |The oneM2M System shall be able to forward the M2M Application Data to M2M Application without storing the Data. |Partially implemented<br />(see note 22) |
|OSR-091<br />See REQ-2015-0622R02 |The oneM2M System shall be able to notify interested oneM2M entities when it detects forwarded M2M Application Data was not delivered within expected time duration. |Not implemented |
|OSR-092<br />See REQ-2015-0629 |The oneM2M System shall provide the capability for monitoring and describing data streams with associated attributes e.g. data freshness, accuracy, sampling rate, data integrity. |Not implemented |
|OSR-093<br />See REQ-2015-0630 |The oneM2M System shall support transaction management to multiple devices or applications providing policy based mechanism that should be invoked (e.g. keep status, re-schedule, rollback) depending on the outcome of the desired operation. |Not implemented |
|OSR-094<br />See REQ-2015-0631R02 |The oneM2M System shall provide Information Model(s) to support interoperability among different devices/applications. |Implemented in Rel-2 |
|OSR-095<br />See REQ-2015-0631R02 |The oneM2M System should provide mappings between different Information Models from non-oneM2M System(s). |Not implemented |
|OSR-096<br />See REQ-2015-0631R02 |The oneM2M System should be able to interwork with non-oneM2M System(s). |Implemented in Rel-2 |
|OSR-097<br />See REQ-2015-0583R01 |The oneM2M System shall be able to share data collection policies among multiple M2M Devices/Gateways within an M2M Application Service, or among different M2M Application Services. |Not implemented |
|OSR-098<br />See REQ-2016-0055R02 |The oneM2M system shall be able to support machine socialization functionalities (such as existence discovery, correlated task discovery, message interface discovery and process optimization for multiple machines with same tasks). |Not implemented |
|OSR-099<br />See REQ-2016-0066R01 |The oneM2M system shall enable continuity of services to M2M devices as they move across various geographic points in the oneM2M System(s). |Implemented in Rel-3 |
|OSR-100<br />See REQ-2017-0006R02 |The oneM2M system shall allow use of multiple communication methods (protocol bindings, serializations, and versions) between M2M Devices/Gateways and M2M application services. | |
|OSR-101<br />See REQ-2017-0008R02 |The oneM2M System shall enable discovery of M2M Application Servers, M2M Management Servers and M2M Devices available to an M2M Gateway for data exchange. | |
|OSR -102<br />See REQ-2017-0008R02 |The oneM2M System shall enable discovery of M2M Gateways available to a M2M Management Server and an M2M Device for data exchange. | |
|OSR-103<br />See REQ-2017-0008R02 |The oneM2M System shall be able to 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 via M2M Area Network without any assistance or instruction of M2M Management Servers and M2M Application Serve | |
|OSR-104<br />See REQ-2017-0008R02 |Upon request from M2M Application Server, an M2M Gateway shall enable functions that pre-process (e.g. average) M2M data before providing them to the recipient. |Not Implemented |
|OSR -105<br />See REQ-2017-0008R02 |Upon request, an M2M Gateway shall enable functions that erase M2M data (e.g. that have been sent or could not be sent to the recipient within a certain time) based on criteria from an M2M Application Server. |Not Implemented |
|OSR-106<br />See REQ-2017-0008R02 |An M2M Gateway and/or an M2M Device shall be able to broadcast the need to receive/deliver specific data.to otherM2M Devices and/or M2M Gateways |Not Implemented |
|OSR -107<br />See REQ-2017-0008R02 |The oneM2M system shall enable M2M Gateways and/or M2M Devices to establish a connection to each other if able to receive/deliver the specific data. |Not Implemented |
|OSR-108<br />See REQ-2017-0008R02 |The oneM2M System shall enable M2M Gateways to set conditions used for processing jointly group/aggregate data subscriptions to reduce the number of messages to M2M Devices and distribute the resulting notifications according to the set conditions. |Implemented in Rel-3 |
|OSR -109<br />See REQ-2017-0008R02 |The oneM2M System shall enable M2M Gateways to distribute notifications according to how data subscriptions have been grouped/aggregated. |Implemented in Rel-3 |
|OSR-110<br />See REQ-2017-0008R02 |The oneM2M System shall enable subscriptions to changes to multiple data sources (e.g. oneM2M resources) which aim to generate data publication (i.e. automatic notifications) if and only if the expected changes to each of those multiple resources occur concurrently. |Implemented in Rel-3 |
|OSR-111<br />See REQ-2017-0018R01 |The oneM2M system shall be able to support heterogeneous identification services, the recognition of external identification systems and converting an object identifier to a compatible identifier recognized by the oneM2M system. | |
|OSR-112<br />See REQ-2017-0030R05 |The oneM2M System shall enable the M2M Application to configure the notification interval in the M2M Devices. |Implemented in Rel-1 |
|OSR-113<br />See REQ-2017-0030R05 |The oneM2M System shall support communication between the Infrastructure Domainand M2M devices either directly or via a gateway. |Implemented in Rel-1 |
|OSR-114<br />See REQ-2017-0030R05 |The oneM2M System shall enable exchange of information between M2M applications viathe Infrastructure Domain . |Implemented in Rel-1 |
|OSR-115<br />See REQ-2017-0030R05 |The oneM2M system shall be able to support service requests from M2M applications for communication with QoS requirement e.g. higher delivery priority, reliable delivery. |Partially Implemented |
|OSR-116<br />See REQ-2017-0030R05 |The oneM2M system shall be able to support requests with time expiration or geography restriction. |Implemented in Rel-2 |
|OSR-117<br />See REQ-2017-0030R05 |The oneM2M System shall support setting the configuration for Geo-Fence based location services by a M2M Application. |Implemented in Rel-2 |
|OSR-118<br />See REQ-2017-0031R05 |The oneM2M System shall enable exchanges of diagnostic data periodically between M2M Devices and the Infrastructure Domain. |Rel-3/ future releases |
|OSR-119<br />See REQ-2017-0031R05 |The oneM2M system shall support a mechanism to describe the syntax and semantics format of the diagnostics data exchanged between the M2M Devices and the InfrastructureDomain. |Rel-3/ future releases? |
|OSR-120<br />See REQ-2017-0031R05 | The oneM2M System shall be able to provide the service capability for location based services | Implemented |
|OSR-121<br />See REQ-2017-0031R05 |The oneM2M System shall be able to provide the service capability supporting Over The Air management. |Implemented |
|OSR-122<br />See REQ-2017-0031R05 |The oneM2M system shall provide the capability for an M2M Device to maintain registration with multiple entities simultaneously. |Rel-3/ future releases? |
|OSR-123<br />See REQ-2017-0031R05 |The oneM2M System shall enable exchange of information with the intended vehicles by unicast, multicast and/or broadcast. |Partially Implemented<br />(Note 23) |
|OSR-124<br />See REQ-2017-0031R05 |The oneM2M System shall be able to transfer time critical information. . For example for feeding back current road states to automatic driving control,the feedback time should be less than a few seconds (the distance between vehicles normally corresponds to a few seconds) to avoid unnecessary speed down/stop of following vehicles. (Note 24) |Rel-3/ future releases? |
|OSR-125<br />See REQ-2017-0031R05 |The oneM2M System shall be able to guarantee its reliability in order to receive/feedback messages from/to related M2M Devices (e.g. for Vehicular Domain) . (Note 24) |Rel-3/ future releases? |
|OSR-126<br />See REQ-2017-0031R05 |The oneM2M System shall enable sharing of service information between devices/GWs based on proximity. (Note 24) |Rel-3/ future releases? |
|OSR-127<br />See REQ-2017-0031R05 |The oneM2M System shall enable sending and receiving of service information between devices/GWs with minimized interruption. (Note 24) |Rel-3/ future releases? |
|OSR-128<br />See REQ-2017-0031R05 |The oneM2M System shall support mobile/portable M2M Gateway and/or Device. |Rel-3/ future releases? |
|OSR-129<br />See REQ-2017-0031R05 |The oneM2M System shall support triggering M2M Devices for on-demand reporting regarding collected data. |Rel-3/ future releases? |
|OSR-130<br />See REQ-2017-0031R05 |The oneM2M System shall enable the M2M Infrastructure to facilitate direct communication between two or more different M2M devices without having registered with one another. |Rel-3/ future releases? |
|OSR-131<br />See REQ-2017-0031R05 |The oneM2M System shall be able to verify geographical location information from moving objects regardless of information accuracy. |Rel-3/ future releases? |
|OSR-132<br />See REQ-2017-0031R05 |The oneM2M System shall be able to verify time synchronization |Rel-3/ future releases? |
|OSR-133<br />See REQ-2017-0031R05 |The oneM2M System shall be able to coordinate end-to-end reliable communications for applications that can have safety impacts. |Rel-3/ future releases? |
|OSR-134<br />See REQ-2017-0048R02 |The oneM2M System shall enable provisioning, installation, configuration and registration methods of field devices for different management systems (e.g. allowing different entities to own and manage the device) or application systems (e.g. allowing different entities to utilise the device data). |future releases? |
|OSR-135<br />See REQ-2017-0048R02 |The oneM2M System shall enable registrations to include information identifying the peer entites, and related information (e.g. management privilege, subscription etc.), necessary for establishment of the respective peer relationships. |future releases? |
|OSR-136<br />See REQ-2017-0048R02 |The oneM2M System shall enable registrations using a complete set of information context for the peer entities (termed "full registrations"). |future releases? |
|OSR-137<br />See REQ-2017-0048R02 |The oneM2M System shall enable registrations using only a subset of information context for the peer entities (termed "lightweight registration"). |future releases? |
|OSR-138<br />See REQ-2017-0048R02 |The oneM2M System shall enable "lightweight registrations" instances with different entities, which pertain to a common peer entity, to use different sets of information about the common peer entity as needed. |future releases? |
|OSR-139<br />See REQ-2017-0048R02 |The oneM2M System shall enable correlation of the "full registration" and the "lightweight registration" instances pertaining to a common peer entity. |future releases? |
|OSR-140<br />See REQ-2017-0048R02 |The oneM2M System shall enable differentiation of the "full registrations" and the "lightweight registrations" instances pertaining to a common peer entity. |future releases? |
|OSR-141<br />See REQ-2017-0073R02 |The oneM2M system shall be able to maintain information about the correlation status of a data set and update it dynamically based on application request | |
|OSR-0142<br />See REQ-2018-0009R04 |The oneM2M System shall enable pool-based functionality sharing and scaling between Edge/Fog Nodes. |Rel-4/ future releases? |
|OSR-0143<br />See REQ-2018-0009R04 |The oneM2M System shall be able to trigger priority services from the underlying network (e.g. 3GPP MPS). |Rel-4/ future releases? |
|OSR-0144<br />See REQ-2018-0009R04 |The oneM2M System shall enable detection of network bandwidth between Edge /Fog Nodes and M2M devices in order to provide necessary quality of service according to the bandwidth. |Rel-4/ future releases? |
|OSR-0145<br />See REQ-2018-0009R04 |The oneM2M System shall enable Edge/Fog Nodes to provide system metrics and diagnostic information to other Edge/Fog Nodes, as required to ensure reliable operations within the oneM2M System. |Rel-4/ future releases? |
|OSR-0146<br />See REQ-2018-0009R04 |The oneM2M System shall enable Edge/Fog Nodes which are unable to perform specific services to alert other suitable Edge/Fog Nodes. |Rel-4/ future releases? |
|OSR-0147<br />See REQ-2018-0011R03 |The oneM2M System shall enable data continuity services to be provided between Edge/Fog Nodes by enabling the discovery, retrieval, and combination of data sets dispersed across the Edge/Fog Nodes' network. |Rel-4/ future releases? |
|OSR-0148<br />See REQ-2018-0011R03 |The oneM2M System shall enable data optimization services to be provided at Edge/Fog Nodes including aggregation, stale or redundant data identification and removal, integrity check, validation, etc. even if the data sets are dispersed across the Edge/Fog Nodes' network |Rel-4/ future releases? |
|OSR-0149<br />See REQ-2018-0011R03 |The oneM2M System shall enable categorization of the data collected by M2M devices (e.g. high priority data, low priority data) for differential delivery and processing. |Rel-4/ future releases? |
|OSR-0150<br />See REQ-2018-0011R03 |The oneM2M System shall enable timestamp synchronization of the data collected by M2M devices between Edge/Fog Nodes for data synchronization. |Rel-4/ future releases? |
|OSR-0151<br />See REQ-2018-0011R03 |The oneM2M System shall enable services to receive and utilize location-based information about available access networks, their congestion level and other related network information when the information is provided by the Underlying Network. |Rel-4/ future releases? |
|OSR-0152<br />See REQ-2018-0011R03 |The oneM2M System shall enable differential routing and processing of data streams at different nodes, e.g. Edge/Fog Node vs. infrastructure.<br /> |Rel-4/ future releases? |
|OSR-153<br />See REQ-2018-0021R03 |The oneM2M System shall be able to dynamically obtain metadata (e.g. Firmware version, Manufacturer ID, HW version) from field devices (e.g. located behind a gateway). | |
|OSR-154<br />See REQ-2018-0013R02 |The oneM2M system shall support handover (e.g east-west communication) over platoon relevant data migration from one Edge/Fog noNde Platooning Manager (running on Edge/Fog Node) to next neighbouring Edge/Fog Node Platooning Manager (running on neighbouring Edge/Fog Node). |Rel-4/ future releases? |
|OSR-155<br />See REQ-2018-0013R02 |The oneM2M system shall support a common information models for Platooning including vehicular domain (e.g.vehicle state, and platooning state, road conditions or parking places). |Rel-4/ future releases? |
|OSR-156<br />See REQ-2018-0013R02 |The oneM2M system shall support profile profiles of information models for data exchange Platooning . |Rel-4/ future releases? |
|OSR-157<br />See REQ-2018-0013R02 |The oneM2M system shall support grouping of devices with different roles relative to the group.The oneM2M system shall support group management (e.g .joining, leaving and changing vehicle's role within the platoon) and group message communication for platooning service. |Rel-4/ future releases? |
|OSR-158<br />See REQ-2018-0013R02 |The oneM2M system shall support methods for device joining, leaving and changing roles within groups, for the purpose of communicating with group members . |Rel-4/ future releases? |
|OSR-159<br />See REQ-2018-0013R02 |The oneM2M system shall support field node to field node direct Vehicle-to-Vehicle (V2V) communications without having registeration relationship with each other, via different network interfaces (e.g. Vehicle-to-Vehicle (V2V) communication). |Rel-4/ future releases? |
|OSR-160<br />See REQ-2018-0013R02 |The oneM2M system shall support management of of Vehicle-to-Vehicle (V2V) network interface switching for field node to field node communications. |Rel-4/ future releases? |
|OSR-0161<br />See REQ-2018-0018R01 |The oneM2M System shall enable the remote instantiation of services across Edge/Fog Nodes' networks as well as the remote provisioning of information required to instantiate the services. |Rel-4 |
|OSR-0162<br />See REQ-2018-0018R01 |The oneM2M System shall enable the sharing and discovery of service capability information across Edge/Fog Nodes'networks. |Rel-4 |
|OSR-0163<br />See REQ-2018-0018R01 |The oneM2M System shall enable to request services provided by Edge/Fog Nodes |Rel-4 |
|OSR-0164<br />See REQ-2018-0018R01 |The oneM2M System shall enable service migration among Edge/fog Nodes. |Rel-4 |
|OSR-0165<br />See REQ-2018-0018R01 |The oneM2M System shall enable the orchestration of services provided by Edge/Fog Nodes in a dynamic fashion to satisfy operational requirements for availability, scalability, interoperability, etc. |Rel-4 |
|OSR-0166<br />See ARC-2018-0062 |The oneM2M System shall support identification of M2M Service Subscribers and associating a M2M Service Subscriber with a M2M Service Subscription to a M2M Service Provider. |Rel-4 |
|OSR-0167<br />See ARC-2018-0062 |The oneM2M System shall support identification of M2M Service Users and associating a M2M Service User with a M2M Service Subscriber. |Rel-4 |
|OSR-0168<br />See ARC-2018-0062 |The oneM2M System shall support charging event detection, statistics collection and charging records generation mechanisms based on M2M Service Subscriber and M2M Service User identification. |Rel-4 |
|OSR-0169<br />See ARC-2018-0062 |The oneM2M System shall support M2M Service Subscriber-based enrolment comprised of enrolment of M2M Devices and M2M Applications and M2M Service Users associated with a M2M Service Subscriber. |Rel-4 |
|OSR-0170<br />See ARC--2018-0062 |The oneM2M System shall support identification of M2M Service Subscribers and associating a M2M Service Subscriber with a M2M Service Subscription to a M2M Service Provider. | |
|OSR-0170<br />See ARC--2018-0062 |The oneM2M System shall support identification of M2M Service Users and associating a M2M Service User with a M2M Service Subscriber. | |
|OSR-0171<br />See ARC--2018-0062 |The oneM2M System shall support M2M Service Subscriber-based enrolment comprised of enrolment of M2M Devices and M2M Applications and M2M Service Users associated with a M2M Service Subscriber. | |
|OSR-172<br />See ARC--2018-0052R02 |The oneM2M System shall support request/response message interaction with M2M Devices with minimallatency. | |
|OSR-173<br />See ARC--2018-0052R02 |The oneM2M System shall support request/response message interaction with M2M Devices with minimal number of request/response messages. | |
|OSR-174<br />See ARC--2018-0052R02 |The oneM2M System shall support request/response message interaction with M2M Devices with minimal request/response message size. | |
|OSR-175<br />See ARC--2018-0052R02 |The oneM2M System shall support approaches for M2M Devices to minimize response message size. | |
|OSR-176<br />See ARC--2018-0052R02 |The oneM2M System shall support approaches for M2M Devices to remove unrequired or redundant attributes from the resource representation as contained in the "Content" parameter | |
|OSR-177<br />See ARC--2018-0111 |The oneM2M System shall support the capability to initiate the update (i.e. refresh) of a resource by its creator if/when the representation of the resource is too old (i.e. stale) to meet the requirements of a requester. | |
|OSR-178<br />See REQ-2018-0047R04 |The oneM2M System shall be able to support requests for offloading between nodes (e.g., offloading indication, a service logic, task, target offloading resources). |4 |
|OSR-179<br />See REQ-2018-0047R04 |The oneM2M System shall be able to support data and task synchronization mechanisms between source and offloaded nodes. |4 |
|OSR-180<br />See REQ-2018-0047R04 |The oneM2M System shall be able to manage offloaded resources based on given policies from the users, e.g., blocking the offloaded resources to be accessed while the resources are offloaded to other oneM2M nodes. |4 |
|OSR-181<br />See REQ-2018-0067R01 |The M2M System shall provide capabilities to request from the underlying network either the last known location information or current location information, if supported by the underlying networks. |4 |
|OSR-182<br />See REQ-2018-0071R05 |The oneM2M System shall support the management and configuration of authorization level setting for device remote control, based on the device functionality. |Rel-4 |
|OSR-183<br />See REQ-2018-0071R05 |The oneM2M System shall enable mechanisms to expose device policies regarding access and communication for device security and safety. |Rel-4 |
|OSR-184<br />See REQ-2018-0070R04 |The oneM2M System shall support dynamic and variable vehicle Geo-Fence setting configuration for location-based services (e.g. boundary reshaping) |Rel-4 |
|OSR-185<br />See REQ-2018-0070R04 |The oneM2M System shall enable mechanisms for sequential triggering of operations(e.g. time-based, event-based) based on requirements defined by M2M applications. |Rel-4 |
|OSR-186<br />See REQ-2018-0070R04 |The oneM2M System shall enable mechanisms to expose policies about the current and future resource needs of M2M nodes for resource allocation and management purposes at the system level. |Rel-4 |
|OSR-187<br />See RDM-2019-0046R01 |The oneM2M System shall be able to enable mechanisms for access control and resource lifecycle management based on number and types of operations on oneM2M resources. |Rel-4 |
|OSR-188<br />See RDM-2019-0046R01 |The oneM2M System shall be able to operate (e.g., delete) a resource based on resource operation policy (e.g., delete a resource when the resource is read by a specific application) |Rel-4 |
|OSR-189 |The oneM2M System shall support geometry objects (e.g. Point, Polygon) to represent the geo-location of a M2M Device, M2M Gateway and a Thing. | |
|OSR-190 |The oneM2M System shall support syntax and semantics of geometry objects referring existing standards (e.g. OGC) to assure location information interoperability for M2M Applications. | |
|OSR-191 |The oneM2M System shall support discovery of identifiers of Things with geospatial function execution against geometry objects representing the Things. | |
|OSR-192<br />See RDM-2019-0048R03 |The oneM2M System shall enable migration of data and context information between Edge/Fog Nodes for continuous services support. |Rel-4 |
|OSR-193<br />See RDM-2019-0048R03 |The oneM2M System shall enable synchronization of data between Edge/Fog Nodes and Cloud Node when migrating data and context information between Edge/Fog Nodes. |Rel-4 |
|OSR-194<br /> |The oneM2M System shall enable Edge/Fog Nodes to have service communications with multiple other Edge/Fog Nodes to meet reliability requirements. | |
|OSR-195 |The oneM2M System shall enable Edge/Fog Nodes to detect the failure of other Edge/Fog Nodes. | |
|OSR-196 |The oneM2M System shall enable the sharing and discovery of service capability information across Edge/Fog Nodes' networks. | |
|OSR-197 |The oneM2M System shall enable requests for services to be provided by Edge/Fog Nodes. | |
|OSR-198 |The oneM2M System shall enable service migration among /Edge/Fog Nodes. | |
|OSR-199 |The oneM2M system shall enable Edge/Fog Nodes to support the data delivery and processing based on the event prioritization associated with an information model. | |
|OSR-200 |The oneM2M System shall support the provisioning and management of policies governing the use of resource reservation mechanisms, including: authorizing resource reservation requests, constraining resource reservation parameters (e.g. maximum reservation duration, maximum aggregated reservation duration, maximum number of resources reserved, maximum number of consecutive reservations granted, etc.) | |
|OSR-201 |The oneM2M System shall support mechanisms for time-limited reservation of resources at resource hosts, based on pre-provisioned resource reservation policies and reservation requests, subject to access control. | |
|OSR-202 |The oneM2M System shall enable methods to identify resource link-binding roles, such as source resource and destination resource. | |
|OSR-203 |The oneM2M System shall enable the link binding between a source resource and a destination resource. | |
|OSR-204 |The oneM2M System shall enable to create link bindings between a source resource and a destination resource. | |
|OSR-205 |The oneM2M System shall enable to update link bindings between a source resource and a destination resource. | |
|OSR-206 |The oneM2M System shall enable to delete link bindings between a source resource and a destination resource. | |
|OSR-207 |The oneM2M System shall enable an Edge/Fog nNode to identify EdgeFog Nodes that can potentially cooperate to complete a request and to track their capabilities (e.g. battery level, available memory) in an efficient manner. | |
|OSR-208 |The oneM2M System shall enable an Edge/og noNde to select a group of Edge/Fog Nodes to cooperate on an Edge/Fog service request, and split the request into multiple sub-requests according to the type, amount, and availability of the selected Edge/Fog nodes' capabilities, such that the capability requirement in each sub-request will not exceed the capacity of the corresponding Edge/og Node. | |
|OSR-209 |The oneM2M System shall enable an Edge/Fog Node to coordinate a group/cluster of Edge/Fog nodes to provide services to a user. | |
|OSR-210 |The oneM2M System shall enable a group of Edge/Fog Nodes cooperating on a service to re-allocate tasks among the group nodes as needed to adapt to the dynamic capability distribution within the group. | |
|OSR-211 |The oneM2M System shall enable identification and management of hierarchical Edge/Fog Nodes. | |
|OSR-212 |The oneM2M System shall enable local analytic services executed at processing gateways using evaluation rules associated with local data | |
|OSR-213 |The oneM2M System shall enable distributed analytics services executed in collaboration with a centralized analytics service, e.g. where the centralized service performs additional processing triggered by the distributed services or where the centralized service provides rules associated with the local processing | |
|OSR-214 |The oneM2M System shall enable policies for initiating data delivery or parameters for categorizing data into different levels of priority orQoS. | |
|OSR-215 |The oneM2M System shall enable the use of subscriber-specific filters for notifications and event processing, so that each subscriber can be notified only when events relevant to the subscriber occur. | |
|OSR-216 |The oneM2M System shall enable sharing of data anonymously between applications. | |
|OSR-217 |The oneM2M System shall support mechanisms for delaying notifications in case of a congested communication network. | |
|OSR-218 |The oneM2M System shall support the capability of selecting communication protocols between entities in a flexible manner. | |
|OSR-219 |The oneM2M System shall support dynamic management and configuration of protocols in entities for sustainable device connection. | |
|OSR-220 |The oneM2M System shall support the capability of selecting underlying networks between entities in a flexible manner. | |
|OSR-221 |The oneM2M System shall support dynamic management and configuration of underlying networks in entities for sustainable device connection. | |
|OSR-222<br />See RDM-2019-0089R01 |The oneM2M system shall enable notification when the condition is maintained for pre-defined time. |Rel-5 |
|OSR-223 |The oneM2M System shall be able to create datasets using the historical data (e.g. IoT sensor) to train AI/ML models. |Rel-5 |
|OSR-224 |The oneM2M System shall be able to create datasets using the current data (e.g. IoT sensor) to train AI/ML models or make prediction/inference with the trained models. |Rel-5 |
|OSR-225<br />See RDM-2023-0006R01 |The oneM2M System shall be able to manage AI/ML models with model metadata. | |
|OSR-226<br />See RDM-2023-0006R01 |The oneM2M System shall be able to support an AI/ML model deployment to IoT devices (e.g. Edge/Fog nodes) and IoT applications. | |
|OSR-227<br />See RDM-2023-0008 |The oneM2M System shall be able to handle data augmentation requests for AI/ML purposes. |Rel-5 |
|OSR-228<br />See RDM-2023-0008 |The oneM2M System shall be able to generate augmented data resources from a given source data and data augmentation technique. |Rel-5 |
|OSR-229<br />See RDM-2023-0008 |The oneM2M System shall be able to manage data for AI/ML purposes such as model training and augmentation of training dataset. |Rel-5 |
|OSR-230<br />See RDM-2023-0009R01 |The oneM2M System shall be able to support the management (e.g., store, update, access) of structured and unstructured data for training, for example, preprocessing data, describing data and inferring meaning. |Rel-5 |
|OSR-231<br />See RDM-2023-0009R01 |The oneM2M System shall be able to support model retraining with newly collected data, e.g., location, time series and historical data. |Rel-5 |
|OSR-232<br />See RDM-2023-0009R01 |The oneM2M System shall be able to support AI/ML data partitioning for training, validation, and testing in supervised learning. |Rel-5 |
|OSR-233<br />See RDM-2023-0010R01 |The oneM2M System shall be able to synchronize data between oneM2M devices and virtual world devices. |Rel-5 |
|OSR-234<br />See RDM-2023-0010R01 |The oneM2M System shall enable Edge/Fog Nodes to run AI/ML models to retrieve information from the real world. |Rel-5 |
|OSR-235<br />See RDM-2023-0011R01 |The oneM2M system shall be able to support the creation and management of classifiers for AI/ML applications as follows:<br />Predefined-classifier function comes with a predefined and pretrained classifier for object detection, object tracking, semantic segmentation,instance segmentation, etc. from data generated by IoT devices (e.g., smart city camera). (Note 25) |Rel-5 |
|OSR-236<br />See RDM-2023-0012R01 |The oneM2M System shall be able to distinguish the data set that will be trained and has already been trained. |Rel-5 |
|OSR-237<br />See RDM-2023-0012R01 |The oneM2M System shall be able to provide automated machine learning applications under certain conditions, e.g., building a model every week or when the number of datasets reaches 100. |Rel-5 |
NOTE 1: The set of features or APIs to be supported depends on the M2M Common Services and access to available APIs.
NOTE 2: The relation M2M Network Application to M2M Device/Gateway may be 1:1, 1:n, n:1 and/or n:m.
NOTE 3: No roaming on M2M Service level is assumed by this requirement.
NOTE 4: M2M Service Subscriptions are not Application subscriptions (e.g. Home Energy Management).
NOTE 5: Transparent exchange of information implies information that is mainly interpreted by the M2M Application and the Underlying Network Provider.
NOTE 6: Based on the Event Categories and via interworking with Underlying Networks, the oneM2M System can support differentiated services (by providing Quality-of-Service) requested by M2M Applications.
NOTE 7: Geographical location information can be more than simply longitude, latitude and Geo-fence event.
NOTE 8: "means" above does not imply only technical mechanisms, e.g. there is no protocol version negotiation.
NOTE 9: In Rel-1 only GBA and localization are available.<br />
NOTE 10: Rel-1 covers: Location, Charging and billing services, Configuration and management of devices, Device information and profiles, Triggering.
NOTE 11: This requirement applies to M2M Devices but not to devices interworked via M2M Area Networks.
NOTE 12: Based on device triggering.
NOTE 13: No Support for streamed communication.
NOTE 14: Limitations to trigger (via Tsp interface) devices in a roamed-to network.
NOTE 15: Detail syntax to describe Dynamic Context is not specified.
NOTE 16: It is possible to deliver CoAP over SMS, but currently SMS message delivery interfaces are not explicitly defined.
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in this document are to be interpreted as described in the oneM2M Drafting Rules <a href="#_ref_i.1">[i.1]</a>
NOTE 17: 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.
NOTE 18: Void.
# 5 User defined clause(s) from here onwards
NOTE 19: Only the M2M Service Administrative State can be notified. M2M Service Operational Status is not implemented.
## 5.1 User defined subdivisions of clause(s) from here onwards
&lt;Text>
NOTE 20: This can be implemented based on preconfigured access rights.
<mark>The following text is to be used when appropriate:</mark>
NOTE 21: In Rel-1 this is supported by means of the Mca interfaces, mapping the new service module to an AE.
NOTE 22: In Rel-2 data are stored in the CSE but never get retrieved by other entities except by subscribe/notify mechanism.
# Proforma copyright release text block
<mark>This text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or template which is intended to be copied by the user. Such an element shall always start on a new page.</mark>
NOTE 23: Unicast communications have been implemented in Release 1
NOTE 24: Definition of "real time" and how to specify timing and reliability requirments is TBD.
|Notwithstanding the provisions of the copyright clause related to the text of the present document, oneM2M grants that users of the present document may freely reproduce the &lt;proformatype> proforma in this {clause\|annex} so that it can be used for its intended purposes and may further publish the completed &lt;proformatype>.|
|----|
NOTE 25: Customized classifier that can be generated by an application to support a specific detection function such as visual recognition.
<mark>&lt;PAGE BREAK></mark>
## <mark>Annexes</mark>
<mark>Each annex shall start on a new page (insert a page break between annexes A and B, annexes B and C, etc.).</mark>
## 6.2 Management Requirements
<mark>Use the Heading 9 style for the title and the Normal style for the text.</mark>
**Table 2: Management Requirements**<a name="table_2"></a>
# Annex &lt;A> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
|Requirement ID |Description |Release |
|-|-|-|
|MGR-001 |The oneM2M System shall be able to support management and configuration of M2M Gateways/ Devices including resource constrained M2M Devices. |Implemented in Rel-1 |
|MGR-002 |The oneM2M System shall provide the capability to discover the M2M Area Networks including information about devices on those networks and the parameters (e.g. topology, protocol) of those networks. |Implemented in Rel-1 |
|MGR-003 |The oneM2M System shall be able to provide the capability to maintain and describe the management Information Model of devices and parameters (e.g. topology, protocol) of M2M Area Networks. |Implemented in Rel-1 |
|MGR-004 |The oneM2M System shall support common means to manage devices enabled by different management technologies (e.g. OMA DM, BBF TR069). |Implemented in Rel-1 |
|MGR-005 |The oneM2M System shall provide the capability to manage multiple devices in a grouped manner. |Implemented in Rel-1 |
|MGR-006 |The oneM2M System shall provide the capability for provisioning and configuration of devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-007 |The oneM2M System shall provide the capability for monitoring and diagnostics of M2M Gateways/Devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-008 |The oneM2M System shall provide the capability for software management of devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-009 |The oneM2M System shall provide the capability for rebooting and/or resetting of M2M Gateways/Devices and other devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-010 |The oneM2M System shall provide the capability for authorizing devices to access M2M Area Networks. |Implemented in Rel-1 |
|MGR-011 |The oneM2M System shall provide the capability for modifying the topology of devices in M2M Area Networks, subject to restriction based on M2M Area Network policies. |Implemented in Rel-1 |
|MGR-012 |Upon detection of a new device the M2M Gateway shall be able to be provisioned by the M2M Service Infrastructure with an appropriate configuration which is required to handle the detected device. |Partially implemented <br />(see note) |
|MGR-013 |Void. | |
|MGR-014 |The oneM2M System shall be able to retrieve events and information logged by M2M Gateways/ Devices and other devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-015 |The oneM2M System shall be able to support firmware management (e.g. update) of M2M Gateways/ Devices and other devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-016 |The oneM2M System shall be able to retrieve information related to the Static and Dynamic Device/Gateway Context for M2M Gateways/Devices as well as Device Context for other devices in M2M Area Networks. |Implemented in Rel-1 |
|MGR-017 |The oneM2M System shall be capable of correlating Access Management elements provided by the technology specific Device Management Protocols to Access Management elements used by the oneM2M System. |Implemented in Rel-1 |
|MGR-018<br />See REQ-2015-0555R02 |The M2M Service Infrastructure shall be able to accept standardized configuration settings from an external configuration server to allow the M2M Devices to register. |Not implemented |
|MGR-019<br />See REQ-2015-0555R02 |The M2M Device shall be able to accept standardized configuration settings from an external configuration server in order to register to the oneM2M System. |Not implemented |
&lt;Text>
<mark>&lt;PAGE BREAK></mark>
NOTE: In Rel-1 no detection mechanism exists, but once an M2M Device is known at the Gateway it can be configured via the GW through DM.
# Annex &lt;B> (Informative/Normative):<mark>Remove Informative or Normative as appropriat</mark> Title of annex <mark>(style H9)</mark>
## B.1 First clause of the annex <mark>(style H1)</mark>
### B.1.1 First subdivided clause of the annex <mark>(style H2)</mark>
## 6.3 Semantics Requirements
&lt;Text>
### 6.3.1 Ontology Related Requirements
<mark>&lt;PAGE BREAK></mark>
**Table 3: Ontology Requirements**<a name="table_3"></a>
<mark>The following text is to be used when appropriate:</mark>
|Requirement ID |Description |Release |
|-|-|-|
|ONT-001<br />See REQ-2015-0521R01 |The M2M System shall support a standardized format for the rules/policies used to define service logic. |Not implemented |
|ONT-002<br />See REQ-2015-0521R01 |The M2M System shall support modelling semantic descriptions of Things (including relationships among them) by using ontologies. |Implemented in Rel-2 |
|ONT-003<br />See REQ-2015-0521R01 |The M2M System shall support a common modelling language for ontologies (e.g. OWL). |Implemented in Rel-2 |
|ONT-004<br />See REQ-2015-0521R01 |The M2M System should be able to provide translation capabilities from different modelling languages for ontologies to the language adopted by oneM2M if the expressiveness of the imported ontology allows. |Not implemented |
|ONT-005<br />See REQ-2015-0521R01 |The M2M System shall provide the capability to retrieve semantic descriptions and ontologies stored outside of the M2M System. |Not implemented |
|ONT-006<br />See REQ-2015-0521R01 |The M2M System shall provide support for linking ontologies defined in the context of the M2M System with ontologies defined outside this context. |Not implemented |
|ONT-007<br />See REQ-2015-0521R01 |The M2M System shall be able to support extending ontologies in the M2M System. |Not implemented |
|ONT-008<br />See REQ-2015-0521R01 |The M2M System shall be able to use ontologies that contain concepts representing aspects (e.g. a room) that are not represented by resources of the M2M System. |Implemented in Rel-2 |
|ONT-009<br />See REQ-2015-0521R01 |The M2M System shall be able to re-use common ontologies (e.g. location, time ontologies, etc.) which are commonly used in M2M Applications. |Not implemented |
|ONT-010<br />See REQ-2015-0521R01 |The M2M System shall be able to support simultaneous usage of multiple ontologies for the same M2M resource. |Implemented in Rel-2 |
|ONT-011<br />See REQ-2015-0521R01 |The M2M System shall provide the capability for making ontology available in the M2M System, e.g. through announcement. |Not implemented |
|ONT-012<br />See REQ-2015-0521R01 |The M2M System shall be able to support mechanisms to import external ontologies into the M2M System. |Not implemented |
|ONT-013<br />See REQ-2015-0521R01 |The M2M System shall be able to support update of ontologies. |Not implemented |
|ONT-014<br />See REQ-2015-0521R01 |The M2M System shall enable functions for data conversion based on ontologies. |Not implemented |
|ONT-015<br />See REQ-2015-0521R01 |The M2M System shall be able to model devices based on ontologies which may be available outside the M2M System (e.g. HGI device template). |Implemented in Rel-2 |
|ONT-016<br />See REQ-2015-0521R01 |The M2M System shall support storage, management and discovery of ontologies. |Not implemented |
|ONT-017<br />See REQ-2015-0609 |The oneM2M System shall support a semantic relation ("Is Paired To") between two M2M Devices. |Not implemented |
|ONT-018<br />See REQ-2018-0057R01 |The oneM2M system shall support semantic query and discovery across heterogeneous ontologies including support of automatic ontology mapping and semantic reasoning. |4 |
|ONT-019<br />REQ-2018-0058R01 |The oneM2M system shall be able to support semantic control of devices with support of addtional capabilities e.g. automatic ontology mapping and semantic reasoning. |4 |
|ONT-020<br />See REQ-2018-0049R03 |The oneM2M system shall be able to detect ontology's mapping conflicts and repair them.<br /> |Not implemented |
|ONT-021<br />See RDM-2019-0093 |The oneM2M System shall be able to provide machine understandable semantic information for object identifiers to map the identified objects to corresponding classes in the IoT ontology and enable objects to identify what the interactive object is independently. |5 |
### 6.3.2 Semantics Annotation Requirements
**Table 4: Semantics Annotation Requirements**<a name="table_4"></a>
|Requirement ID |Description |Release |
|-|-|-|
|ANN-001<br />See REQ-2015-0521R01 |The oneM2M System shall provide capabilities to manage semantic information about the oneM2M resources, e.g. create, retrieve, update, delete, associate/link. |Implemented in Rel-2 |
|ANN-002<br />See REQ-2015-0521R01 |The oneM2M System shall support a common language for semantic description, e.g. RDF. |Implemented in Rel-2 |
|ANN-003<br />See REQ-2015-0521R01 |The oneM2M System shall support semantic annotation of oneM2M resources for example application related data contained in containers. |Implemented in Rel-2 |
|ANN-004<br />See REQ-2015-0521R01 |The oneM2M System shall support semantic annotation based on related ontologies. |Implemented in Rel-2 |
|ANN-005<br />See REQ-2015-0521R01 |The oneM2M System shall provide the capability for making semantic descriptions available in the M2M System, e.g. announcement. |Implemented in Rel-2 |
|ANN-006<br />See REQ-2015-0521R01 |The oneM2M System shall enable applications to retrieve an ontology representation related to semantic information used in the M2M System. |Not implemented |
|ANN-007<br />See REQ-2015-0521R01 |The oneM2M system shall provide capabilities to manage data quality descriptions of resource. |Not implemented |
# Annex &lt;y>:<br />Bibliography
<mark>The annex entitled "Bibliography" is optional.</mark>
<mark>It shall contain a list of standards, books, articles, or other sources on a particular subject which are not mentioned in the document itself</mark>
<mark>It shall not include references mentioned in the document.</mark>
### 6.3.3 Semantics Query Requirements
<mark>Use the Heading 9 style for the title and B1+ or Normal for the text.</mark>
**Table 5: Semantics Query Requirements**<a name="table_5"></a>
|Requirement ID |Description |Release |
|-|-|-|
|QRY-001<br />See REQ-2015-0521R01 |The oneM2M System shall provide capabilities to discover M2M Resources based on semantic descriptions. |Implemented in Rel-2 |
- &lt;Publication>: "&lt;Title>".
OR
### 6.3.4 Semantics Mashup Requirements
&lt;Publication>: "&lt;Title>".
**Table 6: Semantics Mashup Requirements**<a name="table_6"></a>
<mark>&lt;PAGE BREAK></mark>
|Requirement ID |Description |Release |
|-|-|-|
|MSH-001<br />See REQ-2015-0521R01 |The oneM2M System shall provide the capability to host processing functions for mash-up. |Not implemented |
|MSH-002<br />See REQ-2015-0521R01 |The oneM2M System shall enable M2M Applications to provide processing functions for mash-up. |Not implemented |
|MSH-003<br />See REQ-2015-0521R01 |The oneM2M System itself may provide pre-provisioned or dynamically created processing functions for mash-up. |Not implemented |
|MSH-004<br />See REQ-2015-0521R01 |The oneM2M System shall be able to create and execute mash-ups based on processing functions. |Not implemented |
|MSH-005<br />See REQ-2015-0521R01 |The oneM2M System shall be able to expose mash-ups as resources e.g. virtual devices. |Not implemented |
# History
<mark>This clause shall be the last one in the document and list the main phases (all additional information will be removed at the publication stage).</mark>
### 6.3.5 Semantics Reasoning Requirements
**Table 7: Semantics Reasoning Requirements**<a name="table_7"></a>
|Requirement ID |Description |Release |
|-|-|-|
|RES-001<br />See REQ-2015-0521R01 |The oneM2M System shall be able to update ontologies as a result of the ontology reasoning. |Not implemented |
|RES-002<br />See REQ-2015-0521R01 |The oneM2M System shall be able to support semantic reasoning e.g. ontology reasoning or semantic rule-based reasoning. |Not implemented |
|RES-003<br />See REQ-2015-0521R01 |The oneM2M System shall be able to support adding and updating semantic information based on semantic reasoning. |Not implemented |
### 6.3.6 Data Analytics Requirements
**Table 8: Data Analytics Requirements**<a name="table_8"></a>
|Requirement ID |Description |Release |
|-|-|-|
|ANA-001<br />See REQ-2015-0521R01 |The oneM2M System shall be able to support capabilities (e.g. processing function) for performing M2M data analytics based on semantic descriptions from M2M Applications and /or from the M2M System. |Not implemented |
|ANA-002<br />See REQ-2015-0521R01 |The oneM2M System shall provide the capability of interpreting and applying service logic (e.g. rules/policies of triggering operations upon other resources or attributes according to the change of the monitored resource) described with semantic annotation and ontology. |Not implemented |
|ANA-003<br />See REQ-2015-0521R01 |The oneM2M System shall support a standardized format for the rules/policies used to define service logic. |Not implemented |
### 6.3.7 Domain specific requirements
**Table 9: Smart Lift Requirements**<a name="table_9"></a>
|Requirement ID |Description |Release |
|-|-|-|
|SLS-001 |oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in <a href="#_ref_i.4">[i.4]</a> and <a href="#_ref_i.5">[i.5]</a>. |R4 |
NOTE1: No specific additional new feature is currently identified in oneM2M to support the Smart Lifts. The oneM2M system supports properly the Smart Lift domain. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems.
### 6.3.8 Advanced Semantic Discovery Requirements
**Table 9-bis: Advanced Semantic Discovery Requirements**<a name="table_9-bis"></a>
|Requirement ID |Description |Release |
|-|-|-|
|ASD-001<br />See RDM-2020-0063 |The oneM2M system shall provide mechanisms for Advanced Semantic Discovery (ASD) across a distributed network of IoT nodes within a single oneM2M Service Provider and across different IoT Service Providers. |Rel-5 |
|ASD-002<br />See RDM-2020-0063 |A CSE receiving an Advanced Semantic Discovery Query (ASDQ) shall extract the Semantic Discovery Query (SDQ), embedded in the packet payload, and shall resolve the query with respect to the locally available information and shall forward to other suitable CSEs the Advanced Semantic Discovery Query (ASDQ) to complete the discovery. |Rel-5 |
|ASD-003<br />See REQ-2015-0521R01 |To support Advanced Semantic Discovery the oneM2M system shall provide:<br />An Advanced Semantic Discovery Query Language (ASDQL) that the ability to write Advanced Semantic Discovery Query (ASDQ);<br />A Semantic Discovery Agreement (SDA) to state some communication agreements between CSE;<br />A Semantic Query Resolution (SQR) that allows to locally translate an Advanced Semantic Discovery Query (ASDQ) into some elementary oneM2M Semantic Discovery Queries (SDQ);<br />A Semantic Discovery Routing (SDR) to route an Advanced Semantic Discovery Query (ASDQ) between different CSEs. |Rel-5 |
|ASD-004<br />See RDM-2020-0063 |The oneM2M system shall integrate already standardized ontology extensions to the current oneM2M ontology to cope with new specific domains (ex: SAREF core and its extensions SAREF4BLDG, SAREF4ENVI, SAREF4ENERGY, SAREF4CITY, SAREF4AGRI, SAREF4WATER). |Rel-5 |
|ASD-005<br />See RDM-2020-0063 |Based on semantic information, the oneM2M system shall take routing decisions for forwarding a received Advanced Semantic Discovery Query (ASDQ). The semantic information will allow the oneM2M system to maximize and to accelerate the semantic discovery process. |Rel-5 |
|ASD-006<br />See RDM-2020-0063 |Advanced Semantic Discovery shall support queries written with specific domain ontologies, e.g. SAREF. |Rel-5 |
|ASD-007<br />See RDM-2020-0063 |Advanced Semantic Discovery shall support semantic reasoning between the baseline oneM2M ontology and the identified domain specific ontologies, e.g. SAREF. As example, if a query is looking for a oneM2M device observing Celsius temperature, then the Advanced Semantic Discovery would potentially return a SAREF temperature sensor |Rel-5 |
|ASD-008<br />See RDM-2020-0063 |Advanced Semantic Discovery shall provide capabilities to identify multiple set of targets, and a multiplicity of searches (e.g. by setting parameters or filters). |Rel-5 |
|ASD-009<br />See RDM-2020-0063 |The oneM2M Access Control Policy shall include discovery permissions to support Advanced Semantic Discovery. When an Advanced Semantic Discovery is performed by the oneM2M System, it shall operate according to the indications associated with the desired information. |Rel-5 |
|ASD-010<br />See RDM-2020-0063 |Advanced Semantic Discovery shall prioritize queries, e.g. to ensure a quick response to urgent situations. |Rel-5 |
|ASD-011<br />See RDM-2020-0063 |Advanced Semantic Discovery shall minimize complexity to avoid impacting negatively the oneM2M system performance. |Rel-5 |
|Publication history |Publication history |Publication history |
NOTE 1: These requirement are derived from the Advances Semantic Discovery studies in <a href="#_ref_i.4">[i.4]</a> and <a href="#_ref_i.6">[i.6]</a>.
NOTE2: The solution would be based an evolution of the current oneM2M architecture and functionality and would reuse existing standard ontology mechanisms e.g. considering the SAREF standard developed in ETSI TC SmartM2M (which is also aligned with the W3C ontology approach). This intends to assure also a smooth interworking with relevant non-oneM2M solutions.
NOTE3: The solution would be complete and will be a part of the oneM2M core functions, to avoid the need of ad hoc applications designed to expand the oneM2M functionality with the risk of being implemented with different flavours.
## 6.4 Security Requirements
**Table10: Security Requirements**
|Requirement ID |Description |Release |
|-|-|-|
|SER-001 |The oneM2M System shall incorporate protection against threats to its availability such as Denial of Service attacks. |Partially Implemented in Rel-1 |
|SER-002 |The oneM2M System shall be able to ensure the Confidentiality of data. |Implemented in Rel-1 |
|SER-003 |The oneM2M System shall be able to ensure the Integrity of data. | Implemented in Rel-1 |
|SER-004 |In case where the M2M Devices support USIM/UICC and the Underlying Networks support network layer security, the oneM2M System shall be able to leverage device's USIM/UICC credentials and network's security capability e.g. 3GPP GBA for establishing the M2M Services and M2M Applications level security through interfaces to Underlying Network. |Implemented in Rel-1 |
|SER-005 |In case where the M2M Devices support USIM/UICC and the Underlying Networks support network layer security, and when the oneM2M System is aware of Underlying Network's bootstrapping capability e.g. 3GPP GBA, the oneM2M System shall be able to expose this capability to M2M Services and M2M Applications through API. |Implemented in Rel-1 |
|SER-006 |In case where the M2M Devices support USIM/UICC and the Underlying Networks support network layer security, the oneM2M System shall be able to leverage device's USIM/UICC Credentials when available to bootstrap M2M Security Association. |Implemented in Rel-1 |
|SER-007 |When some of the components of an M2M Solution are not available (e.g. WAN connection lost), the oneM2M System shall be able to support the Confidentiality and the Integrity of data between authorized components of the M2M Solution that are available. |Implemented in Rel-1 |
|SER-008 |The oneM2M System shall support countermeasures against unauthorized access to M2M Services and M2M Application Services. |Implemented in Rel-1<br /> |
|SER-009 |The oneM2M System shall be able to support Mutual Authentication for interaction with Underlying Networks, M2M Services and M2M Application Services. |Implemented in Rel-1 |
|SER-010 |The oneM2M System shall be able to support mechanisms for protection against misuse, cloning, substitution or theft of security credentials. |Implemented in Rel-1 |
|SER-011 | The oneM2M System shall protect the use of the identity of an M2M Stakeholder within the oneM2M System against discovery and misuse by other stakeholders. |Implemented in Rel-1 |
|SER-012 |The oneM2M System shall be able to support countermeasures against Impersonation attacks and replay attacks. |Partially implemented in Rel-1<br />(see note 3) |
|SER-013 |The oneM2M System shall be able to provide the mechanism for integrity-checking on boot, periodically on run-time, and on software upgrades for software/hardware/firmware component(s) on M2M Device(s). |Not implemented |
|SER-014 |The oneM2M System shall be able to provide configuration data to an authenticated and authorized M2M Application in the M2M Gateway/Device. |Implemented in Rel-1 |
|SER-015 |The oneM2M System shall be able to support mechanisms to provide M2M Service Subscriber identity to authorized and authenticated M2M Applications when the oneM2M System has the M2M Service Subscriber's consent. |Partially implemented<br />(see note 4) |
|SER-016 |The oneM2M System shall be able to support non repudiation within the M2M service layer and in its authorized interactions with the network and application layers. |Implemented in Rel-1 |
|SER-017 |The oneM2M System shall be able to mitigate threats identified in oneM2M TR0008 <a href="#_ref_i.3">[i.3]</a>. |Implemented in Rel-1 |
|SER-018 |The oneM2M System shall enable an M2M Stakeholder to use a resource or service and be accountable for that use without exposing its identity to other stakeholders. |Partially implemented |
|SER-019 |The oneM2M System shall be able to use service-level Credentials present inside the M2M Device for establishing the M2M Services and M2M Applications level security. |Implemented in Rel-1 |
|SER-020 |The oneM2M System shall enable legitimate M2M Service Providers to provision their own Credentials into the M2M Devices/Gateways. |Implemented in Rel-1<br />(see note 5) |
|SER-021 |The oneM2M System shall be able to remotely and securely provision M2M security Credentials in M2M Devices and/or M2M Gateways. |Implemented in Rel-1<br />(see note 5) |
|SER-022 |The oneM2M System shall enable M2M Application Service Providers to authorize interactions involving their M2M Applications on supporting entities (e.g. Devices/ Gateways/ Service infrastructure). |Implemented in Rel-1 |
|SER-023 |Where a Hardware Security Module (HSM) is supported, the oneM2M System shall be able to rely on the HSM to provide local security. |Partially implemented |
|SER-024 |The oneM2M System shall enable M2M Applications to use different and segregated security environments. |Partially implemented |
|SER-025 |The oneM2M System shall be able to prevent unauthorized M2M Stakeholders from identifying and/or observing the actions of other M2M Stakeholders in the oneM2M System, e.g. access to resources and services (see note 1). |Implemented in Rel-1 |
|SER-026 |The oneM2M System shall be able to provide mechanism for the protection of Confidentiality of the geographical location information (see note 2). |Implemented in Rel-1 |
|SER-027<br />See REQ-2015-0558R01 |The M2M System shall support grouping of M2M Applications that have the same access control rights towards one specific resources, together so that access control validation can be performed by validating if the M2M Application is a member of certain group. |Implemented in Rel-2 |
|SER-028<br />See REQ-2015-0568R04 |The oneM2M System shall enable security protocol end-points to protect portions of individual application-generated data so that intermediate entities (whether trusted or untrusted) forwarding the data are unable to access the protected portions of the data in clear text. |Implemented in Rel-2 |
|SER-029<br />See REQ-2015-0568R04 |The oneM2M System shall enable security protocol end-points to protect portions of individual application-generated data so that security protocol end-points can detect modification, including modification by intermediate service layer entities (whether trusted or untrusted) forwarding the data. |Implemented in Rel-2 |
|SER-030 |The oneM2M System shall enable security protocol end-points to protect portions of individual oneM2M messages so that intermediate entities (whether trusted or untrusted) forwarding the messages are unable to access the protected portions of the messages in clear text. |Implemented in Rel-2 |
|SER-031<br />See REQ-2015-0569R03 |The oneM2M System shall enable security protocol end-points to protect portions of individual oneM2M messages so that security protocol end-points can detect modification, including modification by intermediate service layer entities (whether trusted or untrusted) forwarding the messages. |Implemented in Rel-2 |
|SER-032<br />See REQ-2015-0569R03 |The oneM2M System shall enable security protocol end-points to establish security sessions which are used for protecting portions of one or more oneM2M messages so that intermediate entities (whether trusted or untrusted) forwarding the messages are unable to access the protected portions of the messages in clear text. |Implemented in Rel-2 |
|SER-033<br />See REQ-2015-0569R03 |The oneM2M System shall enable security protocol end-points to establish security sessions which are used for protecting portions of one or more oneM2M messages so that security protocol end-points can detect modification, including modification by intermediate service layer entities (whether trusted or untrusted) forwarding the messages. |Implemented in Rel-2 |
|SER-034<br />See REQ-2015-0575R01 |The oneM2M System shall enable security protocol end-points to protect portions of messages or data so that intermediate entities (whether trusted or untrusted) forwarding the messages or data are unable to access the protected portions of messages or data in clear text. |Partially<br />Implemented |
|SER-035<br />See REQ-2015-0575R01 |The oneM2M System shall enable security protocol end-points to protect portions of messages or data so that security protocol end-points can detect modification, including modification by intermediate service layer entities (whether trusted or untrusted) forwarding the messages or data. |Partially<br />Implemented |
|SER-036<br />See REQ-2015-0575R01 |The oneM2M System shall enable security protocol end-points to authenticate each other without relying on intermediate service layer entities (whether trusted or untrusted). |Implemented in Rel-2 |
|SER-037<br />See SEC-2015-0515R02 |The oneM2M System shall be able to support distributed authorization functions for making access control decisions, providing Access Control Policies and providing authorization attributes (e.g. roles). |Partially<br />Implemented |
|SER-038<br />See SEC-2015-0515R02 |The oneM2M System shall be able to expose an interoperable interface to provide Access Control Policies by means of specified access control policy language. |Not implemented |
|SER-039<br />See SEC-2015-0515R02 |The oneM2M System shall enable individuals to establish policies for controlling access to their personal identifiable information even when it may have been collected without their knowledge. |Implemented in Rel-2 |
|SER-040<br />See SEC-2015-0517R05 |When the M2M Devices are grouped and the M2M Gateway is authorized as the delegate of the group to access the M2M Server, the M2M Gateway shall be able to, perform Mutual Authentication with the M2M Server, on behalf of the M2M Devices in thegroup |Not Implemented |
|SER-041<br />See SEC-2015-0517R05 |When the M2M Devices are grouped and the M2M Gateway belongs to a third party, oneM2M System shall be able to protect Security and Privacy of communication between individual M2M Device and M2M Server from other M2M devices and the third party M2M Gateway. |Implemented in Rel-2 |
|SER-042<br />See SEC-2015-0522R02 |A secured API shall enable application and service layer entities to make use of sensitive functions and data residing within the Secure Environment, independently of the technical implementation of the Secure Environment. |Not Implemented |
|SER-043<br />See REQ-2015-0590R01 |The oneM2M System shall enable authorizing a oneM2M entity to temporarily delegate its access rights (or a subset thereof) to another authorized oneM2M entity, wherein the dynamically delegated access rights shall not enable the "delegated-to" oneM2M entity to delegate the same rights in turn to a third oneM2M entity. |Not Implemented |
|SER-044<br />See REQ-2015-0591R04 |For M2M Application Service data, that are processed by an M2M Application B in a M2M entity (e.g. M2M Gateway) on its path from an originator A to the recipient M2M Application C, the oneM2M System shall provide means that enable the recipient to verify both:<br />integrity of the data received by the M2M Application B from the originator A;<br />and, at the same time:<br />that the M2M Application B that has processed the data has not been compromised. |Not Implemented |
|SER-045<br />See REQ-2015-0604R02 |The oneM2M System shall support classification of application data by M2M Applications into various security levels that are specified by oneM2M and support the mapping of these levels to applicable security capabilities. |Not Implemented |
|SER-046<br />See REQ-2015-0605R04 |The oneM2M System shall enable to protect portions of individual application generated data that is at-rest (e.g. hosted data) for integrity protection and data creator Authentication. |Implemented in Rel-2 |
|SER-047<br />See REQ-2015-0605R04 |The oneM2M System shall enable to protect portions of individual application data at-rest (e.g. hosted data) for confidentiality protection. |Implemented in Rel-2 |
|SER-048<br />See REQ-2015-0605R04 |The oneM2M System shall ensure that the end-to-end data Credentials are protected for Confidentiality, integrity and against tampering. |Implemented in Rel-2 |
|SER-049<br />See REQ-2015-0605R04 |The oneM2M System shall ensure that the end-to-end data Credentials are protected from exposure to intermediate entities. |Implemented in Rel-2 |
|SER-050<br />See REQ-2015-0620 |The oneM2M System shall enable pre-defined conditions to be protected from unauthorized modification. |Implemented in Rel-2 |
|SER-051<br />See REQ-2015-0620 |The oneM2M System shall enable the deletion of M2M data produced/stored by the M2M Devices/Gateways based on request from an authorized entity. |Implemented in Rel-2 |
|SER-052<br />See REQ-2015-0621R01 |The oneM2M System shall store and process privacy preferences in an interoperable manner. |Implemented in Rel-2 |
|SER-053<br />See REQ-2015-0621R01 |The oneM2M System shall support privacy profiles at various levels to care for conditions of legal requirements, manufacturers, and data subjects. |Implemented in Rel-2 |
|SER-054<br />See REQ-2015-0621R01 |The oneM2M System shall be able to prioritize privacy profiles where there is a conflict between profiles (legal profile takes priority over data subject profile, for example). |Implemented in Rel-2 |
|SER-055<br />See REQ-2015-0623R01 |The oneM2M System shall be able to support configuration of security related settings of its infrastructure side components by a privileged user through standardized API. |Not implemented |
|SER-056<br />See REQ-2015-0623R01 |The oneM2M System shall allow overriding of security settings by a privileged User through standardized API. |Not implemented |
|SER-057<br />See REQ-2015-0623R01 |The oneM2M System shall support a mechanism enabling addition/deletion of information enabling authentication of oneM2M entities through standardized API. |Not implemented |
|SER-058<br />See REQ-2015-0627R02 |The oneM2M System shall enable delegation of security functions (e.g. message authentication/integrity protection) of an entity to a trust-worthy entity. |Implemented in Rel-2 |
|SER-059<br />See REQ-2015-0628R01 |The oneM2M System shall protect the authenticity, Integrity, and Confidentiality of the representation of the delegated access rights. |Implemented in Rel-2 |
|SER-060<br />See REQ-2015-0628R01 |The oneM2M System shall be able to revoke the representation of the delegated access rights. |Implemented in Rel-2 |
|SER-061<br />See 0585R01- App-ID Requirements |The oneM2M System shall be able to verify the App-ID to support the detection of impersonation or to support revocation. |Not implemented |
|SER-062<br />See REQ-2016-0056R01 |The oneM2M System shall be able to reuse the privacy policy of the Underlying Network. |Not implemented |
|SER-063<br />See REQ-2016-0056R01 |The oneM2M System shall be able to share its privacy policy with the Underlying Network. |Not implemented |
|SER-064<br />See REQ-2017-0005R03 |The M2M Devices shall provide a mechanism to prevent installation or modification of the software/middleware/firmware which run on the M2M Devices, unless it is authorized by an allowed stakeholder. |Implemented in Release 3? |
|SER-065<br />See REQ-2017-0005R03 |The oneM2M System shall be able to detect installation or modification of the software/middleware/firmware of M2M Devices that has not been authorized by an allowed stakeholder. |Implemented in Release 3? |
|SER-066<br />See REQ-2017-0005R03 |The oneM2M System shall enable allowed stakeholders to restrict or prevent operation of M2M devices using software/middleware/firmware that the stakeholders did not authorize. |Implemented in Release 3? |
|SER-067<br />See REQ-2017-0005R03 |The oneM2M System shall be able to prevent malfunction of M2M Devices caused by receiving unsolicited messages or information. |Implemented in Release 3? |
|SER-068<br />See REQ-2017-0030R05 |The information exchanged within the oneM2M System shall use cryptographic technology to ensure information authentication and information integrity. |Implemented in Rel-2 |
|SER-069<br />See REQ-2017-0030R05 |The oneM2M System shall be able to securely transfer information by using an appropriate method such as digital signature. |Implemented in Rel-2 |
|SER-070<br />See REQ-2017-0030R05 |The oneM2M System shall be able to support security mechanisms to protect cryptographic keys and cryptographic operations by using tamper resistant elements such as TPM (Trusted Platform Module), HSM (Hardware Security Module) and SIM (Subscriber Identity Module). |Partially Implemented Note 7 |
|SER-071<br />See REQ-2017-0030R05 |The oneM2M System shall be able to support processing and granting of requests based on access rights of a resource if the required conditions are met |Implemented in Rel-1 |
|SER-072<br />See REQ-2017-0030R05 |The oneM2M System shall provide privacy protection mechanisms at the central server. |Implemented in Rel-2 |
|SER-073<br />See REQ-2017-0031R05 |The oneM2M system shall be able to support authentication using device key and the integrity check ofM2M Device(s). |Rel-3? |
|SER-074<br />See REQ-2017-0031R05 |The oneM2M system shall be able to support anonymization of the t information being provided, when requested by M2M Applications.. |Rel-3/ future releases? |
|SER-075<br />See REQ-2017-0031R05 |The oneM2M System shall apply appropriate security levels for Applications that can have safety impacts (e.g. protection from malicious attacks) |Rel-3/ future releases? |
|SER-076<br />See REQ-2018-0001 |The oneM2M System shall be able to provide a framework for end-to-end authentication of user applications to the M2M vendor's specific nodes (non oneM2M). | |
|SER-077<br />See REQ-2018-0021R03 |The oneM2M System shall be able to authenticate metadata (e.g. Firmware version, Manufacturer ID, HW version) from field devices (e.g. located behind a gateway). | |
|SER-078<br />See REQ-2018-0021R03 |The oneM2M System shall be able to trigger the secure (e.g. authenticity, integrity, and confidentiality protected) Firmware/Software update of field devices. | |
|SER-079<br />See ARC-2018-0062 |The oneM2M System shall support access control and authorization mechanisms based on M2M Service Subscriber and M2M Service User identification. |Rel-4 |
|SER-080<br />See ARC-2018-0062 |The oneM2M System shall support M2M Service Subscriber and M2M Service User profiles specifying their restrictions (e.g. privacy restrictions, max number and/or types of applications and devices the M2M Service Subscriber and its authorized M2M Service Users are allowed to register to the M2M System, the maximum number of resources or bytes of data that the M2M Service Subscriber can store in the M2M System, etc.) and their default configurations (e.g. access control policies, expiration times, max number of content instances, etc.). |Rel-4 |
|SER-081<br />See ARC--2018-0062 |The oneM2M System shall support access control and authorization mechanisms based on M2M Service Subscriber and M2M Service User identification. | |
|SER-082<br />See ARC--2018-0062 |The oneM2M System shall support M2M Service Subscriber and M2M Service User profiles specifying their restrictions (e.g. privacy restrictions, max number and/or types of applications and devices the M2M Service Subscriber and its authorized M2M Service Users are allowed to register to the M2M System, the maximum number of resources or bytes of data that the M2M Service Subscriber can store in the M2M System, etc.) and their default configurations (e.g. access control policies, expiration times, max number of content instances, etc.). | |
|SER-083<br />See RDM-2019-0054R01 |The oneM2M System shall support access control and authorization mechanisms for the M2M Service Subscriber or M2M Service User information, based on dynamic parameters (e.g. on/off duty time schedule, location, role or job position etc.). |Rel-4 |
|SER-084<br />See RDM-2019-0054R01 | The oneM2M System shall be able to access M2M Service Subscriber information or M2M Service User information based on dynamic parameters (e.g. on/off duty time schedule, location, role or job position, etc.) from M2M Applications. |Rel-4 |
NOTE 1: The above requirement does not cover items outside of the oneM2M System, e.g. Underlying Networks.
NOTE 2: Geographical location information can be more than simply longitude and latitude.
NOTE 3: Partly supported for Impersonation attacks not supported for Replay attacks.
NOTE 4: The oneM2M System has no means to verify a subscriber's consent. This requirement is only fulfillable at application level.
NOTE 5: Regarding remote provisioning, Release 1 supports remote provisioning of symmetric key credentials only.
NOTE6: An M2M device may include e.g. firmware managed by an OEM vendor, middleware managed by a service provider and software managed by an application provider. The entity managing a software piece is designed as "allowed stakeholder" in the requirements above.
NOTE 7: Support for SIM is supported in Release 1 and Release 2.
## 6.5 Charging Requirements
**Table 11: Charging Requirements**<a name="table_11"></a>
|Requirement ID |Description |Release |
|-|-|-|
|V1.x.x |&lt;yyyy-mm-dd > |&lt;Milestone> |
| | | |
| | | |
| | | |
| | | |
|CHG-001 |The oneM2M System shall support collection of charging specific information related to the individual services facilitated by the oneM2M System (e.g. Data Management, Device Management and/or Connectivity Management).<br />Collection of charging specific information shall be possible concurrent with the resource usage. The format of the recorded information shall be fully specified including mandatory and optional elements. |Implemented in Rel-1<br />(see note 4) |
|CHG-002 |The oneM2M System shall support mechanisms to facilitate correlation of charging information (e.g. of a User) collected for M2M Services, M2M Application Services and services provided by Underlying Network Operators. |Partially implemented <br />(see note 2) |
|CHG-003 |The oneM2M System shall provide means to coordinate charging data records for data usages with differentiated QoS from the Underlying Network. |Not implemented |
|CHG-004 |The oneM2M System shall be able to utilize existing charging mechanisms of Underlying Networks. |Not implemented <br />(see note 3) |
|CHG-005 |The oneM2M System shall support transfer of the charging information records to the billing domain of the M2M Service Provider, for the purpose of:<br />subscriber billing;<br />inter-provider billing;<br />provider-to-subscriber accounting including additional functions like statistics. |Implemented in Rel-1 |
|CHG-006 |The oneM2M System should support generation of charging events for the purpose of requesting resource usage Authorization from the real time credit control system where the subscriber account is located. The information contained in the charging events and the relevant chargeable events shall be fully specified including mandatory and optional elements (see note 1). |Not implemented |
|CHG-007<br />See REQ-2017-0031R05 |The oneM2M System shall support mechanisms to correlate charging information (e.g. data/records) from different M2M Application Service Providers. |Rel-3/ future releases? |
|CHG-008<br />See ARC-2018-0062 |The oneM2M System shall support charging event detection, statistics collection and charging records generation mechanisms based on M2M Service Subscriber and M2M Service User identification. | |
NOTE1: A chargeable event is any activity, a provider may want to charge for that utilizes the resources and related M2M Services offered by such provider. A charging event is the set of charging information needed by the credit control system for resource authorization.
NOTE 2: Information collected can be sent to the Underlying Networks which may used it for charging.
NOTE 3: The oneM2M service layer can pass info to Underlying Networks but cannot use Underlying Network mechanism. Charging can be done by Underlying Network. This is covered by CHG-002.
NOTE 4: Only supported in the Infrastructure Node.
## 6.6 Operational Requirements
**Table12: Operational Requirements**
|Requirement ID |Description |Release |
|-|-|-|
|OPR-001 |The oneM2M System shall provide the capability for monitoring and diagnostics of M2M Applications. |Implemented in Rel-1<br /> |
|OPR-002 |The oneM2M System shall provide the capability for software management of M2M Applications. |Implemented in Rel-1 |
|OPR-003 |The oneM2M System shall be able to configure the execution state an M2M Application (start, stop, restart). |Implemented in Rel-1 |
|OPR-004 |When suitable interfaces are provided by the Underlying Network, the oneM2M System shall have the ability to schedule traffic via the Underlying Network based on instructions received from the Underlying Network. |Not implemented |
|OPR-005 |The oneM2M System shall be able to exchange information with M2M Applications related to usage and traffic characteristics of M2M Devices or M2M Gateways by the M2M Application. This should include support for the 3GPP feature called: "Time controlled" (see note). |Implemented in Rel-2 |
|OPR-006 |Depending on availability of suitable interfaces provided by the Underlying Network the oneM2M System shall be able to provide information related to usage and traffic characteristics of M2M Devices or M2M Gateways to the Underlying Network. |Implemented in Rel-2 |
|OPR-007<br />See REQ-2015-0550R03 |The oneM2M System shall be able to support receipt of the status information of the Underlying Network if supported by the Underlying Network. |Not implemented |
|OPR-008<br />See REQ-2015-0550R03 |The oneM2M System shall be able to provide the M2M Applications with status information received from the Underlying Network. |Not implemented |
|OPR-009<br />See 0585R01- App-ID Requirements |The format for registered App-IDs shall be able to support use by people and systems to readily determine whether the App-ID is registered and the Registration Authority which issued the App-ID, App Developer and App Name. |Implemented in Rel-2 |
|OPR-010<br />See 0585R01- App-ID Requirements |The oneM2M System Registration Authorities shall be able to collect and maintain supporting required information when assigning an AppID. |Implemented in Rel-2 |
NOTE: "Time controlled" is equivalent to the MTC Features specified in clause 7.2 of 3GPP TS 22.368 <a href="#_ref_1">[1]</a>.
## 6.7 Communication Management Requirements
|Draft history (to be removed on publication) |Draft history (to be removed on publication) |Draft history (to be removed on publication) |
**Table13: Communication Management Requirements**
|Requirement ID |Description |Release |
|-|-|-|
|V1.x.x |&lt;yyyy-mm-dd > |&lt;CR ID> applied - &lt;Summary of changes> |
| | | |
| | | |
| | | |
| | | |
|CMR-001 |The oneM2M System shall provide to M2M Applications a communication service which provides buffering of messages to/from M2M Gateway/Device/ Infrastructure Domain. |Implemented in Rel-1 |
|CMR-002 |The oneM2M System shall be able to support forwarding buffered messages depending on communication policies and based on service preference associated with the buffered messages. |Implemented in Rel-1 |
|CMR-003 |The oneM2M System shall enable an M2M Application to send a communication request with the following service preference:<br />QoS parameters, including delay tolerance, for initiating the delivery of data;<br />categorizing communication requests into different levels of priority or QoS classes. |Implemented in Rel-1 |
|CMR-004 |The oneM2M 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. |Implemented in Rel-1 |
|CMR-005 |The oneM2M System shall be able to maintain context associated with M2M sessions (e.g. security context or network connectivity context during the interruption of the session). |Partially implemented <br />(see note 1) |
|CMR-006<br />See REQ-2015-0564R02 |The oneM2M System shall support the ability for applications to categorize requested communications (priority, importance, etc.), so that the oneM2M System can adapt its actual communications (scheduling, aggregation, compression, etc.) by taking this categorization into account. |Implemented in Rel-1 |
|CMR-007<br />See REQ-2015-0564R02 |The oneM2M System shall support configurable communication policies that will define its communication patterns. Such policies shall take into account information received from the Underlying Network (such as information referred to in OPR-004) as well as information received from the Applications (such as the information referred to in OPR-005 or categorization of communications requested by the applications). |Partially Implemented<br />(see note 2) |
|CMR-008<br />See REQ-2015-0564R02 |The oneM2M System shall support data aggregation based on communication policies when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Implemented in Rel-1 |
|CMR-009<br />See REQ-2015-0564R02 |The oneM2M System should support data compression based on communication policies when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Not Implemented |
|CMR-010<br />See REQ-2015-0564R02 |The oneM2M System shall support an additional randomized delay of communications, based on communication policies, when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Implemented in Rel-2 |
|CMR-011<br />See REQ-2015-0564R02 |The oneM2M System shall be able to monitor its own usage of the Underlying Networks over given periods of time: attempted communications, failed attempts and successful attempts. |Implemented in Rel-2 |
|CMR-012<br />See REQ-2015-0564R02 |The oneM2M System shall be able to restrict its own usage of the Underlying Networks, based on communication policies and on its monitored usage of them, when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Implemented in Rel-2 |
|CMR-013<br />See REQ-2015-0564R02 |The oneM2M System shall be able to refrain from using its own usage of the Underlying Networks, based on a time-based back-off procedure configurable in communication policies, when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Implemented in Rel-2 |
|CMR-014<br />See REQ-2015-0564R02 |The oneM2M System shall be able to restrict its own usage of the Underlying Networks, based on communication policies and on the date and time, when exchanging data between the M2M Gateway/Device/Infrastructure Domain. |Implemented in Rel-1 |
|CMR-015<br />See REQ-2015-0601R01 |The oneM2M System shall be able to identify a series of data (e.g. Time Series Data) and indicate individual data belonging to this series. |Implemented in Rel-2 |
|CMR-0016<br />See REQ-2017-0001R03 |The oneM2M system shall support the data to be transmitted to IoT platform with strict timing and packet loss requirements, determined by the application(s). |Not Implemented |
|CMR-0017<br />See REQ-2017-0001R03 |The oneM2M system shall support the data to be transmitted from IoT platform to subscribed devices with highest priority, with strict timing and packet loss requirements, determined by the application(s). |Not Implemented |
|CMR-0018<br />See REQ-2017-0001R03 |The oneM2M System shall be able to detect and report the missing data in time series, for each source of time sensitive data which is sent to the IoT platform. |Implemented in Rel-2 |
|CMR-0019<br />See REQ-2017-0001R03 |The oneM2M System shall be able to detect and report the missing data in time series, for each time sensitive application receiving data. |Implemented in Rel-2 |
|CMR-0020<br />See REQ-2018-0001 |The M2M System shall be able to distinguish between the raw dataflow and the configuration/control flow for the purpose of authentication (see note 3). | |
NOTE 1: Long lived security context and registration is covered, M2M Sessions are not covered.
NOTE 2: CMDH policies (application side) is implemented, information from the Underlying Network can be utilized but the method for provisioning via Mcn is not covered.
NOTE 3: The configuration flow is the one used to set-up and configure the entity (e.g. node). The flows are distinguished from a logical point of view.
## 6.8 LWM2M Interworking Requirements
**Table14: LWM2M Interworking Requirements**
|Requirement ID |Description |Release |
|-|-|-|
|LWM2M-001<br />See REQ-2015-0517R04 |The oneM2M System shall provide the capability to transparently transport LWM2M Objects between LWM2M Clients and M2M Applications. |Implemented in Rel-2 |
|LWM2M-002<br />See REQ-2015-0517R04 |The oneM2M System shall provide the capability to translate LWM2M Objects into a semantic representation of the LWM2M Object as oneM2M resources. |Implemented in Rel-2 |
|LWM2M-003<br />See REQ-2015-0517R04 |The oneM2M System shall provide the capabilities of the LWM2M Server in order to interwork between LWM2M Clients and M2M Applications. |Implemented in Rel-2 |
|LWM2M-004<br />See REQ-2015-0517R04 |The oneM2M System shall provide the capability for M2M Applications to discover LWM2M Clients using the LWM2M Client's Endpoint Name. |Implemented in Rel-2 |
|LWM2M-005<br />See REQ-2015-0517R04 |When transparently transporting LWM2M Objects, the oneM2M System shall provide the capability for M2M Applications to discover the defining of LWM2M Objects transported by the oneM2M System. |Not implemented |
|LWM2M-006<br />See REQ-2015-0517R04 |When interworking with LWM2M Objects, the oneM2M System shall provide the capability for M2M Applications to discover a LWM2M Object using the LWM2M Object's identifier. |Implemented in Rel-2 |
|LWM2M-007<br />See REQ-2015-0517R04 |The oneM2M System shall provide capability to onboard devices that incorporate a LWM2M Client. |Implemented in Rel-2 |
|LWM2M-008<br />See REQ-2015-0517R04 |The oneM2M System shall provide the capability to interoperate the underlying security mechanisms of the LWM2M Client with the security capabilities provided by the oneM2M System. |Implemented in Rel-2 |
# 7 Non-Functional Requirements (informative)
This clause is intended to gather high-level principles and guidelines that shall govern the design of the oneM2M System. Such principles and guidelines are fundamental to the design of the oneM2M System. But as they cannot necessarily be expressed as requirements per se, they shall be introduced and expressed in this clause.
**Table 15: Non-Functional Requirements**<a name="table_15"></a>
|Requirement ID |Description |Release |
|-|-|-|
|NFR-001 |Continua Health Alliance is incorporating a RESTful approach to its design. To support CHA, oneM2M should consider RESTful styles and approaches while designing the M2M architecture. |Implemented in Rel-1 |
|NFR-002 |The oneM2M System should communicate using protocols that are efficient in terms of amount of exchanged information over amount of exchanged data measured in bytes. |Implemented in Rel-1 |
# Annex A (informative): Requirements for the next release
The requirements contained in this Annex are gathered and targeted for the next release of oneM2M.
- 1 Functional Requirements
- 1.1 Overall System Requirements
- 1.2 Management Requirements
- 1.3 Semantics Requirements
- 1.3.1 Ontology Related Requirements
- 1.3.2 Semantics Annotation Requirements
- 1.3.3 Semantics Query Requirements
- 1.3.4 Semantics Mashup Requirements
- 1.3.5 Semantics Reasoning Requirements
- 1.3.6 Data Analytics Requirements
- 1.4 Security Requirements
- 1.5 Charging Requirements
- 1.6 Operational Requirements
- 1.7 Communication Management Requirements
- 1.8 LWM2M Interworking Requirements
# History
|**Publication history** |**Publication history** |**Publication history** |
|-|-|-|
|V5.0.0 |30-Sep-2020 |Release 5 - Baseline according to V4.8.0, includes agreed contribution from RDM#41 to RDM#46 for Rel.5:<br />RDM-2019-0092R01- Requirement\_for\_ semantic\_mapping\_between\_IoT\_ontology\_and\_object\_identifiers \_Use\_case<br />RDM-2019-0091R02- Adding\_a\_new\_requirement\_to\_TS-0002<br />RDM-2019-0113R01- Requirement\_for\_Vehicle\_Idling\_Alarming\_Service<br />RDM-2020-0063-Advanced Semantic Discovery Requirements |
|V5.1.0 |26-Sep-2022 |This baseline including agreed CR (from RDM#47 to RDM#55):<br />RDM-2022-0028-requirements\_on\_dataset\_creation\_for\_AI\_models |
|V5.2.0 |14-Dec-2023 |This baseline including agreed contributions from RDM#56 to RDM#62 for Rel.5:<br />RDM-2023-0006R01-ML\_model\_management\_requirements<br />RDM-2023-0008-Requirements\_for\_AI\_ML\_data\_augmentation<br />RDM-2023-0009R01-Requirements\_for\_the\_management\_of\_AI\_ML\_data<br />RDM-2023-0010R01-Requirements\_for\_distributed\_AI\_ML\_model\_on\_Edge\_Fog\_nodes<br />RDM-2023-0011R01-Requirements\_for\_the\_management\_of\_AI\_ML\_classifiers<br />RDM-2023-0012R01-Requirements\_to\_support\_autonomous\_AI\_ML |
| V5.2.1 | 03-May-2024 | This baseline converts the document to Markdown format. |
media/Functional_Roles.png 0 → 100644
+ 0
− 0
View file @ 64b3fc53
media/Functional_Roles.png

82.2 KiB

media/Functional_Roles.svg 0 → 100644
+ 592
− 0
View file @ 64b3fc53
Source diff could not be displayed: it is too large. Options to address this: view the blob.
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment