Switch Migration in SD-IoT Networks for Urban Sensing

Large scale software-defined IoT (SD-IoT) networking need to deploy multiple controllers. How to ensure load balancing among multiple controllers is important to network performance. This paper proposes a switch migration strategy (MMM) which aims to minimize the global migration cost in SD-IoT networks. MMM not only considers the migration cost when making a migration decision, but also takes both the load of the overloaded domain and other domains after migration into consideration when selecting a switch for migration. Simulation experiments prove the effectiveness of the proposed scheme.


Introduction
Software Defined Networking (SDN) is a novel paradigm that decouples the network control and forwarding functions. It especially fits for applications with dynamically changing network traffic. SDN is used in Internet of Things (IoT) services and applications, termed as software-defined IoT (SD-IoT) networking [1]. With the advent of 5G networks, there will be a large number of IoT devices connected to the network in the city, making massive data in the network. Moreover, due to the wide range of the urban area, deploying multiple controllers in SD-IoT networks can ensure the reliability and scalability of services [2]. However, load imbalance is inevitable among multiple controllers [3]. To ensure load balancing, switches controlled by overloaded controllers need to be migrated to other domains with lower utilization periodically. By dynamically modifying the mapping between the switch and the controller, imbalance in the network is avoided.
As one of the most popular issues in SDN, dynamic migration of switches has attracted a lot of attentions. However, most of existing migration strategies have not considered the cost of migration and thus the migration costs are high in these works [4]. Though some prior researches pay attention to the migration cost, they have high time overhead and require multiple migrations to achieve load balancing [5]. To the best of our knowledge, few studies have considered the impact of inter-domain data flows generated by migration on the load of intermediate domains. In fact, the migration process may increase loads of intermediate domains.
This paper proposes a switch migration strategy (MMM) with minimal global migration cost in SD-IoT networks. MMM not only considers the migration cost when making a migration decision, but also takes both the load of the overloaded domain and other domains after migration into consideration when selecting a switch for migration. Simulation experiments show that compared with the existing relevant strategies, MMM always has the minimum total network load and migration cost. At the same time, it can better ensure the load balancing among controllers.

Network model
The SD-IoT network structure for city-aware applications is comprised of three layers: the IoT layer, the Software-defined network layer, and the cloud server layer. The entire network model is shown in Figure 1: IoT layer: The IoT layer includes various sensing devices (such as smartphones, vehicles, shared bicycles, sensors, etc.) which generate sensing data.
Software-defined network layer: The software-defined network layer is responsible for transmitting the sensed data to the remote server. This layer is divided into two parts: the control plane and the data plane.
Cloud server layer: The cloud server layer contains a large number of cloud data servers. These servers collect sensed data and process data. SD-IoT network deploys two layers of controllers at the SDN layer, which is the top layer with the global controller and the middle layer with controllers. The data plane is divided into multiple domains. Each controller in the middle layer manages one domain. There are one or more switches in each domain. The global controller at the top level is responsible for monitoring the global network information. It also decides whether to perform switch migration operations or not based on the load balancing status of the controllers in the middle layer. Flows in the network can be divided into two types, as the Intradomain flow and the inter-domain flow. Intra-domain data flow is the flow with the source and destination are in the same control domain; Inter-domain data flow is the type of flow which source and destination are not in the same control domain.

Data stream transmission
In urban sensing applications, each sensing event has a location. When the sensing device senses an event, it generates data to describe the event. The sensing device transmits the sensing data to a gateway (such as gateway g), and then the gateway transmits the data to the remote data server through the software-defined network layer. Let the set of all gateways be G, the set of all events be E, and the set of data servers be D. As shown in Figure2 (a), it is assumed that four events e 1 ，e 2 ，e 3 and e 4 occurred in a certain area of the city and four gateways are deployed in this area, namely g 1 , g 2 , g 3 and g 4 . Let the load of transmitting event e i to the gateway g j be L (e i , g j ). We assume that the system obtains the load of each sensing event from the historical sensing task statistics near each location. In addition, we assumed that each sensing event can be transmitted to h different gateways at most. For event e i , the set of all gateways it uploads to is S i , and it can be seen that S i is a subset of G. For example, as shown in Figure 2(b), for the above four events, Since the flows of the SDN layer originates from the gateway, we consider that each gateway (g ∈ G) sends all the collected sensing data to a controller c (c ∈ C). Therefore, the gateway-to-controller function is defined as F: g → c, that is, each gateway is divided into the domain where a controller is located. Let p i, j indicates the route from the gateway g i to the data server d j , and L (p i, j ) indicates the number of requested data flows through the route. A route at the SDN layer is an alternating sequence of switches and links. The set of all routes in the network is P.
(a)Multiple gateways and multiple events in urban areas (b) Gateway-to-server mapping Figure 2. The diagrammatic sketch for transmit events to gateways.

MMM migration algorithm
3.2.1. Calculating migration costs. The load of each controller is composed of two main parts. When the switch receives a newly generated data flow or an inter-domain data flow in the network, it will sends a Packet-in message [5] to the controller. The controller then calculates a route and sends routing entries. Thus a rule load is generated. Second, after the controller delivers routing entries, the controller push the flow rules to the flow tables for all switches. Thus, we have: Where L(c i ) is the total load of controller c i in the network, f packet is the average Packet-in packet size, r k is the flow request rate of switch s k , h ki is the number of hops between switch s k and controller c i , l(s k ∈c i ) indicates whether the switch s k belongs to the control domain where c i is located. If it is, the value is 1, otherwise it is 0. r sk is the speed at which the controller rotates the switch s k.
The load of switch s k is defined as the total number of request data flows routed through switch s k , as follows: Where p i,j indicates the route from the gateway g i to the data server d j , and L(p i,j )denote the number of requested data flows through the route. 1(s k ∈p i, j ) indicates whether the path p i,j passes s k , if it is, the value is 1; otherwise it is 0. When the switch s k is migrated from the controller c i to the controller c j , the controller load change of the c i domain caused by the migration is: Where indicates the set of all switches in the domain of controller c i , and h kk' is the number of hops between the switch s k before and after the migration. L(s k ) t t represents the number of data flows passing through s k through the current route.
In addition, the migration cost → is divided into two parts. The first part is the migration request cost that the switch s k sends to the controller c j , similar to formula (1)  Where h kj is the number of hops from switch s k to controller c j . The second part is the additional cost to all other domains (the source domain and destination domain are not included) when the switch s k is migrated from domain c i to domain c j , as follows:

Implementation of migration algorithm.
To ensure the efficiency of switch migration, the cost of the switch migration request should be as small as possible, and the cost of inter-domain flow changes → should be as large as possible, and keep the second part of the cost (that is, the migration cost to other domains) as small as possible. Thus, we have: To perform switch migration efficiently, the switch migration cost problem can be formulated as the following optimization problem as follows: min Where η is the load imbalance parameter and L max is the maximum load that a single controller can handle.
We use the knapsack algorithm to solve the above problems. We regard each controller domain as a small knapsack with a maximum capacity of L max , and consider the entire topology network as a large knapsack containing n (n is the number of control domains) small knapsacks. Consider the migration task of each switch s k as an item whose weight is its own load L(s k ) and its cost is . And aggregate all migration tasks into a large group. In this way, we convert the optimization problem of formula (7) into a knapsack problem. The description of the knapsack problem: select an item from a large group and place it in a small knapsack, under the constraints of the capacity of the large and small knapsacks, to achieve the purpose of making the total weight larger and the total cost smaller in the large knapsack. There are many algorithms to solve the backpack problem, such as greedy algorithm, bat algorithm and heuristic algorithm.

Simulation environment and performance evaluation indicators
The simulation experiment environment includes 3 servers with the same experimental configuration (InterlCore i7 3.5GHz 4GBRAM), 2 servers running Opendaylight [8] controller, and 1 server running Mininet [9].In order to make the experiments more real and reliable, all experiments were based on authoritative network topology, namely Internet2 OS3E [10] and TopologyZoo [11].
To verify the performance of MMM, we compare it with three other strategies: (1)SC strategy is the switch and the controller are connected fixedly; (2)DCM strategy migrates the switch to the nearest controller every time; (3)EOSDM [7] strategy based on performance optimization. It sets trigger factors to determine load imbalance, and establishes a migration efficiency model to consider both the load balancing rate and the migration cost to determine the migration switch and the migration controller. we use the following three indicators to analyze the performance of each strategy:  Migration cost: the cost of communication costs incurred by the switch per unit time during the migration process. Controller throughput: The amount of data processed by the controller per unit time after the switch is migrated.
 Load balancing rate: the load balancing status of the network after the switch completes the migration. The variance is used to calculate the degree of load balancing [7]. The smaller the value, the more balanced the load. Normalize the load balancing rate during the simulation experiment, as follows: Where x is the load variance, x min is 0, and x max is the maximum controller load.

Migration cost and controller throughput under different strategies
In this group of experiments, we compared the different migration costs of MMM, DCM, and EOSDM during switch migration when the controller in a certain domain of the network is overloaded, and the controller throughput after the switch migration. The experimental results are shown in Figure 3 and Figure 4. Since the SC strategy is a fixed connection between the controller and the switch, there is no migration cost. From the two Figures, we can see that the migration cost of DCM is lower, but the controller throughput is also lower. That's because DCM will lead to excessive load of the neighboring controllers. Although the migration cost of EOSDM is slightly higher than that of DCM, it is obviously better than DCM in terms of the throughput of the controller. The MMM strategy has less migration cost than EOSDM, and it has the highest throughput among the three strategies. Because the MMM strategy not only considers the migration cost, but also considers the additional cost of data flow during cross-domain migration, which makes the additional cost is the smallest.

Load balancing rate under different strategies
In this set of experiments, the two network topologies are selected in TopologyZoo to compare the load balancing rate of the four strategies with the number of overloaded controllers. The two topological information is as follows: BT: 36 nodes, 76 links; Columbus: 70 nodes, 85 links. We set 10 controllers in the network, and the number of overload controllers does not exceed 80% of the total number, that is, 8 overload controllers. The experimental results are shown in Figure 5 (a) and Figure 5 (b), we can see that the load balancing rate decreases with the number of overloaded controllers increases. As the number of overloaded controllers gradually increases, the load balancing rate of SC decreases rapidly. When the neighboring controllers are overloaded, the load balancing rate of DCM will decrease and EOSDM can maintain the load balancing rate better. Since MMM considers the impact on all domains during migration, not only the source domain and destination domain, it can ensure efficient migration and its performance has always been better than the other three strategies.

Conclusion
In this paper, we investigate the problem of switch migration for city-aware software-defined IoT networks and propose a dynamic switch migration strategy MMM. MMM can perform dynamic switch migration according to the dynamic changes of data traffic in the network, ensure load balancing among controllers and minimize migration cost during the migration. In simulation experiments, we evaluate the performance of MMM by comparing the four strategies at the cost of migration and controller throughput. We further analyze the impact of the number of overloaded controllers on the load balancing rate under different network topology sizes. The experimental results prove the effectiveness of the proposed scheme.