Design, Deployment and Evolution of Heterogeneous Smart Public Lighting Systems

.


Introduction
As the world population grows at an ever-faster pace, with the majority of people living in urban areas, the idea of creating a more livable and sustainable city is becoming increasingly important. Projections show that by 2030 there will be more than 41 mega-cities worldwide (with more than 10 M people each), with a significant increase with respect to the current 28 mega-cities. Accordingly, the percentage of the population residing in urban areas is expected to reach 66% by 2050, compared to a figure of 54% in 2014 [1]. Since world cities already account for 75% of world energy consumption and contribute more than 80% to global greenhouse gas emissions [2], there are growing concerns about the availability and cost of energy, as well as about the environmental impact of its generation.
Most likely, the solution (if any) to such issues will come from converging developments in several fields [3]: renewable energy sources, cogeneration, electric mobility, heating and cooling systems and lighting technologies, just to mention a few. Certainly, a key role will be played by Information and Communication Technologies (ICTs), which have created new opportunities to improve the quality of life in urban areas with intelligent and energetically efficient solutions. ICTs, through wireless communications and the Internet of Things (IoT) paradigm, will be transforming traditional cities into smart cities, providing the core infrastructure behind more efficient public services. This process has already started: in early 2018, China had about 500 smart city pilot projects [4], the highest in the world, and over 1000 smart city pilot projects were ready or under construction worldwide.
whereas Section 7 outlines the IoT services that such infrastructures may provide in the next future as well as their integration with 5G networks. Final conclusions are drawn in Section 8.

Related Works
The possibility to dynamically and remotely control LED streetlights has been investigated mainly in the last decade. Starting from the first papers on this topic [15][16][17][18][19][20], different remote-control systems have been proposed, which rely on the exchange of information between light fixtures and a Control Center, the latter being the management headquarter for the lighting service. An overview of early researches concerning smart street lighting systems is presented in [13].
The ability to adapt the light intensity to actual conditions was considered since the pioneering era of smart lighting. For instance, the intelligent control of luminaries based on the detection of moving objects was proposed in 2013 [21]. In the same year, an intelligent streetlight management was presented in [22], which was jointly based on wireless communication technologies and environmental monitoring. Another investigation on intelligent street lighting based on the sensing of vehicles appeared in 2014 [23], which stated that energy savings could exceed 50% on roads with low traffic.
In the meanwhile, the smart city paradigm gained ground and smart lighting infrastructures were increasingly considered as a pillar of such concept [24][25][26]. In particular, they were meant (and are meant) to provide additional services, such as predicting traffic flows and regulate traffic lights [27]. Smart lighting infrastructures are thus assimilated to wireless sensor networks (WSNs), as in [28], where the performances of a WSN-based solution for the conversion of a standard public lighting network into a smart lighting system are reported and discussed. As in [29][30][31][32][33][34][35][36], smart lighting infrastructures can also be included in the IoT framework.
In recent years, the topic of urban smart lighting gained attention and several aspects of this technology were investigated separately. Some papers deal with the design of the hardware (e.g., light controller, lamp driver) [37][38][39][40][41], whereas other papers deal with the automatic, context aware, control of illumination [29,42,43]. There are papers concerning software/cloud-computing issues in smart city scenarios [44][45][46], others focusing on energy efficiency [47][48][49][50][51][52], as well as paper presenting smart lighting solutions based on specific communication technologies [53][54][55][56][57]. Photometric computations have been also addressed to achieve substantial power savings [58,59], whereas a formal model based on graph theory aimed at incorporating knowledge regarding multiple sensors into the lighting control model is proposed in [60].
As for significant testbeds, one of the largest is Smart Santander [61], where around 3000 IEEE 802.15.4 devices were deployed in the city of Santander (Spain), which makes the size of such testbed similar to the ones we discuss in our manuscript. However, in contrast to this paper [61] does not deal with smart lighting, thus no specific insight is provided on such application. As a matter of fact, current literature dealing with complete public-lighting infrastructures either shows simulation results, such as [62,63] or presents the results of limited testbeds with few nodes [24,30,64] or campus-wide installations [65,66].
To the best of the authors' knowledge, the scientific literature is lacking a complete discussion of all the aspects that have an impact on possible energy savings, which must be taken into account when planning a smart lighting infrastructure. In fact, different choices, in terms of adopted communications technologies and light controllers, generates different costs (e.g., for deployment and maintenance) and different energy savings as well as different opportunities to use the same communication network for other smart-city services. This paper aims at filling this gap, also considering future developments of smart lighting infrastructures, such as their integration with 5G networks. Furthermore, this paper provides the steps to be followed for the deployment of city-wide lighting infrastructures, which appear here as a further original contribution.

Smart Public Lighting: Infrastructure Architecture and Main Tasks
The most general architecture of a smart public lighting infrastructure is shown in Figure 1, which outlines all the main components, namely, the Control Center, the communication network (the core network in Figure 1) and the light controller (LC). The Control Center is the infrastructure management office: it commands/configures (e.g., light-on, light-off, dimming) each streetlight and monitors the infrastructure operating conditions for maintenance purposes. The command/information exchange between the Control Center and each streetlight takes place through the communication network, which must provide adequate coverage over the whole area where the light fixtures are deployed. Finally, LCs are the smart components of streetlights, as they actuate the commands received by the Control Center and send back the required information. In a smart city perspective, LCs may also be equipped with IoT sensors (e.g., for vehicular traffic metering or air quality monitoring), whose measurements are transmitted to application specific management centers (depicted in Figure 1 as Other Applications). Even in their basic version, smart LCs are in charge of four main tasks: • Task 1: to monitor in real-time the state of the luminaire, • Task 2: to monitor in real-time the electric parameters of the fixture, • Task 3: to drive the power supply, so as to dim the light intensity, • Task 4: to establish a communication link towards the Control Center.
Accomplishing Task 1 and Task 2 allows a timely maintenance, which results in shorter outages and lower operational costs. As for Task 3, both dynamic (context aware) or scheduled light dimming can be pursued, depending to the LC complexity. To provide a thorough discussion of Tasks 1, 2 and 3, a closer look at the LC communication ports is needed.
As shown in Figure 1, LCs have two main interfaces. The power supply interface allows to command the light dimming and collect data concerning electric parameters, whereas the network interface allows the bidirectional exchange of information between the LC and the Control Center.
With regard to the power supply interface, which concerns Tasks 1, 2 and 3, there are two traditional modalities to establish a communication link between the LC and the power supply: by means of an analog 0-10 V pilot signal or through a digital bus. In the former case, the LC outputs a pilot signal, whose voltage is interpreted by the power supply as the light percentage that must be provided (e.g., 1 V = 10%, 5 V = 50%, 10 V = 100%). In the latter case, a bidirectional digital bus is used. When this solution is adopted, the most common choice is the Digital Addressable Lighting Interface (DALI) bus [67]. In this case, data are exchanged by means of an asynchronous, half-duplex, serial protocol over a two-wire bus, with a fixed data transfer rate of 1200 bit/s. Bidirectional communications allowed by DALI are certainly a major advantage with respect to the unidirectional 0-10 V control. Ultimately, the following functionalities are digitally enabled by DALI [67]: • light dimming, • failure detection, • ability to send data related to the lamp's status, • ability to send electric information (e.g., voltage, current and power factor).
Additionally, DALI is more flexible than the 0-10 V control, as no polarity has to be respected for the two wires, whereas the opposite is true for the 0-10 V control. On the other hand, DALI entails an extra cost due to the added electronics and, in case of troubleshooting of dimming issues, it is more complex in terms of diagnostic. Typically, when the DALI bus is adopted in smart streetlight infrastructures, it is embedded in the LC of each luminaire.
As for the communication interface (Task 4), several solutions may be adopted, either wired or wireless. This choice is of paramount importance because the "smartness" of the lighting infrastructure as well the cost for its deployment and management strictly depend on the adopted communication technology. Given its importance, this issue will be discussed in Section 5, which is completely dedicated to communication aspects. In the following subsections, instead, Tasks 1, 2 and 3 are discussed.

Lamp Status Monitoring
For maintenance purpose, the most important information about a luminaire is whether its lamp is properly working or not. To this aim, two approaches can be adopted by the LC: • relying on the DALI bus to exchange information directly with the power supply, which provides measurements of electric parameters in a digital form, • exchanging information with an energy meter, so to diagnose possible LED module breakdowns comparing actual end expected energy consumption.
Both solutions allow to detect not only total breakdowns of luminaires, but also partial malfunctions due to failures of a fraction of the many LEDs chips of a lamp, which in fact result in a detectable reduction of energy consumption. Indeed, the event of a partial malfunctioning of a LED luminaire is not rare. It is usually due to high-voltage spikes, generated for instance by thunderbolts not totally filtered by surge protections, that could damage only some LED chips.

Electric Parameters Monitoring
LCs can be differentiated also according to the quantity and quality of information they can acquire about the electrical network. For instance, beyond active and reactive power consumption, further parameters can be of interest: voltage, current, power factor (cos phi), average consumption (hourly, daily, weekly, monthly, yearly).
The real-time acquisition of such values turns LCs into a distributed analyzer of the lighting infrastructure. Collected information, although not directly concerned with the energy saving objective, are useful to optimize the maintenance of the lighting plant. For instance, hardware failures and faults can be immediately detected and even, in some cases, anticipated. The real-time monitoring allows therefore predictive maintenance, which reduces expenditures avoiding costly emergency repairs, which sometimes also requires modifications to vehicular circulation. Moreover, such real-time distributed analyzer provides insightful data on the operating condition of the city power grid to which it is connected, which are valuable information for the grid operator. Therefore, LCs can be classified according to their capability of providing data with a high time resolution, rather than simply providing aggregated (e.g., averaged) data on a daily basis. In terms of technical requirements, a real-time monitoring of a multitude of parameters claims for higher technical performance, but allows a more effective infrastructure management.

Light Dimming
Clearly, the most important task of LCs is to dim light according to some criterion, to generate savings. Over the years, basic control systems have evolved into extremely advanced ones, providing enhanced capabilities to adapt the lighting intensity to the actual operating environment. In contrast to the simplest and old-fashioned LCs, which allow to settle the light intensity only according to a predefined schedule, cutting edge control systems allow to tailor the lumen output to the current vehicular traffic [68], whose amount is monitored by specific sensors, in some cases even taking into account meteorological conditions jointly with measured road surface luminance. Such advanced features are developed in accordance with specific regulations that allow to dynamically reduce the light intensity when specific conditions are met.
In particular, according to the CEN/TR 13201-2 lighting standard [9], each road is assigned a given lighting class, which mostly depends on the expected traffic flow. With reference to motorized traffic roads, [9] defines six classes, from M1 to M6 in decreasing importance order, each of which corresponds to a specific average luminance requirement. For instance, an average luminance of 2 cd/m 2 is required for the M1 class, 1.5 cd/m 2 for the M2 class, whereas 0.30 cd/m 2 is sufficient for the M6 class. However, the standard allows to dynamically adapt the lighting class to the actual conditions, assessed by means of real-time measurements.
In Italy, for instance, the CEN/TR 13201-2 standard is implemented through the norm UNI 11248, which standardises adaptive lighting strategies, thus allowing the design of systems that regulate lighting conditions according to factors that may vary over time, such as traffic flow, luminance or weather conditions. In particular, two different operating methods can be adoped: (a) TAI (Traffic Adaptive Installation), where only the traffic volume is measured; (b) FAI (Full Adaptive Installation), where even meteorological conditions and road surface luminance are measured.
When TAI is deployed, the lighting class can be downgraded by one if the measured traffic is lower than 50% of the nominal value, whereas a downgrade of 2 lighting classes is possible when the traffic is lower than 75% of the nominal value. Within TAI systems, the traffic volume is measured in given time intervals (usually in the order of 10 min), and dimming is allowed when two consecutive samples are below the limit.
The EU GPP document [7] provides some examples of operational profiles, which allow to gain an insight on the benefit of light dimming. In particular, a scenario is considered in which the light output is reduced by 50% during hours of low use, from 00.00 to 06.00. However, when traffic sensors indicate that road use is lower than a certain minimum level, the lighting output is automatically decreased to 10%. Although the exact energy savings vary from day to day, the road traffic pattern used in [7] resulted in a 30% reduction of the energy consumption with respect to the simple 100%-to-50% dimmed installation and almost 46% less than the same undimmed installation.
In contrast to TAI, which adopts a discrete step dimming, FAI updates the lighting class progressively and continuously between one and the other, to obtain the maximum energy saving. In this case, the dimming level is based on the joint assessment of traffic conditions, road surface luminance and meteorological conditions. Clearly, distinct approaches (preset dimming, TAI or FAI) lead to distinct savings, require different technologies and systems of varying complexity. If the most saving is to be achieved a low-latency communication network is required. In fact, when TAI or (to greater reason) FAI are adopted, streetlights belonging to the same TAI/FAI segment continuously exchange information, and they should react to varied conditions (adopting a different dimming level) simultaneously, so as to avoid to confuse drivers with differently illuminated portions of the road.
An additional feature, which is related to both security and energy saving is the so-called Constant Light Output (CLO). In this regard, it should be observed that the light flux of LED luminares reduces over time as the diode ages and dirt accumulates, just as most of other light sources. Typically, in the absence of any dimming capability, streetlights are overdriven since the first day, in such a way to significantly exceed the required light intensity, so that a reduction over time of the luminaire efficiency does not infringe the regulation on the minimum required illumination level.
This surplus margin depends on the Maintenance Factor (MF), which defines the percentage of the total light output at the start of the installation life, to which the output may eventually fall. The MF is computed taking into account the luminous flux factor (i.e., the depreciation of the luminous flux over time due to the light source aging) as well as other factors, namely the survival factors, the luminaire maintenance factor and the surface maintenance factor (see the ISO/CIE TS 22012 standard [69] for a complete description). Needless to say that this policy causes a useless waste of energy.
If the CLO functionality is implemented, the luminaire itself can compensate for the light depreciation, providing a constant light output [70][71][72]. The LED is initially powered at a given percentage (<100%) of its lighting capability and then continuously dimmed upwards to a final 100% current supply so that the required illuminance level is kept constant until the end of the service life. Clearly, this dim programming protects the LED chip and saves electricity costs over the entire luminaire lifespan.

Economic Analysis
In this section, we discuss the economic benefits that can be achieved transforming a traditional lighting infrastructure into a smart one.
In absolute monetary terms, costs and possible savings vary from one country to another. However, according to our experience, the relative contribution of each cost item (e.g., electricity, maintenance) to the overall cost figure is approximately the same all over the world, so as the possible savings that can be achieved introducing smart features. For this reason, in the following we will express such savings as a percentage of the yearly operational cost, maintenance included, of a traditional non-LED fixture. According to [73], this cost can be broken down as follows: • 70% for the cost of electricity, computed assuming 4200 lighting hours per year per each streetlight and 130 W traditional lamps. • 30% for maintenance operations, computed taking into account the costs of manpower (50%), the use of specialized vehicles (30%) and materials (20%).
Retrofitting with LED luminaires. Expected saving. In terms of energy consumption, simply replacing traditional luminaires with LED ones leads to a significant saving. In fact, a 130 W non LED lamp is equivalent, in terms of lighting intensity, to a 70 W LED one. Thus, a 46% saving in terms of electricity cost is achieved by simply replacing the luminaire, which means (considering the overall electricity+maintenance cost) a 32% saving per year per each fixture. This estimation, confirmed also by [13], is prudential as several papers claim that higher reductions in energy cost can be achieved [64,74]. In particular, Valentová et al. published a report on 106 test-beds from 17 European countries, showing an average energy saving of 59% compared with that of the original installation [5].
Light fixture remote monitoring. Expected saving. Additional savings can be achieved introducing an LC capable of both monitoring in real-time the lamp functioning (lamp status and electric parameters) and transmitting collected data along with the pole ID to the Control Center, which can timely infer or predict failure conditions. This allows both to prevent malfunctions (e.g., when a defective power supply poses a lamp in a stress condition) and to optimize failure recovery operations. In fact, broken lamps can be timely detected, along with their positions, so that repair teams can be dispatched according to a well-planned scheduling, also taking into account the best route to fix all failures in the same area. The amount of saving provided by improved maintenance practices is hard to estimate, as it depends on how maintenance is locally managed. It is expected, however, that it is in the order of a few percentage points per year per streetlight.

Light dimming. Expected saving.
Making the LC also capable of dimming LED lights leads to two more benefits. On the one hand, this feature enables the luminaire to follow daylight variations, meaning that the light intensity can be "tuned" with a fine time granularity to compensate variations in natural light at the sunset and sunrise, thus avoiding the energy wastage caused by a simple on/off policy [75]. On the other hand, the dimming profile can be easily adjusted over the years also to compensate the unavoidable luminous flux degradation due to luminaire aging. As anticipated in Section 3.3, dimmable light sources, such as LEDs, allow the implementation of the CLO functionality, which provides further energy saving. The economic benefit of light dimming depends on many factors, such as the luminaire Wattage, the adopted dimming profile and the daylight duration. Nonetheless, several trials showed that a reduction of 40%∼45% in energy consumption is a realistic target [76,77], which leads to a 15%∼17% saving per year per each fixture.
Dynamic dimming. Expected saving. Further economic benefit can be achieved introducing a dynamic, context-aware, lighting control mechanism.
An example of such technology is the previously introduced TAI, which adapts the light intensity to traffic conditions. According to the lighting standards CEN/TR 13201 [8][9][10][11][12], the traffic intensity must be calculated over a recent period of time. However, the norm gives no specification about the duration of such period. Clearly, the shorter the time window, the more responsive the system is, which might potentially lead to higher energy savings. The drawback is that more frequent vehicular traffic assessments entail an increase of the communication traffic among luminaries as well as of the data processing burden. A common value is a 15 min interval [78].
According to case studies investigated in Poland [68], the expected energy saving due to TAI adopting a 15 min interval could reach 47% compared to a preset dimming schedule, which is about 33% of the overall cost per year per each streetlight. Similar results can be found in [79].
LC operational cost. Clearly, the adoption of smart LCs introduces also some costs. In fact, LCs must be active 24 h a day, either because they also support additional IoT services or simply because they continuously listen to possible messages from the Control Center. Commercially available LCs have a global power consumption that varies between 1 W and more than 5 W (see [80,81] for further readings). This is a very significant difference. In a (conservative) ten years perspective of the plant lifetime and considering, for instance, a medium town with 10 k streetlights, two extreme solutions might lead to a difference of about 3.5 GWh in the whole period. This corresponds to hundreds of thousands dollars/euro, which might be saved with a proper choice of the LC.
Furthermore, in absolute economic terms, the saving generated by dynamic dimming is about 10 dollar/euro per year per each street light. Clearly, the operational cost of such feature cannot exceed the saving it provides. The thing is, though, that this functionality relies on frequent real-time communications (not only few bytes a day) whose cost should be carefully considered. In this regard, it appears very challenging to obtain from a telco operator the support for such an amount of data traffic with a yearly cost per each fixture significantly lower than the saving achieved by dynamically dimming the light. It follows that providing the LC with the dynamic dimming functionality calls for a proper choice of the communication technology, which might hardly be a third-party network (e.g., cellular), with the consequent fee.
More in general, the choice of the communication technology requires a more comprehensive discussion, as different choices have different impacts on costs as well as on the smartness of the lighting service and the possibility to offer additional services (not related to public lighting), supported by the same communication infrastructure. This fundamental issue is thoroughly discussed in Section 5. Overall economic balance. The San Diego case. As far as the cost of the whole infrastructure is concerned, a good reference is provided by the city of San Diego (USA), which recently replaced 14,000 of the city's more than 40,000 streetlights with energy-efficient LED lamps that can communicate with one another and operators and allow lighting adjustments to save energy. As reported in [82], "the price tag comes in at US $30 million, but it won't break the budget (. . . ) because it will save 60 percent in the cost of powering the city's lights. Over the next 13 years, these savings will more than cover the hardware and cloud-computing services required for the streetlight IoT." The reader may refer to the Annex IV ("Examples of Life Cycle Costing") of [7] for other examples of city-wide installations, which are described providing the economic details (investment, saving, payback period, . . . ).

Network Architectures and Transmission Technologies
The fundamental issue that needs to be addressed when designing a smart lighting infrastructure is how to establish a connection between each streetlight and the Control Center. Given the static nature of lighting infrastructures, both wired and wireless networks can be adopted. In the following we discuss both solutions, considering the related network architectures and communication technologies, having in mind the constraint that the Control Center must have the possibility to manage each light fixture individually.

Wired Networks
The most straightforward way to integrate all public light fixtures into a wired communication network is to exploit the existing power lines to convey also data signals. This is the Power Line Communication (PLC) technology, which turns the conventional electrical grid into a communication infrastructure. As reported in [83,84], PLC systems can be classified according to their bandwidth: • broadband PLC (1.8-100 MHz), which yields data rate in the order of Mbps with a coverage of few hundreds meters, • narrowband PLC (3-500 kHz), which provides data rate in the order of few hundred of kbps over several kilometers, • ultra-narrowband PLC (125-3000 Hz), which conveys very low data rates (roughly 100 bps) at tens or even one hundred kilometers.
Broadband PLC and ultra-narrowband PLC are not usually adopted in smart lighting scenarios, owing to their low coverage range and data rate, respectively [85,86]. Narrowband PLC is, instead, commonly adopted for this application. As shown in Figure 2, which depicts the typical PLC-based smart lighting infrastructure, communications take place over the low-voltage power cables (segments) between the luminaires and the electrical cabinet (segment controller). On its turn, the cabinet is connected to the Control Center by means of a wired (e.g., optic fiber) or wireless (e.g., cellular) wide area network (WAN).
This architecture is widely adopted in smart lighting infrastructures currently operating worldwide. PLC is, in fact, a mature technology, with the consequence that many manufacturers have been providing off-the-shelf solutions since many years. In perspective, however, it is questionable whether PLC is the best solution for the smart lighting infrastructures of future smart cities in the IoT era, which are expected to serve as backbone for plenty of location-based wireless services. In fact, future streetlights will be certainly equipped with wireless communication technologies, aimed at gathering/exchanging data from/with IoT devices (sensors, smart bikes, cars, parking lots, waste bins, . . . ) located in their surroundings. In view of this, there is no reason not to use the same wireless network to support both future IoT services and the smart lighting service, with no need of any PLC system dedicated to the latter.
Indeed, the awareness that IoT wireless services and smart lighting will be tightly intertwined in future smart city scenarios, is forcing several PLC manufacturers to upgrade their products in order to accommodate also IoT wireless technologies; PLC is mainly used for data transmission between the electrical cabinet and the luminaires, whereas the supplementary RF network, established by means of radio devices installed in each streetlight, is used to support communications with nearby IoT devices as well as (if necessary) between the luminaires.
In the authors' opinion, this solution, although in the right direction and fully understandable in a commercial perspective, does not have solid technical motivations, as the wireless network alone could easily uphold also (among the others) the smart lighting service, with obvious cost reductions. In addition, a properly designed wireless network is characterized by an intrinsic redundancy which is absent in common PLC architectures, which are more vulnerable to failures. Adding redundancy to PLC networks is certainly possible, but it comes at cost, as duplicated devices must be installed.
In the following section, an overview of the wireless communication technologies that can support smart lighting applications is provided, along with a thorough discussion of their strengths and weaknesses in such scenario.

Cellular Networks
Cellular networks are ubiquitous and widespread, covering around 95% of world inhabitants [87] and almost the totality of populated areas. Given their ubiquitous reach, cellular networks appear the ideal solution to effortlessly connect light fixtures to the Control Center. In principle, under the umbrella of the cellular network coverage, connecting a streetlight to the smart lighting infrastructure is as simple as equipping it with a cellular radio interface and turning it on. It will immediately connect with the cellular network that is already in place. From the perspective of the public lighting holders, this is certainly a good point, as no network installation is required nor its maintenance.
Moreover, cellular networks provide data rates that can scale from few kbps to hundreds of Mbps, thus supporting almost every service, from simple telemetering to more bandwidth-demanding applications, like video-surveillance. Focusing the attention on the basic smart lighting service, which generates small amount of data, it could rely on the two emerging cellular-based IoT standards, namely narrowband-IoT (NB-IoT) and long-term evolution (LTE)-Cat-M1, which have been designed to implement Low-Power Wide-Area Networks (LPWANs).
Both technologies are deployed as overlays of the LTE 4G cellular networks and provides data rate up to 250 kbps (NB-IoT) and 1 Mbps (LTE-Cat-M1), respectively. Like all LPWAN technologies, they have been designed to allow long range (several kms) communications at a low bit rate among connected "things", such as sensors powered by batteries.
Cellular networks, along with their LPWAN developments, certainly appear a convenient solution for providing the smart lighting infrastructure with the required connectivity. There is, however, a number of issues that should be carefully considered.
First of all, connectivity is very critical to smart lighting. Street lights that do not experience an adequate level of received power from the cellular base stations are out of the infrastructure-management control. This issue is particularly critical because, although it is true that cellular networks are ubiquitous and widespread, a target coverage of 100% can not be reached in dense urban environments. Buildings or other obstacles can obstruct the signal propagation to an extent that in some locations the communication is impossible or, at least, intermittent. Furthermore, this situation may occur at any time, as new buildings are raised. Fixing such issue could be very difficult, because the cellular network is owned by a third party (the network operator), which could not be willing (owing to cost or technical difficulties) to change the network layout.
Secondly, since cellular networks are run by third party providers, lighting infrastructure holders have to pay a cost for their usage, which could be significant because thousands of streetlights have to be connected. Thus, the economic saving achieved thanks to the smart light management is reduced owing to this additional cost. Moreover, network operators might decide to increase over time the cost for the service subscription, according to dynamics not controlled by the lighting infrastructure holders.
Thirdly, using the cellular network to provide connectivity to streetlights suggests that the lighting infrastructure holder is unwilling to implement and manage its private communication network. Although this choice is understandable, as it reduces the effort on the public lighting holder's side, it prevents the possibility to use such private network also for additional IoT services that might be of interest. For instance, the lighting infrastructure holder could gain revenues by giving other utilities (waste collectors, smart bike rentals, . . . ) the access to its private network, or simply give them free access in order to foster such services.
Finally, the expected lifetime of a lighting infrastructure is around 15-20 years, which is a very long period in terms of technological evolution. In such a long period, the cellular technology chosen for the smart lighting infrastructure at the time of its deployment might be switched off by network operators to free up frequencies for new technologies. This is what is currently happening with the 3G technology that, although still excellent for many IoT applications, will be dismissed in the next years, 15-20 years after its deployment. It has to be observed, in this regard, that a communication technology is possibly chosen for the smart-lighting service only during its full maturity, which means that its expected residual lifetime might be less than the lighting infrastructure lifespan.

Non-Cellular LPWANs
Non-cellular LPWANs are increasingly adopted for smart lighting applications, as they allow to reduce the operational costs of streetlights networking with respect to cellular networks. Long Range (LoRa) and Sigfox are, in particular, the LPWAN technologies mostly considered in smart lighting scenarios, thus deserving specific discussions. LoRaWAN [88] is a point-to-multipoint networking protocol for WAN communications that uses the LoRa proprietary modulation scheme owned by chip manufacturer Semtech. More specifically, LoRaWAN is an open-standard that defines the medium access control (MAC) layer for LPWANs based on the LoRa chip, which transmit over license-free bands (169 MHz, 433 MHz, 868 MHz and 915 MHz) with a very long transmission range (more than 10 km in rural areas) and low power consumption [89][90][91][92]. It supports bit rates ranging from 250 bps to 21.9 kbps.

LoRa wide area network (LoRaWAN):
It was designed to connect battery-powered, low bit rate, IoT devices across a wide coverage area. Regarding network aspects, LoRaWANs are generally laid out according to a star topology and the central node is usually called gateway. In urban scenarios, more than one gateway might be installed to increase the coverage, so that several star networks might be deployed to cover the whole service area.
The typical communication infrastructure adopted in smart lighting scenarios is shown in Figure 3, where two star networks providing connectivity to groups of light fixtures are depicted. Each gateway, acting as a hub, is then connected to the Control Center by means of the widespread cellular network or another IP-based communication technology.
As can be observed, the resulting network is very similar, from an architectural point of view, to a cellular network. In fact, the LoRa gateways spread across the city play exactly the same role of the cellular BSs. The main difference is that LoRa networks are private ones, so that the holder of the smart lighting infrastructure is also the owner of this fundamental asset. In any case, if the cellular network is adopted to connect the LoRa gateways to the Control Center a fee is to be paid, which is however scarcely significant owing to the low number of gateways.
Sigfox: Sigfox is an LPWAN network operator that offers end-to-end low bit-rate IoT connectivity based on its patented technology. Its proprietary BSs are deployed in the service area by Sigfox partners and are connected to the back-end servers through an IP-based network. They provide wireless connectivity to end devices in unlicensed ISM bands (868 MHz in Europe, 915 MHz in North America, and 433 MHz in Asia). By employing ultra-narrow band (100 Hz) signals, Sigfox communications experience very low noise levels, thus achieving large coverage distances (up to 10-40 km in rural zones and 1-5 km in urban zones) at the expense of maximum throughput of only 100 bps [93].
Sigfox supports limited bidirectional communications: downlink communications can only occur following an uplink communication. The number of uplink messages is limited to 140 per day, with maximum payload of 12 bytes for each message, whereas the number of downlink messages is limited to 4 messages per day, with maximum payload of 8 bytes [94].
As far as the network topology is concerned, Sigfox adopts the same architecture previously described for LoRa. Also in this case, an adequate number of hubs, usually called Sigfox stations, are deployed in the services area, each of them establishing a star network (as shown in Figure 3). However, differently from LoRaWAN, Sigfox networks are owned by Sigfox itself, hence, end users have to pay for the connectivity. In the case of smart lighting scenarios, this entails that a fee is to be paid for thousands of streetlights.
Both LoRa and Sigfox technologies are currently adopted by several light fixture manufacturers. The choice between one or the other depends on the willingness of the public lighting holder to deploy and manage its own network with a low (if any) communication fee (this is the LoRa case) or, contrarily, to avoid any issue with the installation and management of the communication network, which entails that a communication cost is to be borne for each streetlight (this is the Sigfox case). As previously observed, in the former case the lighting infrastructure holder might also gain revenues from its private network, whereas in the latter case the communication service is simply a cost, which could increase over time.
It is worth observing, moreover, that both technologies suffer from the same coverage issue that affects cellular networks, which in fact have the same architecture: differently from mobile phones, which can counteract a poor communication quality thanks to the mobility of users, street lights are static, which make them very vulnerable to obstructions (foliage, buildings, . . . ) that clutter the communication link. Although it is true that both LoRa and Sigfox devices greatly outperform cellular devices in terms of receiver sensitivity, the occurrence of local coverage gaps cannot be excluded and might happen unexpectedly (e.g., when a new building is raised).
Mostly important, such networks were not conceived to support real-time communications, which are required to allow the simultaneous dimming of all interested streetlights when traffic adaptive lighting profiles are adopted.

Mesh Networks
Connectivity issues arising with star networks can be overcome adopting a mesh network architecture. In this case, wireless nodes can connect directly, non-hierarchically and even dynamically, to as many other peer nodes as required, provided that they are in their coverage range, and cooperate with one another to efficiently route data. This lack of dependency on a central node allows for every node to participate in the relay of information, which propagates hop-by-hop.
The typical mesh network in a smart lighting scenario is depicted in Figure 4. One observes that streetlights are grouped in clusters, in which hop-by-hop communications are allowed among neighbors. These communications usually take place by means of short range, low cost, communication technologies, such as IEEE802.11.4 and Bluetooth. Within each cluster, one or more streetlights can communicate with a special network node that is also equipped with a long-range communication technology (cellular, optical fiber, . . . ). This enhanced node acts as a gateway, allowing the bidirectional exchange of information/commands between the Control Center and all poles of the cluster. If the cellular network is adopted to connect the gateways to the Control Center a fee is to be paid, which is however scarcely significant as the number of gateways is much lower than the number of streetlights.
This architecture is much less prone to coverage issues, because neighboring streetlights are close one to the other, and in most cases they experience line-of-sight propagation conditions. Moreover, inter-pole communications do not require any subscription (nor any fee) to a network provider, because the owner of the public lighting infrastructure is also the owner of the inter-pole communication network. In the following, two of the most important technologies for mesh networking are presented, namely IEEE802. 15 As far as the physical layer is concerned, several modulations schemes can be used, providing over the-air speeds of up to 250 kbps in specific unlicensed (depending on the geographic region) 800, 900 and 2400 MHz bands. The transmission range goes from tens to hundred meters, depending on the propagation conditions.  15.4 node that acts as a gateway towards the Control Center, thanks to an additional long-range communication interface, either wireless (e.g., cellular) or wired (e.g., optical fiber). According to the IEEE 802.15.4 terminology, the gateway is termed Coordinator, whereas each sector of the lighting infrastructure controlled by a Coordinator is termed personal area network (PAN). In order to avoid mutual interference, adjacent PANs work on different channels. Lastly, at the upper level there is the Control Center, which manages all sectors of the lighting infrastructure.
The information propagates from the center to the peripheral (and backwards) hopping from one luminaire to another. Since luminaires are usually deployed along streets, the resulting topology is composed by linear segments and some branches, which eventually form a number of trees, rooted at the corresponding gateways.
In actual deployments, IEEE802.15.4 transceivers have a transmission range that covers not only the adjacent light-poles but also a number of nearby luminaries. This makes the system intrinsically robust to possible failures, as a given streetlight is usually reachable by more than one neighbor.

Bluetooth mesh networking:
Bluetooth is one of the best known and most ubiquitous wireless communications technologies on the planet. It has been in existence since 2000 and is currently integrated into billions of devices. It operates in the 2.4 GHz ISM band and uses frequencies between 2402 and 2480 MHz. Initially, it was simply intended as a cable replacement technology, becoming soon the dominant solution for the connection of audio devices as well as of computer peripherals. However, it has been systematically improved with the addition of new functionalities, enabling it to keep pace with market requirements.
Bluetooth mesh networking (BMN), conceived in 2015 and adopted on July 2017 [96,97], is the latest chapter in this evolution path. It was designed to allow many-to-many communications by meshing together hundreds (or even thousands) of devices capable of handing off messages to each other, thus is gaining momentum for smart lighting applications.
Similarly to the previously described IEEE802.15.4 technology, BMN establish a communication infrastructure where light fixtures can communicate with one another to relay commands, diagnostic information and possible data transmitted by nearby smart devices. The resulting mesh network architecture is the same depicted in Figure 4.

Communication Technologies for Smart Lighting Infrastructures: Conclusions
At the end of this section, some conclusion can be drawn concerning the choice of the communication technology best suited to public lighting scenarios.
Wired or wireless networks? The first question that must be addressed is whether to rely on wired or wireless solutions. In the authors' opinion, wired networks, although currently adopted in many street lighting infrastructures, do not represent a reasonable choice when considered in the modern perspective of smart city and IoT scenarios. Such kind of networks, mainly implemented using PLC technologies, represent dedicated communication infrastructures, aimed at providing only the smart lighting service. Considering the ongoing evolution of urban environments, which will be more and more studded with smart object requiring connectivity to exchange data, the deployment of a city-wide network to support a single service is certainly, if nothing else, a missed opportunity. Contrarily, wireless networks are the key enablers for upcoming smart city and IoT applications. Their flexibility, widespread coverage and low deployment cost make them the only feasible choice to interconnect the multitude of smart devices that are being deployed in our cities.
Street lights as smart objects or connectivity providers? Each streetlight of a smart lighting infrastructure might be, on the one hand, one of the many smart objects (sensors, meters, . . .) disseminated in the urban area, which require a wireless connection to operate, or, on the other hand, it could be itself part of a city-wide wireless network that provides connectivity to other objects.
Undoubtedly, the former is the simplest solution. Under the coverage of a third-party wireless network (e.g., cellular or Sigfox), connecting a streetlight to the smart lighting infrastructure simply means to provide it with the proper radio interface and turn it on. It will immediately connect with the wireless network that is already in place. The main downsides of this choice are the need for a service subscription that covers all streetlights, with the corresponding fee to be paid to the network provider, and the impossibility to gain revenues from the smart lighting infrastructure, which remains a passive asset.
On the other hand, turning the smart lighting infrastructure into a capillary, multifunctional, city-wide communications network, capable of relaying information, gathering data and delivering services to and from IoT devices, makes it a dynamic platform serving as backbone for smart city developments. In this case, the public light asset offers opportunities to deliver new services and generate revenues, instead of just being a cost factor. However, this requires the installation of a private network (e.g., LoRa or mesh).
The latter scenario is certainly the most challenging one, as it requires a higher commitment by the lighting infrastructure holders. They need to be fully involved in development path of the urban area in which they operate, as they play a key role in the process that turns a city into a smart city.
To conclude this discussion, Table 1 provides a SWOT analysis (strengths, weakness, opportunities, threats) of the previously introduced communication technologies for smart lighting applications. Focusing the attention on wireless communication technologies, in the following section we will provide the design criteria of a smart lighting infrastructure. Higher number of gateways. other services and Low latency.
Low bit-rate gain revenues.

Deployment and Configuration of a Smart Lighting Infrastructure
Getting to the final deployment of a smart lighting infrastructure requires three main steps: • Step 1: preliminary design, • Step 2: in-field verification and light fixtures upgrade, • Step 3: network partitioning and lighting tasks configuration.
each of which is thoroughly discussed in the following.

Step 1. Preliminary Design
The preliminary design of a smart lighting infrastructure is composed by the following phases: Phase 1.1. Acquisition of the plant topology and connectivity survey. The preliminary design begins with the acquisition of layout of the existing lighting infrastructure, to identify areas that might suffer from connectivity problems. Already available networks (cellular, WiFi, optical fiber, . . . ) are accurately mapped, as they can serve as backbone or provide backbone alternatives to reduce management costs (for instance, avoiding the subscription to a service provider).

Phase 1.2. Choice of the communication technology and detection of gateways positions.
Starting from the analysis in Phase 1.1, as well as from the willingness of the public lighting holder to create its own network or to rely on a third party network infrastructure, the communication technologies are chosen.
If a third party network (e.g., cellular, Sigfox) is used to establish communication links between streetlights and the Control Center, no dedicated gateway needs to be installed, as the network is already in place. If, on the contrary, a proprietary network must be installed, either with a star topology (e.g., LoRa) or a mesh topology (e.g., IEEE802.15.4, BMN), the best locations for the gateways must be detected. Star networks (e.g., LoRa) must prioritize the highest and most central locations, to allow a better coverage, although this could generate additional costs if a fee is to be paid for the hosting of the gateways. Furthermore, star networks can hardly guarantee 100% coverage in urban environments. Therefore, in this phase it is important to consider whether the cost for extending the coverage to unserved areas is reasonable with respect to the saving that can be achieved.
Mesh networks allow a greater flexibility in the gateway positioning phase, because gateways need to cover only a very small subset of network devices. Moreover, since the network arises from hop-by-hop communications among devices installed on streetlights, which are close one to another, it is usually able to guarantee 100% coverage. Clearly, the number of gateways is higher than that required for LoRa networks. This is even more true considering that it is generally not kept at the strict minimum, in order to avoid bottlenecks, provide higher throughput and reduce the latency. Phase 1.3. Choice of traffic sensors locations. The third step is the detection of the streets where to place vehicular traffic sensors, which are needed to implement traffic-adaptive energy saving algorithms, such as TAI or FAI [68,79]. As outlined in Section 3.3, significant savings can be achieved by dynamically adapting the light intensity to actual traffic conditions. However, dynamic light dimming is allowed provided that safety conditions are guaranteed. Thus, the designer of the lighting infrastructure must identify candidate streets, perform a risk analysis and, in case, find the dimming policies capable of achieving the highest saving without affecting transport security.
In this regard, it is worth observing that, to avoid confusing the drivers, the light dimming must take place simultaneously in all the interested light fixtures, which requires a low-latency communication network.

Step 2. In-Field Verification and Light Fixtures Upgrade
Phase 2.1. In-field verification and gateway installation. If a third party network is chosen to provide the connectivity to streetlights, the network provider must be selected, either Sigfox or one of the available cellular providers, considering both the service coverage and the yearly fees.
If, on the contrary, the deployment of a proprietary network is chosen, an in-field verification phase is needed to check whether the locations chosen for the gateways, either LoRa, IEEE 802.15.4 or BMN, actually provide the expected link quality. In the LoRa case this is a critical phase as, in principle, one should first make tentative choices of gateways locations, prioritizing the highest sites, install them and check whether all light fixtures experience good connectivity conditions. Clearly, when thousands of smart fixtures are to be installed, only a subset of communication links can be checked, which means that 100% coverage might not be reached when the network is fully deployed. The deployment of IEEE802.15.4 and Bluetooth gateways is much less critical, as each of them needs to be connected only to a few streetlights, which usually experience line-of-sight conditions. Based on the outcomes of the verification phase, the gateways are finally installed.
Phase 2.2. Light fixtures upgrade. Upgrading each street light with a smart LC is not only a matter of replacing the old hardware with the new one. A fundamental step of this phase is the georeferentiation of each device, whose unique MAC address must be associated to a specific location. As a matter of fact, the installation might well involve thousands of streetlights and in case a failure is reported to the Control Center by the LC, along with the its MAC address, the corresponding position should be immediately known for a timely maintenance.
Usually, smart lighting devices come with a set of identical (for each device) barcode stickers, which are attached to the fixture and to the installation sheet that has to be filled in by the installer. Such sheets, that contains also the positions of devices, provide the link between the MAC address of each device and its location. Clearly, this is an error prone procedure, with many weakness points (transcription errors, stickers swapping, . . . ).
More advanced instruments are at disposal, such as portable devices that scan barcodes and communicate the streetlight coordinates to the Control Center. The most straightforward solution is to equip the LC with a GPS receiver, so that its position is automatically acquired and sent to the Control Center each time a report is transmitted.

Step 3. Network Partitioning and Lighting Tasks Configuration
Phase 3.1. Network partitioning. Whenever gateways are needed, as in the cases of LoRa, Sigfox or mesh networks, streetlights are grouped into clusters, each of which relies on its own gateway to establish a communication link towards the Control Center. Such clusters are created by associating to the designated gateway the MAC addresses of all LCs that logically belongs to the same group.
This phase might be highly or scarcely critical, depending on the adopted network topology. In general, star networks are more vulnerable to local coverage gaps that, unfortunately, are discovered only during the installation phase. In fact, when thousands of streetlights have to be upgraded, it would be impossible to check in advance the gateway coverage for each of them. Should coverage gap exist, additional gateways would have to be deployed, provided that this solution is both feasible and affordable. If not, some streetlights will be unreachable. But still, the addition of one or more gateways require a revision of the network partitioning, at least locally, with possibly the need to change the reference gateway of already configured streetlights.
Mesh network are far less prone to such issue, as only one streetlight of the cluster must be associated to the reference gateway (see Figure 4). The other streetlights need only to communicate with their neighbors, which in most cases are in line of sight. Clearly, the shorter the installation time, the lower the network deployment costs. Phase 3.2: Configuration of dynamic dimming algorithms. If a network has been chosen that allows the dynamic dimming, in this phase all profiles and behaviors will be defined according to external events, to maximize energy saving and keep road safeness unaltered.
In particular, TAI/FAI algorithms are implemented only on specific streets selected by the light engineer in charge of the light project deployment, who also defines the corresponding lighting classes. Specific sensors (traffic, weather, . . . ), installed for each interested street or group of streets, provide the information to dynamically select the dimming level. The LCs of streetlights that should simultaneously dim the light are logically grouped at the Control Center, and controlled as a whole.

Future Services and Integration with 5G Networks
In Section 4, we discussed the saving that can be achieved turning a conventional public lighting infrastructure into a smart infrastructure. However, the benefits of such technology are not limited to economic aspects: Provided that the lighting infrastructure is designed with a far-looking view, an important consequent effect is the availability of a capillary wireless network that reaches every location where a smart streetlight is present. This enables the collection of data from nearby sensors and the provision of new services, concerning, for instance [98]: • smart parking: real-time monitoring of parking lots (vacant/occupied); • waste management: detection of rubbish levels in containers to optimize the trash collection routes and schedule; • air quality: monitoring of the air pollution level; • structural health: monitoring of vibrations and material conditions in buildings, bridges and historical monuments; • vehicular traffic: detection of traffic jams and suggestion of alternative routes through variable message signs.
Moreover, as smart public lighting infrastructures are being deployed, new opportunities are emerging to fuse different smart technologies. In this regard, it is worth mentioning the emergence of 5G, the next-generation cellular technology, that is expected to debut in 2019 with the release of smartphones and network upgrades that will allow higher speeds and lower latency.
As pointed out in Section 1, in order to meet the impressive data rate requirements of this technology, 5G cells will be limited in coverage, which means that many more base stations will be required to ensure a seamless service experience. Network engineers are looking at lighting infrastructures as the solution for the ultra-dense placement of 5G base stations across smart cities [3,99]. For cellular network providers, the advantages of equipping streetlights with 5G base stations include: • the availability on the installation site of the power supply, which avoids separate cabling costs, • a regular and effective deployment, as streetlights are typically tall and evenly spaced, which eases the network planning phase and reduces the occurrence of coverage gaps, • the availability of a single "counterpart" (the public light holder), who leases the sites for hundreds (possibly, thousands) of base stations, • given the location of streetlights along roads, the possibility to support location-based roadside-to-vehicle communications for intelligent-transport services or autonomous driving.
Regarding the cost of integrated 5G/smart lighting infrastructure, one observes that modern light fixtures are composed by separate modules (lamp+light controller, WiFi access point, photometrical unit, IP camera, . . . ) connected each other atop the pole. The 5G transceiver will be simply an additional, removable, module of the light fixture, whose cost would be in charge of cellular operators (as it happens in the case of traditional base stations). Contrarily, the smart lighting operator would have an income given by the site-rental fees paid by the cellular operator. Examples of initiatives aimed at developing 5G-enabled smart lighting fixtures are provided in [99,100].

Conclusions
Public lighting is currently the core of many smart city initiatives around the world. By replacing traditional street lights with LED-based lamps, utilities can cut energy and operations costs by 46% or more. Further savings can be achieved introducing an adequate dimming control during offpeak hours as well as by networking streetlights, also introducing the capability of sensing actual conditions (traffic, weather, luminance conditions) and dimming lights accordingly. Enabling such functionalities, thus turning the lighting infrastructure into a smart one, could lead to an overall saving of 80% or more.
Beyond energy savings, since each smart streetlight needs to be provided with bidirectional communication capabilities, an ubiquitous city-wide communication network arises from the lighting infrastructure. Streetlights are no longer isolated elements, but could establish a capillary, multifunctional, city-wide communication network, capable of relaying information, gathering data and delivering services to and from millions of IoT devices. Streetlights could thus support city-wide IoT services, which will make them key enablers of the smart city revolution.
In this paper we provided a thorough discussion on network architectures and communication technologies that could be adopted for this application, showing the benefits and downsides of each. In particular, we argued that the realization of a private network with a mesh topology, although more challenging for the infrastructure holder, is more suited to support both the smart lighting service and additional IoT services. Moreover, we outlined the steps required for the deployment of a smart public lighting infrastructure, each discussed in accordance with the network topology under consideration. Again, we showed that mesh networks are less prone to coverage issues and more responsive when real-time dimming is required.
Finally, we introduced some of the additional services that a smart public lighting infrastructure could support and we discussed the benefits that would arise from the integration with the upcoming 5G cellular network.
Author Contributions: The first author wrote the paper, with the contributions of the other authors for specific topics and sections. All authors contributed to the text revision.
Funding: This research received no external funding.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: