ETSI TR 103 839 V1.1.1 (2023-09)

SmartM2M; Scenarios for evaluation of oneM2M deployments

DTR/SmartM2M-103839

General Information

• Status: Not Published
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 20-Aug-2023
• Completion Date: 01-Sep-2023

Standards Content (Sample)

TECHNICAL REPORT
SmartM2M;
Scenarios for evaluation of oneM2M deployments

2 ETSI TR 103 839 V1.1.1 (2023-09)

Reference
DTR/SmartM2M-103839
Keywords
IoT, methodology, oneM2M, performance,
scenarios, simulation
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
further, no representation or warranty is made of merchantability or fitness
and/or governmental rule and/or regulation and
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
All rights reserved.
ETSI
3 ETSI TR 103 839 V1.1.1 (2023-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 5
1 Scope . 6
1.1 Context for the present document . 6
1.2 Scope of the present document . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Method for Collecting Use Cases . 9
5 Use Case - Smart Campus . 10
5.1 Description . 10
5.2 Source . 10
5.3 Actors . 10
5.4 Pre-conditions . 10
5.5 Triggers . 10
5.6 High Level Illustration . 10
5.7 Normal Flow . 11
5.8 Alternate Flow . 12
5.9 Post-conditions . 12
5.10 oneM2M resources . 12
5.11 Potential Requirements . 14
6 Use Case - Generalization of Event Trigger/Periodic Event IoT System . 15
6.1 Description . 15
6.2 Source . 15
6.3 Actors . 15
6.4 Pre-conditions . 15
6.5 Triggers . 16
6.6 High Level Illustration . 16
6.7 Normal Flow . 16
6.8 Alternative flow . 17
6.9 Post-conditions . 17
6.10 Description of the deployed solution . 18
6.11 Potential Requirements . 18
7 Use Case - Traffic Light Control and Monitoring . 18
7.1 Description . 18
7.2 Source . 18
7.3 Actors . 19
7.4 Pre-conditions . 19
7.5 Triggers . 19
7.6 High Level Illustration . 20
7.7 Normal Flow . 20
7.8 Alternative flow . 22
7.9 Post-conditions . 22
7.10 Description of the Deployed solution or oneM2M resources . 23
ETSI
4 ETSI TR 103 839 V1.1.1 (2023-09)
7.10.0 Foreword . 23
7.10.1 Traffic Light model using custom resource structure . 23
7.10.2 Traffic Light model using custom resource structure . 25
7.10.3 Traffic Light model using Smart Device Template resource structure . 26
7.10.4 Traffic Light model using C-DAC implementation resource structure. 28
7.11 Potential Requirements . 31
8 Conclusion . 31
Annex A: Change History . 33
History . 34

ETSI
5 ETSI TR 103 839 V1.1.1 (2023-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Smart Machine-to-Machine
communications (SmartM2M).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document proposes three use cases scenario of IoT systems specially selected and defined for representing
situations where a modelling and an analysis of the application performances is mandatory. These uses cases are
compliant with the oneM2M standard. They will serve to define a data and a behavioural model for an evaluation of the
application but also the deployment on a oneM2M implementation. The first use case is currently deployed in a smart
campus environment, the second is a generic one that highlights IoT application with event-triggered and time-triggered
characteristics. The last one is a traffic light control system with synchronization features. For all of the scenarios
specific temporal and behavioural constraints to be verified and Key Performance Indexes (KPIs) that have to be
verified are identified.
Introduction
The objective of the present document in conjunction with three other ones [i.2], [i.3] and [i.4] is to provide three use
cases that articulate across different verticals and identify a list of common requirements across these verticals and to
reason on it with a perspective of simulation and performance evaluation.

ETSI
6 ETSI TR 103 839 V1.1.1 (2023-09)
1 Scope
1.1 Context for the present document
The oneM2M standard is now mature and multiple deployments exist all over the world at both experimental and
operational levels. The experimental deployments are conducted for multiple reasons: to evaluate the capabilities of the
standard in terms of expressiveness, usability on specific equipment, connection with specific existing systems or
performance evaluation. To provide a methodological study, based on performance evaluation (time, space) on a given
set of "paradigmatic use cases". The present document will evaluate use cases in terms of running time, memory space,
numerosity of oneM2M entities (like e.g. AE, MN-CSE, CSE, etc.), data transfer volume and real-time needs. The
present document will use a selection of available oneM2M CSE implementations. The present document will provide a
tool to evaluate and simulate the performance of the use cases. The results of this tool development and evaluations of
the use cases will be the basis to generate three Technical Reports [i.2], [i.3] and [i.4] and one Technical Specification
[i.1]. The present document was developed in the context of ETSI Testing Task Force (TTF) T019, set up to perform
work on "Performance Evaluation and Analysis for oneM2M Planning and Deployment". Five elements were addressed
sequentially:
1) A collection of use cases and derived requirements were formally identified and defined. This work includes
identification of relevant deployment scenarios. The present document adopted the use case style and template
from oneM2M with a minor modification to address some performances issues. This phase of the work
resulted in ETSI TR 103 839 (the present document).
2) The definition of performance evaluation model, with specification of procedures to assess the performance
of oneM2M-based IoT platforms. This includes the identification and definition of a set/list of KPIs necessary
to assess the deployment. For those KPIs, provision of a formal description of the test campaign and the test
results to be obtained. This phase of the work resulted in deliverable ETSI TS 103 840 [i.1].
3) The creation of a proof of concept of a performance evaluation tool. This work also relies on a formal
description of the identified deployment scenarios (single vertical domain & multiple vertical domains). This
phase of the work resulted in ETSI TR 103 841 [i.2].
4) A practical demonstration and analysis exercise putting the proposed tool to use, with a specific oneM2M
implementation but aimed at being a blueprint for the adoption and re-use of the results of ETSI TR 103 839
(the present document), ETSI TS 103 840 [i.1] and ETSI TR 103 841 [i.2] with other oneM2M
implementations and deployment scenarios. This phase of the work resulted in ETSI TR 103 842 [i.3].
5) The development of a set of guidelines and best practices documenting best practices and lessons learnt as
well as providing instructions for IoT solution topology, capacity provisioning, expected performances. This
phase of the work resulted in ETSI TR 103 843 [i.4].
The present document covers the first of the five items listed above and provides the basis for the related ETSI
publications listed below:
• ETSI TR 103 839: Scenarios for evaluation of oneM2M deployments (the present document);
• ETSI TS 103 840: Model for oneM2M Performance Evaluation [i.1];
• ETSI TR 103 841: oneM2M Performances Evaluation Tool (Proof of Concept) [i.2];
• ETSI TR 103 842: Demonstration of Performance Evaluation and Analysis for oneM2M Planning and
Deployment [i.3];
• ETSI TR 103 843: oneM2M deployment guidelines and best practices [i.4].
ETSI
7 ETSI TR 103 839 V1.1.1 (2023-09)
1.2 Scope of the present document
The present document identifies additional requirements to be potentially submitted to oneM2M in the areas of
performance evaluation by means of relevant use cases. The oneM2M architecture ([i.5] and [i.6]) is targeted as the
standard to be evaluated regarding these use cases and requirements. The present document is structured as follows:
• Clauses 1 to 3 set the scene and provide references as well as definition of terms, symbols and abbreviations,
which are used in the present document.
• Clause 4 describes the method used for collecting Use Cases providing a proposal of a tiny extension of the
use case "template" as provided in oneM2M-Template-Use-Case [i.7] and extensively used in oneM2M
TR-0001 [i.8].
• Clause 5 presents Use Case, called "Smart Campus".
• Clause 6 presents a Use Case, called "Generalization of event trigger/periodic event IoT system" that focuses
on classical event triggered and or time triggered behavioural aspects to be captured in IoT systems. The
objective is to obtain, based on such an example, some generic constraints to be expressed and to determine
the associated constraints and KPI to be evaluated.
• Clause 7 presents a Use Case, called "Traffic lights Control and monitoring", reflecting a deployment by
C-DAC, India and several generic implementation variations.
• Clause 8 presents oneM2M feature coverage analysis of the use cases collected.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long-term validity.
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] ETSI TS 103 840: "SmartM2M; Model for oneM2M Performance Evaluation".
[i.2] ETSI TR 103 841: "SmartM2M; oneM2M Performances Evaluation Tool (Proof of Concept)".
[i.3] ETSI TR 103 842: "SmartM2M; Demonstration of Performance Evaluation and Analysis for
oneM2M Planning and Deployment".
[i.4] ETSI TR 103 843: "SmartM2M; oneM2M deployment guidelines and best practices".
[i.5] oneM2M TS-0001 (V4.19.0): "Functional Architecture".
[i.6] ETSI TS 118 111 (V2.4.1): "oneM2M; Common Terminology (oneM2M TS-0011 version 2.4.1
Release 2)".
[i.7] oneM2M-Template-Use-Case.
[i.8] oneM2M TR-0001 (V4.3.0): "Use Cases Collection".
ETSI
8 ETSI TR 103 839 V1.1.1 (2023-09)
[i.9] Shubham Mante, SVSLN Surya Suhas Vaddhiparthy, Muppala Ruthwik, Deepak Gangadharan,
Aftab M. Hussain, Anuradha Vattem: "A Multi-Layer Data Platform Architecture for Smart Cities
th
using oneM2M and IUDX", 8 IEEE World Forum on the Internet of Things (loT), June 2023,
Yokohama, Japan.
[i.10] S. Mante, R. Muppala, D. Niteesh, and A. M. Hussain: "Energy monitoring using
LoRaWAN-based smart meters and oneM2M platform", in Proc. IEEE Sensors, October 2021.
[i.11] S. U. N. Goparaju, S. S. S. Vaddhiparthy, C. Pradeep, A. Vattem, and D. Gangadharan: "Design of
an IoT system for machine learning calibrated TDS measurement in smart campus", in Proc.
th
7 IEEE World Forum Internet Things (WF-IoT), June 2021, pp. 877-882.
[i.12] oneM2M TS-0023 (V3.9.0): "Home Appliances Information Model and Mapping".
[i.13] oneM2M TS-0031 (V3.0.1): "Feature Catalogue".
[i.14] IEEE 802.11: "IEEE Standard for Information Technology--Telecommunications and Information
Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements -
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
guidelines and good practices: methodological document that gives hints to deploy a oneM2M infrastructure
oneM2M implementations: list of the implementations of the oneM2M standard
oneM2M numerosity objects: scalability of a oneM2M application
performance evaluation: evaluation of temporal, data transfer volumetry and scalability aspects of a system
platform evaluation tool: simulation environment that is used to calculate/demonstrate the performance of the
oneM2M standard
real time requirements: timing constraints to be fulfilled by a system
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 111 [i.6] and the following apply:
AC Air Conditioning
ACP Access Control Policy
ADN Application Dedicated Node
AE Application Entity
AE-CM Application Entity - Crowd Monitoring
API Application Program Interface
AQ Air Quality
ASN-CSE Application Service Node - Common Services Entity
ATCS Adaptive Traffic Control System
C-DAC The Centre for Development of Advanced Computing
CM Crowd Monitoring
ETSI
9 ETSI TR 103 839 V1.1.1 (2023-09)
CO Carbon monoxide
COAP Constrained Application Protocol
CoSMiC Common SMart iot Connectivity
COVID Coronavirus Disease
CSE Common Services Entity
CSF Common Services Function
DEL Data Exchange Layer
DML Data Monitoring Layer
DPA Data Platform Architecture
DSL Data Storage Layer
ETSI European Telecommunications Standards Institute
EV Emergency Vehicle
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
HVAC Heating Ventilation Air Conditioning
IEEE Institute for Electrical and Electronic Engineers
IIIT International Institute of Information Technology
IIIT-H IIIT-Hyderabad
IN Infrastructure Node
IN-CSE Infrastructure Node - Common Services Entity
IoT Internet of Things
IPE Interworking Proxy application Entity
IUDX Indian Urban Data Exchange
KPI Key Performance Indexes
LORA LOng RAnge (LoRa)
LoRaWAN LoRa-Wide Area Network
LTE Long Term Evolution
M2M Machine-to-Machine
MN Middle Node
MN-CSE Middle Node - Common Services Entity
MQTT Message Queuing Telemetry Transport
NoSQL Not only Standard Query Language
OM2M Open-Source platform for M2M communication (Eclips)
RAM Random Access Memory
RDF Resource Description Framework
SDT Smart Device Template
SQL Standard Query Language
TC Technical Committee
TDS Total Dissolved Solids
TR Technical Report
TRAM Traffic Monitoring and Management
TRAMMA Traffic Monitoring and Management Application
TS Technical Specification
TTF Testing Task Force
URI Uniform Resource Identifier
WF-IoT World Forum Internet Things ®
Wi-Fi Wireless Fidelity (IEEE 802.11family)
WiSUN Wireless Smart Ubiquitous Network
4 Method for Collecting Use Cases
The oneM2M template for the contribution of use cases [i.7] served as the source for structuring the clauses of the
present document, which describes the use cases and the potential requirements to oneM2M derived from them. A call
for input was issued to oneM2M delegates to provide real deployed use cases that may be examined as proof of concept
examples for analysis. The following clauses capture the inputs received.
ETSI
10 ETSI TR 103 839 V1.1.1 (2023-09)
5 Use Case - Smart Campus
5.1 Description
This use case is based on the deployment made at International Institute of Information Technology, Hyderabad (IIIT).
It is focused on smart campus with several domains involved such as: smart buildings, energy, water, streetlight,
pollution, etc.
Localization: The campus of IIIT is in Telangana, India. IIIT is a residential institute spread over 66 acres.
The campus of IIIT University has deployed a Modular Data Platform Architecture (DPA) that is compliant with the
Indian Urban Data Exchange - IUDX (https://iudx.org.in/) framework and oneM2M standards. The architecture consists
of a oneM2M-based Data Monitoring Layer (DML) for seamless data accumulation from various sensor networks of a
smart city such as air quality, water quality, and energy monitoring. This data is stored in the Data Storage Layer (DSL)
using a multi-tenant architecture with multiple logical databases, enabling efficient and reliable data management.
Finally, the Data Exchange Layer (DEL) enables secure data sharing in a format compliant with IUDX vocabulary.
5.2 Source
This oneM2M architecture is deployed at University Campus of International Institute of Information Technology,
Hyderabad, India. Information has been collected based on [i.9].
5.3 Actors
M2M service provider: technical service and research department that provide the M2M service. This includes the
server, sensors, networks and management of the oneM2M stack. The M2M service provider exposes API for the
access of data.
External users: Based on authorization mechanism and specific layer, they can access the Data for campus management,
research and industry activities.
5.4 Pre-conditions
The campus allows the deployment of sensors and connection to existing systems.
The M2M service provider proposes a oneM2M resources architecture, deploys the system and manages it.
5.5 Triggers
Some transitional phases will happen when the setting of the overall architecture and when new equipment should be
connected (registration of new gateways on servers, registration of end devices on gateways).
On the permanent phase, the sensor data are sent to the IN-CSE through the oneM2M architecture. Through
subscriptions and request response the external elements analyses and react to the data collected.
5.6 High Level Illustration
The proposed architecture consists of a DML, DSL and a DEL as illustrated in Figure 5.6-1. Multiple IoT nodes post
data to the DML at predefined intervals depending on the parameters being monitored. The DML forwards this data
using the subscription-notification CSF of oneM2M to the DSL, where it is parsed and ingested into a database. The
data can be subsequently accessed by registered clients through the APIs defined in the DEL.
The architecture is deployed inside the campus with sensors, network, servers, etc. Several domains are covered: Smart
spaces, Environment, Weather, Water, Energy, etc.
ETSI
11 ETSI TR 103 839 V1.1.1 (2023-09)

Figure 5.6-1: Solution deployed at IIIT-H campus
5.7 Normal Flow
Several types of equipment in different domains are connected to the oneM2M system:
a) Air Quality Monitoring: Several air quality parameters such as particulate matter (pm2.5 and pm10),
temperature, relative humidity, and CO concentration are monitored through densely deployed sensor nodes to
increase the spatial-temporal resolution of air quality data.
b) Crowd Monitoring: This sensor network monitors crowding of people to check the number of mask violations
to avoid a COVID-outbreak inside the campus.
c) Energy Monitoring: Several energy parameters such as the individual phase currents and voltages, power
factor, frequency, energy consumption, apparent and real power are monitored to understand the usage
patterns and provide faster resolutions to power outages (see [i.10] S. Mante, R. Muppala, D. Niteesh, and
A. M. Hussain, "Energy monitoring using LoRaWAN-based smart meters and oneM2M platform", in Proc.
IEEE Sensors, Oct 2021, pp. 1-4.).
d) Water Quality Monitoring: Water quality parameters such as Total Dissolved Solids (TDS), and temperature
are being monitored to avoid health problems caused by poor quality water, as detailed in [i.11] S. U. N.
Goparaju, S. S. S. Vaddhiparthy, C. Pradeep, A. Vattem, and D. Gangadharan, "Design of an IoT system for
th
machine learning calibrated TDS measurement in smart campus", in Proc. 7 IEEE World Forum Internet
Things (WF-IoT), June 2021, pp. 877-882.
e) Smart Room Monitoring: Occupancy state and energy consumption of a room are monitored to adjust the air
conditioning, lighting, and ventilation dynamically.
f) Solar Monitoring: Parameters such as energy generated in a day, signed active power, instantaneous
frequency, output power factor, voltage, and current are monitored to efficiently analyse the solar energy
generated by solar panels.
g) Weather Monitoring: Multiple weather monitoring stations are deployed to monitor parameters such as solar
radiation, temperature, relative humidity, wind direction, wind speed, gust speed and dew point. This data is
used for weather forecasting.
ETSI
12 ETSI TR 103 839 V1.1.1 (2023-09)

Figure 5.7-1: OM2M deployment at IIIT-H campus
The current deployment at IIIT-H uses one infrastructure node. As illustrated in Figure 5.7-1, different verticals use
their respective communication protocols based on the interfaced sensors. The nodes use HTTP as the application
protocol to publish periodic data (event triggered in the case of Occupancy) to their respective containers.
The former architecture adapted individual MN-CSE base for each respective vertical, which are interfaced to an
IN-CSE. This former model was dropped since the deployments were implemented on the same base machine.
5.8 Alternate Flow
Not relevant.
5.9 Post-conditions
The data are stored in the specific database for long-term use.
5.10 oneM2M resources
Table 5.10-1 gives a detailed description of the effective exchange of message between the different parts of the
architecture from sensors to gateways and servers.
ETSI
13 ETSI TR 103 839 V1.1.1 (2023-09)
Table 5.10-1: oneM2M exchanges of messages
Type of sensors Number of Frequency of data Numbers of Communication Connected to
equipment sending for one data in a protocol gateway, server?
equipment message
(Data instances/ (Values per
publishing period) instance)
Air Quality 11 4/min 12 LTE, Wi-Fi IN-CSE
Monitoring
Crowd Monitoring 7 1/min 6 Wi-Fi IN-CSE
Energy Monitoring 50 1/15 min 17 LORA LORAWAN
Gateway
Water Quality 20 1/4hours 5 Wi-Fi IN-CSE
Monitoring
Water Quantity 25 1/min 5 LTE, Wi-Fi External Restful
Monitoring APIs, IN-CSE
Smart Room AC 91 1/min 27 Wi-Fi Bacnet actuator,
Monitoring IN-CSE
Smart Room AQ 18 1/min 7 Wi-Fi IN-CSE
Monitoring
Smart Room Energy 3 1/min 4 Wi-Fi IN-CSE
Monitoring
Smart Room 7 Event triggered 4 Wi-Fi IN-CSE
Occupancy (delay of 1/min)
Monitoring
Solar Monitoring 6 1/min 35 Wi-Fi IN-CSE
Weather Monitoring 2 1/15 min 9 Wi-Fi External Resful
APIs, IN-CSE
Smart Street Lamps 30 1/min 8 WiSUN WiSUN Gateway,
IN-CSE
The data monitoring layer is based on oneM2M standards. It uses the inbuilt CSFs to accumulate data from various IoT
nodes. For instance, every data point generated by a certain water quality node can be stored as a
resource inside the respective resource. Multiple such containers can act as child resources to an
Application Entity () resource, which corresponds to the entire water quality sensor network.
Further, these resources can be managed in groups by defining a resource. Data forwarding to the
DSL is enabled through resources. Every non-ACP resource is linked to an
(ACP) resource via an (ACPI) attribute. ACPs govern the set of allowed operations that can
be performed by a specific user in a given circumstance (time, IP address).
oneM2M also enables discovery and retrieval of resources with options to filter based on type, labels, and content size.
Further, each resource consists of two unique attributes ol, and la whose values act as Uniform Resource
Identifiers (URIs) to retrieve the oldest and the latest respectively. The DML is the first layer to
receive any data point, preserving the highest degree of data freshness in the DPA. Hence, every latestData retrieval
request received by the DEL exploits the la attribute provided by oneM2M.
The developed resource tree is illustrated in Figure 5.10-1. It consists of an IN-CSE, the root or parent for all the
resources in the resource tree. IN stands for Infrastructure Node and CSE stands for Common Service Entity. The
IN-CSE has multiple and , each corresponding to a sensor network, and each to an IoT
node. The describes the node's data attributes and stores the incoming live data. Each sensor network has a
unique to enable controlled data inputs. For instance, in Figure 5.10-1, AE-CM is the application entity
belonging to the Crowd Monitoring (CM) sensor network, which contains six nodes, CM-MG00-00 to CM-VN91-00.
These nodes use the acp-crowd access control policy for publishing the data. Other sensor networks publish data to the
corresponding AEs in a similar manner.
ETSI
14 ETSI TR 103 839 V1.1.1 (2023-09)

Figure 5.10-1: IIIT campus, resources tree
The current system has a dedicated container for each IoT node. Each such container has a Data Container which
receives the data from the node. An individual subscription entity exists for each such data container.
A simple get request can also help in retrieving the data from a data container but, the probability of requesting same
data point would drastically increase due variable frequency of the verticals which lead to adapt the subscription-based
approach.
5.11 Potential Requirements ®
The experiments were conducted on a computer with an Intel Core™ i5-8400 2.80 GHz processor, 8 GB of RAM, and
a 64-bit Ubuntu 18.04 operating system with the opensource eclipse OM2M (https://eclipse.org/om2m). The primary
purpose of this experiment was to mimic the DML's real-time data insertion and retrieval scenarios. A 12-hour
performance test has been conducted on the DML, and the analysis revealed that it could handle 8 parallel users in the
data-insertion scenario. As seen in Figure 5.11-1, the retrieval latency increased proportionally with the increasing
parallel users, and DML was able to handle up to 600 parallel users with zero downtime in the data-retrieval scenario,
while keeping latency well under 100 milliseconds.
The performance evaluation has been conducted in terms of insertions and retrieval latency, where latency is the
number of successful requests served per minute. The testing revealed that 8 parallel nodes can create content instances
in a container at any given instant, and around 600 parallel users can retrieve the latest content instance of a container
from OM2M with an average latency less than 65 ms/request.
ETSI
15 ETSI TR 103 839 V1.1.1 (2023-09)

Figure 5.11-1: IIIT campus: OM2M performance
6 Use Case - Generalization of Event Trigger/Periodic
Event IoT System
6.1 Description
This use case is a generic one based on event triggered computations and periodic computations on a full machine to
machine IoT system. Concerning the deployed architecture, the number of end devices is parametrized as well as the
number of gateways and servers.
Non-functional parameters characterize the behaviour of the system such as periodicity can be settled on the fly.
Non-functional constraints parameters related to response time, parameters on scalability are part of the description.
Such a scenario is typically encountered in intelligent building control systems with a multi-sensor environment, multi
control-command on environmental actuators (heating, lighting, pollution management). This scenario is used to
evaluate the scalability of the system with respect to the infrastructure.This scalability is measured through the criteria
of real-time data recording capacity and their persistence.
6.2 Source
This use case is partially inspired by [i.1], clause 9.5 on Event Triggered Task Execution. The rest of the use case has
been created from scratch.
6.3 Actors
• M2M Devices that produce periodical data.
• Gateway that integrates the oneM2M services of Middle nodes and process and react on certain values.
• Servers that integrate the services of Infrastructure nodes and process and react to certain values.
6.4 Pre-conditions
• Sensor Devices are configured to produce data periodically and send it to a Gateway device.
• Gateway Device is configured to work as the gateway for collecting data from some sensor device and
generates requests to actuator devices.
• Actuator Devices are configured to accept request from a Gateway Device.
ETSI
16 ETSI TR 103 839 V1.1.1 (2023-09)
• Server Device is configured to work as an infrastructure node for collecting data from Gateway Devices and
generate request either to the Gateway or the end devices.
6.5 Triggers
• Transitional phase:
- Setting of the overall architecture: Instantiation of the IN_CSE on the server.
- Registration of gateways on servers.
- Registration of end devices on gateways.
• Permanent phase:
- Production of data by the devices and registration on gateways.
- Reaction of gateways according to sensors values.
- Reaction of servers according to gateways values.
6.6 High Level Illustration
Figure 6.6-1: General view of a multi-level event-triggered and periodic infrastructure
6.7 Normal Flow
Normal Flow 1:
1) Sensor devices produce data periodically and register them on Gateway Devices.
2) Gateway device reports the collected data to Data Storage Server.
3) Server may request actuation on certain devices under certain constraints.
ETSI
17 ETSI TR 103 839 V1.1.1 (2023-09)
Normal flow 2:
1) Sensor devices produce data and register on the Gateway Device.
2) Gateway devices compute data.
3) Gateway may request actuation on certain devices under certain constraints.
6.8 Alternative flow
Alternative flow 1: Non Real-time registration on the Gateway or on the server
1) Sensor Devices produce data and register at a certain rate.
2) The registration time on the Gateway/Server is higher than the production rate of data leading to loss of
samples.
Alternative flow 2: Non Real-time reaction of the Gateway or the server
1) Sensor Devices produce data and register at a certain rate.
2) The reaction time of the Gateway is higher that the production time of data leading to an inconsistent state of
the system.
Alternative flow 3: Overflow on gateways related to maxNrOfInstances parameter or maxByteSize of containers
1) Sensor Devices produce data at a certain rate.
2) Detection of an overflow on a Gateway w.r.t data persistency (data storage) resulting in a loss by data
overwriting.
Alternative flow 4: Overflow on gateways related to Time Series Data Detecting and Reporting
1) Sensor Devices produce data at a certain rate.
Data are missing on the timeseries resource producing a notification by the timeseries resource because the total number
of missing data points becomes equal to or greater than the "minimum specified missing number of the Time Series
Data" in missingData condition.
6.9 Post-conditions
Normal flow 1 & 2:
• Device data are periodically stored either on the gateway or the server.
• Actuation is produced on time according to the response time.
Alternative flow 1:
• Non-Real-time registration on the gateway or on the server.
• Data samples are missing on the gateway or on the server.
Alternative flow 2:
• Non-Real-time reaction of the gateway or the server.
• Reaction of the system is too low with respect to the environment dynamic.
Alternative flow 3:
• Overflow on gateways related to maxNrOfInstances parameter or maxByteSize of containers.
• Inconsistency between data production and data persistency on a database dealing to on a loss by data
overwriting on the data queue.
ETSI
18 ETSI TR 103 839 V1.1.1 (2023-09)
Alternative flow 4: Overflow on g
...