LTE / WiFi Multipath

This project investigates how to distribute traffic across LTE and Wi-Fi as network conditions change and aggregate at the IP layer (Multipath IP, MPIP). Working within a provided ns-3 simulation framework, I developed an adaptive scheduler that uses measured throughput and delay to select paths and distribute traffic while avoiding overload. Testing across five network scenarios revealed that using TCP data packets to monitor a slower path could cause packet reordering and reduce throughput, even without congestion. I revised the design to use separate probe packets, improving performance in the scenario with a large delay difference between the two paths.

Full project report and Github repository available upon request.

Network Architecture

Downlink traffic is split at the router and delivered through LTE (blue curve) and Wi-Fi (red curve) to the receiving device. Uplink traffic travels through LTE (green curve) only. Source: CIS 549 project brief, University of Pennsylvania.

Algorithm

• Router—probe packets: The router periodically sends independent probes through LTE and Wi-Fi to measure each path’s delay.
• Router—data packets: The router favors the lower-delay path, shifts traffic away from overload, and splits traffic proportionally to received throughput when both paths are overloaded.
• UE—packet reception and feedback: The UE returns throughput and delay measurements to the router, which combines them with input rates to update packet allocation.

Simulation Results

In this experiment, I tested five network conditions:

• Comparable Wi-Fi and LTE capabilities
• Better Wi-Fi capabilities
• Better LTE capabilities
• Dynamic LTE MCS, causing LTE network conditions to fluctuate between better and worse than those of Wi-Fi
• Heavy load on both LTE and Wi-Fi

The summary simulation diagrams and performance diagrams for Scenarios 4 and 5 are shown above.

• As shown in the Scenario 4 results, at around 2.5 seconds, LTE experiences a drop in throughput (received rate) due to changing network conditions caused by the dynamic LTE MCS. At this point, the algorithm switches to favor the Wi-Fi path for better overall performance.
• In Scenario 5, given an average Wi-Fi throughput of 11 Mbps and an average LTE throughput of 7 Mbps, the algorithm splits the capacity between the LTE and Wi-Fi paths at a ratio of 7:11.
• In all scenarios, the aggregated path’s average throughput >= max(Wi-Fi-only throughput, LTE-only throughput).

Further thinking point

My algorithm started with a simple goal: avoid overloading either path. Working through the simulations helped me appreciate how complex scheduling can become, particularly when its decisions interact with TCP’s own congestion control. I see this project as a microcosm exploration of multipath communication, and it leaves me with a few questions I’d like to explore further:

• Scheduling decisions: My algorithm relies on throughput and delay feedback, but scheduling can also involve QoS requirements, radio conditions, buffer status, power restrictions, and scheduling history. I’m interested in how these factors are balanced, especially when they suggest different decisions.

• Theoretical performance limits: One objective was to improve throughput relative to the better individual path. I’d like to understand how much improvement is theoretically possible, what limits that improvement, and how current research and industry approaches address those limits.

• Path oscillation: When the scheduler shifts traffic between paths, TCP also adjusts its sending rate. I wonder when these mechanisms work together and when they create oscillations that make congestion harder to interpret. Comparing how MPIP and MPTCP handle these interactions would be a useful next step.