A Mobility Handover Decision Method Based on Multi-Topology

Abstract

With the emergence of new applications in mobile networks, users demand higher network stability and lower data transmission delays. When the network address of a mobile user changes, the data transmission path in the wired network may need to be switched to maintain service continuity. Traditional mobility support methods typically rely on a single switching path for all mobile data flows. However, if this path cannot meet the requirements of all the flows, it may lead to network congestion or a decline in user experience. To overcome this limitation, this paper proposes a mobility handover decision method based on multi-topology. It enables the dynamic allocation of mobile data flows across different switching paths within multiple logical topologies. The method models a multi-topology selection problem aimed at minimizing average packet transmission delay and packet loss rate, while considering network conditions and the Quality of Service (QoS) requirements for each flow. By solving the dual problem of the original optimization, a near-optimal solution is achieved. The proposed scheme and algorithm were implemented and tested using the Mininet network simulator. Results show that the proposed approach achieves low average packet transmission delay, low average packet loss rate, and high throughput, compared to traditional single-path switching methods and existing multipath routing methods.

1. Introduction

In mobile networks, with the development of network devices and the surge in network traffic, modern devices have combined multiple functions. A network device can provide various services simultaneously to a mobile user, resulting in multiple concurrent data flows between the server and the user. At the same time, the emergence of new applications has driven mobile users to demand higher quality of service (QoS). For example, real-time applications such as VoIP [1] and online gaming require low data transmission delays, as quick feedback is essential, and high delay can severely impact operation response. Similarly, live video streaming is sensitive to packet loss. A high packet loss rate will cause delays and audio-video desynchronization, significantly degrading the user experience.

This study focuses on mobility handover in wired networks, where data transmission paths may need to be switched to maintain service continuity when a mobile user’s network address changes. Unlike mobility handovers in wireless networks, which face challenges such as signal degradation and interference, mobility handovers in wired networks focus on efficient path switching. Over the years, various mobility support methods have been proposed to optimize the handover process, reduce overhead, and minimize delays. These methods typically select a single switching path for all mobile data flows. However, relying on a single switching path may fail to accommodate the diverse requirements of all mobile data flows. This limitation may result in network congestion or a decline in user experience.

Recent research has proposed using multiple switching paths by selecting different late-binding nodes for each flow [2]. However, this approach overlooks the potential path overlaps and varying delay requirements of data flow. It limits its effectiveness in complex network environments. To our knowledge, no other work has specifically addressed the dynamic allocation of mobile data flows across multiple switching paths. At the same time, some studies have explored multipath routing in non-mobility contexts. Many approaches suffer from long runtimes, making them unsuitable for mobility support scenarios that demand low handover delays. Some methods overlook important factors such as diverse QoS requirements, path overlap, and different packet loss rates across links. Their effectiveness may be limited in complex networks.

To address the issue of inadequate transmission quality caused by relying on a single switching path, this paper proposes a novel mobility handover decision method based on multi-topology (MHMT). The main contributions of this paper are as follows:

• We introduce a mobile communication system based on multi-topology and provide a detailed analysis of the dynamic allocation problem for mobile data flows. The problem is modeled as a multi-topology selection task aimed at minimizing both average packet transmission delay and average packet loss rate;
• We formulate the dual problem of the original optimization and propose an algorithm to solve it, incorporating the principles of the greedy algorithm. This method enables rapid path switching for mobility support. It addresses varying bandwidth and delay requirements of data flows and achieves a near-optimal solution;
• We implemented and tested the proposed MHMT method using the Mininet [3] network simulator. Simulation results show that MHMT achieves a near-optimal solution with significantly lower time overhead compared to the genetic algorithm, requiring only 7 milliseconds versus 4.7 s for 14 data flows. Compared to ECMP, random selection, and single-path methods, MHMT outperforms in terms of average packet transmission delay, QoS satisfaction rate, average packet loss rate, and throughput. Specifically, with 14 data flows, MHMT reduces average packet delay by 45%, packet loss rate by 66%, and increases throughput by 126% compared to ECMP.

The structure of this paper is as follows: Section 2 reviews existing research on mobility support and multipath routing. Section 3 presents the architecture of a mobile communication system and describes the mobility support process. Additionally, a multi-topology selection model is introduced. Section 4 provides a detailed description of the method and algorithm. In Section 5, experimental analysis is conducted, comparing the performance of MHMT with other methods. Finally, Section 6 offers a summary and outlook for future work.

2. Related Work

In this section, we review related work on mobility support methods and discuss research related to multipath routing.

2.1. Mobility Support Methods

Mobility support in wired networks maintains connectivity as users move between networks. Various methods have been proposed to manage IP mobility. Early solutions, such as Mobile IP (MIP) [4], retain a home IP address but suffer from triangular routing inefficiencies. Mobile IPv6 (MIPv6) [5] and Hierarchical Mobile IPv6 (HMIPv6) [6] introduce Home Agents (HA) and Mobility Anchor Points (MAPs) to reduce latency but still face path extension issues. Proxy Mobile IPv6 (PMIPv6) [7] shifts mobility management to the network layer using Local Mobile Anchors (LMA) and Mobile Access Gateways (MAG), but fixed anchors remain a limitation.

Information-Centric Networking (ICN) uses names instead of IP addresses for routing. Mobility support in ICN can be categorized into anchor-based and anchorless approaches. Anchor-based methods redirect requests through fixed nodes, as seen in the schemes by Hermans et al. [8], Zhang et al. [9], and Kim et al. [10]. However, anchor-based methods often result in triangular routing inefficiencies. They also face scalability issues. Anchorless approaches eliminate fixed anchors and dynamically switch paths based on producer movement. Examples include MAP-ME [11] and OPMSS [12], which optimize data paths effectively. However, these methods suffer from broadcast signaling overhead and topology-specific inefficiencies. Other advanced methods, including MobilityFirst [13] and those by Sun et al. [14], Gao et al. [15], and Azgin et al. [16], use unique identifiers and name resolution systems for seamless mobility but are less effective for low-latency scenarios.

These methods select a single switching path for all mobile data flows. However, relying on a single switching path may fail to accommodate the diverse requirements of all mobile data flows.

2.2. Multipath Routing in Non-Mobility Contexts

Multipath routing has been widely studied to enhance load balancing and resource utilization across networks. However, existing multipath routing methods face two main limitations for mobility support. First, their time consumption is too high, making them unsuitable for mobility scenarios that require minimal handover delays. Second, they do not consider the varying QoS requirements of data flows, which may result in path allocations that fail to meet specific QoS demands for each flow.

Multipath TCP (MPTCP) [17] is a transport layer solution that splits a single data flow into multiple subflows sent across different paths to optimize resource utilization. However, MPTCP suffers from packet reordering, which is time-consuming and therefore unsuitable for mobility scenarios. Routing layer solutions, such as ECMP (Equal-Cost Multi-Path) [18] and WCMP (Weighted-Cost Multi-Path) [19], distribute flows across multiple paths based on a hash of the source IP address. They avoid packet reordering. However, these approaches also do not consider the varying bandwidth or delay requirements of data flows, limiting their effectiveness. Other approaches focus on improving network throughput without specifically addressing QoS differentiation. Tague et al. [20] proposed a flow allocation algorithm based on jamming statistics to improve network throughput. Lee et al. [21] introduced a distributed secure multipath routing algorithm to optimize traffic allocation. To address varying QoS requirements, Pei et al. [22] proposed a dynamic Service Function Chaining (SFC) approach. However, this method has high time complexity, making it impractical for mobility scenarios. Kamboj et al. [23] developed a QoS-aware dynamic multipath routing scheme, but the method introduces significant delays due to packet reordering.

Multi-topology routing [24] is one approach to achieve multipath routing. Within a physical topology, several logical topologies can be generated. Each logical topology is a subset of the physical topology. This enables rapid path switching, which enhances flexibility and efficiency. The challenge in implementing multi-topology routing can be divided into two aspects.

The first focus is on establishing multi-topologies. Menth et al. [25] proposed enhancing network reliability through multi-topology routing, ensuring that there are backup topologies available to restore routing in case of link failures. RFC 4951 introduces relevant standards for OSPF multi-topology routing, indicating the construction of multi-topology routes by including MT-ID information in the TOS field of LSA during link discovery. Bhandari et al. [26] suggested using gray relational analysis (GRA) to address the issue. The goal is to select the optimal parent node based on multiple routing metrics. The weights of these metrics are determined by a standard deviation approach. These methods are all based on creating paths from scratch, which incurs significant computational overhead and is unsuitable for mobility scenarios.

The second focus is on allocating data flows across multiple paths. Demir et al. [27] proposed a multi-topology traffic optimization approach. This method assigns paths for delay-sensitive TT streams and AVB streams. It uses heuristic algorithms to find optimal solutions. Pop et al. [28] developed a model that considers worst-case delay analysis. This model accurately evaluates the timing characteristics of routing candidates. However, both methods suffer from high time complexity. Mehmood et al. [29] suggested a primary and backup path classification for critical and normal flows to improve throughput. However, this binary classification is overly simple, making it difficult to categorize various flows.

In summary, existing multi-topology routing methods are limited by high time complexity, insufficient attention to varying QoS requirements, and issues with path overlaps. Therefore, a new flow allocation algorithm is needed to improve efficiency.

3. System and Scenario Description

3.1. Architecture Overview

The MHMT method is based on the On-Site, Elastic, Autonomous Network (SEANet) [30]. It functions as an overlay network on top of the IP network, ensuring compatibility with IP. SEANet provides a local name mapping and resolution system (LNMRS), which maintains the mapping between the mobile user’s entity identifier (EID) and their current network address (NA). As illustrated in Figure 1, we consider a mobile communication system that includes a content server, switches, base stations (BSs), and mobile users. Additionally, LNMRS provides resolution services to switches with deterministic response delays. This system can collaborate with the 5G core network (5GC). The possible relationship between this system and the 5GC is also depicted. In 5G networks, the User Plane Function (UPF) manages user plane data forwarding. When a user switches to another UPF, its network address should be changed.

The black lines form the physical topology. The green lines represent one logical topology, and the red lines represent another. It can be seen that the green topology includes switches S1, S2, S4 and connections (S1, S2), (S1, S4), and (S2, S4), while the red topology includes switches S1, S3, S4 and connections (S1, S3) and (S3, S4). The content server connects to switch S1 through a wired connection, while the mobile user accesses the network through a base station.

Since this paper focuses on mobility support, it assumes that the connection setup and service requests have already been completed. The content server sends multiple data flows to the mobile user. Each packet in these flows contains a source EID (content identifier), a destination EID (mobile user identifier), and a destination NA (mobile user’s network address). Each data flow is uniquely identified by the combination of its source and destination EIDs. When the mobile user moves and its network address changes, the content server is unaware of this change. As a result, the network addresses in the packets do not change, leading to a failure in data transmission to the mobile user’s new location.

The switch can query the LNMRS to obtain the mobile user’s current network address using the destination EID. Each switch maintains a mobility management flow table, which consists of a set of mobility management entries. These entries store the source EID, destination EID, and the latest network address (NA), corresponding to the destination EID.

When a data packet arrives, the switch first looks up the mobility management flow table for a matching entry by comparing the source and destination EIDs. If a match is found, the switch replaces the outdated destination NA in the packet with the current destination NA. Then, it uses the Forwarding Information Base (FIB) to forward the packet. This procedure is called late-binding. If no matching entry is found, the switch directly forwards the packet according to the FIB. It is noted that if a switch belongs to multiple logical topologies, it will maintain multiple corresponding FIB tables.

We present the mobility support process as follows.

Step 0: Initially, the mobile user is located within the coverage area of BS1. The content server sends F data flows simultaneously to the mobile user across the physical topology. These flows are denoted as Flow 1, Flow 2, …, Flow F, and the transmission path is as follows: content server → S1 → S2 → UPF1 → BS1 → mobile user. The packets carry the source EID (content identifier), destination EID (mobile user identifier, EID0), and destination NA (mobile user’s network address, NA1). In addition, the packets also carry the corresponding sending rates and the transmission delay requirements for the content;

Step 1: When the mobile user moves into the coverage area of BS2, switch S2 can perceive this change through some mechanism, although the method of perception is not the focus of this study. The information includes the mobile user’s identifier (EID0), the identifiers of the requested content (EID1, EID2, …, EIDF), as well as the corresponding sending rates and the transmission delay requirements for each content;

Step 2: Switch S2 queries the LNMRS to obtain the current network address of the mobile user associated with EID0;

Step 3: Switch S2 receives the response from the LNMRS, obtaining the mobile user’s new network address, NA2;

Step 4: Switch S2, acting as a late-binding node, redirects packets intended for the user EID0 by modifying the destination NA from NA1 to NA2. This ensures that, even if other nodes have not completed the late-binding, the packets can be forwarded to the new address. At the same time, switch S2 generates a mobility announcement message that travels back along the original data transmission path to S1. This announcement message includes the following: EID0 and its new network address NA2, identifiers of the requested content (EID1, …, EIDF), data flow rates, and the transmission delay requirements for each content;

Step 5: Switch S1 receives the mobility announcement message and becomes aware of the user’s movement. Acting as a late-binding node, S1 redirects the data flows. Based on the current network conditions and the specific requirements of each data flow, S1 selects an appropriate logical topology for each data flow for subsequent transmission. If only a single switching path is allowed, the rerouted data flows follow the shortest path in the physical topology: content server → S1 → S4 → UPF2 → BS2 → mobile user. However, if multi-topology can be used, part of the data flows can be transmitted along content server → S1 → S4 → UPF2 → BS2 → mobile user (green topology), while another part can be transmitted along content server → S1 → S3 → S4 → UPF2 → BS2 → mobile user (red topology).

3.2. Problem Description and Formulation

In the context of multi-topology routing, as illustrated in Figure 2, diagram (a) represents the physical topology $G(V,E)$, where each link has a bandwidth of $c_e(e\in E)$. Diagrams (b), (c), and (d) represent three logical topologies generated from the physical topology. Each logical topology $G’(V’,E’)$ is a subset of the physical topology, meaning that $V’\subseteq V,E’\subseteq E$.

The content server is connected to Node B, while the mobile user accesses the network through Node A. The mobile user requests multiple content, resulting in $F$ data flows being transmitted from Node B to Node A. The data transmission follows a continuous flow model, which means the traffic flow is sent at a fixed rate. The sending rate for each data flow $f\left(f\in F\right)$ is denoted as $v_f$. When the mobile user moves from Node A to Node D, if data transmission continues to rely on the physical topology, a shortest path routing algorithm will reroute all data flows to follow the path B → C → D. If the bandwidth on the link (C, D) is insufficient, such that $c_{cd}<\sum _{f=1}^F{v}_f$, congestion will occur on the link (C, D), leading to an increased packet loss rate and a decline in user experience.

In a different scenario, if multi-topology routing is allowed, different delay requirements can be met for each content request. The maximum allowable delay for data flow $f$ is denoted as $D_f(f\in F)$. For real-time content, $D_f$ is relatively short, whereas for less time-sensitive content, such as files, $D_f$is comparatively longer. Initially, data transmission relies on logical topology T1. The content server is connected to Node B, while the mobile user accesses the network through Node A. The mobile user requests multiple content, resulting in $F$ data flows sent from Node B to Node A.

When the mobile user moves from Node A to Node D, if data transmission continues within logical topology T1, the shortest path routing algorithm will reroute all data flows through the path B → A → F → D. The transmission delay increases significantly, potentially exceeding the maximum allowable delay $D_f$ for some flows. This leads to a failure to meet QoS requirements, causing a decline in user experience.

When a user’s network address changes, the key challenge is selecting suitable topologies for each data flow. This can be formulated as a mathematical model, specifically a 0–1 integer programming problem.

Table 1. Summary of symbols.

Symbol	Description
$X_{ft}$	$\mathrm{Boolean}\mathrm{variable};X_{ft}=1$$\mathrm{if}\mathrm{flow}f$  $\mathrm{is}\mathrm{selected}\mathrm{for}\mathrm{forwarding}\mathrm{in}\mathrm{topology}t$$;\mathrm{otherwise},X_{ft}=0$
$X_{et}$	$\mathrm{Boolean}\mathrm{variable};X_{et}=1$ $\mathrm{if}\mathrm{link}e$ $\mathrm{is}\mathrm{included}\mathrm{in}\mathrm{the}\mathrm{shortest}\mathrm{path}\mathrm{from}\mathrm{the}\mathrm{source}\mathrm{node}\mathrm{to}\mathrm{the}\mathrm{new}\mathrm{access}\mathrm{node}\mathrm{within}\mathrm{topology}t$$;\mathrm{otherwise},X_{et}=0$ (input parameter)
$C_e$	$\mathrm{Bandwidth}\mathrm{of}\mathrm{link}e$ (input parameter)
$P_e$	$\mathrm{Packet}\mathrm{loss}\mathrm{rate}\mathrm{of}\mathrm{link}e$, in the range of 0–1 (input parameter)
$H_f$	$\mathrm{Hop}\mathrm{constraint}\mathrm{for}\mathrm{flow}f$ (mapping delay constraint to hop constraint) (input parameter)
$V_f$	$\mathrm{Required}\mathrm{bandwidth}\mathrm{for}\mathrm{flow}f$ $(\mathrm{sending}\mathrm{rate}\mathrm{of}\mathrm{flow}f$) (input parameter)
$h_{ft}$	$\mathrm{Hop}\mathrm{count}\mathrm{for}\mathrm{the}\mathrm{packet}\mathrm{in}\mathrm{flow}f$ $\mathrm{along}\mathrm{the}\mathrm{shortest}\mathrm{path}\mathrm{in}\mathrm{topology}t$ (input parameter)
$T$	Total number of topologies (input parameter)
$F$	Total number of flows to be allocated (input parameter)
$P_f$	$\mathrm{Total}\mathrm{packet}\mathrm{loss}\mathrm{rate}\mathrm{for}\mathrm{flow}f$

below summarizes the main symbols used in this paper and their descriptions.

The objective of this problem is to minimize both the average packet transmission delay and the average packet loss rate for the data flows, which constitutes a multi-objective optimization problem.

The transmission delay experienced by a packet consists of the following components [31].

$$T_{trans}=T_{prop}+T_{process}+T_{queue}$$

(1)

Propagation Delay ($T_{prop}$): The time it takes for a packet to propagate through the transmission medium.

Processing Delay ($T_{process}$): The time required for network devices, such as switches, to process the packet.

Queuing Delay ($T_{queue}$): When multiple packets are waiting to be processed by a network device, they enter a queue. Queuing delay is the time packets spend waiting in that queue.

Since the switch processing delay is typically in the microsecond range [32], it can be considered negligible. However, queuing delays depend on congestion levels, making it unpredictable. In our model, link bandwidth is a constraint to avoid congestion. Propagation delays mainly depend on the physical medium length and signal propagation speed. For simplicity, our model assumes that delays across links are uniform, and the packet transmission delay is solely dependent on the hop count of the path. Unlike long-term network resource allocation, mobility handover is a brief event. It occurs within tens of milliseconds. During such a short period, it is reasonable to assume that network conditions remain constant.

Therefore, to minimize the average packet transmission delay for the data flows, the problem can be reformulated as minimizing the average hop count per packet for all flows.

$$\overline{D}={\displaystyle \frac{{\sum }_{f=1}^F{\sum }_{t=1}^T{X}_{ft}{h}_{ft}}{F}}$$

(2)

The average packet loss rate can be expressed as follows:

$$P_f={\sum }_{t=1}^T\left(X_{ft}\left(1-{\prod }_{e=1}^E\left(1-X_{et}{P}_e\right)\right)\right)$$

(3)

The average packet loss rate for all flows is as follows:

$$\overline{P}={\displaystyle \frac{{\sum }_{f=1}^F{P}_f}{F}}={\displaystyle \frac{{\sum }_{t=1}^T\left(X_{ft}\left(1-{\prod }_{e=1}^E\left(1-X_{et}{P}_e\right)\right)\right)}{F}}$$

(4)

Constraint 1:

$${\sum }_{t=1}^T{X}_{ft}=1,\forall f\in \left[1,F\right]$$

(5)

$$X_{ft}=\left\{\mathrm{0,1}\right\},\forall f\in \left[1,F\right]\forall t\in \left[1,T\right]$$

(6)

That is, each flow can only be allocated to one topology.

Constraint 2:

$${\sum }_{f=1}^F{\sum }_{t=1}^T{X}_{ft}{X}_{et}{V}_f\le C_e,\hspace{1em}\forall e\in \left[1,E\right]$$

(7)

That is, the total sending rate of data flows on each link cannot exceed its bandwidth, in order to avoid congestion.

Constraint 3:

$$\begin{array}{c}{\sum }_{t=1}^T{X}_{ft}{h}_{ft}\le H_f,\forall f\in \left[1,F\right]\end{array}$$

(8)

The hop count in the selected topology for each flow must not exceed its specified hop constraint. We translate the user’s low delay requirement for specific content into a hop constraint for the path within the selected topology for that data flow.

Since there are two optimization objectives that may conflict with each other, a common way to address such issues is by using the weighting method. It combines multiple objective functions into a single one, often by calculating a weighted sum. Another alternative is the Pareto optimization method [33], which aims to find a set of Pareto optimal solutions. A pareto optimal solution is one in which no other solution can improve all objectives simultaneously. However, this yields a set of solutions, while we require a unique solution in. Therefore, we apply the weighting method to our problem. First, we normalize the two objective functions, respectively:

$$D^{\prime }\left(x\right)={\displaystyle \frac{D\left(x\right)-D_{min}}{D_{max}-D_{min}}}$$

(9)

$$P^{\prime }\left(x\right)={\displaystyle \frac{P\left(x\right)-P_{min}}{P_{max}-P_{min}}}$$

(10)

Thus, the objective function can be written as follows:

$$OPT=w_1\overline{D^{\prime }}+w_2\overline{P^{\prime }}$$

(11)

where

$$w_1+w_2=1$$

(12)

4. Method and Algorithms

The problem has been modeled as a 0/1 integer programming problem with multiple constraints. Existing algorithms for solving such problems can be divided into two categories: The first category includes branch-and-bound. It has a time complexity of $O\left(2^n\right)$, where $n$ is the number of variables. Another method is dynamic programming. It has a time complexity of $O\left(n^k\right)$, where $k$ is the number of dimensions. The second category includes various heuristic algorithms. These algorithms typically do not have explicit time complexity bounds, and their convergence speed and solution quality vary significantly depending on their parameter settings. Due to the strict requirements for minimal handover delay in mobility support scenarios, the problem must be addressed with a solution that has low time complexity.

4.1. The Dual Problem of the Original Problem

In optimization theory, the principle of duality suggests that an optimization problem can be viewed from two perspectives: the “primal problem” and the “dual problem”. The solution to the dual problem provides a lower bound for the primal problem (assuming it is a minimization problem) [34]. In this work, we analyze the topology selection problem from the perspective of the dual problem.

Dual problem objective:

$$MaximizeW={\sum }_{f=1}^F{\alpha }_f-C_e^T\beta -H_f^T\gamma$$

(13)

Constraint:

$${\alpha }_f-{\left({\sum }_{f=1}^F{\sum }_{t=1}^T{X}_{et}{V}_f\right)}^T\beta -{\left({\sum }_{t=1}^T{h}_{ft}\right)}^T\gamma \le {\displaystyle \frac{w_1{h}_{ft}+w_2\left(1-{\prod }_{e=1}^E\left(1-X_{et}{P}_e\right)\right)}{F}},$$

(14)

$$\forall f\in \left[1,F\right],\forall t\in \left[1,T\right]$$

where ${\alpha }_f$, $\beta$, and $\gamma$ are dual variables. $C_e^T$ and $H_f^T$ are the transposed matrices of $C_e$ and $H_f$, respectively. By constructing the dual problem, the issue can be transformed into maximizing the value of the dual variables, while satisfying constraints for each $f$ and $t$.

4.2. Algorithm Description and Complexity Analysis

From the dual problem’s objective function, it can be found that to minimize average packet delay and packet loss rate while maximizing the value of the dual problem objective, the second and third terms should be minimized. This involves reducing the bandwidth utilization of topologies with high packet loss rates and hop counts, while increasing the bandwidth utilization of topologies with lower packet loss rates and hop counts. Additionally, for each data flow, we assign the topology with the higher hop count that satisfies the flow’s hop constraint.

Guided by this principle, we developed MHMT. The detailed description of the MHMT algorithm is as Algorithm 1:

Algorithm 1 Multi-topology selection algorithm

1: $\mathbf{Input}\mathbf{:}\mathrm{Flows},\mathrm{Topos},\mathrm{Network}\left(\mathrm{A}\mathrm{List}\mathrm{of}\mathrm{Links}\right),\mathrm{Weights}{w}_1$$\mathrm{and}{w}_2$   2: $\mathbf{Output}\mathbf{:}\mathrm{Flows}\mathrm{with}\mathrm{Topology}\mathrm{assigned}$   3: $\mathbf{Main}\mathbf{Program}\mathbf{:}$   4: $\mathbf{for}topo$$\mathbf{in}\mathrm{Topos}\mathbf{do}$

5: ${topo}_{cost}\leftarrow w_1{\displaystyle \frac{h\left(topo\right)-h_{min}}{h_{max}-h_{min}}}+w_2{\displaystyle \frac{P\left(topo\right)-P_{min}}{P_{max}-P_{min}}}$

6: $\mathbf{end}\mathbf{for}$   7: $\mathbf{for}topo$$\mathbf{in}\mathrm{sort}(\mathrm{Topos},\mathrm{key}={topo}_{cost}$$)\mathbf{do}$   8: $\mathbf{for}flow$$\mathbf{in}\mathrm{sort}(\mathrm{Flows},\mathrm{key}=flow.\mathrm{m}\mathrm{a}\mathrm{x}\_hops$$)\mathbf{do}$   9: $\mathbf{if}\mathrm{all}(flow.\mathrm{m}\mathrm{a}\mathrm{x}\_hops$$<topo.hops$$\mathrm{for}topo$$\mathrm{in}\mathrm{other}\mathrm{Topos})\mathbf{then}$ 10: $\mathrm{allocate}\text{\_}\mathrm{flow}(flow$$,topo$$,flow.lock=True$$)$ 11: $\mathbf{end}\mathbf{if}$ 12: $\mathbf{end}\mathbf{for}$ 13: $\mathbf{for}flow$$\mathbf{in}\mathrm{sort}(\mathrm{remaining}\mathrm{Flows},\mathrm{key}=flow.rate$$)\mathbf{do}$ 14: $\mathrm{allocate}\text{\_}\mathrm{flow}(flow$$,topo$$)$ 15: $\mathbf{end}\mathbf{for}$ 16: $\mathbf{end}\mathbf{for}$ 17: $\mathbf{for}flow$$\mathbf{in}\mathrm{sort}(\mathrm{remaining}\mathrm{Flows},\mathrm{key}=flow.rate$$,\mathrm{ascending}=\mathrm{False})\mathbf{do}$ 18: $t\leftarrow$$\mathrm{find}\text{\_}\min \text{\_}\mathrm{available}\text{\_}\mathrm{bandwidth}\text{\_}\mathrm{topo}\left(\mathrm{Topos}\right)$ 19: ${Bw}_t\leftarrow$$t.available\_bandwidth$ 20: $f$$\leftarrow$$\mathrm{find}\text{\_}\mathrm{argmin}\text{\_}\mathrm{flow}(flow$$\mathrm{in}\mathrm{Flows}\mathrm{if}flow.topo$$=t$$)$ 21: ${argmin}_f({Bw}_t+V_f-flow.rate)$ 22: $s.t.{Bw}_t+V_f-flow.rate>0,f.lock=False$ 23: $\mathrm{replace}\text{\_}\mathrm{flow}(\mathrm{flow}\text{\_}\mathrm{in}=flow$$,\mathrm{flow}\text{\_}\mathrm{out}=f)$ 24: $\mathbf{end}\mathbf{for}$ 25: $\mathbf{for}flow$$\mathbf{in}\mathrm{replaced}\mathrm{Flows}\mathbf{do}$ 26: $t\leftarrow$$\mathrm{find}\text{\_}\min \text{\_}\mathrm{available}\text{\_}\mathrm{bandwidth}\text{\_}\mathrm{topo}\left(\mathrm{Topos}\right)$ 27: ${Bw}_t\leftarrow$$t.available\_bandwidth$ 28: ${argmin}_t\left({Bw}_t\right)$ 29: $s.t.{Bw}_t-flow.rate>0$ 30: $\mathrm{allocate}\text{\_}\mathrm{flow}(flow$$,t)$ 31: $\mathbf{end}\mathbf{for}$ 32: $\mathbf{for}flow$$\mathbf{in}\mathrm{remaining}\mathrm{Flows}\mathbf{do}$ 33: $t\leftarrow$$\mathrm{find}\text{\_}\mathrm{argmin}\text{\_}\mathrm{topo}\left(\mathrm{Topos}\right)$ 34: ${argmin}_t\left({\sum }_{f=1}^F{X}_{ft}\right)$ 35: $\mathrm{allocate}\text{\_}\mathrm{flow}(flow$$,t$) 36:   end for 37:   Return Flows

In the first phase of the algorithm, the goal is to allocate as many flows as possible to topologies with lower costs to maximize their utilization, which corresponds to reducing the second term in the dual problem’s objective. During this allocation process, flows for which no other topology can meet the hop constraint are selected and locked, preventing further reallocation. This step helps minimize the third term in the dual problem’s objective. The remaining flows are then prioritized based on smaller sending rates, which further increases the bandwidth utilization of the lower-cost topologies.

The second phase focuses on minimizing fragmented resource space by making strategic replacements. Flows with smaller sending rates are prioritized for replacement, thereby increasing the possibility of successfully finding suitable topologies for them afterwards.

In the third phase, the remaining flows are allocated to the topology with the fewest existing data flows. This approach helps to minimize the impact on other data flows and prevent large-scale congestion caused by the addition of remaining flows.

The overall time complexity of the algorithm is $O$($F\times T)$, where $F$ is the number of data flows and $T$ is the number of logical topologies. Based on static multi-topology routing, the number of topologies $T$ is a constant, so the time complexity is proportional to $F$.

5. Evaluation

5.1. Simulation Setup

This section presents a series of experiments aimed at evaluating the performance of MHMT. Five metrics are used to assess the performance: average packet transmission delay, QoS satisfaction rate, average packet loss rate, throughput, and handover delay. We developed MHMT and compared it with three multi-topology selection methods for path switching: the ECMP algorithm, a random selection method, and a genetic algorithm [35]. The solution provided by the genetic algorithm is treated as a near-optimal solution. ECMP serves as the baseline method for switching across multiple paths. Additionally, we implemented a single-path switching method as another baseline. This single-path approach selects the shortest path from the content server to the new destination node. The experimental platform is built on an Ubuntu 20.04 system. This platform includes Mininet 2.3.0 [3], Open vSwitch 2.17.9, and Ryu 4.34 [36]. Mininet is a network simulator that creates a virtual network of hosts, switches, and links on a single machine. Unlike other network simulators such as OMNeT++ [37] and NS-3 [38], Mininet transmits real data packets. It is widely used for testing software-defined networking (SDN). We repeated each set of experiments three times and took the average of the results.

5.1.1. Network Parameters

Network topologies typically include bus, star, tree, ring, and mesh structures. Since our study assumes multiple paths between the same node pairs, we selected mesh networks as the experimental topology. As shown in Figure 3, We created a random topology consisting of eight nodes and eleven links.

Based on the physical topology, five logical topologies were then randomly generated, as shown in Figure 4 below:

The packet loss rate for each link is set to a range between 0.05 and 0.1, uniformly distributed, and the bandwidth for each link is set to 12 Mbps. The packet queue size is set to five packets. The transmission delay for each link is set to 5 milliseconds. Host H1 is connected to switch S1, simulating the content server. Host H3 is connected to switch S3, simulating the mobile user before moving, and host H2 is connected to switch S2, simulating the mobile user after moving. H3 can send a mobility message to S3 to trigger the mobility management process. The message includes the mobile user’s identifier (EID0), its new network address (NA2, the IP address of H2), the requested content identifiers (EID1, …, EIDF), as well as the sending rate of each content and transmission delay requirements (hop constraints) for each content.

Initially, the content server sends multiple data flows to the mobile user via S1 and S3. After 1 s, the mobility management process is triggered by a mobility message sent by H3. Among the five logical topologies, the paths from S1 to S2 are as follows: (S1-S3-S2), (S1-S4-S2), (S1-S4-S5-S2), (S1-S8-S4-S2), and (S1-S7-S6-S5-S2), with hop counts of 2, 2, 3, 3, and 4, respectively.

5.1.2. Flow Parameters

We simulated situations where a mobile user requests varying amounts of content by generating different numbers of data flows. Each data flow has a sending rate uniformly distributed between 1.6 Mbps and 3.2 Mbps, equivalent to 200 to 400 packets per second, with each packet being 1000 bytes in size. The sending rate represents the bandwidth requirement of the flow. Additionally, each data flow is assigned a hop constraint, which specifies the maximum number of hops allowed in its transmission path. These hop constraints are uniformly distributed between 2 and 4, considering only integer values. Data flows with smaller hop constraints (e.g., hop_constraint = 2) are regarded as latency-sensitive applications, such as VoIP, because their requirements demand shorter paths to minimize delay. In this way, different QoS-sensitive applications can be characterized by varying data flow parameters. Each data flow is randomly generated and independent of each other. The parameters for the generated data flows are shown in

Table 2. Flows’ parameter.

Flow Number	Parameters
$6$	Flow(1,2.4,3), Flow(2,1.6,4), Flow(3,3.2,2), Flow(4,1.6,3), Flow(5,2.4,4), Flow(6,3.2,4)
$8$	Flow(1,1.6,4), Flow(2,2.4,4), Flow(3,2.4,3), Flow(4,3.2,2), Flow(5,2.4,4), Flow(6,2.4,3), Flow(7,1.6,4), Flow(8,3.2,4)
10	Flow(1,3.2,3), Flow(2,3.2,4), Flow(3,2.4,3), Flow(4,1.6,4), Flow(5,3.2,4), Flow(6,1.6,4), Flow(7,1.6,3), Flow(8,1.6,3), Flow(9,3.2,3), Flow(10,3.2,4)
12	Flow(1,1.6,2), Flow(2,2.4,2), Flow(3,2.4,4), Flow(4,3.2,2), Flow(5,1.6,4), Flow(6,2.4,4), Flow(7,1.6,4), Flow(8,1.6,2), Flow(9,3.2,3), Flow(10,1.6,4), Flow(11,2.4,4), Flow(12,3.2,4)
14	Flow(1,1.6,3), Flow(2,2.4,4), Flow(3,2.4,4), Flow(4,1.6,3), Flow(5,3.2,4), Flow(6,2.4,4), Flow(7,3.2,4), Flow(8,3.2,3), Flow(9,3.2,2), Flow(10,1.6,4), Flow(11,1.6,2), Flow(12,3.2,4), Flow(13,2.4,2), Flow(14,1.6,4)

, using the format: Flow (content_identifier, sending_rate, hop_constraint).

Because the data flows have requirements for transmission delay, which is a constraint in our modeling, a higher weight is assigned to the packet loss rate for the two optimization objectives. In the MHMT algorithm, $w_1=0.7$ and $w_2=0.3$. In the comparative algorithm, the parameters for the genetic algorithm are set as follows: the number of generations is 300, the population size is 10, and both crossover and mutation points are generated randomly. The selection algorithm for the next generation uses roulette wheel selection. The ECMP method employs modulo hashing, where the selected topology $T\left(f\right)=\left(fmodt\right)$, with $t$ representing the number of topologies with the shortest paths.

5.2. Simulation Results and Analyses

5.2.1. Average Packet Transmission Delay

By capturing packets from the ports of H1 and H2, we obtained the data packets sent by the content server and received by the mobile user after it moved. We calculated the time differences for all packets within each data flow to obtain the average packet transmission delay for each flow. Dividing by the number of data flows gives us the overall average packet transmission delay. Figure 5 shows the comparison of average packet transmission delays of different algorithms against the number of content requested by a mobile user.

When the number of flows is six and eight, all methods, including MHMT, GENE, ECMP, and RANDOM, show comparable average packet delays, as there are sufficient bandwidth resources to meet the demands. The SINGLE method, however, already starts with a higher delay at six flows. Under the experimental setup, both Topology 1 and Topology 2 have a shortest path length of 3, allowing the ECMP method to distribute data flows evenly between these two topologies without causing congestion. Both MHMT and GENE make topology selections based on packet loss rates and path lengths, while RANDOM selects topologies arbitrarily, which leads to higher delays. SINGLE exhibits the highest delay due to its reliance on a single path. The bandwidth of this single path is insufficient to accommodate all flows, leading to congestion and a significant increase in packet delay.

When the number of flows increases to 10 and 12, the performance of MHMT and GENE remains relatively stable, with a slight increase in average packet delay as they allocate some data flows to topologies with longer paths. In contrast, ECMP begins to experience congestion due to its allocation of flows to only Topology 1 and Topology 2, resulting in a sharp increase in packet delay. RANDOM also suffers from increased delays due to the longer paths it sometimes selects. The average packet delay of SINGLE peaks at around 45 ms and does not continue to increase, because the queue size reaches its limit and extra packets are directly dropped.

At 14 flows, network resources become insufficient to fully meet the demands of all data flows. As a result, all methods show increased average packet delays, but the extent of the increase varies. MHMT allocates the remaining data flows to the topology with the least flows, thereby minimizing congestion and maintaining lower average delays compared to the other methods. The GENE algorithm selects allocation schemes that minimize its objective function. ECMP continues with its selection, leading to severe congestion and the highest packet delays. RANDOM performs better than ECMP but still has high delays due to inefficient path selection.

5.2.2. QoS Satisfaction Rate

Figure 6 illustrates the QoS satisfaction rate for each algorithm as the number of data flows increases. The QoS satisfaction rate represents the percentage of data flows that meet the specified quality of service requirements, such as bandwidth and delay. Initially, both MHMT and GENE maintain high QoS satisfaction rates when the number of flows is low. As the number of flows increases beyond 12, the available bandwidth becomes insufficient, causing a decline in QoS satisfaction. ECMP experiences a rapid decline in QoS satisfaction as the number of flows exceeds 10, since it always distributes flows equally across Topologies 1 and 2 without considering bandwidth constraints. This results in significant congestion and a sharp reduction in performance. The RANDOM method, due to its arbitrary path selection, exhibits erratic QoS satisfaction rates. It occasionally performs well but often fails to select optimal paths, leading to increased congestion and inconsistent performance. SINGLE consistently shows the lowest QoS satisfaction rate across all flow counts. This is because SINGLE relies on a single path, which cannot accommodate all the flows, resulting in persistent congestion and poor performance.

Overall, MHMT stands out by achieving the most stable and highest QoS satisfaction rates as the traffic increases. This highlights its ability to allocate flows effectively and maintain service quality under varying network conditions.

5.2.3. Average Packet Loss Rate

The packet loss rate for each data flow is determined by dividing the number of packets received by H2 by the total number of packets sent by H1. The overall average packet loss rate is then obtained by averaging these rates across all data flows. Figure 7 presents the changes in average packet loss rates for the five algorithms as the number of data flows increases.

As the number of data flows increases, the performances of the MHMT and GENE algorithms are similar, with both exhibiting a gradual rise in packet loss rates. Specifically, MHMT’s packet loss rate increases from 0.119 to 0.166. In contrast, the ECMP algorithm continues to allocate all data flows to Topology 1 and Topology 2, which works well when the flow count is small. However, as the number of data flows reaches 10, congestion starts to occur, significantly raising the packet loss rate. When the flow count reaches 14, the packet loss rate for ECMP peaks at 50%, which is three times that of MHMT. The RANDOM and SINGLE algorithms show even worse performance. SINGLE consistently exhibits the highest packet loss rates across all flow counts due to relying on a single path that cannot handle all the flows. The RANDOM algorithm’s packet loss rate varies widely as it arbitrarily selects topologies.

Overall, MHMT manages to consistently achieve low packet loss rates due to its effective topology selection strategy that prioritizes both QoS and bandwidth availability

5.2.4. Handover Delay Analysis

The handover delay is calculated by comparing the time difference between the last packet received by H3 and the first packet received by H2. Since the mobility message includes the mobile user’s new network address, the resolution query process is omitted. The handover delay primarily consists of the communication delay between the controller and the switches, as well as the runtime of the multi-topology selection algorithm. Figure 8 shows the variation in handover delays for different algorithms as the number of data flows increases.

The genetic algorithm’s long runtime results in handover delays of several seconds, significantly longer compared to the other methods. As seen in Figure 8, the handover delays for ECMP and RANDOM do not change significantly as the number of flows increases, due to their time complexity of $O\left(F\right)$. Meanwhile, the handover delay of the MHMT algorithm shows a slight increase but remains below 20 milliseconds, even as the number of data flows grows from 6 to 14. Theoretically, the time complexity of MHMT is $O(F\times T)$. When the number of topologies $T$ is fixed, the time complexity increases linearly with the number of data flows $F$. Therefore, MHMT exhibits a similar handover delay to ECMP and RANDOM.

5.2.5. Algorithm Runtime Analysis

When evaluating the handover delay, we should consider factors such as packet size and transmission rate. With a packet size of 1000 bytes and a transmission rate ranging from 1.6 to 3.2 Mbps, the time interval for packet transmission falls between 2.5 and 5 milliseconds. A specific packet loss rate was introduced on each link, meaning that if the first packet sent after the user moves is lost, the calculated delay may overestimate the actual handover delay. To more accurately assess the runtime of the proposed algorithm and its relationship with the number of data flows, the runtime was measured separately, as shown in Figure 9.

The runtime of the MHMT algorithm increases linearly with the number of data flows. Since MHMT has a time complexity of $O(F\times T)$, where $F$ is the number of data flows and $T$ is the number of logical topologies. The complexity increases linearly with the number of data flows. This low complexity, compared to most heuristic algorithms, makes MHMT suitable for mobility scenarios with strict handover delay requirements.

5.2.6. Throughput

Figure 10 compares the throughput (in KB/s) of five methods as the number of flows increases from 6 to 14. MHMT consistently achieves the highest throughput, except at six flows where it is slightly lower than GENE. At 14 flows, it peaks at 2898.165 KB/s, indicating its robustness under high traffic loads. This throughput is 66% higher than ECMP and 128% higher than SINGLE.

6. Discussion

This study introduces a novel mobility handover decision method based on multi-topology (MHMT). It is designed to improve QoS satisfaction during mobility handovers in wired networks. Our results show that MHMT outperforms traditional single-path methods and existing multipath routing approaches like ECMP and random selection.

MHMT outperforms in terms of average packet transmission delay, QoS satisfaction rate, average packet loss rate, and throughput. MHMT significantly enhances QoS satisfaction by dynamically allocating data flows across multiple topologies. This also helps reduce packet loss and increase throughput by avoiding congestion. Furthermore, MHMT enables rapid path switching without the need to recalculate routes during the mobility handover. Its low computational complexity ensures that it can achieve low, acceptable handover delays. These features make MHMT a flexible and robust solution for mobility scenarios.

Existing multipath routing methods either introduce delays due to packet reordering and rerouting or fail to account for varying QoS requirements. MHMT dynamically selects paths based on network conditions and QoS requirements. This ensures better performance during handovers.

Table 3. Comparison of MHMT with existing multipath routing methods.

Method	Strength	QoS-Aware	Complexity
MHMT (Proposed)	Rapid path switching, low complexity, High QoS satisfaction	Yes	$\mathrm{Low},O(F\times T)$
MPTCP	Optimizes resource utilization	No	High, due to packet reordering
ECMP	Simple, well-established	No	$\mathrm{Low},O\left(F\right)$
WCMP	Better load balancing compared to ECMP	No	$\mathrm{Low},O(F\times T)$
Tague et al.	Improves throughput under heavy congestion	No	$\mathrm{High},O(F\times T^3)$
Lee et al.	Optimizes traffic allocation	No	High, due to the recomputing of routing
Pei et al. (Dynamic SFC)	Addresses varying QoS for each flow	Yes	High, due to the recomputing of routing
Kamboj et al.	Addresses varying QoS for each subflow	Yes	High, due to packet reordering

shows a comparison of MHMT with existing multipath routing methods.

In conclusion, MHMT offers a promising solution to the challenges of mobility handover in wired networks. Integrating MHMT with 5G networks would help extend MHMT’s capabilities. It provides the potential to address the growing demands of next-generation networks. However, the performance of MHMT is closely dependent on the structure of the logical topologies. Further research is needed to explore how to design more efficient multi-topology. Additionally, our method assumes that network link quality and the traffic in the network remain constant during the handover process. However, in real-world networks, these parameters can change rapidly, even within tens of milliseconds. If there are significant traffic fluctuations during the brief handover period, it could lead to inaccuracies in the input parameters for MHMT. This highlights the need for real-time monitoring with higher frequency to track such dynamic changes and provide timely feedback to MHMT. This represents an area for future research and development.

7. Conclusions

This paper proposes a novel mobility handover decision method based on multi-topology (MHMT) to address the challenge of maintaining the quality of services after mobility handovers. By dynamically allocating data flows across multiple logical topologies, MHMT effectively overcomes the limitations of single-path switching methods. The problem is modeled as an optimization task aimed at minimizing average packet transmission delay and average packet loss rate, while meeting diverse bandwidth and delay requirements. Simulation results show that MHMT outperforms traditional methods (including single-path switching, ECMP, and random selection) across key metrics like average packet transmission delay, QoS satisfaction rate, packet loss rate, and throughput. MHMT achieves a near-optimal solution, while significantly reducing handover delay compared to the genetic algorithm.

In conclusion, this study introduces a new perspective on mobility handover in wired networks. Future research could focus on dynamically adjusting multi-topology routing based on traffic variations to achieve higher levels of automation and intelligence.