Next Article in Journal
Hybrid Approach for Developing Strategic ICT Framework for Smart Cities—A Case Study of Dubai’s Toll Gates (Salik)
Previous Article in Journal
Factors Affecting Stakeholder Acceptance of a Malaysian Smart City
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Efficient Communication Model for a Smart Parking System with Multiple Data Consumers

Department of Computing Technologies, SRM Institute of Science and Technology, Chennai 603203, India
*
Author to whom correspondence should be addressed.
Smart Cities 2022, 5(4), 1536-1553; https://doi.org/10.3390/smartcities5040078
Submission received: 5 October 2022 / Revised: 26 October 2022 / Accepted: 28 October 2022 / Published: 2 November 2022
(This article belongs to the Topic IoT for Energy Management Systems and Smart Cities)

Abstract

:
A smart parking system (SPS) is an integral part of smart cities where Internet of Things (IoT) technology provides many innovative urban digital solutions. It offers hassle-free parking convenience to the city dwellers, metering facilities, and a revenue source for businesses, and it also protects the environment by cutting down drive-around emissions. The real-time availability information of parking slots and the duration of occupancy are valuable data utilized by multiple sectors such as parking management, charging electric vehicles (EV), car servicing, urban infrastructure planning, traffic regulation, etc. IPv6 wireless mesh networks are a good choice to implement a fail-safe, low-power and Internet protocol (IP)-based secure communication infrastructure for connecting heterogeneous IoT devices. In a smart parking lot, there could be a variety of local IoT devices that consume the occupancy data generated from the parking sensors. For instance, there could be a central parking management system, ticketing booths, display boards showing a count of free slots and color-coded lights indicating visual clues for vacancy. Apart from this, there are remote user applications that access occupancy data from browsers and mobile phones over the Internet. Both the types of data consumers need not collect their inputs from the cloud, as it is beneficial to offer local data within the network. Hence, an SPS with multiple data consumers needs an efficient communication model that provides reliable data transfers among producers and consumers while minimizing the overall energy consumption and data transit time. This paper explores different SPS communication models by varying the number of occupancy data collators, their positions, hybrid power cycles and data aggregation strategies. In addition, it proposes a concise data format for effective data dissemination. Based on the simulation studies, a multi-collator model along with a data superimposition technique is found to be the best for realizing an efficient smart parking system.

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].
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.
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].
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.

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.
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,17,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,30,31,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,34,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:
  • Provide reliable data collection in a large mesh network;
  • Minimize the power consumption of the battery-operated IoT devices;
  • Be quicker in collating and furnishing the data to consumer devices;
  • Have a data format that compresses the volume of data.
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:
1.
Border router with a single data collator at the perimeter of the parking lot;
2.
Border router with a single data collator at the center of the parking lot;
3.
Border router with multiple data collators distributed across the parking lot;
4.
Border router with four data collators at the center of the parking lot;
5.
Border router with four data collators at the center and each forwarder in the mesh aggregates occupancy data.
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.
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.

4.1. Positioning BR for a Balanced Mesh Formation

BR is the root node in the mesh that initiates the mesh formation. RPL protocol forms a directed acyclic graph (DAG) that is destined to the BR by sending a DAG information object (DIO). DIO is an advertisement, and nodes hearing it join the DAG. It then furthers the transmission of DIO using trickle timers, and nodes join as in a ripple. Hence, nodes at the far end of the network perimeter takes more time to join the DAG. To have a uniform distribution of DIO along the perimeter of the network, it is necessary for the BR to be at the center of the network. This ensures that all nodes along the entire perimeter of the network have the smallest possible hops to reach the BR. With the number of hops directly proportional to the energy utilization and latency, positioning the BR at the center is the best approach. In addition, congestion around the BR node is quite low for a network having BR at the center when compared to a BR at the top (as in Figure 6a).

4.2. Positioning Data Collators for Reliable and Faster Data Collection

The BR itself can act as a data collecting point as RPL has a reliable DAG path to the root node. This introduces the funneling effect where forwarders close to the BR experience huge traffic. To reduce this effect, many researchers propose using multiple root nodes and collating the data outside the RPL network [42,43]. However, this deprives the on-site data consumers from directly accessing the occupancy data within the network and adds a dependency to the Internet connection besides increasing the delay in acquiring the data. The multi-sink approaches are complex with additional systems and modifications to the RPL control messages. As an alternate, multiple data servers are proposed in this work. It is essential that the data servers are stationed close to a BR so that a data server can reach another through the BR. This reduces the funneling effect and requires no complex improvisations to the RPL protocol. As the data servers are en route to BR, all the data-producing nodes already have an optimal path to reach the data collator. To illustrate this point, the third model has multiple data collators away from the BR.

4.3. Hybrid Power Cycling for Mesh Devices

Thread is an emerging routing protocol that is extensively used in smart home appliances [44]. The thread’s communication model has mains-powered thread routers and duty-cycled sleepy end devices. Such a hybrid power cycling works for smart home mesh networks. However, the mains power is not suitable for mesh forwarders employed in a smart parking lot because a huge number of forwarders are required to cover the entire parking lot. However, the data collators are smaller in numbers and can be mains powered to maximize the packet reception rate of the data servers and also cater to high data volumes. They mains-powered devices do not switch off their radios. All other sensor nodes can have radio duty cycling to reduce energy consumption and switch off their radios most of the time except during packet transmissions. The BR, too, has its radio on so as to have a seamless connection to Internet. The positioning of BR makes it easier to extend the same to the data servers that are nearby. This hybrid power solution allows for lower energy consumption for the battery-powered nodes and ensures reliable occupancy data collection for the data servers.

4.4. Concise Data Format for Data Exchange

The occupancy data can be expressed in binary as they are two-state data, which are either occupied or not occupied. Hence, a single byte can represent eight parking slots and an 80-byte IP payload can effectively contain occupancy data for 640 parking slots. The occupancy data can be multiplexed at the data servers and is used for exchanging collated data between servers. The same is sent to data consumers. The concise string is then broken down back to occupancy data in the consumer node. The BR uses the compressed occupancy string in the HTTP data exchanged with the web browser. This short data exchange format reduces the load time of the web page.
The algorithm presented in Algorithm 1 takes the occupancy data array and converts the same to a single consolidated string. The index of the array is mapped to the position of the parking lot and is subsequently filled with either zero or one. The data collators fill the respective slots in the data array and convert the data to a concise string. This string is eight times compressed and can hold over 600 occupancy data in a single IP payload of IEEE 802.15.4 mesh.
Algorithm 1 Convert occupancy data to a concise string
  • Input is O D A , Occupancy data array
  • Output is o c c u p a n c y _ s t r , Concised occupancy data as string
  • for i = 0 to n o _ o f _ p a r k i n g _ s l o t s 1 do
  •     for j = 0 to 7 do
  •          s h i f t e d _ b i t = O D A [ i ] < < j
  •          c o m b i n e d _ b y t e = c o m b i n e d _ b y t e | s h i f t e d _ b i t
  •     end for
  •      b y t e _ s t r = i n t _ t o _ c h a r ( c o m b i n e d _ b y t e )
  •     concatenate b y t e _ s t r with o c c u p a n c y _ s t r
  • end for
The algorithm presented in Algorithm 2 takes the consolidated string and converts it back to occupancy data.
Algorithm 2 Convert the concise string back to occupancy data
  • Input is o c c u p a n c y _ s t r , Concised occupancy data as array of characters
  • Output is O D A , Occupancy data array
  • b i t _ m a s k [ ] is {128, 64, 32, 16, 8, 4, 2, 1}
  • for i = 0 to n o _ o f _ p a r k i n g _ s l o t s 1 do
  •      i n t _ v a l u e = c h a r _ t o _ i n t ( o c c u p a n c y _ s t r [ i ] )
  •     for j = 0 to 7 do
  •        o c c u p a n c y _ b i t = b i t _ m a s k [ j ] & i n t _ v a l u e
  •        if o c c u p a n c y _ b i t > 0 then
  •            o c c u p a n c y _ b i t = 1
  •        else
  •            o c c u p a n c y _ b i t = 0
  •        end if
  •         O D A [ i ] = o c c u p a n c y _ b i t
  •     end for
  • end for
All these decisions are expected to play a role in establishing efficient communication between all the concerned entities of the SPS system.

5. Evaluations

All the five different communication models referenced in the previous section are evaluated against each other for their efficiency in terms of data loss, packet latency, control overhead, energy consumption, time needed to obtain occupancy data for all the parking slots and the time taken for the occupancy data to reach the consumers. To this effect, an experimental study is carried out in a simulated IPv6 mesh network with 100 nodes and one BR. The Cooja simulator is a widely accepted simulator for conducting experimental studies of IEEE 802.15.4 based IoT networks [45].

5.1. Simulation Setup

In the experiments, the BR is the root node of the IPv6 mesh and creates a DODAG with one RPL instance. All the nodes are forwarders that are capable of forwarding data packets in the upward direction toward the root node (BR). The data collator is placed at a one-hop position from the BR so that it lies in the upward path en route to the BR for each node. The BR is connected through SLIP protocol to a laptop. The Firefox browser is used from the laptop to connect to the data collator to access the occupancy data over the Internet. The five networks to be examined are labeled as Top1, Mid1, Dist4, Mid4 and MidAgg as per their communication model. The model named Top1 denotes a network with a single BR and one data collator placed at the top of all the nodes. Mid1 refers to the network with a single BR and one data collator at the center of the network. The third model, Dist4, has the BR at the center, and its four data collators are distributed within the network and are away from the BR. In contrast, Mid4 refers to four data collators that are adjacent to the BR, at the middle of the network. The final MidAgg model denotes a network with four data collators in the center where each node aggregates the occupancy data. The final model is expected to consume less energy, as it reduces the total number of occupancy data packets transmitted in the network.
The grid network is considered for simulation, as the results are comparable across multiple studies. The channel check rate for a node is kept at 8HZ so as to reduce the power consumption of the nodes. A radio duty cycling ensures that the nodes remain in sleep mode for as long as possible. The data collators do not participate in radio duty cycling to ensure high reliability. The simulation parameters are summarized in Table 1.
After an initial delay of 120 s, each parking sensor node generates a data packet with occupancy data every 60 s. The data are either 0 or 1, depending on whether the respective slot is vacant or occupied. The data packet is addressed to the data server whose address is sought through service discovery. In case of multiple data collators, the address of the first discovered server is considered, since it would be the most nearest server. The data collators exchange data once every 60 s between them and also send the collated data to on-site consumers.

5.2. Simulation Results

The nodes record the number of occupancy data packets dispatched, the time of packet transmission, the number of packets received, the arrival time of the data packet, the number of different control messages transmitted for setting the mesh and the duration for its radio being active. The packet delivery ratio (PDR) is measured as the percentage of the number of occupancy data packets received at the collator(s) to that of the number of packets sent. A high PDR indicates reliable communication between the nodes and the data collator(s). The graph in Figure 7a shows the PDR of all the four communication models. As expected, it is 98.2% for the Top1 model, which has one BR and one data collector positioned at the top of all of the nodes. The model shows some initial packet loss for nodes with longer paths. The longer a data path, the more time it takes to stabilize. Dist4 also exhibits some packet loss, as nodes take relatively longer routes to data collators. The data packets have to travel upwards along the DAG to a common ancestor and then downwards toward the data collator. As the network becomes bigger, both Top1 and Dist4 would experience a further increase in the data path length. The PDR for all the other three models are almost the same and report negligible packet loss.
Figure 7b presents the average number of control packets transmitted by a node. RPL uses three different control packets, DAG information solicitation message (DIS) and DAG information object message (DIO) for forming upward routes, and (Destination advertisement object (DAO) for forming downward routes [6]. Nodes are required to send control packets in order to create and maintain the fail-safe routing paths. Less control overhead reflects the efficiency of the multi-hop mesh creation process and conserves energy in a network. The Mid4 model keeps the control overhead lowest among the models, which is closely followed by the Mid1 model.
The occupancy data packet latency is an average measure of the time duration for each data packet to reach the destination from its corresponding origin. Graph Figure 8a displays a 164.7 ms latency for MidAgg model and a comparable 471 ms and 420 ms for Mid1 and Mid4, respectively. The nodes in Dist4 model experience a latency of 823.2 ms even when there are multiple data collators. The higher latency reflects the longer routes along the DAG to the data collators. The packet latency is lowest in MidAgg because the occupancy data packets are not sent to the data collator but are sent to the immediate one-hop forwarder parent. Hence, the lowest average packet latency corresponds to one level of data aggregation. It must be noted that the occupancy data would take longer to reach the data collator as it has to cross multiple aggregation on its way.
The next graph in Figure 8b shows the total time taken for the occupancy data from all the nodes in the network to reach the data collator. This is an important metric, as it shows the efficiency of the data collation in an SPS. The MidAgg model’s under performance is because of the delay introduced by the aggregation at each hop. Both Mid1 amd Mid4 network’s performances are lowest in the range of 83 s and 63 s, respectively.
The other metrics measured are the average packet latency for data packets between the data collator and the data consumer. Here, all the models have a similar delay under 1 s for one data consumer, but Top1 shows an elevated delay for one consumer, as shown in Figure 9a. The data consumers are placed at opposite sites of the network to simulate the presence of display screens at two far ends of a parking lot. So, when the data collator is at the top, it doubles the number of hops to reach a consumer at the far end. Dist4 exhibits a faster reach to consumers, since the distribution of data collators puts them closer to the consumer. This shows that the BR in middle is an efficient strategy to reach multiple consumers at the same time. Figure 9b visualizes the percentage of run time for which the radio was kept active. The first box shows the transmitter being active, and the second box shows the receiver active time. The transmitter is kept below 1% for models except the Top1 and Dist4, and receivers are kept active for less than 2%. Keeping the radios idle for longer helps conserve energy in the wireless network.
In order to understand the energy utilization of nodes over time, the simulation is run for one hour with the energest metric report once every 5 min. The graph in Figure 10a showcases the average energy utilization of a node in different models. The initial spike is attributed to the network formation. There is a clear ranking in the energy consumption with Top1 being the highest with more packet transmission due to their longer distance to the BR. In the Dist4 model, energy utilization for a node is 22.7% higher than a node in the Mid1 or Mid4 models. Figure 10b displays the total charge consumed by a node in one hour. This also confirms the earlier findings and denotes that the Mid1 and Mid4 models outperform others in terms of efficient data collation and dissemination.

6. Results Discussion

When comparing the performances of the five different communication models, it is evident that the Mid1 and Mid4 models are showing good packet delivery ratio along with low overhead. Although the MidAgg model exhibits a low packet latency along with the lowest power consumption, the time taken for the occupancy data to reach the data collator is six times over the time taken for the Mid4 model or five times over the time taken for the Mid1 model. It requires a specific scheduling algorithm for packet transmission that can reduce the delay introduced by data aggregation at each hop. The Top1 model apparently demonstrates a lower data reliability and a high packet latency as the data packets need to traverse a higher number of hops than the other models. Between these Mid1 and Mid4 models, the Mid1’s packet delivery ratio has an edge over Mid4. However, latency wise, the Mid4 model holds an edge. To understand the advantage of these two models, the experiments are repeated in a larger 15 × 15 grid network.

Assessing the Scalability of Mid1 and Mid4 Models

The graph in Figure 11a presents the PDR for Mid1 and Mid4 models in a 10 × 10 grid network against the 15 × 15 grid network.
In a larger network, the differences between the two models are evident. The Mid4 model outperforms and is 38.1% more efficient than the Mid1 model toward reliable data collation. Figure 11b shows a small rise in control packets for the Mid4 model in a scaled-up network. However, Mid1 suffers from a 40.9% increase in control overhead when compared to the same model in a smaller network.
The data latency metrics for the two models are presented in Figure 12. The average time taken by the occupancy data packet latency to reach the data collator is very high, clocking over 12 s for the Mid1 model. Mid4 takes about 2 s for reaching the data collators and shows a clear superior performance. As the number of nodes in the network increases, the congestion causes a severe funneling effect around the root node. Hence, the performance of the Mid1 model is very low in a large network.
A similar trend is shown in Figure 13a for the time taken to reach the data consumers, and Mid4 outperforms the Mid1 model. The energy consumption is also lower for the Mid4 model, and the same is illustrated in Figure 13b. It can be concluded that a multi-data collator model with the BR at the center of the network fits the efficient communication model requirement for an SPS.

7. Conclusions

The communication technology is a vital component of an SPS system, and it is necessary to have an effective communication model that provides reliable and faster occupancy data collation and dissemination between different entities. This paper explored various aspects such as the position of the BR in a mesh network, the presence of a single data collator against multiple data collators, their relative positions with respect to BR, consumers and the effects of hybrid radio duty cycling for mesh devices. It also proposed a concise data format that accommodates a large number of occupancy data (up to 640 parking slots) in a single data packet. This reduces the number of data packets exchanged between the data collators and data consumers. Lowering the radio activity directly improves the energy efficiency of the system. Along with that, the concise data format presents a short http message and improves the web page load time. Five different communication models are evaluated for their efficiency in providing low latency and energy efficient communication. The best two models were further subjected to a scalability test in a larger 15 × 15 grid network. A multiple data collator model where the data collators are adjacent to the BR and are positioned at the center of the network is identified as the best model for providing efficient communication between data producers and consumers. Having multiple data collators adjacent to BR reduces congestion around the BR in a large network and improves their reliability. Their position at a center point reduces the hop distance between the nodes and reduces latency. Congestion avoidance and shorter communication paths present an energy-efficient system. Thus, the strategic positioning of multiple data collators reduces data transit time, offers a higher data reliability and lowers the power consumption of the mesh devices.

Author Contributions

Conceptualization, T.A.; methodology, T.A. and M.P.; software, T.A.; validation, T.A. and M.P.; formal analysis, M.P. and T.A.; investigation, T.A.; resources, M.P.; data curation, T.A.; writing—original draft preparation, T.A.; writing—review and editing, M.P. and T.A.; visualization, T.A.; supervision, M.P.; project administration, M.P.; funding acquisition, Not Applicable. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

The data are available with the corresponding author and can be provided on request.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Misra, P.; Vasan, A.; Krishnan, B.; Raghavan, V.; Sivasubramaniam, A. The Future of Smart Parking Systems with Parking 4.0: Creating Smarter Mobility Networks, White Paper, Tata Consultancy Solutions. GetMobile Mob. Comput. Commun. 2019, 23, 10–15. [Google Scholar] [CrossRef]
  2. Global Smart Parking System Market Size & Share. Available online: https://www.prnewswire.com/news-releases/at-cagr-of-19-80-global-smart-parking-system-market-size–share–2022—2028–to-hit-usd-16346-57-million-mark-by-2028-industry-trends-value-analysis–forecast-report-by-zion-market-research-301543993.html (accessed on 10 August 2022).
  3. Palattella, M.R.; Dohler, M.; Grieco, A.; Rizzo, G.; Torsner, J.; Engel, T.; Ladid, L. Internet of Things in the 5G Era: Enablers, Architecture, and Business Models. IEEE J. Sel. Areas Commun. 2016, 34, 510–527. [Google Scholar] [CrossRef] [Green Version]
  4. Theoleyre, F.; Watteyne, T.; Bianchi, G.; Tuna, G.; Gungor, V.C.; Pang, A. Networking and communications for smart cities special issue editorial. Comput. Commun. 2015, 58, 1–3. [Google Scholar] [CrossRef]
  5. Barriga, J.J.; Sulca, J.; León, J.L.; Ulloa, A.; Portero, D.; Andrade, R.; Yoo, S.G. Smart Parking: A Literature Review from the Technological Perspective. Appl. Sci. 2019, 9, 4569. [Google Scholar] [CrossRef] [Green Version]
  6. Winter, T.; Thubert, P.; Brandt, A.; Hui, J.; Kelsey, R.; Levis, P.; Pister, K.; Struik, R.; Vasseur, J.P.; Alexander, R. RFC 6550—RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks; Internet Engineering Task Force: Fremont, CA, USA, 2012; Available online: https://www.rfc-editor.org/rfc/pdfrfc/rfc6550.txt.pdf (accessed on 3 November 2016).
  7. What Is a Smart Parking System? Functionalities and Benefits. Available online: https://tomorrow.city/a/smart-parking (accessed on 2 October 2022).
  8. Lin, T.; Rivano, H.; Mouël, F.L. A survey of smart parking solutions. IEEE Trans. Intell. Transp. Syst. 2017, 18, 3229–3253. [Google Scholar] [CrossRef] [Green Version]
  9. Qualcomm QCA4040—Multi-Mode Intelligent Connectivity Solution. Available online: https://www.qualcomm.com/products/technology/wi-fi/qca4020 (accessed on 2 September 2022).
  10. Paidi, V.; Fleyeh, H.; Håkansson, J.; Nyberg, R.G. Smart parking sensors, technologies and applications for open parking lots: A review. IET Intell. Transp. Syst. 2018, 12, 735–741. [Google Scholar] [CrossRef]
  11. Ogás, M.G.D.; Fabregat, R.; Aciar, S. Survey of Smart Parking Systems. Appl. Sci. 2020, 10, 3872. [Google Scholar] [CrossRef]
  12. Fahim, A.; Hasan, M.; Chowdhury, M.A. Smart parking systems: Comprehensive review based on various aspects. Heliyon 2021, 7, e07050. [Google Scholar] [CrossRef]
  13. Ji, Z.; Ganchev, I.; O’Droma, M.; Zhao, L.; Zhang, X. A Cloud-Based Car Parking Middleware for IoT-Based Smart Cities: Design and Implementation. Sensors 2014, 14, 22372–22393. [Google Scholar] [CrossRef]
  14. Biyik, C.; Allam, Z.; Pieri, G.; Moroni, D.; O’Fraifer, M.; O’Connell, E.; Olariu, S.; Khalid, M. Smart Parking Systems: Reviewing the Literature, Architecture and Ways Forward. Smart Cities 2021, 4, 623–642. [Google Scholar] [CrossRef]
  15. Al-Turjman, F.; Malekloo, A. Smart parking in IoT enabled cities: A survey. Sustain. Cities Soc. 2019, 49, 101608. [Google Scholar] [CrossRef]
  16. Yuan, C.; Fei, L.; Jianxin, C.; Wei, J. A smart parking system using WiFi and wireless sensor network. In Proceedings of the 2016 IEEE International Conference on Consumer Electronics-Taiwan (ICCE-TW), Nantou, Taiwan, 27–29 May 2016; pp. 1–2. [Google Scholar] [CrossRef]
  17. Sahfutri, A.; Husni, N.L.; Nawawi, M.; Lutfi, I.; Silvia, A.; Prihatini, E. Smart Parking Using Wireless Sensor Network System. In Proceedings of the 2018 International Conference on Electrical Engineering and Computer Science (ICECOS), Pangkal, Indonesia, 2–4 October 2018; pp. 117–122. [Google Scholar] [CrossRef]
  18. Islam, M.R.; Azam, S.; Shanmugam, B.; Karim, A.; El-Den, J.; DeBoer, F.; Jonkman, M.; Yadav, A. Smart Parking Management System to Reduce Congestion in Urban Area. In Proceedings of the 2020 2nd International Conference on Electrical, Control and Instrumentation Engineering (ICECIE), Kuala Lumpur, Malaysia, 28–28 November 2020; pp. 1–6. [Google Scholar] [CrossRef]
  19. Cai, W.; Zhang, D.; Pan, Y. Implementation of smart Parking Guidance System based on parking lots sensors networks. In Proceedings of the 2015 IEEE 16th International Conference on Communication Technology (ICCT), Hangzhou, China, 18–20 October 2015; pp. 419–424. [Google Scholar] [CrossRef]
  20. Chandra, H.; Michael; Hadisaputra, K.R.; Santoso, H.; Anggadjaja, E. Smart Parking Management System: An integration of RFID, ALPR, and WSN. In Proceedings of the 2017 IEEE 3rd International Conference on Engineering Technologies and Social Sciences (ICETSS), Bangkok, Thailand, 7–8 August 2017; pp. 1–6. [Google Scholar] [CrossRef]
  21. Sobral, J.V.V.; Rodrigues, J.J.P.C.; Rabêlo, R.A.L.; Al-Muhtadi, J.; Korotaev, V. Routing Protocols for Low Power and Lossy Networks in Internet of Things Applications. Sensors 2019, 19, 2144. [Google Scholar] [CrossRef] [PubMed] [Green Version]
  22. Tcholtchev, N.; Schieferdecker, I. Sustainable and Reliable Information and Communication Technology for Resilient Smart Cities. Smart Cities 2021, 4, 156–176. [Google Scholar] [CrossRef]
  23. Barnawi, A.Y.; Mohsen, G.A.; Shahra, E.Q. Performance Analysis of RPL Protocol for Data Gathering Applications in Wireless Sensor Networks. In Proceedings of the 10th International Conference on Ambient Systems, Networks and Technologies (ANT), Leuven, Belgium, 29 April–2 May 2019. [Google Scholar] [CrossRef]
  24. Hakeem, S.A.A.; Hady, A.A.; Kim, H.W. RPL Routing Protocol Performance in Smart Grid Applications Based Wireless Sensors: Experimental and Simulated Analysis. Electronics 2019, 8, 186. [Google Scholar] [CrossRef]
  25. Sales, F.O.; Marante, Y.; Vieira, A.B.; Silva, E.F. Energy Consumption Evaluation of a Routing Protocol for Low-Power and Lossy Networks in Mesh Scenarios for Precision Agriculture. Sensors 2020, 20, 3814. [Google Scholar] [CrossRef]
  26. Sennan, S.; Balasubramaniyam, S.; Luhach, A.K.; Ramasubbareddy, S.; Chilamkurti, N.; Nam, Y. Energy and Delay Aware Data Aggregation in Routing Protocol for Internet of Things. Sensors 2019, 19, 5486. [Google Scholar] [CrossRef] [Green Version]
  27. Pham, V.; Nguyen, T.N.; Liu, B.; Thai, M.T.; Dumba, B.; Lin, T. Minimizing Latency for Data Aggregation in Wireless Sensor Networks: An Algorithm Approach. ACM Trans. Sens. Netw. 2022, 18, 1–21. [Google Scholar] [CrossRef]
  28. Lim, C. A Survey on Congestion Control for RPL-Based Wireless Sensor Networks. Sensors 2019, 19, 2567. [Google Scholar] [CrossRef] [Green Version]
  29. Ge, W.; Zheng, L.; Luo, P.; Liu, Z. Implementation of multiple border routers for 6LoWPAN with ContikiOS. In Proceedings of the 2015 International Conference on Information and Communications Technologies (ICT 2015), Xi’an, China, 24–26 April 2015; pp. 1–6. [Google Scholar] [CrossRef]
  30. Carels, D.; Derdaele, N.; Poorter, E.D.; Vandenberghe, W.; Moerman, I.; Demeester, P. Support of multiple sinks via a virtual root for the RPL routing protocol. EURASIP J. Wirel. Commun. Netw. 2014, 2014, 91. [Google Scholar] [CrossRef] [Green Version]
  31. Alreshoodi, M. Towards Effective Multisink Support in IPv6-based IoT Networks. Int. J. Adv. Trends Comput. Sci. Eng. 2020, 9, 2. [Google Scholar] [CrossRef]
  32. Onwuegbuzie, I.U.; Razak, S.A.; Al-dhaqm, A. Multi-Sink Load-Balancing Mechanism for Wireless Sensor Networks. In Proceedings of the IEEE International Conference on Computing (ICOCO), Kuala Lumpur, Malaysia, 17–19 November 2021. [Google Scholar]
  33. Zaatouri, I.; Alyaoui, N.; Guiloufi, A.B.; Kachouri, A. Performance Evaluation of RPL Objective Functions for multi-Sink. In Proceedings of the 18th International Conference on Sciences and Techniques of Automatic Control & Computer Engineering—STA’2017, Monastir, Tunisia, 21–23 December 2017. [Google Scholar]
  34. Khelifi, N.; Nataf, E.; Oteafy, S.; Youssef, H. Rescue-Sink: Dynamic sink augmentation for RPL in the Internet of Things. Trans. Emerg. Telecommun. Technol. 2018, 29, e3278. [Google Scholar] [CrossRef]
  35. Farooq, M.O.; Sreenan, C.J.; Brown, K.N.; Kunz, T. RPL-based routing protocols for multi-sink wireless sensor networks. In Proceedings of the 2015 IEEE 11th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), Abu Dhabi, United Arab Emirates, 19–21 October 2015; pp. 452–459. [Google Scholar] [CrossRef]
  36. Junior, S.; Riker, A.; Silvestre, B.; Moreira, W.; Oliveira-Jr, A.; Borges, V. DYNASTI—Dynamic Multiple RPL Instances for Multiple IoT Applications in Smart City. Sensors 2020, 20, 3130. [Google Scholar] [CrossRef] [PubMed]
  37. Hassani, A.E.; Sahel, A.; Badri, A. Amalgamation of Novel Objective Function and Multi-sink Solution for a Reliable RPL in High Traffic Monitoring Applications. In Digital Technologies and Applications, Lecture Notes in Networks and Systems; Springer: Cham, Switzerland, 2021; ISBN 978-3-030-73881-5. [Google Scholar]
  38. Tran, H.; Vo, M.T.; Mai, L. A Comparative Performance Study of RPL with Different Topologies and MAC Protocols. In Proceedings of the 2018 International Conference on Advanced Technologies for Communications (ATC), Ho Chi Minh City, Vietnam, 18–20 October 2018; pp. 242–247. [Google Scholar] [CrossRef]
  39. Hilmani, A.; Maizate, A.; Hassouni, L. Designing and Managing a Smart Parking System Using Wireless Sensor Networks. J. Sens. Actuator Netw. 2018, 7, 24. [Google Scholar] [CrossRef] [Green Version]
  40. Kim, H.-S.; Ko, J.; Culler, D.E.; Paek, J. Challenging the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL): A Survey. IEEE Commun. Surv. Tutor. 2017, 19, 2502–2525. [Google Scholar] [CrossRef]
  41. Ghaleb, B.; Al-Dubai, A.Y.; Ekonomou, E.; Alsarhan, A.; Nasser, Y.; Mackenzie, L.M.; Boukerche, A. A Survey of Limitations and Enhancements of the IPv6 Routing Protocol for Low-Power and Lossy Networks: A Focus on Core Operations. IEEE Commun. Surv. Tutor. 2019, 21, 1607–1635. [Google Scholar] [CrossRef] [Green Version]
  42. Foubert, B.; Montavont, J. Sharing is caring: A cooperation scheme for RPL network resilience and efficiency. In Proceedings of the IEEE Symposium on Computers and Communications (ISCC), Barcelona, Spain, 29 June–3 July 2019. [Google Scholar]
  43. Khan, M.M.; Lodhi, M.A.; Rehman, A.; Hussain, F.B. A multi-sink coordination framework for low power and lossy networks. In Proceedings of the 2016 International Conference on Industrial Informatics and Computer Systems (CIICS), Sharjah, United Arab Emirates, 13–15 March 2016; pp. 1–5. [Google Scholar] [CrossRef]
  44. Thread Mesh Networking Protocol, Thread Group, Inc. Thread 1.1.1 Specification, Feb. 2017. Available online: https://www.threadgroup.org/What-is-Thread/Overview (accessed on 20 October 2022).
  45. The Cooja Network Simulator. Available online: https://github.com/contiki-ng/cooja (accessed on 15 January 2020).
Figure 1. IoT infrastructure in a standalone parking lot.
Figure 1. IoT infrastructure in a standalone parking lot.
Smartcities 05 00078 g001
Figure 2. Examples of on-site data consumers. (a) Smart bulb. (b) Buzzer for alarm. (c) Ticketing booth. (d) Display screen.
Figure 2. Examples of on-site data consumers. (a) Smart bulb. (b) Buzzer for alarm. (c) Ticketing booth. (d) Display screen.
Smartcities 05 00078 g002
Figure 3. A display screen placed in a smart parking lot, showing parking availability.
Figure 3. A display screen placed in a smart parking lot, showing parking availability.
Smartcities 05 00078 g003
Figure 4. Mobile application with multiple services. (a) Booking individual parking slot. (b) Searching for available parking slots in a map.
Figure 4. Mobile application with multiple services. (a) Booking individual parking slot. (b) Searching for available parking slots in a map.
Smartcities 05 00078 g004
Figure 5. Over-the-Internet data consumer, a web browser showing parking occupancy.
Figure 5. Over-the-Internet data consumer, a web browser showing parking occupancy.
Smartcities 05 00078 g005
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.
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.
Smartcities 05 00078 g006
Figure 7. Metrics for the communication models. (a) Data reliability in the network (b) Control overhead in the network.
Figure 7. Metrics for the communication models. (a) Data reliability in the network (b) Control overhead in the network.
Smartcities 05 00078 g007
Figure 8. Metrics for the communication models. (a) Latency for occupancy data packets. (b) Arrival of occupancy data from all nodes.
Figure 8. Metrics for the communication models. (a) Latency for occupancy data packets. (b) Arrival of occupancy data from all nodes.
Smartcities 05 00078 g008
Figure 9. Metrics for the communication models. (a) Time to reach local consumers. (b) Percentage of time when radio was active.
Figure 9. Metrics for the communication models. (a) Time to reach local consumers. (b) Percentage of time when radio was active.
Smartcities 05 00078 g009
Figure 10. Metrics for the communication models. (a) Average energy utilization of a single node. (b) Battery charge consumption for one hour.
Figure 10. Metrics for the communication models. (a) Average energy utilization of a single node. (b) Battery charge consumption for one hour.
Smartcities 05 00078 g010
Figure 11. Performance in a 10 × 10 grid vs. 15 × 15 grid. (a) Data reliability in the network. (b) Control overhead in the network.
Figure 11. Performance in a 10 × 10 grid vs. 15 × 15 grid. (a) Data reliability in the network. (b) Control overhead in the network.
Smartcities 05 00078 g011
Figure 12. Occpancy data latency in a large network.
Figure 12. Occpancy data latency in a large network.
Smartcities 05 00078 g012
Figure 13. Performance in a 10 × 10 grid vs. 15 × 15 grid (a) Time to reach local consumers. (b) Percentage of time when radio was active.
Figure 13. Performance in a 10 × 10 grid vs. 15 × 15 grid (a) Time to reach local consumers. (b) Percentage of time when radio was active.
Smartcities 05 00078 g013
Table 1. Configuration parameters for the simulation study.
Table 1. Configuration parameters for the simulation study.
Network ParameterValue
Node placement10 × 10 uniform grid
Radio mediumUDGM
Distance between nodes30 m
TX Range/INT Range50 m/100 m
IoT devices having parking sensors96
IoT devices as on-site data consumers2, top first node and bottom last node
Number of BR1
BR positionTop or Center as per the models
Number of data collators1 or 4 depending on the model
Data collators positionTop/Center of quadrants/Center
Mode of operationStoring mode
Run Time3600 s
Occupancy sensing interval60 s
Radio duty cycling for parking sensorsContikiMAC
RDC for data collators and BRNone
Channel check rate8 HZ
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

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

AMA Style

Anusha T, Pushpalatha M. Efficient Communication Model for a Smart Parking System with Multiple Data Consumers. Smart Cities. 2022; 5(4):1536-1553. https://doi.org/10.3390/smartcities5040078

Chicago/Turabian Style

Anusha, T., and M. Pushpalatha. 2022. "Efficient Communication Model for a Smart Parking System with Multiple Data Consumers" Smart Cities 5, no. 4: 1536-1553. https://doi.org/10.3390/smartcities5040078

Article Metrics

Back to TopTop