Enhancing SDVN Performance via Policy-Driven Lightweight Control-Plane Resizing Strategies

Enhancing SDVN Performance via Policy-Driven Lightweight Control-Plane Resizing Strategies Muhammad Zain Ul Abideen, Prathapasinghe Dharmawansa, Nurul Huda Mahmood, and Chafika Benzaı̈d

arXiv:2609.14107v1 [cs.NI] 12 Sep 2026

Centre for Wireless Communications, University of Oulu, Finland. Email: {muhammad.zainulabideen, prathapasinghe.kaluwadevage, nurulhuda.mahmood, chafika.benzaid}@oulu.fi. Abstract—Software-defined vehicular networks (SDVNs) under high mobility and fluctuating traffic demand offer programmable, centralized control for latency-sensitive intelligent transportation systems. However, data-plane Quality of Service (QoS) is often degraded by control-plane overload due to frequent handovers and dense vehicle-to-infrastructure (V2I) contacts. To address this, we propose two lightweight mechanisms for lowlatency control-plane resizing in multi-controller SDVNs. The first - Control-plane Centric Control-plane Resizing Mechanism proactively offloads roadside units from overloaded controllers to underloaded or idle ones when a predefined load threshold is exceeded, preventing prolonged overload with minimal decision latency. The second - Data-plane Centric Control-plane Resizing Mechanism - triggers resizing based on observable data-plane QoS degradation, such as average round-trip time exceeding a QoS threshold, aligning control-plane adaptation with V2I service experience. Both mechanisms are implemented and evaluated on Mininet-WiFi emulation testbeds with realistic worst-case vehicles mobility. Compared to fixed single-controller and static multi-controller benchmarks, the proposed algorithms significantly reduce end-to-end delay and packet loss while improving load balancing rate. Index Terms—Control-plane load, control-plane resizing, Mininet-WiFi, quality of service, RSU offloading, SDVN

I. I NTRODUCTION Intelligent Transportation Systems (ITS) are vital for Beyond-5G and 6G ecosystems, supporting applications like cooperative driving and real-time infotainment [1]. These applications require strict Quality of Service (QoS) criteria, including low end-to-end (E2E) latency, minimal packet loss, and service continuity under high mobility. As vehicles dynamically connect to roadside units (RSU), the network must maintain reliable data-plane performance while adapting to fluctuating traffic and frequent handovers [2]. Softwaredefined vehicular networks (SDVN) can manage vehicular networks’ complexity by separating the control-plane from the data-plane [3]. In SDVN systems, RSUs provide vehicleto-infrastructure (V2I) connectivity, while SDN controllers manage mobility, flow setup, and policy enforcement [4]. However, as vehicle density and mobility increase, the controlplane can become a performance bottleneck due to delays in processing forwarding rules, increased latency in installing flow rules at RSUs, and congestion during frequent vehicle handovers, resulting in poor data-plane QoS. Despite the flexibility of SDVN architectures, highly dynamic vehicular environments pose challenges to control-plane scalability and QoS assurance [5]. Rapid topology changes, frequent handovers, uneven vehicle density, and intermittent wireless connectivity impose heavy and time-varying processing demands on SDN controllers [6], often leading to flow installation delays, packet loss, and degraded E2E performance. While multi-controller architectures improve scalability and fault tolerance, they can introduce controller load imbalance

due to mobility-driven traffic skew, undermining routing efficiency and service continuity [7]. Load balancing and scalability in SDNs have been addressed in different ways. Examples include fractional switch migration for fine-grained load redistribution [8], joint controller placement and routing optimization via hybrid deep reinforcement learning and graph neural networks [9], and programmable data-plane offloading with adaptive multicontroller coordination [10]. However, these approaches predominantly rely on control-plane-centric metrics, such as controller utilization, flow arrival rates, or synchronization overhead, and assume static or semi-static topologies. Such assumptions are poorly suited for SDVNs, where data-plane QoS degradation manifests itself as an increased round trip time (RTT) and packet loss [11]. Moreover, learning-based SDVN solutions often incur high training time [12]. These limitations motivate the need for lightweight, mobility-aware controlplane resizing mechanisms that jointly consider controller load dynamics and data-plane QoS degradation in vehicular environments. This paper introduces two lightweight, policy-based controlplane resizing mechanisms. The first, Control-plane Centric Control-plane Resizing Mechanism (CCCRM), proactively offloads RSUs based on controller load thresholds to balance the control-plane load. The second, Data-plane Centric Controlplane Resizing Mechanism (DCCRM), reactively resizes the control-plane in response to data-plane QoS degradation. CCCRM and DCCRM are complementary data-plane QoSdriven adaptation mechanisms that alleviate mobility-induced control-plane congestion and improve overall SDVN stability. Both mechanisms are extensively evaluated using the MininetWiFi emulation platform [13], demonstrating improvements in E2E delay, packet loss, and load balancing rate compared to benchmark algorithms. The rest of the paper is organized as follows: Section II presents the system model design. The two proposed mechanisms are detailed in Section III. Section IV highlights the experiment and the results of the proposed mechanisms. Section V presents the conclusion of our study. II. S YSTEM M ODEL D ESIGN We consider a multi-controller SDVN composed of three logical layers: the application-plane, control-plane, and dataplane. Let C = {C1 , C2 , . . . , CNc } denote the set of SDN controllers, R = {R1 , R2 , . . . , RNr } the set of RSUs, and V = {V1 , V2 , . . . , VNv } the set of mobile vehicles, where Nc , Nr , and Nv indicate the number of controllers, RSUs, and vehicles, respectively. The destination vehicle shown in Fig. 1 represents a static external endpoint located outside the SDVN access network. It is connected through the wired

core via a vehicular cloud and serves solely as a traffic sink for E2E data-plane performance evaluation. Mobile vehicles do not communicate with each other; however, each vehicle generates traffic only toward the fixed destination vehicle. This modeling choice isolates the impact of vehicular mobility, RSU handovers, and controller-RSU interactions on controlplane load and data-plane QoS, without introducing additional complexity from vehicle-to-vehicle communication or multidestination traffic patterns. A. Problem Statement All RSUs may initially be assigned to a single controller (such as C1 ). Vehicles move across the RSU coverage areas arbitrarily with various speeds. Each vehicle connects to the closest RSU within its communication range [14]. As vehicles move, changes in signal strength trigger RSU handovers, resulting in dynamic data-plane connectivity and increased control-plane signaling. The dynamic imbalance of the controller load, which results from both static RSU-controller mappings and time-varying RSU-vehicle associations, is the main issue this work attempts to address. Our goal is to determine which, when and how many RSU(s) should be offloaded and redistributed among the controllers to minimize control-plane overload, satisfy data-plane QoS constraints, and prevent unnecessary controller reconfiguration and synchronization overhead, thereby reducing signaling load. Moreover, the proposed RSUs offloading decisions must be designed to be computationally efficient and lightweight to support realtime operation. III. P ROPOSED C ONTROL - PLANE RESIZING A LGORITHMS The proposed control-plane resizing algorithms adapt to vehicular networks’ dynamic conditions by using observable metrics like controller load and QoS degradation for realtime decisions. Threshold-based triggers, periodic checks, and incremental RSU offloading ensure stability, avoiding oscillations. Within a closed-loop framework, the RSU-centric process redistributes control tasks locally without relocating

Communication Link (RSUs and Vehicular Cloud) Communication Link (RSU and Vehicles) Southbound Interface (Data-plane (RSUs) and Control-plane) Roadside Unit (RSU)

controllers or reconfiguring the topology globally. To highlight the general RSUs reassignment and control-plane resizing process, Fig. 2 provides a general timing diagram elaborating the sequence of interactions between vehicles, RSUs, and multiple controllers. RSUs R forward packets according to set flow rules, requesting controller intervention only when necessary. Every controller locally assesses its control-plane load and related data-plane performance parameters for the RSUs under its control at periodic monitoring intervals. The affected controller is identified differently in CCCRM and DCCRM. In CCCRM, any controller whose measured load exceeds a predefined threshold is considered affected. In DCCRM, the affected controller corresponds to the bottleneck controller, defined as the controller with the highest average RTT that violates the specified threshold. Once identified, the affected controller automatically starts a resizing operation by cooperating with other underloaded controllers via eastwest communication when overload or QoS violations are detected. The proposed algorithm balances the controller load by reassigning selected RSUs R′ ⊂ R under the overloaded controller to new (currently underloaded) controllers. During the controller-RSU reassignment process, ongoing V2I traffic experiences a temporary disruption, as a hard handover regime is assumed. Packets generated during this process are buffered at the vehicle’s application layer instead of being instantly dropped once the new controller-RSU connection is established [14]. Both proposed resizing algorithms are based on this general abstraction, with their primary differences lying in how the overload conditions are determined. A. Control-plane Centric Control-plane Resizing Mechanism In this algorithm, the controller load is collected through periodic sampling. Incoming packets from an RSU without a corresponding forwarding rule are known as packet in messages. Their handling constitutes the dominant source of computational load on the controller. To quantify the controller’s load, let Lc,k denote the load of controller c observed during the monitoring interval k, corresponding to a fixed time window t, which can be mathematically expressed as X Lc,k = pir,k , (1) r∈Rc,k

Application-Plane

where pir,k represents the number of packet in messages generated by RSU r during interval k. A controller is consid-

Northbound Interface (TCP/IP) East/West-bound interfaces

Control-Plane

Vehicular Cloud

Destination Vehicle

Fig. 1: System model of the considered SDVN architecture.

Fig. 2: General timing diagram of control-plane resizing.

ered overloaded when its load exceeds a predefined threshold Lth ; i.e., Lc,k > Lth . In practical applications, Lth corresponds to the maximum viable control-plane load based on controller resource constraints (e.g., central processing unit usage or flow rules processing rate) and can be determined using offline benchmarking or capacity profiling to ensure reliable performance. Once an overload condition is detected, the average control-plane load contributed by a single RSU in the interval k is approximated as Lc,k , (2) L̄r,c,k ≈ |Rc,k | where |Rc,k | denotes the maximum number of RSUs connected to the controller c during the interval k. The severity of controller overload at a given monitoring interval k is quantified as ∆Lc,k = Lc,k − Lth . (3) This allows CCCRM to scale its response proportionally to the overload intensity instead of triggering an abrupt offloading action. After initiating an offloading decision, the minimum number of RSUs to be offloaded from overloaded controller c at interval k is determined as   ∆Lc,k off , (4) Nc,k = α · L̄r,c,k where α ∈ (0, 1] is a tunable scaling parameter that controls the aggressiveness of the offloading process and ⌈·⌉ is the ceiling function enforcing an integer-valued decision. The RSUs to be offloaded are then selected based on vehicular mobility characteristics rather than load ranking, as all RSUs connected to the same controller are assumed to contribute equally to the control-plane load, which is approximated by the average per-RSU load given by (2). Thus, RSU selection is performed based on minimum session time. This metric is defined as the duration for which a vehicle remains within the communication coverage of an RSU after initial entry [15]. It is initially expressed as N (r) = {r′ ∈ R | r′ is a neighboring RSU of r}. The average session duration of vehicles that transition from a neighboring RSU r′ to RSU r during the monitoring interval k is denoted as Tr′ ,r,k . For each RSU r, the minimum average session duration with its neighboring RSU is defined as (5) T r,k = ′ min Tr′ ,r,k , r ∈N (r)

where T r,k represents the minimum average session duration observed at RSU r during the monitoring interval k, considering all its neighboring RSUs. By taking the minimum value over all neighboring RSUs, T r,k captures the fastest mobility flow associated with RSU r. The subsequent step involves sorting the RSUs in descending order based on their calculated average session time. This ranking prioritizes RSUs with higher minimum session time durations, as they indicate lower relative vehicular mobility and less handovers, making them suitable candidates for offloading. Thus, the updated off sorted RSUs list for offloading is updated in Rc,k . The total control-plane load removed through offloading is given by off Loff (6) c,k = Nc,k · L̄r,c,k . This value represents the expected reduction in controller load if all selected RSUs are successfully migrated. The number of underloaded controllers required to accommodate the offloaded RSUs is determined by checking whether the total load to be offloaded satisfies the Loff c,k ≥ ∆Lc,k condition. The RSUs selected for offloading are reassigned to available

underloaded controllers via east-west communication, ensuring that each RSU is associated with exactly one controller. The complete procedure is summarized in Algorithm 1. Complexity Analysis: The dominant operation in Algorithm 1 is sorting RSUs associated with the overloaded controllers based on session time at each interval k. In the worst case, this involves sorting all RSUs, resulting in a complexity of O(k C + k Co OSort) where OSort follows the merge sort performed on RSUs, which is generally represented as O(n log n). Finally, the effectiveness of CCCRM is evaluated using the Load Balancing Rate (LBR), which measures the uniformity of controller load distribution over time. A higher LBR value indicates a more uniform control-plane load (i.e., the RTT-induced load) distribution since overloaded controllers increase data-plane RTT delay through delayed flow-rule installation and frequent handovers. On the other hand, a value of LBR close to zero reflects the absence of load balancing capability. To provide an overall assessment of load balancing performance, the instantaneous controller load distribution is used to calculate the LBR at each monitoring interval, which are then averaged over the entire duration. The LBR of the control-plane after offloading RSUs from an overloaded controller to underloaded ones is computed ! as: PNc T X L(c , t) − L̄(t) 1 i 1 − i=1 , (7) LBR = T t=1 Nc · L̄(t) where L(ci , t) represents the load of each controller at time t, L̄(t) denotes the average load of controllers at time instant t, and T is the total simulation time. B. Data-plane Centric Control-plane Resizing Mechanism DCCRM addresses cases where control-plane metrics appear stable but data-plane QoS (e.g., V2I delay) degrades in dynamic vehicular networks. Unlike CCCRM, which relies solely on control-plane load, DCCRM uses real-time RTT and packet loss measurements from vehicles to trigger resizing when QoS thresholds are violated. In this approach, each controller periodically computes the average RTT across its RSUs, identifies the bottleneck controller with the highest RTT, and offloads the most stressed RSUs to underloaded controllers using a score-based assignment when QoS thresholds are exceeded. The average round-trip delay encountered by vehicles connected to RSU r during the monitoring interval k ¯ r,k . It is calculated by is represented by the RSU-level RTT rtt averaging the RTT samples reported by all vehicles v ∈ Vr,k associated with RSU r as X ¯ r,k = 1 RT Tv , ∀r ∈ R. (8) rtt |Vr,k | v∈Vr,k Thereafter, controller-level QoS is obtained by aggregating its corresponding RSU-level RTTs X ¯ c,k = 1 ¯ r,k , ∀c ∈ C. rtt rtt (9) |Rc,k | r∈Rc,k

The synchronization cost of the controller c at time tk is denoted by sc (tk ). This term captures the control-plane overhead resulting from RSU reassignment, including intercontroller coordination and flow rule reinstallation, and represents the temporary delay introduced by resizing operations. It is used to reduce or minimize the occurrence of excessive resizing operations. The synchronization cost of controller c in the previous interval tk−1 is denoted by sc (tk−1 ). The

Algorithm 1 CCCRM Input: Controller set C; RSU set R; controller load threshold Lth ; monitoring interval k; scaling factor α; Output: Balanced controller load and updated RSU-tocontroller mapping; 1: Initialization: Overloaded controller set Co = ∅, Underloaded controller set Cu = ∅; 2: for each monitoring interval k 3: for each controller c ∈ C 4: Measure controller load Lc,k using Eq. (1); 5: if Lc,k > Lth 6: Co ← Co ∪ {c}; 7: else 8: Cu ← Cu ∪ {c}; 9: end if 10: end for 11: for c ∈ Co 12: Compute L̄r,c,k using Eq. (2); 13: Compute ∆Lc,k using Eq. (3); off 14: Compute Nc,k using Eq. (4); 15: Rank RSUs connected to c by minimum session time using Eq. (5) and sort them in descending order; off 16: Select Nc,k RSUs for offloading Roff c,k RSUs; off 17: Compute Lc,k using Eq. (6); 18: if Loff c,k ≤ ∆Lc,k 19: Select a single target controller c′ ∈ Cu ; ′ 20: Offload RSUs in Roff c,k to c ; 21: Update controller-RSU assignment; 22: else 23: Select multiple underloaded controllers Cu′ ⊆ Cu ; ′ 24: Offload RSUs in Roff c,k to Cu ; 25: Update controller-RSU assignment; 26: end if 27: end for 28: end for 29: return Updated controller load distribution and RSU assignments;

incremental synchronization overhead caused by controllerRSU reassignment and the controller c experiences between two consecutive monitoring intervals is represented as ∆sc,k which is computed as ∆sc,k = sc (tk ) − sc (tk−1 ), ∀c ∈ C. (10) The bottleneck controller c∗ at monitoring interval k is identified as the controller experiencing the highest average RTT. The bottleneck controller c∗ is identified as ¯ c,k . (11) c∗ = arg max rtt c∈C Control-plane resizing is triggered only when the bottleneck controller violates the predefined RTT threshold, and resizing ¯ c∗ ,k > rttth . is triggered only if rtt The offload size nk scales with both the normalized RTT excess and the number of RSUs currently managed by the bottleneck controller, ensuring adaptive and incremental resizing. Thus, the number of RSUs to be offloaded at the monitoring interval k is computed as   ¯ c∗ ,k − rttth rtt ∗ nk = κ · · |Rc ,k | . (12) rttth The parameter κ regulates the aggressiveness of the resizing

process. RSUs connected to the bottleneck controller are assigned a weight using a stress metric that captures both delay and traffic density, i.e., ¯ r,k · |Vr,k |. Pr,k = rtt (13) The top-nk RSUs with the highest stress connected to c∗ are   then selected of f Rk = top-nk arg max Pr,k . (14) r∈Rc∗ ,k

After identifying the bottleneck controller and the selected RSUs to offload, these RSUs are offloaded to underloaded controllers based on a variable Scorec,k representing their load, which is calculated for each candidate target controller c ̸= c∗ as follows ∆sc,k , (15) Scorec,k = wL |Rc,k | + wS Sth where the weighting factors wL and wS balance controller load and synchronization cost. Sth is the maximum permissible synchronization cost used for normalization. The target controllers are ranked in ascending order of their current load and updated as the sorted set Cksorted . The selected RSUs are assigned to candidate underloaded controllers using a modulobased controlled round-robin strategy ϕk (ri ) over the ranked controller sorted in ascending order based on Scorec,k . This ensures a fair distribution of offloaded RSUs while preventing secondary controller overload. After migration, the controllerRSU mappings are updated accordingly. The pseudocode of DCCRM is presented in Algorithm 2. Complexity Analysis: The dominant operations in Algorithm 2 include computing RTT metrics across RSUs, sorting RSUs associated with the bottleneck controller for offloading, and sorting underloaded candidate controllers at each interval k. This yields a complexity of O(k R + k C + k OSort), where OSort follows a merge sort applied to RSUs associated with overloaded controllers, among underloaded controllers, and assignment of chosen RSUs to one or more underloaded controllers, generally represented as O(n log n). The effectiveness of DCCRM is evaluated using the metric data-plane (DP)-LBR, which captures the degree of dataplane load balance among active controllers by measuring the normalized deviation of controller loads from their mean value, and is defined  as if Nc (k) = 1,  0 P L(c, k) − L̄(k) DP-LBR(k) =  1 − c∈Ck if Nc (k) ≥ 2, Nc (k) · L̄(k) (16) where Ck is the set of active controllers, Nc (k) = |Ck | is the number of active controllers who have RSU(s) under their domain, L(c, k) is the load of controller c in interval k (e.g., ¯ c,k ), and L̄(k) is the average load (from the sum of RTTs rtt viewpoint of RTT) across active controllers given by 1 X ¯ L̄(k) = rttc,k . Nc (k) c∈Ck Given the long duration of traffic observation and dynamic changes in traffic and controller count, the time-averaged DP-LBR (DP-LBRavg ) is adopted as a single scalar metric to assess the overall effectiveness and consistency of dataplane load balancing throughout the simulation. The overall load balancing performance across all intervals is computed

by averaging over intervals with at least two active controllers 1 X DP-LBRavg = ∗ DP-LBR(k), (17) |T | k∈T ∗ where T ∗ = {k | Nc (k) ≥ 2}. This formulation ensures that intervals with only a single controller, where balancing is not defined, are excluded. IV. E XPERIMENT SETTING AND RESULTS DISCUSSION In the conducted experimentation, the topology design illustrated in Fig. 1 is implemented using a virtual machine (VM) of Ubuntu 20.04.02 operating system on 11th Gen Intel Core i5 CPU with 4GB of RAM. The simulation of the SDN based vehicular network is performed using MininetWiFi 2.6 and the Python-based Ryu controller, which supports the OpenFlow v1.3 protocol. Python version considered for this work is 3.8.10. Each testbed simulation takes about one hour and the monitoring interval k occurred about every 300 seconds (s). A small-scale topology with Nc = 3, Nr = 9, and Nv = 10 is designed to evaluate the two proposed lightweight control-plane resizing mechanisms. This topology size chosen intentionally within the practical resource limits of MininetWiFi emulation running on a single VM. Because both CCCRM and DCCRM are threshold-based and generalized, the fundamental behaviour and performance trends observed in this study remain consistent even for large-scale network because the algorithms’ core decision logic is independent of the total number of controllers, RSUs, or vehicles. Each vehicle generates a packet at each 0.2s interval. The considered mobility model for vehicles is random way point model [16] and the propagation model adopted is Friis propagation loss as provided by Mininet-WiFi. We compare the proposed mechanisms against two baselines: a single-controller testbed (all nine RSUs statically assigned to one SDN controller) and a static multi-controller design (nine RSUs uniformly divided among three controllers, never reassigned). These extremes represent fully centralized control and traditional static load distribution. As shown in Fig. 3a, Fig. 3b, and Fig. 5a, CCCRM significantly improves performance over the single-controller benchmark in most cases. In the benchmark, all RSUs remain statically assigned to one controller, causing severe controlplane overload under high mobility. This results in E2E delay increasing from 81.7 ms at 5 m/s to over 183 ms at 10 m/s and packet loss exceeding 50%. With the aggressive threshold (Lth = 100), CCCRM consistently achieves the best results, reducing E2E delay to 69.0 ms, 100.4 ms, and 147.2 ms, and packet loss to 29.0%, 34.5%, and 45.5% at 5, 10, and 15 m/s, respectively. The more cautious threshold (Lth = 200) also outperforms the benchmark at lower speeds (5 and 10 m/s), but at the highest speed of 15 m/s, it shows a slightly higher E2E delay than the benchmark (approximately 215 ms versus 178 ms). This occurs because the higher threshold delays offloading, allowing temporary control-plane overhead to accumulate. When migration finally occurs, it introduces additional synchronization overhead and flow-rule reinstallation delays. Despite this, CCCRM achieve substantially higher LBR above 0.57 for Lth = 100, compared to nearly zero in the benchmark. The results show that CCCRM effectively reduces control-plane congestion and stabilizes data-plane QoS under higher mobility, with aggressive thresholds yielding the most

Algorithm 2 DCCRM Input: Controller set C; RSU set R; RTT threshold rttth ; monitoring interval k; resizing factor κ; weights wL , wS Output: QoS-aware balanced controller–RSU mapping; 1: Initialization: Overloaded controller set Co = ∅, Underloaded controller set Cu = ∅; 2: for each monitoring interval k 3: for each RSU r ∈ R ¯ r,k using Eq. (8); 4: Compute rtt 5: end for 6: for each controller c ∈ C ¯ c,k using Eq. (9); 7: Compute rtt 8: Compute ∆sc,k using Eq. (10); 9: end for 10: Identify bottleneck controller c∗ using Eq. (11); ¯ c∗ ,k ≤ rttth 11: if rtt 12: QoS satisfied; retain current controller–RSU assignment; 13: else 14: Co ← {c∗ }; 15: Cu ← C \ {c∗ }; 16: Compute nk to offload RSUs using Eq. (12); 17: for each RSU r ∈ Rc∗ ,k 18: Compute Pr,k using Eq. (13); 19: end for f 20: Select Rof for offloading using Eq. (14); k 21: for each controller c ∈ Cu 22: Compute Scorec,k using Eq. (15); 23: end for 24: Sort controllers in Cu in ascending order Cksorted ; 25: Initiate assignment operation among Cu ; f 26: for ri ∈ Rof k 27: Start assignment ϕk (ri ); 28: end for 29: Update c∗ mappings; 30: Update mappings of controllers in Cu ; 31: end if 32: end for 33: return Updated controller–RSU assignment with restored data-plane QoS;

consistent gains. However, excessively low thresholds may cause frequent RSU reassignments, increasing synchronization and migration overhead including flow rule reinstallation and controller coordination delays, which can introduce temporary latency and instability. The threshold values chosen in this work shows a balanced operation.

(a)

(b)

Fig. 3: CCCRM: (3a) E2E delay with variable vehicles speed; (3b) Packets loss with variable vehicles speed.

(a)

(b)

Fig. 4: DCCRM: (4a) E2E delay with variable vehicles speed; (4b) Packets loss with variable vehicles speed.

(a)

(b)

Fig. 5: LBR (5a) CCCRM-LBR; (5b) DCCRM-LBR

As shown in Fig. 4a, Fig. 4b, and Fig. 5b, DCCRM improves data-plane QoS by making resizing decisions based on realtime RTT degradation rather than static controller assignments. In the single-controller benchmark, mobility-induced flow setups accumulate at one controller, causing excessive packet in processing and severe RTT escalation (up to > 2.5 s at 15 m/s). Although the static three-controller (3C) benchmark initially distributes RSUs evenly, it cannot adapt to dynamic traffic asymmetry caused by mobility. In comparison to both static benchmarks, DCCRM achieves the lowest E2E delay (70.1 ms) and packet loss at 5 m/s. At 10 m/s, it exhibits a somewhat higher delay than the static 3C benchmark. Because during RSU reassignment, synchronization and migration overhead introduced short-term latency before the system stabilizes, which results in a temporary increase in RTT. At the highest speed of 15 m/s, DCCRM maintains a reasonable delay of approximately 155 ms while the single-controller scenario collapses to > 2.5 s. The DP-LBRavg results further confirm these gains, reaching up to 0.82 with the proposed mechanism compared to 0.61 for the static 3C and nearly zero for the single-controller case. These findings indicate that QoS-driven resizing offers stability and sustained performance under extremely dynamic SDVN conditions, while static load balancing based topology may overestimate system robustness. This study adopts fixed threshold values to initiate control-plane resizing and offloading decisions. Future research work will investigate adaptive threshold selection mechanisms at each occurred monitoring interval to dynamically adjust threshold values according to varying traffic loads, controller utilization, and network conditions. V. C ONCLUSION This paper addresses controller load imbalance and overload in SDVNs under dynamic mobility. Two lightweight, policydriven control-plane resizing strategies are proposed. CCCRM uses control-plane load indicators to accomplish thresholdbased reactive offloading, whereas DCCRM uses real-time RTT degradation to initiate data-plane-aware resizing. Both algorithms are suitable for real-time execution and scale effi-

ciently with network size. They have been extensively evaluated using Mininet-WiFi. Experimental results show that even in multi-controller deployments, static controller assignment fails to effectively handle mobility-induced traffic asymmetry. In contrast, the proposed strategies provide higher LBR while significantly reducing E2E delay and packet loss when compared to both static single- and multi-controller benchmarks. The current evaluation indicates the efficacy of the proposed mechanisms within the specified considered topology. However, larger and denser SDVN deployments may incur increased control-plane coordination overhead cost, especially under static benchmark configurations. Future research will examine such scalability and overhead-related aspects in largescale topology scenarios and with realistic controlled vehicular mobility model. ACKNOWLEDGMENT This work was supported by the Research Council of Finland through the projects 6G Flagship (369116), ReWin-6G (357120) and 6G-Concorse (359850).

R EFERENCES [1] R. Liu et al., “6G enabled advanced transportation systems,” IEEE Trans. Intell. Transp. Syst., vol. 25, no. 9, pp. 10 564–10 580, Apr. 2024. [2] M. Silva et al., “Exploring software defined networks for seamless handovers in vehicular networks,” Vehicular Communications, vol. 31, p. 100372, 2021. [3] M. M. Islam, M. T. R. Khan, M. M. Saad, and D. Kim, “Softwaredefined vehicular network (SDVN): A survey on architecture and routing,” Journal of Systems Architecture, vol. 114, p. 101961, 2021. [4] M. A. Altahrawi, N. F. Abdullah, R. Nordin, and M. Ismail, “Multi-radio access software-defined vehicular network,” IEEE Trans. Intell. Transp. Syst., vol. 23, no. 8, pp. 10 030–10 048, Oct. 2021. [5] N. H. Hussein et al., “SDN-based VANET routing: A comprehensive survey on architectures, protocols, analysis, and future challenges,” IEEE Access, vol. 13, pp. 126 801–126 861, 2024. [6] Z. He, J. Cao, and X. Liu, “SDVN: Enabling rapid network innovation for heterogeneous vehicular communication,” IEEE Netw., vol. 30, no. 4, pp. 10–15, 2016. [7] A. Boukerche and N. Aljeri, “Design guidelines for topology management in software-defined vehicular networks,” IEEE Netw., vol. 35, no. 2, pp. 120–126, 2021. [8] U. Prajapati, B. C. Chatterjee, and A. Banerjee, “FractionalLB: Controller load balancing using fractional switch migration in softwaredefined networks,” IEEE Netw. Lett., vol. 6, no. 2, pp. 129–133, Jun. 2024. [9] M. Farhan et al., “ReCAP: Reliability–capacity aware joint controller placement and routing using a hybrid AI approach,” IEEE Trans. Rel., vol. 74, no. 4, pp. 5686–5700, Jul. 2025. [10] A. Alyanbaawi et al., “MC-LBTO: secure and resilient state-aware multi-controller framework with adaptive load balancing for SD-IoT performance optimization,” Scientific Reports, 2025. [11] H. Babbar, S. Rani, A. K. Bashir, and R. Nawaz, “LBSMT: Load balancing switch migration algorithm for cooperative communication intelligent transportation systems,” IEEE Trans. Green Commun. Netw., vol. 6, no. 3, pp. 1386–1395, Mar. 2022. [12] K. Smida, H. Tounsi, and M. Frikha, “Intelligent and resizable control plane for software defined vehicular network: A deep reinforcement learning approach,” Telecommunication Systems, vol. 79, no. 1, pp. 163– 180, Oct. 2021. [13] R. R. Fontes et al., “Mininet-WiFi: Emulating software-defined wireless networks,” in 2015 11th International conference on network and service management (CNSM). IEEE, 2015, pp. 384–389. [14] M. Z. U. Abideen, A. M. Htut, and C. Aswakul, “Development of control-plane switch migration testbed using Mininet-WiFi for softwaredefined vehicular network,” in 2023 20th International Joint Conference on Computer Science and Software Engineering (JCSSE). IEEE, Jun. 2023. [15] M. Z. U. Abideen, A. M. Htut, and C. Aswakul, “Evaluation of data-plane performance in control-plane switch migration testbed using Mininet-WiFi for SDVN,” in 2024 International Conference on Intelligent Computing and Next Generation Networks (ICNGN), Nov. 2024. [16] X. Lin, R. K. Ganti, P. J. Fleming, and J. G. Andrews, “Towards understanding the fundamentals of mobility in cellular networks,” IEEE Trans. Wireless Commun., vol. 12, no. 4, pp. 1686–1698, 2013.