Evaluation of a Lightweight IoT Protocol for Intelligent Parking Management in Urban Environments ^†

Abstract

This work presents the design and evaluation of a distributed IoT protocol for intelligent parking management. It exploits the communication protocol LoRa and is designed to operate fully autonomously, without requiring Internet connectivity, enabling real-time parking slot detection and allocation through long-range wireless communication. The protocol also includes an optional MQTT-based synchronisation layer to support data exchange between gateways and with a central collector, allowing for telemetry, system monitoring, and analytics. We performed a set of experiments, proving that the protocol holds system resilience and scalability, which are key aspects for deployment in urban environments with unreliable or limited network access. We also observed a significant reduction in parking search time while preserving acceptable levels of system latency. To complete our evaluation, we deployed, in our laboratory, a test-bed made by ESP32-based nodes and simulated gateway breakage and replacement, in order to prove the fault recovery capabilities of the entire network. Finally, we conducted a few empirical stress tests simulating high communication traffic and interactions, confirming acceptable effectiveness and stability for real urban contexts.

1. Introduction

In recent years, the exponential growth of smart cities has placed urban infrastructure under unprecedented pressure. Cities are facing mounting demands to optimise energy usage, reduce pollution, and improve the quality of life for citizens. Among the critical domains of urban transformation, mobility and traffic flow have become primary concerns. A particularly persistent and unresolved challenge is the efficient management of parking resources. Studies have shown that up to 30% of urban traffic in large cities is caused by drivers looking for available parking spaces [1], which not only increases travel time and driver frustration but also significantly contributes to air and noise pollution. Recent research further highlights the direct relationship between parking search time and the deterioration of urban air quality [2], making parking optimisation a key priority for modern cities.

Although numerous parking management systems have been proposed, most are costly infrastructures based on tailor-made closed spaces that make use of dense sensor networks [3,4] or cloud-dependent services, with the assumption of uninterrupted Internet access. These dependencies pose critical challenges related to scalability, operational costs, and vulnerability to network outages. Additionally, many existing systems fail to effectively exploit the advantages of emerging long-range, low-power communication technologies such as LoRa, which offer the potential to decentralise system logic and reduce reliance on cloud-based processing.

In previous works [5,6], ChirpPark has been introduced as an IoT-based parking solution that uses LoRa (Long Range) and MQTT (Message Queuing Telemetry Transport) protocols to enable real-time, distributed parking space allocation. The proposed system architecture was based on ESP32-enabled vehicles that interact with gateways, deployed on traffic lights or streetlights, which communicate with embedded parking sensors. This architecture can operate even without an active Internet connection, exploiting a low-power network protocol called LoRa. Nevertheless, the original ChirpPark architecture was in a first-phase design. In spite of of feasibility in offline environments and low-power operation in mind, the original protocol implementation attempt revealed several limitations, such as high latency in parking spot updates, vulnerability to packet collision in high-density areas, lack of synchronisation between multiple gateways, and excessive use of flash memory leading to wear and reliability concerns.

1.1. Main Contributions

In this work, we present a revisited ChirpPark protocol by including a series of enhancements and several architectural improvements:

• A compact data structure for dynamic parking slot management, designed for low-memory devices, such as micro-controllers;
• A reservation broadcasting mechanism for avoiding multi-gateway collisions;
• Refined data transmission protocols, optimised for low-bandwidth LoRa environments;
• As we highlight in the remaining part of this work, the creation of a network between vehicles and different infrastructures through the LoRa technology allowed us to avoid the use of an Internet connection (except for external infrastructure monitoring and management);
• The refined version of ChirpPark allows vehicles to communicate directly with gateways with high efficiency as indicated in the experimental results; moreover, gateways act as a bridge between vehicles and sensors placed in each parking lot, therefore contributing to a significant reduction in network traffic and improving the system’s resilience with single-node failures;
• We also integrated the support for MQTT to be optionally used for telemetry and advanced analytics.

Furthermore, concerning the experimental validation,

• We validated our solution via a few laboratory tests with ESP32-based nodes;
• We assessed the performance of ChirpPark using a LoRa network simulator that allowed us to execute the code of the physical communication layer; then we extracted metrics, such as message delivery latency, battery consumption, and message collision, and evaluated fault tolerance under specific load conditions.

As we highlight in the section concerning related work, there are a few solutions employing LoRa communications, and, to the best of our knowledge, only one of them provides a reservation mechanism as in our work. Nevertheless, the latter also relies on some different connectivity protocols to support some of the core functionalities. In our solution, instead, as discussed in the rest of the manuscript, the use of different communication technologies is integrated but it can be used optionally to perform data analytics operations along with MQTT.

1.2. Main Limitations

As we further highlight in the rest of the manuscript, the current main limitation of this work is represented by the fact that the system is not yet deployed in a real environment in our city, due to administrative delays. This aspect did not allow us to perform further experimental analysis and, in addition, a fine tuning of the system itself. We further discuss this aspect in the Conclusion section.

1.3. Organisation of the Manuscript

The remainder of this paper is structured as follows. Section 2 deals with related works. Section 3 describes the reference scenario and the main actors of the ChirpPark architecture. Section 4 presents the new ChirpPark architecture and protocol design. Section 5 discusses the experimental setup and performance evaluation. Section 6 concludes the paper and outlines directions for future research.

2. Related Works

In this section, we discuss a number of different IoT-based solutions for parking systems, in order to provide an insight into the main features of such systems and to highlight the similarities and differences with our work.

There exist several recent works that survey the recent literature about IoT-based parking systems [7,8,9]. The work in [7] presents an analysis of the recent literature about the smart parking solutions. They point out the need to develop such parking solutions to reduce gas emissions. In particular, the authors analysed smart parking solutions from a technical perspective, i.e., the adopted systems and sensors. In particular, the authors present an interesting classification of several existing works on the basis of the adopted communication technology. In fact, among the work presented in the survey, the authors cite the adoption of protocols like LoRa (adopted in our work), ZigBee, and NB-IoT.

In [10], the authors present an edge computing-enabled smart parking system that prioritises security and energy efficiency in IoT deployments. The research addresses critical challenges related to data privacy and energy consumption in distributed parking management systems. The proposed architecture leverages edge computing nodes to process parking data locally, reducing bandwidth requirements and improving response times while implementing robust security mechanisms to protect sensitive user and system information. The authors demonstrate significant improvements in energy efficiency compared to cloud-dependent solutions.

The authors of [8] analysed the adoption of IoT technology to support parking in smart cities. They reviewed several research papers carried out in the years 2018 to 2019 and analysed many different concerns: sensors, cloud integration and mobile applications, along with the main objectives of such work (saving time, energy, fuel and, as a consequence, carbon footprint). They also found an interesting common aspect represented by the fact that disabled people are not considered in many parking systems. Moreover, they underline the need for a global parking system that, at the time of writing, does not exist.

The paper [9] analyses the need to realise smart parking systems, as finding an empty parking place in a crowded area is expensive and time-consuming. The basic requirement illustrated by the authors is that vehicles can use smart parking systems to obtain real-time parking space information. The authors provide an in-depth analysis of smart parking systems in terms of technology and sensors used, networking techniques, and some other important aspects. They also highlight, through further analysis, that the knowledge of the environment is important to design a proper parking system with well-defined properties, such as scalability, fault tolerance, and so on.

The author of [11] addresses the problem of traffic congestion in urban areas by presenting the design of an automated smart parking management system that helps the driver find a suitable parking space very quickly. The key point of this work is that the author addresses the problem of real-time detection of improper parking and an automatic collection of parking charges. To this end, the author proposes a prototype of an IoT-based parking system that integrates an integrated component (the parking meter) to address the above issues related to improper marking. The work also addresses the need to provide smart parking management in the city. For the communication aspects, they employ a Wi-Fi access point for the communication between sensors and a local parking management system (kind of gateway) to send data to a central parking management system.

In the recent work [12], the authors present the design of a parking system based on the concept of parking space detection by using sensors in IoT environments. The system is very simple. For example, the authors do not implement any kind of reservation, which, instead, represents a central point in our work. The sensors send parking statuses to an Internet web page, which allows users to verify free parking spaces. The authors arranged a simple communication module, the ESP8266 Wi-Fi module, to send the sensor’s data to an IoT platform.

In [13], the authors present a feasibility study for smart parking architecture to offer new services by exploiting IoT technologies. The authors try to define a set of requirements and technical choices that can be useful to implement parking systems that exploit innovative aspects. They analyse, for each technology, the possible application/problem, the state of the art, and the current solutions. Then, they designed a parking system by applying a technique called “outline design” in order to integrate the technical specifications and to define the main building blocks of the system by focusing on the information processing between the different blocks. They provided experiments to show that the proposed reservation-based parking policy offers a number of different advantages to reduce traffic congestion. The interesting part of the work is the design of the resulting system, which makes use of the LoRa protocol, as well as several gateways. However, the system presented by the authors includes the additional use of Internet connectivity. In our system, the employment of Internet connectivity is optional, depending on the data analytics operations.

The work in [14] represents an IoT-based smart parking system specifically designed to provide information about the status of parking spots offered in on-street parking areas The authors focus on several key characteristics of well-designed IoT parking systems: scalability and interoperability for the heterogeneity of IoT devices, low energy consumption, and timely prediction of the availability of the parking spots. The authors employed the Social IoT (SIoT) Lysis environment to create virtual entities interacting in place of the real entities of the parking system; this characteristic allowed them to address the interoperability issues among heterogeneous IoT devices. They used magnetometer sensors to detect vehicles in parking spots; moreover, the sensors’ data are collected through concentrators that cover the whole parking area through short-range wireless communication, Wi-Fi. They also developed a control dashboard to provide data analytics, which is accomplished by an Android app. They also presented a few experiments to show the behaviour of the system in terms of timely detection of vehicles and identification of vehicle IDs to perform payments. We observe that one of the main differences with our work is represented by the use of the long-range communication protocol LoRa.

A further recent work [15] presents a parking system solution based on IoT and Radio-Frequency Identification (RFID) technology to check-in/check-out cars under the control of RFID readers/ tags with additional features of automatic billing. The adoption of an RFID module for vehicle identification represents, in fact, an interesting aspect of the solution designed by the authors. Nevertheless, they do not specify the details about the communication technology.

Similarly, the authors of [16] present an enhanced IoT-enabled smart parking system that integrates RFID technology for advanced vehicle identification and parking spot management. The system combines RFID tags with IoT sensors to provide accurate detection of parking occupancy while addressing challenges related to erroneous parking identification. The proposed solution demonstrates how RFID integration can complement traditional sensor-based approaches, offering improved reliability in vehicle detection and automated identification processes for billing and access control purposes.

The authors of [17] focus on the implementation of a cost-effective solution for an IoT parking system in Dhaka city, where finding a parking zone is difficult and time-consuming. They designed a parking system based on the platform NodeMCU ESP32 that represents a low-cost technology with respect to Arduino or Raspberry Pi-based solutions. The authors prove that the system allows the smart city operators to develop a parking system in any urban area very quickly. They also employ the Google Firebase technology https://firebase.google.com/ (accessed on 24 July 2025) for communication, authentication, and data collection.

In [18], the authors presented the implementation of a parking system composed of an Android application and several on-site components—parking sensors and a Raspberry Pi as the processing platform—to allow users to search and reserve nearby parking spaces. An interesting part of the work is represented by the possibility for the users to receive push-based notifications of parking locations in real-time. Finally, the system assists the users during parking, as an alert is sent if the car is not parked within the allotted boundaries.

The authors of [19] present a solution to manage urban parking management by means of IoT technologies. The developed system is made by a cloud platform and a mobile app to monitor in real-time the availability of parking spaces, optimise occupancy and reduce congestion. Moreover, it exploits ultrasonic sensors to identify vehicles in the parking slots. Data is sent to a cloud server, where it is processed and made accessible by users via an application. The solution is designed to be cost-effective and scalable. The proposed system is used in controlled environments, closed parking “by bars” and, in addition, it allows the reservation of the parking before arrival.

In [20], the authors present a project to develop a parking system with an STM32 board and the LoRa communication technology. They connect the STM32 with the LoRa module and an ultrasonic sensor to implement the monitoring node as well as a receiver node that receives the data sent by the monitoring node via an antenna and a NuttyFi ESP8266 mainboard. The system is completed with a dashboard that shows the occupied and free parking spots. The authors point out that the system is cost-effective and practical. Nevertheless, the system is very simple with respect to our system, where it offers more functionalities such as reservation. However, the authors do not address the problem of scalability.

The authors of [21] present a comprehensive smart parking system that integrates dynamic pricing mechanisms with edge-cloud computing architecture and LoRa communication technology. The system employs multi-parametric parking slot sensor nodes that combine various sensing technologies to enhance detection accuracy. The authors demonstrate how edge computing can reduce system latency while maintaining real-time responsiveness, and their dynamic pricing model adapts to parking demand patterns to optimise utilisation. The integration of LoRa technology ensures long-range, low-power communication suitable for large-scale urban deployments.

In [22], the authors present the design of a parking management system made by using LoRa technology. The system divides the parking area into specific zones, each associated with specific parking requirements, along with a network of sensors. Data are transmitted from sensors to the central system by the LoRa protocol due to its extensive coverage. The parking system shows, through LCD screens, a real-time overview of available spaces to the driver and to the parking manager. They also developed a mobile app on the Blynk IoT platform to provide a complete occupancy view to the driver and the manager. An interesting part of the system is that the authors developed another Android app that supports user identification and real-time monitoring of vehicle entry and exit times. The authors performed a series of tests proving that the system is also reliable under different conditions. Nevertheless, in this work, the authors do not provide the reservation system, which we have addressed in our work.

In [23], the authors present a comprehensive analysis of LPWAN technologies for IoT-enabled parking management systems. The research provides a comparative evaluation of different LPWAN protocols, including LoRa, Sigfox, and NB-IoT, examining their suitability for parking applications in terms of range, power consumption, and data throughput. The authors demonstrate how LPWAN technologies can enable cost-effective, large-scale parking deployments while maintaining low operational costs and extended battery life for sensor nodes.

Related to the LPWAN networks, the authors of [24] present an IoT-based smart parking solution that utilises Sigfox technology as the primary communication protocol. The research focuses on the implementation of Sigfox networks for parking sensor connectivity, demonstrating the protocol’s advantages in terms of ultra-low power consumption and wide area coverage. The authors provide experimental validation of Sigfox performance in European smart parking deployments, highlighting its cost-effectiveness and reliability for large-scale IoT parking applications where minimal data transmission requirements align with Sigfox capabilities.

In [25], the authors present an IoT-based parking system solution where communication is based on the Long-Range Wide Area Network (LoRaWAN) sensor, which is a low-power, wide-area networking protocol built on top of the LoRa radio modulation technique. The advantage is that such a protocol connects devices to the Internet and is able to manage communication between sensors and network gateways. As it is well known and is highlighted several times in this manuscript, LoRa helps to optimise the battery life, cost range and capacity. In this solution, the software architecture is composed of a cloud server and a local server that satisfy the requests from web clients and mobile clients. Nevertheless, there is no reservation in the presented solution. Moreover, the authors do not show clearly in what measure the system is scalable and reliable, as, for example, the local server may represent a single point of failure.

The article [26] presents an IoT parking system that makes use of RFID readers to register the driver at the entrance of the parking area. The RFID reader is connected to a Raspberry Pi 3, while an RFID card enables the identification of the vehicle and manages access to the parking lot. The system also includes reservation through the app, and the driver can reach the assigned parking lot with the assistance of Google Maps. Once the user arrives at the parking lot, they use the RFID card to authenticate themselves at a barrier equipped with an Arduino Uno and servo motors. The system is composed of a local unit, a cloud-based server, and a cloud software.

To the best of our knowledge, with respect to our work, only ref. [13] includes the LoRa technology along with a reservation system. Nevertheless, the employment of further communication technologies for the Internet connectivity is not optional but is integrated in the system for core functionalities. Moreover, the design of our protocol has been specifically driven by several crucial requirements, such as scalability and resilience. Moreover, we provided a flexible management of parking areas to address highly dynamic environments such as public car parks in a city where it is not possible to make a reservation, due to highly changeable conditions.

3. Scenario and System Components

Figure 1 represents the main scenario of the proposed system, highlighting the involved parties as well as the adopted communication protocols.

In our system we, identified three main actors: vehicles, gateways (streetlights, traffic lights, signals, etc.) and parking sensors. All the elements exchange messages through the LoRa protocol [27]. In particular, as we explain in the next section of this work, the protocol can integrate the use of MQTT when an Internet connection to a remote server is available or required. It can happen, for example, when a custom application is developed for real-time observation or data analysis (see Section 4.2 and Section 5.3).

In the remainder of this section, we provide the necessary details about the functionalities of the three actors/components before they are introduced.

3.1. Vehicles

In the designed system, every vehicle that aims at exploiting the parking system must be equipped with a (low-cost) micro-controller capable of exchanging messages through the LoRa protocol. The devices can be integrated in the vehicle or put into it as an external one; thus, it can be used in any type of vehicle.

Vehicles represent, in fact, agents of the system that dynamically join and exit the parking system.

A vehicle is able to perform two basic operations:

• Sending a request for a parking space by contacting the nearest gateway;
• Sending a request to cancel a reservation by specifying a previously reserved spot; this will happen in the case the parking spot is no longer needed.

Moreover, the vehicle can optionally send its own GPS data in order to improve the lookup algorithm; in this manner, the gateway will focus on the area around the latter’s location. Conversely, the gateways will perform the search using its own GPS coordinates.

3.2. Gateways

The main characteristic of a gateway is represented by the fact that it can be installed on existing urban infrastructures, such as traffic lights, signals, bridges or similar. In these places, providing a power line to power such devices is always possible. The role of a gateway is crucial since it acts as an intermediary between parking sensors and vehicles. Firstly, a gateway keeps track of the managed parking slots by storing geographical locations and status. Secondly, it looks up and assigns available parking slots, once requested by vehicles, sending suitable responses. To this aim, any gateway must be able to synchronise its own information about parking slots with near gateways. In particular, it must sync the status of contested parking slots.

As an optional requirement, our protocol supports gateways in collecting specific data with MQTT integration in order to perform remote data analysis and presentation about the parking system (see Section 4.2 and Section 5.3). In order to explain this aspect, we depict, in Figure 1, a cloud server that communicates with a couple of gateways.

An important aspect of the gateway consists of keeping a local and volatile management table, which is dynamically updated on the basis of the periodic status update received by the parking sensors. Such a simple feature is essential in such a distributed system to allow new nodes (gateway) to join the network and, conversely, to replace the broken nodes by other working ones.

Moreover, when a parking slot intersects the operative area of two or more gateways, a sync mechanism is performed to prevent double reservation.

3.3. Parking Spot Sensors

As parking spot sensors, low-power devices equipped with magnetometers are used to detect the possible presence of a vehicle in a parking slot. They can be used inside any type of parking, e.g., street or building parking. The only obvious constraint is represented by the availability of communication between the parking slots and at least one gateway. They can be installed at the centre of each parking spot and powered by a battery. Optionally, they can be recharged via solar panel systems, if available.

Based on a few empirical experiments and research works [28,29,30], we found that the centre position of the parking slots also allowed us to maximise detection accuracy in the presence of certain parking scenarios, for instance, front-parking, reverse-parking, pass-through-parking, double-parking, and so on, as well as enhancing physical durability. Moreover, it allows us to minimise the risk of damage due to vehicle manoeuvres.

The main responsibility of a parking spot sensor is represented by periodically sending the assigned parking slot status. It is performed by transmitting its status to the nearest gateways once there is a status change. Moreover, its second responsibility is represented by periodically sending messages that notify of the existence of the parking slot as well as the correct operational status. This operation allows the gateways to populate their management tables.

We remark that the periodic notification represents a crucial aspect of the designed parking system. Indeed, it allows for easy recovery from a fault, because it helps gateways to rebuild their management table and detect irregular reservations. Moreover, it is also used as a “heartbeat” signal, helping the system’s administrators track possible faulty devices. The time elapsed between a transmission and the next one can be defined during the installation process. Its fine-tuning is crucial as it affects both system integrity and sensor battery life; therefore, it must be chosen accordingly.

Finally, the maintenance of active communication with the gateway enables real-time monitoring of the parking infrastructure and supports dynamic spot assignment.

4. Communication Protocol

In designing the communication protocol for the designed system, we defined two main types of packets.

In particular, we defined six different packets managed by the LoRa protocol, and a different packet defined by the MQTT protocol. While the main functionalities of the system are implemented through LoRa packets, the packet defined through MQTT is necessary to implement real-time remote monitoring and analysis, as we explain later in Section 4.1 and Section 4.2.

4.1. LoRa Packets

The packets managed by the LoRa protocol are summarised in the first six rows of

Table 1. Packets Defined for The Communication Protocol.

No.	Name	Sender	Receiver
1	ParkRequest	vehicle	gateways
2	ParkResponse	gateway	vehicle
3	CancelReservation	vehicle	gateways
4	SensorUpdate	parking sensor	gateways
5	HeartBeat	heartbeat	gateways
6	UpdateParkingSpotStatus	gateway	gateways
7	MQTT	gateway	any (cloud) server

and discussed below.

A (1) ParkRequest Packet (Figure 2) is sent by any vehicle to request a parking spot lookup, which is handled by gateways. It includes several pieces of information: the vehicle identifier; the timestamp of the request; and optionally, GPS coordinates encoded in fixed-point integer format, limited to the seventh decimal unit, to achieve centimetre-level spatial precision while optimising memory usage and bandwidth. The message is sent to all the gateways within range that maintain a list of available parking spots and process the request.

When a gateway receives a ParkRequest packet, it executes a lookup algorithm based on its internal management table and populates and sends a (2) ParkResponse packet (see Figure 3): (i) If a spot is available, the field request_status is set to 0x01 and the packet will include information about the gateway’s unique ID, the assigned parking spot’s ID, coordinates, and estimated distance. Finally, the target parking space is internally marked as assigned. (ii) Otherwise, the gateway replies with all empty fields except for response_status, which will be set to 0x00.

We observe that multiple responses from different gateways can be sent to the vehicles, but the latter will only accept the first one. If a response with a negative lookup result is received, the vehicle will automatically request a parking space three more times and, in case of multiple failures, an error message will be shown to the user.

Let us suppose that the user decides not to park before physically occupying the parking space. In that case, a cancellation intent can be sent using the (3) CancelReservation packet (see Figure 4), allowing all the interested gateways to mark the target parking spot as available again.

When a parking sensor detects a change, such as a vehicle entering or exiting the spot, a (4) SensorUpdate packet (Figure 5) is transmitted, which includes the parking spot identifier, updated status, and timestamp.

Moreover, we introduced a (5) HeartBeat packet having the same structure of the SensorUpdate packet (see Figure 5) with the aim of maintaining the presence and current status of the parking sensors at regular intervals. The type of the message is 0x05, and it is essential to allow the gateway to use these signals to verify the ongoing activity of each node. If no heartbeat is received from a specific parking spot for a specified duration, the corresponding entry is removed or flagged as inactive from the gateway’s internal parking list.

Finally, the (6) UpdateParkingSpotStatus (see Figure 6) packet is instead used to propagate any change in status of parking spots across all the gateways. Whenever a reservation or release event occurs, the gateway that is responsible for the update will broadcast the new status using this packet. The structure embeds the current metadata of the parking spot through an internal ParkingInfo struct, enabling all other gateways to synchronise their state tables accordingly and prevent conflicting assignments. The struct ParkingInfo encapsulates all the essential metadata required to identify a parking spot, determine its geographical location, track its current status, and timestamp the latest update. This mechanism guarantees consistent and conflict-free status propagation across the system, even under conditions of intermittent connectivity and constrained computational resources. These data structures and communication patterns reflect a minimal yet robust protocol design, optimised for constrained environments with limited memory and intermittent connectivity, while ensuring reliability and scalability in smart parking applications.

In-Memory Management Table at the Gateway

Each gateway maintains a volatile, compact table in RAM that stores one record per parking spot. The table is rebuilt and refreshed from periodic SensorUpdate and HeartBeat messages and is kept consistent across gateways through UpdateParkingSpotStatus broadcasts (see Figure 6 and Table 1). This mechanism allows new gateways to join and failed ones to be replaced, while preventing conflicting assignments in areas covered by multiple gateways.

We use a fixed-size, packed schema (ParkingInfo) that mirrors the metadata embedded on a wire within the UpdateParkingSpotStatus packet. The record comprises the following for a total of 17 bytes per spot: parking_id (4 B), latitude (4 B), longitude (4 B), status (1 B), and timestamp (4 B). Coordinates are encoded as fixed-point integers with seven decimal digits (${10}^7$) to reduce memory and bandwidth without sacrificing spatial resolution. With about 10,000 bytes available for this table, a gateway can hold approximately 10,000/17 ≈ 588 spots.

• Insert/update: on SensorUpdate, the gateway inserts (if new) or updates the entry and refreshes the timestamp. When a status changes, it broadcasts an UpdateParkingSpotStatus so neighbouring gateways synchronise their copy.
• Heartbeat and expiry: HeartBeat carries the same payload shape and is used to maintain liveness; missing heartbeats beyond a timeout mark the entry as inactive.
• Reservation: When a ParkRequest arrives, the gateway selects a suitable free spot from the table, marks it as reserved, and immediately propagates the change with UpdateParkingSpotStatus, avoiding double booking across gateways.

4.2. MQTT Communication, Backend, and Frontend for Real-Time Monitoring and Analysis

The gateway has been designed to integrate (7) MQTT communication (when Internet or metropolitan network is available) capability to publish parking stall data to a remote broker. In particular, Listing 1 provides a simple example of how such data can be transmitted via MQTT.

Listing 1. MQTT Transmission Data.
1	{
2	"gateway_id": "string",
3	"info": {
4	"parking_id": "string",
5	"latitude": "number",
6	"longitude": "number",
7	"status": "string",
8	"timestamp": "number"
9	}
10	}

Collected data can be used for multiple purposes, for instance, to perform an analysis of urban traffic; by identifying the most heavily trafficked areas and a pattern of parking space utilisation, it is possible to optimise the quantity and arrangement of parking spaces, reducing total gas emissions and improving air quality in the urban area.

As a consequence, the system can potentially produce a large amount of data about parking space use and urban traffic. And, as discusses before, by the MQTT protocol, extending the protocol to collect other types of data as well is possible, and a custom-tailored software suite can be developed to meet the needs of private car park operators, city engineers, and event organisers (such as concerts or conferences). We will further discuss this aspect in Section 5.3, at the end of the experimental section, where we briefly discuss the development of a web application for monitoring the occupancy status of parking spaces for test purposes.

5. Experimental Evaluation

The experimental evaluation of ChirpPark was carried out in distinct directions.

First, we conducted a specific simulation using our LWN Simulator [31], a LoRaWAN physical layer simulator. The advantage of using such a simulator is represented by the availability of an arbitrary number of devices (300 and more) that are not available in our laboratory. Moreover, such simulations allowed us to rigorously assess the performance and scalability of the revised ChirpPark protocol. Indeed, as we explain later in this section, we could measure a few important outputs as message collisions, packet delivery ratios, and collision rates.

A further set of experiments were conducted at the University of Catania using ESP32-based devices configured to act interchangeably as sensors, gateways, and vehicles. Our goals were to perform a real test, by using a certain number of physical devices, of real-world feasibility, low-power distributed communication, and independence from Internet connectivity of the proposed system. Although the system implementation is ready and, therefore, it is almost ready to be deployed in a real-world environment, this task has not been completed due to external administrative constraints.

Finally, in the last part of this section, Section 5.3, we briefly explain how we realised a custom web application to monitor the system and perform real-time analysis of data, thanks to the modular and flexible design of the system and protocol.

5.1. Experimental Evaluation by Simulations

We conducted a specific experiment using the LWN Simulator [31], a LoRaWAN physical layer simulator, with the aim of rigorously assessing the performance and scalability of the revised ChirpPark protocol. The simulation focused exclusively on the LoRa PHY layer and leveraged built-in APIs to

• Emulate mobile vehicle movement through the parking zone;
• Simulate gateways’ positioning and their effective coverage;
• Simulate fault scenarios, including controlled power shutdowns, to assess robustness.

Key metrics analysed included packet delivery rate, response time, and conflict resolution accuracy under overlapping gateway regions.

The simulation environment was configured to emulate a realistic urban deployment in Dubai (Emirates), and spanned approximately 24.5 simulated days, as reported in

Table 2. Simulation Configuration.

Number of Devices	312
Number of Gateway Devices	6
Number of Parking Spot Devices	181
Number of Vehicle Devices	125
Simulation Duration	588.5 h
Parking Spot Heartbeat Interval	15 min
Vehicle Parking Request Frequency	Poisson-distributed arrivals
Vehicle-to-Gateway Delay	1500–2500 ms
Parking Spot-to-Gateway Delay	2000–3000 ms
Gateway-to-Vehicle Delay	1500–2300 ms
Message Retry Delay	500 ms
Max Retries	3
Average Vehicle Speed	40 km/h

, along with all the remaining configuration parameters. The test-bed comprised a total of 312 devices, including 6 gateways, 125 vehicles, and 181 parking spot sensors, reflecting the scale and heterogeneity of a modern smart city parking scenario. The vehicle parking request frequency follows a Poisson distribution to realistically model the randomness of parking demand in an urban scenario. The Poisson process is characterised by a mean arrival rate ($\lambda$) of approximately $0.0106$ requests per second, equivalent to about $915.12$ requests per day. This value was derived by dividing the total number of parking requests by the total simulation time in seconds.

The following timing variables in Table 2 define communication latencies and retries over the network:

• Vehicle-to-Gateway Delay (1500–2500 ms): Represents the delay for a parking request or status update to reach the gateway from a vehicle. This includes transmission and processing delay.
• Parking Spot-to-Gateway Delay (2000–3000 ms): Represents the latency from the sensor at the parking spot to the gateway, taking into account data transmission and possible congestion.
• Gateway-to-Vehicle Delay (1500–2300 ms): Models the delay for gateway-to-vehicle responses, such as parking confirmations or updates.
• Message Retry Delay (500 ms): In the event of message delivery failure, the system waits for 500 ms before a retry is attempted.
• Max Retries (3): A limit of three retries per message is imposed before the message is abandoned, to limit network congestion and encourage responsiveness.

Finally, the average vehicle speed in the simulation was set at 40 km/h, which influences how quickly vehicles can reach available parking spots once identified.

In particular, the simulated urban area was mapped to approximate the density and distribution of parking infrastructure and traffic flow typical of Dubai’s city centre. Dubai was selected as the simulation environment due to its representative characteristics of modern smart cities, including high vehicle density (540 vehicles per 1000 residents), mixed-use urban planning combining commercial and residential areas, and ongoing smart city infrastructure investments. Dubai’s parking demand patterns, with approximately 30% of urban traffic attributed to parking search activities, align with the global urban parking challenge that ChirpPark aims to address. Gateways were strategically placed to maximise coverage and minimise communication dead zones, while vehicles were programmed to exhibit realistic arrival, parking, and departure patterns based on empirical urban mobility models. Each parking spot was equipped with a virtual sensor capable of periodic status updates and event-driven changes. The graphical dashboard of the simulator showing the specific simulation is shown in Figure 7.

The ChirpPark protocol reduced the average parking search time compared with the baseline: vehicles required an average of 1538 s to locate and reserve a parking space, as shown in

Table 3. LWN Simulator Main Metrics.

Metric	Value
Session Duration	588.5 h
Total Downlinks	22,878
Total Uplinks	10,752
Parking Requests	6024
Successful Reservations	2548
Message Collisions	1065
Average Search Time	1538 s
Average Arrival Time	81,149 s
Packet Delivery Ratio	98%
Collision Rate	1.91%

. This improvement is attributed to the distributed reservation mechanism and efficient gateway coordination, which minimised redundant searches and reduced network congestion.

We report in Table 3 the main metric output obtained at the end of the simulation. We explain below each metric output.

• Session Duration: The simulation ran continuously for 588.5 h.
• Total Downlinks/Uplinks: This counts all LoRaWAN messages exchanged. Indeed, 22,878 were sent from the gateway (downlinks) and 10,752 were sent by the nodes (uplinks). In short, it is the total radio chatter. This aspect is highlighted in Figure 8, where the temporal distributions of both downlink and uplink messages are shown. The histograms provide a visual confirmation of the volume discrepancy between downlinks and uplinks across time.
• Parking Requests: Vehicles asked for a parking spot 6024 times during the simulation.
• Successful Reservations: A total of 2548 requests for parking were fulfilled.
• Message Collisions: There were 1065 moments when packets overlapped on the airwaves and none could be understood.
• Average Search Time: On average, vehicles waited about 1538 s from request to assignment of a spot.
• Average Arrival Time: Denotes the delay between a successful reservation and the moment the vehicle physically reaches the assigned parking space.
• Packet Delivery Ratio (PDR): About 98 out of every 100 packets made it through, indicating solid communication reliability.
• Collision Rate: Only 1.91% of all messages collided, suggesting low levels of radio congestion.

In the initial phase of the simulation, the number of vehicles intentionally outnumbered the available spots; only after some days were additional parking resources injected.

In Figure 9, the two panels (upper) and (lower) represents the same measure (no. of collisions) in different ways. The histogram (upper) represents the absolute number of collisions per time interval $\Delta t$; the linear plot (lower) represents the collision rate, as a percentage, in the same interval, defined as $100·{\displaystyle \frac{\mathrm{collisions}}{\mathrm{uplink}+\mathrm{downlink}}}$. These plots were generated to represent the expected side-effect of the increasing density of vehicles in a certain area; the greater the number of vehicles competing for the LoRa channel, the greater the no. of collisions.

Across the 25-day simulation, the average time between parking request and receipt of confirmation was 41 s, as shown in

Table 4. Performance Indicators.

Indicator	Value	Evaluation
Success Rate	62.30%	Good
Collision Rate	1.91%	Good
Packet Delivery Ratio	98%	Excellent
Average Response Time	41 s	Sufficient

; this value represents the overall system response time along the entire message chain.

The histogram in Figure 10 (top panel) shows how parking request frequency peaks at the beginning of the simulation and quickly declines as vehicles gradually secure a space, confirming the expected self-throttling behaviour of the protocol.

The system maintained a robust packet delivery ratio of 98% as shown in Table 3 and Table 4 despite occasional simulated interference and gateway outages. The protocol’s built-in retransmission and acknowledgement mechanisms effectively mitigated the impact of transient communication failures. It is important to remark that the Success Rate (62.3%) reported in Table 4 and the Packet Delivery Ratio (98%) reported in Table 3 capture different phenomena; the former denotes the share of booking requests that culminate in a confirmed reservation, whereas the latter represents the proportion of LoRa packets correctly received out of those transmitted.

Status updates for contested or shared parking spots were consistently propagated to all relevant gateways within 1.2 s on average. This rapid synchronisation prevented double-booking events and maintained global consistency, even as vehicles and sensors dynamically entered or exited the network.

Energy consumption analysis indicated that parking sensors could operate for over 18 months on a standard 2400 mAh battery, assuming a 15 min heartbeat and event-driven transmissions. The protocol’s emphasis on minimising unnecessary communication proved effective in extending sensor lifespan. Moreover, Figure 11 also reveals that 36,480 gateway-info-exchange messages were routed among gateways during the run, highlighting the overhead required to maintain a globally consistent view of parking spot occupancy.

Simulated failures, including random gateway and sensor outages, had minimal impact on overall system performance. The decentralised architecture enabled rapid recovery and state reconstruction, with affected areas restored to full operation within 5 min of device replacement or network healing. The experimental results confirm that the ChirpPark protocol delivers substantial improvements in efficiency, scalability, and resilience. The system’s ability to maintain acceptable packet-level latency (2.3 s for 95% of transmissions) under realistic conditions demonstrates its suitability for large-scale smart city deployments. Furthermore, the energy-efficient design ensures long-term sustainability for battery-powered sensors, while the robust synchronisation mechanisms safeguard against data inconsistencies and service interruptions.

5.2. Experiments with Real Devices

In order to perform experiments with the real devices, we used ESP32-based devices that were configured to act interchangeably as sensors, gateways, and vehicles.

Table 5. Used Devices.

	TTGO LoRa32 V2.1_1.6 [32]	Arduino Nano ESP32 [33]
Micro-controller	ESP32 dual-core 32-bit	ESP32-S3 dual-core 32-bit
Frequency	240 MHz
ROM Memory	4 MB	16 MB
RAM Memory	520 KB
Built-in Modules	Wi-Fi, BLE, and LoRa	Wi-Fi and BLE
LoRa Module	SX1276 868 MHz Internal	SX1276 868 MHz External
LoRa Antenna Gain	2 dBi	2 dBi

summarises the specifications of the used devices.

The firmware for such devices was implemented in C++ using platformIO [34] and Arduino SDK (which is based on FreeRTOS). The communication layer, which is based on LoRa, was configured to transmit at a frequency of 868 MHz. In configuring these devices, we tried to optimise spreading factors and reduce packet sizes. Thus, we obtained efficient broadcasting of minimal telemetry data.

First of all, we tested an “offline” scenario with ESP32 devices communicating exclusively via LoRa by deploying 25 devices. In particular, the role of the used devices was as follows:

• Two gateways;
• Ten parking sensors and the rest as vehicles;
• Of all the parking sensors, 5 were contested between the gateways.

We configured the system to maintain an in-memory management table of available parking spots. The information about states of parking gates was maintained and synchronised without continuous flash writes, ensuring reduced latency and increased system resilience.

In these tests, we manually forced gateway breakage and replacement in order to prove the fault recovery capabilities of the entire network. Indeed, we verified that the parking sensors correctly repopulate the in-memory table with some other gateways in a few heartbeat cycles.

Moreover, we conducted a simple empirical stress test simulating high communication traffic and interactions. These tests confirmed acceptable effectiveness and stability for real urban contexts.

5.3. Backend and Frontend Implementation

As stated in Section 4.2, the system can potentially produce and collect a large amount of data to use for real-time analysis and representation. This is possible by extending the protocol to collect specific data and, thereafter, a customised software can present these data to the operators.

Therefore, to highlight that the designed system is flexible, modular, and extensible, in this subsection, we describe a web application developed and tested for monitoring the occupancy status of parking spaces. For the remainder of this subsection, the reader may refer to Figure 12. The backend was developed by using the Django framework; we integrated Django REST Framework (DRF) for API exposure and Django Channels for real-time communication through WebSocket. The primary function of the backend includes data storage, user authentication, processing of MQTT messages, and system monitoring. Once an MQTT message is received from a gateway, the backend parses the JSON payload, validates its structure, and updates the database accordingly. The ParkingInfo object (see Section 3), transmitted via MQTT, is then deserialised into a database entry representing the state of a parking spot. Inactive parking spots are detected using scheduled tasks that periodically evaluate the timestamp of the latest update. If a spot does not send any message (such as a SensorUpdate or HeartBeat) within a given interval of time, it is flagged as inactive and excluded from the list of available stalls. To enable real-time synchronisation between the backend and user interfaces, the system employs WebSocket channels powered by Django Channels and Redis as a message broker. The frontend was built using the Next.js framework, leveraging hybrid rendering (SSR + CSR) to balance performance and interactivity. Authenticated users can access a responsive web dashboard showing real-time occupancy of parking spots, statistics over time, and alerts for sensor inactivity. Authentication is managed using JSON Web Tokens (JWT), allowing stateless, secure access across the frontend and backend. Overall, the integration among MQTT, Django, and Next.js ensures a modular and scalable system architecture. It supports both real-time responsiveness and robust historical data management, making it suitable for urban deployments of smart parking infrastructures.

6. Conclusions

This paper presents an IoT-based smart parking protocol designed to address critical challenges in urban mobility, particularly the inefficiencies associated with locating and managing available parking spaces. The proposed solution, ChirpPark, leverages the capabilities of LoRa-based communication and modular micro-controllers to enable decentralised, real-time parking management, even without constant Internet connectivity. The system architecture, integrating distributed sensors, gateways, a backend platform, and a real-time monitoring frontend, enables significant reductions in traffic congestion and search time for available spots. This contributes directly to a more sustainable and user-friendly urban mobility experience. Preliminary experimental validation and simulations have demonstrated the protocol’s technical feasibility and reliability. Furthermore, the system is energy-efficient and tailored for long-term autonomy, making it suitable for large-scale deployment without heavy infrastructure costs. Moreover, ChirpPark contributes to environmental sustainability by minimising unnecessary vehicular movement and reducing carbon emissions.

We implemented the system into real devices and, therefore, it is almost ready to be deployed in a real environment. Nevertheless, this task has not been completed due to external administrative constraints. Therefore, once the deployment in a real environment is done, we will perform some further tests aimed at further fine-tuning the system itself.

Future research will include validation across different urban environments with varying traffic densities and infrastructure characteristics. Comparative studies in high-density cities (e.g., Mumbai, Mexico City) and lower-density environments (e.g., Nordic cities) will provide comprehensive validation of ChirpPark’s adaptability to diverse urban contexts.

Although our evaluation focuses on parking applications, in our view, the protocol represents a general-purpose, low-power, long-range communication layer with optional cloud telemetry that fits other IoT verticals. Core functions, as well as LoRa-based operations that do not need Internet connectivity, optional MQTT for telemetry/analytics, and decentralised gateway coordination, can be integrated into application domains where Internet connectivity is not always reliable and devices must run for months on the same set of batteries. The solutions implemented for the heartbeat/SensorUpdate and gateways’ in-memory management tables enable rapid state reconstruction after failures and continuous asset status tracking. Thus, such solutions can be employed to design some different systems, for instance, streetlighting faults, waste-bin fill levels and environmental monitoring.

Beyond the specific case of smart parking, the architectural and communication principles of the proposed protocol are generalisable to a wide range of IoT scenarios requiring long-range, low-power, and resilient networking in intermittently connected environments. Examples include smart agriculture (e.g., soil and crop monitoring in remote fields), environmental sensing (e.g., air quality, noise, or water-level monitoring), waste management (e.g., distributed fill-level sensors for containers), or public safety systems (e.g., structural health monitoring of bridges and infrastructure). In such contexts, the same decentralised gateway coordination, heartbeat-based fault recovery, and optional MQTT telemetry used in ChirpPark can provide scalable, autonomous, and cost-effective operation without continuous Internet dependency.

Further works could involve the implementation of a full-duplex communication between the optional backend system and parking sensors to allow system administrators to dynamically manage, in terms of enabling or disabling, the availability of parking spaces. In summary, ChirpPark constitutes a high-performance and scalable solution for smart parking management that aligns with the broader goals of smart city development.