QoS-Aware Flexible Handover Management in Software-Defined Mobile Networks

Handover support is one of the important issues in mobile networks to guarantee the quality of service (QoS) requirements for mobile users. Alongside the development of network technologies, handover management to provide service continuity has been researched and applied for the Internet or cellular networks such as 3G/4G/5G. However, each network paradigm provides its own individual handover management system, even though there are different kinds of QoS requirements for various mobile services. This causes inefficient network resource utilization from the network operators’ perspectives. Therefore, this paper proposes a QoS-aware flexible mobility management scheme for software-defined networking (SDN)-based mobile networks. The proposed scheme classifies flows into four classes based on the QoS requirements of services in terms of delay and loss tolerance. According to the classified service characteristics, it provides a differential handover method for each flow class to support efficient network operation without any service degradation by interacting between the forwarding plane nodes and SDN controller. The performance analysis shows that the proposed scheme enables flexible network resource utilization, satisfying the QoS requirements for each class well compared to the conventional schemes that only consider their own individual handover procedure.


Introduction
Along with the emergence of various quality-of-service (QoS)-sensitive applications and wireless mobile devices, mobility support has been an important issue for over two decades in the network area. Especially in today's all-IP mobile networks which combine the Internet and telecommunication networks, IP-based mobility management has been applied to enable mobile users to continue their communications even when they move freely.
Since IP was originally designed for communications between fixed and static devices, a large number of works on IP-based mobility protocols have been conducted to develop mobility support for IP, such as mobile IP (MIP), hierarchical MIP (HMIP), fast handover for MIP (FMIP) and proxy MIP (PMIP) [1].
However, these conventional protocols only concentrate on maintaining IP session connectivity without considering whether QoS is guaranteed during handover. For example, handover delay and packet loss during binding updates and path changes can cause a QoS degradation in QoS-sensitive service flows [2,3].
Appl. Sci. 2020, 10, 4264 3 of 17 and applications can simply be provided through the control plane functions without the requirement of specific hardware deployment or the independent access and configuration of each hardware device. As a result, the control plane is responsible for configuring and controlling network nodes to provide mobility management through the programmable interfaces. Based on these properties, research works have been undertaken to provide mobility management in SDN-based networks. As an initial SDN work, OpenRoads [15] provided flat mobile wireless networks in which multiple wireless technologies are connected through the unified network substrate. In OpenRoads [15], the flexible mobility management, such as multicasting transmission during handover, can be provided by incorporating dumb wireless terminations and switches controlled by the SDN controller.
On the other hand, research efforts have been undertaken to apply existing mobility protocols into SDN-based networks. Among them, several works have been based on the well-known IP mobility protocols; in particular, proxy mobile IPv6 (PMIPv6) standardized by IETF [16]. PMIPv6 is a network-based mobility management protocol where a core entity called the local mobility anchor (LMA) plays the role of the physical mobility anchor point to establish the appropriate tunnel with mobility access gateways (MAGs) after handover based on the binding updates of the user information. Compared to the legacy PMIPv6-based architecture, where LMA and MAG nodes are physically deployed in the forwarding plane, the SDN-based PMIPv6 separates the mobility functions of LMA and MAG from the forwarding plane nodes, which can provide efficient route management in the forwarding plane [17,18].
In addition, many works have applied the SDN approach into the evolved packet core (EPC) architecture [11,[19][20][21][22][23][24]. Compared to the conventional EPC architecture, SDN-based EPC architecture can provide cost-efficient network operation and traffic optimization by reducing the hardware/vendor dependency and flat networking. In order to overcome the limits of current mobility management, such as routing complexity, tunneling overheads, and inefficient resource consumption, enhanced mobility support schemes have been researched using SDN-based flexible traffic engineering and centralized controllability [19][20][21][22][23][24]. However, most of these approaches only provided a general handover management procedure, which also has potential limits when the QoS requirements during handover change or new mobile services with different QoS features appear. In addition, it can be noted that an overly strict handover procedure is also utilized in the conventional EPC without the consideration of different QoS requirements. On the other hand, new, optimized mobility management schemes have been researched considering the specific QoS features [20,21]. For example, SDN-based D2D joint and half handover procedures have been proposed [20] which enhance the performance in terms of the amount of signaling messages, handover latency and missing handover rate. However, those works have focused on specific QoS requirements and provided enhanced or new mobility management schemes for those scenarios. In addition, to the best of our knowledge, there have been no efforts to provide generalized differential mobility management procedures based on the different QoS requirements through the flow path management from the core to access networks taking advantage of SDN's flexibility and controllability.
Recently, distributed mobility management (DMM) has emerged, providing a flat mobility architecture that enables traffic to be anchored locally by exploiting different gateways that are closer to the edge. In order to provide DMM, an SDN-based approach is one of the candidate solutions [19]. In the SDN-based DMM approach, mobility is achieved by the configuration of the forwarding rule on the access routers (DMM gateways) controlled by the SDN controller to redirect the traffic to the new access routers and make the users' IP address unchanged from the user's perspective after handover. However, these works also only consider static mobility management without considering the QoS requirements on the flows. In the SDN-based DMM approach, handover and new sessions are only differentiated in the path assignment, and various QoS properties have not been considered.
Although there have been research works undertaken on QoS provisioning in SDN, these works have focused on flow admission control to guarantee the QoS requirements utilizing the given resources of the forwarding plane nodes [25][26][27] and controllers [28]. In other words, previous works have been limited to admission control and resource allocation to the incoming flows, indicating that the QoS of the flows and QoS-based mobility management during network operations have not yet been introduced in SDN research.
On the other hand, in order to provide reliable network services in SDN, reliability and availability issues have been practically researched [29,30]. Based on the SDN architecture, these issues can be classified into data plane, control plane and application issues. In the data plane, abnormal behaviors in packet delivery have been covered [31,32], such as reachability failure (broken pipe), forwarding loops and tunneling errors. In the case of the control plane, fault diagnosis and controller state inconsistency have been studied [33,34]. Application plane research works have included incorrect implementation issues [35]. In addition, there have been research works on the monitoring system in SDN, which is a fundamental requirement for the network management system [36]. The monitoring system is necessary to provide accurate and timely resource reconfiguration [37], intrusion detection [38] and end-to-end path measurement [39]. Although the current paper does not cover these resilience issues and network monitoring systems, considering the data/control plane resilience issues based on the monitoring system during handover will be the topic of one of our future works.
In our previous work [14], a QoS-based mobility management scheme was initially introduced. However, the previous work had some limitations that are highlighted as follows. Firstly, the previous work assumed that all the forwarding nodes support the mobility management protocol to play the anchor role and perform the binding updates because each node can be a candidate crossover node between two paths during handover. This is because each forwarding node has a tightly coupled architecture between the control and forwarding plane. As a result, all nodes should be upgraded or modified to provide the mobility management protocol, which can be a critical limitation in terms of cost. Secondly, the previous work also assumed that the crossover forwarding nodes could intercept the handover initiation message based on the mobile users' predictive next location in the layer 2 (L2) trigger message. However, it is difficult to predict the mobile user's next location practically through the layer 2 (L2) trigger in Wi-Fi networks without modifications on the users' device. These limitations can be solved in the SDN-based networks. In SDN, the network intelligence to provide mobility management exists only in the control plane, which is decoupled from the forwarding plane, where each node only performs packet forwarding. In addition, the candidate next locations of mobile users can be determined based on the global network view of the control plane.
In this paper, in order to overcome the limits of the previous general handover management system [11,19,22], as mentioned above, a QoS-based flexible handover management scheme in SDN is proposed which provides differential handover procedures based on the QoS requirements. From the network operators' view, a satisfactory level of QoS is important because it is one of the important components of the service level agreement (SLA), which is an official agreement between a service provider and client or between service providers [39]. In 5G, SLA has been focused again because of various types of applications and service requirements [40,41]. This means that the proposed scheme can be an efficient methodology for aiding network operators in efficiently operating the limited network resources for handovers as well as for satisfying the QoS level, which is an important aspect of the SLA. In the proposed scheme, flows are classified into four classes based on the QoS requirements. Then, the different service flow handovers according to class are provided by the SDN controller collaborating with the forwarding nodes without requiring any modification on the user device as a network-based mobility management protocol.

QoS-Based Flexible Handover Scheme in SDN
In the proposed scheme, it is assumed that the action fields in the forwarding plane nodes include a buffering function in addition to the dropping the packets, forwarding through the specific port and encapsulating and forwarding to the controller as defined in the OpenFlow specification [12]. This can be a practical assumption because hardware or software-based forwarding nodes generally have a buffer to store and process the incoming packets. In addition, there have been works which consider buffers to provide scalable forwarding node designs [42,43] and analyze the optimum buffer size for QoS provisioning [44]. Except for the buffering function, the proposed scheme exactly follows the operations in the OpenFlow specification [12].

QoS-Based Flow Classification
As many works have shown, the SDN architecture has an inherent scalability problem in both the control [45] and forwarding plane [42,43,46]. Specifically, due to the centralized and forwarding/control plane separation architecture, the control plane fails to process all the input requests from the forwarding plane as the network size increases. In addition, current forwarding nodes have a resource limit for flow-state awareness [47]. This means that the classification of flows to provide flexible handover procedures is required considering the scalability issue rather than per-flow granularity.
In order to classify the flows, this paper considers the QoS requirements of flows in terms of delay and loss tolerance for handover performance. Based on our previous work [14], four kinds of classes are defined according to the QoS categories shown in Table 1. Class 1 includes delay and loss-tolerant flows which can tolerate an end-to-end delay of a few seconds and a packet loss ratio of over 3%, such as best effort service flows. File transfer protocol (FTP) and email services flows are involved in Class 2, which are sensitive to packet loss while a long handover delay can be tolerable compared to other classes. This means that a loss ratio of 0% is strictly required for Class 2. Class 3 contains both delay and loss-intolerant flows, which means that it has the strictest QoS requirements during handover compared to other classes. Interactive real-time games and video telephony as well as alert commands and control flows can be included in Class 3; at least, very short delays under 150-400 ms and packet losses of at most 0-2% percent should be guaranteed during handover for Class 3. On the other hand, Class 4 has a delay-sensitive property rather than packet loss during handover. For example, voice over IP (VoIP) and one-way audio/video streaming services flows can be included in Class 4. This class requires a very short handover delay, as with Class 3, but an about 3% packet loss ratio can be tolerable. A more detailed explanation of the properties and examples of each class are described in our previous work [14].

QoS-Based Flexible Handover Procedures in SDN
Based on the classification described in 3.1, QoS-based flexible handover procedures can be provided and controlled by the SDN controller actively or proactively whenever a handover event happens. The proposed scheme aims to operate the differential handover procedures according to the class of handover flows to guarantee the different QoS requirements of classes and efficiently utilize network resources. Figure 1 shows an access network architecture of an SDN-based mobile network in which the access switches (ASs) and core switch (CS) are deployed in the forwarding plane and the controller is in the control plane. In this paper, wireless parts considering wireless features are not covered. Extending the proposed scheme to the wireless parts will be the subject of one of our future works. The AS is the first switch to which the mobile node (MN) attaches, and the CS is connected with several ASs and located in the switching point of paths when MN moves between ASs. In addition, all the forwarding plane nodes are controlled by the SDN controller using a specific interface (e.g., OpenFlow, ForCES) to add, modify and delete the flow entries (FEs) of each node (for scalability, it can be noted that the SDN controller in the proposed scheme is only in charge of the access networks [10]). When the entry is added for a flow, we assume that both uplink (UL) and downlink (DL) flow entries are set at the same time if not otherwise noted. By using this interface, each forwarding node sends statistics reports which include the statistical information of each flow or aggregated flows. The proposed scheme utilizes these statistics reports to help controller recognize the L2 handover trigger of MN.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 6 of 18 all the forwarding plane nodes are controlled by the SDN controller using a specific interface (e.g., OpenFlow, ForCES) to add, modify and delete the flow entries (FEs) of each node (for scalability, it can be noted that the SDN controller in the proposed scheme is only in charge of the access networks [10]). When the entry is added for a flow, we assume that both uplink (UL) and downlink (DL) flow entries are set at the same time if not otherwise noted. By using this interface, each forwarding node sends statistics reports which include the statistical information of each flow or aggregated flows. The proposed scheme utilizes these statistics reports to help controller recognize the L2 handover trigger of MN. For example, ASs can recognize the L2 handover trigger when the specific flow entry counter that shows how many times the flow entry has been utilized decreases under the specific threshold. Then, the ASs can transmit the statistics report to the controller. As a result of this statistics report, the controller can observe the L2 handover trigger of MN. On the other hand, from the statistics report when the specific flow entry counter exceeds a specific value after the handover, the controller can recognize the MN's attachment to the new AS (if the access points (APs) also support the SDN interface, the L2 handover trigger can be easily found from the APs, and this information can be informed to the SDN controller [48]).
Additionally, in order to make MN unaware of the mobility, the router solicitation (RS) and router advertisement (RA) messages are exchanged between the MN and the controller in the SDNbased architecture.
Based on the explanations above, there are four types of handover procedure for the QoS-based flexible handover scheme based on the flow classification [14]: (1) the reactive procedure for Class 1 flows, (2) the buffering support procedure for Class 2 flows, (3) the buffering support and proactive procedure for Class 3 flows, and (4) the proactive procedure for Class 4 flows. Figure 2 shows the information flows for the proposed scheme. Although there can be several candidate ASs for handover, only AS 2 is described in the figure for simplicity. The detailed operation of each handover procedure is described as follows.
Before the MN moves, the MN's data is delivered via AS 1 and CS through matching to the flow entry at each node. In the flow table of AS 1, the flow entries of the flows in Classes 2, 3 and 4 are set to transmit the statistics reports to the controller for the L2 handover trigger, as mentioned above. However, in the case of the flow entries of Class 1 flows, this setting is not configured. In addition, the flow entries can be deleted either in response to a flow-mod message from the controller or automatically by a pre-defined timeout. Figure 2a shows the information flow for the reactive procedure for Class 1 flows. Because the flows of Class 1 do not require strict handover QoS requirements in terms of the delay and packet loss, the reactive procedure follows a basic operation defined in the OpenFlow specification [12]  For example, ASs can recognize the L2 handover trigger when the specific flow entry counter that shows how many times the flow entry has been utilized decreases under the specific threshold. Then, the ASs can transmit the statistics report to the controller. As a result of this statistics report, the controller can observe the L2 handover trigger of MN. On the other hand, from the statistics report when the specific flow entry counter exceeds a specific value after the handover, the controller can recognize the MN's attachment to the new AS (if the access points (APs) also support the SDN interface, the L2 handover trigger can be easily found from the APs, and this information can be informed to the SDN controller [48]).
Additionally, in order to make MN unaware of the mobility, the router solicitation (RS) and router advertisement (RA) messages are exchanged between the MN and the controller in the SDN-based architecture.
Based on the explanations above, there are four types of handover procedure for the QoS-based flexible handover scheme based on the flow classification [14]: (1) the reactive procedure for Class 1 flows, (2) the buffering support procedure for Class 2 flows, (3) the buffering support and proactive procedure for Class 3 flows, and (4) the proactive procedure for Class 4 flows. Figure 2 shows the information flows for the proposed scheme. Although there can be several candidate ASs for handover, only AS 2 is described in the figure for simplicity. The detailed operation of each handover procedure is described as follows.
Before the MN moves, the MN's data is delivered via AS 1 and CS through matching to the flow entry at each node. In the flow table of AS 1, the flow entries of the flows in Classes 2, 3 and 4 are set to transmit the statistics reports to the controller for the L2 handover trigger, as mentioned above. However, in the case of the flow entries of Class 1 flows, this setting is not configured. In addition, the flow entries can be deleted either in response to a flow-mod message from the controller or automatically by a pre-defined timeout. Figure 2a shows the information flow for the reactive procedure for Class 1 flows. Because the flows of Class 1 do not require strict handover QoS requirements in terms of the delay and packet loss, the reactive procedure follows a basic operation defined in the OpenFlow specification [12] which does not consider a QoS-supported handover. When the MN attaches to AS 2 after handover, the MN sends an RS message to AS 2. Because there is no flow entry of the message at AS 2, the message is delivered to the controller as a packet-in message. Then, the controller transmits the packet-out message including the RA message to add the flow entry at AS 2 and modifies the flow entry at the CS to change the path of the flow after handover.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 7 of 18 which does not consider a QoS-supported handover. When the MN attaches to AS 2 after handover, the MN sends an RS message to AS 2. Because there is no flow entry of the message at AS 2, the message is delivered to the controller as a packet-in message. Then, the controller transmits the packet-out message including the RA message to add the flow entry at AS 2 and modifies the flow entry at the CS to change the path of the flow after handover. Figure 2b describes the information flow for the buffering support procedure for Class 2 flows. In order to provide loss-less handover for loss-intolerant Class 2 flows, the buffering procedure is supported for Class 2 flows. When the MN moves, the controller receives the statistics report for the L2 handover trigger from AS 1. Through the flow entry updates of AS 1 and CS, MN's data after detaching from AS 1 can be buffered at CS. Due to this buffering, MN can receive data after attaching to AS 2. The following procedures for IP address configuration are the same as the Class 1 handover procedures.
The buffering support and proactive procedure for Class 3 flows is described in Figure 2c. Because Class 3 flows require the strictest QoS constraints in terms of both delay and loss during handover, both buffering and proactive entry updates are simultaneously utilized. When the controller receives the statistics report for L2 handover trigger, it updates the flow entry of the MN at AS 1, CS and candidate ASs. As shown in the buffering support procedure for Class 2 flows, MN's data at AS 1 after handover are delivered to the CS. In addition, multicasting to the candidate ASs is set at the flow entry of the MN at the CS. Moreover, the buffering of the MN's data is performed at the candidate ASs by the controller. This means that both the MN's flow entry and data after  In order to provide loss-less handover for loss-intolerant Class 2 flows, the buffering procedure is supported for Class 2 flows. When the MN moves, the controller receives the statistics report for the L2 handover trigger from AS 1. Through the flow entry updates of AS 1 and CS, MN's data after detaching from AS 1 can be buffered at CS. Due to this buffering, MN can receive data after attaching to AS 2. The following procedures for IP address configuration are the same as the Class 1 handover procedures.
The buffering support and proactive procedure for Class 3 flows is described in Figure 2c. Because Class 3 flows require the strictest QoS constraints in terms of both delay and loss during handover, both buffering and proactive entry updates are simultaneously utilized. When the controller receives the statistics report for L2 handover trigger, it updates the flow entry of the MN at AS 1, CS and candidate ASs. As shown in the buffering support procedure for Class 2 flows, MN's data at AS 1 after handover are delivered to the CS. In addition, multicasting to the candidate ASs is set at the flow entry of the MN at the CS. Moreover, the buffering of the MN's data is performed at the candidate ASs by the controller. This means that both the MN's flow entry and data after handover are stored at the candidate ASs. Thus, the MN can send and receive its data as soon as it attaches to the AS 2 without packet loss during handover. Finally, through the IP address configuration procedures, buffered data at AS 2 are delivered to the MN without additional flow entry updates at other nodes.
The proactive procedure for Class 4 flows is shown in Figure 2d. Since the flows of Class 4 are delay-intolerant, fast uplink (UL) and downlink (DL) data delivery after handover should be provided. After the controller notices the L2 handover trigger of the MN, it proactively adds the UL and DL flow entry of the MN at candidate ASs including AS 2 and modifies the UL flow entry of the MN at the CS to receive the flow from candidate ASs (e.g., the input port field of the flow entry can be wild-carded, not specified) but does not update the DL flow entry of the MN at the CS because the access switch after handover is not yet determined. In order to determine the access switch after handover as soon as possible, the controller sets the flow entry of the MN at candidates ASs to send a statistics report when the number of packets of the flow entry exceeds a specific small value. When the controller receives the statistics report message from AS 2 (among candidates ASs), it updates the DL flow entry of the MN at the CS. As a result, the MN sends and receives its data without additional packet-in and flow-mod exchanges. The following procedures for IP address configuration are the same as the Class 3 handover procedures (it can be observed that the multicasting of the DL flow of the MN to candidate ASs can be set at the CS when the controller updates the flow entry at the CS in order to reduce the DL handover delay. Using the multicasting in the proactive procedure depends on the network operator's policy because there is a tradeoff between resource efficiency and fast DL handover).

Performance Evaluation
In this section, we analyze the performance of the proposed scheme in terms of the handover signaling cost, UL/DL handover delay, and packet loss compared to the SDN-based PMIPv6 [16,17] and SDN-based EPC [23,24,49]. Among the conventional schemes, the basic handover procedure for SDN-based PMIPv6 is same as that of Class 1 in Figure 2a, such as the SDN mobility signaling flow [17] and reactive OpenFlow-PMIPv6 handover signaling flow [18]. In the case of the SDN-based EPC, we assume that the architecture is the full-SDN EPC architecture [24], where all of the control plane entities such as MME and HSS are implemented in the SDN controller for a fair comparison with the SDN-based PMIPv6. whose LMA and MAG entities are implemented in the SDN controller. In this SDN-based EPC architecture, almost the same handover procedures as those of the current EPC [4] are provided based on the virtualized MME and gateway entities [23,49]. In addition, we assume that the wireless access point has no information on the handover decision compared to the eNodeB in the EPC which determines the next eNodeB after handover and commands the handover to the MN. This means that proactive tunneling between the candidate wireless access point and SGW and buffering at the candidate wireless access points are also utilized, in the same way as the current EPC, but the functions of eNBs are not considered in this paper for fair comparison with other schemes. This means that the handover procedure in the SDN-based EPC with pro-active buffering and user plane updates [23,49] is the same as that of Class 4. Therefore, from here on, it can be observed that the operations of the SDN-based PMIPv6 and Class 1 as well as the SDN-based EPC and Class 3 have the same procedures, respectively.
Based on the previous research works [1,14], we developed an analytical model. For the sake of simplicity, the user movement pattern is assumed to be the fluid-flow model and has a constant speed in one direction. The parameters for the performance analysis are described in Table 2.
where L is message length and B is the bandwidth in wireless or wired link (η = α or β)

Handover Signaling Cost
As discussed in [50,51], there is no unit for the cost parameter, and the cost can be defined to be proportional to the time to transmit or process the signaling messages. In other words, the handover signaling cost is generally proportional to the handover frequency multiplied by the rate of handover users and the cost of the exchanged signaling messages for handover. The handover frequency is in an inverse proportion to the average residence time. The cost of the exchanged signaling messages is proportional to the distance between nodes, which is defined as the hop distance multiplied by the signaling message size. The processing cost of the node can also be included in this cost. Since the SDN-based PMIP and Class 1 of the proposed scheme are in reactive modes, signaling messages are exchanged after the MN moves to AS 2. In the case of the SDN-based EPC and Class 3 procedures, the strictest handover procedure can be provided through the L2 trigger and buffering. The difference between the two procedures is the direct participation of the MN in the handover procedure. In the SDN-based EPC, the MN requests the handover to the controller based on the wireless signal strength. This procedure is assumed to be included in the L2 trigger in Table 2. On the other hand, AS 1 plays this role in the proposed scheme based on the statistics of the MN's traffic. Thus, the L2 trigger is performed by AS 1 instead of the MN in the proposed scheme for Classes 2, 3 and 4 in Figure 2. The required signaling process of other classes exactly follows the handover procedures, as explained in Figure 2. Based on Table 2, the signaling cost per unit of the residence time in the proposed scheme is as follows. In the following signaling costs, FU, RS, PI, PO, RA, and FM mean flow entry updates, router solicitation message, packet-in message, packet-out message, router advertisement message, and flow-mod message, respectively. On the other hand, the signaling costs per unit of the residence time in the SDN-based PMIP and SDN-based EPC are the same as in Equations (1) and (4), respectively.

Handover Latency
The handover latency (HL) in the SDN-based architecture can be defined as the sum of three components: L2 handover latency (T L2 ), the address configuration delay (T AC ) and the flow entry update delay after handover (T FU ). In this paper, more specifically, the handover latency is defined as the time between the detachment at the previous AP and the receipt of the first data packet at the new AP after handover. In order to remove the effect of wireless and device characteristics, T L2 and T AC are assumed to be constant values and are shown as the same parts in the Equations (5) and (6). T FU is the transmission delay of the signaling messages for handover support before the receipt of the first data packet. In SDN-based PMIP, Class 1 and Class 2, after L2 handover, signaling messages including router solicitation/advertisement, packet-in/packet-out and flow-mod messages as well as the data packet to the MN from the CN through the CS and AS can be transmitted as described in Equation (5). On the other hand, since the flow path is changed before the MN's attachment in advance in SDN-based EPC, Class 3 and Class 4, the data packet can be delivered to the MN right after the signaling messages, including router solicitation/advertisement and packet-in/packet-out messages from the CS via AS, as shown in Equation (6).

Packet Loss
The packet loss (PL) for an MN can be defined as the sum of the lost packets for all handovers in a session [52]. This means that it can be proportional to the handover latency (HL). Since SDN-based PMIP, Class 1 and Class 4 do not support the buffering mechanism, all the packets during HL will be lost. Compared to these methods, SDN-based EPC, Class 2 and Class 3 have buffering mechanisms. Therefore, PL can occur only during L2 handover (T L2 ), the transmission time for L2 statistical reports (T stat ) and the time for the flow-mod message (T FM ). It can be noted that SDN-based PMIP and SDN-based EPC have the same HL as Class 1 and Class 2/Class 3, respectively. Therefore, PL can be defined as follows:

Numerical Results
In this section, we compare the numerical results of the proposed scheme with those of conventional schemes in terms of the signaling cost, handover latency and packet loss. Each result is the average value according to Equations (1)-(9) considering the average session length, handover rate and cell residence time per each session. To verify the numerical results, event-driven simulations based on MATLAB R2014b are performed in Windows 10 with 16GB RAM. In addition, the user movement pattern is assumed to be the fluid-flow model and has a constant speed in one direction. The parameters for the numerical results are based on Table 3 and the parameters in [14], [53]. As explained in Section 4, SDN-based PMIPv6 and Class 1 as well as SDN-based EPC and Class 3 have the same results, respectively, because each pair has the same performance equations.  Figure 3a,b show the signaling cost according to the rate of user mobility and average cell residence time, respectively. From both figures, it can be seen that Class 3, which has the same signaling cost as SDN-based EPC, has the highest signaling cost because it supports buffering and pre-updates for flow entries, guaranteeing the strictest handover policy (loss-less with minimum handover delay). Since Class 2 also supports a buffering mechanism which requires data delivery and buffering cost, it has a higher signaling cost than Class 1 and Class 4 which do not support a buffering mechanism. On the other hand, Class 1, which has the same signaling cost as SDN-based PMIP, has the lowest signaling cost because it does not provide buffering and pre-updates for flow entries but only performs flow entry updates in response to the router solicitation from the MN. In addition, both figures show that the signaling cost can increase when users are more mobile because signaling occurs based on the number of handover operations. From the comparison between Class 2 and Class 4, we can see that signaling costs for buffering operations are much higher than those with only pre-updates for flow entries.

Numerical Results
In this section, we compare the numerical results of the proposed scheme with those of conventional schemes in terms of the signaling cost, handover latency and packet loss. Each result is the average value according to Equations (1) to (9) considering the average session length, handover rate and cell residence time per each session. To verify the numerical results, event-driven simulations based on MATLAB R2014b are performed in Windows 10 with 16GB RAM. In addition, the user movement pattern is assumed to be the fluid-flow model and has a constant speed in one direction. The parameters for the numerical results are based on Table 3 and the parameters in [14], [53]. As explained in Section 4, SDN-based PMIPv6 and Class 1 as well as SDN-based EPC and Class 3 have the same results, respectively, because each pair has the same performance equations.   Figure 3a,b show the signaling cost according to the rate of user mobility and average cell residence time, respectively. From both figures, it can be seen that Class 3, which has the same signaling cost as SDN-based EPC, has the highest signaling cost because it supports buffering and pre-updates for flow entries, guaranteeing the strictest handover policy (loss-less with minimum  Figure 4a,b show the handover latency according to the wired and wireless link delay, respectively. From both figures, we can see that Class 3 and Class 4 have the same, lower handover latency because both support pre-updates for flow entries. More specifically, compared to the case in which the first data packet after handover can be transmitted through the pre-updated flow path in Class 3 and 4, the packet can be delivered after the last flow-mod message is received in the CS from the SDN controller in Class 1 and 2. This means that, even though additional signaling is required, pre-updates for flow entries are required for delay-tolerant services. Figure 3a,b show the signaling cost according to the rate of user mobility and average cell residence time, respectively. From both figures, it can be seen that Class 3, which has the same signaling cost as SDN-based EPC, has the highest signaling cost because it supports buffering and pre-updates for flow entries, guaranteeing the strictest handover policy (loss-less with minimum handover delay). Since Class 2 also supports a buffering mechanism which requires data delivery and buffering cost, it has a higher signaling cost than Class 1 and Class 4 which do not support a buffering mechanism. On the other hand, Class 1, which has the same signaling cost as SDN-based PMIP, has the lowest signaling cost because it does not provide buffering and pre-updates for flow entries but only performs flow entry updates in response to the router solicitation from the MN. In addition, both figures show that the signaling cost can increase when users are more mobile because signaling occurs based on the number of handover operations. From the comparison between Class 2 and Class 4, we can see that signaling costs for buffering operations are much higher than those with only pre-updates for flow entries.   Figure 4a,b show the handover latency according to the wired and wireless link delay, respectively. From both figures, we can see that Class 3 and Class 4 have the same, lower handover latency because both support pre-updates for flow entries. More specifically, compared to the case in which the first data packet after handover can be transmitted through the pre-updated flow path in Class 3 and 4, the packet can be delivered after the last flow-mod message is received in the CS from the SDN controller in Class 1 and 2. This means that, even though additional signaling is required, pre-updates for flow entries are required for delay-tolerant services.  Figure 5a,b show the packet loss according to the rate of user mobility and average residence time, respectively. From both figures, we can see that Classes 2 and 3 have the lowest packet loss because they support buffering after L2 handover occurs. Based on the comparison between Class 1 and Class 4, Class 4 has lower packet loss because it has a lower handover disruption time due to the pre-updates for flow entries. Although the buffering support requires high signaling costs, as mentioned above in Figure 3, the mechanism is needed for the loss-tolerant services. Since the pre-updates for flow entries also have the effect of reducing the packet loss, finding the optimal method considering both signaling cost and packet loss could be the topic of one of our future works.
respectively. From both figures, we can see that Class 3 and Class 4 have the same, lower handover latency because both support pre-updates for flow entries. More specifically, compared to the case in which the first data packet after handover can be transmitted through the pre-updated flow path in Class 3 and 4, the packet can be delivered after the last flow-mod message is received in the CS from the SDN controller in Class 1 and 2. This means that, even though additional signaling is required, pre-updates for flow entries are required for delay-tolerant services.   Figure 5a,b show the packet loss according to the rate of user mobility and average residence time, respectively. From both figures, we can see that Classes 2 and 3 have the lowest packet loss because they support buffering after L2 handover occurs. Based on the comparison between Class 1 and Class 4, Class 4 has lower packet loss because it has a lower handover disruption time due to the pre-updates for flow entries. Although the buffering support requires high signaling costs, as mentioned above in Figure 3, the mechanism is needed for the loss-tolerant services. Since the preupdates for flow entries also have the effect of reducing the packet loss, finding the optimal method considering both signaling cost and packet loss could be the topic of one of our future works.

Conclusions
In this paper, we propose a flexible handover management scheme in SDN-based mobile networks. Firstly, flows are classified into four classes considering QoS requirements in terms of loss and delay sensitiveness. Then, according to the flow classifications, the QoS-based differential handover procedure for each class can be provided by the interaction between the forwarding plane nodes and SDN controller. From the analytical results, compared to the conventional schemes which can only provide their own individual handover procedure (which can be too strict or too loose), the proposed scheme provides efficient network operations without any service degradation based on the flexible handover management according to the service characteristics. In future work, the proposed scheme will be validated to measure the practical benefits based on a virtualized network environment using OpenFlow-based components and real network events.

Conclusions
In this paper, we propose a flexible handover management scheme in SDN-based mobile networks. Firstly, flows are classified into four classes considering QoS requirements in terms of loss and delay sensitiveness. Then, according to the flow classifications, the QoS-based differential handover procedure for each class can be provided by the interaction between the forwarding plane nodes and SDN controller. From the analytical results, compared to the conventional schemes which can only provide their own individual handover procedure (which can be too strict or too loose), the proposed scheme provides efficient network operations without any service degradation based on the flexible handover management according to the service characteristics. In future work, the proposed scheme will be validated to measure the practical benefits based on a virtualized network environment using OpenFlow-based components and real network events.