TS-0002-oneM2M-Requirements.md

oneM2M Technical Specification	oneM2M Technical Specification
Document Number	TS-0002-V5.3.0
Document Name:	Requirements
Date:	2024-06-27
Abstract:	The present document contains an informative functional role model and normative technical requirements for oneM2M.

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.

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.

More information about oneM2M may be found at: http//www.oneM2M.org

Copyright Notification

No part of this document may be reproduced, in an electronic retrieval system or otherwise, except as authorized by written permission.

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

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

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.

• [1] 3GPP TS 22.368: "Service requirements for Machine-Type Communications (MTC); Stage 1".

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.

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.

• [i.1] oneM2M Drafting Rules.

  NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.

• [i.2] oneM2M TS-0011: "Common Terminology".
• [i.3] oneM2M TR-0008: "Security Analysis".
• [i.4] oneM2M TR0001: "Use Cases"
• [i.5] ETSI TR 103 546 "SmartM2M: Requirement & Feasibility study for Smart Lifts in IoT"
• [i.6] ETSI TR 103 714 SmartM2M; Study for oneM2M Discovery and Query use cases and requirements

3 Definitions and abbreviations

3.1 Definitions

For the purposes of the present document, the terms and definitions given in oneM2M TS-0011 [i.2] apply.

3.2 Abbreviations

For the purposes of the present document, the following abbreviations apply:

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

4 Conventions

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 [i.1].

NOTE: According to oneM2M Drafting Rules [i.1] 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:

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

5 Introduction to the M2M ecosystem

5.1 Functional roles description

Figure 1: Functional Roles in the M2M Ecosystem

1. The User (individual or company - aka: end-user) fulfils all of the following criteria:

   • Uses an M2M solution.

2. The Application Service Provider fulfils all of the following criteria:

   • Provides an M2M Application Service.
   • Operates M2M Applications.

3. The M2M Service Provider fulfils all of the following criteria:

   • Provides M2M Services to Application Service Providers.
   • Operates M2M Common Services.

4. The Network Operator fulfils all of the following criteria:

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

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.

6 Functional Requirements

6.1 Overall System Requirements

Table 1: Overall System Requirements

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 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 (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: - IP Multimedia communications. - Messaging. - Location. - Charging and billing services. - Device information and profiles. - Configuration and management of devices. - Triggering, monitoring of devices. - Small data transmission. - Group management. (see note 1).	Partially implemented (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 (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 (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 (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: - Connectivity management. - Device management (service level management). - Application Data management. 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 (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: - action initiated either by an M2M Device, M2M Gateway, M2M Services Infrastructure, or M2M Application Infrastructure; - when triggered by schedule or event; - 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 (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 (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 (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 (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 (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 (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 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 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 See REQ-2015-0546R01	The oneM2M System shall be able to collect, store Time Series Data.	Implemented in Rel-2
OSR-76 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 See REQ-2015-0558R01	The oneM2M System shall be capable of collecting asynchronous responses pertaining to the broadcasted messages.	Not implemented
OSR-078 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 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 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 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 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 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 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 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 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 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 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 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 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 (see note 22)
OSR-091 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 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 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 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 See REQ-2015-0631R02	The oneM2M System should provide mappings between different Information Models from non-oneM2M System(s).	Not implemented
OSR-096 See REQ-2015-0631R02	The oneM2M System should be able to interwork with non-oneM2M System(s).	Implemented in Rel-2
OSR-097 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 See REQ-2017-0030R05	The oneM2M System shall enable exchange of information between M2M applications viathe Infrastructure Domain .	Implemented in Rel-1
OSR-115 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 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 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 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 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 See REQ-2017-0031R05	The oneM2M System shall be able to provide the service capability for location based services	Implemented
OSR-121 See REQ-2017-0031R05	The oneM2M System shall be able to provide the service capability supporting Over The Air management.	Implemented
OSR-122 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 See REQ-2017-0031R05	The oneM2M System shall enable exchange of information with the intended vehicles by unicast, multicast and/or broadcast.	Partially Implemented (Note 23)
OSR-124 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 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 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 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 See REQ-2017-0031R05	The oneM2M System shall support mobile/portable M2M Gateway and/or Device.	Rel-3/ future releases?
OSR-129 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 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 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 See REQ-2017-0031R05	The oneM2M System shall be able to verify time synchronization	Rel-3/ future releases?
OSR-133 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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.	Rel-4/ future releases?
OSR-153 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 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 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 See REQ-2018-0013R02	The oneM2M system shall support profile profiles of information models for data exchange Platooning .	Rel-4/ future releases?
OSR-157 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 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 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 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 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 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 See REQ-2018-0018R01	The oneM2M System shall enable to request services provided by Edge/Fog Nodes	Rel-4
OSR-0164 See REQ-2018-0018R01	The oneM2M System shall enable service migration among Edge/fog Nodes.	Rel-4
OSR-0165 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 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 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 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 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 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 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 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 See ARC--2018-0052R02	The oneM2M System shall support request/response message interaction with M2M Devices with minimallatency.
OSR-173 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 See ARC--2018-0052R02	The oneM2M System shall support request/response message interaction with M2M Devices with minimal request/response message size.
OSR-175 See ARC--2018-0052R02	The oneM2M System shall support approaches for M2M Devices to minimize response message size.
OSR-176 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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	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 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 See RDM-2023-0006R01	The oneM2M System shall be able to manage AI/ML models with model metadata.
OSR-226 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 See RDM-2023-0008	The oneM2M System shall be able to handle data augmentation requests for AI/ML purposes.	Rel-5
OSR-228 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 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 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 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 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 See RDM-2023-0010R01	The oneM2M System shall be able to synchronize data between oneM2M devices and virtual world devices.	Rel-5
OSR-234 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 See RDM-2023-0011R01	The oneM2M system shall be able to support the creation and management of classifiers for AI/ML applications as follows: 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 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 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.

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.

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.

NOTE 19: Only the M2M Service Administrative State can be notified. M2M Service Operational Status is not implemented.

NOTE 20: This can be implemented based on preconfigured access rights.

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.

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.

NOTE 25: Customized classifier that can be generated by an application to support a specific detection function such as visual recognition.

6.2 Management Requirements

Table 2: Management Requirements

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

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.

6.3 Semantics Requirements

6.3.1 Ontology Related Requirements

Table 3: Ontology Requirements

Requirement ID	Description	Release
ONT-001 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 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 See REQ-2015-0521R01	The M2M System shall support a common modelling language for ontologies (e.g. OWL).	Implemented in Rel-2
ONT-004 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 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 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 See REQ-2015-0521R01	The M2M System shall be able to support extending ontologies in the M2M System.	Not implemented
ONT-008 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 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 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 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 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 See REQ-2015-0521R01	The M2M System shall be able to support update of ontologies.	Not implemented
ONT-014 See REQ-2015-0521R01	The M2M System shall enable functions for data conversion based on ontologies.	Not implemented
ONT-015 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 See REQ-2015-0521R01	The M2M System shall support storage, management and discovery of ontologies.	Not implemented
ONT-017 See REQ-2015-0609	The oneM2M System shall support a semantic relation ("Is Paired To") between two M2M Devices.	Not implemented
ONT-018 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 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 See REQ-2018-0049R03	The oneM2M system shall be able to detect ontology's mapping conflicts and repair them.	Not implemented
ONT-021 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

Requirement ID	Description	Release
ANN-001 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 See REQ-2015-0521R01	The oneM2M System shall support a common language for semantic description, e.g. RDF.	Implemented in Rel-2
ANN-003 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 See REQ-2015-0521R01	The oneM2M System shall support semantic annotation based on related ontologies.	Implemented in Rel-2
ANN-005 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 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 See REQ-2015-0521R01	The oneM2M system shall provide capabilities to manage data quality descriptions of resource.	Not implemented

6.3.3 Semantics Query Requirements

Table 5: Semantics Query Requirements

Requirement ID	Description	Release
QRY-001 See REQ-2015-0521R01	The oneM2M System shall provide capabilities to discover M2M Resources based on semantic descriptions.	Implemented in Rel-2

6.3.4 Semantics Mashup Requirements

Table 6: Semantics Mashup Requirements

Requirement ID	Description	Release
MSH-001 See REQ-2015-0521R01	The oneM2M System shall provide the capability to host processing functions for mash-up.	Not implemented
MSH-002 See REQ-2015-0521R01	The oneM2M System shall enable M2M Applications to provide processing functions for mash-up.	Not implemented
MSH-003 See REQ-2015-0521R01	The oneM2M System itself may provide pre-provisioned or dynamically created processing functions for mash-up.	Not implemented
MSH-004 See REQ-2015-0521R01	The oneM2M System shall be able to create and execute mash-ups based on processing functions.	Not implemented
MSH-005 See REQ-2015-0521R01	The oneM2M System shall be able to expose mash-ups as resources e.g. virtual devices.	Not implemented

6.3.5 Semantics Reasoning Requirements

Table 7: Semantics Reasoning Requirements

Requirement ID	Description	Release
RES-001 See REQ-2015-0521R01	The oneM2M System shall be able to update ontologies as a result of the ontology reasoning.	Not implemented
RES-002 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 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

Requirement ID	Description	Release
ANA-001 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 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 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

Requirement ID	Description	Release
SLS-001	oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.4] and [i.5].	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

Requirement ID	Description	Release
ASD-001 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 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 See REQ-2015-0521R01	To support Advanced Semantic Discovery the oneM2M system shall provide: An Advanced Semantic Discovery Query Language (ASDQL) that the ability to write Advanced Semantic Discovery Query (ASDQ); A Semantic Discovery Agreement (SDA) to state some communication agreements between CSE; A Semantic Query Resolution (SQR) that allows to locally translate an Advanced Semantic Discovery Query (ASDQ) into some elementary oneM2M Semantic Discovery Queries (SDQ); A Semantic Discovery Routing (SDR) to route an Advanced Semantic Discovery Query (ASDQ) between different CSEs.	Rel-5
ASD-004 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 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 See RDM-2020-0063	Advanced Semantic Discovery shall support queries written with specific domain ontologies, e.g. SAREF.	Rel-5
ASD-007 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 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 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 See RDM-2020-0063	Advanced Semantic Discovery shall prioritize queries, e.g. to ensure a quick response to urgent situations.	Rel-5
ASD-011 See RDM-2020-0063	Advanced Semantic Discovery shall minimize complexity to avoid impacting negatively the oneM2M system performance.	Rel-5

NOTE 1: These requirement are derived from the Advances Semantic Discovery studies in [i.4] and [i.6].

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
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 (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 (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 [i.3].	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 (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 (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 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 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 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 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 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 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 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 Implemented
SER-035 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 Implemented
SER-036 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 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 Implemented
SER-038 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 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 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 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 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 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 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: integrity of the data received by the M2M Application B from the originator A; and, at the same time: that the M2M Application B that has processed the data has not been compromised.	Not Implemented
SER-045 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 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 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 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 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 See REQ-2015-0620	The oneM2M System shall enable pre-defined conditions to be protected from unauthorized modification.	Implemented in Rel-2
SER-051 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 See REQ-2015-0621R01	The oneM2M System shall store and process privacy preferences in an interoperable manner.	Implemented in Rel-2
SER-053 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 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 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 See REQ-2015-0623R01	The oneM2M System shall allow overriding of security settings by a privileged User through standardized API.	Not implemented
SER-057 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 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 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 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 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 See REQ-2016-0056R01	The oneM2M System shall be able to reuse the privacy policy of the Underlying Network.	Not implemented
SER-063 See REQ-2016-0056R01	The oneM2M System shall be able to share its privacy policy with the Underlying Network.	Not implemented
SER-064 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 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 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 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 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 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 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 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 See REQ-2017-0030R05	The oneM2M System shall provide privacy protection mechanisms at the central server.	Implemented in Rel-2
SER-073 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 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 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 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 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 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 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 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 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 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 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 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
<<<<<<< TS-0002-oneM2M-Requirements.md
SER-085 See TR-0062	The oneM2M System shall support the ability to apply pseudonymisation and anonymisation techniques to data based on specified privacy preferences, ensuring compliance with applicable privacy regulations (e.g., GDPR) and protecting data subject identity.	Rel-4
SER-086 See TR-0062	The oneM2M System shall ensure that "additional information" used for pseudonymisation is securely stored and access-controlled, allowing only authorized entities to link pseudonymised data back to the data subject while maintaining separation from the main data set.	Rel-4
SER-087 See TR-0062	The oneM2M System shall be able to store, manage and access user's consent information for data processing activities associated with oneM2M resources in compliance with requirements from relevant regulations.	Rel-4
SER-088 See TR-0062	The oneM2M System shall provide mechanisms for managing consent information, including the ability to update or withdraw consent, specify the scope and purpose of processing activities, and associate each processing activity with one or more oneM2M resources.	Rel-4

TS-0002-oneM2M-Requirements.md

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

Requirement ID	Description	Release
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). 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 (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 (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 (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: subscriber billing; inter-provider billing; 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 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 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
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 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 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 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 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 [1].

6.7 Communication Management Requirements

Table13: Communication Management Requirements

Requirement ID	Description	Release
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: QoS parameters, including delay tolerance, for initiating the delivery of data; 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 (see note 1)
CMR-006 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 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 (see note 2)
CMR-008 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 See REQ-2015-0517R04	The oneM2M System shall provide capability to onboard devices that incorporate a LWM2M Client.	Implemented in Rel-2
LWM2M-008 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

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

Editor note: add publication history

Draft history (to be removed on publication)

Version	Date	Description
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: RDM-2019-0092R01- Requirement_for_ semantic_mapping_between_IoT_ontology_and_object_identifiers _Use_case RDM-2019-0091R02- Adding_a_new_requirement_to_TS-0002 RDM-2019-0113R01- Requirement_for_Vehicle_Idling_Alarming_Service RDM-2020-0063-Advanced Semantic Discovery Requirements
V5.1.0	26-Sep-2022	This baseline including agreed CR (from RDM#47 to RDM#55): 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: RDM-2023-0006R01-ML_model_management_requirements RDM-2023-0008-Requirements_for_AI_ML_data_augmentation RDM-2023-0009R01-Requirements_for_the_management_of_AI_ML_data RDM-2023-0010R01-Requirements_for_distributed_AI_ML_model_on_Edge_Fog_nodes RDM-2023-0011R01-Requirements_for_the_management_of_AI_ML_classifiers RDM-2023-0012R01-Requirements_to_support_autonomous_AI_ML
V5.2.1	03-May-2024	This baseline converts the document to Markdown format.
V5.3.0	2024-06-27	New baseline