RTPS: Prioritizing "VIP" Nodes to Optimize Socially-Aware Ad-hoc Networks
Poster: reliable TCP for popular data in socially-aware ad-hoc networks
This paper introduces RTPS (Reliable TCP for Popular Data), a transport layer protocol designed for multihop Ad-hoc Social Networks (ASNETs). It leverages social metrics, specifically degree centrality, to prioritize bandwidth allocation and acknowledgment timing for "popular" nodes, achieving superior throughput and reduced latency.
TL;DR
Mobile Ad-hoc Social Networks (ASNETs) often suffer from "traffic jams" at popular nodes. This paper proposes RTPS (Reliable TCP for Popular Data), a protocol that uses Degree Centrality to redistribute bandwidth and optimize acknowledgment delays. By treating socially important nodes as "VIPs," RTPS increases throughput by up to 44.8% while significantly cutting down latency.
The Bottleneck: Why Standard TCP Fails Social Networks
In a multihop ASNET, the network isn't just a collection of random connections; it reflects social structures. Traditional TCP treats every packet as equal. However, in reality:
- Congestion Collapse: When multiple senders converge on one receiver, the limited bandwidth causes massive packet drops.
- ACK Interference: In multihop environments, data packets and Acknowledgments (ACKs) often collide on the same path, leading to a vicious cycle of retransmissions and dropped performance.
Previous solutions like TIBIAS or TCP-DAAp tried to fix this using social similarity or fixed delay windows, but they lacked a mechanism to prioritize the most critical nodes in the network graph.
Methodology: Socially-Aware Resource Allocation
The core innovation of RTPS is its perception of Node Popularity. It breaks down the transmission process into three distinct modules:
1. Link Capacity Computing Module (LCCM)
LCCM estimates the total available rate of the link and determines the optimal capacity to achieve full utilization without overwhelming the network.
2. Degree-Centrality based Rate Calculation Module (DRCM)
This is the "brain" of RTPS. Instead of equal sharing, it calculates a Desired Rate () for each sender based on its Degree Centrality—the number of social connections a node has.
- High Centrality = Higher Bandwidth Priority.
- The formula ensures a base minimum rate for all users, but the "surge" capacity is assigned to social hubs.
3. Popularity-aware Flow and ACK Control (PFAOCM)
To solve the collision issue, RTPS uses a Dynamic Delayed ACK strategy. If a packet comes from a popular node:
- It receives an earlier ACK to maintain it's high throughput.
- For other nodes, ACKs are delayed to reduce the frequency of packets on the channel, thereby reducing collision probability.

Experiments: Does Popularity-Based Routing Work?
The authors compared RTPS against TCP-DAAp and TCP-DCA in an 11 Mbps channel environment using AODV routing.
Key Performance Metrics:
- Throughput: RTPS achieved a 34.5% improvement over TCP-DAAp and a 44.8% improvement over TCP-DCA. The gains become more pronounced as the number of simultaneous connections increases.
- Latency: By prioritizing ACKs and bandwidth for popular nodes, the overall network latency dropped by roughly 31%.
- Bandwidth Fairness: Unlike traditional methods that struggle with "unfairness," RTPS intentionally skews bandwidth toward popular nodes, which surprisingly leads to better overall link utilization.

Critical Analysis & Takeaways
The beauty of RTPS lies in its Inductive Bias: the assumption that in a social network, data from "popular" nodes is inherently more valuable or frequent, and prioritizing it benefits the entire infrastructure.
Limitations:
- The study focuses heavily on Degree Centrality. In more dynamic environments, Betweenness Centrality (nodes that act as bridges) might be even more critical for congestion control than mere popularity.
- The evaluation is performed in a simulation environment; real-world radio interference and physical mobility might introduce more noise into the Link Capacity estimations.
Conclusion: RTPS proves that the transport layer shouldn't be "socially blind." By looking at the graph structure of the users, we can make smarter decisions about which packets to drop, which to delay, and which to fast-track.
