Credit: Getty Images
Street lamps constitute the densest electrically operated public infrastructure in urban areas. Their changeover to energy-friendly LED light quickly amortizes and is increasingly leveraged for smart city projects, where LED street lamps double, for example, as wireless networking or sensor infrastructure. We make the case for a new paradigm called SLaaP—street lamps as a platform. SLaaP denotes a considerably more dramatic changeover, turning urban light poles into a versatile computational infrastructure. SLaaP is proposed as an open, enabling platform, fostering innovative citywide services for the full range of stakeholders and end users—seamlessly extending from everyday use to emergency response. In this article, we first describe the role and potential of street lamps and introduce one novel base service as a running example. We then discuss citywide infrastructure design and operation, followed by addressing the major layers of a SLaaP infrastructure: hardware, distributed software platform, base services, value-added services and applications for users and 'things.' Finally, we discuss the crucial roles and participation of major stakeholders: citizens, city, government, and economy.
Recent years have seen the emergence of smart street lamps, with very different meanings of 'smart'—sometimes related to the original purpose as with usage-dependent lighting, but mostly as add-on capabilities like urban sensing, monitoring, digital signage, WiFi access, or e-vehicle charging.a Research about their use in settings for edge computing14 or car-to-infrastructure communication (for example, traffic control, hazard warnings, or autonomous driving)6 hints at their great potential as computing resources. The future holds even more use cases: for example, after a first wave of 5G mobile network rollouts from 2020 onward, a second wave shall apply mm-wave frequencies for which densely deployed light poles can be appropriate 'cell towers.'
Street lamps: A (potential) true infrastructure. Given the huge potential of street lamps evident already today and given the broad spectrum of use cases, a city's street lamps may obviously constitute a veritable infrastructure. However, cities today do not consider street lamps—beyond the lighting function—as an infrastructure in the strict sense. Like road, water, energy, or telecommunication, infrastructures constitute a sovereign duty: provision and appropriate public access must be regulated, design and operation must balance stakeholder interests, careful planning has to take into account present and future use cases and demands, maintenance, threat protection, and more. Well-considered outsourcing or privatization may be aligned with these public interests.
The LED dividend: A unique opportunity. The widespread lack of such considerations in cities is even more dramatic since a once-in-history opportunity opens up with the changeover to energy efficient LED lighting, expected to save large cities millions in terms of energy cost, as we will discuss, called 'LED dividend' in the following. Given their notoriously tight budgets, cities urgently need to dedicate these savings if they want to 'own' and control an infrastructure, which, once built, can foster innovation and assure royalties and new business as sources of city and citizen prosperity.
Computing platform and extensible hardware: The indispensable core. It is common knowledge that in the current era of digitization, computers are at the core of most innovation and added value. Large consortia and initiatives like OpenFog and MEC (mobile edge computing)30 arose around the conviction that 'the cloud' will, at least in part, move closer to the user and to the applications. Reasons include the increasing need for real-time (short delay, reliably connected) computing and resource-demanding AI algorithms that overstrain mobile devices' batteries or compute power but are too bandwidth-demanding to be offloaded to a distant cloud. Many services and applications discussed in the article, such as our running example, support these arguments.
It seems obvious that computing and storage resources should be the core of a true smart street lamp infrastructure, at least in part directly integrated with the lamp posts. A second absolutely crucial characteristic of such a true infrastructure is obviously the versatility and extensibility of lamp posts. They must be prepared for exchange and extension with respect to electricity, mounting space (partly with line-of-sight to the urban scene), weather/vandalism protection, and ease of (dis-)mounting, among others. These characteristics are not automatically a primary interest of street lamp customers and providers as they cannot be easily matched with aesthetics and competitive pricing.
Our call stands in stark contrast to reality, namely mostly project-based extension of street lamps. Such projects follow opportunities, perceived pressing needs, or selective flagship efforts. Moreover, the LED dividend is often spent in a short-sighted manner. Most city councils ignore reasons to become edge-computing providers; just as many cities took too long to realize the need to become WiFi providers, they may 'wake up' too late here, this time losing a historic opportunity to be in the driver's seat of a novel true infrastructure and its potentials (for innovation, citizen wealth, or city income) as well as its risks (to privacy, dependability, and so on). This may also erect a classical innovation barrier where application providers wait for infrastructures (and hence, a customer base) and infrastructure providers wait for application demands.26
To summarize these arguments, we proposed a citywide true infrastructure based on augmented street lamps as a platform (termed SLaaP) that can bootstrap smart cities and enrich them with novel services, ensure stakeholder tradeoffs (such as data analytics and novel services versus privacy risks) and extend seamlessly to sovereign interests such as emergency preparedness and response, safety, and security. Figure 1 presents an overview of this new infrastructure and the remaining structure of this article. Authorities must define and assume their sovereign role and ensure the dedication of the LED dividend to this historic duty. Versatile extensible hardware and integrated compute infrastructure and base services must form the base of this effort.
Figure 1. An overview of the proposed citywide infrastructure based on augmented street lamps, its potential end-users/'things' and the stakeholders, as well as the remaining structure of this article (gray circles).
Unique characteristics and opportunity. Street lamps are a basic and important facility of cities, illuminating roads and sidewalks in order to increase the safety of road users and pedestrians' sense of security. This leads to three characteristics that make them highly attractive from an ICT perspective and for smart city concepts.
These three characteristics qualify street lamps as the scalable vehicle for a novel urban digital infrastructure—SLaaP. As discussed, such an infrastructure has extensible lamp post hardware and a general-purpose computing platform (a distributed edge cloud) as its basic constituents (as illustrated in Figure 2). However, the success of this infrastructure comes from enablements and services, such that the selection of provided hardware add-ons and base services as well as a proper bootstrapping of them will be crucial—and hence the key aspects of this article.
Figure 2. Our visionary view of augmented street lamps (top); acting as a citywide infrastructure in future smart cities for its new kinds of applications and end-users/'things' (bottom).
Running example: 4D-service for urban scene modeling. Since many arguments and sample calculations can be backed by relating them to one of the SLaaP base services we will discuss later, we focus on a particular one here called 4D-service. This service is particularly demanding and innovative, thus serving as a challenge for other SLaaP components and aspects. It can drive innovation in virtually every application domain of smart cities. It is related to the fact that augmented and virtual reality (AR/VR) are so eagerly pursued in industry that press tends to speak of a race between major companies.b In contrast to this race for 3D models and corresponding AR/VR apps in many domains, the smart city domain is still one where software is for the most part bound to 2D maps: navigation and routes, location information (with respect to businesses, or friends, among others), situational awareness, city planning, and operations software, and so on. The 4D-service shall enable smart cities to move from 2D map-based apps to 3D AR/VR based ones.
To this end, street lamps equipped with 3D capturing hardware (LiDAR and/or cameras) shall provide a constant stream of visual "city situation" information, distinguishing the immobile city scenery (buildings, roads, or trees) from mobile elements (pedestrians or vehicles). The captured scenes are automatically processed, populating a semantic-annotated 3D model of the city. Since time-series of 3D models are captured, a fourth dimension comes into play (hence the term 4D). For public and standard app use, the mobile elements are replaced by semantically equivalent models, such that individual persons, cars, etc. cannot be detected. Access to privacy-sensitive information is tightly controlled, especially to the encrypted true representation of mobile entities stored at the edge and kept for a determined time span (rolling overwrite). The resulting 4D model enables or supports various urban use cases over multiple timescales (see Figure 2), for example:
The following section discusses the layers of SLaaP from the bottom to top, preceded by a consideration of the overall design and operation. We will elaborate on new (interdisciplinary) research opportunities linked to the opportunities and challenges of SLaaP as a true citywide digital infrastructure.
A citywide infrastructure requires geo-spatial planning and operation; in particular, coverage of components (computing resources, scene capturing hardware, and others) must tradeoff economics with technical and application necessities (for example, sufficient density for meshing or coverage of hotspots interesting for 4D-modeling) sporadic addition of lamp posts may be needed.
In order to provide insights into this issue, we conducted a case study in Darmstadtc—a typical mid-size city (some 160,000 inhabitants) in Germany. Figure 3 shows the real-world geographic distribution of the 14,331 publicly owned street lamps (yellow dots) in Darmstadt. We see the distribution of public street lamps is particularly dense along streets and sidewalks in public or populated areas (for example, downtown, parks, and residential areas) sparse in industrial or privately owned areas, where property owners are responsible for the lighting. This distribution reflects a representative street lamp deployment pattern in urban environments; cities only vary in the regulated distance between two neighboring street lamps. In our Darmstadt example, the distance is about 25.2 ± 9.2m and normally distributed (see Figure 4). These short distances between neighboring street lamps allow the interconnecting of them via high-bandwidth wired (for example, optical fiber, Powerline) or wireless technologies (for example, WiFi, mmWave) to mesh networks across the city (as shown in Figure 3), addressing scalability. A street lamp of the citywide mesh network can further act as a nearby access point of urban services to address accessibility. For instance, assuming a realistic outdoor wireless range of 50m and if only 30% (70%) of all 5,608 street lamps in the inner city (14.57km2) are upgraded, that is, 1,682 (3,926) street lamps or 115.4/km2 (269.5/km2), nearly half (two thirds) of the inner city can already be covered spatially,11 where (mobile) endusers can access services with low latency and high bandwidth (see Figure 4). This case study gives an impression of SLaaP's potential as a decentralized, stationary, and predictable infrastructure for urban services.
Figure 3. Geographic density of public street lamps in urban areas (left) and resulting wireless mesh networks (d = 50m) of interconnected inner-city street lamps (right), presented by the example of Darmstadt (Germany).
Figure 4. Case study in the city of Darmstadt (Germany): distance distribution of public street lamps to their nearest neighbor (left), and spatial coverage of augmented street lamps as function of wireless ranges (right).
To realize the infrastructure envisioned here, conventional lamp posts first must be upgraded or replaced by augmented street lamps (termed ASL), pursuing a modular and exchangeable design that is appropriate to the desired services. For instance, the proposed 4D-service requires sensors (for example, depth cameras) that need a free field of view on the traffic from the top; such components should either be attached within a kind of crow's nest to the pole or integrated into it with inspection windows. It is important to understand that not all of the following elaborated (exemplary) components must be part of each lamp post but can be strategically distributed across the city to well-selected lamp posts, depending on the service demands and budget:
Sensors and actuators. Today's lighting industry starts equipping street lamps with first sensors and actuators, for example, for a smart lighting control.10 Recently, an EU-wide research initiative has proposed The Humble Lamppost project that aims to deploy 10 million 'smart' lamp posts across EU cities, addressing first use cases, such as traffic monitoring or environmental data acquisition.20 Besides the currently considered sensors (for example, air quality, noise, and temperature) and actuators (for example, displays or speakers), new promising hardware components should be investigated to enable innovative applications. The proposed 4D-service, for instance, requires economic, compact depth cameras like range-extended Intel RealSense ($200) or 360° Velodyne Puck Lite LiDAR ($3k)—collecting point clouds up to 20Hz—to capture the dynamic 3D urban scene over time. Since the latter only has 16 slices at ±15° vertical FoV, challenges must be solved to get a complete scene model: for example, using a continuously rotating/tilting mount, or fusing point clouds from well-aligned LiDAR systems of neighboring street lamps. Next-generation short-throw or laser based projectors may serve as actuators, providing situation-aware, personalized information to citizens (for example, in evacuation situations).
Computing and storage. The emergence of latency-critical use cases like AR or autonomous driving and resource-intensive services like the proposed 4D-service requires nearby computational resources (fog/edge computing, edge-Clouds, cloudlets23,26). Integrating computing power into street lamps is a completely undervalued aspect: street lamps with their unique characteristics can actually enable an economic large-scale deployment of cloudlets (despite their range restrictions), making the break-through of practicable edge computing at long last.
We propose upgrading street lamps should start with single-board computers (SBC)—having a fair trade-off between good performance, low energy consumption, compact size, and low prize.15 For instance, low-energy ARM-based Raspberry PI ($40) or Odroid ($60) would be fine for a minimalist setup to basically analyze sensor data or reduce network traffic. Applying advanced machine learning (ML) or computer vision-based algorithms, as required for the privacy-preserving modeling or semantic scene analysis of the 4D-service,24 performant but economic hardware like 64-bit x86 quad-core Udoo Ultra ($300) or Udoo Bolt with GPU support ($600) is required for real-time capabilities. It is further important that the processors used support trusted computing features (for example, ARM TrustZone, Intel SGX3) to protect the provider's intellectual property—that is, their ML algorithms/models—on (untrustworthy) devices.
Caching and storage integrated into street lamps can further enable novel research concepts,9 reducing redundant or unnecessary network traffic, and thus, preventing traffic (over)load in the core network. Related to the 4D-service example, privacy-critical scene elements should not be transferred (for example, to the cloud) but stored locally in encrypted form to protect privacy; for crime or accident investigations, access to the full imagery of the scene may be granted but restricted to law enforcement agencies.
Networking and communication. Connectivity to the Internet, end-user/things, or other street lamps is an essential ability of the SLaaP concept; however, to this day, the possible advantages of this decentralized infrastructure are not nearly exploited as they could be (see Figure 3). One reason could be that there is no economic one-size-fits-all solution to act as high-performance backhaul technologies for decentralized street lamp networks. For latency-critical applications, either fiber or 5G connectivity would be a viable option, but at a high cost.27 Also, a subset of street lamps could be connected to a fiber network and act as gateway nodes for the street lamp network. The fiber connected lamps can wirelessly relay traffic to other lamps in proximity by either WiFi or mmWave communications (street lamps are typically in line of sight with each other; as illustrated in Figure 4). Depending on the technologies used (and their inherited wireless range), strategic placement on street lamps is crucial; combined with mobile base stations, a nearly citywide spatial coverage can be reached, and many street lamps can be left out—a more detailed coverage analysis is given in Gedeon et al.11 Depending on the depth of relaying, support of low-latency applications might be limited. Since mmWave offers multi-G throughput,32 bandwidth should not be an issue. In a second wave (after the first wave of 5G mobile network rollouts from 2020 onward), densely deployed street lamps can be appropriate cell towers for applying such mm-wave frequencies. A WiFi-mesh could act as backhaul technology between street lamps for various best-effort services; this would not allow offering hundreds of M to/from individual lamp posts. However, such a decentralized mesh network would allow vital emergency communications, avoiding dysfunctions and supporting the ICT resilience of smart cities.
Energy and space management. An ASL can play three different roles—consumer, producer and retailer—at the same time. As a consumer, street lamps need power to primarily operate their lighting but also the aforementioned ICT components. For this, an ASL relies on a balanced combination of power from the subterranean power grid, as noted earlier, integrated backup batteries (UPS), and energy harvesting (for example, solar) acting as a producer. The latter two are optional but can transform an ASL into a largely energy self-sufficient infrastructure when the regular power source fails, say, in emergency situations like blackouts—supporting the ICT resilience of digital cities by avoiding dysfunctions and providing critical emergency services (for example, decentralized emergency communication) in an accelerated way. Although the harvested energy can be sufficient to cover the ASL's power consumption under best conditions, the harvesting level varies widely and is not reliable; therefore, an ASL must manage the available energy and balance the load by limiting non-critical ICT functionalities or dimming the light situation-consciously. As a retailer, an ASL can provide charging points for electric vehicles (cars or drones) requiring permanent current from the fixed power grid. In UAV research, in particular, challenges such as 'endless' flying can now be practically addressed, for example, by recharging or automatically replacing the battery8 at the designed parking place on top of ASLs. (For more details, see the accompanying sidebar.)
To exploit the full potential of this decentralized infrastructure of interconnected ASLs, distributed concepts/methods need to be applied and refined to its characteristics. We recommend using a two-layered software platform—consisting of the local layers and a distributed system layer (see Figure 1).
Local layer. This layer running on a single street lamp should consist of three sublayers: A modular hardware abstraction layer—to communicate with the various lower level components while preventing direct access to the hardware; an appropriate operating system (OS)—to manage the underlying hardware resources, enable controlled software executions (for example, permission model, process isolation, low-level power management), and support container-based virtualization, such as, HypriotOS or balenaOS for low-energy ARM-based SBCs like Raspberry PI or Odroid, Alpine or CoreOS for x86-SBCs like Udoo; and, a local service layer—providing software-defined basic cloud-let functionalities, storage, energy, and user/things management locally. Depending on the given real-time requirements (for example, in the order of 0.01s for supporting autonomous driving), optimizing these sublayers by an accelerated computing pipeline is crucial for specific urban services.
Distributed system layer. This layer runs as an overlay over the street lamps' local layers and the interconnecting mesh networks, being responsible for the routing, distributed processing, and storage. We envision a distributed OS at the edge (termed edgeOS), supporting both vertical and horizontal balancing in the given 3n-tier architecture.d Vertically, communication issues (such as latency, network traffic, bandwidth) should be primarily addressed, while horizontally computing issues (for example, distributed in-network processing) play a primary role. Although latest research,26 large consortia and initiatives like OpenFog and MEC30 have already investigated and standardized partial aspects for each direction, important challenges are still open for making the breakthrough. Particularly, we recommend focusing on three neglected aspects: The intelligent, economic interplay between both directions to incorporate the resources from all three tiers; result delivery in high-dynamic environments, for example, through mobility predictions; and the methods to efficiently distribute AI algorithms in the 3n-tier architecture.
Due to the strict responsiveness requirements and high mobility of end users, these aspects are difficult to achieve with traditional ways of developing an application as a single monolith. We propose to base this layer on two concepts namely microservices2 and serverless computing:28 applications are developed as a set of small individual functions that are instantiated and executed on demand. SLaaP must take care of the operation of the edge resources through unified resource management, the provisioning of the functions (for example, cold launch times in microseconds), and the optimization of the system to achieve global goals, such as high resource utilization and guaranteed service quality.29 Additionally, secure network channels and so-called enclaves—private, encrypted memory regions on corresponding SGX-enabled processors—should be used (termed trusted edge computing) to protect the provider's intellectual property.3
Besides our running example of the 4D-service discussed previously, we now illustrate two more exemplary base services to show how they can be enabled at all or applied in a novel large-scale way. Such services can be used by other base services or (third-party) value-added applications. Hence, it is crucial that these services must be highly reliable and controlled by a certified/government agency.
Unmanned aerial traffic (UAV) support. Latest industry research of logistic companies (for example, DHL Parcelcopter, Amazon Prime Air)e uses UAVs for an innovative parcel delivery service. However, a limited flying range and unresolved safety issues arising from the necessity of flying over residential areas technically block the breakthrough in all these cases.19 ASLs can notably accelerate the everyday suitability of UAVs in urban areas by playing a key role in overcoming both issues: Street lamps provide recharging stations mounted on top of them, extending the UAV's flying range; and street lamps acting as waypointsf span a virtual air corridor along them, that is, a citywide network of air routes, limiting the possible crash sites. Flying along these defined and controlled flight paths in combination with the 4D-service for tracking and positioning can enable fully automated "aerial highways" (noted in Figure 2). For safety and security—the main reasons blocking their breakthrough—UAVs may have an integrated or parachute/airbag system; street lamps can operate a catching and safety system; a "traffic police" service19 can intervene by controlling a prescribed, independently working UAV security chip that overwrites the general software and enforces controlled landing. Using these air routes, UAV job services such as an address-independent people-to-people packet transport, or event filming can be established. In emergencies, these UAVs can also assigned to a secondary use, supporting disaster management by flying rescue missions,7 providing projected evacuation advice,17 and so on.
Street lamps with their unique characteristics can actually enable an economic large-scale deployment of cloudlets, making the breakthrough of practicable edge computing at long last.
Technology-enabled civil protection. ASLs acting as a citywide surveillance infrastructure may support counterterror-ism and crime fighting. For instance, a combination of sensors (acoustic, optical, others) mounted on the street lamp could detect gunshots or explosions, allowing fast response and the identification of perpetrators. Assessing situations with regard to risks and avoiding these risky areas, a remote or virtual companion can escort and guide a user to his or her destination. To prevent or detect a serious crime, police can appear by combining so-called holoportation,21 which can rely on the proposed 4D-service and thus become ubiquitous, with 3D projection techniques to produce a hologram of a police officer. The holographic officer, who can be seen, heard, and interacted with almost as if he was present, serves as a deterrent and victim support until the real police officers or paramedics arrive on the scene. Moreover, an injured person gets holographic victim support in disasters until the rescuers arrive physically. However, systematic further development of such promising techniques is necessary to make the holographic scene more realistic and immersive.
More than the base services, SLaaP facilitates novel value-added services and applications for both humans and things, covering or digitally developing several application domains: tourism, urban mobility, marketing, sales, gaming, city planning, logistics, environmental affairs, sustainable cities, to name a few.16 These new (qualities of) applications enabled by SLaaP lead to a novel kind of interactions, called SLaaP-to-X interactions; X represents the possible end users: Humans and mobile devices; vehicles of all kind; and city inventory (for example, buildings, places, hotspots) and facilities. For instance, SLaaP can stage an intelligent personal cloudlet that moves along the user's path and personalizes his environment, such as, displaying personal navigation/evacuation advice through laser-based projection; humans can further interact with ASLs in novel ways (say, through vision-based gesture interactions), raising challenges like obtrusiveness, occlusion, and privacy in the public multi-user environment. As a static supportive infrastructure, SLaaP can complement autonomous driving/flying and tackle safety and security issues by reliably detecting obstacles (for example, pedestrians, accidents, roadworks) or the road surface state using the proposed 4D-service. Finally, SLaaP can be the entry point into the smart city for smart buildings/homes, exchanging data for intelligent lighting and energy management, among others. As the city's nervous system, SLaaP can detect environmental changes that impact the city and autonomously adapt facilities to respond to such events (traffic regulation).
SLaaP promises an outstanding technological progress for smart city concepts and clearly offers many benefits for its end users, but there are still interdisciplinary research and actions required. Besides research, we identify four major stakeholders: citizens, city, government, and economy.
A holographic police officer, who can be seen, heard, and interacted with almost as if he were present, serves as a deterrent and victim support until the real officers or paramedics arrive on the scene.
From the citizens' perspective. As we have learned from Gascó-Hernandez,10 a smart city must involve its most important component—its citizens—not only as recipients of its services but also as partners (civic participation) in deciding the type of city they want to live in. One crucial challenge lies in designing the ASL in ways that citizens socially and ethically accept—or merely tolerate—the new technology, considering a socio-technical design. At the same time, we need to be careful about security and privacy, especially if the infrastructure collects and processes user-related data.31 Otherwise, the consequences may be disastrous if the infrastructure is hacked or misused. Therefore, a secure data management (Databox5) and privacy-preserving data analysis techniques (for example, replacing privacy-critical 'objects' in the 4D-service by means of semantic modeling directly 'at the source') are desirable while ensuring a two-way data tracking (based on blockchains12): Access and usage control to ensure the traceability of the data use (say, for the compliance with the GDPR) and enforcing contracts or any data usage fees; and non-repudiation of data authorship through smart contracts to ensure the undeniable proof of the guaranteed data confidence.
From the city perspective. Approximately, 60–90 million street lamps exist across Europe; 75% are over 25 years old.g It is therefore common for street lamps to consume up to 50% of a city's energy budget. Large-scale retrofitting/renewal programs (in LA or NYCh) to highly efficient LED lamps quickly amortize and can save up to 70% of the energy costs, representing a once-in-history opportunity for economically upgrading to the proposed ASLs. On the other hand, there are challenges in energy-efficiently designing SLaaP, and finding a good cost-benefit trade-off of the deployed ICT components that SLaaP does not lead to disproportionately high costs. For instance, major cities can team up with industry and further push a standard (ImHLa13) to open up market competition in this segment, and to ensure compatibility and interoperability between different manufacturers.4 Beyond that, a city can offer economic incentives to companies and rent out infrastructure resources to (partly) cover the costs. Other important challenges include a strategic rethinking of urban development and planning—concerning the new augmented infrastructure and air corridors—and a reliable integration of city facilities (power plants, traffic facilities) and rescue organizations (fire/ambulance service, police).
From the government perspective. The government's role is to timely adopt laws that allow SLaaP with all its benefits, but at the same time, and to review legal issues with respect to privacy, ethics, applicability, and liability coming with the new (technological) opportunities. For instance, one could get the idea to use the 4D-service for solving the question of fault in road accidents or other incidents (similar to dash cams). For promises of safety, many citizens are likely to accept sacrificing—at least some—privacy. A governed disclosure strategy can be realized in serious threats only (for example, terrorist attacks, natural and human/technology-caused disasters): it would allow authorities (requiring N parties) and data owners (for alibi reasons) to carefully and selectively unhide private information to enable fast and focused emergency responses or counter-terrorism. To establish citywide air corridors for UAVs, corresponding regulations must be adjusted so that they can fly near people and safely coexist in everyday urban life.19 The prevailing legal situation will surely have the decisive influence on how UAVs can use and benefit from the new infrastructure.
From the economy perspective. SLaaP should be open for third parties, targeting a comprehensive involvement of industry. The challenges lie in providing economic incentives for companies to support the new infrastructure; and in establishing an open urban platform with standardized interfaces,25 allowing companies to offer their novel services and business models for different smart cities without the need for redeveloping. Overcoming these challenges, connected urban platforms available in smart cities within a country would finally pave the way for a smart nation.
We argued and envisioned that augmented street lamps as a platform can be the key driver and enabling technology for smart cities, proposing a citywide true infrastructure for innovative urban applications. Versatile extensible hardware, integrated computer platform and base services must form the base of this effort. We further pointed out the once-in-history opportunity with the 'LED dividend' and made the case for paying more attention to this—seriously under-valued—public facility of street lamps from several research fields.
Some research reported in this article is based upon interdisciplinary work supported by the LOEWE initiative (Hessen, Germany) within the NICER project as well as by the German Research Foundation (DFG) as part of the Collaborative Research Center (CRC) 1053 – MAKI and as part of the project D4 within the RTG 2050 "Privacy and Trust for Mobile Users." Large parts of this work have been performed in the context of the LOEWE centre emergenCITY (for more details, please visit https://www.emergencity.de).
We also thank Communications' reviewers, Matthias Hollick, and Andrea Ortiz; the City of Darmstadt for the valuable street lamp data; and designer Simone Schroeder for her great graphics.
1. Atzori, L. et al. The Internet of Things: A survey. Computer Networks 54, 15 (2010), 2787–2805.
2. Boucher, S. et al. Putting the "micro" back in microservice. USENIX ATC, 2018, 645–650.
3. Brasser, F. et al. VoiceGuard: Secure and private speech processing. INTERSPEECH, 2018, 1303–1307.
4. Breining, C. et al. Orchestrating Infrastructure for Sustainable Smart Cities. White Paper, IEC (2014).
5. Chaudhry, A. et al. Personal data: Thinking inside the box. Critical Alternatives. Aarhus University Press, 2015, 29–32.
6. Coppola, R. et al. Connected car: Technologies, issues, future trends. ACM Computing Surv. 49, 3 (2016), 46.
7. Erdelj, M. et al. Help from the sky: Leveraging UAVs for disaster management. IEEE Pervasive Computing 16, 1 (2017), 24–32.
8. Fujii, K. et al. Endless flyer: A continuous flying drone with automatic battery replacement. UIC/ATC. IEEE, 2013, 216–223.
9. Garcia Lopez, P. et al. Edge-centric computing: Vision and challenges. ACM SIGCOMM Computer Communication Review 45, 5 (2015), 37–42.
10. Gascó-Hernandez, M. Building a smart city: Lessons from Barcelona. Commun. ACM 61, 4 (Apr. 2018), 50–57.
11. Gedeon, J. et al. From cell towers to smart street lamps: Placing cloudlets on existing urban infrastructures. SEC. 12018, IEEE, 87–202.
12. Halaburda, H. Blockchain revolution without the blockchain? Commun. ACM 61, 7 (July 2018), 27–29.
13. Heuser, L. et al. Humble Lamppost DIN SPEC 91347: Integrated Smart Lighting Infrastructure., 2017.
14. Jia, G. et al. SSL: Smart street lamp based on fog Computing for Smarter Cities. IEEE Trans. Industrial Informatics (2018).
15. Kaup, F. et al. Energy models for NFV and service provisioning on fog nodes. In Proceedings of NOMS'18. IEEE, 2018, 1–7.
16. Khatoun, R. et al. Smart cities: Concepts, architectures, research opportunities. Commun. ACM 59, 8 (Aug. 2016), 46–57.
17. Knierim, P. et al. Quadcopter-projected in-situ navigation cues for improved location awareness. In Proceeding of CHI 2018. ACM, 433.
18. Ku, M-L. et al. Advances in energy harvesting communications: Past, present, and future challenges. IEEE Communications Surveys & Tutorials 18, 2 (2016), 1384–1412.
19. Menouar, H. et al. 2017. UAV-enabled intelligent transportation systems for the smart city: Applications and challenges. IEEE Commun. 55, 3 (2017), 22–28.
20. Nahrstedt, K. et al. Smart communities Internet of Things, 2016; arXiv:1604.02028.
21. Orts-Escolano, S. et al. Holoportation: Virtual 3D teleportation in real-time. In Proceedings of UIST 2016. ACM, 741–754.
22. Panitzek, K. et al. Can we use your router, please? Benefits and implications of an emergency switch for wireless routers. IJISCRAM 4, 4 (2012), 59–70.
23. Perera, C. et al. Fog computing for sustainable smart cities: A survey. ACM Computing Surv. (2017), 32:1–43.
24. Qiu, H. et al. AVR: Augmented vehicular reality. In Proceedings of MobiSys 2018. ACM.
25. Santana, E. et al. Software platforms for smart cities: Concepts, requirements, challenges, and a unified reference architecture. ACM Computing Surv. 50, 6 (2017), 78.
26. Satyanarayanan, M. The emergence of edge computing. Computer 50, 1 (2017), 30–39.
27. Simsek, M. et al. 5G-enabled tactile Internet. IEEE J-SAC 34, 3 (2016), 460–473.
28. Wang, L. et al. Peeking behind the curtains of serverless platforms. USENIX ATC, 2018, 133–146.
29. Wang. L. et al. Service entity placement for social virtual reality applications in edge computing. In Proceedings of INFOCOM 2018. IEEE, 468–476.
30. Wang, S. et al. A survey on mobile edge networks: Convergence of computing, caching and communications. IEEE Access 5 (2017), 6757–6779.
31. Zhang, K. et al. Security and privacy in smart city applications: Challenges and solutions. IEEE Commun. 1 (2017), 122–129.
32. Zheng, K. et al. 10 Gb/s hetsnets with millimeter-wave communications: Access and networking challenges and protocols. IEEE Commun. 53, 1 (2015), 222–231.
a. https://smight.com; https://www.schreder.com; https://www.stengg.com
b. For example, see https://cnet.co/38XAbcK.
c. Darmstadt has won the prestigious national competition "Digital City" in 2017, aiming to become the digital model city for Germany and even for Europe; https://digitalstadt-darmstadt.de
d. We introduce a novel 3n-tier architecture, extending the traditional "device-cloud" paradigm to a three-tier "device-edge cloud" setting (vertical), where n interconnected edge nodes (that is, street lamps) participate in the middle tier (horizontal).
f. A waypoint is similar to the reference point of landing within the radio-navigation system (called ILS) for aircraft, which provides aircraft with horizontal and vertical guidance.
Copyright held by authors/owners. Publication rights licensed to ACM.
Request permission to publish from [email protected]
The Digital Library is published by the Association for Computing Machinery. Copyright © 2020 ACM, Inc.
No entries found
