An Implementation of High Efficient Smart Street Light Management System for Smart City

Street light are among the most common infrastructure in cities. Street lights and sensors can be combined to generate an interface of data collection. The analysis of massive data serves as an integral element of a smart city. This paper proposes a highly efficient system for the configuration, deployment, and management of smart street lights. The features of fast deployment and high scalability of the container-based system management result in virtual deployment. Additionally, for database design, NoSQL and in-memory databases are integrated to realize flexible data management. In terms of data transmission, this paper designs an asymmetric key and an SSH encrypted tunnel. Moreover, when all the services are connected, it conducts legitimacy validation via a token. Therefore, this system can help meet the demands for data throughput, low-latency, configuration, and realization of a smart city. It boasts high efficiency and security. Besides, it offers a flexible data storage and management service to facilitate the massive data processing of a smart city. With respect to experiments, this paper designs a street lighting simulation system with edge computing devices (consisting of a micro-controller, a sensor, and an IP camera) and a street lighting function. The system collects real-time sensed environmental data, enables live streaming of images, and offers an API for historical data query. This paper utilizes container-based virtualization to deploy all edge computing devices on the server and validates the feasibility of simultaneous operation of multiple container-based services on edge computing devices. This system has high commercial value.

areas. Data on atmospheric composition and air quality are collected everywhere at any time. Such data are analyzed and reported to local environmental protection departments for effective inspection and tracking. Thus, the overall quality of urban life can be improved. Characteristics of application development and examples of smart cities in the world are summarized in [8]. Souri et al. [74] proposed a systematic analysis of communication strategies for the Internet of Things. The purpose is to enable the device to connect and respond more quickly and flexibly. In analysis, there are four main directions: device-to-device, device-to-cloud, deviceto-gateway and device-to-application. And analyze the existing papers of the Internet of Things and divide the technology into five categories including monitoring-based communications, routing-based communications, health-based communication, intrusion-based communication and resource-based communication. For resource management, Arani et al. [77] put forward a complete discussion of resource management on fog computing. Due to the limitations, heterogeneity and dynamics of resources on IoT devices, and the unpredictability of the fog environment, resource management is one of the challenging topics. Reference [77] divides the resource management methods into six categories including application placement, resource scheduling, task offloading, This paper focuses on the following three parts: real-time lighting control is realized by manual setting or scheduling; real-time information, including the status of the lighting system, sensed environmental information, streaming of realtime images of the IP camera, is provided; and an API for historical data query is provided (including video storage). The system architecture proposed by this paper is mainly made up of a management platform, edge service orchestrators, and a web-based user interface. It is highly scalable, securityand privacy-oriented, and user-friendly. Along with the rapid development of smart street lights, the management system requires ever more computing, networking, and storage resources to simultaneously handle the many requests issued by street lights. Therefore, it is necessary to build a highly scalable system featuring easy migration, rapid deployment, and high resource utilization. This paper took advantage of container-based virtual deployment technology to realize rapid deployment and high scalability. Besides, with respect to database design, it utilized NoSQL and an in-memory database to achieve flexible data management. In accordance with the latest OWASP IoT Top 10 [10], more attention has been paid to insecure ecosystem interface and insecure data transmission (i.e., without encryption or access control). A security lapse not only results in wrong applications and services, but also unexpectedly becomes an intermediary for cyberattacks. For instance, in the 2016 Dyn cyberattack [11], a series of distributed denial-of-service (DDoS) attacks took advantage of substantial IoT devices infected with the Mirai malware. [12]. In line with the General Data Protection Regulation (GDPR), privacy management must be integrated into the solution for achieving the development of smart cities in Europe [13]. Therefore, when establishing a management system, one needs to consider how to protect and validate data transmission. This paper designed an asymmetric key and an SSH encrypted tunnel for data transmission. Moreover, it conducted legitimacy validation via a token when all services were connected. The edge processing function may be deployed on edge nodes with heterogeneous functions [14]. Therefore, this paper designed a program that facilitates the user's deployment of edge nodes, which was a great challenge. Furthermore, many aspects need to be considered in designing a practical remote observation and control system, such as a user-friendly interface, real-time feedback on status, and multi-user accessibility [15]. Another challenge lies in the diversity and number of streaming video devices. Hence, an effective edge node deployment mechanism and a user-friendly interface are essential for achieving an effective management system. The rest of this paper is organized as follows. Section 2 discusses related works and introduces background concepts and technologies. Section 3 describes the entire system architecture and provides the implementation details of the cloud management platform, the edge node services, and the webbased user interface. Section 4 presents the results of the experiment and its verification. Finally, we conclude this paper. VOLUME 8, 2020

II. RELATED WORKS A. SMART STREET LIGHT
Smart street light is one of the most significant applications in a smart city. Automatic switch of street lights for this pervasive infrastructure, but also take into account the connected urban digital platform. Álvarez et al. [16] proposed a taxonomy of use cases based on sensing technologies, databases, and actuation purposes. However, the identification of new creative cases requires the combination of multiple data streams. The first challenge was to enable street lights to collect data via different types of sensors and provide such data to a public digital platform. Most efforts spent on the building of a smart street lighting management system in recent years centered on the smart switch of LED street lights. Reference [17] integrated street lighting control with the current SmartGrid products of Portugal. In the technical abstraction layer, the lighting communication table was used to reduce the changes in circuit via a Web-based central management system. Daely et al. [18] put forward an architecture consisting of ZigBee-based wireless communication, a turnable correlated color temperature (CCT)-based LED array, and a central web server. This server can receive weather information and real-time sensed data from each lamp pole. In addition, this system switches the CCT to 5,000K or 3,000K based on the weather conditions from the weather API. In case of a traffic accident caused by low visibility due to fog, the system will recommend the use of a weak CCT light to reduce the possibility of such situation. Jia et al. [19] proposed a management platform based on a fog computing server with improved real-time response. Street lights periodically send their status to the server through NB-IoT network technology. However, the system could not guarantee 100% reliability. Its simulation results demonstrated that the average periodic maintenance time and the abnormal state of the server was approximately 20 minutes. Escrivá et al. [20] put forward a prototype architecture based on IoT devices and cloud computing. The modules included: a dedicated wireless lighting controller, one IoT sensor gateway set installed on LED lights, a smart collector, and a central management system. Through Apache Kafka, Apache Flink, and MongoDB, the smart collector analyzed and stored the data collected from the sensors. The smart central management system provides a Web interface that uses the real-time REST Web service and the IoT gateway to control and monitor street lights, including the status and location of lights. The difference between this paper and the existing researches lies in the fact that the former attaches more importance to scalable cloud and edge deployment, security against cyberattacks, and userfriendly Web-based interface.

B. VIRTUALIZATION TECHNOLOGY-CONTAINERS AND VIRTUAL MACHINES
Virtualization simplifies the replication and scaling of applications [21]. There are two main virtualization technologies: hardware-level virtualization and operating system-level virtualization. The container, using operating system-level virtualization, executes processes in the operating system. It uses namespace [21] to handle the resource isolation of each process (e.g. process ID, network interface, and mount point) and manage CGroups [23]. A virtual machine (VM) is independent of the operating system; it simulates VM management processes (e.g. VMware ESXi [24] and KVM [25]) on virtual hardware (e.g. CPU, memory, and network devices). Containers and virtual machines are compared in terms of architecture in Figure 1.
Docker [26] introduced an advanced API. It used a lib container-based [27] solution to create a container with Linux kernel virtualization. Its first version was released as an open source in March 2013. Since then, many applications have been shifted from VMs to containers. According to Docker's blog [28] in March 2018, 3.5 million Dockerized applications and 37 billion containers have been downloaded. The main differences between Docker and VM are shown in Table 1. Previous studies [21], [29], [30] explored the relationship between containers and VMs. Sharma et al. [21] compared the performance of intensive workload between KVM and LXC [31] (another OS-level virtualization relying on the Linux kernel). Their results displayed that the performance overhead of KVM is negligible in CPU, memory, and network-intensive workload, but high in I/O-intensive applications because I/O is based on the hypervisor. Additionally, an interesting architecture different from a VM was considered; it enables the nesting of a container on a VM for the isolation of applications. Similar to a VM, it restricts soft container resources to slightly improve performance. Zhang et al. [29] compared the convenience of deployment, initiation efficiency, and the performance of Spark jobs (e.g. execution of Kmeans, logistic regression, page ranking, and SQL Join) between Docker container clusters and VM clusters. Their measurements showed that containers are more convenient in deployment and initiation. Containers have better scalability among different and multiple workflows and higher resource utilization in one workflow in the big data environment. Maheshwari et al. [30] deemed that the time, CPU, network, and disk I/O resource utilization of the Docker container required for start and stop are lower than those of Oracle VirtualBox [32]. However, they held that compared with containers, VMs enable greater isolation and provide better support for real-time migration.
Recent studies [14], [33]- [38] reveal the growing trend of Docker services in the IoT environment; they probed into the balance between flexibility and performance overhead. Bellavista and Zanni [33] containerized the IoT framework of open source codes and deployed the containers as fog gateways on the resource-constrained node (i.e., Raspberry Pi (RPi)). The application runtime and execution of multiple containers on a resource-constrained device indicated good scalability. The overhead derived from container-based virtualization in the experiments of [34] and [37] could be ignored, reflecting advantages in resource consumption, service activation time, and energy efficiency. Meanwhile, container-based virtualization features prominent manageability and scalability. Reference [36] applied the concept of container migration to the edge cloud architecture in the checkpoints stored and managed by Docker, and handled realtime internal and external container migration. The energy consumption at the edge of network was minimized via the cooperative game theory and Docker. Badiger et al. [38] proposed VIoLET, a virtual environment for defining and launching large-scale IoT deployment in cloud VMs. Containers were deployed in cloud VMs to simulate the computing resources matching the performance of native edge, fog, and cloud devices. Cao et al. [14] realized collaborative video processing. Various video processing functions were run on different edge nodes on a container-based edge computing platform. Their study implied that when the network link capacity is sufficient, collaborative processing is superior to baseline in terms of the total time for video processing. References [33] and [14], [37], [38] utilized Docker Swarm [39] which is a lightweight solution compared to Kubernetes [40] natively integrated with Docker; it can simplify the deployment and management of multiple containers and run across multiple physical or virtual hosts. In regard to security, [41] and [42] indicated that Docker provides an extremely secure container-based application development platform. They suggested running it for non-privileged users (i.e., non-root users) and initiating other enhanced solutions in the Linux kernel, such as AppArmor and SELinux. Therefore, this paper takes advantage of container-based virtual deployment technology to realize fast deployment and high scalability.

III. THE PROPOSED SYSTEM ARCHITECTURE A. SYSTEM ARCHITECTURE
The proposed system architecture contains three main parts: the cloud server, edge orchestrators, and user applications. The whole system architecture is shown in Figure 2. Six modules were designed for the cloud management platform running on the cloud server: account management module, device management module, secure transmission module, edge service handling module, historical data query module, and video streaming module. For the edge, multiple devices are installed on the light pole, including one single-board computer, one IP camera, and one Arduino where multiple sensors are embedded. Three modules run on the single-board computer at the edge: secure transmission module, edge service handling module (communicating VOLUME 8, 2020  with Arduino), and video streaming module (pulling/pushing video streams from the IP camera). The necessity of the edge manager depends on the swarm management of multiple street lights.
The Docker CE engine is installed on the cloud server [43]. This engine creates and controls containerized Docker applications. The cloud management platform consists of seven Docker containers, as shown in Figure 3. Each container is connected to a software bridge network for communication among containers. Containers not connected to a bridge network are isolated from the rest of the containers.  containers via simple commands. It is used to create images and containers, mount all volumes, wire up the network, and expose ports to docker-compose.yml to define the format of    YAML [45]. In this paper, we adopted Version 3 of the file format of Compose to write the bridge network for each container. We specified to ''always'' restart each container and restart Docker daemon unlimited times to ensure that these containers always ran regardless of the reason of exit. All seven containers were created based on minimal image and Alpine Linux [46], a security-oriented lightweight version of Linux, as shown in Table 2. The total size of the seven images     is less than 1 GB. As shown in Figure 4, for all Web-based requests, we used Django [47] to realize the web server. The requests fall into two categories: HTTP/2 [48] and WebSocket [49]. Two standard interfaces were used for the collocation of Django applications and to allocate two types of incoming requests: WSGI [50] and [51], respectively. In the web  container, we used Supervisor [52] as a process control tool to monitor and automatically start the following processes:

2) DETAILS OF CLOUD CONTAINERS
• Gunicorn [53]: WSGI server. We used the asynchronous work procedure based on gevent [54]. Asynchronous IO was used to handle I/O binding requests with higher synchronization.
• Daphne [55]: A WebSocket protocol server for ASGI. In addition, among the following containers: Nginx, Nginx-RTMP, Web, and SSHD, we adopted crond built in Alpine Linux for time synchronization and logrotating [56] jobs. It is used to manage log files (e.g. Nginx access log or Supervisord log).

3) CLOUD SERVER NETWORK TOPOLOGY
The network topology of the cloud server is shown in Figure 5. Each container has its own namespace. A namespace is regarded as an isolated network stack in the kernel with its own network interface and routing and firewall rules. There is also a Linux bridge (realized by the virtual switch inside the Linux kernel). It has multiple virtual Ethernet interfaces linked to the interfaces in each container; therefore, containers communicate with each other through the ARP protocol of the Layer 2 bridge. Moreover, containers on the network bridges defined by the same user can resolve the name of the other container into an IP address through the embedded DNS server of the Docker engine and DNS lookup.     Docker daemon attaches rules to the iptables [57] of the host in order to filter a data package in Layer 3 and enable specific connection of containers, such as traffic forwarding and host port mapping.

4) ACCOUNT MANAGEMENT MODULE
This module takes charge of user registration, modification of user information, and user login. Table 3 shows that this module is stored in MongoDB [58] (a JSON-like document oriented NoSQL database). This container records both user information and the permission of each user account.    The permission of each type of user in the management platform is listed in Table 4. The simple user registration process and the user interface for user registration are introduced in Figures 6 and 7. As shown in Figure 8, the user login process includes login failure (the maximum failed VOLUME 8, 2020   login attempts every five minutes is set to five times), password resetting, and account information. We stored two keyvalue pairs in the database container in Redis (an open source, in-memory data structure store used as a database or cache) in the management platform, as shown in Table 5, to   accelerate each request that needs to be transmitted after the permission check.

5) DEVICE MANAGEMENT MODULE
This module manages the configuration, public keys, and device tokens. Table 6 describes the configuration and location of each device, secure transmission parameters, and lighting control schedules. Table 7 lists the device configuration for real-time data transmission and authentication stored in the Redis database container. The CRUD (i.e., Create, Read, Update, and Delete) of device configuration   management is described in Figure 9. Figure 10 shows that only the device owner can modify the device configuration. Figure 11 shows incorrect input, incorrect permissions, and incorrect pages requesting resetting.

6) SECURE TRANSMISSION MODULE
This paper applied two communication protocols to the edge node: RTMP and WebSocket. For the communication between Edge and Cloud, we set up an encrypted SSH tunnel to forward local ports to remote ports and monitor the Docker bridge network inside the cloud server. As shown in Figure 12, the edge node binds ports 65000 and 65001 on localhost to the remote addresses of nginxrtmp: 1935 and web: 8001, respectively.
For Web browser to Cloud, this paper applied two communication protocols to the browser: HTTP/2 [48] and    WebSocket. We adopted HTTPS [69] with a 4096-bit RSA certificate to encrypt the communication between the browser and the cloud. Figure 13 demonstrates the authentication workflow requested by HTTP/2. The user login workflow before the management platform is entered is as follows:   • 4. The Web container adds session information to the Redis cache and returns the session key to the browser. The authentication workflow requested for WebSocket of the browser is shown in Figure 14: The browser sends the WebSocket request with a session key to the Nginx container via TLS encryption.
• 2. The Nginx container uses the HTTP/2 proxy and forwards the request to the Web container.
• 3. The Web container uses the session key stored in the Redis cache to check the session information. After successful authentication, the session key stored in the Redis cache will be used for session check.

7) HTTP CERTIFICATE RENEWAL
HTTPS is the key to communication security between the browser and the cloud. HTTPS requires a digital certificate that allows the browser to verify the identity of the web server. Let's Encrypt [60] is a free, automatic, and open certificate authority, sponsored by the Electronic Frontier Foundation (EFF), Mozilla, and other organizations. We used Certbot [61] to obtain the HTTPS certificate and   ensure the validity of the certificate. Certbot is the fullfeatured and scalable client side of CA. Let's Encrypt CA was used. The domain name of the cloud server was configured and provided by NOC of NCKUEE [62]. Figure 15 shows the workflow of the script that checks whether the HTTPS certificate expires, when the Certbot container is started.

8) VIDEO STREAMING MODULE
In order to provide real-time video streams, this module uses the nginx rtmp module [63] to receive the RTMP [64] stream issued by the edge node and utilizes FFmpeg [65] to transcode it into HLS [66]. We regard Nginx and Nginx-RTMP as two separate containers to make it easy to add more computing resources in the future to raise the scalability of the system. The Nginx-RTMP container has the following functions: • It monitors Port 1935 (internal) to receive the RTMP stream with token inspection.
• It generates the HLS file.
-HLS playlist (.m3u8) -Encrypted media segment (.ts) -AES encryption key (.key) • It records the RTMP stream and converts it to MP4 via FFmpeg. information. The maximum length of historical videos is 15 minutes.
• It monitors Port 80 (internal) to receive the control messages requested by the Web container in order to disconnect the RTMP client side later.
-The token of the device has been reset.
-The device has been removed. The Nginx container safely provides all video files to the browser through HTTPS encryption. This container and the Nginx-RTMP container share volumes with each other. As the HLS media segment is encrypted, only a request by HLS encryption key for historical videos requires session check for authentication by Nginx. The workflow of requesting a video file is shown in Figure 16. The HLS playlist and request of an unauthenticated HLS encryption key are shown in Figure 17. Figure 18 demonstrates that the realtime video streams on our management platform are running across platforms, including Android, iOS, and Windows.

9) EDGE SERVICE HANDLING MODULE
This module provides edge services, including: • It receives information from the edge and broadcasts it to the browser (real-time). • It receives commands sent from the browser to the specific edge (real-time).
• It controls LED lights based on two schedules: (1) Manual control, (2) Automatic control in accordance with the value displayed on the Passive Infrared Sensor (PIR). Figure 19 shows the workflow of this module when WebSocket is connected. Figure 20 displays the workflow when multiple commands are used to process the WebSocket request, including updating Edge information, turning on/off LED lights or the PIR, and configuring the PIR timeout value. All data frames in WebSocket are encoded as JSON (a data structure standard in Web applications). Figure 21 shows the workflow of this module during the disconnection of WebSocket.
The built-in crond service is used in the cloud server. According to the two schedules stored in MongoDB, each device will have its own cron job. In this way, the user can control street lights more easily. Figure 22 describes the process of a cron job. Figure 23 shows the user interface of schedules based on jQuery Schedule [67] and Ajax [68].

10) HISTORICAL DATA QUERY MODULE
This module enables the query of historical data in different methods, including: • Query via a Web-based user interface (session check). • Query via the Open Data API (token check). Table 8 describes each historical file stored in the Mon-goDB container and records the values of all sensors and the Led status of the edge nodes. Besides the above keys in the historical information set, the two keys of devices in the current information are stored in the Redis database. For the query request via a logged-in session in the Web user interface, the server will simultaneously return the historical information and video of the device, as shown in Figures 24  and 25. In contrast, For the query request via a user token and the Open Data API, the server will only return the historical information of the device, as shown in Figure 26.

C. EDGE SERVICE ORCHESTRATORS
We deployed each edge service on the edge node as a Docker container, as shown in Figure 27. The image information of each edge container is shown in Table 9, including base image, Docker file content, image tag, and size of images on  different platforms. We adopted Docker Compose to deploy three edge services in a single node, according to the compose file. The file defines the configuration for building images, creating containers, mounting volumes, wiring up network, as well as the configuration of environment variables. It is defined in .env and star-single.env, as shown in Figure 28.

D. DEPLOYMENT OF CLUSTER NODES
We provided a tool to deploy edge services on many edge nodes, according to Docker Swarm, Docker Compose, Buildx [70], and DockerHub. Figure 29 demonstrates a swarm cluster system structure consisting of one manager node and four worker (edge) nodes. Figure 30 shows the deployment profile of each edge node designed by this paper. Furthermore, the user can utilize the Docker swarm visualizer [71] to monitor and visualize the container status in the swarm. Figure 31 displays an example of a visualization service. This service is deployed on the swarm manager node.

A. ENVIRONMENT
Tables 10 and 11 display the specifications of the cloud server and devices on edge nodes used in this paper. Figure 32 shows the relevant devices that we used to simulate light VOLUME 8, 2020  street scenarios, including: the IP camera, the Arduino micro-controller, and sensors for PM2.5, ambient sound, temperature and humidity, intensity of illumination, ultraviolet, and motion sensing.

B. FUNCTION VERIFICATION
This paper proposes the following system design objectives: • High scalability. • Security and privacy orientation. • User-friendly interface. Indeed, this platform has high scalability. The cloud server consists of seven Docker containers that are able to be deployed on multiple physical machines at the swarm cluster with the built-in multi-host networking. In light of the results shown in Figure 33, the scalability of deployment is met. The backup and restoration of cloud Docker containers on a single host are explained. As expected, it took approximately 20 seconds and 34 seconds to start and stop the system, respectively. It only took nearly 500MB to back up cloud projects, including source codes, static files, database volumes, and seven Docker images. From the perspective of the edge, this paper proposed and described two (containerbased) deployment methods in Section 3. The security and privacy of the platform are satisfactory. Three TCP ports were exposed in the cloud server and forwarded from the Internet to the internal Docker bridge network via iptables. The three TCP ports are 80 (for HTTPS certificate renewal), 443 (for HTTPS requests), and 62422 (for SSH tunnels). Table 12 describes the security method for each connection type. The configuration of the HTTPS certificate was verified by SSL Labs [72]. The test results are shown in Figure 34.

C. PERFORMANCE EVALUATION 1) PERFORMANCE OF THE CLOUD SERVER
The following experiments were carried out in this paper, as shown in Figure 35. Many edge services were deployed on two VMs (i.e., VM0 and VM1). Ten real clients were browsing the page of real-time device status. Many edge services were deployed on embedded devices. The input to FFmpeg and Edge containers running on edge nodes are described below: • FFmpeg: The RTSP stream from the IP camera proxy (maximum connections = 10).
• Edge: Random value (simulation of the information collected by Arduino). According to the experimental results shown in Figure 36, 80 edge nodes were deployed at 21:05. From 21:19 to 21:24, 10 client pages were browsed. Table 13 shows the average  use of CPU and RAM of each cloud container in the client side serving different numbers of edge nodes and browsers (measured based on docker statistics).

2) PERFORMANCE OF EDGE NODES
Experimental scenarios are shown in Figure 37. Figure 38 shows the edge services deployed on TX2 based on the time in Table 14. Figure 39 displays the deployment of edge services on RPi according to the time in Table 15.
The reason why we did not deploy more containers on RPi was that, after 20 FFmpeg and 20 Edge containers were deployed, RPi would crash randomly. As expected, in terms of CPU usage and time for container deployment, Nvidia Jetson TX2 is better than RPi.

V. CONCLUSIONS AND FUTURE STUDIES
This paper proposes a street lighting management system consisting of one Web-based cloud management platform, one set of edge devices (a single-board computer, a microcontroller, sensors, and an IP camera), and the real-time lighting control function. The system can provide street pole information to the user in real-time and three major functions, including the historical data query API, which has been verified and discussed in detail. We put forward a novel architecture differing from that of the existing street lighting management systems. The architecture integrates the container-based virtualization technology, Docker, to provide a strong and highly scalable solution to the deployment of the cloud and edge services. Furthermore, our design protects the communication between the edge and the cloud, including token authentication and SSH-based encryption (with public key authentication). In general, the proposed system is modular, scalable, easy to deploy, and security-oriented. Therefore, this system has a high commercial value.
It is suggested that future studies explore the development of some smart applications and integrate them into our system. For instance, the machine learning algorithm can be applied to the development of a smart lighting control mechanism based on the environment data provided by the sensors. Besides, the neural network can be integrated into edge devices through the IoT edge devices installed on light poles to execute low-latency AI applications, such as real-time target detection (e.g. pedestrian or vehicle detection). As a result, the application value of this system architecture will be raised.