**1. Introduction**

Social, technological and economic factors contributed to the emergence of smart parking systems (SPS), and the recent advancements in electric and autonomous vehicles present a strong business case for intelligent parking services [1]. Currently, they are an urban requirement where users can search, navigate, reserve and pay for a free parking slot on a real-time basis. Countries across the world are turning to smart parking solutions for reducing traffic, minimize effort spent on parking, combat illegal parking, cutting down emissions as well as a business model to generate revenue. The global smart parking market is projected to grow at a compounded annual growth rate of 19.8% and is on its way to becoming a 16.3 billion dollar market in another six years [2]. As SPS matures, it fuels expansion of allied sectors such as sensor technology, Internet of Things (IoT) devices, communication access technologies, Machine to Machine (M2M) standards, smart city infrastructure projects and security solutions. As the roll out of 5G infrastructure facilitates real-time data availability with ultra low latency, IoT is excepted to realize its full potential [3].

**Citation:** Anusha, T.; Pushpalatha, M. Efficient Communication Model for a Smart Parking System with Multiple Data Consumers. *Smart Cities* **2022**, *5*, 1536–1554. https://doi.org/10.3390/ smartcities5040078

Academic Editors: Antonio Cano-Ortega and Francisco Sánchez-Sutil

Received: 5 October 2022 Accepted: 28 October 2022 Published: 2 November 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

All the literature on SPS concentrates on parking sensors that are data producers, access technologies and various software solutions. The data consumers, who access the generated parking data, are by default expected to be connected to cloud for their input. However, a smart city is analogous to the presence of heterogeneous IoT devices that consume data during M2M interactions [4]. Multiple data consumers are inevitable in an SPS, as various IoT devices are present in the parking lot. A workstation in the control room or a display device needs only local data. Whereas, an end user's mobile application may need more sophisticated data from a central cloud as it accesses the data over Internet. Hence, receiving data from the cloud may not be the best approach for on-site consumers because it takes up additional time in sending and receiving data through the Internet. A robust communication model is essential for establishing a quick, reliable communication between the data producers and consumers in a smart parking system.

Figure 1 shows the possible layout of a standalone parking lot equipped with different types of IoT devices.

**Figure 1.** IoT infrastructure in a standalone parking lot.

IoT devices are installed at each parking space for gathering accurate data on availability, location and the duration of parking. These IoT devices are battery operated, simple to install and can last up to five or six years of operation without maintenance. The border router heads the mesh network and offers a global prefix for each device to equip them with a global IPv6 address. Parking availability data are locally consumed by the ticketing stations, which are present at the exit points and by the display screens, positioned at the entry points. As these devices depend only on the data collected from a standalone parking

lot, they are labeled as on-site data consumers. Consumers that require global collated data from multiple parking lots are off-site data consumers, who access the same over the Internet or cloud.

A survey by J. J. Barriga et al. found that an SPS is predominantly implemented using Zigbee networks in 60% of the studies followed by 25% with IEEE 802.15.4 [5]. However, data collection networks are not the best candidates for M2M communication between IoT devices. RPL [6] is the IPv6 routing protocol for low-power lossy networks, whose directed cyclic graph (DAG) formation is best suited for networks incorporating local data consumers. In RPL's storage mode, heads of subtrees store the routes to nodes that are underneath them and hence provide fail-safe communication paths between thr various nodes in the network. This paper evaluates different types of communication models for an SPS with multiple local data consumers, using the RPL routing protocol, in an IEEE 802.15.4 mesh network.

The next section briefly identifies various data consumers that are present in a smart parking system and categories them as either on-site or over-the-Internet type. Section 3 summarizes the related research works, and Section 4 elaborates on the different aspects of efficiency for a communication model. The further section evaluates the models, discusses their relevance and converges on an efficient multi-collator communication model.

#### **2. Data Consumers in an SPS**

A smart parking system is a complete digital platform that manages city-wide parking resources in real-time and provides multiple services to end users [7,8]. Starting from searching for a nearby available parking slot, booking a parking slot in advance, navigating to an available parking lot, charging electric vehicles at the booked slot, and predicting the availability for a specific time until payment for parking or charging is possible with a SPS. An smart parking lot utilizes various sensors for the accurate identification of empty slots, parking boundaries and the automated counting of the number of entries and exits. Apart from these sensors, it may have other IoT devices such as overhead LEDs as indicators for vacancy, LCD displays showing layout/availability statistics, buzzers or alarms for indicating wrong parking, automated gates that open after payment verification or license plate identification. These IoT devices need data from the sensors for their intended operations and are data consumers in a smart parking system.

A cloud-based SPS collates availability data from the sensors and sends them to the cloud for storage and processing. The application(s) on cloud servers provide relevant decisions and inputs to the data consumers. In such a system, it is required that the data consumers are connected directly to the cloud. This may not be an economical solution, as a direct Internet connection is required for all the consumers. For instance, an overhead LED light, showing the occupancy of a specific parking lot, just needs input from the respective parking sensor. Such a local scope does not need a cloud SPS. A mesh with any-to-any traffic support is most suitable. Multi-hop mesh networks are a cost-effective way of connecting heterogeneous IoT devices and providing Internet connectivity to all nodes in a network. There is no gateway device involved in an IPv6 mesh as there are no protocol translations, and all the communication is IP based. In addition, local data consumers can be given instructions within the network by the border router itself in a scaled-down centralized approach, reducing the round-trip time taken by the data. Data consumers can be classified as on-site or over-the-Internet, depending on the scope of the data consumed by them.

#### *2.1. On-Site Data Consumers*

On-site data consumers are IoT devices that work with the data generated from devices that are in its proximity. Figure 2a–d depict some of the IoT devices that are employed in individual smart parking lots. Smart LED bulbs are used to provide visual clues for drivers in a closed parking system that has less day light visibility. These smart LEDs can be connected to other IoT devices through WiFi or BlueTooth technology. Similarly, smart alarms devices are also available and could be integrated to the central parking management system. The availability of systems on chips (SoC) supporting multiple radios in a single chip equips an IoT device to switch between different types of communication channels for device-to-device interaction. For instance, Qualcomm QCA4020 SoC provides intelligent multi-radio connectivity with WiFi, BlueTooth and 802.15.4 support [9].

(**d**) LCD screen

**Figure 2.** Examples of on-site data consumers. (**a**) Smart bulb. (**b**) Buzzer for alarm. (**c**) Ticketing booth. (**d**) Display screen.

The ticketing booths could be a simple hand-held device with ticket or receipt-printing capability. They would need occupancy duration and timings for calculating relevant parking charges. They could also be a complex system, complete with an automated toll gate to allow passage for vehicles after verfication. Figure 3 shows a simple LCD screen display showing the aisle numbers and the respective numbers of lots that are vacant in them. Such a display screen, placed at the entrances of different levels, help users in a multi-level parking system. It could also be a complex system complete with a map in a very large parking lot.


**Figure 3.** A display screen placed in a smart parking lot, showing parking availability.

#### *2.2. Over-the-Internet Data Consumers*

Off-site data consumers are remote devices that access the parking lot occupancy data combined with other systems such as maps or payments. Figure 4a,b show mobile applications for booking parking lots or viewing parking lots available in a particular area. In contrast, Figure 5 presents a web page that provides a passive view of the availability information from the parking sensors. These are good examples for remote data consumers that need Internet access to receive data from an SPS. In an IPv6 mesh, the BR advertises a global prefix, and hence, the nodes become accessible over the Internet. The IoT devices are capable of hosting a web page, and hence, it can supply the occupancy data to a web browser upon an HTTP request. The example for such a web page is as shown in Figure 5, where a laptop is connected to the BR through a Serial Line Internet Protocol (SLIP). SLIP allows IP datagrams to be encapsulated and exchanged over serial ports. The web page can be accessed through the IPv6 address of the data collator.

**Figure 4.** Mobile application with multiple services. (**a**) Booking individual parking slot. (**b**) Searching for available parking slots in a map.


**Figure 5.** Over-the-Internet data consumer, a web browser showing parking occupancy.

Such direct BR to Internet connections work for a limited number of devices. However, if the number of simultaneous users increases, it is preferential to host the application in the cloud, as it provides elasticity in meeting user demand. In addition, web and mobile applications in the cloud have the privilege of collating data from multiple parking lots to show area-wide or city-wide car park availability. They can integrate the parking system data with other systems to offer seamless services.

#### **3. Related Work in Literature**

SPS systems are generally assisted or non-assisted where an assisted SPS allocates parking lots intelligently after considering various parameters such as the slot availability, user preference, closeness and traffic pattern of the route. This category strives to move forward toward autonomous vehicles and the navigation. A non-assisted SPS is a partially manual system where occupancy data are provided to end-users, and the actions are left to their decisions. Lin et al. classify SPS from another perspective based on the methods employed for information collection, the deployment technique of the system and their service dissemination model [8]. Paidi et al. show the gaps in deploying existing sensors and technologies for an open parking lot and the ways to design a robust multi-agent open parking lot [10]. Other works categorized parking systems based on the services offered by them such as parking reservation, guidance and crowdsourcing [11]. A survey by Fahim et al. identifies 12 different types of SPS systems depending on the technology used for sensing (Vision-based/GPS), communication (BlueTooth/WSN) or the learning models (ML/Fuzzy) employed [12]. In all these categories of SPS, a layered architecture is defined with the sensing layer at the bottom, the application layer at the top and a communication layer in between these two layers [13,14]. Al-Turjman et al. add one more layer for middleware to collate data from the sensors deployed at the parking lot [15].

The communication model of the available smart parking system perceives the sensing layer as a single unit where the sensors transmit the occupancy data to a central controller [16–18]. In rare cases, a parking guidance system considers a communication model with multiple wireless sensor systems for covering a single parking lot, and the unification of the data happens in the cloud-based application [19]. Another parking management system considers hierarchical occupancy data collation where sensor nodes communicate to group nodes and group nodes report to a central control node [20]. The parking systems do not measure the network performance of the sensing layer irrespective of its communication model being a flat network or clusters inside a single network or multiple networks. This paper studies different communication models for the sensing layer and proposes finding an efficient model for data collation and dissemination.

Access technologies inter-connect various subsystems, and the performance of the whole system is directly related to the performance of the communication layer. IoT systems have many options for access technologies depending on the required range of the wireless communication, the network topology, data-sharing models, open technologies versus proprietary and the availability of standardization. The most important support for IoT's access technology came in the form of a tiny IPv6 stack for the low power-constrained devices designed by the standard body Internet Engineering Task Force (IETF) [21]. 6LoWPAN and RPL are standard messaging protocols that could increase the utilization of open-source components in building a dependable information and communication technology for a sustainable smart city [22].

RPL is a mesh-routing protocol that supports IPv6 addresses for IoT devices and is used extensively in smart utility networks and smart grids. There are a huge number of studies to measure the performance of RPL for data-gathering applications based on a variety of parameters. Studies conclude that the combination of utilizing ETX as the link metric and a radio duty cycling mechanism to synchronously turn on and off radios empowers RPL in terms of lowest energy consumption [23,24]. Similarly, the network topology is found to have an impact on RPL network's energy consumption, and a circular topology is found to more effective than a grid or tree [25]. A study finds that compressed sensing and data aggregation in RPL reduces the data latency as well as cuts down packet loss [26]. In contrast, Pham et al. shows the need for a scheduling mechanism for delivering the aggregated data packet to reduce the latency and proposes a novel relative collision graph algorithm-based scheduler [27].

Lim, in a survey paper, categorizes multiple sinks as a viable method to reduce congestion and improve RPL's performance in an IoT network [28]. Many research works propose to increase network performance by defining more than one instance of RPL under a BR. Multi-sink approaches are proposed to handle high traffic volumes, offer safety against BR failure, combat congestion and balance traffic load across various forwarders [29–32]. A sink is a node that collates data; however, these works refer to the RPL root node as the sink.

The coordination between multiple sinks is proposed through a virtual root or through cooperative mechanisms between the different sinks [33–35]. Junior et al. argued that dynamism in invoking multiple instances is better than static multiple instances in handling different data traffic for multiple IoT applications [36]. Depending on the type of application, the node switches between stored instances to experience a reduction in control messages and power consumption. Hassani et al. show that combined metrics offer superior performance when compared to a single metric in a multi-sink scenario [37]. All such works incur modifications to RPL control messages, introduce new layers and increase the complexity. Furthermore, these works do not focus on exchanging data between multiple sinks, as they focus on a particular case of different sinks collating different type of data from the IoT network. Moreover, there is no need for the sink node to be the destination of data and any node in the network can act as a data server.

Tran et al. measure RPL's performance under different topologies such as linear, circular, random and grid. They conclude that the topology does not impact power consumption but influences latency [38]. The number of hops needed to reach the destination has an impact on the performance, as congestion is prevalent around the sink node. Hilmani et al. use a WSN for gathering occupancy data in the central gateway/sink node and apply a self-organizing algorithm for cluster formation [39]. In the clustering approach, there is no explicit insight on the exchange of data between clusters or the latency involved. Although there are a plethora of works in the literature to improve the performance of RPL [40], the simple effects of the position of root node or the usage of multiple servers to collate data are not studied.

#### **4. Efficient Communication Model for an SPS with Multiple Data Consumers**

IoT applications implemented with low-power personal area networks have a variety of requirements such as low power consumption, low latency, less traffic overload and high reliability [41]. In order to satisfy these requirements, an efficient communication model must:


A parking lot application that generates parking availability data has to forge effective communication paths between IoT devices that generate occupancy data, devices that collate the occupancy data and devices that consume occupancy data. The performance of a multi-hop network depends on the number of hops between the source and the destination. When data are transmitted through a minimal number of nodes, the latency and power consumption are optimal. On this basis, five different communication models are evaluated for implementing an SPS with multiple data consumers:


A border router (BR) facilitates connections between the mesh devices and Internet backbone. A BR aggregates routes to all mesh nodes and utilizes the same to connect them with hosts from other IP-based networks [6]. The wireless connection between all these entities forms the communication ecosystem of the SPS. In order to realize the goals of an efficient communication model, several aspects such as the position of border router and data collators, radio duty cycling, and data formats are considered in this work. Figure 6a–d represent a class of communication model where IoT devices simply forwards data toward the data collator. However, the position of the data collators vary among them. Except for the third model in Figure 6c, the BR and data collators are neighbors. The third model has split the entire network into four quadrants and has one data collator at the center of each quadrant. This places the data collator nested among the data producers. In contrast, Figure 6e shows a model where forwarders accept data from their children nodes, aggregate and then send out a single data packet with the consolidated occupancy data.

**Figure 6.** Flow of occupancy data (**a**) BR with one data collator at top. (**b**) BR with one data collator in middle (**c**) BR with four distributed data collators (**d**) BR with four data collators near BR. (**e**) Routers aggregate occupancy data at each hop.

The past research work on RPL's performance provides several pieces of vital information, including ETX for best link assessment, the significance of radio power consumption, duty cycling for reducing energy consumption, the relation between topology and performance and load balancing with multiple sinks. As multiple sinks mean more border routers, it involves high control overhead in maintaining more than one instance of RPL. Instead, this paper explores several alternate aspects such as multiple data collators, their positions, relative positions with data consumers, duty cycles of IoT devices, and data exchange format for arriving at a simple and efficient communication model.
