{"id":"8449b10e-76f6-4ee3-8736-adfbe815b02c","arxiv_id":"2502.01290","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"MPTCP maintains one TCP session over multiple simultaneous IEEE 802.11p links to different roadside units using a single shared radio, enabling handover without breaking the connection in a small emulated test.","lead":"An experimental study shows that Multipath TCP can keep a connection alive when a vehicle has only one radio, by sharing that radio among several roadside units through tunnels. The result points to smoother vehicle-to-infrastructure handovers, but the evidence is a single emulated run without error bars or a baseline.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The load-bearing assumption is that on/off toggling of RSUs emulates real mobility; since the experiments contain no radio-level dynamics and no direct handover-interruption metric, the 'seamless handover in highly mobile environments' claim is not yet supported.","rationale":"The reader's weakest_assumption correctly identifies the emulated mobility as the load-bearing premise. My read of the paper confirms that the experimental configuration (Section IV) uses turning RSUs on and off as the only mobility mechanism and that no direct handover continuity metric is reported. The central claim in the abstract and conclusions depends on this equivalence. I do not see a more fundamental internal inconsistency: the GRE-tunnel overlay (Section III) is a plausible way to create multiple logical links over one 802.11p interface, and the paper is honest that the overlay and SDN performance are out of scope (footnote 1). The lack of repeated trials and baseline comparisons strengthens the conditional status but does not by itself invalidate the proof-of-concept. The 'seamless handover' attribution is also weakened by the paper's own statement that MPTCP does not detect connectivity changes and that the Handover CM must create/remove subflows; this is a scope limitation rather than a contradiction, and it reinforces the need for a real mobility test. Therefore the verdict remains CONDITIONAL: accept the existence proof that MPTCP can operate over multiple logical links on a shared single radio, but require real or higher-fidelity mobility evaluation before accepting the seamless-handover claim.","tokens_in":5892,"tokens_out":4647,"duration_ms":44086,"concrete_test":"Repeat the experiment with actual mobility (or a network simulator with an 802.11p PHY/MAC and mobility traces) using one OBU moving at, say, 30 km/h through overlapping coverage of two RSUs, with the Handover CM deciding subflow creation from live signal-strength reports. Run at least 10 trials and record the application-level throughput gap and maximum consecutive packet loss at the RSU1-to-RSU2 transition. If the MPTCP connection shows a gap comparable to a TCP timeout or stalls until the new subflow is manually created, the seamless-handover claim fails; if the gap is below one RTT and iPerf continues without application-visible interruption, the emulated-mobility concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim requires MPTCP to sustain communication during handovers in a highly mobile single-RAT network. The evaluation replaces mobility with a binary on/off switching of RSUs (Section IV). This removes the very phenomena that make vehicular handovers hard: distance-dependent signal attenuation, fading, Doppler shift, MAC-layer contention for the shared 802.11p channel, and packet loss. It also removes the need for the Handover CM to decide when to create a subflow based on degrading signal strength; the experimenter guarantees overlap by turning RSU2 on before RSU1 off. The paper asserts that MPTCP 'ensures seamless handovers' but never reports an interruption metric (e.g., application-level gap, retransmission count, or time without connectivity); the plotted bitrate curves cannot distinguish a true seamless transition from a controlled switchover. Moreover, the paper itself states that MPTCP does not automatically create/remove subflows and that the Handover CM does this, so the seamless behavior is largely attributable to the external CM and the pre-configured GRE tunnels, not to MPTCP. Thus, the proof-of-concept shows MPTCP can run over multiple logical links on one radio, but the 'highly mobile' and 'seamless' parts of the claim rest on an unvalidated equivalence between RSU toggling and vehicular motion.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":6132,"tokens_out":3679,"duration_ms":34368,"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":[{"comment":"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":"Section IV (Performance Evaluation)"},{"comment":"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":"Section IV, Figs. 4 and 5"},{"comment":"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":"Section IV, Figs. 4 and 5"},{"comment":"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":"Section III (Integration) and Section IV"},{"comment":"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.","section":"Section IV (Performance Evaluation)"}],"minor_comments":[{"comment":"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":"Figs. 4 and 5"},{"comment":"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":"Section IV"},{"comment":"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.","section":"Section IV"},{"comment":"The affiliations contain LaTeX encoding artifacts (e.g., 'Instituto de Telecomunicac ¸ ˜oes') that should be cleaned up in the camera-ready version.","section":"Author affiliations"},{"comment":"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.","section":"Section IV, last paragraph"}],"recommendation":"major_revision","confidential_remarks":"The reader's stress-test concern is valid and is the main reason for the major-revision recommendation. The paper is a short experimental demonstration; as a journal contribution it would benefit from a more rigorous evaluation procedure, including repeated trials, direct handover metrics, and a baseline. The novelty is moderate, but the single-RAT MPTCP question is worth pursuing if the evaluation is strengthened."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThe 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.\n\nTo 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.\n\nThis 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.","headline":"The single-radio MPTCP configuration is genuinely new, but the seamless-handover claim outruns what the on/off RSU experiment can support.","tokens_in":6735,"tokens_out":3050,"would_cite":false,"duration_ms":26455,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Multipath TCP","MPTCP","single radio access technology","802.11p","vehicular networks","seamless handover","GRE tunnels","software-defined vehicular networks"],"falsifier":"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.","tokens_in":5661,"feed_emoji":"📶","tokens_out":10145,"duration_ms":86863,"temperature":0.7,"pith_summary":"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.","feed_headline":"One radio, many paths: MPTCP keeps vehicle handovers seamless","feed_subtitle":"By sharing one 802.11p radio across GRE tunnels, MPTCP keeps traffic flowing as the vehicle moves between roadside units.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines MPTCP itself, the protocol whose single-RAT operation the paper is testing.","marker":"[1]"},{"why":"Specifies the 802.11p radio technology shared by all logical links in the experiments.","marker":"[2]"},{"why":"Describes the SDN-based vehicular network that manages logical links between the OBU and RSUs and redirects downlink traffic.","marker":"[7]"},{"why":"Provides the cooperative ITS messaging stack whose positioning and signal-strength reports drive subflow creation and removal.","marker":"[8]"},{"why":"Introduces the GRE tunnelling approach that lets one wireless interface carry multiple simultaneous logical links.","marker":"[9]"},{"why":"Defines the coupled congestion control algorithm used with MPTCP in the experiments.","marker":"[10]"}],"fun_headline_variants":["One radio, many tunnels: MPTCP handovers without multiple RATs","MPTCP paradox resolved: single radio gives multiple paths","Single 802.11p radio, seamless MPTCP handovers in vehicles","Sharing one radio: MPTCP works with just one RAT","One RAT, many subflows: MPTCP vehicular handover made seamless"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One radio, many tunnels: MPTCP handovers without multiple RATs","MPTCP paradox resolved: single radio gives multiple paths","Single 802.11p radio, seamless MPTCP handovers in vehicles","Sharing one radio: MPTCP works with just one RAT","One RAT, many subflows: MPTCP vehicular handover made seamless"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000237,"raw_usage":{"total_tokens":1465,"prompt_tokens":859,"completion_tokens":606,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":475,"completion_tokens_details":{"reasoning_tokens":507}},"tokens_in":475,"tokens_out":606,"duration_ms":5965,"temperature":1.0,"reasoning_tokens":507,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T15:47:07.613774+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"1–51, 2010","cited_arxiv_id":null,"evidence_quote":"Specifies the 802.11p radio technology shared by all logical links in the experiments."},{"cited_title":"A Software Defined Vehicular Network Using Cooperative Intelligent Transport System Messages,","cited_arxiv_id":null,"evidence_quote":"Describes the SDN-based vehicular network that manages logical links between the OBU and RSUs and redirects downlink traffic."},{"cited_title":"Vanetza-NAP: Vehicular Communications and Services in MicroServices Architectures,","cited_arxiv_id":null,"evidence_quote":"Provides the cooperative ITS messaging stack whose positioning and signal-strength reports drive subflow creation and removal."},{"cited_title":"Multihoming in Software Defined Vehicular Net- works,","cited_arxiv_id":null,"evidence_quote":"Introduces the GRE tunnelling approach that lets one wireless interface carry multiple simultaneous logical links."},{"cited_title":"Coupled Congestion Control for Multipath Transport Protocols,","cited_arxiv_id":null,"evidence_quote":"Defines the coupled congestion control algorithm used with MPTCP in the experiments."}],"review_version":1}