Internet of Things (IoT) Service Layer System

Distributed Ledger Proxy Architecture:

Architecture Overview: A distributed ledger proxy (DLP) architecture is proposed, which acts as a bridge between the IoT service layer system (SLS) and the distributed ledger system (DLS). DLP is able to support multiple SLS nodes and different types of DLS.

Functional Support: DLP interfaces SLS nodes and DLS nodes, allowing SLS nodes to utilize the functions provided by DLS, such as inserting SLS information into the distributed ledger.

Interoperability Methods:

DLP and SLS Association: SLS nodes need to register with DLP and request approval to use its functions. DLP can create a distributed ledger account for SLS nodes.

Add SLS Information to Distributed Ledger: SLS nodes can convert SLS information (such as service layer request raw data) into distributed ledger transactions through DLP and add them to DLS. DLP maintains the mapping between SLS information and distributed ledger transactions.

Transaction Query and Verification: SLS nodes can query transactions in DLS, verify transaction status, and subscribe to transaction notifications that meet specific conditions.

Distributed Ledger System (DLS):

System Overview: DLS consists of multiple distributed ledger nodes (DLNs) that are interconnected through a peer-to-peer (P2P) network to jointly maintain and verify the distributed ledger.

Consensus Protocol: DLN uses a consensus protocol (such as Proof of Work PoW) to reach consensus on a set of transactions, and then adds the verified set of transactions to the ledger.

Ledger Structure: Distributed ledgers usually consist of blockchains, each block contains multiple transactions and block header information (such as timestamps, difficulty targets, hash of the previous block, etc.).

Interoperability Architecture Options:

Option 1: DLP supports a single SLS, which is suitable for simple interoperability scenarios.

Option 2: DLP supports multiple SLSs, but each SLS only interoperates through a single DLP.

Option 3: SLS nodes can connect to multiple DLPs, each DLP supports different types of SLSs, allowing SLS nodes to select the appropriate DLP based on their needs.

Option 4: A single DLP supports multiple types of DLSs, and SLS nodes interoperate with different DLSs through this DLP.

Specific implementation methods:

Transaction format and template: proposes transaction format and template resources (and) for defining and operating DLS transactions.

RESTful operation: describes how to implement DLP functions through RESTful operations in the oneM2M architecture, including creating, retrieving, updating and deleting and resources.

User interface: shows DLP configuration and user interface examples for configuring DLP parameters and displaying SLS nodes and DLS related information.

Application scenarios and advantages:

Application scenarios: This architecture is suitable for scenarios that require high security, immutability and distributed trust, such as data exchange between IoT devices, service request and response records, etc.

Advantages: By leveraging the characteristics of DLS (such as appendix, non-repudiation and distributed trust), the efficiency and security of data exchange between SLS nodes are improved, while reducing the need for pre-established trust.

These points comprehensively summarize the core content of the document, from the proposal of distributed ledger proxy architecture, detailed description of interoperability methods, basic concepts of distributed ledger systems, different options of interoperability architecture, specific implementation methods to application scenarios and advantages, providing readers with key information for in-depth understanding of the document.

Answers to short-answer questions:

What is a distributed ledger proxy (DLP)?

A: A distributed ledger proxy (DLP) is a logical node that interfaces between the IoT service layer system (SLS) and the distributed ledger system (DLS) and acts as a bridge. DLP can support multiple SLS nodes and different types of DLS, allowing SLS nodes to take advantage of the functions provided by DLS, such as inserting SLS information into the distributed ledger.

What does a distributed ledger system (DLS) consist of?

A: A distributed ledger system (DLS) consists of multiple distributed ledger nodes (DLNs), which are interconnected through a peer-to-peer (P2P) network to jointly maintain and verify the distributed ledger. Each DLN can generate new messages (i.e., transactions) and send them to other DLNs, reach consensus on the transaction set through a consensus protocol (such as PoW), and then add the verified transaction set to the ledger.

In the interoperation between DLP and SLS, what steps do SLS nodes need to take?

A: In the interoperability between DLP and SLS, the SLS node needs to perform the following steps: First, the SLS node needs to register with DLP and request approval to use its functions; Second, the SLS node converts SLS information (such as service layer requests or responses) into distributed ledger transactions through DLP and sends them to DLS; Then, the SLS node can query transactions in DLS, verify transaction status, and subscribe to transaction notifications that meet specific conditions.

What interoperability architecture options are proposed in the document?

A: Four interoperability architecture options are proposed in the document:

Option 1: DLP supports a single SLS, which is suitable for simple interoperability scenarios.

Option 2: DLP supports multiple SLSs, but each SLS only interoperates through a single DLP.

Option 3: SLS nodes can connect to multiple DLPs, each DLP supports different types of SLSs, allowing SLS nodes to select the appropriate DLP according to needs.

Option 4: A single DLP supports multiple types of DLSs, and SLS nodes interoperate with different DLSs through this DLP.

Briefly describe how to implement the functions of DLP in the oneM2M architecture?

A: In the oneM2M architecture, the functionality of DLP can be implemented through RESTful operations. Specifically, it includes creating, retrieving, updating, and deleting resources, which define the format and content of DLS transactions. By performing these RESTful operations, DLP can create and manage DLS transactions in oneM2M service layer nodes (such as CSE), thereby achieving interoperability between SLS nodes and DLS.