ITERL: A Wireless Adaptive System for Efficient Road Lighting

This work presents the development and construction of an adaptive street lighting system that improves safety at intersections, which is the result of applying low-power Internet of Things (IoT) techniques to intelligent transportation systems. A set of wireless sensor nodes using the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard with additional internet protocol (IP) connectivity measures both ambient conditions and vehicle transit. These measurements are sent to a coordinator node that collects and passes them to a local controller, which then makes decisions leading to the streetlight being turned on and its illumination level controlled. Streetlights are autonomous, powered by photovoltaic energy, and wirelessly connected, achieving a high degree of energy efficiency. Relevant data are also sent to the highway conservation center, allowing it to maintain up-to-date information for the system, enabling preventive maintenance.


Introduction
Until recently, communication was considered to be a type of relationship among humans. The Internet was created in the 1970s to exchange information among connected computers. The capability of connecting smart devices, identified with a unique address, to the Internet paved the way for the so-called Internet of Things (IoT). It is expected that "things" communicating with other "things" on behalf of people will dominate the future of Internet communications. In fact, it is estimated that, at some time between 2008 and 2009, the number of devices connected to the Internet became higher than that of connected people. Since then, this number has grown exponentially.
The integration of the IoT with intelligent traffic systems has recently been explored [1][2][3][4][5]. The IoT can provide both infrastructure and vehicles with sensors that can measure general traffic conditions, ambient variables, vehicle variables (such as position and speed), and driver conditions. For example, with this information it is possible to measure the intensity of traffic and the degree of traffic congestion, as well as to detect risk situations. Through local and global smart processing, it is possible to act on traffic control systems and interact with the drivers in order to reduce waiting times, increase the efficiency of transport systems, and decrease the accident rate. Ultimately, from the information Rapid detection of fault, emergency, and alarm situations, which are immediately reported to the central station.  Figure 2 shows the hardware architecture of ITERL, which is described in detail below.

Sensing Devices
A set of sensors was used for the measurement of the ambient conditions (illumination, rain, temperature, and humidity), while video cameras were used for vehicle detection. Table 1 shows the selected sensors and the video camera, as well as their main features.

Wireless Nodes
There is a strong demand for wireless solutions in applications where high speed data transmission is not required, but small, cheap, and autonomous (low power) terminals are required, which guarantee secure and reliable communications. Many of these applications require topologies  Figure 2 shows the hardware architecture of ITERL, which is described in detail below.  In ITERL, the wireless network collects the data measured by the sensors, establishes communication with the gateway, and receives the data from (transmits the commands to) the streetlight control nodes. The wireless network is composed of three types of nodes: the coordinator node, sensor node, and actuator node. They have a common wireless platform that uses the CC1125

Sensing Devices
A set of sensors was used for the measurement of the ambient conditions (illumination, rain, temperature, and humidity), while video cameras were used for vehicle detection. Table 1 shows the selected sensors and the video camera, as well as their main features.

Wireless Nodes
There is a strong demand for wireless solutions in applications where high speed data transmission is not required, but small, cheap, and autonomous (low power) terminals are required, which guarantee secure and reliable communications. Many of these applications require topologies with a large number of nodes and the lowest possible cost per node. The development of IEEE 802.15.4 technology with different protocol stacks has provided a solution for this demand, which has experienced exponential grow in the last decade. IEEE 802.15.4 features low data rates and high energy efficiency, as well as versatility for the deployment of large networks with complex topologies. We would like to mention the existence of protocol stacks such as ZigBee and Rime, as well as some other implementations that allow IP networking, such as micro-IP (uIP) TCP/IP in its V4 and V6 versions.
In ITERL, the wireless network collects the data measured by the sensors, establishes communication with the gateway, and receives the data from (transmits the commands to) the streetlight control nodes. The wireless network is composed of three types of nodes: the coordinator node, sensor node, and actuator node. They have a common wireless platform that uses the CC1125 transceiver and the MPS430 family microcontroller, both from Texas Instruments. The MPS430 microcontroller family consists of ultra-low-power devices whose architecture, combined with low power operation modes, is optimized to extend battery life in portable applications. Specifically, the MSP430F5438A device was used here. It integrates general purpose IO pins, a power management stage, and Universal Asynchronous Receiver-Transmitter (UART), Joint Test Action Group (JTAG), and mini USB interfaces. Figure 3a shows the wireless platform hardware developed for the 868 (Europe)/915 (USA) MHz band. transceiver and the MPS430 family microcontroller, both from Texas Instruments. The MPS430 microcontroller family consists of ultra-low-power devices whose architecture, combined with low power operation modes, is optimized to extend battery life in portable applications. Specifically, the MSP430F5438A device was used here. It integrates general purpose IO pins, a power management stage, and Universal Asynchronous Receiver-Transmitter (UART), Joint Test Action Group (JTAG), and mini USB interfaces. Figure 3a shows the wireless platform hardware developed for the 868 (Europe)/915 (USA) MHz band. The hardware of the border router coincides with the wireless platform shown in Figure 3a, since it does not require extra components. This node acts as a coordinator node for the 802.15.4 network. It is in charge of creating the network, managing the routing, and the connection and disconnection of nodes. It receives the messages sent by sensor nodes towards the local controller, and resends the commands received from the local controller to the actuator nodes located in the streetlights. There is only one border router in the network. For the sensor node ( Figure 3b), a specific card was designed to condition the signals coming from sensors. It is plugged into the common wireless hardware platform previously mentioned. It also contains the voltage regulator required to power both the sensors and the sensor node itself.
The actuator node (Figure 3c) controls the on-off function of the streetlights, as well as their illumination level using pulse width modulation (PWM). To this end, a control card was designed that activates and deactivates the streetlights by means of a relay (PE014005), which acts as a power switch. To set the illumination level, from an internal voltage source, a programmable voltage divider built with a digital potentiometer (MAX5160) selects one of 32 different voltage references for the PWM regulator (Figure 4a).  The hardware of the border router coincides with the wireless platform shown in Figure 3a, since it does not require extra components. This node acts as a coordinator node for the 802.15.4 network. It is in charge of creating the network, managing the routing, and the connection and disconnection of nodes. It receives the messages sent by sensor nodes towards the local controller, and resends the commands received from the local controller to the actuator nodes located in the streetlights. There is only one border router in the network.
For the sensor node (Figure 3b), a specific card was designed to condition the signals coming from sensors. It is plugged into the common wireless hardware platform previously mentioned. It also contains the voltage regulator required to power both the sensors and the sensor node itself.
The actuator node (Figure 3c) controls the on-off function of the streetlights, as well as their illumination level using pulse width modulation (PWM). To this end, a control card was designed that activates and deactivates the streetlights by means of a relay (PE014005), which acts as a power switch. To set the illumination level, from an internal voltage source, a programmable voltage divider built with a digital potentiometer (MAX5160) selects one of 32 different voltage references for the PWM regulator ( Figure 4a).
The actuator node (Figure 3c) controls the on-off function of the streetlights, as well as their illumination level using pulse width modulation (PWM). To this end, a control card was designed that activates and deactivates the streetlights by means of a relay (PE014005), which acts as a power switch. To set the illumination level, from an internal voltage source, a programmable voltage divider built with a digital potentiometer (MAX5160) selects one of 32 different voltage references for the PWM regulator (Figure 4a).

LED Luminaires
An 84 W LED luminaire was selected for ITERL ( Figure 4b). It comes with a regulator that raises the voltage level up to 48 V and a dimmer that receives the PWM signal from the voltage regulation card mentioned above. Table 2 shows the technical specifications of the selected streetlight.

Local Controller, Image Processor, and Gateway
Signals coming from sensors are locally processed in the microcontroller available in their corresponding sensor node. The local controller, built on a BeagleBone Black platform, concentrates the information coming from (and directed towards) the wireless network. Concerning the video cameras, powerful hardware is required to build the image processor, and an industrial computer (the VBOX 3200) was selected for this purpose. The image processor is also in charge of transmitting the data to a remote server using a 3G link, acting as a gateway for ITERL

Wireless Sensor Network (WSN)
The network topology is shown in Figure 5. It is organized as an IPv6 subnet. At a functional level, the client-server communication paradigm was followed, so that end devices establish User Datagram Protocol (UDP) communication with the coordinator node, which also acts as a 6LowPAN border router (BR). Sensor nodes collect the ambient information (illuminance, ambient temperature, relative humidity, and rain). The coordinator node collects the data coming from sensor nodes and sends them to the communication gateway through a series connection, over which the serial line Internet protocol (SLIP) is implemented. Although a star topology could have been selected, the presence of a router allows that multiple intersections to be controlled in the future by the same local controller. At the actuation level, an actuator node is placed in each of the streetlights to control the illumination level.
Contiki was chosen as the operating system (OS). Contiki is a small, open source, highly portable, and multi-task-oriented OS developed for small systems, ranging from 8 bit computers to • RDC Protocol: In the Contiki OS, the driver chosen was the contikimac_driver; • Frame Formation Protocol: Frames are generated in accordance with the IEEE 802. 15.4 protocol. In the Contiki OS, the framer_802154 driver was used; • Radio Protocol: This defines the transceiver driver. In the Contiki OS, for the CC1125 transceiver, the driver chosen was the cc1125_driver.
The wireless network uses a mesh topology with adaptive route optimization. Extensive simulations using COOJA [17], a simulator especially designed for the Contiki OS, was used to optimize throughput.

Border Router, Local Controller, and Gateway
The border router has the ability to perform bidirectional IPv6 to IPv4 datagram conversion in order to communicate with the WSN with the web through the gateway. The image processor gateway is responsible for receiving, managing, processing, and storing the network information resulting from communication between the coordinator, sensor and actuator nodes, and the video cameras. In addition, it also processes the commands to act on the streetlights, which are triggered by the arrival of an event.
The communication links between these elements use the following: • A SLIP interface that links the local controller with the coordinator of the wireless network (i.e., the border router). The use of this protocol allows the transmission of IP packets over a serial line in a simple way. It does not support either error control or frame fragmentation. Contiki uses SLIP to adapt the IPv6-based wireless network to a higher capacity device, such as the communication gateway through the coordinator node. In the For data interchange between the Wireless Personal Area Network (WPAN) devices, Contiki incorporates two communication stacks: Rime and uIP. Packets with an IP destination address that matches the address associated with a valid node are registered. If they use the IPv6 protocol, the uIP stack looks for the existence of any extension header and processes it, generating an Internet Control Message Protocol (ICMP) error message in case of errors. The packet is only uploaded to the transport layer when no errors are found when processing the headers, the package length is correct, and the destination address matches the address of the receiving node. The transport protocol can be UDP, TCP, or ICMP (note that although the latter is not a transport protocol, it is considered to be one within the uIP stack). The reduction of program code and uIP memory is obtained by three methods: (a) an event-based programming interface, (b) a simple memory buffer management scheme, and (c) efficient implementation of the TCP protocol.
Several node addresses were used in this work, taking advantage of the different protocol layers offered by Contiki: application address, uIP (network) address, and Rime (link) address. Each of the network devices, at each moment, has one unique address of each type. The protocols chosen for the implementation of each of the layers of the OSI model, as well as the specific configuration parameters of the Contiki OS, were the following:

•
Application Protocol: This is in charge of the encoding of the data generated by the sensors. It also defines alarm frames in abnormal situations; • Transport Protocol: Sensor and actuator nodes establish a UDP connection with the border router. This protocol is preferred to TCP because it is easier to implement; • Network Protocol: The uIPv6 protocol is chosen. In the Contiki OS, the network driver sicslowpan_driver was used, and the WITH_UIP6 = 1 macro was selected; The wireless network uses a mesh topology with adaptive route optimization. Extensive simulations using COOJA [17], a simulator especially designed for the Contiki OS, was used to optimize throughput.

Border Router, Local Controller, and Gateway
The border router has the ability to perform bidirectional IPv6 to Ipv4 datagram conversion in order to communicate with the WSN with the web through the gateway. The image processor gateway is responsible for receiving, managing, processing, and storing the network information resulting from communication between the coordinator, sensor and actuator nodes, and the video cameras. In addition, it also processes the commands to act on the streetlights, which are triggered by the arrival of an event.
The communication links between these elements use the following: • A SLIP interface that links the local controller with the coordinator of the wireless network (i.e., the border router). The use of this protocol allows the transmission of IP packets over a serial line in a simple way. It does not support either error control or frame fragmentation. Contiki uses SLIP to adapt the Ipv6-based wireless network to a higher capacity device, such as the communication gateway through the coordinator node. In the gateway, from the available tools, the slattach tool was used, which allows the creation of an interface to connect the coordinator node through a local network address.

•
An Ethernet interface that links the local controller with the image processor gateway. • A UART interface that links the image processor gateway with the 3G modem.

ITERL Software
In this section, the main functions and algorithms implemented in the devices comprising ITERL are described.

Event Detection by Cameras
The events to be controlled are related to the arrival of vehicles to some pre-defined areas of interest. Upon detecting these events, the system analyzes them and generates a series of responses in the streetlights.
Event detection is done using Imageprocess, an application based on the Open source Computer Vision (OpenCV) library for object detection in images. When Imageprocess is active, it takes the real time video obtained from the camera and the pre-defined areas of interest as data sources. When a vehicle enters one of the pre-defined areas of the camera, Imageprocess generates an event that is processed by other programs in the image processor, producing an action on the streetlights. This event contains the ID of the area where the incoming vehicle was detected, the ID of the detected object, the type of detected event, the vehicle direction, the vehicle speed, the size of the detected object, and the date of detection. For each camera, an independent instance of Imageprocess is run, which analyzes its assigned area.
The camera-based event detection program requires the definition of the so-called areas of interest. They are defined as eXtensible Markup Language (XML) files, which fix their boundaries by means of coordinates in the image plane; a different XML file is required for each area of interest. An Application Programming Interface (API), responsible for analyzing the events generated by image process, was created in Flask, an API microframework in Python language. The first objective of this API is to determine if the received event is relevant. Then, the application checks if it contains the expected information and if it has a valid content. In this case, the API transforms this event into a data frame, which is sent through a TCP socket to the program in charge of managing and storing the system data frames. If the expected information is not present or has invalid content, the event is discarded.
With respect to movement detection, different algorithms were programmed and tested in the laboratory using a testbench composed of sequences of images taken from academic repositories on the Internet, and from a database of images recorded by ITERL cameras in the demonstration area. This testbench includes images recorded under different conditions (day or night, with good visibility, rain, or fog. The algorithm used in ITERL is an evolution of Oriented FAST and Rotated BRIEF (ORB) [18], where the movement is detected by comparing the current photogram with the background, which in turn slowly adapts itself to follow the changes in atmospheric and ambient conditions. The algorithm was tuned in-field to reduce the number of false negatives down to zero under conditions of good visibility, at both day and night. Note that the presence of false negatives under low visibility conditions is not so important, since under these conditions, ITERL is programmed to illuminate the intersection regardless of traffic activity. Figure 6 depicts the logical architecture of the local controller. The communication manager is a server developed in C language that receives information from the wireless network through both the border router and the image processor and sends this information to the internal data processor. The server establishes a communication channel through the creation of a UDP socket. After the socket is created, it is attached to a free listening port and initiates an attention process. It continuously listens to the attached port, and when input data is detected, it starts a checkup function that processes the frame header and checks that the received data (Rx) is correct. If an error is detected in the frame header (incorrect cyclic redundancy check, frame start flag not detected, etc.) it is rejected, and the corresponding port is listened to again. If the header field is correct, then the raw frame is sent to the data processor. Figure 7a shows the flowchart of the communication manager. continuously listens to the attached port, and when input data is detected, it starts a checkup function that processes the frame header and checks that the received data (Rx) is correct. If an error is detected in the frame header (incorrect cyclic redundancy check, frame start flag not detected, etc.) it is rejected, and the corresponding port is listened to again. If the header field is correct, then the raw frame is sent to the data processor. Figure 7a shows the flowchart of the communication manager. As for the data processor in Figure 6, it is responsible for receiving the frames from the communication manager and processing the incoming information. This process follows a state machine, implemented in C++, which goes through the following phases (Figure 7b):

•
Reception of one data frame from the communication manager; • Reading of the frame identification fields: First, the API indicator (API ID) and the command type (CMD) are processed to verify that it is a reading-type frame; Then, the useful information is stored for later treatment.
• Reading of the service identification Universally Unique IDentifier (UUID) field, with a twofold objective: To verify that the service identifier belongs to a sensor measurement or an event; and In the case of an event, to take the necessary actions on the streetlights, if required.
The data processor takes different actions depending on whether the information corresponds to a temperature or humidity measurement, to a fog event (requiring the computation of the dew point), to a luminosity measurement, or to an event coming from any of the field cameras. Once a given reading frame is processed and the necessity of actuation on the streetlights is detected, the "instant set" module from Figure 6 is responsible for programming the required action. The actuation frames are sent to the border router in an orderly manner, adding a 0.1 second delay between frames. A re-sending mechanism is implemented to ensure that the actuation frames arrive at the destination.
The "web service" block in Figure 6 is an information request mechanism based on web services, implemented in the local controller for external consultation of system data (i.e., those measurements and events stored in the database). Finally, a method must be provided for time and date synchronization. This is the objective of the "stamp client" module shown in Figure 6.
continuously listens to the attached port, and when input data is detected, it starts a checkup function that processes the frame header and checks that the received data (Rx) is correct. If an error is detected in the frame header (incorrect cyclic redundancy check, frame start flag not detected, etc.) it is rejected, and the corresponding port is listened to again. If the header field is correct, then the raw frame is sent to the data processor. Figure 7a shows the flowchart of the communication manager. As for the data processor in Figure 6, it is responsible for receiving the frames from the communication manager and processing the incoming information. This process follows a state machine, implemented in C++, which goes through the following phases (Figure 7b): • Reception of one data frame from the communication manager; • Reading of the frame identification fields: o First, the API indicator (API ID) and the command type (CMD) are processed to verify that it is a reading-type frame; o Then, the useful information is stored for later treatment.

Server Database and Graphical Interface
A My Structured Query Language (MySQL)-type database was implemented in a remote server, where data coming from cameras and sensors measuring the ambient conditions are stored. This allows the user or analyst to have a historic record of the system's behavior, as well as a representation of data in a graphic interface. Figure 8 shows snapshots of the graphical interface. It allows the user to choose the measurement to display and the date of consultation (using a calendar). Measurements can be graphically displayed or printed in plain text. Additional pages are available to provide information about the state of ITERL and its components and for system configuration.
It is notable that Figure 8 illustrates the measured ambient illuminance graph for two different dates. Daylight duration can be determined so that the actuation over streetlights is performed when necessary (nighttime, sunrise, and sunset). For the dates in This allows the user or analyst to have a historic record of the system's behavior, as well as a representation of data in a graphic interface. Figure 8 shows snapshots of the graphical interface. It allows the user to choose the measurement to display and the date of consultation (using a calendar). Measurements can be graphically displayed or printed in plain text. Additional pages are available to provide information about the state of ITERL and its components and for system configuration.

Experimental Results
Experimental validation of the ITERL system was carried out using a simplified version consisting of one detection point and four actuation points. The detection points include the sensors that measure ambient conditions and the cameras that detect vehicle presence. The actuation points consist of the LED luminaires (powered by a solar panel) and the actuator node used for their control. Tables 3 and 4 show the components of the detection and actuation points, respectively, excluding power components (solar panels, regulators, and batteries).
Regarding the inventory of components in Tables 3 and 4, the energy consumption was computed and measured in the laboratory. Results are shown in Table 5 (for the detection point) and Table 6 (for each actuation point). The power consumption for the detection and lighting points was 523 and 542 Wh per day, respectively. Two parallel connected solar panels of 100 W and one 12 V, 85Ah battery were selected to supply the detection point. One solar panel of 190 W and two series-connected 12 V, 66 Ah batteries supplied the lighting points, since its power regulator requires a 24 V input voltage.    The correct functioning of the systems was first verified in the laboratory, both for hardware and software components, including the wireless communication network and the energy storage and control subsystem. With respect to the software, the tests consisted of the simulation of a series of events through the communication gateway, followed by an analysis of the system response by comparison to the expected one. Among others, the following tests were performed: • Detection, reception, and storage of measurements and events, coming from both the wireless network and the cameras; • Actuation on streetlights after the reception of an event, under different ambient conditions; • Interactions with the system through the internal web service.
Once the tests in the laboratory were completed, the correct operation of the communication manager, the data processor, and the instant set applications was guaranteed, as well as the proper use of the internal database. Only then could field tests be addressed. To this end, a prototype of ITERL was deployed at an intersection in the village of Villafranca de Córdoba, in southern Spain. Figure 9 shows an aerial view of the deployment area, and Table 7 shows the geolocated coordinates of its components. Following the nomenclature introduced in Figure 2, Figure 10a shows detection point A. Three cameras were placed near the top of a pole at a height of 11 meters, with one of them facing the CP-227 road, and the other two facing both directions of the A-421 road. The cameras covered 200 meters. At a height of 5.5 meters, the sensor node (including the sensors) was placed inside its protection cover. Slightly above the sensor node, at a height of about 6 meters, the image processor and gateway and the border router were placed inside a protective cover. The two solar panels of the detection point, connected in parallel, were placed at heights of 6 and 9 meters, respectively, with a southern orientation and an inclination angle of 40°. The battery and PWM regulator were placed inside a small tamper-proof stand built next to the base of the pole.
As for the lighting points (B, C, D, and E, respectively), four poles of about 8 meters in height were installed, with a relative separation of approximately 18 meters (Figure 10b). In every pole, a  Following the nomenclature introduced in Figure 2, Figure 10a shows detection point A. Three cameras were placed near the top of a pole at a height of 11 meters, with one of them facing the CP-227 road, and the other two facing both directions of the A-421 road. The cameras covered 200 meters. At a height of 5.5 meters, the sensor node (including the sensors) was placed inside its protection cover. Slightly above the sensor node, at a height of about 6 meters, the image processor and gateway and the border router were placed inside a protective cover. The two solar panels of the detection point, connected in parallel, were placed at heights of 6 and 9 meters, respectively, with a southern orientation and an inclination angle of 40 • . The battery and PWM regulator were placed inside a small tamper-proof stand built next to the base of the pole.
As for the lighting points (B, C, D, and E, respectively), four poles of about 8 meters in height were installed, with a relative separation of approximately 18 meters (Figure 10b). In every pole, a single LED luminaire was used, placed on top of the pole at approximately 8.5 meters high. Point B, the closest to the intersection, was 24 meters away from detection point A. Each lighting point provided enough light for a distance of 20 meters along the road. The actuator node, with its corresponding protective cover, was attached to its corresponding pole near the streetlight. One solar panel, also orientation towards the south and at an inclination angle of 40 • , was placed just on top of the pole, at a height of 9 meters. Batteries and power regulators were located inside the bases of each pole, under protective covers. Wiring passed through the interior of the pole. Implementation aspects such as the distance between detection, lighting points, and the intersection were selected according to national regulations and industry recommendations [19], under the supervision of experts from our industrial partner organizations and the administration. These values can be considered to be adequate for T-shaped intersections, such as that in Figure 9 with selected streetlights, although they should be carefully reconsidered for each new deployment.
of each pole, under protective covers. Wiring passed through the interior of the pole. Implementation aspects such as the distance between detection, lighting points, and the intersection were selected according to national regulations and industry recommendations [19], under the supervision of experts from our industrial partner organizations and the administration. These values can be considered to be adequate for T-shaped intersections, such as that in Figure 9 with selected streetlights, although they should be carefully reconsidered for each new deployment.

Discussion
The ITERL demonstrator was in operation from July 2016 to December 2018. In the first semester, it was under daily supervision from the central facilities, and a report was elaborated by a group of experts from a company in charge of the use and maintenance of traffic infrastructure. As a consequence, the lighting sequence and the intensity level of the streetlights were updated their final version, which is illustrated in Figure 11. According to the average measured illuminance, ITERL split a day into four successive intervals, namely nighttime, sunrise, sunset, and daylight, and a different lighting configuration was assigned to each one. In every interval, LEDs were illuminated at a low lighting level by default and at a high level when a vehicle was detected. Maximum and minimum lighting values were fixed at every interval, although ITERL determined the final value according to the present interval and the instantaneous ambient conditions. As a matter of illustration, by default, LEDs were not active during daylight, even when a vehicle was detected. However, during the daytime, the intersection could be lit to a high level when a vehicle was detected under low visibility conditions (i.e., fog or rain). To accomplish this selection, ITERL had a complete set of decision rules.

Discussion
The ITERL demonstrator was in operation from July 2016 to December 2018. In the first semester, it was under daily supervision from the central facilities, and a report was elaborated by a group of experts from a company in charge of the use and maintenance of traffic infrastructure. As a consequence, the lighting sequence and the intensity level of the streetlights were updated their final version, which is illustrated in Figure 11. According to the average measured illuminance, ITERL split a day into four successive intervals, namely nighttime, sunrise, sunset, and daylight, and a different lighting configuration was assigned to each one. In every interval, LEDs were illuminated at a low lighting level by default and at a high level when a vehicle was detected. Maximum and minimum lighting values were fixed at every interval, although ITERL determined the final value according to the present interval and the instantaneous ambient conditions. As a matter of illustration, by default, LEDs were not active during daylight, even when a vehicle was detected. However, during the daytime, the intersection could be lit to a high level when a vehicle was detected under low visibility conditions (i.e., fog or rain). To accomplish this selection, ITERL had a complete set of decision rules.
Some other general rules were taken into account for the sake of safety, to prevent drivers from being confused or dazzled by sudden changes in lighting:

•
A certain hysteresis in the measured illuminance was taken into account when changing from a daytime interval to another one. In addition, the date and the estimated duration of each interval were also taken into account to avoid false changes; • When a change in the lighting level of a streetlight was decided, it was done in a gradual manner, in 1 second steps of no more than 10% of maximum lighting.
Concerning energy efficiency, Table 8 shows the percentage of power reduction in ITERL with respect to a conventional lighting system, whose streetlights are fully "on" overnight (12 hours), and "off" the rest of the day. It can be seen that the energy consumed by ITERL was about 50% less in many cases, with an average reduction of 36.78%. When compared to the conventional system, ITERL also illuminated the intersection under adverse weather conditions, regardless of the time of day, which is a significant contribution to road safety. Some other general rules were taken into account for the sake of safety, to prevent drivers from being confused or dazzled by sudden changes in lighting: • A certain hysteresis in the measured illuminance was taken into account when changing from a daytime interval to another one. In addition, the date and the estimated duration of each interval were also taken into account to avoid false changes; • When a change in the lighting level of a streetlight was decided, it was done in a gradual manner, in 1 second steps of no more than 10% of maximum lighting. Concerning energy efficiency, Table 8 shows the percentage of power reduction in ITERL with respect to a conventional lighting system, whose streetlights are fully "on" overnight (12 hours), and "off" the rest of the day. It can be seen that the energy consumed by ITERL was about 50% less in many cases, with an average reduction of 36.78%. When compared to the conventional system, ITERL also illuminated the intersection under adverse weather conditions, regardless of the time of day, which is a significant contribution to road safety.
The contribution of the wireless sensor network to total power consumption was negligible, since even though a wireless node can consume up to 40 mA when transmitting or receiving data, it was in sleep mode most of the time. The highest contributors to total power consumption were the streetlights, although they were seldom illuminated at high values (90% or 100% of their maximum values) due to ITERL intelligence.  Table 8 also shows the average number of vehicle detection events (excluding the daylight interval) per day for every quarter of the year, which is an indicator of the ITERL activity during the intervals with low illuminance.  The contribution of the wireless sensor network to total power consumption was negligible, since even though a wireless node can consume up to 40 mA when transmitting or receiving data, it was in sleep mode most of the time. The highest contributors to total power consumption were the streetlights, although they were seldom illuminated at high values (90% or 100% of their maximum values) due to ITERL intelligence. Table 8 also shows the average number of vehicle detection events (excluding the daylight interval) per day for every quarter of the year, which is an indicator of the ITERL activity during the intervals with low illuminance.

Conclusions
This paper has presented ITERL, an adaptive wireless system for efficient road lighting with an emphasis on rural intersections, which have a high number of road accidents. To achieve efficient power usage, ITERL employs recent LED technology for streetlights and has a smart controller that takes into account the presence and speed of vehicles that approach an intersection as well as ambient conditions in order to illuminate the area of interest with the most appropriate light intensity, only when it is necessary. To this end, ITERL incorporates a set of sensors (illuminance, temperature, humidity, and rainfall) and video cameras (to detect the presence and speed of incoming vehicles). To reduce installation and operation costs, communication between ITERL elements (sensors, actuators, and local controller) is done wirelessly, which does not require civil work. Finally, the local controller is supervised from a central facility, as it is connected using the cellular network provided by a telecommunication carrier.
The paper provides a detailed description of ITERL operation and of its components. An ITERL prototype was deployed at a road intersection in Villafranca de Córdoba (Spain), where it was in continuous operation for more than two years. Results of ITERL operation and the measured energy savings when compared to a conventional road lighting system were also reported, showing an average power reduction of 36.78%.
These results show that a smart combination of recent advances in lighting and IoT technologies enable the development of cost-effective road lighting systems, which can make a significant contribution to the reduction of traffic accidents, which is one of the main objectives of transportation departments around the world. Funding: This research was funded by the Consejería de Fomento y Vivienda of the Andalusian Regional Government, and by the European Regional Development Fund under Grant G-GI3002/IDIO.