Modeling and Analysis of Market Blockchain-based Data Trading in NB-IoT Networks

Modeling and Analysis of Market Blockchain-based Data Trading in NB-IoT Networks

Abstract

Mobile devices with embedded sensors for data collection and environmental sensing create a basis for a cost-effective approach for data trading. For example, these data can be related to pollution and gas emissions, which can be used to check the compliance with national and international regulations. The current approach for IoT data trading relies on a centralized third-party entity to negotiate between data consumers and data providers, which is inefficient and insecure on a large scale. In comparison, a decentralized approach based on distributed ledger technologies (DLT) enables data trading while ensuring trust, security, and privacy. However, due to the lack of understanding on the communication efficiency between sellers and buyers, there is still a significant gap in benchmarking the data trading protocols in IoT environments. Motivated by this knowledge gap, we introduce a model for DLT-based IoT data trading over the Narrowband Internet of Things (NB-IoT) system, intended to support massive environmental sensing. We characterize the communication efficiency of three basic DLT-based IoT data trading protocols via NB- IoT connectivity in terms of latency and energy consumption. The model and analyses of these protocols provide a benchmark for IoT data trading applications.

Distributed Ledger Technology, Blockchain, Data Trading, Internet of Things (IoT), NB-IoT, Smart Contract, Smart City.

I Introduction

In 2025, the volume of sensing data generated by personal IoT devices is expected to reach 79.4 ZB globally[1]. Many attempts have been made to improve and adapt business workflows to exploit the availability of IoT data[2, 3]; among these, IoT data trading is the most popular approach. Various services for trading of IoT data are emerging, connecting various devices and distributed IoT data sources, thereby facilitating data providers to exchange their data [4].

Interesting use cases for data trading include public transport systems, for example, the bus network in Aalborg, Denmark. In these systems, the density of personal travel card swipes at specific bus stations could be useful information, not only to the administration of transport systems, but also to the local taxi companies. The taxi companies benefit from the data of anomalous passenger traffic patterns for the purposes of improving ride-sharing and private services[5]. Also, analyzed traffic data of passengers can be collected via IoT infrastructure and recommendation services to taxi companies can be sold. Besides, drivers can exchange information about the traffic status of a particular street with others to avoid traffic jams or to exchange green house gas emission information with manufactures. Hence, IoT data can be considered as a tradable digital asset.

Traditional trading systems (e.g. Paypal) feature a single point of failure, the lack of trust, transparency, and incentive for data trading, which is preventing the availability of digital information from data providers to customers. On the other hand, Distributed ledger technologies (DLTs) and Blockchains1 support immutable and transparent information sharing among involved untrusted parties [6]. Outside of its role in financial transactions, DLTs are seen as a key enabler for trusted and reliable distributed monitoring systems. The authentication process for DLTs relies on consensus among multiple nodes in the network[7]. In Blockchain-enabled IoT networks [8], transactions can include sensing data, or monitoring control messages, and these are recorded and synchronized in a distributed manner in all the participants of the system. These participants are called miners or peers and, in some specific DLTs, users are charged a transaction fee to deploy and execute transactions.

In addition, DLTs allow the storage of all transactions into immutable records and every record is distributed across many participants. Thus, security in DLTs comes from the decentralized operation, but also from the use of strong public-key cryptography and cryptographic hashes. The benefits of the integration of DLTs into IoT data trading systems include: i) guarantee of immutability and transparency for environmental sensing data, ii) removal of the need for third parties, iii) development of a transparent system for heterogeneous IoT data trading networks to prevent tampering and injection of fake data from the stakeholders[9].

With the spread of ubiquitous marketplaces, it became relevant to explore the use of IoT data trading in marketplace environments. For instance, in [10], Gupta et al. introduced the architecture for a dynamic decentralized marketplace for trading IoT data. The approach involves a 3-tier design: 1) provider, 2) broker and 3) consumer. The use of DLTs in their work is primarily to manage the terms of agreement between involved parties. Additionally, a reputation system is used in the design to penalize the participants and reduce their rating. Bajoudah et al. present a marketplace model and architecture for the trading of IoT streaming data in [11]. Within their work, periodic checkpoints during data exchange are introduced to limit fraudulent activity on either side. In [12], Missier et al. propose another marketplace, where streams of IoT data are the main assets traded utilizing Oracles for the off-chain queries. Xiong et al. [13] present a trading mode based on smart contracts. It incorporates machine learning to guarantee fairness of data exchange and utilizes arbitration institution to deal with the dispute over the data availability in the data trading. However, the arbitration institution in the trading mode is a trusted entity of trading parties.

The related work indicates a gap in terms of: 1) a benchmark for IoT data trading, and 2) analysis of the cost of IoT data trading in terms of communication, specifically in city-level networks. The efficiency of a Blockchain-based data trading protocol is a major concern for data traders. The futures markets are highly dynamic and low latency trading is critical to to maximize the efficiency of the the marketplace. However, currently there is a lack of general framework that provides a guideline for the use of trading protocols based on a set of neutral and commonly accepted rules. A proper benchmark helps the interested parties to understand the tradeoffs in Blockchain-based systems and the associated performance indicators.

In this paper, first, we design a DLT-based trading system for exchanging IoT data. We have chosen the NB-IoT standard [15] as the underlying connectivity solution, as it is seen by the mobile operators as a major candidate to dominate wide-range connectivity for future smart cities. One of the reasons for this is that, unlike other IoT technologies, it is able to offer symmetric uplink/downlink throughput, which is a feature essential from the viewpoint of a DLT [16, 7]. The proposed trading system includes the following IoT data trading protocols; General Trading (GT), Buying on Demand (BoD), and Selling on Demand (SoD). Here we use the term ”on demand” from the viewpoint of the smart contracts that implement the transactions between buyers and sellers. Each trading protocol is customized for different scenarios. GT could be considered as the usual trading protocol in data marketplace, while the BoD and SoD are protocols used to support particular demands from either sellers or buyers.

The analysis and simulation results show that the GT protocol has outstanding performance in terms of latency and energy consumption; however, it requires mechanisms to guarantee the continuous availability of data. On the contrary, the BoD protocol can be adapted in Vehicle-to-Infrastructure (V2I) networks, where vehicles can trade their emission information with manufactures. Finally, the SoD protocol is particularly useful when customers are interested in collecting specific data as soon as it is available on the market, for example, in the for of updates. It can also be deployed in Vehicle-to-Vehicle (V2V) networks where the drivers want to buy traffic jam information of a specific street from other vehicles on the road. Clearly, SoD protocols, on their own, would face situations in which the data is no longer available for customers after the initial advertising phase. In practice, the three trading protocols present interesting synergies and can be implemented together in a single system, which will select the best one based on the actual situation.

The contributions of this paper can be stated as follows. First, we present a solution for systematic DLT-based IoT data smart trading towards city-level networks using NB-IoT connectivity. Next, we propose three IoT data trading protocols namely General Trading (GT), Buying on Demand (BoD), and Selling on Demand (SoD). The cost model of each trading protocol is derived and analyzed along with NB-IoT connectivity. Both resources consumed by executing DLT/smart contracts and NB-IoT devices are investigated. Finally, the analysis and the associated experimental results provide a benchmark for data trading protocols in wide-area IoT networks.

The remainder of this paper is organized as follows. In the next section, we outline the general architecture of DLT-based trading system and introduce three IoT data trading protocols. Then, we present the system model, including the physical deployment of the devices. In Section III and IV, we model and analyze the performance of Blockchain-enabled IoT network in terms of latency and energy. Then, we evaluate and prove the derived model and design in Section V. Finally, we conclude the paper in Section VI.

Parameters Descriptions Values
General
Total number of NB-IoT devices 10000
Number of DLT miners
Set of Data Providers (Sellers)
Set of Data Consumers (Buyers)
Data to buy or sell
Set of trades
Uplink request arrival rate Eq.3
Downlink request arrival rate Eq.3
Transmitter and receiver antenna gains 1
Path loss exponential
Receiver sensitivity
Computing speed of a miner 0.3
Scaling factor 0.05
Power of miner 6
The unit length 10 ms
The average time interval between two NPDCCH
, Uplink and Downlink transmission rate -
Energy
Energy required to complete a trade Eq. 7
Uplink energy consumption Eq. 7
Downlink energy consumption Eq. 7
Blockchain energy consumption Eq. 6
Energy required for synchronization -
Uplink: Energy for resource reservation Eq.11
Uplink: Resource reservation energy Eq.11
Downlink: Energy for synchronization 0.33
Downlink: Resource reservation energy Eq.11
Downlink: receive energy Eq.17
Listening Power 0.1 W
Idle Power 0.2 W
Transmission Power 0.2 W
Power consumption in electronic circuits 0.01 W
Latency
Average computation latency of a miner Eq.19
Total DLT latency Eq.
DLT average transmission latency Eq.18
Synchronization Latency 0.33s
Maximum number of attempts 10
Probability of resource reservation Eq.8
  • * Eq: Equation

TABLE I: NOMENCLATURE

Ii DLT-enabled IoT Data Smart Trading Architecture and Protocols

This section presents the general system model of DLT-based IoT data trading as well as the data trading system with the three protocols tailored to different scenarios. Table I summarizes the used notation.

Fig. 1: General system model of DLT-enabled IoT Data Trading via NB-IoT connectivity where seller and buyer make a deal on the data .

Ii-a DLT-enabled Data Trading via NB-IoT

The general architecture of DLT-based IoT data trading includes three main components: data providers (sellers ), data consumers (buyers ) and a distributed ledger, shown in Fig. 1. Each seller or buyer can own one or more devices in the network. Here we assume that buyers and sellers act as digital wallets in a distributed network. During a trade denoted by , the seller and buyer communicate using the wide-area NB-IoT links. The trading procedure occurs to complete a deal between and , exchanging data and payment . First, completes the payment to in reference to the requested data, , and delivers to immediately. The general procedure from Fig. 1 can be described as follows:

Buyer

Subscribes to the IoT data in distributed ledger generated and published by , and makes a data request, regarding its preferred data, . The will be transmitted to and recorded in the ledger via transaction for negotiation based on factors such as amount of data, quality of data, price, discount, etc. After choosing from the list, generates a transaction which executes payment from ’s wallet. Once receives the via , it will generate a confirmation back to ledger.

Seller

Has two main roles; to collect data from the environment (e.g., environmental sensing data, geographical data or data from surveillance systems) and to act as a hub gathering data from neighboring devices to sell on the market. aims to earn the payment from by delivering to . After publishing a hashed version of its data and prices to the market via , waits for buying requests. Based on the predefined rules in the smart contract system, upon receiving a request from and the appearance of , generated by , as being recorded in the ledger, the seller can receive the payment . Finally, it confirms to the ledger that the trade is completed.

Distributed Ledger

The DLT manages a distributed ledger to record all data trading history which is grouped into blocks and linked together chronologically. The deployed smart contracts autonomously control the order and automate payments from parties without the need of human interaction. The smart contracts guarantee trust, transparency and speed of exchanging information. These can be deployed based on the negotiation between data providers and customers via . Any change in smart contract (e.g. change of price, amount of data, or discount) can be performed via .

In order to minimize the cost of storage, the sensing data could be hashed and recorded at more powerful DLT nodes, and only the hash of data is recorded to ledger. Then, a message is sent back to confirm that the data has been added to the ledger. After both and are satisfied with the terms of the contract, is executed to get the payment from to transfer to ’s wallet, while the data is transmitted to the storage address of . We assume that the data services, (e.g., data storage, trading and task dispatching) are implemented on top of a permissionless Blockchain. The sensing data are formatted into normal transactions of fixed size. To enhance efficiency, only the digest of each transaction is stored on the chain, and the content of the transactions are stored by each consensus node off-chain or at the IPFS (InterPlanetary File System) storage.

(a) General Trading (GT)
(b) Buying on Demand (BoD)
(c) Selling on Demand (SoD)
Fig. 2: Three IoT data trading protocols: (a) General Trading protocol (GT), (b) Buying on Demand (BoD), and (c) Selling on Demand (SoD).

Ii-B IoT Data Trading Protocols

General Trading (GT)

The GT protocol procedure is shown in Fig. 1(a). In a trade , the buyer sends a buying request to market via transaction to express its need in specific data . The data producer and seller , after collecting sensing data, start publishing its data information to the market. The smart contracts receive the requests from both customers and producers and then map the buying requests and selling requests to satisfy both parties based on their expected data and price. The buyer commit the requests with fund transfer via . After the smart contract receives the payment from , it executes to transfer requested to and to . Finally, both and confirm to the ledger that they received and , respectively.

A marketplace exchange of streaming IoT data, with a massive amount of data, requests, and a large number of parties, is an appropriate use case for the GT protocol. The environmental sensing data such as accurate real-time measurement data for control and alarm systems are exchanged between interested customers. More specifically, this protocol is used for the aforementioned use case due to its wide range of data continuously being pushed to the market. The open advertisement style of the GT protocol is appealing to potential buyers, encouraging the safe buying and selling of IoT data in a decentralized IoT data marketplace.

Buying on Demand (BoD)

BoD protocol describes a process where the producer publishes data information to the market for selling via request. The smart contract will broadcast information of received data by buying offer to other parties, e.g, to ask whether they are interested in buying . If is interested in , it will accept the offer by generate , and commit by when get the payment requests from smart contract. Then, the deal is settled as GT protocol via . The process of BoD protocol is described in Fig. 1(b).

Vehicle-to-Industry (V2I) emission trading, with a frequent exchange of data between vehicles and the vehicle industry, is an appropriate use case for the BoD protocol. In this scenario, the vehicles on the network act as the sellers of their emissions data, e.g., \chCO2, \chNOx, while manufacturers (vehicle industry), GoV e.g air quality management department, and data analytic organizations act as the buyers for maintaining accurate, secure tamper-proof vehicular emissions data. In V2I, the data being exchanged are used for the purpose of creating a trusted life-cycle emissions or fuel economy monitoring.

Selling on Demand (SoD)

The SoD protocol is described in Fig. 1(c). In this case, the smart contract receives the buying requests from a customer , but there is no available appropriate data on the ledger to satisfy the requirements from . Hence, the smart contract sends an ask-for-data request to producers to ask whether they can provide the required data . The providers after a while can gather data from the environment or from other sources then answer to the market by including information as well as price . Then, the smart contract asks for fund transfer with amount of . The make payment via . Then are executed to complete the deal between and . Finally, the confirmations are sent to the ledger from both parties.

This protocol is beneficial, for example, when a party needs a type of data that is not available on the market and there is a need to trade in real time. In the scope of this study, we assume that, when a provider receives the request ask-for-data from smart contract, it can provide the required data to the market. In real-life scenario, the requests from customer sometimes cannot be satisfied immediately, so these requests are queued in the systems until completed. A Vehicle-to-Vehicle (V2V) use case is appropriate for this protocol where vehicles can purchase the information on the traffic jam in specific street which drivers expect to use in the near future. The vehicles that have the requested information can be traded with the buyers on the road. Finally, similar to V2I, V2V involves the continuous wireless exchange of IoT data collected from vehicle sensors. The V2V use case contributes in generating a life-cycle emissions or fuel economy monitoring system amongst vehicles. This form of communication helps to manage the safety of the road, as well as increase vehicle awareness.

Fig. 3: Delivery probability versus distance for a standard deviation = 6 dBs.

Ii-C Communication System Model

We consider an NB-IoT cell with eNB located in its center, including devices uniformly distributed within the area. A data provider or consumer can consist of a single or multiple NB-IoT devices. For simplicity, we assume that each buyer or seller owns a single NB-IoT device to exchange assets and all devices belong to the normal coverage class. The DLT nodes are NB-IoT devices that have more computational power than seller/buyer nodes. In our model, involved sellers and buyers use NB-IoT as wireless network interfaces. In reality, the involved parties can use various wireless interfaces or networks for trading purposes but, our general model and analysis can be applied in these cases because of its modular and versatile design satisfies a broad range of interfaces and networks.

Our propagation model takes into account shadowing, but not small-scale fading; which is a sufficient first approximation as detailed physical layer modeling is not the focus of the work. Hence, for a given transmission power and carrier frequency , the received power at a distance between the base station and sensor is:

(1)

where and are the transmitter and receiver antenna gains, respectively,  m/s is the speed of light, is a zero-mean Gaussian RV with standard deviation  dB, and is the path loss exponent. From there, the outage probability at a given distance and receiver sensitivity W is:

(2)

Fig. 3 demonstrates the delivery probability at varying distances, for four different path loss exponent values, a standard deviation of dBs. In this work, we choose for urban area. We are aware that the model lacks a mobility aspect, however for this initial work, we have decided to use a simple model as previously described.

Fig. 4: Communication diagram of the GT protocol.

The arrival rate of uplink including selling and buying requests, respectively, to the system are: in which is number of communication sessions that an IoT device performs daily; and are probability a device request a selling service and a buying service, respectively. When an NB-IoT sensor device attempts to join the network, it first listens for the cell information, e.g, NPSS and NSSS messages to synchronize with the eNB. NB-IoT UEs have only two modes of operation, namely radio-resource control (RRC) idle and RRC connected [17]. In the former, the UEs can only receive the system information from the BS and, only in the latter, data can be transmitted. UEs are in idle mode before initial access to the network, but may also enter this mode during power saving or after an explicit disconnection request. To transition from idle to connected mode, the UEs (clients) must first acquire the basic system information and synchronization as illustrated in the upper part of Fig. 4. For this, the UE receives the master information block (MIB-NB) and the system information blocks 1 (SIB1-NB) and 2 (SIB2-NB). These are transmitted periodically through the downlink shared channel (DL-SCH) and carry the basic cell configuration, timing, and access parameters[18]. In addition, SIB1-NB carries the scheduling information for the rest of the SIBs.

After the system information has been acquired, the UEs must perform the RA procedure to transition to RRC connected mode. The RA procedure is a four-message handshake, initiated by the UEs by transmitting a single-tone frequency-hopping pattern, called preamble, through the NB Physical Random Access Channel (NPRACH). In most cases, the RA procedure is contention-based, hence, the preamble is chosen randomly from a predefined pool of up to orthogonal sub-carrier frequencies. Consequently, the main reasons for an access failure are the lack of power in the transmission and simultaneous transmissions of the same preamble, which lead to collisions.

After completing the RA procedure, and if the control-plane (CP) cellular IoT (CIoT) is used, UEs may piggyback short UL data packets along with the RRC Connection Setup Complete message. Otherwise, the non-access stratum (NAS) setup must be completed before eNB allocates resources for uplink transmission through the NB Physical UL Shared Channel (NPUSCH) and data can be transmitted. The resource unit (RU) is the basic unit for resource allocation in the NPUSCH and comprises a set of sub-frames in the time domain and sub-carriers in the frequency domain. The downlink (DL) data is transmitted through the NB physical DL shared channel (PDSCH). Data is exchanged based on the three defined trading protocols, GT, BoD and SoD. Fig. 4 shows the physical operations of GT protocol as an example. BoD and SoD could be considered as extensions of the GT protocol, those protocols are especially beneficial when the data is not available in the market.

Ii-D Performance metrics

Latency and the time required to complete a trade is one of the most important concerns of involved users. Latency directly influences the amount of time it takes for a trader to interact with the data market, the timely reception of relevant market information and the ability to act upon its receipt. The spread of the automatized data trading amplifies the impact of latency in terms of its competitive advantage. On top of this, IoT environments should be characterized with high energy efficiency. All these factors have motivated this investigation on the total E2E latency and energy consumption to complete a trade .

Latency

The latency to complete a trade between seller and buyer are formulated as:

(3)

where is the transmission latency between and which act as light nodes and full DLT nodes; While, represents the DLT mining and synchronization latency. In detail, , where , are NB-IoT uplink and downlink latency, respectively; , where is block verification time at DLT nodes, and is synchronization time between DLT nodes via NB-IoT connectivity.

Total energy consumption

Similarly, the energy consumption model of a trade includes the energy consumption for uplink , downlink transmission between NB-IoT sensors with DLT full nodes, among DLT full nodes, and the energy consumed in verification process known as mining in DLT nodes .

(4)

where and are energy consumed by communication between sellers/buyers and DLT nodes and the energy performed among full DLT nodes, respectively. The transmission power and latency depend significantly on the physical deployment, such that we analyze both analyze the resource consumed in physical communication and the application layer. In next parts, we formulate the latency and energy consumption of each process.

Iii NB-IoT Transmission Latency and Energy Consumption Models

As described in previous section, the total E2E latency includes two parts, the latency of transmissions of uplink and downlink between buyers/sellers and DLT nodes, and latency occurs in DLT verification process. For the first part, we define an adapted queuing model for DLT-based NB-IoT based on queuing model of the NB-IoT access network [19], where the uplink and downlink radio resources are modeled as two servers which visit and serve their traffic queues in both directions.

End-to-End latency

The E2E latency of NB-IoT uplink and downlink can be formulated as:

(5)

where , , , ,, are energy consumption of synchronization, resource reservation, and data transmission of uplink and downlink, respectively. has been defined in [18] with the values of . is given as:

(6)

in which is the maximum number of attempts, is the probability of successful resource reservation in an attempt, , is the expected latency in sending an RA control message, is the unit length and equal to the NPRACH period for the coverage class 1 which is varied from  ms to  s [18], and , is the expected latency in receiving the RAR message, where are requests waiting to be served.

In the following, we provide a simple technique based on drift approximation [20] to calculate recursively. Therefore, we treat the mean of the random variables involved in the process as constants. Besides, we assume that sufficient resources are available in the PDCCH so that failures only occur due to collisions in the PRACH or to link outages.

Let be the arrival rate of access requests per PRACH period and be the mean number of devices participating in the contention with their -th attempt. Note that in a steady state remains constant for all PRACH periods. Next, let and that the collision probability in the PRACH can be calculated using the drift approximation for a given value of and for a given number of available preambles as:

(7)

From there, the we approximate the probability of resource reservation as a function of as This allows us to define as:

(8)

since for and . Finally, from the initial conditions for , the values of and can be calculated recursively by: 1) applying (8); 2) calculating for the new value of ; and 3) updating the values of . This process is repeated until the values of the variables converge to a constant value. The final value of is simply denoted as and used throughout the rest of the paper.

Assuming that the transmission time for the uplink transactions follows a general distribution with the first two moments , then first two moments of the distribution of the packet transmission time are , and . Applying the results from [21], considering as a function of scheduling of NPUSCH, we have:

(9)

where is the average uplink transmission rate, , and is the mean batch-size. The latency of data reception is defined as:

(10)

in which, , are two moments of distribution of the packet transmission time, assuming that Assuming that packet length follows a general distribution with moments , , , is downlink data transmission rate.

Energy consumption

The energy consumption of the protocol 1 are formulated as below:

(11)

In which ,, , ,, are energy consumption of synchronization, resource reservation, and data transmission of uplink and downlink, respectively. We have:

(12)
(13)
(14)
(15)
(16)
(17)

in which, , , , , and are the power amplifier efficiency, idle power consumption, circuit power consumption of transmission, listening power consumption, and transmit power consumption, respectively.

Fig. 5: DLT performance in latency and energy consumption

Iv Resource consumption model of DLT verification process in NB-IoT environment

Consider a DLT network that includes miners. These miners start their Proof-of-work (PoW) computation at the same time and keep executing the PoW process until one of the miners completes the computational task by finding the desired hash value [6]. When a miner executes the computational task for the POW of current block, the time period required to complete this PoW can be formulated as an exponential random variable whose distribution is , in which presents for the computing speed of a miner, is power consumption for computation of a miner, and is a constant scaling factor. Once a miner completes its PoW, it will broadcast messages to other miners, so that other miners can stop their PoW and synchronize the new block.

(18)

where , , and , are latencies of sending hash of new mined block, requesting new block from neighboring nodes, and new block transmission, respectively. and are computed using as uplink transmission, while is computed based on downlink transmission as described in previous section.

For the PoW computation, a miner , first finds out the desired PoW hash value, . The fastest PoW computation among miners is , the complementary cumulative probability distribution of could be computed as . Hence, the average computational latency of miner is described as:

(19)

The total latency required from DLT verification process is . The average energy consumption of DLT to finish a single PoW round is:

(20)

The performance of DLT system is shown in Fig. 5. The figure demonstrates that the energy consumed and latency by DLT nodes are reduced with the number of miners. As the number of miners increases, this leads to a higher probability that miners verify transactions, and the mining speeds increases.

Iv-a Analysis of data trading protocols

In this section, the E2E latency and energy consumption of three protocols are formulated and compared approximately. The resource consumed by each data trading protocol is separated into two parts, namely, 1) the connectivity between and acting as light nodes in DLT network with full nodes, and 2) the communication among DLT full nodes.

The E2E latency of trade using GT protocol including the transmission latency between , and DLT verification nodes is described as below:

(21)
(22)

Assuming that 0.33 s, and are computed as (7), and are calculated based on (8) and (9) with the defined packet length of uplink and downlink.

Then, the battery lifetime of a NB-IoT device can be computed as below: where is the energy storage at device battery. Similarly, the performance of BoD protocol and SoD protocol can be formulated as GT protocol.

V Performance Evaluation

In this section, we will introduce the settings in terms of simulations and experiments. Then, we analyze the performance of proposed trading protocols in terms of latency and battery lifetime.

V-a Settings

In this section, we evaluate the derived data trading model, compare and analyze the designed trading protocols. In order to evaluate the derived model and compare the three proposed protocols, we setup a network with NB-IoT devices, where devices randomly play roles as sellers or buyers. We validate the results via Monte Carlo Simulations, where we run 1000 realizations for each trading protocol and experiments. The buyer nodes and seller nodes generate requests following a Poisson distribution process with rates of and , respectively. The number of buying and selling requests per day varied from 1 to 20, . The number of buyer and seller nodes varied and less than . The transmission power W, . The number of DLT miners are up to 20 miners as maximum, .

Protocols Operations Ether Gas Cost Approx. USD
GT Deploy SC 1.2 1132443 0.2862
BoD Deploy SC 1.3 1268369 0.2879
SoD Deploy SC 1.5 1582349 0.3783
  • * 1 Ether = Gwei; 1 USD = 4,182,471.9949 Gwei

TABLE II: Comparison in Smart Contract Execution Cost

V-B Cost of Smart Contracts

The proof of concept for the three proposed trading protocols are deployed in Ganache2 Ethereum network to evaluate the complexity and the cost of execution of different trading strategies. The smart contracts are implemented and deployed using Remix IDE3. In the Ethereum platform, any operation or transaction executions that changes the Blockchain or its state requires fees and the involved parties need to pay that fees. These costs are calculated by using the amount of gas executed and the unit of gas price. The gas required during any activity reflects the computational complexity or size of the smart contracts, while the gas prices are determined by the Ethereum miners in the network. In this work, we used Gwei4 to evaluate the cost of different operations in trading process.

Table II shows the cost of three protocols deployment and transactions to complete a deal between a seller and a buyer. We observe that the approximate cost in USD for GT is the cheapest in comparison to BoD and SoD protocols. The cost of smart contracts execution is generally expensive, therefore, it is preferred to use the GT protocol. In an environment with a massive number of involved parties and transactions (e.g, marketplace), the transactions are executed autonomously to reduce costs using the available resources. While, BoD and SoD are preferred when the users have requests with specific resources.

(a) M = 20
(b) M = 5.
Fig. 6: Impact of number of DLT miners to latency
Fig. 7: Impact of ratio

V-C Latency to complete a deal

Impact of number of Miners

Fig. 6 shows the latency of three trading protocols. Both the analysis and the simulation results show that the SoD protocol has higher latency to complete a deal between and because of extra steps. Note that the comparison is evaluated approximately because the latencies are depended on various factor such as number of DLT miners, the length of blocks, and level of difficulty. The verification latency of DLT miners are measured based on Ganache Ethereum network. In GT protocol, the smart contracts map selling requests with available stored in the ledger and make a deal between and immediately, so that it guarantees efficient trading in the market. The average latency to complete a deal of GT protocol is around seconds including latency of NB-IoT and DLT procedures. The BoD and SoD latencies are higher because of extra procedures necessary to gather required information between customers and producers. We observe that GT could be used in terms of applications which require low latency. The downside of GT protocol is that the data requests have to always be available to settle the trade, so that it is matched with applications (e.g smart metering) where the type of information is fixed.

Seller and Buyer Ratio

The impact of ratio between the number of sellers and buyers are demonstrated in Fig. 7. The figure also shows a comparison between trading protocols under varying NB-IoT uplink transmission rate, Kbps and fixed downlink data rate at Kbps. The results show that i) the increase in number of buyers requires more delay to complete a trade, and ii) in contracts, increasing data rates help to provide a faster service.

Fig. 8: NB-IoT Battery lifetime.

V-D Battery lifetime of NB-IoT devices

In general, the power consumption of battery lifetime during a reporting period depends on length of data transmitting, bandwidth, MCL, latency, and RF module. Hence, the power consumption of one trading protocol will be higher or lower than the other depending on the values of these parameters. The battery lifetime capabilities of NB-IoT devices among three trading protocols are compared and demonstrated in Fig. 8. The number of uplink requests are varied from 1 to 20 requests per day. We observe that the number of requests per day significantly impact to the battery lifetime of NB-IoT devices. The fact is that the battery lifetime of around 10 years can be achieve with one report per day, however, for more frequent transmissions (e.g. 8 requests per day) the battery lifetime is reduced to around 1 year. Specifically, the GT trading protocol achieves over 11 years for 1 report per day, while BoD and SoD achieve around 10 years and 9 years, respectively. The fact is that applications such as smart metering, smart parking based on NB-IoT connectivity do not require frequent updates from sensors. In terms of increasing number of requests daily up to 5, the battery lifetime reduced significantly to around 2 years. Because for each buying or selling request, the NB-IoT devices start running protocol with multiple operation until the trade is settled.

Vi Conclusion

In this paper, we proposed the first benchmarking framework for evaluating data trading protocols. The framework includes a model and analysis of systematic DLT-based IoT data smart trading protocols in massive NB-IoT deployments. We hate proposed and analyzed three IoT data trading protocols named General Trading, Buying on Demand, and Selling on Demand. Considered collectively, these protocols cover a wide range of interesting scenarios, such as carbon emission trading or monitoring of vehicle emissions. We have conducted a comprehensive analysis of these protocols in terms of communication and evaluated end-to-end latency, battery lifetime and resource consumption. In terms of performance, each protocol is tailored to a different scenario. We conclude that the GT protocol should be used as primary protocol in a data marketplace where massive amounts of data are available. Additionally, the BoD and SoD protocols can be interchangeably used when there are particular demands from either buyers or sellers.

To the best of our knowledge, this is the first work of its kind, providing a general benchmark framework for data trading protocols in IoT environments. In the next iteration of this work, we will first consider more elaborate utility models for the parties involved in trading. Second, we will evaluate the performance of trading schemes in diverse network interfaces.

Acknowledgment

This work has been in part supported by the European Research Council (Horizon 2020 ERC Consolidator Grant Nr. 648382 WILLOW).

Footnotes

  1. The terms DLT and Blockchain will be used interchangeably throughout this paper, Blockchains are a type of DLT, where chains of blocks are made up of digital pieces of information called transactions and every node maintains a copy of the ledger
  2. https://www.trufflesuite.com/ganache
  3. https://remix.ethereum.org/
  4. https://www.cryps.info/

References

  1. ”The Growth in Connected IoT Devices Is Expected to Generate 79.4ZB of Data in 2025, According to a New IDC Forecast”, IDC report, 2019. [Online]. Available: https ://www.idc.com/getdoc. jspcontainerId=prUS45213219. Accessed: July 9, 2020.
  2. Huang, Zhiqing, Xiongye Su, Yanxin Zhang, Changxue Shi, Hanchen Zhang, and Luyang Xie. ”A decentralized solution for IoT data trusted exchange based-on Blockchain.” In 2017 3rd IEEE International Conference on Computer and Communications (ICCC), pp. 1180-1184. IEEE, 2017.
  3. Perera, Charith. ”Sensing as a service (S2aaS): Buying and selling IoT data.” arXiv preprint arXiv:1702.02380 (2017).
  4. Mao, Weichao, Zhenzhe Zheng, and Fan Wu. ”Pricing for revenue maximization in iot data markets: An information design perspective.” In IEEE INFOCOM 2019-IEEE Conference on Computer Communications, pp. 1837-1845. IEEE, 2019.
  5. Jernigan, Stephanie, David Kiron, and Sam Ransbotham. ”Data sharing and analytics are driving success with iot.” MIT Sloan Management Review 58, no. 1 (2016).
  6. Nakamoto, Satoshi. Bitcoin: A peer-to-peer electronic cash system. Manubot, 2019.
  7. Danzi, Pietro, Anders E. Kalor, Rene B. Sorensen, Alexander K. Hagelskjær, Lam D. Nguyen, Cedomir Stefanovic, and Petar Popovski. ”Communication aspects of the integration of wireless iot devices with distributed ledger technology.” IEEE Network 34, no. 1 (2020): 47-53.
  8. Lam D. Nguyen., Israel Leyva-Mayorga, and Petar Popovski. ”Witness-based Approach for Scaling Distributed Ledgers to Massive IoT Scenarios.” arXiv preprint arXiv:2004.06300 (2020).
  9. L. D. Nguyen, A. E. Kalor, I. Leyva-Mayorga and P. Popovski, ”Trusted Wireless Monitoring Based on Distributed Ledgers over NB-IoT Connectivity,” in IEEE Communications Magazine, vol. 58, no. 6, pp. 77-83, June 2020, doi: 10.1109/MCOM.001.2000116.
  10. Gupta, P., Kanhere, S., & Jurdak, R. (2019). A Decentralized IoT Data Marketplace. arXiv preprint arXiv:1906.01799.
  11. Bajoudah, S., Dong, C., & Missier, P. (2019, July). Toward a Decentralized, Trust-less Marketplace for Brokered IoT Data Trading using Blockchain. In 2019 IEEE International Conference on Blockchain (Blockchain) (pp. 339-346). IEEE.
  12. Missier, P., Bajoudah, S., Capossele, A., Gaglione, A., & Nati, M. (2017, October). Mind my value: a decentralized infrastructure for fair and trusted iot data trading. In Proceedings of the Seventh International Conference on the Internet of Things (pp. 1-8).
  13. Wei, X., and Li, X., ”Smart Contract Based Data Trading Mode Using Blockchain and Machine Learning,” in IEEE Access, vol. 7, pp. 102331-102344, 2019, doi: 10.1109/ACCESS.2019.2928325.
  14. Weiqi, D., Chunkai, D., Kim-Kwang. R. C., Changze, C., Deiqing, Z., and Hai, J., ”SDTE: A Secure Blockchain-Based Data Trading Ecosystem,” in IEEE Transactions on Information Forensics and Security, vol. 15, pp. 725-737, 2020, doi: 10.1109/TIFS.2019.2928256.
  15. Popli, Sakshi, Rakesh Kumar Jha, and Sanjeev Jain. ”A survey on energy efficient narrowband internet of things (NBIoT): architecture, application and challenges.” IEEE Access 7 (2018): 16739-16776.
  16. 3GPP, “Physical layer procedures,” TS 36.213 V15.5.0, Mar. 2019.
  17. 3GPP, “Radio Resource Control (RRC); Protocol specification,” TS 36.331 V15.0.0, Sept. 2018.
  18. “Technical specification group GSM/EDGE radio access network; cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT),” 3GPP, Sophia Antipolis, France, Rep. TR 45.820, 2015.
  19. Azari, A., Stefanović, Č., Popovski, P. and Cavdar, C., 2019. On the Latency-Energy Performance of NB-IoT Systems in Providing Wide-Area IoT Connectivity. IEEE Transactions on Green Communications and Networking.
  20. C.-H. Wei, G. Bianchi, and R.-G. Cheng, “Modeling and Analysis of Random Access Channels With Bursty Arrivals in OFDMA Wireless Networks,” IEEE Transactions on Wireless Communications, vol. 14, no. 4, pp. 1940–1953, 2015.
  21. H. Akimaru and K. Kawashima, Teletraffic: theory and applications. Springer Science and Business Media, 2012.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
417601
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description