Chapter 12. Smart and Connected Cities

The world is rapidly urbanizing, and this trend is slated to continue. Less than one-third of the world’s population lived in cities in 1950; by 2050, two-thirds of our planet’s population will be city dwellers. Africa and Asia, which today account for 90% of the world’s rural population, are projected to have 56% and 64%, respectively, of their populations urbanize. Today, the percentage of people in North America, Europe, Latin America, and the Caribbean who live in cities already exceeds 70%. In terms of raw numbers, the urban population of the world has grown to nearly 4 billion, from just 746 million in 1950. By 2050, this figure will grow by another 2.5 billion.

Most cities started as small urban centers and grew organically. Very few of them were initially designed to immediately accommodate a very large population. Rapid growth typically strains city infrastructure. Roads, bridges, and sewer systems often reach their maximum capacity, making access to urban services challenging. The question of how to provide basic necessities such as water and housing while reducing the carbon footprint has begun to dominate the agendas of city planners and civic leaders everywhere.

As the world population grows, emissions and consumption also increase. When the population concentrates in limited geographic areas, the environment’s ability to absorb emissions and wastes becomes challenged. The triggers for climate change are exacerbated by increased emissions and waste. Today, cities are responsible for 60% to 80% of the world’s energy and greenhouse emissions and consume 60% of all potable water, losing as much as 20% in leakage.¹ One key concern of city leaders around the world is to optimize resources (water, power, communication infrastructure efficiency, and so on), waste, and emissions processing.

However, city leaders also know that the increasing population in a city provides an opportunity to capitalize on the city’s potential. Within the new population pouring into cities every hour of every day, there are people with skills, talents, and dedicated mentalities that will be assets to whatever city they end up living in. The sheer population density will generate more commerce for all residents. Research from Massachusetts Institute of Technology (MIT) predicts that cities in the future will account for nearly 90% of global population growth, 80% of wealth creation, and 60% of total energy consumption. The goal is not to limit the growth but to manage population increase more effectively. Improved management efficiency means providing better and more efficient urban services and ensuring better life experiences to city inhabitants—in short, capitalizing on the economic benefits of large urban populations while mitigating the social and environmental difficulties that come with them. http://web.mit.edu/professional/international-programs/courses/beyond_smart_cities/index.html.

Where will the cities of tomorrow find the resources they need to sustain themselves? There are no easy answers—but there are smart solutions. This chapter covers some of these solutions, in the following sections:

An IoT Strategy for Smarter Cities: This section defines how IoT technologies can be leveraged to improve the lives of citizens and the efficient management of urban centers.

Smart City IoT Architecture: This section describes the four main layers for integration of IoT for smart cities.

Smart City Security Architecture: This section examines the primary constraints and considerations to secure IoT for smart cities, both in terms of communication and in terms of acceptable use of the collected data.

Smart City Use-Case Examples: This section details four use cases of IoT for smart cities: street lighting, smart parking, traffic, and smart environment. Chapter 13, “Transportation,” and Chapter 15, “Public Safety,” provide two other use cases that apply to smart cities that are big enough to require dedicated chapters.

Cities are expected to generate almost two-thirds (63%) of IoT’s overall civilian benefits worldwide over the next decade.² To maximize value, smart cities can combine use cases through a shared-revenue business model together with special partners to monetize city location services for retail and tourism, as well as city planning, parking, and water management.

A recent Cisco study, as illustrated in Figure 12-1, expects IoT to have the following economic impact over a 10-year period:³

Smart buildings: Smart buildings have the potential to save $100 billion by lowering operating costs by reducing energy consumption through the efficient integration of heating, ventilation, and air-conditioning (HVAC) and other building infrastructure systems. Note that the financial gain applies to city budgets only when a building is city owned. However, the reduced emissions benefit the city regardless of who owns the buildings.

Gas monitoring: Monitoring gas could save $69 billion by reducing meter-reading costs and increasing the accuracy of readings for citizens and municipal utility agencies. The financial benefit is obvious for users and utility companies when the utility is managed by the city. There are also very important advantages in terms of safety, regardless of who operates the utility. In cases of sudden consumption increase, a timely alert could lead to emergency response teams being dispatched sooner, thus increasing the safety of the urban environment.

Smart parking: Smart parking could create $41 billion by providing real-time visibility into parking space availability across a city. Residents can identify and reserve the closest available space, traffic wardens can identify noncompliant usage, and municipalities can introduce demand-based pricing.

Water management: Smart water management could save $39 billion by connecting household water meters over an IP network to provide remote usage and status information. The benefit is obvious, with features such as real-time consumption visibility and leak detection. In addition, smart meters can be used to coordinate and automate private and public lawn watering, initiating the watering programs at times when water consumption is lower or in accordance with water restrictions imposed by civic authorities. At a city scale, IoT can be used to manage water supply equipment and report status (for example, open or closed, on or off, reservoir level, output speed vs. input). A gate or a pump can be opened and closed remotely and automatically in real time, based on a variety of flow input and output analytics data. Vibrations can be measured to detect and predict potential equipment failures. Repair teams can be dispatched proactively before equipment failure occurs. These efficiency gains directly translate into operational gains.

Road pricing: Cities could create $18 billion in new revenues by implementing automatic payments as vehicles enter busy city zones while improving overall traffic conditions. Real-time traffic condition data is very valuable and actionable information that can also be used to proactively reroute public transportation services or private users.

To maximize the return on investment (ROI) on their energy and environmental investments, smart cities can employ strategies that combine water management, smart grid, waste management, particulate monitoring, and gas monitoring.

A smart city can use these technological advances to improve its livability index, which can help attract and retain talent amid increasingly competitive labor markets. The growth in jobs and talent influences the amount of foreign investment and how many top companies come to settle in a city, which in turn leads to higher economic impact and improves the potential for future investments.

The independent investment model results in the following problems:

Isolation of infrastructure and IT resources

No sharing of intelligence and information, such as video feeds and data from sensors.

Waste and duplication in investment and effort

Difficulty scaling infrastructure management

This fragmented approach is not scalable, efficient, or economically viable, and it does not benefit from cross-functional sharing of data and services. For example, in traditional city infrastructure, parking, lighting, and traffic departments are all administratively independent and run separately, with their own budgets used to invest in upgrading their respective infrastructures. This introduces duplication of investments made on the same infrastructure, with only minor details tailored to specific department oversights. This is highly inefficient money management and wastes public resources that could instead go toward benefitting the community. However, integrating and expanding disparate IoT systems with different vendors and data protocols creates challenges.

Cities need to begin with a solution that can extend systems across vendors, technologies, and data types, and they should approach their infrastructure investment with a horizontal solution that addresses their issues cohesively. A comparison can be made to a highway system: Cities do not have different road systems for cars, trucks, and emergency vehicles because it is much more efficient to use a unified road network. This idea can be applied to data flowing over the network: Multiple networks are less efficient than a single unified network. A city needs an open IoT solution that allows all public services (garbage, parking, pollution, and so on) to use a common network and, possibly, exchange data for cross-optimization.

City issues are typically large-scale. They require collection of large amounts of diverse data sets in real time. For instance, managing traffic flows and congestion in a city involves understanding patterns of traffic in real time. This means that data from traffic sensors, traffic cameras, parking sensors, and more has to be collected and analyzed in real time so that decision making can be optimized around signal timing, rerouting, and so on.

All these requirements pose technological challenges, including the following:

How do you collect the data? What are the various sources of data, including hardware endpoints and software?

How do you make sure that any data collection devices, such as sensors, can be maintained without high costs?

Where do you analyze the data? What data do you carry back to the cloud, and what data do you analyze locally?

What kind of network connectivity is best suited for each type of data to collect?

What kind of power availability and other infrastructure, such as storage, is required?

How do you aggregate data from different sources to create a unified view?

How do you publish the data and make it available for applications to consume?

How do you make the end analysis available to specialized smart city personnel, such as traffic operators, parking enforcement officers, street lighting operators, and so on at their logical decision points?

How do you present the long-term analysis to city planners?

Each smart city needs a tailored and structured computing model that allows distributed processing of data with the level of resiliency, scale, speed, and mobility required to efficiently and effectively deliver the value that the data being generated can create when properly processed across the network.

In this context, a combination of cloud and fog computing makes sense. (Chapter 2, “IoT Network Architecture and Design,” provides more architectural details on cloud vs. fog computing.) Data that needs to be processed locally stays at the edge of the network. For example, local and real-time information about available parking spaces is only locally available. Metrics about traffic can also be processed locally to regulate and synchronize traffic lights or redirect public mass transit vehicles around congestion. In contrast, global statistics and analytics about peak times and structure can be sent to the cloud to be processed at the scale of the entire city. This allows city planners to better organize the growth of various activity centers in the city and also plan for increases in public transportation availability, waste collection shift times, and so on.

In smart cities, multiple services may use IoT solutions for many different purposes. These services may use different IoT solutions, with different protocols and different application languages. Therefore, data flow from sensor to application involves a translation process into a normalized language that can be exposed through APIs for other service application consumption. This translation ensures a single language for all devices in the cloud. This common language simplifies communication and data management and allows solutions to inform each other. Leveraging this exchange allows smart cities to develop new solutions that span services, without requiring further infrastructure, and future-proofs the system. With a normalized language and open APIs, cities can invest in new solutions, knowing that the new solutions will easily interact with existing solutions. In contrast, a closed format would limit the exchanges and the ability to leverage part of a solution to improve another one.

The following sections discuss various high-level considerations for choosing sensors for specific applications and provide examples of technological networking requirements to support sensors and drive real-time solutions through information and communication technology (ICT) connectivity.

A sensor is a data source that generates data required to understand the physical world. Sensor devices are able to detect and measure events in the physical world. ICT connectivity solutions rely on sensors to collect the data from the world around them so that it can be analyzed and used to operationalize use cases for cities. (See Chapter 3, “Smart Objects: The ‘Things’ in IoT,” for an in-depth discussion of smart objects.)

A variety of sensors are used at the street layer for a variety of smart city use cases. Here is a short representative list:

A magnetic sensor can detect a parking event by analyzing changes in the surrounding magnetic field when a heavy metal object, such as a car or a truck, comes close to it (or on top of it).

A lighting controller can dim and brighten a light based on a combination of time-based and ambient conditions.

Video cameras combined with video analytics can detect vehicles, faces, and traffic conditions for various traffic and security use cases.

An air quality sensor can detect and measure gas and particulate matter concentrations to give a hyper-localized perspective on pollution in a given area.

Device counters give an estimate of the number of devices in the area, which provides a rough idea of the number of vehicles moving or parked in a street or a public parking area, of pedestrians on a sidewalk, or even of birds in public parks or on public monuments—for cities where bird control has become an issue.

For each type of data to collect, there are a variety of solutions and possible approaches. The choice of sensor technology depends on the exact nature of the problem, the accuracy and cost trade-offs appropriate for it, and any installation limitations posed by the physical environment. Another consideration is the requirement to interact with other IoT systems in the same physical space. For example, parking space availability sensors may be part of a closed system available to users through an app, or they may have to interact through open APIs with other systems, such as towing companies, public law enforcement agencies, parking meters, and so on. A holistic solution would make the data open and integrated, bringing together disparate systems through a single and open platform.

One of the key aspects to consider when choosing a sensing device is its lifetime maintenance costs. Some sensors are mounted on city infrastructure, such as light poles. These sensors can benefit from the power, and possibly the network connectivity, of their mounting location. However, other sensors may be installed in the ground or in other inaccessible locations. Once they are installed, the cost of pulling them out to deal with an issue is very high. At installation time, drawing a power line to the sensor location is typically also extremely costly. Thus, such sensors are normally battery operated and energy efficient so they have long life expectancy, and they are ruggedized to avoid maintenance costs.

Another key aspect to consider when choosing the right technology for a smart city is edge analytics. The many sensors and their data must be managed through the network in a way that securely processes data with minimal delay—and often in real time. Distinguishing between events in order to send only relevant pieces of data is a key component with the large data intakes inherent in a smart city’s design. For example, a car-counting sensor does not need to send an update for each car detected; it may send only a cumulative count every minute. Similarly, a pollution sensor may process chemical sensing all the time but send status reports only at intervals. To maximize processing speed and minimize server requirements, the amount of data that goes through cloud servers must be event based. (Refer to Chapter 2 for an in-depth look at cloud vs. fog data processing.)

Event-driven systems allow the city infrastructure to be contextually intelligent so that only targeted events trigger data transfer to the cloud. This flexibility allows the infrastructure to monitor a large number of systems without the risk of overloading the network with uneventful status update messages. Analytics processed on the edge distributes the computing and storage requirements for the cloud, maximizing data transfer speeds and minimizing server requirement and cost.

Finally, for sensor characteristics, storage is a key consideration that depends on the method, location, and length of time the data has to be archived. This varies based on legal requirements on a per-country basis as well as use case; the difference is significant between storing video for weeks and using a set of event-based triggers, and it has a big impact on the analytics that can be included in the limited physical capacity of the device. In addition, given the scale of city deployments and the needs related to long-term planning, the storage requirements might be higher than in traditional deployments, and event-driven approaches help avoid putting pressure on the supporting network. Cities must figure out the best approach to address their storage requirements as well as determine how long they need to keep their data, and choose devices appropriately based on those criteria.

Data collection and storage also have an important impact on privacy. A video sensor used to count entities may be able to read car registration numbers or record the faces of pedestrians. Legal and privacy considerations play a major role in choosing a system. There may be a mandate to record this type of data for public safety reasons. On the other side of the spectrum, there may be a conditional mandate that devices can be counted only if they cannot be individually identified (with privacy as a requirement). In this last case, a sensor may be specifically chosen for its limited image resolution or inability to identify objects beyond their general shape or silhouette. The communication system may also be designed to forbid more than device count transport (low bandwidth, for example). The scope of the privacy requirements must be clearly understood and scoped at the time of design.

Regardless of the type of system chosen, sensor data is transported and processed by the IoT system. Although IoT systems use common APIs and normalized language in the cloud, they may use different network protocols. To physically connect the data streams from so many devices, it is critical to have a network infrastructure that can communicate with devices using the variety of communication protocols operating at the street level. Cellular technologies are core to ICT, as cities typically allow for easy and dense cellular connectivity. However, other technologies are present.

In all cases, the network for a smart city has to be ruggedized for outdoor conditions and must be able to withstand harsh weather conditions. In order to support the ICT solutions a smart city deploys, the network must meet standards for outdoor electronic devices and provide maintenance faults for simplified issue isolation.

Another issue that network planning must take into account is the required level of agnosticism of smart city networks. LoRaWAN is growing as a major protocol for smart city sensors, across multiple verticals. LoRaWAN is well adapted to the type of ranges required in an urban environment and the types of data exchanges that most smart city sensors need. (Chapter 4 provides detailed information about LoRaWAN.) However, multiple use cases mean that multiple protocols may be deployed. A heterogeneous array of sensors for different domains and from different technology vendors utilizes different communication protocols to drive certain benefits and features. Many sensors come with their own gateways that are compatible with their specific hardware. However, the network needs to be broad and vendor-agnostic enough to enable these gateways to communicate with a larger network and with end nodes that can bridge low-power consumption protocols, such as ZigBee to IP, and meet a host of other communication requirements. All these protocols and systems have to work together and be transported over the same network infrastructure.

Smart city networks also have to make possible local analysis and closed-loop decision making, which also means that computing capacity at end nodes needs to be higher than for typical deployments. The size and complexity of the network grows with the size of the smart city deployment, as well as with the number and types of sensors utilized by the city. The IoT network infrastructure is the backbone of any cohesive smart solution for a city; device connectivity is the key to the utility of digitized public services.

The city layer may appear to be a simple transport layer between the edge devices and the data center or the Internet. However, one key consideration of the city layer is that it needs to transport multiple types of protocols, for multiple types of IoT applications. Some applications are delay- and jitter-sensitive, and some other applications require a deterministic approach to frame delivery. A missed packet may generate an alarm or result in an invalid status report. As a result, the city layer must be built around resiliency, to ensure that a packet coming from a sensor or a gateway will always be forwarded successfully to the headend station. Figure 12-3 shows a common way of achieving this goal.

In this model, at least two paths exist from any aggregation switch to the data center layer. A common protocol used to ensure this resiliency is Resilient Ethernet Protocol (REP). (REP is examined in detail in Chapter 9, “Manufacturing.”)

The key technology in creating any comprehensive smart solution with services is the cloud. With a cloud infrastructure, data is not stored in a data center owned directly or indirectly by city authorities. Instead, data is stored in rented logical containers accessed through the Internet. Because the containers can be extended or reduced based on needs, the storage size and computing power are flexible and can adapt to changing requirements or budget conditions. In addition, multiple contractors can store and process data at the same time, without the complexity of exclusively owned space. This proximity and flexibility also facilitate the exchange of information between smart systems and allow for the deployment of new applications that can leverage information from several IoT systems.

The cloud model is the chief means of delivering storage, virtualization, adaptability, and the analytics know-how that city governments require for the technological mashup and synergy of information embodied in a smart city. Traditional city networks simply cannot keep up with the real-time data needs of smart cities; they are encumbered by their physical limitations. The cloud enables data analytics to be taken to server farms with large and extensible processing capabilities.

Figure 12-4 shows the vision of utilizing the cloud in smart solutions for cities. The cloud provides a scalable, secure, and reliable data processing engine that can handle the immense amount of data passing through it.

Smart city issues require not just efficient use of infrastructure, which the cloud helps enable, they also require new data processing and management models. For example, cloud services allow for Software as a Service (SaaS) models that create cyclical returns on investment. With the cloud approach shown in Figure 12-4, smart cities can also take advantage of operating expense–based consumption models to overcome any financial hurdles in adopting solutions to their most critical issues. Critical data, such as air condition (humidity, temperature, pollution) levels monitoring, can be processed initially. Then, as the efficiency of IoT is scaled up, richer data processing can be enabled in the cloud applications. For example, the humidity level can be used to regulate the color and luminosity of street lights. In times when city budgets are strained, data processing can be scaled down to essential services.

In the layered architecture just discussed, a platform can be enabled by the cloud service; this platform would aggregate, normalize, and expose city data through APIs consumable by applications that drive services.

However, not all data is processed in the central cloud-based data center. Most of the real-time and locally significant data can be directly processed at the edge of the network, leveraging a fog architecture. In this model, processing and analytics capabilities are made available at the top of the street layer, where gateways operate. In this way, data coming from multiple sensors (of the same type or of multiple different types) can be processed locally at the edge. Decisions are locally significant and can be made without unnecessary interactions with the cloud. The results from the locally processed data are then sent to the cloud to provide a more global perspective.

With the architecture described in this section, a smart city can incorporate any number of applications that can consume normalized data from a cloud-hosted platform or from fog applications. Because the entire architecture operates with compatible APIs, these applications can even enable cross-domain benefits. As an example of such cross-domain benefits, at known traffic congestion points, parking spots could be removed from availability maps, waste management routes could be properly rerouted, and street lighting could be increased. These types of cross-domain data correlations can be developed and improved by the system, inside the layered architecture, since there is a horizontal level of aggregation and normalization.

The architecture provides application developers and sensor vendors with the tools necessary to innovate and invent new community experiences via open APIs, software development kits (SDKs), city information models, and more to develop city-qualified applications that drive high-value smart city services. This enables tailored, customized smart city solutions that can also be developed by citizens themselves, for their cities.

Ideally, a smart city utilizing ICT connectivity would use the cloud in its architecture, but if this is impossible, the city would need to invest far more in the city layer’s networking components (for example, switches, routers) and still may not be able to drive the same cross-domain value propositions and scalability in its design.

A city could begin with traditional networking designs and on-premises hosting, with the intent to protect the data, but then it might quickly conclude that the capabilities of on-premises data centers lag behind what cloud-hosting data management can enable for the city. In that case, a hybrid hosting approach could be implemented, whereby some data may be migrated to the cloud while other data stays on-premises. For example, images from individual street cameras may be stored locally, while the analytics about pedestrian or car flows and the associated metadata may be hosted in the cloud.

In general, citizens feel better about data security when the city itself, and not a private entity, owns public or city-relevant data. It is up to the city and the officials who run it to determine how to utilize this data. When a private entity owns city-relevant data, the scope of the ownership may initially be very clear. However, later considerations or changes in the private entity strategy may shift the way the data is used. It may then be more difficult for city authorities or the citizens to oppose this new direction, simply because they do not have any stake in the decision-making process of the private entity. In addition, private entities may have financial interests and political motivations, and they may not have the security standards or the accountability matrix city governments commonly possess or acquire through public vetting and votes. For example, suppose that a private contractor is in charge of collecting and managing parking sensor data. One possible way to increase the profitability of such data is to sell it to insurance companies looking to charge an additional premium to car owners parking in the street (vs. in a covered and secured garage). Such deviations from the original mandate are less likely to happen when cities own the data and when citizens have a way to vote against such usages.

Traditionally, network deployments use a siloed approach and do not always follow open security standards. Agencies may run applications and servers on the public cloud, have limited security safeguards implemented, and use cloud-based collaboration tools without proper security. Hence there is a need for a centralized, cloud-based, compliance-based security mechanism to address the needs of service providers and end users. Security is obviously an end-to-end problem, starting with where and how data is collected, and spanning pervasively throughout the entire data processing lifecycle.

A security architecture for smart cities must utilize security protocols to fortify each layer of the architecture and protect city data. Figure 12-5 shows a reference architecture, with specific security elements highlighted. Security protocols should authenticate the various components and protect data transport throughout. For example, hijacking traffic sensors to send false traffic data to the system regulating the street lights may result in dramatic congestion issues. The benefit for the offender may be the ability to get “all greens” while traveling, but the overall result would typically be dangerous and detrimental to the city. The security architecture should be able to evolve with the latest technology and incorporate regional guidelines (for example, city by-laws, county or regional security regulations). Network partners may also have their own compliance standards, security policies, and governance requirements that need to be added to the local city requirements.

Starting from the street level, sensors should have their own security protocols. Some industry-standard security features include device/sensor identification and authorization; device/sensor data encryption; Trusted Platform Module, which enables self-destruction when the sensor is physically handled; and user ID authentication and authorization. Sensor identification and authorization typically requires a pre-installed factory X.509 certificate and public key infrastructure (PKI) at the organization level, where a new certificate is installed through a zero-touch deployment process. This additional processing may slow the deployment but ensures the security of the exchanges.

Another consideration may be the type of data that the sensor is able to collect and process. For example, a roadside car counter may include a Bluetooth sensor that uniquely identifies each driver or pedestrian. Security considerations should determine whether this information should even be collected. If it is collected, a decision should be made on whether this data is processed using an “online process” (in which information is used for analytics, but individual identifying data is not stored and is therefore forgotten immediately) or a more classical analytical process (in which data is stored temporarily, either because the algorithm needs to avoid duplicates or because trajectory determination is part of data processing). Data should be secured both at rest and in motion, but when data is stored, additional security needs to be put in place to ensure that information will not be tampered with, abused, or stolen. This is true regardless of the location where data is stored—at the gateway (fog) or in the cloud.

The city layer transports data between the street layer and the data center layer. It acts as the network layer. The following are common industry elements for security on the network layer:

Firewall: A firewall is located at the edge, and it should be IPsec- and VPN-ready, and include user- and role-based access control. It should also be integrated with the architecture to give city operators remote access to the city data center.

VLAN: A VLAN provides end-to-end segmentation of data transmission, further protecting data from rogue intervention. Each service/domain has a dedicated VLAN for data transmission.

Encryption: Protecting the traffic from the sensor to the application is a common requirement to avoid data tampering and eavesdropping. In most cases, encryption starts at the sensor level. In some cases, the sensor-to-gateway link uses one type of encryption, and the gateway-to-application connection uses another encryption (for example, a VPN).

Multiple specific elements (such as switch-to-switch encryption) may be required by each deployed IoT solution to increase the reliability of the system. At the data center layer, having secure virtual private clouds is a common requirement. Creating dynamic perimeters around applications, clients, hosts, and shared resources can further obfuscate data from prying eyes. Integrating the latest technology frameworks, such as mutual Transport Layer Security (mTLS) or OAuth 2.0 for device attestation and identity-based access, is key to ensuring the integrity of a city solution.

Following and prioritizing the security logic in the layered architecture will reduce the chances of a serious network security breach or privacy violation of city data.

LEDs require less energy to produce more light than legacy lights, and they have a much longer life span and a longer maintenance cycle.

A leading lighting company estimates that a complete switch to LED technology can reduce individual light bills by up to 70%.⁵

LEDs are well suited to smart solution use cases. For example, LED color or light intensity can be adapted to site requirements (for example, warmer color and lower intensity in city centers, sun-like clarity on highways, time- and weather-adaptive intensity and color).

Figure 12-6 shows how electricity prices rise, while LED prices decrease and their unit sales rise.

The global transition to LED is a key enabler for smart cities to begin the moving toward ICT connectivity solutions. As electricity bills rise and prices for LEDs drop, this hardware transition can open the door to a complete smart lighting solution.

A comprehensive smart lighting solution enables a converged and networked system that incorporates LED-based fixtures and dynamic lighting control, supported by the layered smart city architecture discussed earlier in this chapter that is easily extensible to support other use cases and solutions to benefit the city.

A human or automated operator can use a cloud application to perform automated scheduling for lights and even get light sensors to perform automated dimming or brightening, as needed. The schedule can also impact the light intensity level and possibly the color, depending on environmental conditions, weather, time of year, time of day, location within the city, and so on.

Lighting nodes vary widely in the industry, especially with respect to elements such as what communication protocol they use (for example, Wi-Fi, cellular, ZigBee, 802.15.4g [Wi-SUN], LoRaWAN), level of ruggedization, and on-board sensor capabilities. These features are optimized for different circumstances and conditions; no single lighting node can support all environments ideally. For example, city centers may be locations where Wi-Fi is easy to deploy (due to proximity to Ethernet or Internet backbones, ranges on the order of 100 meters, and high urban furniture density offering a large choice of relays and gateway points), whereas highways may mandate longer-range solutions such as cellular or LoRaWAN. Many solutions leverage wired connectivity, either by using the existing city cable infrastructure or by adding a cable adjacent to the power cable. In cases where cabling is not practical, wireless technologies may bring interesting capabilities. For example, 802.15.4g controllers can be used to form a mesh and extend the network. This extension is used not only to connect other light poles but also to connect smart meters from neighboring houses. In all cases, the built-in versatility offered by the four-layer architecture shown in Figure 12-2 ensures that all the different types of technologies optimized to fit any city topology can be flexibly incorporated into the solution.

Lighting, as an ICT connectivity solution, utilizes an existing city asset with an existing power source. Enabling that asset with ICT connectivity technologies not only drives revenue on its own but can also drive an ICT connectivity solution by being the asset that different technology pieces use to operate. For example, LED light bulbs are commonly equipped with basic sensors that can detect light (driving local on/off and dimming actions) and that can also detect many other environmental parameters, such as temperature, motion, pressure, or humidity. Adding such functions to sensors typically adds only marginal cost. The great advantage is that street lights can also become local weather reporting stations. This information is useful for local citizens and also for city transportation systems that need to detect real-time driving conditions. Functions such as monitoring power, measuring the oxygen and carbon dioxide levels, measuring the amount of pollution or particulate matter, and detecting levels of long-wave ultraviolet A (UVA) and short-wave ultraviolet B (UVB) radiation can also be added to provide additional values and services (for example, pollution monitoring, pollen alerts, energy grid monitoring). More specialized capabilities can also be embedded, such as basic audio or video functionality with filtering and analytics to detect traffic congestion or car crashes in real time. In this case, the network connectivity technologies are important as usage and bandwidth consumption increase. Efficiency is a key feature of smart cities, including connected lighting. For example, the amount of lighting can be reduced on highways where no cars are detected. Lights can be set to blink with a specific pattern to help police locate a specific GPS location quickly. Using IoT for lighting allows for a plethora of useful applications, and for this reason, lighting is often used as an introductory IoT function for smart city deployments. Municipalities often start with the energy cost savings as a primary priority and soon realize that sensors added to the already deployed IoT lighting infrastructure can add major benefits and advantages to city management.

Contributes to pollution: Tons of extra carbon emissions are released into the city’s environment due to cars driving around searching for parking spots when they could be parked.

Causes motorist frustration: In most cities, parking spot scarcity causes drivers to lose patience and waste time, leading to road rage, inattention, and other stress factors.

Increases traffic incidents: Drivers searching for parking spots cause increased congestion in the streets and that, in turn, causes increased accidents and other traffic incidents.

Revenue loss is another consequence of drivers looking unsuccessfully for parking space, and it also has various negative side effects:

Cities often lose revenue: As a result of inadequate parking meter enforcement and no-parking, no-standing, and loading-zone violations, cities lose revenue.

Parking administration employee productivity suffers: Employees waste time roaming the streets, attempting to detect parking rules offenders.

Parking availability affects income: Local shops and businesses lose customers because of the decreased accessibility caused by parking space shortages.

As we look at ways to apply technology to tackle some of the most pressing issues facing cities today, parking is an area where improvement is clearly needed and can be easily quantified. As cities continue to grow in number, size, and complexity, urban infrastructure and the services that rely on it are increasingly stressed. The issues described above become more pressing as urban population and density increase. The difficulties of parking in urban areas impact citizens’ quality of life and make living in the city less desirable due to increased travel times, stress, noise, pollution, and so on.

One option for solving urban center traffic issues is to repurpose dense urban space to create additional parking infrastructure. However, such an option is often challenging, primarily because of the costs, financial and otherwise. Instead of resorting to utilizing valuable city real estate to create more parking spaces, cities often have the option of optimizing the usage efficiency of existing parking assets to better manage citizen needs. This option often provides the quickest relief to the parking issue, while minimizing the need for new investment and limiting the impact on urban architecture.

Technology innovations are happening all the time, making the holistic ICT connectivity architecture even more important. For example, new detection technologies rely on sensing the radio emissions (Bluetooth and others) coming from a vehicle. The adoption of such new technologies implies that the communication architecture is open enough to accommodate the needs of these new systems. (Refer to Chapter 2 for more details on such an open architecture.) Combining these technologies in innovative ways also expands the possibilities of the services IoT systems can deliver; this certainly holds true for smart parking. For example, sensors can be installed in disabled parking spots. An application can be used for drivers to register their disability and then locate these spots more easily. When a user parks, the sensor can communicate with the application on the driver’s smart phone to validate the disability status and limit fraudulent use of these parking spaces.

Regardless of the technology used, parking sensors are typically event-driven objects. A sensor detects an event and identifies it based on time or analysis. The event is transmitted through the device’s communication protocol to an access point or gateway, which forwards the event data through the city layer. The gateway sends it to the cloud or a fog application, where it is normalized. An application shows the parking event on operator dashboards, or personal smart phones, where an action can be taken. For example, a driver can book a nearby parking spot, or a parking operator can remove it from the list of available parking spaces in target locations. This action triggers data to be sent back to the parking sensor to modify its availability status based on the received instructions. In turn, the sensor may interact with nearby systems. For example, in response to these instructions, lights above parking spaces can be turned red, orange, or green to display a free, booked, or occupied spot, thus facilitating a driver’s search for an available parking spot. Similarly, a parking sensor can send a status to a general parking spot counter at the entrance of the parking deck to display how many spots are available in a given area, such as on a particular floor of a parking deck. This communication may be direct but often goes through a gateway, the network, and the application that communicates with the other systems through APIs. The user may also access the data from the cloud or fog-based applications to see the list of spots available in a particular city district or neighborhood. Smart data can also be embedded—for example, to increase the discount on more distant parking spots or increase the cost of parking spots closer to venues at particular times (such as sporting events or concerts).

As discussed earlier in this chapter, smart parking has three users that applications must support through aggregated data: city operators, parking enforcement personnel, and citizens. The true value of data normalization is that all parking data, regardless of technology or vendor, would be visible in these applications for the different users to support their particular experiences. The following are some potential user experiences for these three user types:

City operators: These users might want a high-level map of parking in the city to maintain perspective on the city’s ongoing parking situation. They would also need information on historical parking data patterns to understand congestion and pain points in order to be able to effectively influence urban planning.

Parking enforcement officers: These users might require real-time updates on parking changes in a certain area to be able to take immediate action on enforcement activities, such as issuing tickets or sending warnings to citizens whose time is nearing expiration. Their focus is driving revenue creation for the city and minimizing wasted time by performing parking monitoring and enforcement at scale (that is, not needing to look at each individual vehicle situation since only a small percentage of the inspected vehicles actually require an action).

Citizens: These users might want an application with a map (such as a built-in parking app in their car) showing available parking spots, reservation capabilities, and online payment. Their focus would be on minimizing the time to get a parking spot and avoiding parking tickets. The application could warn when parking duration limits approach, allowing the driver to move the vehicle before the timer expires or pay a parking timer extension fee without having to go back to the vehicle.

Other types of sensors that are part of traffic control solutions include Bluetooth vehicle counters, real-time speed and vehicle counters, and lighting control systems. These sensors provide a real-time perspective while also offering data collection services for historical data trending and correlation purposes. Communication techniques are as varied as sensor form factors. For example, counters installed in light fixtures or traffic lights may use a wired or wireless technology and any number of communication protocols. When a sensor is not coupled with another IoT urban application, wireless technologies are typically used.

A well-known remedy for stop-and-go traffic is to regulate the standard flow speed based on car density. As density increases, car speed is forced down to avoid the wave effect. An application that measures traffic density in real time can take action by regulating the street light cycle duration to control the number of cars added to the flow of the main routes, thus limiting or suppressing the wave effect. From the driver’s standpoint, there is a wait time before being able to get on the highway or main street, and traffic on the main route is slow but steady. The impression is that traffic is slow but moving, and the overall result is a better commute experience, with lowered and less stressful commute time, as well as a reduced number of accidents.

Information can also be shared with drivers. Countless applications leverage crowd sourcing or sensor-sourced information to provide real-time travel time estimates, suggest rerouting options to avoid congestion spots, or simply find the best way between two points, while taking into account traffic, road work, and so on.

Understanding a city’s real-time traffic patterns and being able to effectively mitigate traffic issues can drive tremendous value for a city. Many IoT systems deployed in the street, even for other purposes, can do something with traffic information; specifically, waste, parking, lighting, and environment can all drive traffic outcomes. Sensors counting devices or cars, sensors detecting movements, and sensors measuring gas concentration in the air can all be leveraged to provide an estimate of traffic conditions. The resulting estimate can be leveraged in many ways, such as at a city level to regulate traffic flows and at a citizen level to have a better driving experience.

To fully address the air quality issues in the short term and the long term, a smart city would need to understand air quality on a hyper-localized, real-time, distributed basis at any given moment. To get those measurements, smart cities need to invest in the following:

Open-data platforms that provide current air quality measurements from existing air quality monitoring stations

Sensors that provide similar accuracy to the air quality stations but are available at much lower prices

Actionable insights and triggers to improve air quality through cross-domain actions

Visualization of environmental data for consumers and maintenance of historical air quality data records to track emissions over time

As shown in Figure 12-10, at the street layer there are a variety of multivendor sensor offerings, using a variety of communication protocols. Connected environment sensors might measure different gases, depending on a city’s particular air quality issues, and may include weather and noise sensors. These sensors may be located in a variety of urban fixtures, such as in street lights, as explained earlier. They may also be embedded in the ground or in other structures or smart city infrastructure. Even mobile sources of information can be included through connected wearables that citizens might choose to purchase and carry with them to understand the air quality around them at any given moment. Crowdsourcing may make this information available to the global system.

Communication technologies depend on the location of the sensors. Wearables typically communicate via a short-range technology (such as Bluetooth) with a nearby collecting device (such as a phone). That device, in turn, forwards the collected data to the infrastructure (for example, through cellular data). Sensors that are installed in urban fixtures also use a variety of communication technologies. Sensors included in street lighting systems may utilize the same communication infrastructure as the street light control application.

Independent and standalone sensors typically use wireless technologies. In dense urban environments, ZigBee and Wi-Fi are common. However, Wi-Fi is not very well adapted for networks where reports are sporadic because Wi-Fi requires an 802.11 connection to be maintained, which consumes battery resources. (However, new implementations of Wi-Fi, such as Wi-Fi Alliance IoT Low Power and 802.11ah can alleviate this issue.) In larger environments, LPWA technologies, such as NB-IoT and LoRaWAN, are used, unless the sensor is able to use a wired technology (for example, when connecting to the wired lighting infrastructure), but this is much rarer because of the cost.

In addition to all the air quality sensor and wearable data, the data center layer or application layer represented on the left side of Figure 12-10 also receives the open data from existing weather stations as an additional data input. All these data inputs come together to provide a highly accurate sense of the air quality in the city at any given moment. This information can be visualized in applications that include heat maps of particulates, concentrates, and specific information on the dangers of such gaseous anomalies. Different pollution levels can be communicated, and gases can be tracked as they move throughout the city, either because of the wind or because of the movement of gas sources (for example, the systematic pendulum swing of commuter movements in the morning vs. the evening creates pollution patterns along the denser traffic routes).

From this pollution and environmental data and the analytics applied to it, the city can track problem areas and take action in long-term urban planning to reduce the effects of air quality disturbances. This action can take many forms, from increasing public transit availability along the more polluted routes to encouraging the displacement of businesses toward living areas to limit the need to commute daily. With this pollution information, citizens can also take short-term actions, such as turning on their air purifiers at a given moment or simply stepping inside if pollutant concentrations are becoming serious. Strategic coordinated joint actions are also possible, such as restricting traffic along certain routes or on certain days, and encouraging citizens to share vehicles or use the public transportation system.

A key concern for such smart city solutions is security. One requirement for smart cities is to isolate and protect data exchanges with the street level devices and also secure the exchanges with databases and processed data. Another requirement is to use a common transport architecture for multiple services and a common cloud infrastructure to facilitate the exchanges between applications. A great advantage of this exchange is that the same information can be leveraged by multiple users, each with different concerns or perspectives, such as individual citizens, emergency responders, and city planners. Balancing the need for security with the need for exchanges is an ongoing challenge.

A typical example of smart city IoT applications is connected lighting; IoT can reduce city energy costs dramatically while using existing lighting infrastructure and coupling with other smart city applications (pollution or traffic detection, for example) for a very small premium. Smart parking is another case where IoT provides great benefit, reducing city congestion and increasing the quality of life for driving citizens. Correlated with parking, smart traffic control is another smart city solution that can be used to regulate car flows and offer optimal route options in real time. Controlling traffic and improving parking also benefit the environment. Connected environment smart city solutions can measure, manage, and monitor air quality and pollution directly through distributed sensors or crowd sourcing.

2. J. Bradley, et al., Internet of Everything: A $4.6 Trillion Public-Sector Opportunity (white paper), Cisco, 2013, http://internetofeverything.cisco.com/sites/default/files/docs/en/ioe_public_sector_vas_whitepaper_121913final.pdf.

3. Cisco, Private Sector Value at Stake, http://ioeassessment.cisco.com/learn/value-stake-analysis. Accessed November 23, 2016.

4. New York State Department of Environmental Conservation, Reduce Utility Bills for Municipal Facilities and Operations, www.dec.ny.gov/energy/64089.html. Accessed November 23, 2016.

5. R20, The LED Future: Outdoor Lighting for Sustainable, Living Cities (white paper), http://regions20.org/wp-content/uploads/2016/08/TheLEDFuture.pdf. Accessed November 23, 2016.

6. World Health Organization, Ambient Air Pollution: A Global Assessment of Exposure and Burden of Disease, 2016, www.who.int/phe/publications/air-pollution-global-assessment/en/.