Secure storage of dynamic node information in smart parking using local blockchain

Abstract

One of the challenges drivers face in today’s fast-paced urban world is the ability to access parking spaces quickly. The increase in the number of vehicles in cities, especially in urban areas, as well as the growth of network services in smart cities, has created the need to provide easy-to-use smart parking networks. However, the most critical challenge in building such a network is the secure storage of customer and service provider information. Using blockchain to store data securely requires powerful computing resources and high energy consumption. In this research, combining existing ideas in the field of smart parking and blockchain, a solution will be proposed to use blockchain in dynamic nodes with poor computing resources, such as sensors used in smart parking. As one of the layers introduced in smart parking, we simulated the proposed algorithm in a wireless sensor network (WSN). In light of the findings of previous studies demonstrating the efficacy of Zigbee technology as a mesh topology in WSNs with low-cost infrastructure and resource requirements and our simulation results, we employed this technology to evaluate its performance in our proposed smart parking application. On the other hand, functions created with the Solidity language can use online payment services on such a secure network.

Keywords

security Internet of Things smart parking smart cities blockchain

1. Introduction

Blockchain technology is expected to change transactions, affecting many potential applications completely. Expectations are high, but their impact and benefits in the real world still need to be fully understood. Blockchain is a distributed ledger technology that provides a secure and transparent way to store and transfer data without a central authority. It uses cryptography to link and protect data blocks that form an immutable and chronological record of transactions or events. This technology focuses on peer-to-peer networks, enabling group collaboration [19]. Blockchain is the foundation of Bitcoin cryptocurrency and has recently been used to provide privacy and security in a peer-to-peer network with a topology similar to that of the Internet of Things (IoT). However, blockchain’s high processing cost, bandwidth, and latency make it unsuitable for nodes with limited processing capacity, such as IoT devices [3].

Many studies have been done on integrating blockchain and the Internet of Vehicles [8,20] and combining blockchain and smart parking [23,24]. For example, Jihan Lailatul Atiqoh et al. [2] integrated blockchain technology with ring learning with error-based digital signatures to protect the scheme from impersonation and double-spending threats.

While traditional parking management systems often rely on centralized servers, these systems are vulnerable to single points of failure and data breaches. To address these limitations, several researchers have proposed using local blockchains to store dynamic node information securely in smart parking systems.

In [12], Li et al. developed a decentralized parking management system using a local blockchain to record real-time parking data and enable secure and efficient payments. The system utilizes a coordinator node to validate and broadcast block transactions, ensuring data integrity and consistency.

In [21], Yang et al. proposed a local blockchain-based parking management system that utilizes a smart contract to automate parking fee calculations and transactions. The system employs a consensus mechanism to ensure the immutability of parking records and prevent data tampering.

These studies demonstrate the feasibility of using local blockchains to secure and manage dynamic node information in smart parking systems. The decentralized nature of local blockchains enhances data security and resilience against single points of failure. Moreover, smart contracts streamline parking fee transactions and automate parking management processes.

Researchers have explored techniques for efficient block pruning and data validation to enhance the security and efficiency of local blockchain-based smart parking systems.

In [15], Lin et al. proposed an efficient block-pruning algorithm that selectively removes outdated blocks from the local blockchain to optimize storage and network bandwidth consumption. The algorithm prioritizes blocks based on age and importance, ensuring critical data remains readily accessible.

In [22], Zhang et al. developed a decentralized data validation scheme based on consensus among sensor nodes. The scheme utilizes a voting mechanism to determine the validity of incoming block data, ensuring that only legitimate transactions are incorporated into the local blockchain.

These studies highlight the importance of efficient block management and data validation in local blockchain-based smart parking systems. We can enhance these systems’ scalability, security, and reliability by employing optimized block-pruning techniques and decentralized data validation schemes.

Sergii Kushch and Francisco Prieto Castrillo [10] considered the implementation of blockchain technology in WSN as a component of the IoT. They presented the “rolling blockchain” idea, which can be utilized to construct a WSN in which automated vehicles serve as network nodes. The ideal number of WSN nodes, interconnections between them, and network reliability are estimated for the specified values. Their findings can be used in at least two areas: sensor networks in smart cities and the IoT. Their simulation results revealed that the network remains stable as the attack density increases. The network’s reliability depends on the number of nodes in each subsection at any given time. The proposed method is constructing a private blockchain data network with constant complexity.

Pham et al. [17] proposed and developed an efficient cloud-based parking system solution based on the IoT. Their proposed system considers each parking lot as an IoT network. It transmits data, including the GPS location of the vehicle, the distance between parking places, and the number of car parks available in the parking lot, to the cloud data center. The data center functions as a remote server to estimate the cost of parking demands, which are often adjusted and may be accessed at any time by vehicles connected to the network.

One of the most essential elements of a smart city is easy and secure access to a smart parking network. In addition to facilitating urban traffic, it allows drivers to use existing parking lots with minimal time and cost. Many articles have considered creating a smart parking network. However, using blockchain capabilities to develop a secure network that can be used in dynamic nodes with poor computing resources and batteries [10] is a missing link in this process.

Any proposed models for use in the parking scenarios shall be aligned with the VANET/IoV protocol. According to some research papers, blockchain technology can enhance the security, privacy, and trust of VANET communication. Blockchain is a decentralized, distributed, and tamper-proof ledger that records transactions among nodes in a network. Blockchain can provide identity and location privacy protection for vehicles, as well as detect and prevent malicious attacks or data tampering in VANET [1,11]

Despite the significant contributions of the research above, our proposed smart parking application stands out with several unique advantages.

Scalability: Our system’s decentralized architecture, utilizing dynamic nodes and a network of local servers, enables seamless scalability as the number of users and parking lots increases. Unlike centralized systems that may become overloaded, our approach effortlessly accommodates growth without compromising performance.

Resource Efficiency: Our system prioritizes resource-constrained environments, such as smart parking lots with limited infrastructure. We optimize resource utilization by employing dynamic nodes with minimal computing requirements while maintaining system functionality. This contrasts with existing methods that may demand more powerful hardware, making them less suitable for resource-limited scenarios.

Seamless Integration: Our system integrates with existing WSN and RFID network technologies, leveraging established infrastructure to collect and transmit data efficiently. This eliminates the need for additional infrastructure or data processing steps, streamlining integration and reducing complexity.

Enhanced Security: Our system employs blockchain technology to securely store check-in and check-out information and encrypted user and account information, providing robust protection against unauthorized access and data tampering. Unlike referenced systems that may rely on weaker security measures, our approach ensures the highest data confidentiality and integrity level.

Decentralized Decision-Making: Our system utilizes a decentralized consensus mechanism, empowering stakeholders such as drivers, smart parking owners, and service providers to participate in decision-making. This fosters transparency and accountability, reducing the risk of manipulation by single entities.

These advantages and the proposed algorithm position our system as a compelling solution for securing and efficiently managing smart parking data. Our approach caters to resource-constrained environments, scales effectively, integrates seamlessly with existing technologies and prioritizes data security while enabling decentralized decision-making. These features make our system a robust and appealing choice for smart parking applications.

However, it is crucial to recognize the potential drawbacks of our approach. The decentralized architecture necessitates careful management of the distributed network of nodes and consensus mechanisms. In addition, the consensus process in blockchain-based systems may introduce latency in transactions, raising concerns for real-time applications. Dynamic nodes in our system may consume more energy than specialized hardware used in traditional blockchain networks, especially in resource-constrained environments. Furthermore, blockchain technology, while providing data immutability, also presents privacy concerns due to the transparent nature of the ledger. These limitations should not be overlooked and can be addressed through effective mitigation strategies to strengthen the appeal and robustness of our proposed system.

Despite these potential drawbacks, our proposed system offers several compelling advantages and represents a promising approach to secure and efficient management of smart parking data. By carefully considering these limitations and implementing appropriate mitigation strategies, we tried to enhance the robustness and appeal of our proposed system. This research aims to provide a solution to achieving this critical goal.

Our proposed smart parking application uses blockchain technology to provide a secure and transparent way to store and transfer data. By using dynamic nodes and a network of local servers, this system proposes a way to use blockchain technology in devices with poor computing resources, thus enabling the cooperation of a group of actors, including drivers, smart parking owners, and service providers. These actors interact with each other to provide a seamless parking experience. To access the smart parking service, drivers must register their account and receive their blockchain address through the mobile application. To use the smart parking service, each driver must top up their account with the required amount and link a payment method with Ethereum digital currency. The infrastructure that supports the smart parking program includes using blockchain technology to securely store check-in and check-out information and encrypted user and account information in the local blockchain system. Additionally, this system uses WSN and RFID network technology to collect and transmit data in real-time. Thus, the main objectives of the study are:

Building a network of smart parking lots that can store information for smart city service providers and recipients in a secure and easy-to-use manner

Providing an excellent way to employ blockchain on dynamic nodes with low computing resources

The structure of the paper is as follows: The related work is described in Sect. 2. The proposed algorithm is introduced in Sect. 3. The results of the simulation are presented in Sect. 4. Finally, Sect. 5 offers the summary, conclusion, and future work possibilities.

2. Related work

Feilong Lin et al. [14] proposed Proof-of-Planned-Behavior as a new blockchain consensus methodology. It constructs a model of the autonomous consensus process using planned behavior. They designed a system for a dynamic authorizer group for decentralization and creditability reasons. In addition, they developed various smart contracts to ensure the parking facilities were performed transparently. To prove the usefulness of their technique, the prototype has finally been deployed on a university campus.

Gerald B. Imbugwa et al. [7] presented a smart parking system with a distributed network to improve prior work on smart parking utilizing blockchain. In contrast to most research focusing on privacy for a single component, a single point of failure for systems placed on cloud databases, and geographical censorship, six components will interact and trade value easily. Their study emphasized performance, scalability, privacy, and interaction between multiple components in a distributed network.

Riya Kakkar et al. [9] presented a blockchain and Interplanetary file-based parking cost prediction technique enabling customers to reserve parking spaces securely and efficiently. Their primary goal is to guarantee privacy, security, and accessibility for car park owners. Moreover, they utilized a second-price auction strategy to increase the parking cost to benefit users and car park owners. The efficiency of the suggested method for 100 users and 40 car parks has been simulated based on multiple auction models. The results indicate that their proposed method is secure and beneficial for customers and car park owners.

Yanfeng Geng and Christos G. Cassandras [4] presented a novel smart parking method for urban contexts, coupled with [5]. The method recognizes and stores the optimal car park based on the driver’s cost function, a mix of distance to target and parking fee. The suggested method solves the mixed-integer linear programming problem (MILP) on every decision point specified in the time-based sequence. Each MILP solution is based on the optimal distribution of current status data. It will be adjusted at the next decision point to ensure no resource reservation conflicts and no driver is allocated a higher flow rate than the existing flow. In the proposed smart parking system, vehicles can reserve on-street and off-street car parks based on an explicitly expressed target performance level. The issue that has been resolved is that each driver has specific requirements, and only a portion of the available resources (parking areas) can accommodate these requirements. This is comparable to the skill-based routing observed in contact centers, where calls are redirected according to the ability to answer service calls.

Ali Dori et al. [3] presented a blockchain-based architecture for IoT that delivers lightweight, distributed privacy and security. This architecture provides the benefits of blockchain technology while solving the following obstacles associated with blockchain usage on the IoT:

The amount of calculation for blockchain mining is considerable, and most IoT devices have limited resources.

Block mining is time-consuming, and most IoT applications want low latency.

As the number of network nodes grows, the scalability of the blockchain is weakened. The IoT network is expected to contain many nodes.

The basic blockchain protocol generates massive overhead traffic, which the bandwidth of some IoT devices may limit.

To illustrate their ideas, they provided a clear example of a smart home. Meanwhile, they stated that the proposed architecture is practical and suitable for various uses of the IoT.

FalkMoritz Schaefer et al. [18] examined and compared the energy usage of a home network established using 6LoWPAN and a Zigbee network with the same topology. In addition, the energy consumption of the two stack protocols using identical hardware was assessed and measured. The physical layer (PHY) and IEEE 802.15.4 access control layer are utilized by both Zigbee and 6LoWPAN (MAC). They evaluated a two-story, medium-sized, appliance-filled household environment. Several of them functioned on batteries, whereas others operated on power supplies. They considered transmitting at a data rate of 250 kbps on the 2.4 GHz ISM band. The overhead of 6LoWPAN was compared to the Zigbee network layer in the home network scenario to calculate the total power consumption of the network. Assuming the most efficient and standard configuration compatible with 6LoWPAN and Zigbee, 6LoWAN would require more overhead to organize the network, while Zigbee requires more network header overhead. Considering the home network scenario, the energy consumption of the two protocols was only slightly different. The energy consumption of two implementations on the same hardware was also evaluated, and there were only minor differences between 6LoWPAN and Zigbee.

C. Margescu et al. [16] evaluated the functioning of the ZigBee WSN using OPNET. The network is suitable for various applications and must be able to collect data from a large group of nodes, each of which is connected to several sensors. Healthcare is one application that may be possible for this network. Initially, the network would be used to show the variation in blood pressure. In addition, body temperature, ambient temperature, pressure, and blood transfusion levels can be measured. The network coordinator node transmits the data to the local server for processing. After reviewing the results of the first project’s implementation, it was discovered that the maximum distance between nodes under the OPNET specifications is 100 meters. This distance is shorter in the actual world and can be increased with routers, illustrating the importance of placing routers that cover a larger area. In addition, it was found that the CSMA-CA algorithm reduces the overall data rate.

Hamoudi et al. [6] analyzed the effectiveness of the OPNET modeler in simulating the ZigBee WSN network. In general, the outcomes reported were compatible with other WSN simulators. They determined that OPNET offers promising results for modeling ZigBee WSN networks since it can give rich reporting and data on various network layers (notably the MAC layer) for different nodes or the whole WSN.

3. The system layers and operations

The proposed algorithm operates in an environment that comprises three interconnected layers:

Sensor Network Layer: This layer utilizes wireless sensors and RFID technology to monitor and manage parking spaces, providing real-time data on occupancy levels and vehicle movements.

Local Blockchain Layer: This layer maintains a secure and decentralized database of vehicle entry and exit records, service provider-customer transactions, and historical parking data. Powered by Zigbee technology, the local sensor network forms a lightweight and energy-efficient mesh topology, enabling dynamic nodes to develop the local blockchain.

Public Blockchain layer: This layer seamlessly integrates with the Ethereum public blockchain, leveraging its robust security and decentralized nature to facilitate cryptocurrency-based online payments. Smart contracts developed using the Solidity programming language seamlessly integrate payment processing with the local blockchain network, ensuring efficient and secure transactions.

This three-tier architecture, as depicted in Figure 1, provides a comprehensive solution for secure data storage and transaction management in smart parking systems. Combining Zigbee technology, a novel consensus algorithm, and integration with the Ethereum public blockchain network ensures data security, scalability, and decentralization, making the proposed system a promising advancement in smart city infrastructure.

Figure 1.

The proposed three-layer communication structure.

Layer 1: A local network of sensors equipped with Zigbee and RFID technology and installed at the entrance and exit of the smart parking and parking lots. The information collected on this network includes the identity of the car driver, which appears in the form of a blockchain network address on the label, the time of entering and leaving the parking lot, the parking number, the fee paid, and other information provided in the proposed block structure as shown in Figure 2.

Figure 2.

Block structure in smart parking network.

Figure 3.

Steps to manage block information in local smart parking sensor network and local blockchain network.

The block is temporarily stored in the sensor memory and finally stored in the local smart parking server on the local blockchain network to which it belongs. All sensor nodes in the WSN will be equipped with RFID to record the information of vehicles entering the smart parking lot and create data blocks. Therefore, the identity of the vehicles entering the parking lot can be done only by reading the Blockchain address of the vehicle owner installed on the windshield as an RFID tag when registering in the smart parking network. The process of creating, updating, and integrating block information into the local blockchain network within the smart parking sensor network is as follows, as depicted in Figure 3:

Vehicle Entry Detection and Genesis Block Creation:

A wireless parking entrance sensor with RFID technology detects vehicles entering the parking lot.

The sensor generates a genesis block, serving as the foundation for the local blockchain.

The genesis block incorporates crucial information about the vehicle, including the timestamp, vehicle ID, and assigned slot number.

The created genesis block is forwarded to the coordinator node.

Coordinator Node Reception and Block Validation:

The coordinator node, linked to the local blockchain server, receives the genesis block from the parking entrance sensor.

The coordinator node employs cryptographic methods to validate the authenticity of the genesis block.

If the block is valid, the coordinator updates the sender and receiver address fields with the corresponding blockchain addresses.

Block Distribution and Internal Blockchain Connection:

The coordinator node disseminates the updated genesis block to all sensor nodes within the network.

Sensor nodes receive the block and temporarily store it in their local memory.

Sensor nodes connect their internal blockchains to the newly received block, preserving the continuity of the blockchain sequence.

Slot Number Update and Sensor Node Verification:

The parking sensor that recognizes the vehicle’s entry updates the slot_Number field in the received block to reflect the actual slot location.

The sensor verifies the integrity of the updated block and forwards it to the coordinator node for consensus.

Fee-Per-Second Update and Block Broadcast:

The coordinator node updates the Fee_per-second field in the block based on the current cryptocurrency market rates, converting the fee into Wei, the smallest unit of Ether. We have added the conversion of the fee into Wei to ensure that the fee is represented in the smallest unit of the cryptocurrency, which is more accurate and efficient for the system.

The updated block is broadcast to all sensor nodes for verification and consensus.

Vehicle Exit Detection and Fee Calculation:

An exit sensor node in the parking lot detects the vehicle exiting.

The sensor transmits a packet related to the vehicle’s exit to the coordinator node, including the exit timestamp.

The coordinator node updates the Parking_Out field in the block with the exit timestamp.

Parking Fee Calculation and CostToPay Update:

The coordinator node calculates the vehicle’s total time in the parking lot.

The coordinator node updates the CostToPay field in the block based on the calculated parking time and the Fee_per-second value.

Added Field Reset and Further Block Updates:

The coordinator node resets the “Added” field to zero for all nodes that haven’t yet verified the block.

The coordinator node updates other fields in the block, adhering to the previous steps.

Sensor Node Verification and Consensus Refinement:

Sensor nodes receive data packets from the coordinator node carrying the updated block.

Sensor nodes compare the Block_ID field in the received packet with the Block_ID of the last block saved in their internal blockchain.

If the Block_ID is new, the sensor node incorporates the complete packet into its internal blockchain.

If the Block_ID is not new, it compares the previously updated fields of the received packet with the corresponding fields of the packet stored in its internal blockchain.

If there are no discrepancies between the fields, the sensor node updates the “Added” field of the received packet to 1, signaling its validation.

The updated packet is returned to the coordinator node for further consensus.

Local Blockchain Integration and Consensus:

The coordinator node, employing a voting mechanism, collects updated packets with the “Added” field set to 1 from at least 51% of the sensor nodes.

The coordinator node, acting as a consensus arbitrator, seamlessly incorporates these verified packets into the local blockchain, ensuring the integrity and consistency of the entire blockchain. This process paves the way for research into similar applications in scenarios where only dynamic nodes can be utilized. The most significant benefit of this step is that it enables the smart contract system to respond in real time even if the connection to the Local Blockchain layer is interrupted or the information stored in a Local Blockchain Server is inaccessible. The local sensors’ chain can provide the necessary data.

Block Pruning and Memory Management:

Suppose the number of blocks in the internal sensor blockchain reaches the N blocks specified by Eq. (1).

In that instance, one-third of the oldest blocks are eliminated from the beginning of the queue to keep the storage memory unchanged and avoid removing recent blocks.

In this equation, M stands for the minimum memory capacity of the sensor nodes (in bytes), R denotes the sensor’s minimum reserved memory (in bytes), and finally, S refers to the Block_size (in bytes).

\begin{aligned} N = [(M - R) * 8 / S] \end{aligned}

(1)

Layer 2: The existing smart parking server network with sufficient computing and storage resources is identified as a local blockchain network in the structure proposed in Figure 1. In this network, all parking transaction information is recorded in a chain structure like that of blockchain, without using Proof of Work (PoW), a resource and energy-intensive task [3] of adding blocks to the network.

According to the data block structure proposed in Figure 2, the same blocks as the data packets exchanged in the sensor network can be connected into chains after completing the fields to form a local blockchain.

In addition to the data generated in the WSN, the blockchain information of other nodes connected to the local blockchain, as reported in Table 1, is maintained in the network and updated through the user interface designed for the public blockchain. When the current parking space is complete, this information can guide the driver to the nearest parking lot connected to the smart parking network, which has sufficient capacity.

Table 1

Information on the distance and capacity of adjacent parking lots.

Parking blockchain address	Distance (Dij)	Capacity	Number of free spaces
0xFB91212D81CA24C759c5DaD39cD6fDc616189844	2 Km	30	5
0x45Db6535B495c482d67F5c612Ed828A21aeeD935	5 Km	36	10
0x53bD4b98105a1e9a3e5Bf2706e9825E715bC67FA	7 Km	20	4
0x72102068bb23dF8BbeC18624C10B5890C0bc8B6c	10 Km	40	12
0x99e0C127652bE30e34c010D5C314eaC946981E02	8 Km	30	1

Figure 4.

Parking order and safe payment smart contract.

Layer 3: The blockchain public network, which establishes a connection between the user and the smart parking network by deploying the smart contract, as indicated in Figure 4, to receive information about the distance and capacity of the smart parking network, make online payments through the established cryptocurrency in the target country and update smart parking network information. In this smart contract, the owner owns a Local Parking Network, uses his blockchain address to deploy the contract, and enters the wallet address to which the received amount will be transferred.

Upon registering their details in the system, drivers can initiate a seamless parking search through the intuitive application powered by the robust smart contract framework. The system promptly acknowledges the request and dispatches it to the local parking network, tasked with meticulously identifying the nearest smart parking lot that aligns with the driver’s specified criteria. This intelligent network, equipped with cutting-edge algorithms, meticulously scrutinizes the available parking spaces across the network, prioritizing those that meet the driver’s preferences and ensuring an optimal parking experience.

The smart contract system is the orchestrator, ensuring seamless communication between the driver, the local parking network, and the local sensor network. Once the nearest smart parking lot is identified, the system swiftly relays this information to the driver through the user-friendly application, empowering them to make informed decisions regarding their parking options.

The local parking network, acting as the custodian of parking space availability and accessibility, diligently evaluates each potential parking spot based on the driver’s preferences. Once the most suitable parking space is identified, the network meticulously provides the system with the parking space’s unique identifier, precise location, and remaining capacity. The system then seamlessly transmits this comprehensive information to the driver through the application, enabling them to select the optimal parking destination confidently.

Upon entering the designated smart parking lot, the vigilant local sensor network dutifully records the vehicle’s entry timestamp, ensuring accurate tracking of the parking duration. This timestamp is relayed to the local blockchain network, an immutable record of parking events. In tandem with the updated parking fee, the system generates an invoice and promptly transmits it to the driver through the application, enabling secure and transparent payment processing. Upon successful payment confirmation, the system communicates the driver’s exit permission to the local blockchain network, and the local sensor network prepares the vehicle for seamless exit from the parking lot, completing the entire smart parking experience.

3.1. Discussion on operations rationale

3.1.1. The rationale for updating fee at step 5 rather than step 1

Updating the fee at step 5, rather than step 1, is a crucial aspect of the proposed algorithm. This decision stems from the need to ensure data integrity and prevent malicious actors from attempting to manipulate the fee mechanism.

Updating the fee at step 1, where the block header is created, would allow malicious nodes to influence the fee value in their favor before broadcasting the block to the network. This could lead to unfair fee distribution and undermine the system’s trust in the fairness of the fee mechanism.

The proposed algorithm mitigates these risks by delaying the fee update to step 5 after most nodes have verified the block header. Only after the block has been deemed valid and added to the local blockchain is the fee updated, ensuring that all participating nodes have had a chance to review and validate the transaction data before the fee is finalized.

This approach aligns with the decentralized nature of the blockchain and promotes fair and transparent fee distribution among participating nodes. It also prevents any single node from controlling or manipulating the fee mechanism, further enhancing the security and integrity of the system.

3.1.2. Rationale for 51% consensus in a local blockchain network

Even in a local blockchain network where all sensors belong to the same parking lot, implementing a 51% consensus mechanism offers several crucial advantages:

Enhanced Data Integrity and Authenticity:

Requiring 51% of the nodes to agree on the validity of each block ensures that only legitimate data is recorded on the local blockchain. This prevents malicious actors from tampering with or forging data, safeguarding the integrity of the parking information.

Improved Network Resilience and Fault Tolerance:

Achieving consensus across multiple nodes enhances the network’s resilience against potential failures or attacks. If a single node fails or becomes compromised, the remaining nodes can continue to validate transactions and maintain the ledger’s integrity. This distributed consensus mechanism ensures the network remains functional despite node failures or disruptions.

Enhanced Transparency and Accountability:

By publicly recording the consensus process, the network promotes transparency and accountability. This transparency allows stakeholders to verify the validity of data and identify any potential anomalies or inconsistencies.

Preventing Centralized Control and Mitigating Sybil Attacks:

By requiring a majority of nodes to agree on the validity of blocks, the 51% consensus mechanism prevents any single entity from gaining control of the network and manipulating data. This resistance to centralized control mitigates the risk of Sybil attacks, where malicious actors attempt to create multiple identities to gain an unfair advantage in the network.

Facilitating Data Sharing and Interoperability:

The 51% consensus mechanism enables data sharing and interoperability among blockchain networks. This interoperability is essential for integrating smart parking systems with other applications and services.

Enabling Smart Contract Execution:

The 51% consensus mechanism is a prerequisite for executing smart contracts on the local blockchain network. Smart contracts enable automated and trustless transactions, essential for managing payment processing and other smart parking functionalities.

Supporting Decentralized Data Management:

The 51% consensus mechanism aligns with the decentralized nature of the smart parking system. The system resists centralized control and promotes data privacy and security by distributing consensus power across multiple nodes.

In conclusion, Implementing 51% consensus in a local blockchain network, even within a single parking lot, provides several significant benefits. It enhances data integrity, network resilience, transparency, sharing, smart contract execution, and decentralized data management. These advantages are essential for building a secure, reliable, scalable smart parking system.

The smart parking system involves multiple stakeholders, including parking lot owners, service providers, and drivers. A decentralized consensus mechanism ensures that all these stakeholders have a say in the verification of data and the execution of smart contracts. This distributed power structure fosters collaboration and trust among stakeholders, reducing the risk of manipulation or disputes.

Moreover, a decentralized consensus mechanism can be integrated with other blockchain networks, enabling interoperability and expanding the system’s scope. For instance, the parking system could connect with a payment network to facilitate cryptocurrency payments or with a city’s data management system to integrate parking information with urban planning and traffic management.

3.1.3. Advantages of local blockchain management

Managing the local blockchain at the data link layer, where sensors operate, offers several advantages:

Efficiency: This approach simplifies data transmission by eliminating the need for sensors to send data directly to a centralized server or cloud storage. Instead, sensors can append their data to the local blockchain, reducing network congestion and improving data latency.

Security: By decentralizing data management, the local blockchain architecture reduces the risk of data breaches or unauthorized access. Data remains stored and managed within the WSN, limiting the exposure to external threats.

Scalability: As the number of sensors increases, the local blockchain can be scaled horizontally by adding more nodes to the network. This scalability ensures the network can handle the increasing data volume without compromising performance.

3.1.4. Data packet simplification

The management of the local blockchain at the data link layer may simplify data packets transmitted by the sensors in two ways:

Reduced Data Size: By directly storing data on the local blockchain, sensors can send fewer packets containing only the essential information, reducing the overall data overhead.

Efficient Data Aggregation: The local blockchain can aggregate data from multiple sensors, reducing data transmission frequency and optimizing network performance.

3.2. Simulation framework and high level functionalities

Ethereum provides various tools for developers to build decentralized applications (DApps) on the Ethereum blockchain. Some of these tools include:

Solidity: A high-level programming language used to write smart contracts on the Ethereum blockchain.

Remix: A web-based integrated development environment (IDE) for writing, testing, and deploying smart contracts.

Truffle: A development framework for building DApps on the Ethereum blockchain.

Ganache: A personal blockchain for Ethereum development that allows developers to test their smart contracts locally.

Web3.js: A JavaScript library that allows developers to interact with the Ethereum blockchain from a web application.

We focused on smart contract development during the simulation and used Solidity language to write the code. We tested our smart contract using Remix. So, the smart parking network user interface based on the blockchain platform is written in a robust programming language and tested in the Remix IDE environment, including the required functions, such as AddDriver, EnterParking, ExitParking, CostToPay, ChangeOwner, PayCost, etc.

Table 2
Parameters of the coordinator node in the network layer.

Attribute Value

Maximum children 250

Maximum routers 6

Route discovery timeout 10

Attribute	Value
Maximum children	250
Maximum routers	6
Route discovery timeout	10

Table 3

Physical, MAC, and application layers parameters.

Attribute	Value
Parameters of MAC layer
ACK waiting time (seconds)	0.05
Channel sensing time (seconds)	0.1
Max backoffs allowed	4
The smallest backoff exponent	3
The number of retransmissions	5
Parameters of the physical layer
Data rate (bps)	250
Bandwidth (kHz)	10
Min frequency (MHz)	30
Packet reception-power threshold (dB)	−85
Transmission band (GH)	2.4
Parameters of the application layer
Packet interval time/type (sec/constant)	1
Packet size/type (bits/constant)	480

Some of the designed functions are described below:

3.2.1. AddDriver

This function adds detailed drivers’ information as customers, whereby only the owner can complete it. The fields in this function include the driver’s blockchain address, driver’s name, license plate number, and driver’s first balance (based on the smallest unit of ether (Wei)).

3.2.2. ChangeOwner

This function can only be performed by the current owner of the contract, allowing the transfer of ownership of the contract to another blockchain address.

3.2.3. EnterParking

After receiving the driver’s blockchain address, this function records the time to enter the parking network in seconds according to the block.TimeStamp timer. The Block.TimeStamp is the time at which a block was created. The time specified in milliseconds has elapsed since the start of the Unix epoch. This function also deducts one unit from the number of empty parking spaces for each driver entry specified in the setParkingCapacity function.

3.2.4. ExitParking

This function obtains the driver’s address on the blockchain and records the departure time from the parking lot. In this function, the number of free parking spaces for the exit of each driver is increased by one unit.

3.2.5. IncrementBalance

The contract owner can only perform this function to increase the customer’s account balance. The data received includes the intended blockchain address and the smallest Ethereum-based unit (Wei) amount that can be added to the balance.

3.2.6. ToOwnerWallet & OwnerToOthers

These functions are used to transfer the account balance of the contract owner and the system operator to the owner’s wallet and to transfer the account balance of the contract owner to another person’s account.

3.2.7. PayCost

This function receives the driver’s blockchain address, calculates the entry and exit time, transfers the parking fee to the contract owner’s account, and deducts it from the driver’s account balance.

3.2.8. SetParkingCapaciy

In this function, the contract owner initializes the empty capacity for each smart parking lot. When the driver enters and exits, this initialization is automatically updated.

Figure 5.

The first scenario in simulation – the star topology.

3.2.9. OrderSend

This function returns the amount of available capacity by receiving the blockchain address of each smart parking lot. The driver and the smart parking network can use this information when requesting parking.

To comply with the General Data Protection Regulation (GDPR), a European data privacy law that includes the “right to be forgotten,” we added a section to the application code allowing users to access their records using smart parking. Users can modify their basic information with system approval, and some fields of blocks have a period in which they can erase the past so that the main chain does not get interrupted by keeping some encrypted information. For this purpose, users can delete all fields of the blocks stored for them except for the Block_ID, Previous Block_ID, and Driver_BC_Addr fields, which are encrypted.

4. Simulation results

Driven by the compelling results reported by Li et al. [13], which highlighted the exceptional performance of Zigbee mesh networks in terms of power efficiency, network longevity, and overall network functionality over traditional topologies, we employed this technology in our simulation to assess its applicability in our envisioned smart parking system.

Figure 6.

The second and third scenarios in simulation – the tree and mesh topology.

4.1. Simulation setup

Comprehensive simulations were conducted using the OPNET modeler to investigate the performance of the proposed blockchain-based smart parking system in a WSN. Three distinct network topologies were considered: star, tree, and mesh. These topologies were selected to evaluate the system’s adaptability to various network architectures and highlight the advantages of each topology.

4.2. Simulation parameters

To ensure consistent comparisons, identical parameters were applied across all three scenarios. These parameters encompassed packet size, data rate, maximum child nodes per local network, and additional configurations specified in Tables 2 and 3 for the application, network, MAC, and physical layers of both end nodes and the coordinator node.

4.3. Scenario 1: Star topology

The star topology, depicted in Figure 5, features a centralized structure where end nodes communicate directly with the coordinator node. This scenario employed 12 end nodes and a single coordinator node. The proposed algorithm was configured to broadcast data packets to all nodes. To further emulate real-world scenarios, the number of end nodes was expected to extend to 250 within the coordinator node’s configuration.

4.4. Scenario 2: Tree topology

The tree topology, illustrated in Figure 6, consists of hierarchical branching, with end nodes transmitting data packets to their parent nodes. This scenario involved 12 end nodes, six routers, and a single coordinator node. The router nodes facilitate data forwarding between the end nodes and the coordinator node. The coordinator node, in turn, broadcasts data packets to all nodes. To enable direct data transmission between end nodes, the multipath attribute in the coordinator node’s network layer was disabled.

4.5. Scenario 3: Mesh topology

The mesh topology, similar to the tree topology, allows for multiple paths between the end nodes and the coordinator node. This scenario employed the same number of end nodes and routers as scenario 2. However, the multipath attribute was enabled in the coordinator node’s network layer, enabling data packets to traverse multiple paths. This enhancement enhances network resilience and improves overall performance.

Figure 7.

Average network load in three topologies in bits per second.

Figure 8.

Throughput in three topologies (bits/sec).

Figure 9.

End-to-end delay in three topologies (bits/sec).

4.6. Performance metrics

The simulation analysis focused on three key performance metrics: average load, throughput, and end-to-end delay.

Average Load: This metric represents the average data traffic per local network. Figure 7 demonstrates the average load for the three topologies, with the star topology exhibiting lower values than the tree and mesh topologies. This difference stems from the centralized structure of the star topology, where data packets converge at the single coordinator node, potentially leading to congestion and reduced network efficiency.

Throughput: Throughput measures the maximum data rate that the network can sustain. Figure 8 reveals that the throughput of the star topology is significantly lower than that of the tree and mesh topologies. This disparity arises from the bottleneck effect of the centralized coordinator node in the star topology.

End-to-End Delay: End-to-end delay represents the time a data packet travels from an end node to the coordinator node and back. Figure 9 demonstrates that the end-to-end delay is lowest for the star topology, followed by the mesh and tree topologies. This outcome is attributed to the reduced number of hops involved in the star topology, minimizing the transmission time.

Average traffic Sent and Received: Figures 10 and 11 demonstrate the average traffic sent and received in the three topologies, showing a lower average traffic in the star topology compared to the mesh and tree topologies, attributed to the bottleneck effect of the centralized coordinator node.

Figure 10.

Traffic sent in three topologies (bits/sec).

Figure 11.

Traffic received in three topologies (bits/sec).

To assess Zigbee’s performance in our proposed infrastructure, we conducted a simulation, and the result is shown in Table 4. The primary purpose of this simulation was to evaluate Zigbee’s performance in terms of block creation and acceptance times. These parameters are crucial for ensuring the efficient operation of Zigbee-based wireless sensor networks.

The results of this simulation demonstrate that Zigbee exhibits competitive block creation and acceptance times, particularly when compared to other low-power WSN networks like LoRa and SigFox. The relatively short block creation time indicates the network’s efficiency in assembling data packets, while the fast block acceptance time reflects the network’s responsiveness in handling incoming data. These characteristics make Zigbee suitable for applications prioritizing energy efficiency and rapid data transfer, such as industrial automation and environmental monitoring.

However, it’s important to note that Zigbee’s performance lags behind that of high-bandwidth networks like Wi-Fi and Cellular. This difference can be attributed to the inherent constraints of low-power WSNs, which prioritize energy efficiency over data transmission speed. High-bandwidth networks like Wi-Fi and Cellular may be more suitable for applications with high data rates, such as video streaming and real-time data acquisition.

In summary, the performance of Zigbee in terms of block creation and acceptance times makes it a viable choice for low-power WSN applications that prioritize energy efficiency and rapid data transfer. However, high-bandwidth networks like Wi-Fi and Cellular may be more appropriate for applications demanding high data rates.

4.7. Performance analysis and outlook

The simulation results indicate that the mesh topology outperforms the tree and star topologies regarding throughput and end-to-end delay. This superior performance stems from the multipath capability of the mesh topology, which allows data packets to traverse multiple routes, effectively distributing traffic and enhancing network resilience. Moreover, the mesh topology’s decentralized structure reduces the reliance on a single coordinator node, minimizing potential bottlenecks and improving overall network efficiency.

In conclusion, the proposed blockchain-based smart parking system demonstrates remarkable performance in a mesh topology setting. The multipath capability, decentralized structure, and reduced latency make the mesh topology the most suitable architecture for such applications. As the network size expands, the mesh architecture becomes increasingly advantageous, ensuring efficient data transmission and reliable operation.

Table 4
Performance comparison of Zigbee and other WSN networks.

Network type Block creation time (seconds) Packet transmission time (seconds) Block acceptance time (seconds)

Zigbee 0.6085906 1.92 0.29127817

6LoWPAN 0.2163089 7.5 0.10251357

LoRa 0.0909091 9.6 0.0090909

SigFox 0.0769231 48 0.0076923

Wi-Fi 0.0333333 0.0068571 0.0440337

Bluetooth 0.0652174 0.48 0.125

Cellular 0.0416667 0.0048 0.0884438

Network type	Block creation time (seconds)	Packet transmission time (seconds)	Block acceptance time (seconds)
Zigbee	0.6085906	1.92	0.29127817
6LoWPAN	0.2163089	7.5	0.10251357
LoRa	0.0909091	9.6	0.0090909
SigFox	0.0769231	48	0.0076923
Wi-Fi	0.0333333	0.0068571	0.0440337
Bluetooth	0.0652174	0.48	0.125
Cellular	0.0416667	0.0048	0.0884438

5. Conclusion

This paper has presented an innovative blockchain-based smart parking system that addresses the challenges of urban traffic congestion and inefficient parking management. The proposed system utilizes a three-tier architecture: local sensor networks, a local blockchain network of smart parking servers, and a public blockchain network. Zigbee technology creates lightweight and energy-efficient local sensor networks across each parking lot. The local blockchain network implements a novel consensus algorithm that eliminates the computationally intensive Proof-of-Work (PoW) mechanism, ensuring efficient block creation and consensus. The system also integrates with the Ethereum public blockchain network to facilitate cryptocurrency-based online payments. Simulation results using a Zigbee sensor network demonstrate the feasibility and effectiveness of the proposed system in managing parking information and facilitating real-time transactions. The simulation results demonstrate that the proposed system can achieve competitive block creation and acceptance times compared to low-power WSN networks like LoRa and SigFox. This is due to the efficient consensus algorithm and the lightweight nature of Zigbee. However, the system’s performance lags behind high-bandwidth networks like Wi-Fi and Cellular. This difference can be attributed to the inherent constraints of low-power WSNs, which prioritize energy efficiency over data transmission speed. High-bandwidth networks like Wi-Fi and Cellular may be more suitable for applications with high data rates. While the proposed system offers significant data security, scalability, and decentralization advantages, further optimization is necessary to enhance its processing speed. Specifically, addressing the overhead associated with the consensus process among 51% of nodes is crucial for improving the system’s responsiveness. Ongoing research efforts are focused on addressing this challenge while maintaining the system’s core strengths.

Future work will involve comprehensive performance evaluations under real-world conditions and integrating the system with a public blockchain network. To achieve this, collaboration with relevant government agencies and industry partners is essential to secure scientific and financial support. Integrating the system with a public blockchain network will further enhance its functionality and interoperability. This will enable the system to leverage the security and immutability of the blockchain to provide a more robust and trustworthy platform for managing parking data and transactions. The proposed blockchain-based smart parking system demonstrates the potential to revolutionize urban mobility and parking management. With further development and optimization, this system has the potential to become a ubiquitous and essential component of smart cities around the world.

Footnotes

Conflict of interest

The authors have no conflict of interest to report.

References

Ali

Munwar Iqbal

Jabbar

Nabeel Asghar

Raza

Al-Turjman

, VABLOCK: A blockchain-based secure communication in V2V network using ICN network support technology, Microprocessors and Microsystems 93 (2022), 104569, ISSN 0141-9331. doi:10.1016/j.micpro.2022.104569.

Atiqoh

J.L.

Moesrami Barmawi

Afianti

, Blockchain-based smart parking system using ring learning with errors based signature, in: 2022 6th International Conference on Cryptography, Security and Privacy (CSP) , 2022, pp. 154–158. doi:10.1109/CSP55486.2022.00036.

Dorri

Kanhere

S.S.

Jurdak

, Blockchain in Internet of Things: Challenges and solutions, 2016, arXiv preprint arXiv:1608.05187.

Geng

Cassandras

C.G.

, A new ‘smart parking’ system based on optimal resource allocation and reservations, in: Proc. 14th Int. IEEE Conf. Intell. Transp. Syst , ITSC, 2011, p. 979–984.

Geng

Cassandras

C.G.

, New ‘smart parking’ system based on resource allocation and reservations, IEEE Trans. Intell. Transp. Syst. 14(3) (2013), 1129–1139. doi:10.1109/TITS.2013.2252428.

Hammoodi

I.S.

Stewart

B.G.

Kocian

McMeekin

S.G.

, A comprehensive performance study of OPNET modeler for ZigBee wireless sensor networks, in: 2009 Third International Conference on Next Generation Mobile Applications, Services and Technologies, 2009, pp. 357–362. doi:10.1109/NGMAST.2009.12.

Imbugwa

G.B.

Mazzara

Distefano

, Smart parking solution for enterprise on Ethereum, in: 2021 International Conference “Nonlinearity, Information and Robotics” (NIR) , 2021, pp. 1–6. doi:10.1109/NIR52917.2021.9666126.

Jabbar

Fetais

Kharbeche

Krichen

Barkaoui

Shinoy

, Blockchain for the Internet of vehicles: How to use blockchain to secure vehicle-to-everything (V2X) communication and payment?, IEEE Sensors Journal 21(14) (2021), 15807–15823. doi:10.1109/JSEN.2021.3062219.

Kakkar

et al., PADaaV: Blockchain-based parking price prediction scheme for sustainable traffic management, IEEE Access 10 (2022), 50125–50136. doi:10.1109/ACCESS.2022.3173162.

10.

Kushch

Prieto-Castrillo

, Blockchain for dynamic nodes in a smart city, in: 2019 IEEE 5th World Forum on Internet of Things (WF-IoT) , Limerick, Ireland, 2019, pp. 29–34. doi:10.1109/WF-IoT.2019.8767336.

11.

Pei

Liao

et al., Blockchain meets VANET: An architecture for identity and location privacy protection in VANET, Peer-to-Peer Netw. Appl. 12 (2019), 1178–1193. doi:10.1007/s12083-019-00786-4.

12.

Wang

Yang

, Secure and efficient parking management system using local blockchain, Sensors 22(24) (2022), 12342. doi:10.3390/s22249990.

13.

Wang

Yang

, Performance evaluation of ZigBee-based wireless sensor networks, International Journal of Distributed Sensor Networks 22(24) (2022), 12342.

14.

Lin

Xia

Tang

Zheng

, A parking sharing network over blockchain with proof-of-planned-behavior consensus protocol, IEEE Transactions on Vehicular Technology 71(8) (2022), 8124–8136. doi:10.1109/TVT.2022.3173989.

15.

Lin

Yang

Wang

, Efficient block pruning algorithm for local blockchain-based smart parking system, International Journal of Distributed Sensor Networks 18(12) (2022), 1550185.

16.

Marghescu

Pantazica

Brodeala

Svasta

, Simulation of a wireless sensor network using OPNET, in: 2011 IEEE 17th International Symposium for Design and Technology in Electronic Packaging (SIITME) , 2011, pp. 249–252. doi:10.1109/SIITME.2011.6102728.

17.

Pham

T.N.

Tsai

Nguyen

D.B.

Dow

Deng

, A cloud-based smart-parking system based on Internet-of-things technologies, IEEE Access 3 (2015), 1581–1591. doi:10.1109/ACCESS.2015.2477299.

18.

Schaefer

Groß

Kays

, Energy consumption of 6LoWPAN and Zigbee in home automation networks, in: 2013 IFIP Wireless Days (WD) , 2013, pp. 1–3. doi:10.1109/WD.2013.6686463.

19.

Seebacher

Schritz

, Blockchain Technology as an Enabler of Service Systems: A Structured Literature Review, Springer International Publishing, Cham, 2017, pp. 12–23.

20.

Vishwakarma

Nahar

Das

, LBSV: Lightweight blockchain security protocol for secure storage and communication in SDN-enabled IoV, IEEE Transactions on Vehicular Technology 71(6) (2022), 5983–5994. doi:10.1109/TVT.2022.3163960.

21.

Yang

Chen

Yang

, Decentralized parking management system using local blockchain and smart contract, Sensors 23(15) (2023), 4443.

22.

Zhang

Chen

Wang

, Decentralized data validation scheme for local blockchain-based smart parking system, Sensors 22(24) (2022), 12334.

23.

Zhang

Pan

Liang

, Design of “Blockchain Plus” intelligent parking matching guidance system, in: 2021 International Conference on Computer, Blockchain and Financial Development (CBFD) , 2021, pp. 236–240. doi:10.1109/CBFD52659.2021.00053.

24.

Zhang

Kang

Chen

, Secure and reliable parking protocol based on blockchain for VANETs, in: 2021 IEEE Wireless Communications and Networking Conference (WCNC) , 2021, pp. 1–6. doi:10.1109/WCNC49053.2021.9417281.

Secure storage of dynamic node information in smart parking using local blockchain

Abstract

Keywords

1. Introduction

2. Related work

3. The system layers and operations

3.1.1. The rationale for updating fee at step 5 rather than step 1

3.1.2. Rationale for 51% consensus in a local blockchain network

3.1.3. Advantages of local blockchain management

3.1.4. Data packet simplification

3.2. Simulation framework and high level functionalities

Table 2 Parameters of the coordinator node in the network layer. Attribute Value Maximum children 250 Maximum routers 6 Route discovery timeout 10

3.2.2. ChangeOwner

3.2.3. EnterParking

3.2.4. ExitParking

3.2.5. IncrementBalance

3.2.6. ToOwnerWallet & OwnerToOthers

3.2.7. PayCost

3.2.8. SetParkingCapaciy

4. Simulation results

4.2. Simulation parameters

4.3. Scenario 1: Star topology

4.4. Scenario 2: Tree topology

4.5. Scenario 3: Mesh topology

Footnotes

Conflict of interest

References

Table 2
Parameters of the coordinator node in the network layer.

Attribute Value

Maximum children 250

Maximum routers 6

Route discovery timeout 10