Multipath TCP with Single Radio Access Technologies: a Paradox or an Opportunity?

Duarte Dias; Jo\~ao Torrinhas; Miguel Lu\'is; Pedro Rito; Susana Sargento

REVIEW 5 major objections 5 minor 10 references

Multipath TCP with Single Radio Access Technologies: a Paradox or an Opportunity?

T0 review · 5 major / 5 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read MPTCP can run on a single shared radio when one 802.11p interface is split into logical links to several roadside units, delivering seamless handovers.

desk verdict The single-radio MPTCP configuration is genuinely new, but the seamless-handover claim outruns what the on/off RSU experiment can support. read the letter →

arxiv 2502.01290 v2 pith:DDPSCTMZ submitted 2025-02-03 cs.NI

João Torrinhas , Miguel Luís , Duarte Dias , Pedro Rito , Susana Sargento This is my paper · ORCID

classification cs.NI

keywords MultipathTCPMPTCPsingleradioaccesstechnology802.11pvehicularnetworksseamlesshandoverGREtunnelssoftware-defined

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that Multipath TCP can work in a single-radio environment, not just when several different radio technologies are available. The key move is to treat each roadside unit in range as a separate path: GRE tunnels over one shared 802.11p interface carry distinct MPTCP subflows to several RSUs at once. Experiments with real vehicular hardware and emulated mobility show the subflows are created and used as RSUs come into and out of range, with throughput shared across them because they occupy the same radio. The authors argue that this turns handover from one roadside unit to another into a seamless process, because MPTCP keeps the connection alive on remaining subflows. The result matters because vehicles are often not covered by multiple radio technologies, so a single shared radio might be enough to get multipath benefits.

What carries the argument

The central object is the GRE tunnel, a generic routing-encapsulation overlay that lets one physical 802.11p interface appear as multiple logical links, one to each roadside unit in range. Each logical link hosts its own MPTCP subflow, while the Handover Connection Manager adds and removes subflows on the basis of cooperative ITS messages, and the minRTT scheduler distributes data over whichever subflow currently has the lowest round-trip time. The coupled congestion control algorithm then adjusts each subflow's rate so that the shared radio's capacity is divided among the active logical links.

What would settle it

Move a real vehicle with one 802.11p radio along a road with overlapping RSU coverage, logging MPTCP throughput and connection state through each handover; if the aggregate flow stalls or resets as signal strength decays, the seamless-handover claim is refuted.

Watch

Extended reading notes

Core claim

The central discovery is that the contradiction in the title is only apparent: one radio access technology can still present MPTCP with multiple usable paths. A single 802.11p radio is shared by several GRE tunnels, each tunnel connecting the on-board unit to a different roadside unit and carrying its own MPTCP subflow. The experimental results show that when a new RSU becomes reachable a subflow is created and used, and when an RSU disappears the corresponding subflow is removed while traffic continues on the remaining subflow. With the default minRTT scheduler, traffic is distributed among subflows according to measured round-trip time, so even over one shared radio the protocol behaves as if multiple independent paths existed, and the aggregate connection survives the loss of any single roadside unit.

Load-bearing premise

The load-bearing premise is that emulated mobility, created by turning roadside units on and off in a controlled environment, reproduces the connectivity changes a moving vehicle would experience; real fading, Doppler, and radio contention are absent.

Editorial extensions

If this is right

An MPTCP connection on a vehicle with only a single 802.11p radio can survive a roadside unit going out of range because traffic shifts to a subflow through another RSU.
When multiple RSUs are in range, the one shared radio's capacity is divided among the active subflows, so total throughput does not multiply with the number of paths.
With minRTT scheduling, a lower-RTT logical link attracts more traffic, so even within one radio the protocol can favour the better next hop.
A connection manager is required to create and remove subflows as vehicles move; MPTCP itself cannot detect RSU handovers.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper, the same GRE-tunnel trick could turn a single Wi-Fi or cellular interface with multiple reachable base stations into a multipath transport, extending the result to other shared-medium networks.
Beyond the paper, true path diversity is weaker than in multi-RAT MPTCP, because all subflows share one radio and channel, so the resilience gain is mainly alternative next-hop infrastructure rather than independent physical paths.
Beyond the paper, the authors' on/off emulation probably makes handovers look cleaner than real fading and Doppler, so a moving-vehicle trial is the natural next test.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague, the one thing to know: this is a proof-of-concept that MPTCP can run multiple subflows over GRE tunnels on a single IEEE 802.11p radio, talking to several RSUs. That configuration is genuinely new as far as the cited related work goes. It is not a conceptual breakthrough, and the headline claim about "seamless handovers in highly mobile environments" is not supported by the experiments.

The paper does several things well. It clearly describes the SDN-based architecture, uses real 802.11p hardware, and is upfront that mobility is emulated by turning RSUs on and off. The time-series plots show subflow creation and removal, and the bitrate sharing between subflows is consistent with the minRTT scheduler. The authors also explicitly state that MPTCP cannot automatically create or remove subflows and that their Handover CM does that. So the paper is honest about the division of labor.

The soft spots are significant. There is one run per scenario, no error bars, and no baseline comparison. More importantly, the emulated mobility removes exactly the phenomena that make vehicular handovers hard: fading, Doppler, MAC contention, and packet loss. The "seamless" claim is also weakened because the Handover CM pre-creates the tunnels and the experimenter guarantees overlap by turning RSU2 on before RSU1 off. There is no direct metric of handover interruption, such as application-level gap or retransmission count, so the plots cannot distinguish a true seamless transition from a controlled switchover. In the delay scenario, the throughput drop is blamed on "channel occupation by other IEEE 802.11p stations" without any channel measurement, so that attribution is unsupported.

To make this a solid engineering contribution, I would want repeated trials, a real mobile testbed or a trace-driven radio emulator, and a conclusion scoped to "MPTCP can maintain a connection over multiple logical links on one radio." As it stands, the paper is a plausible demonstration with a thin evidence base.

This is for researchers working on MPTCP in vehicular networks or SDN-based handover management. I would bring it to a reading group to discuss experimental methodology, but I would not cite it as evidence in my own work. It deserves peer review because the question is legitimate and the authors have real hardware, but a serious referee should push for more rigorous evaluation before acceptance.

Referee Report

5 major / 5 minor

Summary. The paper studies whether MPTCP can provide seamless handovers in a vehicular network where the OBU has only one radio access technology (IEEE 802.11p), by creating multiple logical links (GRE tunnels) to several RSUs and running one MPTCP subflow per logical link. The architecture uses a Software-Defined Vehicular Network (SDVN) and a Handover Connection Manager that creates and removes subflows. The experimental evaluation, based on real OBU/RSU hardware but with emulated mobility (turning RSUs on and off), reports bitrate and RTT time series for two scenarios: with and without an extra 200 ms delay on one link. The paper claims that MPTCP successfully uses the shared radio across multiple subflows and ensures seamless, continuous, stable communication in highly mobile environments.

Significance. If the central claim is validated, the paper would provide a useful proof-of-concept that MPTCP can operate over a single RAT when multiple logical links are available, which is contrary to the usual multi-RAT assumption in MPTCP studies. The work has the merit of using real 802.11p hardware and a standard Linux MPTCP implementation, and the time-series plots do show that MPTCP creates, uses, and shifts traffic between subflows on one shared radio. However, the strength of the current evidence is limited: the mobility emulation removes the very wireless effects that make vehicular handovers difficult, there is no direct handover-interruption or loss metric, there is only one run per scenario with no error bars, and the role of the Handover CM versus MPTCP itself is not isolated. These issues do not invalidate the core observation, but they do prevent the paper from supporting the 'seamless handovers in highly mobile environments' claim as written.

major comments (5)

[Section IV (Performance Evaluation)] The load-bearing assumption is that turning RSUs on and off emulates real vehicular mobility. This removes distance-dependent attenuation, fading, Doppler shift, MAC-layer contention for the shared 802.11p channel, and packet loss, which are central to why handovers are challenging in vehicular networks. The abstract and conclusion claim 'seamless handovers in highly mobile environments,' but the experiments contain no radio-level dynamics. Please either perform a real moving-vehicle experiment or provide a concrete justification of why on/off toggling captures the MPTCP-relevant aspects of mobility, and state this limitation explicitly in the conclusions.
[Section IV, Figs. 4 and 5] No handover-interruption or loss metric is reported. The paper never quantifies the application-level gap, retransmission count, or time without connectivity when an RSU disappears. The bitrate and RTT curves cannot distinguish a true seamless transition from a controlled switchover that happens to avoid data loss. Please add a direct metric such as iPerf3-reported throughput gaps, TCP retransmissions, or time-to-recovery at the handover instants.
[Section IV, Figs. 4 and 5] The evaluation presents only one run per scenario, without error bars, confidence intervals, or any indication of run-to-run variability. Given the known variability of 802.11p and the claims of 'stable and efficient communication,' at least a small number of repetitions with summary statistics is needed to support the quantitative statements such as 'average bitrate of 8.5 Mbps'.
[Section III (Integration) and Section IV] The paper states that MPTCP cannot automatically create or remove subflows and that the Handover CM performs this task. Therefore, the observed creation and removal of subflows is attributable to the external controller, not to MPTCP. The MPTCP-specific contribution is restricted to scheduling and failover among already-existing subflows. Please design an experiment that isolates MPTCP's role, for example by abruptly disabling a GRE tunnel without CM intervention and measuring how quickly MPTCP shifts traffic to the surviving subflow.
[Section IV (Performance Evaluation)] There is no baseline comparison. To support the framing of a 'paradox or opportunity,' the paper should compare against a conventional single-path TCP handover in the same testbed, or against MPTCP with multiple RATs. Without a baseline, it is not possible to assess whether the proposed approach actually improves continuity or efficiency over existing solutions.

minor comments (5)

[Figs. 4 and 5] The figures use multiple colored curves but no legend explicitly mapping colors to subflow numbers; the text assumes the reader can identify subflow 1, 2, and 3.
[Section IV] The reported average bitrate values (e.g., 8.5 Mbps, 6.2 Mbps) do not specify the averaging interval or method; please state how these averages were computed.
[Section IV] The phrase 'MPTCPv12' is ambiguous; presumably this means MPTCP version 1 with a particular patch series, but the notation is nonstandard and should be clarified.
[Author affiliations] The affiliations contain LaTeX encoding artifacts (e.g., 'Instituto de Telecomunicac ¸ ˜oes') that should be cleaned up in the camera-ready version.
[Section IV, last paragraph] The sentence about 'RTT values of 10 times more' does not specify which links are being compared or give the actual RTT values; please make this comparison explicit.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's central result is a direct experimental measurement, not a derivation from its own definitions or fits.

full rationale

The paper makes no mathematical derivation and fits no parameters; its central claim that MPTCP can operate over a single IEEE 802.11p radio shared by multiple GRE tunnels is supported by iPerf3 bitrate and RTT measurements in a real testbed (Section IV). The cited prior work [7] (the SDVN architecture) and [9] (GRE-tunnel overlay) is used as implementation substrate rather than as evidence for the MPTCP result, and the paper explicitly disclaims evaluating that substrate (footnote 1: 'this work does not aim to evaluate the performance of such overlay solution, nor the SDVN'). The MPTCP subflow creation, removal, and traffic distribution are observed directly, so the conclusion is not constructed from its own output. The self-citations to [7] and [9] are therefore not load-bearing in a circular sense. The main weakness -- emulated mobility by turning RSUs on and off (Section IV) -- concerns external validity of the 'highly mobile environments' and 'seamless handovers' claims, not circularity, because the paper's conclusions are not defined in terms of that emulation. Accordingly, no circular step can be exhibited, and the circularity score is 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No fitted model is involved; the experimental design uses hand-chosen conditions (200 ms delay and RSU on/off times). The central claim rests on domain assumptions about emulated mobility, the radio as bottleneck, the standard MPTCP scheduler and congestion control, and the independence of GRE tunnels over a shared radio. No new physical or logical entities are introduced.

free parameters (2)

Additional delay on second RSU link = 200 ms
Chosen test condition to create RTT asymmetry between subflows; hand-picked, not fitted.
Emulated RSU on/off schedule = t = 0, 20, 50, 100 s
Hand-picked timeline for the emulated path to create single- and double-coverage periods; not fitted to data.

assumptions (4)

domain assumption Turning RSUs on and off reproduces the connectivity changes a moving vehicle would experience.
Section IV: the experiment emulates mobility by switching RSUs on and off; this assumes radio propagation, contention, and signal degradation do not qualitatively change MPTCP behavior.
domain assumption The IEEE 802.11p radio, configured at 9 Mbps, is the bandwidth bottleneck so that summing MPTCP subflow bitrates measures sharing.
Section IV reports radios configured for max 9 Mbps and explains bitrate splitting as radio sharing; no link-layer measurement verifies this.
standard math MPTCP minRTT scheduler and LIA congestion control operate as described in RFC 6356 and the Linux MPTCP implementation.
Section IV assumes the default scheduler behavior, lowest RTT first, and coupled congestion control; this is standard background, not tested here.
domain assumption GRE tunnels over the same wireless interface provide independent logical paths for MPTCP subflows.
Section III uses GRE tunnels to create multiple logical links; their independence on a shared radio is assumed.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Multipath TCP with Single Radio Access Technologies: a Paradox or an Opportunity?." pith.science (2026). https://pith.science/paper/DDPSCTMZ

@misc{pith2026250201290,
  author       = {Pith},
  title        = {Pith review of: Multipath TCP with Single Radio Access Technologies: a Paradox or an Opportunity?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DDPSCTMZ}},
  note         = {Machine review of arXiv:2502.01290}
}

read the original abstract

This paper addresses the use of Multipath Transmission Control Protocol (MPTCP) in a single Radio Access Technology (RAT) network. Different from other studies where multiple RATs are explored by the MPTCP, a situation that cannot be always guaranteed, due to lack of coverage for example, in this work we assess and evaluate the capability of MPTCP to operate over a single RAT environment. With a vehicular network as use case, we show how the IEEE 802.11p interface is shared among the multiple logical links created between the On-Board Unit (OBU) and the several Road Side Units (RSUs) in its range, supporting the different MPTCP subflows. The results, obtained through experimentation with real vehicular networking hardware, show that MPTCP allows for seamless handovers, ensuring continuous, stable and efficient communication in highly mobile environments.

Figures

Figures reproduced from arXiv: 2502.01290 by the authors.

**Figure 1.** Software-Defined Vehicular Network architecture: [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 4.** MPTCP performance in the first scenario (no additional [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗

Figures from the paper (2 more)

**Figure 3.** Figure 3: OBU’s emulated path. 2Multipath TCP Project available at https://www.mptcp.dev/. 3 iPerf3 available at https://iperf.fr/. Finally, to better assess the behavior and performance of the MPTCP protocol, two scenarios were considered: one with no manipulation on the networ…

**Figure 5.** Figure 5: MPTCP performance in the second scenario (200 ms [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

10 extracted references · 9 canonical work pages

[1]

TCP Extensions for Multipath Operation with Multiple Addresses,

A. Ford, C. Raiciu, M. J. Handley, O. Bonaventure, and C. Paasch, “TCP Extensions for Multipath Operation with Multiple Addresses,” RFC 8684, Mar. 2020. [Online]. Available: https://www.rfc-editor.org/ info/rfc8684

2020
[2]

1–51, 2010

“IEEE Standard for Information technology– Local and metropoli- tan area networks– Specific requirements– Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifica- tions Amendment 6: Wireless Access in Vehicular Environments,” IEEE Std 802.11p-2010 , pp. 1–51, 2010

work page 2010
[3]

C-ITS: Three observations on LTE-V2X and ETSI ITS-G5—A comparison,

A. Turley et al. , “C-ITS: Three observations on LTE-V2X and ETSI ITS-G5—A comparison,” White Paper. [Online]. Available: https://www.nxp.jp/docs/en/white-paper/CITSCOMPWP.pdf

work page
[4]

Multipath TCP on a V ANET: A Performance Study,

J. Mena, P. Bankole, and M. Gerla, “Multipath TCP on a V ANET: A Performance Study,” SIGMETRICS Perform. Eval. Rev. , vol. 45, no. 1, p. 39–40, Jun. 2017

work page 2017
[5]

A path transmission algorithm for the mobile Vehicular Ad Hoc Networks based on MPTCP,

C. Liu et al. , “A path transmission algorithm for the mobile Vehicular Ad Hoc Networks based on MPTCP,” in 2023 International Conference on Cyber-Physical Social Intelligence (ICCSI) , 2023, pp. 32–37

work page 2023
[6]

Multi-Path TCP in Vehicular Ad-Hoc Networks (V ANETs),

S. K. Abed and D. K. T ¨ureli, “Multi-Path TCP in Vehicular Ad-Hoc Networks (V ANETs),”Eurasian Journal of Engineering and Technology, vol. 26, no. 1, pp. 24–30, Jan 2024

work page 2024
[7]

A Software Defined Vehicular Network Using Cooperative Intelligent Transport System Messages,

D. Dias, M. Lu ´ıs, P. Rito, and S. Sargento, “A Software Defined Vehicular Network Using Cooperative Intelligent Transport System Messages,” IEEE Access , vol. 12, pp. 93 152–93 170, 2024

work page 2024
[8]

Vanetza-NAP: Vehicular Communications and Services in MicroServices Architectures,

R. Rosmaninho et al. , “Vanetza-NAP: Vehicular Communications and Services in MicroServices Architectures,” in 2024 IEEE V ehicular Networking Conference (VNC) , 2024, pp. 297–304

work page 2024

Show all 10 references

[9]

Multihoming in Software Defined Vehicular Net- works,

N. Ferreira et al. , “Multihoming in Software Defined Vehicular Net- works,” in 2024 IEEE V ehicular Networking Conference (VNC) , 2024, pp. 132–139

2024
[10]

Coupled Congestion Control for Multipath Transport Protocols,

C. Raiciu, M. J. Handley, and D. Wischik, “Coupled Congestion Control for Multipath Transport Protocols,” RFC 6356, Oct. 2011. [Online]. Available: https://www.rfc-editor.org/info/rfc6356

2011

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.

[1] [1]

TCP Extensions for Multipath Operation with Multiple Addresses,

A. Ford, C. Raiciu, M. J. Handley, O. Bonaventure, and C. Paasch, “TCP Extensions for Multipath Operation with Multiple Addresses,” RFC 8684, Mar. 2020. [Online]. Available: https://www.rfc-editor.org/ info/rfc8684

2020

[2] [2]

1–51, 2010

“IEEE Standard for Information technology– Local and metropoli- tan area networks– Specific requirements– Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifica- tions Amendment 6: Wireless Access in Vehicular Environments,” IEEE Std 802.11p-2010 , pp. 1–51, 2010

work page 2010

[3] [3]

C-ITS: Three observations on LTE-V2X and ETSI ITS-G5—A comparison,

A. Turley et al. , “C-ITS: Three observations on LTE-V2X and ETSI ITS-G5—A comparison,” White Paper. [Online]. Available: https://www.nxp.jp/docs/en/white-paper/CITSCOMPWP.pdf

work page

[4] [4]

Multipath TCP on a V ANET: A Performance Study,

J. Mena, P. Bankole, and M. Gerla, “Multipath TCP on a V ANET: A Performance Study,” SIGMETRICS Perform. Eval. Rev. , vol. 45, no. 1, p. 39–40, Jun. 2017

work page 2017

[5] [5]

A path transmission algorithm for the mobile Vehicular Ad Hoc Networks based on MPTCP,

C. Liu et al. , “A path transmission algorithm for the mobile Vehicular Ad Hoc Networks based on MPTCP,” in 2023 International Conference on Cyber-Physical Social Intelligence (ICCSI) , 2023, pp. 32–37

work page 2023

[6] [6]

Multi-Path TCP in Vehicular Ad-Hoc Networks (V ANETs),

S. K. Abed and D. K. T ¨ureli, “Multi-Path TCP in Vehicular Ad-Hoc Networks (V ANETs),”Eurasian Journal of Engineering and Technology, vol. 26, no. 1, pp. 24–30, Jan 2024

work page 2024

[7] [7]

A Software Defined Vehicular Network Using Cooperative Intelligent Transport System Messages,

D. Dias, M. Lu ´ıs, P. Rito, and S. Sargento, “A Software Defined Vehicular Network Using Cooperative Intelligent Transport System Messages,” IEEE Access , vol. 12, pp. 93 152–93 170, 2024

work page 2024

[8] [8]

Vanetza-NAP: Vehicular Communications and Services in MicroServices Architectures,

R. Rosmaninho et al. , “Vanetza-NAP: Vehicular Communications and Services in MicroServices Architectures,” in 2024 IEEE V ehicular Networking Conference (VNC) , 2024, pp. 297–304

work page 2024