A Blockchain System for TDMA-Based Tactical Wireless Networks With Constrained Resources

This paper proposes a blockchain system with a consensus algorithm and timeslot allocation policy for TDMA-based tactical wireless networks with constrained resources. A blockchain can serve as a distributed database that ensures all nodes can store the same data even in unreliable network environments. Blockchain technology has numerous benefits, such as decentralization, tamper resistance, traceability, and audibility. Due to these characteristics, the application range of blockchains has dramatically expanded from cryptocurrency, financial services, risk management, and IoT to various services in both public and non-public domains. In addition, there has been an increasing demand for using blockchain technology in wireless network environments. Unlike wired networks, communication resources in wireless networks for data transmission and reception are relatively limited; as such, it is necessary to design a consensus algorithm with low resource consumption and an efficient resource allocation policy for these environments. The proposed system allocates timeslots to nodes based on their contribution to blockchain management, which prevents nodes from participating in an unnecessary competition for block generation, thereby preventing the associated waste of energy. We could verify the proposed system’s practicality through numerical analysis and computer simulations under various conditions.


I. INTRODUCTION
Blockchain technology has attracted widespread attention in both industry and academia since Bitcoin [1], the first cryptocurrency, was a considerable success [2], [3]. Applications for the blockchain are rapidly expanding from cryptocurrencies to various services for public, and non-public domains [4], [5], [6], [7]. A blockchain can be seen as a balanced integration of several existing technologies such as cryptographic hash, digital signature, and distributed consensus mechanism, P2P network technology rather than the birth of brand new technologies that did not exist before [8]. One of the main characteristics of blockchain technology is that data stored in the blockchain is practically impossible to modify and change by intentional malicious acts and operational mistakes. This feature makes it very useful for services where The associate editor coordinating the review of this manuscript and approving it for publication was Young Jin Chun . data must not be changed to ensure traceability regarding data transmission and reception. This makes blockchain technology very attractive, mainly when used in environments with a risk of stored data being changed maliciously, such as in military operations.
Blockchain technology has been mainly applied to wired networks that can transmit large amounts of data with low error rates thanks to their stable connectivity and wide bandwidth. As the IoT, which tends to be made up of various types of low-power consumption mobile equipment, has become widely distributed, it becomes increasingly important to try to apply the advantages of blockchain technology to wireless environments [9]. Accordingly, researchers are actively looking to apply blockchain technology in wireless networks where the connection between nodes is dynamic due to node mobility and poor channel conditions. This technology also seems well-suited to wireless tactical networks; the wireless networks operated for military VOLUME 11, 2023 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ purposes in tactical situations, i.e., during combat [10]. Tactical networks technically include all the characteristics of wireless networks. However, in terms of operation, some features differ from typical wireless networks [11], [12]. First, channel conditions in tactical wireless networks are worse than those in typical wireless networks. Because the physical destruction of equipment by the enemy must be considered when operating these networks, points that are safe from enemy observation but have conditions that lead to poor communication performance are preferred over points that are good for communication but are not safe from enemy observation. Second, strong countermeasures against enemy attacks on the network, such as jamming and eavesdropping, are required. Third, nodes in the same network tend to move similarly, i.e., there is group movement. Fourth, a leader node usually exists in tactical networks to maintain the chain of command in military operations. When the leader node is lost, a new leader node is elected from among the follower nodes. In addition, traffic is mainly directed to the leader node. Fifth, the traffic type used in tactical wireless networks is almost always broadcast because situational awareness is essential for successful military operations.
To effectively utilize blockchain technology in wireless tactical networks, blockchain systems must be designed considering the characteristics of tactical networks (described above). However, to the best of our knowledge, there has been no research into blockchain systems that considers the operational features of tactical networks. Therefore, we propose a blockchain system for time division multiple access (TDMA) based wireless tactical networks. TDMA is widely used in military applications such as in the single ground, and airborne radio systems (SINCGARS), enhanced position location reporting systems (EPLRS), Link-16 and Link-22 systems since TDMA can easily ensure QoS by employing a channel reservation mechanism [13], [14].
Tactical data for military operations require a high degree of accuracy and reliability. However, it is challenging due to poor channel conditions in tactical networks and the enemy's malicious acts that disrupt communications. It is the motivation for our research. The proposed blockchain system guarantees data integrity by storing essential tactical data in the blockchain through efficient methods for generation, propagation, and validation of block header.
The contributions of this paper are as follows: First, considering the unique characteristics of military networks, we proposed a blockchain system for TDMA-based tactical wireless networks in which each node has exclusive and periodic opportunities to access a channel. This system can ensure the integrity of essential data from friendly forces and block deceptive data from an adversary during a military operation. Second, unlike the existing consensus algorithm that reaches consensus through the validation of the block propagated, we design a consensus algorithm to reduce network traffic by generating and validating only the block header instead of the block. Third, the practicability of the proposed system was confirmed by analyzing its performance and comparing it with state-of-the-art schemes through numerical analysis and extensive simulations in tactical network conditions. The rest of this paper is organized as follows. In Section II, we review existing studies on blockchain systems in wireless networks. Section III presents the system model for the system proposed in this paper, while Section IV describes the proposed system in detail, including an example operational scenario. Section V shows a performance analysis of the proposed system. Finally, we conclude this paper in Section VI.

II. RELATED WORKS
There are previous studies that have applied blockchain technology in wireless networks. Brincat et al proposed using decentralized anonymous access control and congestion avoidance in WiFi networks, their system exploited certain features of blockchain technology such as anonymity and the consensus mechanism from PoW (Proof of Work) in an untrustworthy environment [15]. Their work showed that using blockchain technology in wireless networks can be helpful. Their proposed approach was able to regulate wireless access to resources while maintaining anonymity and improving the fairness of existing congestion avoidance schemes.
Hsiao and Sung integrated blockchain technology into the transmission of sensor data and, in this way, were able to enhance transmission reliability [16]. However, some issues have come out of using this kind of approach such as transmission delays caused by cryptographic processing and low transmission efficiency as the amount of data transmitted increases.
Chanana et al proposed a blockchain-based secure model for transmitting sensor data in Wireless Sensor Networks (WSN) [17]. WSNs consist of three layers: sensor, gateway, and base station (BS); in this scheme, the gateway acts as a blockchain node. The gateway nodes then generate blocks using the data received from sensors before sharing them with other gateway nodes. The BS also acts as a blockchain node, similar to the gateway nodes. The proposed model improved the security of the received sensor data by exploiting the immutable feature of data stored in these blocks. Unfortunately, a performance analysis for this model was not conducted.
Meanwhile, several efforts have been made to analyze the performance of blockchain technology that is run on a wireless network. The impact of the wireless blockchain on the network's communication resources, while using various representative consensus mechanisms such as PoW, PBFT, and Raft, was analyzed in terms of communication complexity, spectrum requirements, transmission power, throughput, and delay time [18].
One study [19] presented an analytical model for a wireless IoT system that used blockchain technology. This was done to find the optimal node density of such a network to maximize the overall throughput. In addition, the security performance of the proposed system against three typical attacks, eclipse attack, random link attack, and random function node attack, was analyzed in terms of overall communication throughput.
Anand et al analyzed the performance of a PoW blockchain composed of mobile nodes in a wireless network [20]. Their work considered what happens when blockchain and network parameters such as the block interval, the number of minders, node mobility, transmission power, and network density become large in these systems. The comprehensive analysis revealed that the influence of these wireless parameters cannot be ignored and can significantly impact the actual performance of the associated blockchain.
The security performance of a Raft-based wireless blockchain network was studied in the presence of malicious jamming [21]. Raft is a representative consensus mechanism often used for wirelessly connected, low-complexity devices in distributed systems with unreliable nodes. In this setting, the blockchain transactions were modeled as part of a wireless network and were composed of the network's uplink and downlink transmissions. The analytical model guides the practical deployment of wireless blockchain networks.
In [22], the authors proposed a novel consensus algorithm for wireless blockchain networks that do not guarantee the reliable communication. They did focus on designing a fast consensus protocol. The protocol consists of four phases: leader election, block proposal, block validation, and chain update. The leader elected by competition generates and disseminates a block to nodes. The local blockchain maintained by each node is updated if σ fraction of validators agrees to the block proposed by the leader. Assuming that the leader node produces valid blocks, the algorithm's time complexity is O(logn + k), where n and k are the numbers of nodes and consensuses, respectively. However, the processing procedure for the case where the leader node cannot generate a valid block for any reason is not presented. In particular, the proposed algorithm requires significant time to reach a consensus when the leader node has yet to receive all the data to be included in the block.
As can be seen, there has been some research into blockchain systems and their performance in wireless networks. However, no studies have looked at the implementation of blockchain technology in tactical wireless networks and considered the operational characteristics of these networks.

III. SYSTEM MODEL
In this paper, we consider wireless tactical networks that apply a centralized TDMA-based scheduling algorithm. All nodes are equipped with omni-directional antennas and are within a 1-hop distance. When a node sends data, all neighboring nodes can receive this transmission. However, some neighbors will not always receive data due to imperfect channel conditions.
There are two types of node: leader nodes (LN) and follower nodes (FN). The LN is selected from among all the follower nodes. The role of the LN is to authenticate transmissions for the FNs and to assign a timeslot to each FN. If the current LN can no longer function as the leader node, a new LN is elected from among the FNs.
The structure of TDMA is shown in Fig. 1. The superframe is divided into three periods: a beacon signal period, a Slot Allocation Information (SAI) period, and a frame period. In the beacon signal period, the LN transmits a beacon signal to inform the other nodes about the start of a superframe. The SAI is transmitted by the LN during the SAI period, this includes the slot allocation information for all nodes during that superframe period, as such, the SAI should be shared with all nodes. A superframe includes f frames, and each frame contains t timeslots. Each timeslot is assigned to the appropriate node according to the SAI.
Meanwhile, there are three types of data transmitted in a timeslot: D c , D f , and D r . The different classifications depend on whether the data is re-transmitted or not, and whether the value should be stored. The first type, D c , is data that is not worth storing, such as control messages for flow control, error correction, etc. The second type, D f , is data worth storing that has never been transmitted before. The third type, D r , is data worth storing that has been transmitted before. That is, data worth holding that is being re-transmitted at the request of the receivers. Of these three types of data, only the second type is saved in a specific block of the blockchain. In other words, not all data transmitted in a timeslot is included in a block to be added to the blockchain.

IV. THE PROPOSED BLOCKCAHIN SYSTEM
This chapter describes the proposed system in detail, including the structure of the block header, block generation and propagation, block verification process, fork resolution, and operational scenarios. Table 1 summarizes the notations and abbreviations used in this paper.
A. OVERVIEW OF THE PROPOSED SCHEME All nodes participating in the network only transmit data in the slots allocated by the LN. All data transmitted in the same frame will be included in the same block. In other words, one block is generated per frame. Nodes must compute hash values that satisfy specific conditions to generate a valid Block Header (BH). A node that has generated a valid BH can then generate a block and append it to its own copy of the blockchain. Then, the node is ready to propagate the BH to neighboring nodes in its next slot. Note that only the BH is propagated, not the entire block. At a given time, multiple nodes can simultaneously generate a block from the same data. However, neighboring nodes cannot receive several BHs that come from the same data at the same time, this is because one BH will be the first to be allocated a transmission time among the nodes that generated a block from the same data. A node that successfully generates a valid block waits for its slot to transmit the BH. If a node waiting to transmit this BH in its slot receives another valid BH for the same data, it abandons the propagation of its BH and deletes that BH. Neighboring nodes receiving the valid BH verify that BH and then generate a block from it. Finally, the nodes append the block to their copy of the blockchain that they maintain.
The LN allocates slots to each node based on the number of successful BHs propagated within a predetermined time. If a node does not meet the set criteria for the number of BHs it should have succeeded in propagating, the LN withdraws the slot allocated to that node. On the contrary, if the node meets the criteria, the use of the currently allocated slot is continuously guaranteed. The proposed system guarantees the stable operation of the blockchain by allocating timeslots according to the contribution of each node to blockchain management. Also, nodes that successfully propagate BHs do not participate in the block generation competition for a certain period, thereby reducing energy wastage.

B. BLOCK HEADER STRUCTURE
The BH itself consists of three sets of block metadata. In the first set of metadata, there is a ''previous block hash'' that links the current block with the last block in the blockchain, there is also a ''current block hash'' that guarantees the integrity of the block header. The second set includes difficulty and nonce information that is associated with the mining. The third set consists of the Merkle tree root and BDI (Block Data Indicator) information, these are used to efficiently summarize all the data in the block.
The difficulty field's value in the BH measures how difficult it is to find a hash below a given target. A high difficulty value means that it will take more computing power and time to find a nonce, this makes the network more secure against attacks that modify data. The difficulty value is also included in the SAI and periodically transmitted from the LN to FNs. The LN adjusts the difficulty value in each superframe to reflect the propagation rate of the BH. If the rate becomes too fast, the difficulty value is increased, and if the rate becomes too slow, the value is decreased.
A nonce is a pseudo-random number used as a counter in the BH generating process. A node must guess the right nonce to find a hash complying with the specific requirements.
The Merkle root results from an iterative hash operation to ensure that the data contained in the Merkle tree is undamaged and unaltered. A frame with ts timeslots can be expressed a Merkle tree with ts leaves. Each leaf's value is the data (of type D f ) transmitted or received in the corresponding timeslot. If there was no data or the data that was not of the D f type in the timeslot, a pre-defined meaningless data value is assigned to that leaf.
Meanwhile, the block data indicator (BDI) indicates the location of the timeslot in which D f type data was transmitted or received as a bitmap. Each node has a BDI for every frame and can check whether data has been properly received by comparing it with the BDI of neighboring nodes. If a node recognizes that it has not received certain data that was transmitted in a specific slot, it can request retransmission of that data from the node that owned that slot. A node that has received the block header can easily check whether the D f type data it has is missing or has been changed by using the Merkle root and BDI.
Each node calculates a Merkle root every frame, as shown in Fig. 2.

C. GENERATION AND PROPAGATION OF A BLOCK HEADER
A node can be in one of four states: Mining state (S M ), Waiting state (S W ), Transmit state (S T ), and Resting state (S R ).
• Mining state (S M ): The node is computing the hash to generate a BH. After completing this BH generation, the node transitions to S W . If it receives a valid BH from neighboring nodes, the node stops computing the hash in progress and starts computing the next BH. • Waiting state (S W ): When the node has completed its generation of a BH, it waits until its allocated slot becomes the current slot and then transitions to S T . If it receives a valid BH from the neighboring nodes before its turn, the node transitions to S M .
• Transmitting state (S T ): The node transmits the BH it has generated and transitions to S R on completion • Resting state (S R ): The node no longer participates in the competition for BH generation but validates any received block header. When a new superframe starts, it transitions to S M . Fig. 3 shows the state transition diagram for the nodes in our network.

D. BLOCK HEADER VALIDATION
To illustrate this process, we assume that node D has received a BH from node S. We also denote the number of non-zero elements in the BDI from node N as |BDI N |. The verification process consists of two steps.
The first step is to compare |BDI D | with |BDI S |, which is included in the received BH S . If the BDIs match, it moves to the second step. If |BDI D | > |BDI S |, node D ignores the received BH, i.e., BH S . If |BDI S | > |BDI D |, node D requests retransmission from neighboring nodes to catch up with the missing data.
The second step is to compare MR D with MR S , which is included in the received BH. If MR D and MR S match, node D considers the received BH S to be valid. It then generates BK D using the received block header BH S , and BK D is added to its own blockchain, BC D . If the MRs are unmatched, node D generates BH D and transmits it in its own slot. The two blocks, BK D and BK S , will be added to BC D and BC S , respectively. This means there is a fork in the blockchain. We will explain the resolution to this fork in Section IV-F.

E. CONTROL FOR BLOCK HEADER GENERATION
T M is defined as the time it takes to find a valid hash. T M can be adjusted using the difficulty value that is transmitted by the LN in the SAI period. T W is defined as the time it takes for its own slot to become the current slot after that node generates a BH. The time it takes for a node to generate a BH and get a transmission opportunity for that, T P , is defined as the sum of T M and T W . Assuming that slots are randomly assigned to all nodes, T W is half the frame length. As a result, T P can be expressed as T M + L f 2 . In the proposed system, the node must successfully propagate a valid BH at least once during a superframe period to continuously maintain the slot allocated to it. In other words, the node only needs to propagate a valid BH once during the superframe period. Thus, a node that successfully propagates a BH does not need to participate in the competition for BH generation until a new superframe starts.
We assume that a node that has successfully propagated a BH does not participate in the competition during the same superframe. At the beginning of a superframe, all nodes participate in the competition to propagate the next BH. Thus, the probability of success in the first round can be expressed as 1 N n . During the same superframe, the number of nodes participating in the competition decreases by 1 each time the competition to generate a new BH begins. Thus, the probability of failure in k consecutive rounds, p k f , is as follows: The probability of success by the k th competitions is calculated as follows: The average time it takes a node to successfully propagate a BH, T BH , can be expressed as follows: From the perspective of the blockchain network, a new BH is propagated for every T BH . Therefore, the T BH must be adjusted so all nodes can propagate a BH at least once in the same superframe. In other words, the following equation should be approximately satisfied.
The above equation can be satisfied by adjusting the T M by setting the appropriate difficulty value.

F. FORK RESOLUTION
A blockchain fork can happen in the following two cases in the proposed system.
• Case I: Transmission of BH with incorrect BDI • Case II: Transmission of BH with correct BDI but incorrect MR Case I occurs when the received signal is not properly demodulated due to the inherent characteristics of the wireless channel (e.g. noise, interference). One the other hand, VOLUME 11, 2023  Case II is caused by incomplete demodulation due to poor channel conditions or by data integrity being compromised by a malicious attack.
The forks of two cases are resolved when subsequent BH are added and one of the chains becomes longer than the alternatives. Note that the blocks are not transmitted and each node should generate the blocks using the received BH. Therefore, nodes that do not have all the data for block generation request to retransmit that data with a higher power level or improved error correction rate.
The forks of two cases are resolved when a subsequent BH is added and one of the chains becomes longer than the alternatives. Note that the blocks themselves are not transmitted and each node should generate the blocks using the received BH. Therefore, nodes that do not have all the data for block generation request to have that data retransmitted with a higher power level or an improved error correction rate. Fig. 4 shows the procedure for fork resolution in the proposed system.
An example of the fork resolution procedure for Case I is as follows. In this example, node A did not receive all transmitted data and thus had an incorrect BDI.

i)
A | is smaller than its own |BDI |. Therefore, they discard the BH  A with an invalid BDI that is different from the BDIs of other nodes. respective BCs. However, node A confirms the missing data by comparing BDI

5) Node
A requests retransmission of the missing data from neighboring nodes. 6) Neighboring nodes retransmit the missing data to node A. 7) Node A, having received all missing data, verifies BH An example of the fork resolution procedure in Case II is as follows. In this example, node A receives data that contains errors and thus has an incorrect MR.
1) Node A propagates BH    Fig. 6 shows a simplified data flow for the Case II example of fork resolution.

G. OPERATIONAL SCENARIO
In this subsection, we go over a typical operational example for the proposed system. Fig. 7 is a conceptual flow diagram. In the example, we assume that a frame consists of 3 timeslots and a superframe consists of a beacon, SAI period, and three frames. Initially, the timeslots in the frame are allocated to each node. The slot allocation can be changed by the LN during the SAI period.

V. PERFORMANCE ANALYSIS
In this section, we analyze the performance of the proposed system by looking at the nodes' ratio of resting time per superframe and the probability that a fork will occur. In the simulations, we assume a typical tactical wireless network for the squad units in which the number of members is under 10, including the squad leader. We consider a frame that consists of 10 timeslots and a superframe that consists of 10 frames. All nodes, including a leader node, participate in the blockchain network. Each node is allocated one timeslot for each frame.
The average T M can be set by adjusting the difficulty value. It is assumed that some nodes may not receive data due to poor channel conditions. The results are given as the average value from 1,000 experimental iterations. Fig. 8 shows the T R from a single node's point of view as a ratio of the superframe time according to T M for various networks with different numbers of nodes, N n . The ratio gradually decreases as T M increases and as N n increases. This is because as T M increases, the time required to generate a BH increases. While as N n increases, the competition for BH propagation intensifies, increasing the time it takes to propagate a BH successfully. Fig. 9 shows the average number of BHs propagated by a single node per superframe according to T M for various networks with different numbers of nodes, N n .

A. EFFECT OF N n AND T M ON T R
The simulation results with varying N n and T M are consistent with results derived from Eq. (4). The figure shows that when T M is below a certain level, the average remains at one per frame. This is because a node propagating a BH successfully stays in the S R state until a new superframe starts. However, when T M increases above a certain level, the average starts to become less than one, as T M increases further, the average number gradually decreases further. The higher the T M , the higher the safety of the blockchain, but the lower the block throughput. In addition, each node must propagate one BH on average during the superframe to retain its allocated slot. Therefore, it is necessary to set a proper T M . The proposed system can adjust T M by setting an appropriate difficulty value.   Fig. 10 shows the probability of a fork in the node's blockchain according to the data reception success probability and the number of pieces of data to be included in a block, N d . As the reception success probability increases, the probability of a fork occurrence decreases. Also, as the number of data to be included in the block increases, the probability of a fork occurrence increases. The smaller the number of data, the higher the probability of reception success, the lower the probability of a fork occurrence. However, the probability of a fork occurrence is not significantly low. This means that a forks can occur often in the blockchain. However, these forks are naturally resolved by receiving a normal BH from a neighboring node. Fig. 11 shows the probability, P Corr BH , that at least one node may propagate a correct BH according to data reception success probability. The higher the reception probability, the higher the probability that there is a node to generate the correct BH. Also, the probability increases as N n increases. When the reception probability is high and the number of nodes is large, P Corr BH rapidly increases. On the other hand, even if there is currently no node capable of generating a correct BH, each node knows that the status of unreceived FIGURE 11. Probability that there is a node to generate the correct BH in a competition, P Corr BH .

B. EFFECT OF RECEPTION PROBABILITY AND N d ON FORK OCCURRENCE
data is the cause of incorrect BH generation. Thus, a node will soon be able to propagate a correct BH after the proper retransmission procedure.

C. EFFECT OF DATA RETRANSMISSION
In the proposed system, nodes should receive all data in a block to generate a valid block. A node requests the retransmission of unreceived data to a neighbor node, which causes energy consumption. This subsection analyzes the average number of retransmissions required until a node successfully receives a packet. Let P s be the transmission success probability when data is transmitted to the node with the worst channel conditions. The transmission node would receive a request for retransmission of the packet from nodes that failed to receive it. The transmission node retransmits the packet until all neighbor nodes receive the packet successfully. We can calculate the average number of retransmission, N r , as follows: Fig. 12 shows N r according to P s . As shown in the figure, N r decreases as P s increases. In addition, N r is smaller than 2 if the P s is higher than 0.5. If the channel condition is not very poor, the retransmission's effect is insignificant.

D. COMPARISON WITH EXISTING ALGORITHMS
We compare the proposed system with the algorithms in [22] and [23], called Comparison 1 and Comparison 2. For a fair comparison with the proposed system, in the comparison algorithm, we assume that the algorithms have successfully elected the leader node and that various control packets transmitted in the block validation procedure are transmitted without error. Fig. 13 shows the probability that a valid block, including all packets transmitted in a specific frame, is generated successfully in the first round.
As we can see, the probability of success in the proposed system is much higher than that of the comparison algorithms. The proposed system allows any node to generate  block headers. However, only the leader node can generate blocks in the comparison algorithms. It is the reason why the proposed system shows a higher success probability than the comparison algorithm.

VI. CONCLUSION
This paper proposes a blockchain system in TDMA-based tactical wireless networks. The proposed system allocates timeslots to nodes according to their contributions to blockchain operation. This means nodes with good contributions do not need to participate in the competition for generating the block header. In addition, only the block header is propagated, and block generation from the received header is performed at each node. These features of our approach improve the energy efficiency of blockchain operation, allowing more prudent use of the limited wireless resources. Meanwhile, forks in the blockchain can occur due to data inconsistency between nodes under poor channel conditions. However, our system can swiftly resolve this problem by retransmitting missing data and using the longest chain selection strategy. We confirmed the practicality of the proposed system through various simulations. As a result, VOLUME 11, 2023 the proposed system is expected to be effectively applied to tactical wireless networks to enhance common situational awareness and improve the reliability of the received data.