pith. sign in

arxiv: 2604.07889 · v1 · submitted 2026-04-09 · 💻 cs.NI

Design and empirical validation of a stock-Android software architecture for Wi-Fi Direct multi-group communication

Kwasi Edward , Wayne Goodridge , Koffka Khan , Amit Ramkissoon This is my paper

Pith reviewed 2026-05-10 18:11 UTC · model grok-4.3

classification 💻 cs.NI
keywords Wi-Fi Directmulti-group communicationstock Androidsoftware architecturerelay state managementforwarding tablespeer-to-peerAndroid application
0
0 comments X

The pith

Stock Android can support multi-group Wi-Fi Direct communication through an application-level architecture that coordinates relays and forwarding without OS changes or rooting.

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

The paper designs and empirically tests SWARNET, an architecture that lets developers handle communication across multiple Wi-Fi Direct groups entirely within an app on unmodified Android 11 devices. Android's standard APIs limit groups to one at a time with interface-specific contexts, so the authors manage relay roles, sockets, and state at the application layer using separate components for networking, forwarding tables, and consistency. Tests on five stock Samsung Galaxy A10s phones across single-group and multi-group setups up to five devices in three groups showed the system stayed operational. Throughput declined modestly with added groups while packet loss stayed low except in the most complex cases. This matters because it removes the need for custom firmware or root access for peer-to-peer mobile applications.

Core claim

The authors present SWARNET as a layered software architecture that realizes multi-group Wi-Fi Direct communication on stock Android by combining a Flutter application layer, a Kotlin native networking layer, interface-bound P2P and legacy-Wi-Fi sockets, relay-state management, and subscription-based forwarding tables. The design keeps all coordination at the application level to preserve forwarding-state consistency. Evaluation on five stock Samsung Galaxy A10s devices in four scenarios confirmed the artifact remained operational, with measured peak receiver throughputs of approximately 19.7 Mbit/s in the two-device single-group case, 17.9 Mbit/s in three-device single-group, 16.1 Mbit/s in

What carries the argument

SWARNET layered architecture using relay-state management and subscription-based forwarding tables to coordinate interface-specific transport contexts and relay roles entirely at the application level.

If this is right

  • Developers gain a concrete way to implement multi-group Wi-Fi Direct apps on non-rooted Android 11 devices.
  • The system remains operational from simple single-group to complex three-group forwarding without modification.
  • Throughput decreases gradually with added forwarding complexity but stays functional at 16 Mbit/s or higher in the tested cases.
  • Packet loss stays below 20 percent except in the highest-load three-group region, indicating manageable overhead.
  • The architecture demonstrates feasibility in a small static testbed without requiring operating-system changes.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar application-level coordination could address other peer-to-peer limits in mobile operating systems that lack multi-interface support.
  • The design opens paths for decentralized mobile apps such as local file sharing or mesh messaging without custom hardware.
  • Extending tests to dynamic group changes and larger device counts would clarify how far the consistency mechanisms scale.

Load-bearing premise

Relay-state management and subscription-based forwarding tables can maintain consistency across multiple groups without any OS-level support, assuming stable device behavior on stock Android 11.

What would settle it

A run of the architecture on stock Android 11 devices that shows loss of forwarding consistency, dropped multi-group connections, or inability to sustain relay roles in the tested scenarios would disprove feasibility.

Figures

Figures reproduced from arXiv: 2604.07889 by Amit Ramkissoon, Koffka Khan, Kwasi Edward, Wayne Goodridge.

Figure 1
Figure 1. Figure 1: Implemented two-group communication backbone after relay promotion [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Implemented three-group communication backbone with primary and secondary relay roles. 4.2. Interface-aware communication and socket binding A key architectural decision is the use of two communication contexts at a relay: one socket bound to the device’s WFD P2P interface for nativegroup communication and one socket bound to the legacy-Wi-Fi connection for adjacent-group communication. This decision follo… view at source ↗
Figure 3
Figure 3. Figure 3: 2d1g: average sender throughput versus average receiver throughput. [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: 2d1g: average sender throughput versus packet loss. [PITH_FULL_IMAGE:figures/full_fig_p014_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: 3d1g: average sender throughput versus average receiver throughput. [PITH_FULL_IMAGE:figures/full_fig_p014_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: 3d1g: average sender throughput versus packet loss. [PITH_FULL_IMAGE:figures/full_fig_p015_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: 4d2g: average sender throughput versus average receiver throughput. [PITH_FULL_IMAGE:figures/full_fig_p015_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: 4d2g: average sender throughput versus packet loss. [PITH_FULL_IMAGE:figures/full_fig_p016_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: 5d3g: average sender throughput versus average receiver throughput. [PITH_FULL_IMAGE:figures/full_fig_p016_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: 5d3g: average sender throughput versus packet loss. [PITH_FULL_IMAGE:figures/full_fig_p017_10.png] view at source ↗
read the original abstract

Context: Stock Android exposes Wi-Fi Direct peer-to-peer APIs, but it does not provide application-transparent communication across multiple Wi-Fi Direct groups. For developers working on non-rooted devices, the main obstacle is architectural: interface-specific transport contexts, relay roles, and forwarding state must be coordinated entirely at application level. Objectives: This paper investigates whether multi-group Wi-Fi Direct communication can be realized as a stock-Android software architecture while preserving forwarding-state consistency and remaining compatible with Android 11 devices without rooting or operating-system modification. Methods: We design SWARNET, a layered artifact composed of a Flutter application layer, a Kotlin native networking layer, interface-bound P2P and legacy-Wi-Fi sockets, relay-state management, and subscription-based forwarding tables. We evaluate the implemented artifact on five stock Samsung Galaxy A10s smartphones across four single-group and multi-group scenarios using archived throughput and packet-loss measurements. Results: The artifact remained operational in all four scenarios. Peak receiver throughput observed from the archived curves was approximately 19.7~Mbit/s in 2d1g, 17.9~Mbit/s in 3d1g, 16.1~Mbit/s in 4d2g, and 16.0~Mbit/s in 5d3g. Packet loss increased with forwarding complexity, reaching about 19--20\% only in the highest-load region of the three-group case. Conclusion: The contribution is an implementable software architecture and a feasibility study showing that stock-Android multi-group Wi-Fi Direct communication can be engineered at application level on non-rooted devices. The results support architectural feasibility in a small static testbed; they do not establish broad resilience, scalability, or deployment readiness.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 1 minor

Summary. The manuscript presents SWARNET, a layered stock-Android architecture (Flutter application layer, Kotlin networking, interface-bound P2P/legacy sockets, relay-state management, and subscription-based forwarding tables) to enable multi-group Wi-Fi Direct communication without rooting or OS changes. It reports an empirical evaluation on five Samsung Galaxy A10s devices across four scenarios (2d1g, 3d1g, 4d2g, 5d3g), claiming the artifact remained operational with peak receiver throughputs of approximately 19.7 Mbit/s down to 16.0 Mbit/s and packet loss reaching 19-20% only in the highest-load three-group case.

Significance. If the central feasibility claim holds under broader conditions, the work offers a concrete, implementable application-level solution to a documented limitation in Android's Wi-Fi Direct APIs. The use of a real-device artifact with archived throughput and loss measurements provides tangible evidence of practicality in small static settings, which could benefit developers of ad-hoc mobile networks.

major comments (3)
  1. Evaluation/Results: The reported peak throughputs (19.7 Mbit/s in 2d1g to 16.0 Mbit/s in 5d3g) and packet-loss figures are given as approximate values extracted from archived curves without error bars, number of trials, standard deviations, or raw data, which limits assessment of measurement reliability and variability.
  2. Methods and architecture description: The claim that relay-state management and subscription-based forwarding tables maintain consistency across multiple groups rests on the assumption of stable device behavior, but the evaluation provides no explicit verification (e.g., consistency checks, race-condition tests, or long-running runs) beyond noting operational success in static scenarios; this leaves open the risk of nondeterministic state from Android's single-group P2P semantics.
  3. Evaluation setup: All tests are confined to a five-device static testbed with no dynamic group formation, mobility, or extended-duration consistency validation, which is insufficient to support the broader architectural feasibility conclusion for multi-group forwarding.
minor comments (1)
  1. Abstract: The notation '19.7~Mbit/s' is unclear; replace the tilde with 'approximately' or define it explicitly.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback on our manuscript. We address each major comment point by point below, providing clarifications on the presented evidence and indicating revisions that will be incorporated to strengthen the description of results, methods, and evaluation scope.

read point-by-point responses

  1. Referee: Evaluation/Results: The reported peak throughputs (19.7 Mbit/s in 2d1g to 16.0 Mbit/s in 5d3g) and packet-loss figures are given as approximate values extracted from archived curves without error bars, number of trials, standard deviations, or raw data, which limits assessment of measurement reliability and variability.

    Authors: We appreciate the referee highlighting this limitation in the presentation of results. The peak values were derived from archived measurement curves obtained across multiple experimental runs per scenario. In the revised manuscript, we will explicitly report the number of trials conducted, add error bars or standard deviations to the throughput and packet-loss figures, and make the raw data available via a public repository to enable independent assessment of reliability and variability. revision: yes

  2. Referee: Methods and architecture description: The claim that relay-state management and subscription-based forwarding tables maintain consistency across multiple groups rests on the assumption of stable device behavior, but the evaluation provides no explicit verification (e.g., consistency checks, race-condition tests, or long-running runs) beyond noting operational success in static scenarios; this leaves open the risk of nondeterministic state from Android's single-group P2P semantics.

    Authors: We agree that explicit verification of state consistency would strengthen the claims. The current evaluation demonstrated operational success in static multi-group scenarios without observed inconsistencies, relying on the subscription-based forwarding tables to coordinate relay roles. In the revision, we will expand the methods section to describe the consistency mechanisms in greater detail and include any checks performed during the experiments (such as periodic validation of forwarding tables). We will also acknowledge the potential for nondeterminism arising from Android's P2P semantics and note extended consistency testing as future work. revision: yes

  3. Referee: Evaluation setup: All tests are confined to a five-device static testbed with no dynamic group formation, mobility, or extended-duration consistency validation, which is insufficient to support the broader architectural feasibility conclusion for multi-group forwarding.

    Authors: We concur that the evaluation is limited to a static five-device testbed. However, the manuscript conclusion already explicitly scopes the claims to feasibility in a small static testbed and states that the results do not establish broad resilience, scalability, or deployment readiness. In the revision, we will further emphasize these limitations in the evaluation and conclusion sections, clarify the distinction between architectural feasibility and broader operational claims, and outline dynamic group formation and mobility as directions for future work. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical implementation and measurement study

full rationale

The paper presents the design of SWARNET as a layered application-level architecture (Flutter + Kotlin sockets, relay-state management, subscription tables) and reports direct empirical measurements of throughput and packet loss from running the implemented artifact on five physical stock Android devices across four static scenarios. No mathematical derivations, equations, fitted parameters, or predictions appear in the provided text. The central claim of operational feasibility rests on observed device behavior rather than any reduction to inputs by construction, self-citation chains, or renamed known results. Self-citations are absent from the load-bearing sections. This is a standard honest empirical systems paper with no circularity.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The paper relies on standard Android APIs and device behavior assumptions rather than new parameters or entities.

axioms (2)
  • domain assumption Stock Android Wi-Fi Direct APIs can be used at application level for peer-to-peer without rooting.
    Assumed in the design for compatibility with Android 11.
  • domain assumption Relay roles and forwarding state can be coordinated entirely at application level.
    Central to the architecture to overcome interface-specific transport contexts.

pith-pipeline@v0.9.0 · 5639 in / 1463 out tokens · 36334 ms · 2026-05-10T18:11:28.266669+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

9 extracted references · 9 canonical work pages

  1. [1]

    Wi -Fi Direct (peer -to-peer or P2P) overview,

    Android Developers, “Wi -Fi Direct (peer -to-peer or P2P) overview,” 2026. [Online]. Available: https://developer.android.com/develop/ connectivity/wifi/wifip2p

    work page 2026

  2. [2]

    Create P2P connections with Wi -Fi Direct,

    Android Developers, “Create P2P connections with Wi -Fi Direct,” 2026. [Online]. Available: https://developer.android.com/develop/ connectivity/wifi/wifi-direct

    work page 2026

  3. [3]

    The Emergency Direct Mobile App: Safety message dissemination over a multi -group network of smartphones 22 using Wi -Fi Direct,

    M. Di Felice, L. Bedogni, and L. Bononi, “The Emergency Direct Mobile App: Safety message dissemination over a multi -group network of smartphones 22 using Wi -Fi Direct,” in Proceedings of the 14th ACM International Symposium on Mobility Management and Wireless Access , 2016, pp. 99 – 106

    work page 2016

  4. [4]

    Supporting multi -hop device- to-device networks through WiFi Direct multi -group networking,

    C. Funai, C. Tapparello, and W. Heinzelman, “Supporting multi -hop device- to-device networks through WiFi Direct multi -group networking,” arXiv:1601.00028, 2015

    work page arXiv 2015

  5. [5]

    Content-centric routing in Wi-Fi Direct multi-group networks,

    C. Casetti, C. -F. Chiasserini, L. Curto Pelle, C. Del Valle, Y . Duan, and P . Giaccone, “Content-centric routing in Wi-Fi Direct multi-group networks,” in 2015 IEEE 16th International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2015, pp. 1–9

    work page 2015

  6. [6]

    Group -to-group bidirectional Wi -Fi Direct communication with two relay nodes,

    A. Teófilo, D. Remédios, H. Paulino, and J. Lourenço, “Group -to-group bidirectional Wi -Fi Direct communication with two relay nodes,” in Proceedings of the 12th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services , 2015, pp. 275 – 276

    work page 2015

  7. [7]

    Android 6.0 changes: Access to hardware identifiers,

    Android Developers, “Android 6.0 changes: Access to hardware identifiers,”

    work page

  8. [8]

    Available: https://developer.android.com/ about/versions/marshmallow/android-6.0-changes

    [Online]. Available: https://developer.android.com/ about/versions/marshmallow/android-6.0-changes

    work page

  9. [9]

    ConnectivityManager.bindProcessToNetwork(Network),

    Android Developers, “ConnectivityManager.bindProcessToNetwork(Network),” 2026. [Online]. Available: https://developer.android.com/reference/android/net/ ConnectivityManager

    work page 2026