# Efficient Communication Model for a Smart Parking System with Multiple Data Consumers
## 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  
Figure 1: IoT infrastructure in a standalone parking lot. 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 [PERSON] 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.