# Design and Implementation of Ledger-Based Points Transfer System for IoT Devices in LPWAN

Authors: Xin Qi; Keping Yu; Toshio Sato; Kouichi Shibata; Isao Konno; Takanori Tokutake; Rikiya Eguchi; Yusuke Maruyama; Zheng Wen; Kazuhiko Tamesue; Yutaka Katsuyama; Kazue Sako; Takuro Sato
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

Distributed ledger technology is becoming popular these days because of its high confidentiality, decentralization, and nontampering. It is suitable for replacing centralized security disadvantaged point transfer systems. Low-power wide area network (LPWAN) is capable for long-range communication with low-power consumption. The iconic features like wide area coverage and long battery-powered duration make it best to combine with large-scale IoT application deployment. In both industry and academic field, such combination of LPWAN and point transfer system is highly attended. However, the ledger management system generates too much data that low-bandwidth network such as LPWAN can hardly handle; meanwhile, the processing power’s requirement for small IoT devices is challenging. Towards addressing these issues, we design a packet transmission optimizing mechanism for a ledger-based point transfer system (LPTS) in LPWAN to reduce overall data traffic and build a simulator to evaluate its performance. Moreover, we have implemented the system and evaluated in field experiment.


---

## Body

## 1. Introduction

The current demand of information and communication technology has changed from simple point-to-point communication to interconnection of people and things and things and things and eventually realizes the interconnection of everything. In the process of upgrading and iterating mobile communication technologies, branches that focus on low-power communication technologies, such as Bluetooth, ZigBee [1], and other short-range communication technologies, have also developed. However, with the development of the Internet of Things (IoT), a large number of devices need to be interconnected, and their communication requirements are based on low mobility, low communication frequency, and low data volume. Traditional wired communication technologies are clearly not adaptable. Short-range communication technology cannot provide enough communication distance to meet the demand of long-distance and wide coverage of IoT. Mobile cellular networks, which are based on high speed, wide coverage, high mobility, and high terminal capacity, also discourage IoT. To solve this problem, an IoT network access technology with low cost, wide coverage, and simple deployment, and support for large number of connections, low-power wide area network (LPWAN) [2], has emerged. LPWAN-based interconnection systems are gaining widespread attention from academia and industry [3]. LPWAN has formed several technology camps worldwide, including narrow-band Internet of Things (NB-IoT) [4, 5], Long Range Wide Area Network (LoRaWAN) [6–8], Sigfox [9–11], and weightless [12].Meanwhile, modern information technology represented by the Internet, especially mobile payment, has had a fundamental impact on the human financial model. Along with the invention of digital currencies, the evolution of ledger technology can address the security issues of centralized services [13]. In other words, a ledger is similar to a database holding assets that can be shared across multiple sites, different places, or networks. Moreover, a decentralized ledger is designed to guarantee for tamper-proofing and being encrypted. It is currently most widely used in IoT finances. However, a traditional point transfer system is usually based on a centralized computer system with powerful processors, which consume much energy. When a point transfer system is introduced in a decentralized system, it is hard to simply split the computing need to individual nodes in the network. The combination of sensing, communication, and computing (SCC) needs to be smart deployed in the network. In other words, a more suitable design is needed for decentralized ledger systems to satisfy low-power hunger IoT devices. The specific contributions are as follows.
(1)
This paper designs a lightweight ledger-based point transfer system (LPTS) in LPWAN, which can guarantee the data security well and is suitable for IoT devices with weak computational power and capacity(2)
A field experiment is performed to evaluate the implementation of the system(3)
Additional signatures and an optimal packet delivering algorithm is proposed and evaluated by simulations. Evaluation against disasters is also performedThe rest of this paper is organized mainly into three parts as follows. In Section2, we describe the related work on LPWAN, ledger-based technology for IoT, and other lightweight distributed ledger system. In Section 3, we describe the design of LPTS with its principle, algorithm, configuration, and evaluation. Section 4 describes the implementation of LPTS with module designs and working prototype. Section 5 describes the extension of LPTS to improve either its security, packet transmission, or disaster management. Finally, we conclude the paper in Section 6.


## 2. Related Works

In the recent years, IoT had been a top trending field, and LPWAN is also a hot wireless technology that was introduced for IoT. On the other hand, Wi-Fi [14], ZigBee [15, 16], and Bluetooth technologies are dedicated high speed and low communication frequency, not very suitable for those battery-powered and long range communication needed IoT devices. In LPWAN field, NB-IoT is built by telecommunication operators with the adoption of cellular communication technology and authorized frequency bands [17, 18]. LoRa works in an unlicensed frequency band with linear spread spectrum technology, which is setup and managed by users [19, 20]. ZigBee mainly focuses on home IoT devices which use common frequency band. Table 1 shows some specifications of the above communication technologies. NB-IoT and LoRa perform the best in power consumption, up to 10 years with AA battery. However, the transmission data rate is too low to handle real-time data [21] in monitoring scenarios.Table 1
Comparison of wireless communication technologies.
TechnologyFrequencyTransmission rateTransmission distanceMaximum support nodesPower consumption (AA battery)LoRa150 MHz-1 GHz0.3-50 kbps~15 km200000About 10 yearsNB-IoTOperator bands<100 kbps10-15 km200000About 10 yearsZigBee2.4 GHz<250 kbps10-75 m65000About 2 yearsBluetooth2.4 GHz<1 mbps20-200 m7WeeksWi-Fi2.4/5 GHz<54 mbps20-200 m2007HoursMost IoT devices rely on the centralized servers or cloud servers to actually communicate with other devices [22]. It was possible to use satellite communication-based cloud service for remote nodes [23], but the power consumption was too high. In some studies, Proof-of-Work (PoW) [24] principle still suffers from 51% attack [25]. Centralized management can offer easy management and accesses but can also cause privacy and security issues, then comes the distributed ledger technology and IoT-powered integration. IoT devices can exchange, store, and generate data by using peer-to-peer technology, which is a characteristic role in distributed ledger systems [26]. This can ensure its privacy and robustness. Creating, modifying, and deleting data can be verified in IoT-powered distributed ledger to detect and prevent data misuse and tampering [27, 28].


## 3. Design of Ledger-Based Points Transfer System for IoT Devices in LPWAN

### 3.1. Design Principle

The design principle of LPTS for IoT devices in LPWAN is listed as below and referenced in Figure1:
(1)
Realize point transfer from A to B. The client can be terminals or other user devices(2)
The ledger management can manage the point balance of each user. The ledger should be tamper-proof(3)
LPWAN applied to achieve system availability even in the event of a disaster (achieved in Section5)(4)
Packet delivery mechanism optimization applied to achieve high packet deliver rate even with low communication bandwidth of LPWAN (achieved in Section5)(5)
System should be able to implement into IoT devices and be evaluated in field experimentFigure 1
System architecture.The main purpose of the point transfer system is to realize the function that delivers points from A to B. The users can use their terminal devices like smartphones or integrated devices. The user sends a point transfer request to the network, and the ledger management should be able to verify and start the point transfer process. After the point transfer, the point balance of the sender and receiver should be kept recorded in the ledger system; a certain way of validation should be implemented in the ledger system to protect it from tampering. Because this system has its application in disaster scenarios like earthquakes and tsunamis, it is important to make the nodes to run with battery power and wide area coverage. LPWAN is suitable for these situation and selected for the communication network for the point transfer system. However the bandwidth that LPWAN provides is known to be quite low comparing with modern cellular network or Wi-Fi. A packet delivery mechanism is proposed to optimize the bandwidth consumption, letting the network be valid and fast. Small-scale IoT devices like ARM-based chip sets are known to be energy saving and are suitable to hold the functions of the point transfer system. To verify the above ideas, we use simulations to validate and evaluate the technical performance of the system. In the end, the practical system should be implemented and tested in field experiments.


### 3.2. Algorithm for Distributed IoT Devices

The function of a point transfer system is to make point payment available in normal or disaster situations. The point transfer procedure is shown in Figure1, and the referenced hardware is shown in Figure 2; the user can use a smartphone or a smart device to connect to a node in the point transfer system. When the user chooses to send points from A to B, it sends out a point transfer request to the nodes. The node received the transaction request will broadcast the transaction to the surrounding nodes using its signature. Then, the nodes received the broadcast request will verify the written signature in the packet. If the signature is valid, the node appends its own signature and continues to forward this packet to the next node. When the packet contains enough signatures, this transaction is considered to be true and stored in the ledgers held by the nodes. In LPTS, all the nodes are maintaining the ledger’s consistency. This act involves verifying transmission requests. Algorithm 1 shows the verification logic of a transaction in the point transfer function. When a node receives a transaction request from users, it broadcasts this request to the nodes around, with its own verification signature in the message. The nodes receiving the broadcast request will first verify the sender node’s signature. The node shall add its own signature to the message once the previous signature is verified and forwards the message to other nodes. When message contains enough number of signatures, this transaction is verified, and the record will be added to the received node’s ledger.Algorithm 1: Point transfer function
InitializeM;                  //The number of nodesInitializeL;                    //The ledgerInitializeB0⋯M     //The candidates of received node j’s update blockData:T, total_node, wait_timeResult:request_count, new_segment_count, success_ratefunction transaction_request(T)Receive requested transactionT from the points transfer terminal;ifT is not NULLthenmy_nodeID⟵hostSendT to other nodes;elsemy_nodeID⟵guestReceiveT from other nodes;endifT is not NULLthenX⟵userID of point_sender in T;Y⟵userID of point_receiver in T;Calculate candidates of new balancesPx and Py based on blocks in L0⋯n;my_nodeID⟵"X⟵Px" and "Y⟵Py"fori=1toMdoifwait_time≤thresholdthenReceiveBi as calculated candidate of new balances from other nodes;endendCalculateBu as a majority vote of B0⋯M;Send approval results to the points transfer terminal;n⟵n+1;Ln⟵Bup;endFigure 2
Device examples.
(a)
Payment operation terminal(b)
User device(c)
NodesAlgorithm1 and Figure 3 describes the process of a transaction request (simulation scenario).
(1)
Create N nodes(2)
Create authentication mechanism and forwarding mechanism for each node(3)
Initial a book to keep the transferred points recording, and create initial among of points in the book(4)
Perform point transfer operations according to a random schedule of transaction request(5)
After verifying the transactions, the updated information is written in the ledger bookFigure 3
Ledger operation [29].


### 3.3. Evaluation

The first priority to validate the point transfer system is to make sure the system is stable. We need to evaluate the system’s robustness, since LPWA network may fail in handling large data transmission for the point transfer management. In the results, we compare it with a bitcoin-like ledger system to see the process time and packet deliver success rate is in the safe zone.Based on the system architecture in Figure1, we design an experimental setup that miniaturizes the hardware and uses LPWAN for communication. It is mainly composed of three parts (samples shown in Figure 2): payment operating terminals, user devices, and nodes.
(1)
Node. As shown in Figure4, a node uses Bluetooth module to communicate with smartphones and user devices. The ARM-based computer process all the requests, verification, and packet forwarding. The LPWAN module is used to communicate with other nodes using 920 MHz radio(2)
Payment operation terminal. The payment operation terminal is based on a commercially available microcomputer with integrated BLE module to communicate with the distributed ledger nodes(3)
User device. We built a prototype private key device using a low energy BLE integrated microcomputer to store account IDs and encryption keys. It can communicate with smartphones to send encrypted account IDs or with nodes to check balancesFigure 4
Node configuration.
(a)(b)In Figure5(a), we can see the success rate results with various conditions. With the options in the simulation, we can change the value of packet data error ratio and packet loss ratio. The packet data error ratio is the possibility of data error happening while delivering the data packet. The packet loss ratio is the rate of packet loss, also known as timeout in the network’s communication. We set up 50 nodes in the simulation and preset the probability of holding appropriate ledger of 100%. With the increase of both packet data error ratio and packet loss ratio, the packet delivery success rate is decreasing gradually. But the system remains highly robust even if the two ratios are at 40%.Figure 5
Success rate and process time compare.
(a)
Success rate with various conditions(b)
Process time of bitcoin-like system (red dots) and our system (blue dots)In Figure5(b), we can see the process time comparison between a bitcoin-like system (red dots) and our system (blue dots). When the number of node is less than 50, the process time of our system is lower. This means our system is suitable to deploy in small scale of nodes in limited areas.


## 3.1. Design Principle

The design principle of LPTS for IoT devices in LPWAN is listed as below and referenced in Figure1:
(1)
Realize point transfer from A to B. The client can be terminals or other user devices(2)
The ledger management can manage the point balance of each user. The ledger should be tamper-proof(3)
LPWAN applied to achieve system availability even in the event of a disaster (achieved in Section5)(4)
Packet delivery mechanism optimization applied to achieve high packet deliver rate even with low communication bandwidth of LPWAN (achieved in Section5)(5)
System should be able to implement into IoT devices and be evaluated in field experimentFigure 1
System architecture.The main purpose of the point transfer system is to realize the function that delivers points from A to B. The users can use their terminal devices like smartphones or integrated devices. The user sends a point transfer request to the network, and the ledger management should be able to verify and start the point transfer process. After the point transfer, the point balance of the sender and receiver should be kept recorded in the ledger system; a certain way of validation should be implemented in the ledger system to protect it from tampering. Because this system has its application in disaster scenarios like earthquakes and tsunamis, it is important to make the nodes to run with battery power and wide area coverage. LPWAN is suitable for these situation and selected for the communication network for the point transfer system. However the bandwidth that LPWAN provides is known to be quite low comparing with modern cellular network or Wi-Fi. A packet delivery mechanism is proposed to optimize the bandwidth consumption, letting the network be valid and fast. Small-scale IoT devices like ARM-based chip sets are known to be energy saving and are suitable to hold the functions of the point transfer system. To verify the above ideas, we use simulations to validate and evaluate the technical performance of the system. In the end, the practical system should be implemented and tested in field experiments.


## 3.2. Algorithm for Distributed IoT Devices

The function of a point transfer system is to make point payment available in normal or disaster situations. The point transfer procedure is shown in Figure1, and the referenced hardware is shown in Figure 2; the user can use a smartphone or a smart device to connect to a node in the point transfer system. When the user chooses to send points from A to B, it sends out a point transfer request to the nodes. The node received the transaction request will broadcast the transaction to the surrounding nodes using its signature. Then, the nodes received the broadcast request will verify the written signature in the packet. If the signature is valid, the node appends its own signature and continues to forward this packet to the next node. When the packet contains enough signatures, this transaction is considered to be true and stored in the ledgers held by the nodes. In LPTS, all the nodes are maintaining the ledger’s consistency. This act involves verifying transmission requests. Algorithm 1 shows the verification logic of a transaction in the point transfer function. When a node receives a transaction request from users, it broadcasts this request to the nodes around, with its own verification signature in the message. The nodes receiving the broadcast request will first verify the sender node’s signature. The node shall add its own signature to the message once the previous signature is verified and forwards the message to other nodes. When message contains enough number of signatures, this transaction is verified, and the record will be added to the received node’s ledger.Algorithm 1: Point transfer function
InitializeM;                  //The number of nodesInitializeL;                    //The ledgerInitializeB0⋯M     //The candidates of received node j’s update blockData:T, total_node, wait_timeResult:request_count, new_segment_count, success_ratefunction transaction_request(T)Receive requested transactionT from the points transfer terminal;ifT is not NULLthenmy_nodeID⟵hostSendT to other nodes;elsemy_nodeID⟵guestReceiveT from other nodes;endifT is not NULLthenX⟵userID of point_sender in T;Y⟵userID of point_receiver in T;Calculate candidates of new balancesPx and Py based on blocks in L0⋯n;my_nodeID⟵"X⟵Px" and "Y⟵Py"fori=1toMdoifwait_time≤thresholdthenReceiveBi as calculated candidate of new balances from other nodes;endendCalculateBu as a majority vote of B0⋯M;Send approval results to the points transfer terminal;n⟵n+1;Ln⟵Bup;endFigure 2
Device examples.
(a)
Payment operation terminal(b)
User device(c)
NodesAlgorithm1 and Figure 3 describes the process of a transaction request (simulation scenario).
(1)
Create N nodes(2)
Create authentication mechanism and forwarding mechanism for each node(3)
Initial a book to keep the transferred points recording, and create initial among of points in the book(4)
Perform point transfer operations according to a random schedule of transaction request(5)
After verifying the transactions, the updated information is written in the ledger bookFigure 3
Ledger operation [29].


## 3.3. Evaluation

The first priority to validate the point transfer system is to make sure the system is stable. We need to evaluate the system’s robustness, since LPWA network may fail in handling large data transmission for the point transfer management. In the results, we compare it with a bitcoin-like ledger system to see the process time and packet deliver success rate is in the safe zone.Based on the system architecture in Figure1, we design an experimental setup that miniaturizes the hardware and uses LPWAN for communication. It is mainly composed of three parts (samples shown in Figure 2): payment operating terminals, user devices, and nodes.
(1)
Node. As shown in Figure4, a node uses Bluetooth module to communicate with smartphones and user devices. The ARM-based computer process all the requests, verification, and packet forwarding. The LPWAN module is used to communicate with other nodes using 920 MHz radio(2)
Payment operation terminal. The payment operation terminal is based on a commercially available microcomputer with integrated BLE module to communicate with the distributed ledger nodes(3)
User device. We built a prototype private key device using a low energy BLE integrated microcomputer to store account IDs and encryption keys. It can communicate with smartphones to send encrypted account IDs or with nodes to check balancesFigure 4
Node configuration.
(a)(b)In Figure5(a), we can see the success rate results with various conditions. With the options in the simulation, we can change the value of packet data error ratio and packet loss ratio. The packet data error ratio is the possibility of data error happening while delivering the data packet. The packet loss ratio is the rate of packet loss, also known as timeout in the network’s communication. We set up 50 nodes in the simulation and preset the probability of holding appropriate ledger of 100%. With the increase of both packet data error ratio and packet loss ratio, the packet delivery success rate is decreasing gradually. But the system remains highly robust even if the two ratios are at 40%.Figure 5
Success rate and process time compare.
(a)
Success rate with various conditions(b)
Process time of bitcoin-like system (red dots) and our system (blue dots)In Figure5(b), we can see the process time comparison between a bitcoin-like system (red dots) and our system (blue dots). When the number of node is less than 50, the process time of our system is lower. This means our system is suitable to deploy in small scale of nodes in limited areas.


## 4. Implementation of Ledger-Based Points Transfer System for Small-Scale IoT Devices in LPWAN

### 4.1. System Design and Prototype

To realize a LPWA-based ledger system in IoT devices, we need to face and solve several problems. First, the LPWA network and Raspberry-Pi devices form a limited platform with low bandwidth network and low processing capability. The operating system and daemon software need to be compact and simplified.Figure4(a) shows the topology of the modules in a node, and Figure 5(b) shows the prototype of a nod device. Table 2 shows the specification of the prototype. The main board in the node is an ARM-based small computer, Raspberry-Pi. It has 1 GB RAM and a Cortex-A53 SoC. In the communication module part, the Bluetooth module talks to the terminals and user devices so they can display the balance and operate the point transfer system. 3G module is not used in this part, but it shows the ability to communicate via cellular network. LPWAN module is used to build the mesh network among the nodes. It can provide wireless connection range up to 400 m and speed in high speed mode up to 50 kbps. We set the communication speed to 50 kbps to maximize the bandwidth.Table 2
Node specification.
ItemsSpecificationProcessor of nodeRaspberry-PiCortex-A53 (ARMv8) 64-bitSoc@1.4 GHz 1 GB RAMCommunication distance (high-speed mode)Maximum 400 mTypical 100 mCommunication speed (high-speed mode)Maximum 50 kbpsTypical 10 kbps


### 4.2. Evaluation

We use the prototype nodes (Figure4) to build the experiment topology. The LPWAN can broadcast one-to-many communications; however, we set up the system to limit the nodes that can receive messages from one node. In the experiment, there are two kinds of topology that applied to the nodes. In Figures 6(a) and 6(b), (a) shows the nodes can communicate with each other without limitation via LPWAN, and (b) shows a preset node topology that limits the packet delivery direction and path among the nodes. In the small-scale experiment, we use 13 nodes, same number as the multihop nodes used in large scale experiment. The small-scale experiment is for evaluating the efficiency of large-scale system. We suppose the system handle 40 nodes in the community area where one node will send messages to an average of 3 nodes in one transmission. This configuration will cause 13 multihopping (forwarding) to keep same messages for every node.Figure 6
Experiment topology.
(a)
Mesh topology(b)
Chain topologyThe evaluation measures process time for the point transfer system in the following steps.(1)
Send a transaction request (“send A to C 100 pts”) to one contact node(2)
Forward the requests to other nodes(3)
The message will be broadcast to all nodes via multihop nodes in LPWAN(4)
Create an additional new block in each node(5)
Each node sends the new block data to other nodes(6)
Each node receives the new block data from other nodes(7)
Each node decides the new block data by majority voting of data from other nodes(8)
Append the new block to the ledger(9)
Return the transaction results and answer the latest balances of A and CIn each node, there is a parameter called “wait time.” It is between steps 2 and 4 to confirm if the communication succeeded with other nodes. The process time results depend on the “wait time.” Figure7 shows the total process time for 44 to 49 trails, with different “wait time.” For example, if “wait time” is 30 s, one of the trail’s process time is about 90 s. This may be caused by communication congestion due to LPWAN’s low bandwidth. Also, we can see that the process time of lower “wait time” tends to have much variation. When “wait time” is at around 40 to 60 seconds, the variation of the process time of a transaction is quite stable, making 40 seconds the top option in selecting “wait time.”Figure 7
Process time result of small scale experiment.


## 4.1. System Design and Prototype

To realize a LPWA-based ledger system in IoT devices, we need to face and solve several problems. First, the LPWA network and Raspberry-Pi devices form a limited platform with low bandwidth network and low processing capability. The operating system and daemon software need to be compact and simplified.Figure4(a) shows the topology of the modules in a node, and Figure 5(b) shows the prototype of a nod device. Table 2 shows the specification of the prototype. The main board in the node is an ARM-based small computer, Raspberry-Pi. It has 1 GB RAM and a Cortex-A53 SoC. In the communication module part, the Bluetooth module talks to the terminals and user devices so they can display the balance and operate the point transfer system. 3G module is not used in this part, but it shows the ability to communicate via cellular network. LPWAN module is used to build the mesh network among the nodes. It can provide wireless connection range up to 400 m and speed in high speed mode up to 50 kbps. We set the communication speed to 50 kbps to maximize the bandwidth.Table 2
Node specification.
ItemsSpecificationProcessor of nodeRaspberry-PiCortex-A53 (ARMv8) 64-bitSoc@1.4 GHz 1 GB RAMCommunication distance (high-speed mode)Maximum 400 mTypical 100 mCommunication speed (high-speed mode)Maximum 50 kbpsTypical 10 kbps


## 4.2. Evaluation

We use the prototype nodes (Figure4) to build the experiment topology. The LPWAN can broadcast one-to-many communications; however, we set up the system to limit the nodes that can receive messages from one node. In the experiment, there are two kinds of topology that applied to the nodes. In Figures 6(a) and 6(b), (a) shows the nodes can communicate with each other without limitation via LPWAN, and (b) shows a preset node topology that limits the packet delivery direction and path among the nodes. In the small-scale experiment, we use 13 nodes, same number as the multihop nodes used in large scale experiment. The small-scale experiment is for evaluating the efficiency of large-scale system. We suppose the system handle 40 nodes in the community area where one node will send messages to an average of 3 nodes in one transmission. This configuration will cause 13 multihopping (forwarding) to keep same messages for every node.Figure 6
Experiment topology.
(a)
Mesh topology(b)
Chain topologyThe evaluation measures process time for the point transfer system in the following steps.(1)
Send a transaction request (“send A to C 100 pts”) to one contact node(2)
Forward the requests to other nodes(3)
The message will be broadcast to all nodes via multihop nodes in LPWAN(4)
Create an additional new block in each node(5)
Each node sends the new block data to other nodes(6)
Each node receives the new block data from other nodes(7)
Each node decides the new block data by majority voting of data from other nodes(8)
Append the new block to the ledger(9)
Return the transaction results and answer the latest balances of A and CIn each node, there is a parameter called “wait time.” It is between steps 2 and 4 to confirm if the communication succeeded with other nodes. The process time results depend on the “wait time.” Figure7 shows the total process time for 44 to 49 trails, with different “wait time.” For example, if “wait time” is 30 s, one of the trail’s process time is about 90 s. This may be caused by communication congestion due to LPWAN’s low bandwidth. Also, we can see that the process time of lower “wait time” tends to have much variation. When “wait time” is at around 40 to 60 seconds, the variation of the process time of a transaction is quite stable, making 40 seconds the top option in selecting “wait time.”Figure 7
Process time result of small scale experiment.


## 5. Extension of Ledger-Based Points Transfer System for IoT Devices in LPWAN

After designing LPTS and building its prototype, we have found some optional optimizations that might benefit the system. The extension of LPTS includes additional security option, packet transmission optimization, and system’s disaster tolerance. The security enhancement option is based on LPTS prototype and evaluated in experiments. The packet transmission optimization and disaster tolerance are evaluated in simulations.We aim to validate and evaluate the proposed point transfer system and its performance in the simulated environment. By using a Python language-powered simulator, we manage to evaluate the proposed system’s performance. This part involves packet success rate under different communication error and loss rate, packet success rate with differentk value in optimization, and packet success under disaster scenario.


### 5.1. Additional Signature for Higher Security

In addition to the nonsignature-based system we tested above, we have also tested a higher security method by adding ECDSA (FIPS 186-3 Digital Signature Standard)-based signatures to the messages. With signature, data packet size is 198 bytes, 134 bytes longer than the 64 bytes nonsignature messages. Figure8 shows the message delivery processes with signatures added to the messages. We added signature to the following steps:
(1)
Transaction requests(2)
New block data (candidates)Figure 8
Message delivery with signature.Figure9 shows the process time of the trails in the similar conditions of the above part. We can see that with signature, the process time becomes longer and has wide variations due to larger packet size and LPWAN’s limitation. The process finishes within 120 s without errors. The overall ledger management is still intact.Figure 9
Process time result with signature.


### 5.2. Function to Optimizing Packet Transmission

By using LPWAN-based communication environment, the bandwidth for the ledger system is limited. According to the simulation of the system, without considering the bandwidth limit, the network needs to handle 1742 packets by generate one transaction. The overall packet size hits about 900 kbit, and with the bandwidth limit of LPWAN which is 50 kbps, it needs about 15 min to complete one transaction. An optimal algorithm is needed to make the system finish one transaction faster and remain tamper-proof.To reduce overall data size, we choose to reduce transmission packet numbers by reducing number of nodes that can forward the packets. We select a number of nodes from all the nodes to offer multihop function to forward packets. All nodes are divided into several clusters to make sure that most of the nodes can join the verification of the transaction request. As shown in Algorithm2 and Figure 10, we use K-means clustering [30] with a preset k, to select multihop nodes. First, we create N nonmultihop nodes (all the nodes). Then, we perform K-means clustering with the location information of each node and select the nodes closest to the output location information to be the multihop nodes (red marked nodes). Finally, the selected nodes are given multihop function to finish preparing the system before running. Because the LPWA network operates in a low bandwidth mode, it is necessary to find a way to further reduce the data traffic in the network. We use K-means clustering algorithm to find center node of each cluster in the whole area. This chosen node is capable of multihopping that can receive and send multiple packets at the same time. The simulator can generate random nodes in a certain area with preset node numbers. Each node has LPWA communication ability to simulate data traffic in the network. In the simulation, we use different sets of multihop node numbers k to cluster all the nodes. By increasing number k, we can evaluate from nonmultihop to fully multihop scenarios. This gives us concepts in different scales to see the best balance between overall system stability and network data traffic consumption.Algorithm 2:Optimized transaction request function
InitializeM;               //The number of nodesInitializeL;                   //The ledgerInitializeB0⋯M;     //The candidates of received node j’s update blockInitializeS;                 //Selected nodesData:T, total_node, wait_timeResult:request_count, new_segment_count, success_ratefunctiontransaction_requestT;Receive requested transactionT from the points transfer terminal;ifT is not NULLthenmy_nodeID⟵hostSendT to other nodes;elsemy_nodeID⟵guest;ReceiveT from other nodes;endifT is not NULLthenX⟵userID of point_sender in TY⟵userID of point_receiver in TCalculate candidates of new balancesPx and Py based on blocks in L0⋯n;my_nodeID⟵"X⟵Px" and "Y⟵Py"fori=1toMdoifwait_time≤thresholdthenReceiveBi as calculated candidate of new balances from other nodes;endendifmy_nodeID not in Sthenfori=1toM and Bi not received doForwardBi;endendCalculateBu as a majority vote of B0⋯M;Send approval results to the points transfer terminal;n⟵n+1Ln⟵BupendFigure 10
K-means clustering example.In Figure11, the two result figures are oriented by k value from small to large. CommandRequests stands for transaction request packet number, and NewSegment stands for transaction packet number generated by transaction requests. In (a), the average number of CommandRequests is at the same level, and the number of NewSegment is from smallest to largest, which means that changing the number of multihop function nodes does not change the number of transaction requests, but affects the overall packets of new blocks for the transaction. Therefore, it is effective reducing the number of multihop function nodes to reduce the overall communication traffic. In (b), at the same time, the average update success rate of new blocks is not 100%, which leads to a reduction in the overall security and integrity of the network. We cannot blindly reduce the k value to reduce the traffic volume. In this simulation, reducing multihop node number to 30, in a 50 overall node number, is a balanced result.Figure 11
Packet reduction results.
(a)
Generated packet number compare(b)
Success rate and insecure requests


### 5.3. Function to against Disaster

According to the design principle of our proposed system. The nodes consume small amount of power and can keep running for a long period of time on battery powers to avoid power shortage. However, there are some inevitable disasters like earthquake and tsunami that can disable or destroy the structure of certain area, meaning the nodes in that area will be offline. In that sense, putting the distributed ledger system in disaster scenarios is important to evaluate its robustness. The communication principle should remain the same with Algorithm1, and the transaction success rate is the result showing the system robustness.When it comes to disaster scenarios, we categorize them into two kinds, single-point node offline and disaster area offline. Figures12(a) and 12(b) show the node topology of the two kinds of disasters. In single-point node offline, the offline nodes will take place in the whole area evenly. In disaster area offline, nodes inside the disaster area will be offline. Figures 12(c) and 12(d) show the results of the two kinds of disaster scenarios. In single-point node offline, with the online nodes decrease gradually, and the nodes participating in the transaction decrease. But the success rate remains at a high level under the online node number which is less half of the overall node number. The same situation happens in the disaster area offline scenario, but we have noticed that when more than 30% of the nodes are offline, the ledger is actually divided into two or more. This means the ledger system is no longer whole, and it leads to security issue. In the tsunami scenario shown in Figure 12(b), the failure area is set to the upper right corner because the ocean region is located at the edge of the installation area. On the other hand, in a volcanic eruption scenario, the failure could occur in other locations like the center of the area. A failure in the center of the area increases the probability that the communication area will be divided into two or more parts. The same situation can be seen in Figures 12(c) and 12(d), as more than 30% of the failures result the area divided. Therefore, it is concerned that the percentage of the failure area is more dominant than the location of the failure area.Figure 12
Disaster scenario evaluation results.
(a)
Single-point node offline(b)
Disaster area offline(c)
Evaluation of single-point node offline(d)
Evaluation of disaster area offline


## 5.1. Additional Signature for Higher Security

In addition to the nonsignature-based system we tested above, we have also tested a higher security method by adding ECDSA (FIPS 186-3 Digital Signature Standard)-based signatures to the messages. With signature, data packet size is 198 bytes, 134 bytes longer than the 64 bytes nonsignature messages. Figure8 shows the message delivery processes with signatures added to the messages. We added signature to the following steps:
(1)
Transaction requests(2)
New block data (candidates)Figure 8
Message delivery with signature.Figure9 shows the process time of the trails in the similar conditions of the above part. We can see that with signature, the process time becomes longer and has wide variations due to larger packet size and LPWAN’s limitation. The process finishes within 120 s without errors. The overall ledger management is still intact.Figure 9
Process time result with signature.


## 5.2. Function to Optimizing Packet Transmission

By using LPWAN-based communication environment, the bandwidth for the ledger system is limited. According to the simulation of the system, without considering the bandwidth limit, the network needs to handle 1742 packets by generate one transaction. The overall packet size hits about 900 kbit, and with the bandwidth limit of LPWAN which is 50 kbps, it needs about 15 min to complete one transaction. An optimal algorithm is needed to make the system finish one transaction faster and remain tamper-proof.To reduce overall data size, we choose to reduce transmission packet numbers by reducing number of nodes that can forward the packets. We select a number of nodes from all the nodes to offer multihop function to forward packets. All nodes are divided into several clusters to make sure that most of the nodes can join the verification of the transaction request. As shown in Algorithm2 and Figure 10, we use K-means clustering [30] with a preset k, to select multihop nodes. First, we create N nonmultihop nodes (all the nodes). Then, we perform K-means clustering with the location information of each node and select the nodes closest to the output location information to be the multihop nodes (red marked nodes). Finally, the selected nodes are given multihop function to finish preparing the system before running. Because the LPWA network operates in a low bandwidth mode, it is necessary to find a way to further reduce the data traffic in the network. We use K-means clustering algorithm to find center node of each cluster in the whole area. This chosen node is capable of multihopping that can receive and send multiple packets at the same time. The simulator can generate random nodes in a certain area with preset node numbers. Each node has LPWA communication ability to simulate data traffic in the network. In the simulation, we use different sets of multihop node numbers k to cluster all the nodes. By increasing number k, we can evaluate from nonmultihop to fully multihop scenarios. This gives us concepts in different scales to see the best balance between overall system stability and network data traffic consumption.Algorithm 2:Optimized transaction request function
InitializeM;               //The number of nodesInitializeL;                   //The ledgerInitializeB0⋯M;     //The candidates of received node j’s update blockInitializeS;                 //Selected nodesData:T, total_node, wait_timeResult:request_count, new_segment_count, success_ratefunctiontransaction_requestT;Receive requested transactionT from the points transfer terminal;ifT is not NULLthenmy_nodeID⟵hostSendT to other nodes;elsemy_nodeID⟵guest;ReceiveT from other nodes;endifT is not NULLthenX⟵userID of point_sender in TY⟵userID of point_receiver in TCalculate candidates of new balancesPx and Py based on blocks in L0⋯n;my_nodeID⟵"X⟵Px" and "Y⟵Py"fori=1toMdoifwait_time≤thresholdthenReceiveBi as calculated candidate of new balances from other nodes;endendifmy_nodeID not in Sthenfori=1toM and Bi not received doForwardBi;endendCalculateBu as a majority vote of B0⋯M;Send approval results to the points transfer terminal;n⟵n+1Ln⟵BupendFigure 10
K-means clustering example.In Figure11, the two result figures are oriented by k value from small to large. CommandRequests stands for transaction request packet number, and NewSegment stands for transaction packet number generated by transaction requests. In (a), the average number of CommandRequests is at the same level, and the number of NewSegment is from smallest to largest, which means that changing the number of multihop function nodes does not change the number of transaction requests, but affects the overall packets of new blocks for the transaction. Therefore, it is effective reducing the number of multihop function nodes to reduce the overall communication traffic. In (b), at the same time, the average update success rate of new blocks is not 100%, which leads to a reduction in the overall security and integrity of the network. We cannot blindly reduce the k value to reduce the traffic volume. In this simulation, reducing multihop node number to 30, in a 50 overall node number, is a balanced result.Figure 11
Packet reduction results.
(a)
Generated packet number compare(b)
Success rate and insecure requests


## 5.3. Function to against Disaster

According to the design principle of our proposed system. The nodes consume small amount of power and can keep running for a long period of time on battery powers to avoid power shortage. However, there are some inevitable disasters like earthquake and tsunami that can disable or destroy the structure of certain area, meaning the nodes in that area will be offline. In that sense, putting the distributed ledger system in disaster scenarios is important to evaluate its robustness. The communication principle should remain the same with Algorithm1, and the transaction success rate is the result showing the system robustness.When it comes to disaster scenarios, we categorize them into two kinds, single-point node offline and disaster area offline. Figures12(a) and 12(b) show the node topology of the two kinds of disasters. In single-point node offline, the offline nodes will take place in the whole area evenly. In disaster area offline, nodes inside the disaster area will be offline. Figures 12(c) and 12(d) show the results of the two kinds of disaster scenarios. In single-point node offline, with the online nodes decrease gradually, and the nodes participating in the transaction decrease. But the success rate remains at a high level under the online node number which is less half of the overall node number. The same situation happens in the disaster area offline scenario, but we have noticed that when more than 30% of the nodes are offline, the ledger is actually divided into two or more. This means the ledger system is no longer whole, and it leads to security issue. In the tsunami scenario shown in Figure 12(b), the failure area is set to the upper right corner because the ocean region is located at the edge of the installation area. On the other hand, in a volcanic eruption scenario, the failure could occur in other locations like the center of the area. A failure in the center of the area increases the probability that the communication area will be divided into two or more parts. The same situation can be seen in Figures 12(c) and 12(d), as more than 30% of the failures result the area divided. Therefore, it is concerned that the percentage of the failure area is more dominant than the location of the failure area.Figure 12
Disaster scenario evaluation results.
(a)
Single-point node offline(b)
Disaster area offline(c)
Evaluation of single-point node offline(d)
Evaluation of disaster area offline


## 6. Conclusion

Point transfer system merging with LPWAN communication technology provide us a new way to make use of small IoT platforms. LPWAN provides low-power and wide-area radio communication network to realize end-to-end connection. Third-party points transfer system can now overcome disasters to become a financial solution and application in local areas. The decentralized design principle of our proposed system solves the traditional centralized system issues like asset data tampering and low robustness. We also proposed an optimal solution to reduce packet congestion in LPWAN and tested it and disaster scenario robustness in simulations. At last, we implemented the system in small-scale IoT devices and made experiment to prove our design which is valid and robust.



---

*Source: 3027978-2022-08-19.xml*