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.