Chapter 3
Software defined things: a green network management for future smart city architectures
Ö.U. Akgül
B. Canberk Computer Engineering Department, Istanbul Technical University, Ayazaga, Istanbul, Turkey
Abstract
The control framework in modern cities highly relies on human-centralized management that dependently brings the latency and failure in many critical real-time applications. The insufficiency of centralized human control mechanism over cities’ resource and function management framework led the evolution of the smart city concept that essentially counts on the communications between different networks. However, the deployment of electronic components that can carry both the decision-making mechanisms and the functional capacity to perform the necessary action is economically impossible to afford. This impossibility brings out an older approach of separating the decision-making and the application parts. The decision-making part can handle the data from different networks and make smart decisions according to the predefined constraints and trusted control resources. The derived decisions are sent over secure channels to the actuators that can perform physical tasks to change its surroundings. Even though the definition presents an illusion of simplicity, the design, implementation, and control of two separated yet correlated network structure are not trivial.
The decentralized structure of data networks, for example, Internet of Thing (IoT) network and wireless sensor node (WSN), and ineffective scheduling algorithms result in a challenging durability problem for control frameworks. Self-Organized Network (SON) frameworks enable a self-aware system structure that can adjust network resources according to the user needs. In this chapter, as the main focus is the durability of the actuator network, we proposed a SON-based centralized control scheme. Through this chapter the observed actuator devices are cyber physical devices (CPDs) and the actuator network will be named as CPD network. With the objective of maintaining the highest coverage ratio with the minimum number of CPD devices, we used Local Indicator of Spatial Association (LISA) coefficient and Conflict Ratio for each CPD device. Using a probabilistic approach, the number of minimum active devices to fulfill the user expectations is determined. Using LISA coefficient and Conflict Ratio, the centralized controller determines a schedule for IoT devices. In this study, in order to maintain the connection with the generality, a layered CPD device network is considered where all CPD devices at the same layer are the same. Different CPD devices are considered to be in different layers and the controller can optimize each layer separately.
Keywords
smart city
self-organized networks
software defined network
local indicator of spatial association
self-aware networks
self-controlled networks
energy-aware coverage optimization
1. Introduction
The existing city applications mostly depend on reactive human-centralized controls. However, the infeasibility of this framework for the future’s denser and more complicated cities is obvious [1]. In order to overcome this infeasibility, the real-time monitoring data of wireless sensor nodes (WSNs) and the user feedback are added to control cycle of the cyber physical devices (CPD) within the cities. Maintaining connections between CPDs, WSNs, and users brings out the idea of smart cities. Even though there is not a complete definition of the smart cities, the most common aspect of it is the connections between different subsystems of the city, for example, surveillance system and the traffic control system. This completely connected structure increases the computational and physical resource demand [2]. This new approach to the city management integrates the machine-centralized state detection–failure prevention model and user control. More specifically, the automatized systems continuously monitor the behaviors of their systems and detect the state changes and the anomalies in their systems. The control framework tries to predict the next failure in the system and tries to prevent it. Such a control framework presents a continuous observation on the parameters and machine-based parameter detection and processing that handles a far larger amount of parameters. Unlike digital city management, smart cities present more accurate and more efficient failure detection and recovery specifications. The participation of the user aspects to this autonomous structure improves the user experience and enables exceptional action selection. From this point of view, the smart cities can be investigated under two major regions, that is, data plane and the control plane of the city.
First of all, the design and implementation of the control plane is the most challenging part of the smart city deployment. The future’s smart cities will cover large variety of devices, for example, WSNs, CPDs, Internet of Thing (IoT) devices, and mobile users. This huge variety of devices will use different technologies to connect to the Internet, as seen in Fig. 3.1. The heterogeneity of smart city devices (SCDs) will bring the scalability and interoperability problems [4]. The network management structure has to maintain the efficiency and the success of the communication between different devices and systems. The heterogeneity of the device types and their protocols should not affect the integrity of the city scope network [5]. Moreover, the intermediary steps of the data gathering, processing, and performing actions should be invisible to the users. More specifically, the machine-centralized control framework demands an abstraction of the users from the system parameters. For instance, when the control framework tries to optimize the temperature at a home, the user should not be concerned about the sensor data, for example, the thermometer value or the state of the air conditioner. From a user perspective, the main objective is receiving the ultimate result without concerning the intermediary steps. The communication between cyber physical systems would remove the necessity of a user control in the midlevel operations. For example, the communication between air conditioner and the number of thermometers around the room would remove the user-based iterative control process in order to keep the heat higher than a specific value. Another important challenge in control plane is the management of gathered data. The vast amount of SCDs continuously collect user and environment-specific and usually private data. Processing such a huge amount of data and storing the results are the main challenges [6].
Another aspect of the data collection process is maintaining the data security. The collected private data will face many possible attacks. Due to these malicious attempts, the service providers have to enable a secure environment [7]. Additionally, interoperability is another challenge in the smart cities [8]. The smart city infrastructure contains a huge number of switches and network equipment that have different objectives and use different operating systems (OSs). The control framework should be able to perform efficient operations using these devices. Finally and most importantly, the network control framework should be able to adjust the power consumption and present an energy-efficient network topology without a performance degradation [9]. The energy efficiency downfall is usually due to the controller’s lack of capability in following the dynamic needs of the network. In order to maintain the Quality of Service (QoS) requirements, the network providers usually overprovide the network resources. This mismatch between resource demands and supply causes an unnecessarily high power dissipation. The network controller needs dynamic traffic observations and adaptive resource allocations [10].
Second, every kind of monitoring and performing devices including the mobile devices and CPDs forms the data plane of the smart network. Recently, the sensor devices and controllers are used in basically every layer of the city management from surveillance systems to farming techniques. In addition to the city-related sensor devices, consumer electronics are also increasing in the cities. The decrease in the electronic device manufacturing costs increased the consumer rate that uses at least one smart electronic device that can communicate through the Internet. By definition SCD covers basically every electronic device that carries a radio-frequency (RF) receiver, for example, intrasensor and intersensor networks, smartphones, smart buildings, or wearable electronics. As a generic approach, SCD types are divided into two main groups, that is, reactive and active devices. Reactive devices are dumber devices that only receive some information and act something. In contrast with reactive devices, active SCDs are smarter devices that are capable of pursuing a complete communication between other SCD or human operators and perform required actions. The generic objective of the reactive SCDs (R-SCDs) is increasing their energy efficiency without a sacrifice of performance [11]. The active SCDs have unique and application-based performance metrics and the power management usually has secondary importance [12].
2. Smart city data plane challenges
Smart city network proposes a massive capacity and throughput improvement and a better QoS in terms of latency, battery consumption, device cost, and reliability. In order to manage the vast amount of devices, the network densification and the autonomous network management frameworks are considered. The idea of connected SCDs would be effective in many aspects. The control and preventative applications would eliminate possible dangers and failures before they actually happen. Abstraction of the intermediate steps would increase the user satisfaction. Moreover, connection between different kinds of devices enables the determination of a more realistic approach toward the physical processes. The correlations between different data could be processed more accurately and effective models could be applied. However, the application of SCD network contains many challenges.
2.1. Compatibility between smart city devices
In order to maintain connection with the generalization, the communication in a SCD network topology can be modeled with a few subroutines, that is, the communication between SCD and the network element (NE; switch), the communication between different NEs, and finally the communication between the NE and the controller. The controller is the device that tries to use the collected raw data from the SCD network. The connection between the NE and the controller would not be different from the recent communication framework. However, the communication between the NE and the SCD and the results of this communication cause the main challenge. Future’s smart cities contain huge number of smart device networks, which will produce enormous amount of raw data. Since most of the SCDs are application based designed and dedicated to certain objectives, they all contain different structures and capabilities [13]. In the communication level, a certain layer structure is expected for these SCDs that demands a certain electronic capabilities. However, such a demanding framework will increase the expenditures on both design and implementation steps. For example, since the future’s smart cities will have billions of sensor nodes, making these devices more complex than they need to be will increase both Capital Expenditures (CAPEX) and operational expenditures (OPEX) that will eventually make this sensor-based observation idea unrealistic. However, using application-defined simple and cheaper SCD would cause device to switch compatibility issues. The existing infrastructure demands a certain layered structure for these devices [14].
Additionally, the SCD networks contain basically all kinds of consumer electronics. Most of these devices carry plug and play specification [2]. So the NEs have to detect the existence of a new SCD in their network and have to determine a new set of rules for this new device. Such a determination process would also be impossible due to the hardware limitations. The NEs would need to be more complex that will increase the CAPEX and also more complexity would make them open to failure. Moreover, the communication infrastructure will also be demanding. In addition to the heterogeneity in SCD network, the communication infrastructure also contains NEs from different manufacturers that carry different embedded rules and applications. The system designers have to consider all that heterogeneity of network plane. As the number of SCD increases and they communicate more frequently, the massive network load will trigger the deployments of more NEs and make the heterogeneity problem more crucial. In the conventional communication infrastructure the controllers have to recognize a vast amount of switches. Apart from the heterogeneity between devices, the standardization heterogeneity between different countries and even cities will be problematic.
2.2. Simplicity
The heterogeneity of SCDs and dynamic nature of them causes additional complexity issues. Since many SCDs are application-based and dedicated devices, they demand specific applications and special processes for each case. These demands cause complexity in management as the recent switches carry their control plane (their OS) inside them with a hard link to their data plane. This hard link prevents the implementation-based applications to be applied to the switches. This challenge brings out the necessity of simplicity in management. In order to overcome the management problem, software-based application control is necessary. The engineers should be able to integrate specific functions to NEs in order to handle this application-based SCD network. The design of the active networks is a result of this research. By theory, the software engineers would transmit specific packets to NEs that would add special application functions to these devices. However, it is not feasible for a large network as the engineers have to control the whole network manually. This manual control will also bring static characteristics to the network, as the network will lose its ability to adapt itself for anomalies autonomously. Moreover, the security is also a problem as wrong or bad applications would be injected to NEs. Additionally, the bandwidth and storage requirements complicate the hardware design of switches. Most of the SCD applications demand simple yet important preprocessing stages that would actually determine the packet’s destination.
From the network management point, the network administrator has to consider system issues such as efficiency, fairness, and load balancing that results in high complexity. The key network performance metrics, that is, latency, reliability, speed, mobility, or spectrum usage, have to be considered in the network configurations. Since SCD would demand very different QoS requirements, the necessary algorithms to detect and respond to these demands will became more complex. However, as the complexity of the applied algorithms increases, the speed of the optimal configuration will decrease. This trade-off between configuration speed and complexity of the applied algorithms also appears in the power management. Higher complexity usually means more calculations and this leads to inefficient battery management for NEs. Design and implementation process of SCD network management devices is also challenging. By definition, SCD covers basically every electronic device that can connect to the network. This broad device coverage complicates the communication structure and the necessary protocols. Moreover, SCDs can demand specific applications or routines. Programmers should be able to implement their application libraries and programs to the network controllers. In the existing topology management framework, since each device carries its own OS and the necessary applications, application-specific functions and programs have to be integrated at the design process of the controllers or switches. This persistent structure is also infeasible for SCD networks as it basically demands the change of whole infrastructure at each device update.
2.3. Mobility and geographic control
In the future, smart cities will be depending on SCDs to perform various tasks, that is, perception, observation, execution, etc. Due to this dependency, the smart devices will be distributed in a large geographic region. These distributed devices continuously produce a vast amount of data that should be transmitted between these devices simultaneously. This massive packet load brings out the necessity of a high communication capacity. As these devices travel through a large region, they use many switches and links. In conventional network topology, each switch makes a decision according to a local knowledge. However, a possible link failure pushes the switch to make a new route to transfer the packet.
Their broad task definition will make the smart devices to be distributed in a large geographic region. As the geographic coverage area of an SCD network grows, the number of NEs between SCD and the controller will increase. In the conventional network topologies, each NE makes its own routing tables. When it receives a packet, based on the embedded rules and the specifications, the NE decides where to route the packet. However, each NE could have a local knowledge without a complete understanding of the network topology. This lack of generality makes it weak to the possible failures. For instance, a possible link failure will push the NE to make a new route to transfer the packet. This fluctuation in packet’s route would have enormous effects on the latency and jitter. In real-time applications of SCD network, such QoS problems would lead to not only bad user experience but also wrong decisions. Especially for the medical applications of SCD, such misjudgments could end in fatal situations. Such problems could only be solved with the usage of a dynamic traffic engineering. In addition to the necessity of traffic management, the network management should have a strong mobility management. The smart devices can join the network in very broad areas and can move rapidly. For instance, in a commercial SCD network application, for example, fleet management, the company may demand the instant locations and the fuel consumptions of their truck fleet. In their trade route, the smart devices in truck will pass many switches and the communication has to be kept continuous. In order to perform such a strong mobility control a centralized control mechanism and a complete view of global network topology are necessary.
3. Software defined network-based smart city network management
The main challenges of the future applications of SCD networks in smart cities can be listed as follows:
• lack of central control that has a complete information of the topology;
• integration and application simplicity;
• excessive amounts of system needs;
• compatibility between SCDs and NEs.
In order to overcome these challenges software-centered control structures need to be developed. In this development process the Software Defined Network (SDN) is a promising framework. SDN proposes a logically centralized framework that separates the control and the data planes. The connections between these two separate planes are performed by the Open Flow protocol (Fig. 3.2).
Figure 3.2 SDN-Based Network Control; Software Defined Things
3.1. Centralized control
One of the most important specifications of the SDN is the separation of the data and the control plane. The data plane contains dummy switches, whereas the control plane covers all the OSs. The control plane presents a centralized control over the data plane that contains lots of NEs. This logically centralized control framework has complete information of the network topology, that is, the distribution of NEs in 2D space and their workloads. Therefore, SDN has the capability to distribute the workload fairly and optimize the network throughput [15]. Moreover, SDN’s control plane is also in connection with the user-defined applications that enables the applications to remotely connect the network devices. Due to this connection, it allows specific applications to optimize the network resources according to their needs. Applications can directly access the control plane to gather information about the network state or make specific reservations for network resources such as bandwidth or changing priorities of specific IP addresses.
Additionally, the logically centralized controller enables centralizing the policy control for all devices on the network. In the recent network infrastructure, to deploy a new network policy or a new protocol, all network equipment has to be updated separately. This discrete upgrade process is not applicable since it is not feasible to upgrade each device separately and it also increases the OPEX. Thanks to its logically centralized control plane, SDN allows easy deployment of new protocols and network services as a result of high operation abstraction. Moreover, since the controller can determine the network state perfectly, it allows dynamic application management. As previously stated, one of the most important reasons of the SCD deployment in smart cities is the necessity of continuous and complete monitoring of the SCD. However, in order to enable successful power management, the monitoring of noncritical parameters may be scaled down in off-peak times in the day, for example, night times.
3.2. Simplicity and inerrability
One of the most crucial problems of the classical networks is their persistent structure. The classical NEs use their embedded functions and specifications to determine an action to the received packet. However, this persistency of the embedded software structure constraints the possible applications especially in SCD networks. SCD networks are designed in an application-specific manner. This design paradigm requires different actions for different cases. Even some SCD packets may need preprocessing stages or packets received from a specific SCD may need to send to different controllers to manage the situations. For instance, a heat sensor may send the data to a predicting controller until the measured data stays below a certain value, Tcritical, whereas it sends the packets to an action controller after the heat exceeds this critical value. These kinds of implications are application-specific architectures and implementing them into the SCD would be infeasible and expensive. However, the SDN model enables this kind of application-specific actions.
The application plane of the SDN proposes a specific action space for each different implementation. Any software engineer can write an application for the SDN controller that can define a new set of actions for specific cases. The SDN controller is challenging in terms of security. First of all, the collected data needs to be encrypted and also the admission process has to be revised in order to improve privacy. Moreover, the application integration ability is challenging in terms of security. The attackers can manipulate the controller by submitting their malicious applications. Nevertheless, this kind of attacks is prevented by defining the usable primitives and the templates to write an application. By this way, the system provider could passively control the extent of the user applications. The SDN proposes an open and simple programmable network topology. Implementing new functions or new specifications to the network controller is as simple as downloading a new application to the network controller [16]. This simplicity in the distribution of the new applications and libraries presents an ease of use for the users. The generic network topologies demand licensed programs and unique, application-specific libraries to meet the application requirements. This method increases the capital and the OPEX. However, the simplicity that SDN presents enables the programmers to implement generic programs and libraries and openly share these applications with the other users.
Finally and most importantly, SDN presents the concept of “reconfiguration on the fly” specification [17]. The newly applied actions will be available while the network is actually being used. In SDN, dummy switches carry routing tables that is similar to the classical NE. However, in SDN, the newly received and unknown packets are buffered and an action request is sent to the control plane using Open Flow. Using the applications and the libraries, the controller chooses a new set of action and sends it to the dummy switch. As this mechanism is repeated for each unknown packet, the new applications and new action sets will be able while the system is running. By this “reconfiguration on the fly” capability, the optimization of the applications performance will be simpler due to the autonomous network provisioning and related configuration challenges. Moreover, SDN supports scalable and effective programming with diverse device services and raw data streams [13].
3.3. Virtualization
Abstraction is a critical challenge in both network applications and SCD applications. The Abstraction within the smart city has two major parts. First, the abstraction of the services is important to improve user experience. One of the most important aspects of the smart cities is improving the quality of the user life. In order to manage this aspect the involvement of the users to the network management is necessary by presenting specific data and necessary feedbacks. But being a part of the control cycle would not imply involving in each state. The system would need to operate lots of functions and optimization processes in order to maintain an efficient and sustainable network topology. Human involvement in the intermediate steps would make the control framework open for failure and slow down the optimization process. Instead of demanding user control on each state, the network controller should accept the user-specific data as a network objective and the user feedback as a generic network state.
Second, the network resources and the network applications should be virtualized from each other. In order to maintain security and increase the user experience, the user-demanded applications that are implemented to the network controller should not notice the system resources they used and the constraints of the system. Most of the SDN applications are using cloud-based solutions, which presents a virtual infinite calculation capacity and service rate. These virtual resources increase the network service efficiency while easing the design and implementation of new service applications and decrease the necessary time to develop these applications. Moreover, the virtualization of discrete and usually geographically distant resources provides more control to the SDN over the system resources while decreasing the CAPEX and OPEX.
3.4. Compatibility
The increasing number of mobile devices, the participation of CPDs to the wireless network, and the increasing demand for performance improvement lead to the deployment of SDN-based smart city networks. It proposes a massive capacity and throughput improvement and a better QoS in terms of latency, battery consumption, device cost, and reliability. In order to manage the vast amount of devices, the network densification and the autonomous network management frameworks are considered. Despite the promises of the SDN-based smart city networks, many challenges are also coming to light.
In the future’s smart city applications, vast amount of SCD networks will be applied. Such an enormous number of SCD will continuously produce raw monitoring and control data that will be transferred by delay-bounded QoS requirements through a large number of NEs. The compatibility between SCD and NEs and also between NEs is crucial. SCD concept covers a large variety of devices. Due to this reason, it contains many different OSs and protocols. Enabling a flat structure in terms of communication protocols and OS is not a feasible solution because of CAPEX and OPEX. The interoperability and the harmony in communication should be provided from the communication infrastructure. Moreover, especially interdevice communication should be autonomously managed and adjusted in terms of necessary communication protocol. Nevertheless, the interconnection between different network equipment is also challenging. Like SCDs, network equipment concept covers a large variety of switches. Different producers usually present different communication sequences and primitives and the network providers should be able to handle all these different protocols. In terms of network infrastructure the problem has two stages.
First of all, the compatibility between existing infrastructures needs to be managed. The geographic growth of the cities increased the distance between two connected devices. In order to reach destination device, the packet has to pass many switches. The compatibility between different switches becomes a major aspect in order to achieve a fully integrated network. Second, the compatibility between existing infrastructure and the newly deployed infrastructure is also crucial. The number of devices in the network is increasing exponentially (Fig. 3.3). In order to sustain the connectivity, new network equipment is needed to be incorporated into the network infrastructure. However, the changing and increasing needs of users and service providers trigger the changes in the network equipment design. Due to this difference, the newly applied infrastructure should be able to cooperate with the existing infrastructure while performing specific tasks and actions.
SDN presents a simple yet efficient methodology to overcome the compatibility issues. In the generic network management frameworks, the network equipment contains both the data plane and the control plane. It has its own objectives, action sets, and algorithms. The interoperability becomes a problem due to this self-operable structure. SDN divides the control plane and the data plane. The data plane contains SCDs and dumb switches, whereas the SDN controller has the control plane. All network equipment will be dumb devices that do not carry specific action sets or objectives. The controller has these objectives and using the Open Flow protocol, it adjusts the actions of the switches. This division of control and data plane degrades the interoperability issues as the dumb switches will demand application-based assignments from the controller. Additionally, the SCDs would not need to carry any specific structure since the received data can be preprocessed by the SDN controller. As the SDN is a software-based control framework, the network architecture would be dynamically adjusted according to the needs of the network and the user expectations.
3.5. Challenges of SDN in smart city applications
Separation of control and the data planes can fulfill many expectations from the next-generation smart city networks such as simplicity in integration, development, and compatibility within a heterogeneous network. However, there are lots of open issues. First of all, as in all complex networks, the resource management is a challenging task. In future’s smart cities, the network topology will be dynamically changing. Because of this dynamic nature, the devices will be competing for network resources. Even though the SDNs virtualize the network resources, an adaptive and fair management algorithm will be necessary. Determination of user expectations is an essential part of the network design. Different users would produce different types of data that would demand unique processes (eg, monitoring, prediction) and face various types of problems (eg, latency). The network controller has to carry the specifications of self-analyzing and dynamic configuration of the network resources while handling with a mix of network objectives. Increasing the user satisfaction from the network services by using a simple, robust, and low-cost network controller is a major challenge in future’s smart cities.
In addition to the wireless resources in the network, the power consumption is another challenging issue to be handled. The power consumption within the network should be investigated under two major topics, that is, energy efficiency of the backhaul system and the energy efficiency of the network topology. According to the latest researches, the power consumption of the network is mainly because of the network infrastructure. A centralized control algorithm that can optimize the network topology to maximize the energy efficiency is relatively basic for SDN. However, most of the devices carry plug and play specification that changes the network topology rapidly. Due to that, the network management framework has to support autodiscovery capability as well as adaptive power control mechanism. The dynamic mode selection would perform adaptive energy consumption specification; however, the off-loading techniques to the underlay network have to be investigated. The energy efficiency of the overall network topology is another challenge in the power management framework. The future’s smart cities will be counting on SCDs in monitoring and analyzing. However, SCDs are battery-driven objects and the durability of these devices will be the main concern of the network management. Therefore, the network management will need to control the network topology to increase the lifetime of these devices. On another perspective, the decision process of where to locate these devices is another problem. A brute force solution is to use a vast amount of WSN and CPD devices to cover the whole geographic region. However, this solution will result in massive capital and OPEX. A lesser coverage would lead to a more cost-efficient application; nevertheless, it may cause low performance.
4. Software defined things framework
The application of SDN in SCD management is an effective solution to the infrastructure-based problems. In a smart city, many services and applications are going to be observed with SCD and will be sent to the SCD controllers. Even though the SCD applications would demand a complete communication with the controller, R-SCDs will not require any specific response from the controller. Instead, they will demand only a power optimization framework to increase their lifetime. In a classical network, this optimization can be solved in the controller. The controller can provide a complete on/off schedule for the devices and optimize the power consumption. However, with huge number of R-SCDs an enormous traffic load would be observed in the network, which would end in bad resource management.
In this chapter, to provide a SDN-based SCD management framework, we provide a self-adaptive R-SCD network management framework. By performing the optimization process at the control plane layer, we are preventing a huge traffic load. Additionally, by dynamically changing the network structure, we are decreasing the response time.
4.1. Reactive smart city device management
R-SCDs are dummier electronics that cannot usually perform actions or can execute some simple tasks. Like sensor structures, R-SCDs usually make certain observations such as heat or pressure and with the detection of a specific situation, they transmit a constant data packet, usually an acknowledge packet. The concept of situation, or more generally event, has to be defined for this kind of devices. In this chapter, two possible event types are considered, that is, continuous events and discrete events. Continuous events can be deterministically modeled. In these events, the detection of a previous event assures the possible detection of a future event. For instance, motion is a continuous event. The change of location is continuous in time domain. More specifically, in a 1D space, to detect an obstacle at x location at time t, it has to be in x + 1 or x −1 location at t −1. In contrast with the continuous events, discrete events are chaotic events. They cannot be modeled deterministically. This event type is usually applicable to modeling consumer electronics. For example, the coffee machine tries to detect a discrete event, existence of hot coffee. However, even if one coffee machine detects hot coffee at time t, another coffee machine adjacent to it would not detect hot coffee at time t + 1.
R-SCDs try to detect events, continuous or discrete, and in case of detection, they send acknowledge message. The operation cycle of these devices changes the main objective of these devices. The main objective of these devices is to increase the number of events for a long time interval. To increase the number of observed continuous events the SCDs have to be placed at remote locations, whereas they need to cover the complete observation environment concurrently.
Even though for most of the applications the SCDs cannot work identical job, it is possible to model them in a layered structure. On the same layer devices performs identical tasks while devices from different layers observe different events. Conventional approach to solve this optimization problem is activating all SCDs simultaneously that decreases the battery life of the IoT devices [11]. In Fig. 3.4, the changes of IoT network lifetime with the communication ratio are measured. In a more specific sense, since the reactive IoT devices communicate in times of event detection, Fig. 3.4 emphasizes the network lifetime’s dependency on the number of observed events. In a high event detection environment, by keeping all IoT devices in active mode, the lifetime of the network is decreased by 40%. Even though such a decrease may be acceptable for some intracity applications, most of the R-IoT devices are used in suburban regions. Changing batteries frequently would increase the OPEX, and as the R-SCD network cannot be working until their batteries are changed, it will also cause decrease in QoS.
In order to increase the durability of network the battery management of the SCD network has to be managed. A simple and yet efficient approach is scheduling the R-SCD on/off times. On behalf of maintaining the connectivity with the generality, in this chapter three device states are considered, that is, on, off, and dead. When a device is in on state, it observes the environment and in case of an event detection, it transmits an acknowledge packet. In off state, device is in sleep mode and does not observe the environment. It is a battery-saving mode. Since it does not observe the environment, it stops transmitting and only keeps on listening. A R-SCD in off mode expects a wake call from the controller. Finally a device changes its state to the dead mode if its battery is exhausted. An energy-based scheduling algorithm is necessary for R-SCD networks; however, observation of the complete network is a challenge. Since SCDs have plug/play capacity, the topology of the network dynamically changes. In addition to the dynamically changing network topology, the network controller is also a problem. Optimization process requires a large amount of calculation and maintaining such a hardware system will increase the CAPEX. Finally the network should be able to adapt itself when a new device is added to the network. The existing framework demands a reset to configure the network topology that is acceptable for most cases since such a dynamic configuration process produces huge amount of calculation load. Managing the R-SCD network with a discrete management structure is expensive and for most of the situations infeasible. However, a centralized management with larger resources will efficiently manage the R-SCD network. SDNs enable smart solution in R-SCD network management.
As previously stated, SDN proposes a centralized control. This centralized OS controls dummy switches that expect an action when they encounter a new device. This action expectation model enables a control mechanism in the dynamically changing network structure. When a new device connects to the network, since the switch will not be able to find this device in the flow table, it will demand an action from the SDN controller. SDN controller will be able to decide the kind of the device and add it to the correct device list. Since R-SCDs cover a large group of electronic devices, SDN controller tries to cluster devices with the same capabilities and duties in order to optimize them. After adding device to a suitable list, it optimizes the network topology for this device type. The optimization process is performed by transmitting the control packages to the state changing devices and the necessary flow entries to the switches.
4.1.1. The number of necessary devices
Former studies proved that sleep scheduling improves the overall energy efficiency of the network. However, these studies did not consider the event observation rate in the network. The total coverage area increases with the number of working R-SCDs. And since the only way to increase the number of observed events is covering more regions, the direct proportion between working R-SCD count and the number of observed events is a valid argument. Nevertheless, the necessity of an energy management framework is an important challenge and the sleep scheduling is a promising method. Based on these arguments, a dynamic scheduling algorithm is applied in this chapter. Since applications are directly in touch with the SDN controller, each application could select a guaranteed detection rate that will determine the number of necessary working devices. The probability of observing an event can be formalized as in Eq. (3.1), where P(C | x) denotes the expected observation rate, N is the device count, R is the radius of coverage for each R-SCD, and A is the total coverage area:
(3.1)In actual implementations, the NR2 term has to be normalized since the total coverage area will not be equal to the theoretical coverage area due to collusions. A normalization parameter, ϕ, is defined as in Eq. (3.2):
(3.2)Integrating Eqs. (3.1 and 3.2), the number of necessary working devices can be determined as in Eq. (3.3), where P = P(C | x):
(3.3)
(3.4)The variance of P that is more likely a mathematical result more than an optimization problem can be calculated as in Eq. (3.4). This parameter represents the missed events that will decrease the QoS.
4.1.2. Software defined reactive devices
The proposed framework tries to optimize the network topology such that the network can cover as much region as possible with the minimum energy. When a new R-SCD is connected to the network, it sends a “hello” package to the switch. When the switch receives that package, the MAC address of this R-SCD is compared with the existing MAC addresses in the flow table. Since this device is newly connected to the network, its address will not be available in the flow table. So the switch will inform the controller and wait for an action. The proposed framework will be working in the controller. When this action request is received, the controller will first determine this device’s task. Task determination is the main clustering mechanism as the on/off mode scheduling would be effective only among devices with equivalent tasks. For simplicity, in this study we will consider only a single device task.
After the clustering process, the SDN controller will add this device to a correct list and start an optimization process among the devices in the list. In the previous sections, two different event types were introduced. In order to increase the observation rate of the discrete events the network management has to activate as much device as possible, since the determination of possible events is not possible. However, the continuous events are deterministic. This deterministic nature emphasizes that a possible event observed at location (x1; y1) will probably be observed at an adjacent location like (x2; x3). Despite the fact that such a determination would be beneficial especially for vector determination processes, it would not be efficient for many applications. Thanks to SDN structure, it is possible to let the application to select the P parameter that directly affects the number of active devices. For applications for which the determination of an existing event is more important than determining a motion vector for this event, selection of remote R-SCDs is a better solution. The device selection processes are performed with two calculation parameters, that is, Conflict Parameter and Spatial Correlation Coefficient.
4.1.3. Conflict parameter calculation
Dense deployment of R-SCDs causes conflicts in their coverage area. More specifically, two or more R-SCDs may cover the same region simultaneously. However, depending on the conflicting ratio, one of these conflicting devices would be enough to cover the area. The continuous event detection rate increases by remote devices and the discrete event detection rate affected only by the number of working devices. Since the main objective is to cover the largest area using a constant number of devices (N), selection of nonconflicting devices would be efficient. The conflict parameter (ξi) is used to measure how much unique area the ith device is covering. The conflict parameter for device i can be calculated as given in Eq. (3.5):
(3.5)In Eq. (3.5), the numerator [Dij × (Dij < 2R) + 2R × (Dij > 2R)] calculates the distance between two R-SCDs. If their coverage areas are not conflicting each other’s, then this term will be equal to 2R. By normalizing this term with the optimal case that is equal to 2R a conflict ratio is calculated. For ith device, this ratio is calculated for every jth device. After summing these conflict ratios, the conflict parameter is calculated. The optimization process tries to select highest parameter valued devices.
4.1.4. Spatial correlation coefficient calculation
The conflict parameter is effective in the configuration of the network topology. However, most of the continuous events follow a sequential path that results in the detection of the same event by lots of devices. For example, in a R-SCD network that is designed to detect a motion in a region, when a R-SCD detects a motion, an adjacent device will detect the same motion. Both of them are going to acknowledge the server about the motion, which will be a waste of power since the object of the R-SCD network is the detection of motion in an environment, not to determine the motion vector of the event. Due to this mismanagement, the working R-SCDs would not be effective and they would probably consume all their power with a minimum detection rate. With the objective of overcoming this mismanagement, a Spatial Correlation Coefficient (Ii) is designed.
This spatial parameter presents the distribution of the active devices in the environment. Ii can be calculated as presented in Eq. (3.6):
(3.6)where subscript k denotes the state of the kth device and Dki denotes the Euclidean distance between kth and ith devices.
4.2. Self-organization algorithm
The proposed application uses a self-organizing structure to adjust the R-SCD network to the dynamic nature of the devices. The self-configuration framework is presented in Algorithm 3.1. At this part the controller activates all R-SCDs to optimize the network. After the optimization, according to their locations the controller calculates their IK parameters. Since the considered structure contains only the same devices, a constant coverage area is considered. Based on this consideration the conflict parameters are calculated. After the self-configuration, the self-optimization is applied. In the self-optimization part (Algorithm 3.2), the main objective is to optimize the network in terms of power consumption. With this objective, controller first lists the devices according to their conflict parameters. The scheduling algorithm of the controller has an objective to select the R-SCD devices with the highest unique coverage area.
Algorithm 3.1 Device Control Algorithm (Self-Configuration)
Algorithm 3.2 Device Control Algorithm (Self-Optimization)
At the beginning of the algorithm, the controller tries to select the nonconflicting devices and activates all these devices. In practical applications because of the dense deployment, the number of nonconflicting R-SCD would be 0. After activating all the nonconflicting devices, the controller tries to select from the set of conflicting devices. In this process the controller compares the two adjacent R-SCD’s IK parameters. As a higher IK parameter represents a higher change to observe a chaotic event, the controller activates the device with a higher IK. This selection process continues until Nact = N(t) condition is satisfied or the end of the list. If the controller reaches the end of the list without satisfying the condition, then it starts to sequentially activate the devices from the list until Nact = N(t) condition is satisfied. When the new R-SCD network topology is determined, the normalization coefficient (t) is calculated.
The changes in the R-SCD network topology are handled by the self-healing mechanism of the framework. The changes in the network topology can happen only due to battery exhaustion. The self-healing mechanism (Algorithm 3.3) is a subfunction that recalculates the ξi and IK parameters according to the new topology.
Algorithm 3.3 Device Control Algorithm (Self-Healing)
5. Conclusions and future research
The smart cities brought many good opportunities such as low latency over time-critical applications, better resource management, or more trustable control framework. However, the huge data load from the sensor and the actuator devices and economic inadequacies caused the necessity of handling the network devices and applications in different layers. Data layer contains CPDs and sensor nodes, whereas control layer contains the necessary applications and OS. However, this virtually centralized yet actually distributed topology brought essential problems.
In this chapter, we presented an energy-aware coverage optimization framework that makes smart coverage decisions to handle the energy optimization. In the first part of the chapter we briefly discussed the main drawbacks and the benefits of SDN-based network management in smart cities. Due to its suitability to the needs, we covered an SDN-based approach and worked on an energy-based optimization framework to solve the coverage problem. We first explored the concept of necessary coverage area to guarantee a certain amount of event detection and then using this parameter, we calculated the conflict ratio and Local Indicator of Spatial Association (LISA) coefficient to cover the optimization problem. Based on the MATLAB simulations we observed huge improvements in energy efficiency without an accountable loss of coverage.
The future studies of this study can be investigated in two main folds, that is, improving self-awareness and improving the covered arguments. First of all, this chapter shows a generic understanding over the self-awareness concept in future’s smart cities. In this structure, the city should not only analyze the variable data but also anticipate future failures or needs and be able to make deterministically modelable logical (smart) decisions to handle this decision. The framework in this chapter is a self-aware energy model that considers only existing network state and does not anticipate any possible actions in the near future. Apart from an improvement in self-awareness, second, a more generic analysis and a more generic handler will be investigated. As previously explained, many assumptions are made throughout the chapter. We are hoping to improve our work by simply generalizing our study and making the necessary additions to overcome the needs to these assumptions.