ETSI GS PDL 028 V1.1.1 (2025-06)

Permisisoned Distributed Ledger (PDL); Specification utilizing PDL to Standardized IoT Service Layer Platform oneM2M

DGS/PDL-0028_Study_SLP_oneM2M

General Information

• Status: Not Published
• Technical Committee: PDL - Permissioned Distributed Ledger
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 09-Jun-2025
• Completion Date: 16-Jun-2025

Standards Content (Sample)

GROUP SPECIFICATION
Permissioned Distributed Ledger (PDL);
Specification utilizing PDL to Standardized IoT Service Layer
Platform oneM2M
2 ETSI GS PDL 028 V1.1.1 (2025-06)

Reference
DGS/PDL-0028_Study_SLP_oneM2M
Keywords
blockchain, IoT, PDL
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 the
ETSI Search & Browse Standards application.
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 on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
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
and/or governmental rule and/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.
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 2025.
All rights reserved.
ETSI
3 ETSI GS PDL 028 V1.1.1 (2025-06)

Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
1.1 In-scope . 7
1.2 Out of scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 10
3.3 Abbreviations . 10
4 IoT with Blockchain . 10
4.1 Introduction . 10
4.2 Use cases of using Blockchain in IoT . 11
4.2.1 Enhancing Transparency and Confidentiality in the Wine Industry through Blockchain and IoT

Technologies . 11
5 Introduction to oneM2M . 12
5.1 Overview of oneM2M . 12
5.2 oneM2M use cases . 13
5.3 oneM2M architecture . 14
6 Introduction to PDL . 15
6.1 Overview of PDL . 15
6.2 PDL use cases . 16
6.3 PDL architecture . 17
7 Utilization of PDL in oneM2M . 19
7.1 Overview . 19
7.2 Two-factor authentication . 19
7.3 Interworking between oneM2M and PDL . 21
8 Possible Proof of Concepts (PoCs) . 22
8.1 Overview and considerations . 22
8.2 System design . 22
8.3 Implementation details . 25
8.3.1 Smart contract . 25
8.3.2 oneM2M-PDL IPE . 26
9 Future Outlook and Recommendations . 27
10 Conclusion . 28
Annex A (informative): Change history . 29
History . 30

ETSI
4 ETSI GS PDL 028 V1.1.1 (2025-06)

List of figures
Figure 1: Using Blockchain and IoT technologies for the Wine Industry .12
Figure 2: oneM2M smart home use case .13
Figure 3: oneM2M function architecture showing logical entities and their reference points .14
Figure 4: PDL Function in Mobile Core Networks .16
Figure 5: Trusted Computing and Data Sharing Scheme based on Blockchain [i.3] .17
Figure 6: PDL Reference Architecture .18
Figure 7: 2FA for biometric gates at an airport using oneM2M and PDL .21
Figure 8: Interworking Proxy for oneM2M and PDL .21
Figure 9: PDL-based oneM2M access authentication system overview .22
Figure 10: Ticket minting sequence diagram .23
Figure 11: Ticket listing and sales sequence diagram to prevent scalping .23
Figure 12: Ticket validation and verification sequence diagram for PDL-Based oneM2M access authentication .24

List of tables
Table 1: oneM2M-PDL IPE API list .26

ETSI
5 ETSI GS PDL 028 V1.1.1 (2025-06)

Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Permissioned
Distributed Ledger (PDL).
Modal verbs terminology
In the present document "shall", "shall not", "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 investigates the integration of Permissioned Distributed Ledger (PDL) technology with the
oneM2M IoT service layer platform to address security and data integrity challenges in centralized IoT systems. It
examines how PDL's decentralized architecture can enhance data security, provide tamper-proof record-keeping, and
implement robust access control mechanisms within IoT environments. The present document provides a detailed proof
of concept demonstrating PDL-based access authentication for IoT systems, focusing on ticket validation and smart gate
control. Through practical implementation examples and architectural analysis, it establishes the feasibility and benefits
of standardized interworking between oneM2M and PDL platforms, offering insights for future development of secure,
scalable IoT infrastructure with Blockchain integration.
ETSI
6 ETSI GS PDL 028 V1.1.1 (2025-06)

Introduction
The present document examines the integration of Permissioned Distributed Ledger (PDL) technology with the
oneM2M IoT service layer platform to address critical challenges in existing IoT infrastructures. Current centralized
IoT platforms face significant vulnerabilities including data tampering, single points of failure, compromised device
management, and inadequate access control mechanisms. These weaknesses become increasingly concerning as IoT
deployments scale and manage more sensitive data across diverse applications.
Traditional oneM2M implementations typically rely on conventional database technologies that, while functional,
cannot guarantee data immutability or provide decentralized verification. Meanwhile, standalone PDL solutions often
lack standardized interfaces for seamless integration with established IoT ecosystems. The convergence of these
technologies presents a compelling solution that leverages the complementary strengths of both platforms.
By integrating PDL's immutable ledger capabilities with oneM2M's comprehensive service layer functions,
organizations can implement IoT systems with enhanced data integrity, transparent yet secure access control, resilience
against network failures, and automated trusted execution through smart contracts. This integration addresses the
fundamental security and reliability challenges that have hindered wider adoption of IoT solutions in mission-critical
applications.
The present document is structured as follows: clause 1 defines the scope, while clauses 2 and 3 provide references and
terminology. Clause 4 discusses Blockchain applications in IoT contexts, followed by introductions to oneM2M
(clause 5) and PDL (clause 6) technologies. Clause 7 explores practical utilization of PDL within oneM2M systems,
while clause 8 presents a proof of concept demonstrating the interworking capabilities. Finally, clauses 9 and 10 offer
recommendations and conclusions for implementing this integrated approach.

ETSI
7 ETSI GS PDL 028 V1.1.1 (2025-06)

1 Scope
1.1 In-scope
The present document covers the utilization of Permissioned Distributed Ledger (PDL) ETSI GS PDL 012 [1]
technology for the oneM2M ETSI TS 118 101 [2] platform and includes a Proof of Concept (PoC) implementation. The
objectives of the present document are to:
• Define the need for standardized interworking between oneM2M and PDL platforms
• Establish use cases for the interworking between oneM2M and PDL platforms
• Identify impacts and requirements for both oneM2M and PDL platforms to enable interworking
• Outline detailed procedures for the interworking between oneM2M and PDL platforms
• Demonstrate the feasibility of PDL-based access control integration with oneM2M
• Present a reference architecture for combining PDL and oneM2M technologies
• Analyse the security benefits of using distributed ledger technology with IoT services
The approach taken in the present document focuses on demonstrating the feasibility of standardized interworking
between IoT (represented by oneM2M) and Blockchain (represented by PDL) platforms.
1.2 Out of scope
The following topics are considered outside the scope of the present document:
• Detailed implementation guidelines for specific PDL platforms beyond the conceptual framework
• Performance benchmarking or comparative analysis of different Blockchain technologies
• Comprehensive security analysis beyond the identified use cases
• Modifications to the core oneM2M standard specifications
• Business models and commercial deployment considerations
• Legacy system migration strategies
• Interoperability with non-PDL Blockchain implementations
• Protocol-level optimizations for IoT-Blockchain communications
• Implementation-specific details beyond what is necessary for the presented PoC
The present document serves as a study of integration possibilities rather than a normative specification for
implementations.
2 References
2.1 Normative 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.
ETSI
8 ETSI GS PDL 028 V1.1.1 (2025-06)

Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
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 necessary for the application of the present document.
[1] ETSI GS PDL 012: "Permissioned Distributed Ledger (PDL); Reference Architecture".
[2] ETSI TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".
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 may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI TR 118 501: "oneM2M Use Case collection".
[i.2] ETSI TR 118 525: "oneM2M; Application Developer Guide (oneM2M version 1.0.0 Release 1)".
[i.3] ETSI WP 48 PDL: "An Introduction of Permissioned Distributed Ledger (PDL)".
[i.4] Ethereum ERC-721: "Non-Fungible Token Standard".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
Application Dedicated Node (ADN): node that contains at least one Application Entity and does not contain a
Common Services Entity
NOTE: See ETSI TS 118 101 [2].
Application Entity (AE): entity in the oneM2M architecture that handles application logic, providing specific M2M
functionality
NOTE: See ETSI TS 118 101 [2].
Blockchain: distributed database technology that maintains a growing list of records (blocks) that are linked using
cryptography
NOTE: Not attributed to a specific external source in the present document.
Common Services Entity (CSE): entity in the oneM2M architecture that delivers essential service functions like
registration, discovery, and data management
NOTE: See ETSI TS 118 101 [2].
Common Services Function (CSF): functionality provided by a CSE, such as device management, registration, or
security
NOTE: See ETSI TS 118 101 [2].
ETSI
9 ETSI GS PDL 028 V1.1.1 (2025-06)

Decentralized Identifiers (DID): unique, self-sovereign identifiers stored in a PDL alongside network or service
access credentials ®
standards (mentioned in clause 6.2).
NOTE: See W3C
ERC-721: standard for Non-Fungible Tokens on the Ethereum Blockchain
NOTE: See Ethereum ERC-721 [i.4].
European Blockchain Services Infrastructure (EBSI): Blockchain infrastructure that supports multiple storage
strategies for digital identifiers
NOTE: European initiative, not attributed to a specific publication in the present document.
Infrastructure Node AE (IN-AE): AE that is registered with the CSE in the Infrastructure Node
Infrastructure Node CSE (IN-CSE): CSE which resides in the Infrastructure Node of the oneM2M architecture
NOTE: See ETSI TS 118 101 [2].
Internet of Things (IoT): network of physical objects embedded with sensors, software, and technologies to connect
and exchange data with other devices over the Internet
NOTE: Not attributed to a specific external source in the present document.
Interworking Proxy application Entity (IPE): entity that connects different platforms, specifically oneM2M and
PDL, facilitating bidirectional message exchange
NOTE: See ETSI TS 118 101 [2].
Machine to Machine (M2M): direct communication between devices using any communications channel
NOTE: Not attributed to a specific external source in the present document.
Middle Node AE (MN-AE): AE that is registered with the CSE in Middle Node
Middle Node CSE (MN-CSE): CSE which resides in the Middle Node of the oneM2M architecture
NOTE: See ETSI TS 118 101 [2].
Network Service Entity (NSE): entity in the oneM2M architecture that supplies fundamental network services to the
CSE
NOTE: See ETSI TS 118 101 [2].
Non-Fungible Token (NFT): unique digital identifier recorded on a Blockchain, used in this context for ticket
authentication
NOTE: See Ethereum ERC-721 [i.4].
oneM2M: global technical standard for interoperability across Machine-to-Machine and IoT platforms
NOTE: See ETSI TS 118 101 [2].
Permissioned Distributed Ledger (PDL): distributed ledger where participants require authorization to join and are
governed by specific authorities
NOTE: See ETSI GS PDL 012 [1].
PDL Function (PDLF): function that connects mobile networks with PDL infrastructures
NOTE: See ETSI GS PDL 012 [1].
smart contract: self-executing contracts with the terms directly written into code, ensuring automatic execution of
agreements on PDLs
NOTE: See ETSI GS PDL 012 [1].
ETSI
10 ETSI GS PDL 028 V1.1.1 (2025-06)

Trusted Execution Environment (TEE): secure area of a processor that ensures data is protected with regards to
confidentiality and integrity
NOTE: Not attributed to a specific external source in the present document.
Two-Factor Authentication (2FA): authentication method requiring users to provide two different types of
verification before gaining access
NOTE: Industry standard security practice, not attributed to a specific external source in the present document.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
2FA Two-Factor Authentication
ADN Application Dedicated Node
AE Application Entity
AE-CSE Application Entity/Common Services Entity
CSE Common Services Entity
CSF Common Services Function
DD Data Demanders
DDM Distributed Data Management
DIS Discovery
DMR Data Management and Repository
DP Data Providers
DT Data Trainers
DW Data Warehouses
EBSI European Blockchain Services Infrastructure
IN-AE Infrastructure Node AE
IN-CSE Infrastructure Node CSE
IoT Internet of Things
IPE Interworking Proxy application Entity
IRPs Interface Reference Points
M2M Machine to Machine
MN-AE Middle Node AE
MN-CSE Middle Node CSE
NFT Non-Fungible Token
NSE Network Service Entity
PDLF PDL Function
PoC Proof of Concept
SEC Security
UE User Equipment
4 IoT with Blockchain
4.1 Introduction
The integration of Blockchain technologies within the IoT service layer platform heralds a transformative era for
various industries, significantly bolstering data integrity, system security, and device control. As centralized IoT
platforms often rely on cloud-centric models, they face inherent risks such as data tampering, unauthorized access, and
compromised device management due to their centralized structure. The decentralized nature of Blockchain, as a
distributed ledger, presents a robust solution to these vulnerabilities.
ETSI
11 ETSI GS PDL 028 V1.1.1 (2025-06)

By incorporating Blockchain into IoT, each data transaction is immutably recorded across multiple nodes, ensuring that
system integrity remains intact even if a single point fails. This resilience, combined with the automation capabilities of
smart contracts, can accelerate transaction processes and enhance overall system performance. The immutable
record-keeping feature of Blockchain makes data falsification and unauthorized modifications impossible, while access
to sensitive information is conditionally granted, ensuring that only verified users can engage with the system.
Thus, the synergy between Blockchain and IoT platforms is not just a step towards mitigating existing security concerns
but a leap towards a more secure, efficient, and trustworthy digital infrastructure for IoT services. In the following
clause 4.2, various use cases that show the synergetic benefits of integrating Blockchain with IoT platforms are
described.
4.2 Use cases of using Blockchain in IoT
4.2.1 Enhancing Transparency and Confidentiality in the Wine Industry
through Blockchain and IoT Technologies
In the wine industry, the integration of Blockchain with IoT technologies presents a compelling use case for ensuring
the transparency and confidentiality of data from vineyard to consumer. IoT devices, managed by a IoT service layer
platform, collect crucial quality metrics from the winery, such as soil condition and grape maturity, and monitor
environmental conditions within the wine cellar to maintain the wine's integrity. These IoT devices also track the wine's
journey, including any flights it may take, ensuring that the conditions remain optimal for wine preservation.
The data collected at each stage is securely stored on a private Blockchain network, guaranteeing the integrity of the
information due to Blockchain's immutable nature. This data management approach allows wine applications to utilize
general IoT services such as smart city data and access Blockchain-stored data, ensuring that the provenance and
handling of the wine are transparent and meet regulatory compliance for data privacy.
The high-level use case depicted in Figure 1 herewith shows an IoT service layer platform with Blockchain employed
for global service continuity, connecting private Blockchain networks from different regions through a public
Blockchain network. This ensures a seamless and secure exchange of data across borders, where each bottle's
journey - from the winery data collection, through storage in the wine cellar, the flight to international locations, and
finally to the retail shop in Korea - is documented and verifiable.
By leveraging the IoT service layer platform, the wine industry can manage data effectively while utilizing Blockchain
technology to ensure the data's integrity. This integration is pivotal for enhancing trust across the wine supply chain,
providing stakeholders with a reliable record of the wine's quality and handling, and ultimately enhancing consumer
confidence in the products they purchase.
The below shows several features to support this use case:
1) Data Collection through IoT: IoT sensors are deployed across the winery to collect a wide range of data. These
sensors monitor the quality of the grapes, environmental conditions in the wine cellar, and the transportation of
wine bottles to various outlets. The IoT service layer platform aggregates and manages this data, ensuring it is
available for real-time monitoring and decision-making processes.
2) Data Integration with Blockchain: Selected data that require high integrity, such as quality certifications, origin
of grapes, and cellar conditions, are recorded onto a Blockchain network. This could include timestamped
entries for each batch of wine produced, ensuring a tamper-proof ledger. The Blockchain network provides an
immutable record, guaranteeing the integrity of the wine-related data and enabling traceability throughout the
wine supply chain.
3) Transparency and Confidentiality: Stakeholders in the wine value chain, including regulators, distributors, and
consumers, can access the IoT platform to receive verified information about the wine's quality and journey.
While the IoT platform provides general service data, the Blockchain network ensures that the data's integrity
is maintained, and sensitive information remains confidential due to its encryption and permissioned access
features.
4) Application and User Interaction: Wine applications can utilize the data managed by the IoT service layer
platform for various services such as quality assurance, inventory management, and customer engagement.
Customers can scan QR codes on wine bottles to view the Blockchain-stored data, such as harvest date, cellar
conditions, and delivery details, thereby gaining confidence in the wine's authenticity and quality.
ETSI
12 ETSI GS PDL 028 V1.1.1 (2025-06)

Benefits of this use case include:
• Integrity: Blockchain's immutable ledger means that once data about a wine batch is recorded, it cannot be
altered, providing an unbreakable chain of custody.
• Transparency: Every stakeholder has access to up-to-date and accurate information about the wine
production and distribution process.
• Confidentiality: Sensitive data is protected through Blockchain's secure and encrypted mechanisms, ensuring
that only authorized parties can access it.
• Quality Assurance: The integration of IoT and Blockchain allows for the constant monitoring of production
and storage conditions, directly correlating to the quality of the wine.
This use case demonstrates how Blockchain and IoT technologies can revolutionize the wine industry by providing a
reliable and secure way to assure the quality and origin of each bottle, thereby enhancing consumer trust and regulatory
compliance.
Blockchain
Public Blockchain
Network
Secure
data
Secure
Private data
Private
Blockchain
Blockchain
IoT Platform
IoT Platform
Network
(EU side) (KR side) Network
A user’s A user’s
Secure
Secure Secure
data
data data
Secure
data
Wine shop
Winery Wine celler Delivery
Application Application Application Application
Wine shop in
Winery data Wine cellar Wine flight
Korea
Figure 1: Using Blockchain and IoT technologies for the Wine Industry
5 Introduction to oneM2M
5.1 Overview of oneM2M
Founded in 2012, oneM2M is a collaborative project uniting eight prominent ICT standards development bodies
globally, including ARIB and TTC from Japan, ATIS and TIA from the United States, CCSA from China, ETSI from
Europe, TSDSI from India, and TTA from Korea. Its mission is to establish a universal technical standard that
facilitates interoperability across Machine-to-Machine (M2M) and IoT platforms, encompassing everything from
system architecture and API specifications to security protocols and registration processes. Through global consensus,
oneM2M devises end-to-end M2M specifications, utilizing shared use cases and foundational architectural principles
that span a multitude of M2M applications.
Acting much like a decentralized operating system for the IoT, oneM2M features a middleware service layer comprised
of an array of Common Service Functions (CSFs). This middleware bridges the gap between applications and the
underlying connectivity layers, with CSFs accessible via RESTful APIs for both applications and IoT devices. This
service layer can be integrated within field devices, sensors, gateways, and backend cloud services, fostering collective
intelligence within dispersed IoT ecosystems.
ETSI
13 ETSI GS PDL 028 V1.1.1 (2025-06)

The oneM2M Service Layer Is essentially a software stratum Interfacing IoT applications with the hardware necessary
for processing and connectivity, usually operating over IP, while also accommodating non-IP data transmission through
interworking proxies.
This Service Layer supplies a suite of common service functions essential for IoT applications, with oneM2M's
standards currently detailing fourteen such functions. These functions provide a modular toolkit for developers, who can
start with essential services like device management, registration, and security, and gradually integrate more
sophisticated capabilities for advanced applications, such as those requiring semantic interoperability and location-
based services.
5.2 oneM2M use cases
OneM2M has been at the forefront of crafting use cases across a myriad of industry sectors, ranging from domestic
environments like smart homes to industrial settings like smart factories. The use cases formulated are meticulously
documented in ETSI TR 118 501 [i.1]. This particular clause draws upon a home lighting scenario where a user can
remotely manipulate their home's lighting using their smartphone, all enabled through the oneM2M framework. The use
case is mainly captured from ETSI TR 118 525 [i.2] that provides a use case for guiding application developers to
develop applications using functionalities provided by a oneM2M service platform.

NOTE: It shows an overview of remote lights control use case (left) and oneM2M functional architecture of remote
lights control use case (right).

Figure 2: oneM2M smart home use case
Figure 2 (left) provides a schematic of the home lighting use case, highlighting the primary elements involved:
1) The lighting fixtures are installed within a residence and are connected to a home gateway.
2) This gateway facilitates communication with a cloud-based service platform, which in turn allows for the
lighting to be remotely operated via a smartphone.
3) The cloud platform is equipped with a suite of functionalities designed to streamline the control of home
lighting through the smartphone. These functionalities encompass various services such as registration,
discovery, data management, and group management, along with subscription and notification mechanisms.
4) The smartphone is equipped with an application that provides remote control over the home lighting system.
This app enables users to:
• Discover lighting fixtures within the home.
• Issue commands to toggle the lights on or off.
• Check the current state of the lights.
Figure 2 (right) delineates the alignment of the use case components with the corresponding entities within the oneM2M
architecture.
ETSI
14 ETSI GS PDL 028 V1.1.1 (2025-06)

The oneM2M architectural framework identifies two fundamental entity types: the Application Entity (AE) and the
Common Services Entity (CSE). In our home lighting scenario, both the lighting fixtures and the smartphone are
equipped with their respective AEs. A cloud-based Infrastructure Node CSE (IN-CSE) is maintained by the oneM2M
Service Provider, while a Middle Node CSE (MN-CSE) is integrated within the Home Gateway. Interactions between
an AE and a CSE are facilitated by the oneM2M-defined Mca reference point. Conversely, interactions between
different CSEs utilize the Mcc reference point. In our scenario, the Light AEs communicate with the home gateway's
MN-CSE, and the Smartphone AE communicates with the IN-CSE, both via the Mca reference point. Communication
between the home gateway's MN-CSE and the IN-CSE occurs over the Mcc reference point.
To encapsulate, the applications in this use case are categorized as follows:
1) ADN-AE1: An embedded application within Light#1, capable of controlling the fixture and interacting with
the MN-CSE through the Mca reference point.
2) ADN-AE2: A similar embedded application within Light#2, also capable of controlling the fixture and
interfacing with the MN-CSE through the Mca reference point.
3) IN-AE: An application within the smartphone that directly interfaces with the oneM2M service platform's
IN-CSE via the Mcc reference point, enabling remote control over Light#1 and Light#2.
4) MN-AE: An application within the home gateway that communicates with the MN-CSE through the Mca
reference point, facilitating the overall connectivity and control within the home lighting system.
5.3 oneM2M architecture
The oneM2M reference architecture ETSI TS 118 101 [2], as illustrated in Figure 3, introduces multiple logical
oneM2M entities such as the Application Entity (AE), Common Services Entity (CSE), and Network Service
Entity (NSE), each fulfilling distinct roles across various layers. The AE handles the application logic, similar to how a
smart home application operates on M2M services. The CSE delivers essential service functions like registration,
discovery, and data management, accessible to both AEs and other CSEs. On the other hand, the NSE supplies
fundamental network services to the CSE, including device activation, location services, and device management. These
entities, located on devices ranging from mobiles to gateways or servers, communicate through designated oneM2M
reference points, namely Mca for AE-CSE interactions, Mcc for CSE-CSE communications, and Mcn for CSE-NSE
interactions. The Mcc reference point also facilitates communication between two CSEs within the Infrastructure
Domain.
Figure 3: oneM2M function architecture showing logical entities and their reference points
oneM2M adopts a resource-oriented data model representing services as resources, with the CSEBase being the root for
all resources within a CSE. This root can have various child resources like AEs, Containers, and accessControlPolicies.
Similarly, AEs can host multiple child resources. oneM2M standards, which are widely utilized and evaluated across
academia and industry, have been established across several releases.
ETSI
15 ETSI GS PDL 028 V1.1.1 (2025-06)

Common Service Functions (CSFs) identified by oneM2M cater to a broad range of IoT domains, functioning like tools
in a toolbox to address myriad IoT challenges. For instance, just as a screwdriver is versatile across automotive and
aviation industries, oneM2M CSFs like device management or security apply across diverse IoT scenarios. In the initial
phase of standardization, oneM2M members scrutinized numerous IoT use cases, deducing common requirements that
led to the creation of CSFs. Moreover, oneM2M has standardized the execution of these functions by defining
consistent APIs for access.
The non-domain-specific nature of CSFs allows for flexible application across various sectors, much like how
general-purpose services of an operating system facilitate application functions such as file I/O. In this vein, oneM2M's
Service Layer offers akin services to a multitude of IoT applications. CSFs are housed within a CSE, serving AEs via
Mca and other CSEs through Mcc. The subsequent clause outlines oneM2M CSFs potentially intersecting with
Blockchain technology:
• Data Management: The Data Management and Repository (DMR) CSF is tasked with data storage and
transformation, supporting data aggregation, conversion, and storage for advanced analytics and semantic
processing. This includes managing application data, user data, location, device details, and access
permissions, laying the groundwork for Big Data.
• Discovery: The Discovery (DIS) CSF locates information about applications and services based on resource
attributes, with the scope and outcome of discovery requests being contingent on filter criteria and access
control policies.
• Security: The Security (SEC) CSF handles sensitive data protection, security administration, association
establishment, and identity management, including access control measures that regulate operations on
resources according to established policies and roles. It also ensures the protection of credentials and the
implementation of security algorithms, while providing pseudonyms to safeguard entity identities.
6 Introduction to PDL
6.1 Overview of PDL
The ETSI Industry Specification Group (ISG) on Permissioned Distributed Ledger (PDL), established in 2018, focuses
on laying down the groundwork for the operation of permissioned distributed ledgers. The ISG's mission is to create a
standardized and open ecosystem of industrial solutions that can be adopted across various sectors, enhancing the
application of these technologies and bolstering trust in information technologies underpinned by global, open
telecommunications networks.
PDL is distinct from permissionless systems in that participants are not allowed to freely join or exit. Instead, they
require authorization and are governed by specific authorities, which may be private entities or consortia. Governance
and the associated access control policies are thus crucial in managing PDL systems.
PDLs offer selective visibility of information to the public, addressing privacy concerns more effectively than
permissionless systems. They are also capable of employing more efficient consensus protocols, like proof-of-stake, to
facilitate higher transaction speeds and improved energy efficiency. These features make PDLs an attractive choice for
entities seeking the advantages of distributed ledger technologies, including decentralization and enhanced security,
without the openness of permissionless systems.
Smart contracts on PDLs ensure automatic execution of agreements,
...