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

Distributed ledger technology is becoming popular these days because of its high con ﬁ dentiality, 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 ﬁ eld, 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 tra ﬃ c and build a simulator to evaluate its performance. Moreover, we have implemented the system and evaluated in ﬁ eld experiment.


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 Blue-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 performed The rest of this paper is organized mainly into three parts as follows. In Section 2, 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.

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.
Most 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].

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 Figure 1: (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 tamperproof (3) LPWAN applied to achieve system availability even in the event of a disaster (achieved in Section 5) (4) Packet delivery mechanism optimization applied to achieve high packet deliver rate even with low communication bandwidth of LPWAN (achieved in Section 5) (5) System should be able to implement into IoT devices and be evaluated in field experiment 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 2 Wireless Communications and Mobile Computing 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 Figure 1, 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 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

Wireless Communications and Mobile Computing
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 Figure 1, 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 Figure 4, 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 balances In Figure 5(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%.
In Figure 5(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.

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. Figure 4(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 920 MHz ratio module

Evaluation.
We use the prototype nodes ( Figure 4) 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. The 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

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

Request for transaction
Private key Public key LPWA LPWA Node1 Node2

LPWA
Private key Public key Private key Public key Private key Public key     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 different k value in optimization, and packet success under disaster scenario.

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     Figure 8 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 9 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.

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 Algorithm 2 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.
In Figure 11, 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.

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 Algorithm 1, 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. Figures 12(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.

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