Enhancing IoT Common Service Functions with Blockchain: From Analysis to Standards-Based Prototype Implementation

Abstract

The proliferation of Internet of Things (IoT) applications in safety-critical domains, such as healthcare, smart transportation, and industrial automation, demands robust solutions for data integrity, traceability, and security that surpass the capabilities of centralized databases. This paper analyzes how blockchain technology can be integrated with core IoT service functions—including data management, security, device management, group coordination, and automated billing—to enhance immutability, trust, and operational efficiency. Our analysis identifies practical use cases such as consensus-driven tamper-proof storage, role-based access control, firmware integrity verification, and automated micropayments. These use cases showcase blockchain’s potential beyond traditional data storage. Building on this, we propose a novel framework that integrates a permissioned distributed ledger with a standardized IoT service layer platform through a Blockchain Interworking Proxy Entity (BlockIPE). This proxy dynamically maps IoT service functions to smart contracts, enabling flexible data routing to conventional databases or blockchains based on the application requirements. We implement a Dockerized prototype that integrates a C-based oneM2M platform with an Ethereum-compatible permissioned ledger (implemented using Hyperledger Besu) via BlockIPE, incorporating security features such as role-based access control. For performance evaluation, we use Ganache to isolate proxy-level overhead and scalability. At the proxy level, the blockchain-integrated path achieves processing latencies (≈86 ms) comparable to, and slightly faster than, the traditional database path. Although the end-to-end latency is inherently governed by on-chain confirmation (≈0.586–1.086 s), the scalability remains high (up to 100,000 TPS). This validates that the architecture secures IoT ecosystems with manageable operational overhead.

1. Introduction

The Internet of Things (IoT) is a revolutionary technology that enables interconnected devices to collect, exchange, and process data in real time, driving advancements in safety-critical domains such as healthcare, smart transportation, and industrial automation. However, traditional IoT architectures that rely on centralized relational database management systems (RDBMS) have significant vulnerabilities, including data tampering, single points of failure, and unauthorized modifications. For instance, falsified health data from wearable devices could lead to misdiagnoses, whereas altered sensor data from autonomous vehicles might cause accidents. These challenges highlight the urgent need for enhanced data integrity, traceability, and security in IoT systems.

Blockchain technology offers a promising solution by using distributed ledgers that ensure immutability through cryptographic hashing and consensus mechanisms. Permissioned distributed ledgers (PDLs), in particular, restrict access to authorized entities and enhance privacy and efficiency compared to public blockchains, which suffer from high energy consumption and low throughput. By enabling trustless interactions and eliminating intermediaries, blockchain reduces costs and strengthens security across IoT ecosystems. However, the broad applicability of blockchain—from data storage and log management to device authentication and lifecycle tracking—requires a carefully structured approach to determine how and where it can be effectively integrated into IoT platforms.

Despite numerous studies on IoT-blockchain integration, prior research has largely adopted fragmented, ad hoc approaches, focusing on specific aspects such as access control [1,2,3], secure transactions [4], and domain-specific applications such as logistics [5]. These efforts often lack a comprehensive analysis of blockchain’s potential across the diverse functionalities of IoT platforms, limiting their scalability and interoperability. A critical gap exists in providing a clear mapping of blockchain capabilities to standardized IoT functions, which is essential for developing interoperable trust-enhanced systems that can be widely adopted across industries.

Among the global IoT standards, oneM2M [6] stands out as a leading international framework and is widely adopted in the industry. It defines a comprehensive set of Common Service Functions (CSFs) that abstract essential IoT capabilities, including data management, security, device management, discovery, group coordination, location tracking, subscription and notification, application management, and service charging [7]. These CSFs, supported by protocols such as 3GPP, Modbus, and Lightweight M2M (LWM2M), ensure interoperability across heterogeneous IoT ecosystems [8]. Leveraging oneM2M’s structured framework, this paper analyzes how blockchain technologies can be applied to each CSF by mapping blockchain functionalities to oneM2M CSFs. It also synthesizes representative prior work across the full spectrum of IoT functionalities—from tamper-proof data storage and role-based access control to device authentication and automated billing.

Our analysis derives practical use cases demonstrating blockchain’s ability to enhance trust, immutability, and automation. For example, blockchain ensures tamper-resistant data storage for healthcare monitoring, enforces secure access policies in smart cities, and automates micropayments in energy systems. At the same time, IoT and IIoT platforms increasingly rely on AI/ML-driven analytics for anomaly detection, predictive maintenance, and closed-loop automation. However, these approaches presuppose the integrity and provenance of the underlying data streams, which our blockchain-enhanced oneM2M CSFs are designed to strengthen. Building on this analysis, we propose a blockchain-enabled IoT framework that integrates PDL with oneM2M by introducing BlockIPE—a novel interworking proxy that maps CSFs to blockchain smart contracts. This framework enables dynamic data routing to either conventional databases or permissioned blockchains, preserving compatibility with existing oneM2M implementations, while demonstrating the feasibility of the integration patterns identified in our analysis.

The main contributions of this study are as follows:

An analysis that maps blockchain functionalities to oneM2M CSFs, synthesizing representative prior work and identifying use cases that enhance trust, security, and automation across diverse IoT scenarios. Compared with many prior studies that focus on a single function or a specific vertical, this provides a CSF-wide, standards-grounded view.

A standards-compliant IoT-blockchain framework featuring BlockIPE for transparent interworking, supporting selective data handling for traceability-critical applications. In contrast to fragmented ad hoc integrations, BlockIPE preserves the standard oneM2M request flow and enables optional on-chain anchoring (e.g., hashes/events) for auditability.

A Dockerized prototype (tinyIoT + BlockIPE + Ethereum-compatible smart contracts) targeting a permissioned ledger deployment (implemented with Hyperledger Besu), with performance evaluation on Ganache to isolate proxy-level overhead and scalability. This provides implementation evidence in a standards-based setting, complementing prior work that is often evaluated outside a CSF-aligned interworking architecture.

This paper presents the challenges addressed through oneM2M-PDL integration in Section 3. However, unresolved challenges are beyond the scope of this study, and are briefly presented in Section 6.

The remainder of this paper is organized as follows. Section 2 provides background information on IoT standards and blockchain technologies. Section 3 explores how blockchain can be utilized for each CSF in oneM2M. Section 4 provides an overview of the proposed IoT architecture that utilizes blockchain features as a common function. The prototype implementation is discussed in Section 5. The paper finishes with the conclusions and future works in Section 6.

2. IoT Service Layer Standards and Blockchain Fundamentals

In this section, we introduce oneM2M as a leading standard for IoT service layer platforms, with a detailed overview of its CSFs. We also review the fundamental concepts of blockchain technology and PDL.

2.1. IoT Service Layer Standards and oneM2M

The IoT service layer is a standardized software middleware positioned between communication networks and IoT applications. It provides a common set of functions to support the development and management of diverse IoT services across multiple vertical domains. The oneM2M global standard, established in 2012 through the collaboration of major Standards Development Organizations (SDOs) and industry alliances [9], defines a comprehensive, unified service layer framework specifically designed to mitigate IoT fragmentation. By specifying a robust set of CSFs, oneM2M ensures interoperability across heterogeneous devices, networks, and application protocols—such as those from 3GPP, Modbus, and Lightweight M2M (LWM2M)—thereby enabling the seamless integration of disparate IoT systems and vendors.

The logical rationale for selecting oneM2M’s CSFs as the foundational framework for analyzing blockchain’s applicability to IoT is twofold. First, the CSFs are not implementation-specific technologies but rather abstract, logically defined capabilities that represent the core functional requirements of a generic IoT platform. Second, since its inception, oneM2M has systematically refined these functions over the past decade, making its CSF set a mature and comprehensive articulation of the common features IoT platforms must provide. Consequently, this corpus of standardized functions offers a natural and logically grounded basis for an analysis that maps blockchain functionalities to oneM2M CSFs and identifies use cases that enhance trust, security, and automation across modern IoT ecosystems.

As illustrated in Figure 1, the oneM2M architecture encapsulates these essential capabilities into distinct, yet interoperable, CSFs. These CSFs abstract a wide range of critical IoT platform functionalities that support applications in domains like healthcare, smart cities, and industrial automation. The key CSFs include, but are not limited to:

Data Management and Semantics: Manages the storage, retrieval, and semantic annotation of IoT data, ensuring efficient processing and meaningful interpretation across devices.

Security: Provides authentication, authorization, and encryption mechanisms, such as access control policies (ACPs), to safeguard data and interactions.

Device Management and Registration: Handles device onboarding, configuration, and lifecycle tracking, ensuring reliable operation and updates.

Discovery: Enables the identification of devices and services, supporting dynamic interactions within IoT ecosystems.

Group Management: Facilitates coordinated operations among device groups, such as synchronized control in smart homes or industrial systems.

Location Services: Supports geospatial data management and location-based triggers for applications like logistics and smart cities.

Subscription and Notification: Manages event-driven subscriptions and real-time alerts for timely responses to IoT conditions.

Application and Service Management: Oversees the deployment, execution, and monitoring of IoT applications and services.

Service Charging and Accounting: Tracks resource usage and enables billing, supporting monetization of IoT services.

By providing this structured framework of logically defined and standardized functions, oneM2M directly addresses critical IoT challenges such as data silos, security heterogeneity, and protocol incompatibility. This makes its CSF model an ideal reference point for a methodical assessment of blockchain’s potential to enhance specific IoT capabilities, from decentralized trust to immutable audit trails.

2.2. Blockchain and Permissioned Distributed Ledger

Blockchain was introduced in 2008 and was initially designed to solve problems in the financial sector by allowing users to conduct transactions without intermediaries. Blockchain uses special rules to store or update data in a chain [10]. Blocks are linked by hash values, typically using functions such as SHA-256, making reverse engineering difficult. Transactions include the sender, receiver, data or assets, and timestamps, which are aggregated into blocks that reference the hash of the previous block, ensuring immutability through cryptographic linking and digital signatures. All the changes are verified using a consensus algorithm.

This technology has applications beyond finance, such as in automotive, digital identity, healthcare, and energy markets. Integrating blockchain with IoT is promising because it eliminates intermediaries, reduces costs, and enhances data integrity, traceability, and security for large-scale distributed devices. Blockchain enables trust-based interactions and data verification in IoT systems; however, this integration is recent and requires further empirical research on network structures and applications.

A PDL leverages the distributed ledger technology (DLT) for reliable and secure data management, standardized by the ETSI Industry Specification Group on PDL (ISG PDL). Unlike public blockchains, PDL restricts access to approved participants, enhancing control and security. The key features are as follows.

Access Control: Only authorized entities join, ensuring transparency and manageability.

High Security: Verified identities reinforce system integrity.

Efficient Consensus Mechanisms: Limited nodes enable rapid processing and energy efficiency.

PDL uses peer-to-peer networking, hashing, and consensus for data immutability, with advantages in privacy and security. Smart contracts enable automatic rule execution for secure transactions without intermediaries. The PDL architecture comprises three layers: Application, Platform Service, and DLT (Figure 2). This design promotes interoperability and flexibility. The Application Layer includes applications such as data sharing or distributed AI, interacting via the Platform Service Layer, with an Abstraction Layer for data-model compatibility. The Platform Service Layer provides atomic (stand-alone) and composite (combined) services for governance, identity, privacy, and security. The PDL Abstraction Layer ensures cross-compatibility among the ledger types. The DLT Layer is the core ledger environment, which uses governance models such as the Proof of Authority (PoA) for trusted participants. It securely processes transactions and synchronizes ledgers. PDL supports privacy, security, and interoperability across domains, thereby addressing complex data management challenges.

2.3. Advantages of the Proposed Method Compared to Related Works

Prior research on IoT-blockchain integration has often been fragmented, focusing on specific aspects such as access control or secure transactions, or limited to domain-specific applications such as logistics. These efforts typically lack comprehensive coverage of IoT platform functionalities and suffer from limited scalability and interoperability owing to ad hoc approaches.

By contrast, this study provides a multifaceted analysis of how blockchain technologies can enhance diverse IoT CSFs, including data management, security, device management, group coordination, and automated billing. By mapping of blockchain capabilities to standardized oneM2M CSFs, we derive practical use cases that improve trust, immutability, and automation across safety-critical domains. A key distinction is our reliance on international standards: oneM2M for IoT service layer platforms and PDL standards from the ETSI ISG PDL, avoiding proprietary solutions. This ensures interoperability and widespread adoption. Furthermore, we conducted a feasibility study using a standard-based prototype implementation to validate the practicality of the integration.

3. Analysis of Blockchain Applications for oneM2M Common Service Functions

To fully leverage blockchain technologies in IoT ecosystems, a clear understanding of their applicability to standardized IoT functionalities is essential. Prior research on IoT blockchain integration has often been fragmented, focusing on specific issues like access control [11,12] or domain-specific applications such as logistics [13], thus limiting a comprehensive view of blockchain’s potential across IoT platforms. As described in the previous section, the oneM2M standard, with its well-defined CSFs, provides a structured framework to address this gap. These CSFs—encompassing data management, security, device management, discovery, group management, location, subscription and notification, application and service management, service charging and accounting, and network service exposure—offer a standardized set of capabilities for interoperable IoT systems. This section analyses how blockchain functionalities can be mapped to each oneM2M CSF, based on representative prior work on IoT-blockchain integration. We synthesized these studies to identify typical use cases and integration challenges, demonstrating blockchain’s utility in enhancing trust, security, and automation across IoT domains.

Figure 3 illustrates the integration of oneM2M CSFs with PDL through smart contracts, leveraging blockchain features such as consensus algorithms, Decentralized Identifiers (DIDs), and Decentralized Autonomous Organizations (DAOs) for secure and automated IoT operations. Table 1 summarizes these mappings, detailing how blockchain enhances each CSF. The following subsections analyze each CSF, supported by the literature and practical use cases, and discuss integration challenges such as scalability and computational overhead.

3.1. Data Management & Semantics

The oneM2M data management and semantics CSF handles storage, retrieval, and semantic annotation of IoT data. Blockchain enhances these functions through immutable, distributed storage and verifiable data structures.

Consensus-Driven Data Storage

Blockchain’s consensus mechanisms, such as PoA or Practical Byzantine Fault Tolerance (PBFT), validate data before storage, ensuring integrity and preventing unauthorized modifications [39]. This is critical for IoT applications requiring high reliability, such as healthcare monitoring, where falsified data could lead to misdiagnoses [14].

Distributed Ledger Storage By storing data across multiple nodes, blockchain eliminates single points of failure and enhances data availability. Tampering is deterred, as altering data requires compromising a majority of nodes, a principle demonstrated by Bitcoin’s resistance to 51% attacks [39]. Studies like [40] highlight blockchain’s role in ensuring data redundancy in IoT networks.

Semantic Integrity Blockchain records ontology changes immutably, ensuring consistent semantic annotations across IoT devices. This supports interoperable data interpretation, critical for cross-domain applications [14]. For instance, smart contracts can enforce semantic consistency in supply chain data.

Use Case: Blockchain facilitates trusted data management across diverse domains. In agri-food supply chains and smart agriculture, systems immutably record IoT sensor data to ensure traceability and food safety from farm to consumer [14,41]. Similarly, in industrial IoT, blockchain creates secure, auditable logs for manufacturing data, ensuring provenance and reliable sharing [42]. Furthermore, in the energy sector, smart meters utilize distributed ledgers to enable secure, decentralized peer-to-peer energy trading while protecting against fraud [43].

Challenge: The primary challenge in integrating blockchain with IoT data management is the inherent conflict between high-frequency IoT data generation and the storage-intensive, slower consensus processes of blockchain. Simply recording all raw sensor data on-chain is impractical. Therefore, hybrid architectures are necessary. Only critical data (e.g., integrity proofs, access events, or aggregated state hashes) are stored on the blockchain. Bulk data is stored in off-chain solutions like the InterPlanetary File System (IPFS) or traditional databases, with their hashes anchored on-chain for verification [40].

Resolution: This paper applies a hybrid pipeline that keeps raw data streams off-chain and stores on-chain only integrity hashes, access/policy events, or transactions bundled in batches, thereby mitigating storage and consensus overhead.

3.2. Security

The oneM2M Security CSF provides foundational mechanisms for authentication, authorization, and encryption to safeguard IoT systems. Blockchain technology enhances these security functions by introducing decentralized trust, immutability, and cryptographically enforced policies. By leveraging its inherent properties, blockchain can address critical IoT security challenges such as single points of failure, opaque access control, and data integrity vulnerabilities.

3.2.1. Decentralized and Immutable Access Control Policies

Traditional access control systems often rely on a central authority, creating a single point of failure and a target for attacks. Blockchain mitigates this risk by enabling Access Control Policies (ACPs) to be stored and managed on a distributed ledger. This approach renders the policies immutable and tamper-resistant, as any modification requires network consensus. The decentralized nature ensures that no single entity can unilaterally alter permissions, providing a robust foundation for secure access control in dynamic IoT environments [11]. Furthermore, smart contracts can automate the enforcement of these policies, enabling fine-grained, context-aware access decisions without intermediary trust.

Blockchain also supports group access control, allowing data access to be restricted to specific groups. This feature enhances data confidentiality while enabling secure data sharing between authorized groups. Smart contracts enable the implementation of role-based access, granting different groups different levels of access [12]. This ensures that only authorized participants can view or modify sensitive data, maintaining segregation of duties.

3.2.2. RBAC via Smart Contracts

Blockchain facilitates the precise implementation of RBAC through smart contracts. These self-executing contracts can assign roles and permissions to users and devices, with all changes being recorded immutably on the ledger. This creates a fully auditable and traceable access history, ensuring accountability. For instance, in a smart building, a smart contract could automatically grant temporary access credentials to a maintenance contractor, which are automatically revoked upon job completion. This system ensures that access control remains consistent, verifiable, and enforceable across the entire network [44]. Such immutable, ledger-backed policies and the resulting audit trails form a crucial foundation for AI/ML-based security mechanisms—such as anomaly detection or adaptive access control—because they ensure that learning and decision-making processes are grounded in trustworthy, non-tamperable records. In particular, advanced deep learning-based cyber threat detection for IoT networks, exemplified by the hybrid autoencoder-GRU model optimized with the Honey Badger algorithm in [45], relies on high-integrity logs and traffic traces that a blockchain trust layer can securely provide.

3.2.3. Encryption and Data Privacy

Although blockchain ledgers are typically transparent, the confidentiality of sensitive IoT data can be maintained through encryption. Data can be encrypted before being stored on-chain or, more commonly, its cryptographic hash is stored on-chain, whereas bulk data reside in off-chain storage. This model preserves data privacy while leveraging the blockchain to provide immutable proof of integrity. Any tampering with the off-chain data results in a hash mismatch, immediately revealing the breach. This hybrid approach is essential for balancing the transparency and immutability of blockchain with the privacy requirements of IoT applications.

Use Case: The practical application of blockchain for enhancing IoT security is evidenced in several research initiatives. For example, Novo designed a scalable access control system for IoT where blockchain-based smart contracts manage the distribution of access keys to devices, successfully overcoming the limitations of a centralized manager in a wireless sensor network scenario [46]. In a more complex industrial setting, Di Francesco Maesa et al. demonstrated the use of blockchain to automatically manage access rights in an IoT ecosystem, providing a decentralized and auditable access control mechanism that dynamically adapts to changes in the system [47]. These implementations highlight blockchain’s capacity to create more resilient and transparent security architectures for IoT.

Challenge: A significant challenge in deploying blockchain for IoT security is the performance overhead associated with consensus mechanisms and smart contract execution, which can introduce latency incompatible with real-time access control requirements. Optimizing consensus algorithms like PBFT for resource-constrained environments or employing hybrid layered architectures are necessary to achieve a viable balance between security assurance and system performance [15].

Resolution: To address the security/privacy/access-control concerns raised in the literature, we clarify the intended on-chain enforcement pattern and threat assumptions rather than claiming a full formal proof. Specifically, the proposed architecture supports a two-layer access-control design. First, a permissioned membership/allowlist at the PDL boundary to reject non-authorized nodes/accounts. Second, smart-contract RBAC/ACP checks that authorize the caller before any policy update or state transition occurs. For privacy, deployments may choose a hybrid path in which only integrity anchors and policy/audit events are recorded on the chain, whereas sensitive payloads are kept off-chain (optionally encrypted), or payloads are selectively stored on-chain using the oneM2M BC attribute (see Section 4.5).

3.3. Device Management & Registration

In IoT platforms, device management and registration are often treated as separate CSFs. However, from the blockchain perspective, these two functions share similar goals and can be integrated into a single cohesive process. Blockchain provides a decentralized, immutable solution that ensures that device registration and management are handled securely, along with firmware updates and lifecycle tracking.

Device Registration and Authentication: Blockchain ensures that each IoT device is securely registered with a unique identifier (e.g., MAC address, digital certificate), stored on the blockchain. This creates a tamper-resistant and verifiable record of device identities, ensuring that only trusted devices can join the network.

Firmware Update Integrity: Blockchain ensures the integrity of firmware updates. By storing the hash of the firmware on the blockchain, devices can verify that the updates have not been altered. Furthermore, the blockchain enables devices to securely download firmware and configurations directly from the blockchain [17].

Device Lifecycle Management: Blockchain tracks the entire lifecycle of IoT devices, from manufacturing to deployment, maintenance, and retirement. Every event in the lifecycle is recorded on the blockchain, creating a transparent and auditable history.

Use Case: Blockchain implementation enhances device management across diverse sectors. The filament blocklet chip secures device authentication and firmware verification, thereby ensuring regulatory compliance in the medical IoT [17]. Dorri et al. proposed a lightweight distributed ledger to manage access rights in smart homes without a central authority [48]. Furthermore, for industrial environments, Samaniego and Deters demonstrated blockchain as an immutable storage layer for transparently tracking the lifecycle and state changes in virtualized IoT resources [49].

Challenge: A primary challenge in applying blockchain to device management is the scalability limitation posed by the high volume of frequent, small transactions generated by lifecycle events and status updates from millions of devices. This can strain the blockchain throughput and storage. Potential solutions include employing efficient transaction-batching techniques, utilizing hybrid on-chain/off-chain architectures in which only critical attestations are recorded on the blockchain, and leveraging lightweight consensus algorithms designed for IoT resource constraints. The high-frequency lifecycle updates the strain-blockchain throughput, requiring efficient transaction batching or hybrid storage solutions [50].

Resolution: This study alleviates the throughput and storage constraints by batching high-frequency lifecycle updates into single transactions and adopting a hybrid on/off-chain design that anchors only critical on-chain attestations.

3.4. Discovery

The oneM2M Discovery CSF enables dynamic identification and location of devices, services, and data within an IoT ecosystem. Traditional discovery mechanisms often rely on centralized directories, which can become bottlenecks and single points of failure. Blockchain technology, particularly when integrated with smart contracts and advanced cryptographic techniques, offers a decentralized and trustworthy alternative to discovery processes. This enhances the security, privacy, and reliability of resource location in large-scale, multi-stakeholder IoT environments.

Decentralized and Tamper-Proof Resource Directories: Blockchain acts as a decentralized, immutable registry for IoT resources. By recording device capabilities and services on a distributed ledger, it creates a tamper-proof catalog immune to malicious alteration. Smart contracts further automate registration and deregistration, ensuring the directory remains current without a central authority.

Confidential and Privacy-Preserving Discovery: To balance findability with privacy, blockchain utilizes cryptographic techniques such as zero-knowledge proofs. These allow smart contracts to validate resource availability and metadata without revealing sensitive underlying data, enabling entities to prove capabilities while preserving confidentiality [18].

Role-Based Access Control for Discovery: Smart contracts can enforce RBAC on the discovery process, ensuring only authorized roles can query specific resources. For instance, maintenance personnel might access diagnostic sensors while tenants are restricted to user services. This granular control prevents unauthorized network reconnaissance and secures the network topology.

Use Case: Research has demonstrated various approaches to blockchain-based discovery in IoT. Novo addressed the scalability challenges in IoT access management using a blockchain, which inherently requires a robust discovery mechanism to locate and verify devices within a network [46]. In a more focused study, Dorri et al. proposed a lightweight blockchain framework for smart homes that included a secure and private method for device discovery, ensuring that only authorized users could locate and interact with specific IoT devices while maintaining their privacy [48]. These implementations demonstrate that blockchain can create more secure, private, and decentralized discovery mechanisms than traditional centralized approaches. In the industrial IoT, blockchain ensures the confidential discovery of factory sensors, restricting access to authorized operators, as implemented in [18].

Challenge: The primary challenge in employing blockchain for discovery is the computational overhead associated with performing cryptographic operations and executing smart contracts for every query, which can affect scalability and response latency. The storage cost of maintaining the resource metadata on-chain for many IoT devices is also nontrivial. Utilizing lightweight cryptographic algorithms, such as Elliptic Curve Cryptography (ECC) and implementing hybrid architectures, where only critical discovery metadata are stored on-chain, are potential solutions for mitigating these performance concerns [18].

Resolution: This paper mitigates computational and storage overheads by adopting a hybrid discovery architecture that records only critical discovery metadata on-chain while keeping bulk indices off-chain, thereby improving scalability and response latency.

3.5. Group Management

Group management is essential in IoT systems to securely manage devices and user groups. Blockchain technology can enhance this process by providing a decentralized, immutable, and transparent management of group memberships and access rights through smart contracts.

Decentralized Group Registration and Management: Blockchain ensures tamper-proof storage of IoT group memberships while encrypting sensitive data like permissions [51]. Smart contracts further automate group dynamics by defining and executing conditions for joining and leaving [20].

RBAC for Group Policies: Blockchain securely stores access policies [21], while smart contracts enforce RBAC to ensure only authorized roles can access or modify group resources. This prevents unauthorized manipulation of sensitive data within device groups [19].

Decentralized Group Coordination through Smart Contracts: Group tasks, such as device synchronization, are executed as blockchain transactions. This creates an immutable record of task completion that is shared across the network, enabling transparent and real-time monitoring of group status.

Use Case: Blockchain technology has demonstrated significant potential in enhancing secure group management across diverse IoT applications. In medical IoT environments, it enables the management of group access while supporting robust device authentication and authorization through public-private key mechanisms [23,24]. Extending this paradigm, blockchain-based group key agreement protocols have been employed in energy-constrained IoT networks to establish decentralized and resilient key management for group communications, effectively addressing the vulnerabilities associated with centralized architectures [52]. Moreover, in dynamic IoT settings characterized by large-scale groups, distributed blockchain solutions provide scalable and trustworthy mechanisms for group key management by incorporating intelligent authentication and lightweight data updates [53].

Challenge: The primary challenge for blockchain in group management, particularly in large groups, is scalability. The large transaction volume and data size generated by massive IoT devices can lead to significant processing delays (latencies) when traditional consensus mechanisms are used. To mitigate this, sharding techniques have been actively researched to partition networks into smaller segments (shards) that can process group transactions in parallel, thereby improving throughput [24,54,55]. In addition, resource-constrained IoT devices face challenges when directly participating in resource-intensive blockchain consensus processes. This necessitates the use of lightweight consensus algorithms such as PoA variations, which are tailored to minimize computation and energy consumption, or the deployment of dedicated management hub nodes that interface with the blockchain on their behalf to manage group activities [56,57].

Resolution: This study demonstrates a feasible path using a lightweight blockchain interworking proxy solely as a ledger interface—without centralizing group management—and by adopting a hybrid on/off-chain design with batched submissions to explicitly reduce the on-chain transaction rate and data footprint for large groups. In addition to improving scalability, this decentralized group-management model can naturally support federated learning scenarios that rely on secure group aggregation across multiple organizations: blockchain-based membership, key-management, and contribution records allow participating clients, aggregators, and auditors to verify group composition and updates without sharing raw training data.

3.6. Location

Location data are critical in IoT applications such as smart cities, logistics, and agriculture, where real-time tracking and geospatial information are key. Blockchain enhances location data management by providing tamper-resistant, secure, and transparent storage.

Location Data Integrity and Verification: Blockchain ensures location data (e.g., GPS) is stored immutably, guaranteeing integrity against tampering [25]. This provides a verifiable foundation for applications like logistics, where the authenticity of location history is critical.

Location-Based Automation: Smart contracts enable location-based automation by triggering events when devices reach predefined geographical boundaries [26,27]. This facilitates real-time automated actions in scenarios such as supply chain management and smart agriculture.

Location Data Sharing: Blockchain facilitates secure, consistent location data sharing among multiple stakeholders while preserving privacy [58]. It enforces strict access controls, ensuring that only authorized parties in ecosystems like smart cities can view or update sensitive location information.

Use Case: The integration of Blockchain and IoT for location management enhances trust and transparency in critical sectors. In logistics, IoT sensors record shipment locations and conditions in a distributed ledger, creating an immutable audit trail that allows smart contracts to automate payments or insurance claims based on verifiable delivery data [13,59,60]. Similarly, in Smart Cities and Intelligent Transportation Systems (ITS), blockchain secures decentralized vehicle location data. This enables real-time sharing with authorized entities (e.g., traffic management) while preserving driver privacy through pseudonymity, ensuring data authenticity without compromising security [61,62].

Challenge: The primary challenge in utilizing the blockchain for real-time location management is its scalability. The high frequency and sheer volume of location updates generated by a massive number of mobile IoT devices can significantly increase the transaction latency and blockchain storage demands, requiring solutions such as off-chain data storage (e.g., the InterPlanetary File System or IPFS) with on-chain verification mechanisms [58].

Resolution: This study adopts a hybrid on/off-chain design for real-time location data—keeping high-frequency off-chain updates while anchoring concise on-chain proofs—and uses batched submissions to alleviate processing latency and on-chain storage demand.

3.7. Network Service Exposure

Blockchain enhances network-service exposure by securely logging network-service usage and automating network selection for IoT devices. Using blockchain, network service usage, such as service requests and data consumption, is recorded in a tamper-resistant and transparent manner, ensuring accurate billing and auditability [63]. In addition, smart contracts automate the network selection process, ensuring that IoT devices connect to the most optimal network based on real-time conditions such as bandwidth or latency [64]. Blockchain also ensures that service agreements are met before a service is established, thus enhancing security and efficiency.

Use Case: In 5G and beyond, consortium blockchains facilitate decentralized trading and management of network slices. These frameworks allow Infrastructure Providers (InPs) and Mobile Virtual Network Operators (MVNOs) to securely trade spectrum resources by utilizing smart contracts and game-theoretic incentives to automate slice adjustments and ensure a fair distribution [64,65]. Furthermore, for 6G networks, blockchain enhances service-level agreement (SLA) management by immutably recording slice configurations and performance indicators. This enables automated, auditable SLA monitoring and penalty enforcement, thereby securing trust between consumers and providers in multidomain environments [66,67].

Challenge: A primary challenge is the requirement of low-latency consensus mechanisms to support real-time instantaneous decisions for network selection and resource allocation. The computational overhead of traditional blockchain consensus protocols can introduce significant delays, imposing constraints on resource-constrained IoT devices and time-sensitive network functions.

Resolution: This study confines blockchain use for network service exposure to asynchronous, batched audit/attestation writes via an interworking proxy—devices do not participate in consensus or execute contracts—while real-time network selection/resource allocation remains off-chain, reducing per-device on-chain interaction without modifying consensus.

3.8. Subscription and Notification

In IoT systems, subscriptions and notifications play critical roles in ensuring that devices and services react to real-time events. Blockchain can significantly enhance this process by providing secure, immutable, and transparent mechanisms to manage subscriptions and notifications.

Event-Based Subscription and Notification: Smart contracts automate event-driven subscriptions by triggering alerts when predefined conditions (e.g., temperature thresholds) are met [28]. This ensures timely, verifiable notifications, while the ledger’s immutability creates an unalterable audit trail of all triggered events.

Secure and Tamper-Proof Notifications: Blockchain creates a secure, validation-based history for critical IoT alerts. In sectors like smart agriculture, recording environmental anomalies on-chain ensures a transparent audit trail for stakeholders [29]. This mechanism mitigates the risk of fraudulent or erroneous notifications by enforcing data integrity.

Access Control and Role-Based Notification Delivery: Smart contracts enforce RBAC to ensure notifications reach only authorized recipients [30]. For instance, in smart grids, operational alerts can be routed exclusively to utility managers while billing data is sent to consumers [31]. This granular control enhances privacy by preventing unauthorized information exposure.

Use Case: Blockchain facilitates trusted, automated dissemination of critical event data across various ecosystems. Commercial platforms, such as IBM Watson’s IoT and WiMi, leverage this to securely transmit real-time alerts between business partners, thereby ensuring data immutability for supply chain updates [31]. In Intelligent Transportation Systems (ITS), blockchain frameworks verify traffic anomalies by using consensus mechanisms before broadcasting authenticated warnings to vehicles, thereby preventing accidents caused by false information [68]. Similarly, in Industrial IoT (IIoT), smart contracts trigger secure maintenance notifications upon detecting anomalies logged on a private blockchain and are dispatched exclusively to authorized technicians, creating a verified audit trail for regulatory compliance [28].

Challenge: The primary technical constraint is the potential of high-frequency notifications to generate a large volume of transactions, which can lead to network congestion and high latency within a blockchain network. This challenge necessitates the development of efficient transaction aggregation and optimized off-chain processing solutions to maintain real-time responsiveness required by many IoT applications [29].

Resolution: This study mitigates congestion by adopting a hybrid on/off-chain design that records only critical subscription/notification attestations on-chain, while keeping bulk event data off-chain and employing batched, asynchronous submissions to reduce transaction volume and preserve real-time responsiveness.

3.9. Application & Service Management

Blockchain enhances Application & Service Management (ASM) by decentralizing the application lifecycle and automating service provision through smart contracts [33]. This automation reduces manual intervention while ensuring transparent and dispute-free billing by immutably logging usage data and triggering an automated payment settlement.

Use Case: In commercial scenarios, platforms such as IBM Watson IoT leverage the blockchain to automate smart grid provisioning and ensure an immutable financial settlement [32]. Beyond billing, research focuses on Quality of Service (QoS) assurance, and frameworks such as SmartSLA utilize smart contracts to automatically enforce service-level agreements (SLAs) by verifying metrics such as latency and executing penalty clauses [69]. Similarly, in Edge-Cloud environments, systems such as EdgeChain employ smart contracts for decentralized resource orchestration. These contracts govern the computing resource allocation based on policies and credit systems, thereby ensuring fair and auditable usage of IoT devices [70].

Challenge: The primary challenge is the complexity of encoding the intricate application management logic in smart contracts, which can lead to increased gas costs (in public blockchains) and potential vulnerabilities. Furthermore, the performance overheads of consensus mechanisms and contract execution may affect the responsiveness of management operations, particularly for latency-sensitive applications. Designing lightweight smart contracts and utilizing permissioned blockchain configurations with optimized consensus algorithms are essential strategies for mitigating these challenges.

Resolution: This study does not directly address the intrinsic performance limits of consensus or smart contract execution. Instead, it minimizes the on-chain application management logic (favoring lightweight contracts) and employs a BlockIPE that abstracts the ledger, enabling replacement/reconfiguration (e.g., permissioned chains with optimized consensus) without redesigning the services. These choices constrain on-chain exposure and the associated costs, and the remaining limitations are discussed in Section 6.

3.10. Service Charging & Accounting

Blockchain has revolutionized IoT service charging by enabling secure, automated, and tamper-proof billing based on resource consumption [34]. By using smart contracts, the system automatically tracks usage and triggers payments upon reaching predefined thresholds, thereby effectively eliminating manual invoicing disputes [35]. Furthermore, the blockchain architecture naturally supports micropayments, making it ideal for high-frequency, low-value transactions inherent to IoT environments [71].

Use Case: Blockchain facilitates trustless automation in verticals such as decentralized smart grids, enabling real-time peer-to-peer micropayments between prosumers and consumers without intermediaries [37,38]. This is particularly evident in the Electric Vehicle (EV) charging infrastructure. Consortium blockchains and smart contracts manage the entire transaction lifecycle, from bidding and authentication to final settlement, based on smart meter data. This approach not only fosters an efficient decentralized energy market [72] but also secures charging sessions against cyberattacks by enforcing strict identity verification and data integrity during the payment process [73].

Challenge: The primary challenge in implementing blockchain for service charging is the scalability requirement for handling the high volume of microtransactions characteristic of massive IoT deployments. The latency and transaction throughput limitations of some blockchain consensus mechanisms can constrain the real-time billing capabilities. Potential solutions include employing DAG-based structures for a higher transaction throughput, implementing payment channel networks for off-chain transaction aggregation, and developing optimized consensus algorithms specifically designed for high-frequency accounting scenarios [36].

Resolution: This study did not directly address optimizing the consensus or performance overheads associated with high-volume microtransactions for service charging. Instead, the architecture abstracts the ledger via a BlockIPE, enabling the replacement or reconfiguration of the underlying blockchain (e.g., DAG-based or payment-channel-enabled networks) without redesigning services; the evaluation of such alternatives and their limitations is deferred to future work.

3.11. Discussion

The comprehensive analysis conducted in the preceding sections demonstrates blockchain’s significant potential to enhance the foundational capabilities of oneM2M CSFs. By mapping blockchain’s inherent features—decentralization, immutability, and programmability via smart contracts—to each CSF, this study provides a structured framework for understanding its transformative impact on IoT platforms. The findings reveal that blockchain’s utility extends far beyond its conventional application as a mere data storage solution, positioning it as a versatile technology capable of reinventing core IoT service layer functionalities from secure device lifecycle management to automated service charging.

3.11.1. Key Lessons Learned

This analysis yields several critical insights. First, it is evident that blockchain can address the fundamental trust and security challenges inherent in centralized IoT architectures, particularly in multi-stakeholder environments. The ability to create tamperproof audit trails for data provenance (Data Management), device actions (Device Management), and financial transactions (Service Charging) has introduced a new accountability paradigm. Second, the automation enabled by smart contracts can significantly increase operational efficiency across various CSFs, such as automating access control (security), group policy enforcement (Group Management), and subscription notifications. However, a paramount lesson is that this enhancement is not without cost. The architectural paradigms of blockchain often conflict with the performance and scalability requirements of large-scale IoT deployments. The computational overhead of consensus mechanisms, storage burden of immutable ledgers, and latency introduced by smart contract execution present substantial challenges that must be carefully navigated through hybrid architectural designs and optimized protocols.

3.11.2. Synthesis of CSF Enhancements

This study established that the value proposition of blockchain varies across the CSF landscape. For CSFs, such as securityand Service Charging & Accounting, blockchain provides a direct and powerful solution for decentralized trust and automated enforcement. For others, such as discovery and Network Service Exposure, their roles are more complementary, adding verifiability and transparency to existing processes. A crucial finding is that a one-size-fits-all approach is impractical and that the integration strategy must be tailored to the specific requirements and constraints of each CSF. For instance, although full on-chain storage may be suitable for critical access control policies, a hybrid model with off-chain data storage and on-chain hash verification is essential for managing high-volume sensor data.

3.11.3. Bridging to Implementation

While the conceptual analysis confirms the feasibility and benefits of blockchain integration, a critical gap remains between its theoretical potential and practical deployment. The identified challenges, particularly regarding scalability and performance, require empirical validation to understand their real-world implications. To address this issue, the following section transitions from analysis to implementation. Section 4 presents the BlockIPEframework, which is a concrete architectural blueprint designed to operationalize the insights from this discussion. This framework is instantiated within a oneM2M-standard-compliant IoT service platform to empirically evaluate how blockchain can be pragmatically integrated to enhance data management, provide measurable performance metrics, and validate the lessons learned.

4. Blockchain-Enabled IoT Platform

Our goal is to allow IoT entities to store data in a blockchain network, whereas conventional IoT management data are stored in conventional databases. Our system is simple to use because all of the provided data are based on the global standards oneM2M platform and PDL platform, but it is also secure enough to trust sensitive information by using a permissioned blockchain network.

4.1. oneM2M Architecture Principle

As shown in Figure 4, oneM2M comprises several entities in separate layers with different roles. These are the Application Entity (AE), common service entity (CSE), and lately the Network Service Entity (NSE). The AE is responsible for applying logic using the oneM2M services. A CSE is the instantiation of a set of common service functions that can be provided to the AEs. The NSE provides network services to the CSE from the underlying network, such as device management, device triggering, and localization. The first two entities can be placed on diverse devices, such as servers, gateways, computers, and mobile devices. Communication between these devices is made possible using oneM2M reference points called Mca, Mcc, and Mcn [74]. Mca allows the AEs to use the services provided by the CSE. Mcc is responsible for inter-CSE communication. The Mcn reference point permits CSEs to use the services offered by networks or NSEs.

oneM2M uses a resource-based model in which the services are labeled as resources. For example, the <CSEBase> that denotes a CSE is considered to be the root of the rest of the resources within the CSE.

The <CSEBase> root node can accommodate a number of IoT applications represented by the <AE> as its child resources. Every <AE> can have multiple child resources as data instances, represented by the <container> (cnt) resource. Actual data and content are stored in the <contentInstance> (cin) child resource connected to the data storage used by the IoT platform. A oneM2M-based platform can be linked to any database product; however, Relational Database Management Systems (RDBMS) and MongoDB are the databases most commonly used by the centralized IoT service layer platform. These databases are subjected to various security threats, including data modification [74]. In the proposed architecture, we propose a mechanism that allows data to be stored in either a general database or a blockchain-based database that can utilize oneM2M’s CSF, moving away from traditional methods.

4.2. High-Level Architecture of Blockchain-Enabled IoT Platform

The architecture of the proposed system is shown in Figure 5. When an IoT device is registered on an IoT platform, it can decide how to store its measurement data, depending on the characteristics of the data. The first option is to store the data in a conventional database such as an RDBMS. The second option allows the device to store sensitive data that must be preserved in a connected PDL blockchain network.

Similar to the oneM2M IoT platform, our blockchain-enabled IoT platform supports various CSFs oneM2M such as discovery, registration, and security. In addition, our platform supports the common function of utilizing blockchain technologies, such as identity management, consensus, and peer-to-peer (P2P) communication. These functions are provided by a set of RESTful APIs. When one of the APIs of a blockchain smart contract is called via an IoT application, BlockIPE, which is a dedicated proxy for blockchain functions, converts the information in the IoT API call into the corresponding blockchain smart contract API call. To do this, BlockIPE manages an internal mapping table to convert IoT APIs into blockchain smart-contract APIs.

We assume that an IoT AE representing a sensor on an IoT platform exists in the service to be leveraged. The AE receives values periodically from the sensor. Depending on the usage and characteristics of the sensor data, they can be managed on the IoT platform using one of two options:

Conventional data processing. If the data does not have a significant impact on the service, it does not need to be stored in the blockchain network. In that case, the IoT platform will manage the data in the conventional way, using common functions to store data in a connected conventional database.

Blockchain data processing. If the data needs to be traced, they should not be changed under any circumstances. Such data should be stored in the blockchain network when it Is uploaded to the IoT platform.

Using the APIs provided by the IoT platform, users can decide in real time which option to choose. This decision can be made even when the sensor resources are created. When the IoT platform receives information from the sensor to be stored in the blockchain network, the IoT platform’s BlockIPE runs a function through the blockchain API that generates information regarding the sensor ID for a smart contract. The remaining nodes in the system observe the change through the transactions that occur, and the corresponding sensor ID information is added to the blockchain.

Figure 6 describes the architectural interworking between the oneM2M platform and the PDL blockchain network. It is assumed that an Application Dedicated Node (ADN-AE) intends to store data in the oneM2M IN-CSE for tracking purposes. To anchor these data to the blockchain, the user sets the BC attribute to 1 during the CREATE, RETRIEVE, or UPDATE operations. This attribute can be applied to key oneM2M resources such as <cin>, <sub>, and <acp>.

Communication occurs via the Mca reference point, translating the user’s request into a resource creation command on the IN-CSE. When a resource with an enabled BC attribute is detected, the oneM2M BlockIPE mediates the interaction. As shown in the figure, the BlockIPE consists of an IN-AE that manages the oneM2M-side resources and a PDL Client that acts as a gateway for the blockchain network. The BlockIPE translates the oneM2M resource payload into a smart contract transaction and submits it to the PDL nodes through the PDL interface. Finally, upon successful mining, the BlockIPE receives a confirmation and links the transaction hash back to the oneM2M resource.

4.3. Connected Blockchain

Theoretically, any blockchain network could be connected to an IoT service platform. However, because many blockchain technologies suffer from inefficient consensus rules, resulting in low transaction throughput and block generation rates, and because all data are public, we use Hyperledger Besu as a reference permissioned-ledger implementation for the PDL network, suitable for IoT platforms that handle sensitive data. A PDL blockchain network is a private blockchain that allows only authorized nodes and users to access the network. A list of users and nodes limits unauthorized access from the outside, ensuring that sensitive data are kept safe. In addition, RBAC can be implemented using smart contracts for granular access control. The data stored in the blockchain are sensitive and should be accessible only to trusted nodes and wallet addresses. The PDL blockchain maintains a list of accessible nodes and wallet addresses. All nodes participating in the PDL blockchain have the same list. The nodes must be registered on the list before participating. This provides more advanced access control owing to the private nature of the blockchain. When a request arrives for a transaction, the address that sends the request is first validated to determine whether it is on the list. Otherwise, the transaction is rejected to prevent untrusted wallet addresses from accessing the transaction. Lifecycle management of smart contracts is essential for the PDL blockchain. This helps validate permissions and prevent smart contract malfunctions. Lifecycle management can be achieved through timers present in a smart contract. Access control is required for all functions. You must ensure that you have sufficient permission to access a particular function, and you must check the role of the caller in the allow/block access.

4.4. Detailed IoT and Blockchain Interworking Mechanism

In this section, we describe the integration steps for PDL blockchain functionality within the oneM2M service layer platform. As shown in Algorithm 1 and Figure 7, the mechanism involves four key entities: the Application (AE), the oneM2M Platform, the BlockIPE, and the PDL Platform.

Algorithm 1: BlockIPE Interworking Pseudocode that shows detailed interworking mechanism enabling blockchain function to IoT platforms

    Based on these entities, the proposed architecture supports three main phases, Initialization, Application Registration, and Transaction Generation, to securely anchor sensitive IoT data to the blockchain.

Initialization Phase: The process begins with the BlockIPE, which establishes the necessary resources. The IPE sends a request for AE registration and container (<cnt>) creation to the oneM2M platform (Step 1-1). Subsequently, a subscription (<sub>) is created (Step 1-2). This subscription configures the platform to notify the IPE of any Creation, Update, or Deletion (CRUD) events on the target resources, establishing a communication channel for data handling.

Application Registration Phase: This phase authorizes the application to interact with the blockchain. First, the IoT Application (AE) sends a registration request to the oneM2M platform (Step 2-1). The platform receives this information and forwards the request to the BlockIPE based on the interworking policy (Step 2-2). Upon receiving the request, the IPE registers its wallet address with the PDL platform (Step 2-3). The PDL platform then adds the wallets to its allow-list, authorizing the application to interact with the ledger through the IPE.

Transaction Generation Phase: This phase handles the actual data anchoring. The Application initiates the process by creating a content instance (<cin>) with the BC attribute set to true (Step 3-1), flagging the data for blockchain storage.

Notification and Processing: The oneM2M platform detects the BC attribute and sends a notification containing the <cin> details to the BlockIPE (Step 3-2). The IPE internally processes this data, consulting the CSF-contract mapping and encoding the payload.

Submission: The IPE creates and submits a transaction to the PDL platform (Step 3-3). The PDL platform validates the transaction and anchors it to the ledger.

Finalization: Once validated, the PDL platform returns the transaction hash to the BlockIPE (Step 3-4). Finally, the IPE creates a history <cin> in the oneM2M platform (Step 3-5). This resource contains the transaction hash, effectively linking the off-chain IoT data with its immutable on-chain record.

In our prototype, this mapping is generic: the IPE exposes REST endpoints and uses configuration to link oneM2M notifications to smart contracts. Thus, CSFs like Data Management (<cnt>/<cin>) or Security (<acp> updates) use the same pipeline, realizing the CSF-blockchain mapping in Table 1.

4.5. Security, Privacy, and Access-Control Clarifications

This subsection clarifies the security semantics of our integration, explicitly defining the threat model, privacy groups, key management, and on-chain authorization mechanisms.

Threat Model: We assume adversaries may (i) impersonate AEs, (ii) attempt unauthorized CRUD operations, or (iii) submit replayed transactions. We do not assume default on-chain confidentiality; thus, sensitive payloads represent off-chain data.

Privacy Groups: A privacy group aggregates authorized principals (e.g., AEs) under a common scope. On-chain, this maps a groupId to member addresses and binds to oneM2M <acp> policies to strictly control resource access.

Key Handling: Principals sign requests using cryptographic keys, optionally linked to DIDs. In the event of a compromise, access is revoked by updating the on-chain role assignments, effectively blocking future authorization.

On-Chain RBAC Enforcement: Smart contracts enforce authorization by validating the caller’s role against stored policies before any state transition. Unauthorized calls revert, preventing invalid state changes. The enforcement flow is as follows:

1.. Admission: The BlockIPE is allow-listed on the PDL to reject unauthorized senders.

2.. Trigger: An AE creates a BC-anchored <cin>, notifying the IPE.

3.. Validation: The IPE submits a transaction; the contract verifies the role/policy and reverts if unauthorized.

4.. Linkage: Validated transaction hashes are recorded on-chain and linked back to a history <cin> for auditability.

Mitigation: Our design employs a dual-layer defense: network-level allow-listing and contract-level role checks. Replay attacks are mitigated using nonces/timestamps, whereas key compromises are handled through immediate on-chain role revocation.

5. System Implementation and Evaluation

This section evaluates the performance of an IoT platform embedded with blockchain technology by assessing the interaction proxy within the proposed framework.

To utilize blockchain in the CSFs of oneM2M, the role of the BlockIPE is essential. The BlockIPE receives CSFs requests from oneM2M and facilitates interactions with the blockchain smart contract through mapping. Several experiments were conducted to validate this.

For the IPE, we implemented the proxy in Go and deployed it on macOS Sequoia 15.4, while tinyIoT, a C-based platform supporting low-power devices, was employed as the oneM2M service platform. The entire service was run on a MacBook Air M1 16 GB. IPE, tinyIoT, and the blockchains were all executed within Docker containers, independently running and isolating different environments during performance testing. The k6 tool was used for performance testing.

Internally, the BlockIPE was implemented as a thin Go service without any persistent storage of application data. Its in-memory runtime state is limited to the configuration parameters, an in-memory mapping table that associates oneM2M resources with smart contracts, and an optional in-memory buffer used when batched submissions are enabled (via the batchSize parameter). Each HTTP notification from the oneM2M platform is processed independently, and the IPE does not maintain long-lived per-client sessions or application-specific states beyond this shared configuration. Under load, concurrency is handled by the Go HTTP runtime, and the IPE simply transforms each request into a corresponding JSON-RPC call to the PDL node. If a blockchain call fails (e.g., owing to timeout, connectivity issues, or contract-level rejection), the IPE logs the error and returns the error status to the IoT platform. The prototype does not implement persistent retry queues or compensation logic; designing such mechanisms is left for future work, and our performance experiments, therefore, the focus is on steady-state behavior under successful transaction submissions.

For the blockchain, we used Ganache, a local Ethereum development network, running in a single-node configuration on the same host as the IPE and tinyIoT (inside a Docker container). To isolate the IPE’s processing overhead from blockchain consensus effects, we configured Ganache to mine blocks immediately (effectively zero block time) with no artificial network delay. In other words, the latency results in Figure 8 and Figure 9 primarily reflect the proxy- and platform-level processing, not on-chain finality. Real-world confirmation times depend strongly on the choice of platform, consensus mechanism, validator count, and hardware. Therefore, we report the end-to-end confirmation latency separately using a Hyperledger Besu permissioned testbed and discuss how different configurations would affect the overall latency budget rather than fixing a single blockchain configuration.

Figure 8 compares the data storage latency between a blockchain-integrated IoT platform and a traditional IoT platform across four time intervals: network delay from request initiation ($T_0$) to IoT platform receipt ($T_1$, NetDelay); IoT platform processing ($T_1$ to $T_2$, TinyProc); data transmission to the BlockIPE ($T_2$ to $T_3$, NetToIPE); and proxy processing and transaction submission ($T_3$ to $T_4$, IPEProc). In our setup, the blockchain path did not perform a conventional database write and was returned after submitting the transaction to the ledger (i.e., without waiting for on-chain confirmation/finality). Under this configuration, the blockchain-integrated path achieved a total latency of 86.376 ms compared with 92.130 ms for the traditional path, yielding an apparent ∼6 ms reduction. This reduction stems from skipping the database commit rather than any consensus effect; if confirmation/finality were included, the end-to-end latency would increase by the ledger’s confirmation time (e.g., ≈0.586–1.086 s on our Besu testbed). Latency varies by blockchain network: Hyperledger Fabric exhibits 0.13–0.16 s at <200 transactions per second (TPS) [75], while Hyperledger Besu ranges from 0.5–1 s [76]. Solana, with a higher TPS, incurs  11 s owing to the transaction validation and block confirmation processes [77]. For Besu, the total latency in our setup was 0.586–1.086 s, which remained acceptable given the enhanced security.

Figure 9 illustrates the average latency across various TPS levels, up to 100,000 TPS. As in Figure 8, the latency was measured across four intervals. The BlockIPE maintained a stable performance, indicating that the platform and blockchain design significantly influenced scalability. Given blockchain’s superior security, batch processing can further align the performance with traditional IoT platforms. The proposed integration offers a practical solution for IoT systems by effectively balancing latency and robustness.

Overall, our measurements indicate that the additional proxy- and platform-level overhead introduced by the BlockIPE is modest compared with a traditional database-backed path. The dominant contributor to the end-to-end latency remains the underlying permissioned ledger, whose confirmation delay (e.g., ≈0.586–1.086 s on Besu) must be accounted for when evaluating the suitability for a given IoT application. Although some trade-offs for enhanced security may lead to increased latency, blockchain technology can still be effectively utilized in typical IoT environments.

5.1. Scope of Evaluation and System-Level Considerations

This subsection states the scope of our evaluation and summarizes key system-level considerations of the proposed oneM2M-PDL interworking architecture. We focus on proxy-level measurements and provide an analytical discussion of reliability, storage growth, and resource costs.

Scope of evaluation: Our evaluation is intentionally scoped to demonstrate the feasibility of a standards-compliant oneM2M-PDL interworking architecture with acceptable proxy-leveloverhead, rather than claiming end-to-end optimization of all system-level metrics. Accordingly, the latency and throughput results shown in Figure 8 and Figure 9 measure the path up to transaction submission at the BlockIPE (i.e., without waiting for on-chain finality/confirmation). They are used to isolate the incremental overhead introduced by the BlockIPE and the selective on-/off-chain routing.

Reliability under node failures/partitions: Reliability under node failures and network partitioning is primarily governed by the underlying permissioned ledger’s membership and consensus configuration (e.g., crash/fault tolerance thresholds and reconfiguration policies), which is orthogonal to the oneM2M interface logic. Within our architecture, the BlockIPE is a replaceable gateway component; thus, availability can be improved by deploying redundant IPE instances behind a load balancer and treating transaction submission failures as recoverable errors (retry/queue policies are deployment-dependent and will be discussed in future work).

Storage overhead and long-term ledger growth: Ledger growth is linear in the number of anchored operations: $\mathrm{growth}\approx N\times s$, where N is the number of on-chain anchoring events and s is the average size of the on-chain record (transaction + logs). The hybrid model reduces s by recording only integrity anchors and policy/audit events for high-volume data, while maintaining privacy-sensitive payloads off-chain, and batching can reduce N under bursty workloads. Long-term sustainability can be supported by operational techniques (e.g., pruning/archival nodes, periodic checkpointing, and off-chain data-retention policies), which we leave to deployment-specific engineering.

Computational cost and resource utilization: Our measurements decompose proxy-level latency into network and processing segments (e.g., NetToIPE and IPEProc), where IPEProc remains sub-millisecond across increasing virtual loads, indicating low processing overhead at the BlockIPE. However, the validator-side CPU/RAM costs from consensus and smart contract execution are not directly measured in this work and are explicitly stated as limitations and future benchmarking targets.

Sustainability of the hybrid on-/off-chain model: The hybrid design improves scalability by minimizing on-chain storage and avoiding confidentiality assumptions for ledger state, while preserving auditability through immutable anchors and events. This shifts part of the system’s responsibility to off-chain storage availability and retention, which can be addressed through replication and regular integrity audits (hash verification) and is discussed as an operational consideration rather than a protocol guarantee.

5.2. Security Analysis of the Prototype Implementation

Although a full formal security analysis is beyond the scope of this paper, the prototype incorporates several concrete protection mechanisms in line with the Security CSF discussed in Section 3.2.

Access Control Integration (oneM2M Layer): The prototype strictly adheres to the oneM2M security model by integrating with the existing <accessControlPolicy> (ACP) mechanism. The BlockIPE is designed to trigger blockchain anchoring only for requests from AEs that hold valid ACP authorizations. This ensures that the decision to record events on-chain is governed by the same fine-grained access control policies that protect standard IoT resources, effectively preventing unauthorized entities from initiating ledger transactions.

Ledger Security and Admission (Blockchain Layer): Architecturally, the system is designed for a permissioned environment (e.g., Hyperledger Besu with validator allow-listing), where only registered IPE wallets can invoke smart contracts. In our experimental prototype, we utilized a local Ganache network to validate the functional correctness of the transaction flows. Although the Ganache environment does not enforce network-level admission control, our smart contract implementation simulates this security boundary by validating that the sender’s address exists on an on-chain allowable list before accepting any state changes.

Integrity and Auditability: The integration enforces a strict gateway pattern where all state changes must pass through the BlockIPE. This creates a tamper-resistant audit trail. Even if an adversary compromises a local database, the corresponding on-chain hash (stored in the history <cin>) remains immutable, allowing the system to detect data corruption or post hoc manipulation.

Limitations and Future Work: We acknowledge that the current prototype stores IPE wallet keys locally without a Hardware Security Module (HSM), which presents a potential vulnerability to host-level compromise. Furthermore, we did not model active network attacks (e.g., DDoS) in the Ganache testbed. Future iterations will focus on hardening the key management lifecycles and performing penetration testing in a multi-node production deployment.

6. Conclusions and Future Work

In IoT systems, the secure storage of data is an important challenge. However, traditional centralized IoT platforms that use conventional databases can incur high costs, long latency, and pose the risk of various attacks, such as data tampering. Blockchain technology can enhance the trustworthiness and security of IoT platforms. In this study, we propose a secure system utilizing blockchain within the oneM2M standard to facilitate the use of CSFs.

Experimental results demonstrate that the proposed BlockIPE achieves a processing latency of 86.38 ms, representing an improvement of approximately 6.2% compared to the traditional database-backed path (92.13 ms). Furthermore, throughput tests confirmed the scalability of the system, maintaining stable performance under loads of up to 100,000 TPS. These findings indicate that the proposed architecture achieves higher data integrity with minimal latency overhead, thereby rendering it suitable for various IoT scenarios.

However, a performance evaluation focusing solely on the IPE and the absence of a PDL native blockchain may slightly reduce the overall trustworthiness. Therefore, future research should focus on data for performance evaluation based on different blockchains and aim to establish reliability through the development of a native blockchain.

Although our prototype does not directly implement AI/ML modules, the proposed blockchain-enhanced CSFs can serve as a trustworthy substrate for AI/ML-driven security and automation in IoT and IIoT settings. Integrity-assured logs and device interactions help prevent learning and decision-making on tampered or fabricated data, which is a key prerequisite for robust anomaly detection, predictive maintenance, and policy automation. We leave the integration of concrete AI/ML use cases on top of the proposed architecture as an important direction for future work.

In addition, future work includes (i) a more detailed latency characterization by quantifying tail latencies (e.g., p95 and p99) under different load conditions and permissioned-consensus settings, (ii) an experimental robustness study via fault-injection (e.g., node failures and network partitioning) to assess reliability, (iii) storage-growth profiling over long horizons under different anchoring/batching policies to evaluate the sustainability of the hybrid on-/off-chain model, and (iv) validator-side computational resource benchmarking (CPU/RAM) to quantify the cost of consensus and smart-contract execution. We also plan to strengthen the operational security by integrating a deployment-grade key management approach (e.g., KMS-backed key protection and lifecycle management for BlockIPE) and to benchmark alternative permissioned consensus mechanisms and network configurations.

In addition, we delineated the challenges that were not resolved in this study at the CSF level.

Security: We did not optimize or evaluate the intrinsic overheads of consensus mechanisms and smart-contract execution. Data encryption, key lifecycle management, and private channel operational guidelines remain at the design-only stage. Future work: Quantify p95/p99 latency and throughput under permissioned consensus (e.g., PBFT/PoA/IBFT), implement encryption with KMS-backed key lifecycle, and define private-channel operational policies.

Group Management: The proxy was used only as a ledger interface; optimization of consensus and contract performance was out of scope. The evaluation of sharding and other distributed techniques for large-scale groups—without centralized control—remains a topic for future work. Future work: Prototype sharding and hierarchical group operations, and measure cross-shard consistency, membership churn costs, and end-to-end latency while preserving decentralization.

Application & Service Management: We used lightweight smart contracts, and no quantitative analysis of consensus performance or contract-execution overhead was conducted. The effectiveness of IoT-tailored consensus and network alternatives is unverified. Future work: Apply formal verification to contracts and assess upgrade safety (proxy/modular patterns); benchmark IoT-suitable consensus/networks (e.g., Fabric, Besu/IBFT) for contract-execution latency and resource cost.

Service Charging & Accounting: Mechanisms tailored to high-frequency microtransactions (e.g., DAG-based ledgers, payment channels, rollups) were neither integrated nor evaluated. Future work: Integrate payment channels/rollups/DAG-based ledgers and benchmark settlement latency, double-spend resilience, fee volatility, and recovery under bursty microtransaction loads.

Although the modular architecture and BlockIPE facilitate ledger replacement and reconfiguration, these limitations persist and may manifest differently depending on the chosen ledger and operational policies.

Author Contributions

Conceptualization, J.L. (Jiho Lee) and J.L. (Jieun Lee); methodology, J.S.; software, J.L. (Jiho Lee); validation, J.L. (Jiho Lee), J.L. (Jieun Lee), Z.W. and J.S.; formal analysis, J.S.; investigation, J.L. (Jiho Lee) and J.L. (Jieun Lee); Resources, J.L. (Jiho Lee) and J.L. (Jieun Lee); data curation, J.L. (Jiho Lee); writing—original draft preparation, J.L. (Jiho Lee) and J.L. (Jieun Lee); writing—review and editing, Z.W. and J.S.; visualization, J.L. (Jiho Lee) and J.L. (Jieun Lee); supervision, J.S. and Z.W.; project administration, J.S.; funding acquisition, J.S. All authors have read and agreed to the published version of the manuscript.

Informed Consent Statement

Not applicable.

Data Availability Statement

Most data are contained within the article. All the data are available on request because of privacy or ethical restrictions.

Acknowledgments

Authors would like to give thanks for the support of the Culture, Sports and Tourism R&D Program through the Korea Creative Content Agency grant funded by the Ministry of Culture, Sports and Tourism in 2025 (Project Name: Training Global Talent for Copyright Protection and Management of On-Device AI Models).

Conflicts of Interest

The authors declare no conflicts of interest.

Footnotes

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Figures and Table

Figure 1 The oneM2M architecture encapsulates core IoT functionalities into interoperable CSFs to streamline operations across various domains. The dashed box represents additional oneM2M CSFs that are not explicitly depicted in the figure.

Figure 2 The PDL architecture comprises three layers—Application, Platform Service, and DLT. This layered separation decouples application logic from ledger implementations, enabling interoperability and allowing each layer to evolve independently.

Figure 3 oneM2M CSFs link to a PDL via smart contracts, enabling consensus-secured state, DID-verified identity, DAO-style governance, and automated registration, access control, and eventing. Each arrow represents the CSF-specific operation described in the figure.

Figure 4 A high-level oneM2M architecture and its resource structure. AE, CSE, and NSE interact via Mca (AE–CSE), Mcc (CSE–CSE), and Mcn (CSE–NSE). Resources follow a hierarchical tree rooted at the CSEBase.

Figure 5 High-level IoT platform architecture integrating blockchain: after device registration, routine telemetry is stored in an RDBMS, while sensitive or audit-critical data is stored on PDL blockchain network. The left dashed box represents the blockchain-based storage structure, whereas the right dashed box represents the conventional storage structure.

Figure 6 Detailed interworking architecture for oneM2M and Blockchain PDL using oneM2M BlockIPE.

Figure 7 The oneM2M-PDL interworking procedure phases: initialization (Steps 1-1 to 1-2), application register (Steps 2-1 to 2-3), and transaction generation (Steps 3-1 to 3-5).

Figure 8 End-to-end data-write latency is decomposed into NetDelay (T0–T1), TinyProc (T1–T2), NetToIPE (T2–T3), and IPEProc (T3–T4). In our measurement the blockchain path returns after transaction submission (no finality wait) and omits a conventional DB write, producing an apparent ∼6 ms lower latency than the traditional path; including on-chain confirmation would reverse this effect.

Figure 9 Latency across virtual user loads (proxy-level up to transaction submission; ledger finality/consensus cost is not included). The BlockIPE remains stable at scale; platform/chain design drives scalability, and batch submission can narrow the latency gap with traditional IoT while preserving blockchain security.

Table 1

Mapping of oneM2M CSFs to blockchain/PDL functionalities (smart contracts, consensus, DIDs, DAO-style governance, immutable logging). Summarizes how each CSF is enhanced for secure, automated IoT operations and notes trade-offs in scalability, latency, and computational overhead.

IoT Platform CSF	Blockchain-Enabled IoT Platform Common Feature
Data Management	Blockchain enhances data integrity and reliability via consensus mechanisms and distributed ledgers. IBM Blockchain IoT provides a tamper-proof record-sharing platform [14].
Security	ACP and Role-based access control (RBAC) are enforced via smart contracts. Hyperledger Fabric supports fine-grained access control and privacy via channels and identity-based permissions [12,15,16].
Device Management	Blockchain ensures device authentication and firmware integrity using hashed records. Filament’s Blocklet and DoE’s smart grid trials exemplify secure device lifecycle tracking [17].
Discovery	Confidential discovery and role-based access are enabled through encrypted smart contracts. RBAC improves security and privacy during device discovery [12,18,19].
Group Management	Blockchain manage decentralized group formation, access policy enforcement, and group task synchronization. Examples include LWM2M interworking and medical IoT authentication [20,21,22,23,24].
Location	Tamper-resistant location logs and geofence-triggered smart contract events enhance traceability and automation. TradeLens and SK C&C logistics exemplify its use in cargo tracking [25,26,27].
Subscription & Notification	Smart contracts enable real-time, tamper-proof event alerts and subscription logs with RBAC. Used in IBM Watson IoT and WiMi for timely anomaly notifications [28,29,30,31].
Application & Service Management	Lifecycle automation of applications, usage metering, and service billing are implemented via smart contracts. IBM Watson IoT applies this in smart grid billing [32,33].
Service Charging & Accounting	Smart contracts support real-time micropayments based on IoT data usage. Proven in decentralized energy platforms and logistics billing [34,35,36,37,38].