Searcharxiv⌕ Search

arXiv · 0710.0789

Wireless Local Area Networks with Multiple-Packet Reception Capability

Abstract

Thanks to its simplicity and cost efficiency, wireless local area network (WLAN) enjoys unique advantages in providing high-speed and low-cost wireless services in hot spots and indoor environments. Traditional WLAN medium-access-control (MAC) protocols assume that only one station can transmit at a time: simultaneous transmissions of more than one station causes the destruction of all packets involved. By exploiting recent advances in PHY-layer multiuser detection (MUD) techniques, it is possible for a receiver to receive multiple packets simultaneously. This paper argues that such multipacket reception (MPR) capability can greatly enhance the capacity of future WLANs. In addition, it provides the MAC-layer and PHY-layer designs needed to achieve the improved capacity. First, to demonstrate MUD/MPR as a powerful capacity-enhancement technique, we prove a "super-linearity" result, which states that the system throughput per unit cost increases as the MPR capability increases. Second, we show that the commonly deployed binary exponential backoff (BEB) algorithm in today's WLAN MAC may not be optimal in an MPR system, and that the optimal backoff factor increases with the MPR capability: the number of packets that can be received simultaneously. Third, based on the above insights, we design a joint MAC-PHY layer protocol for an IEEE 802.11-like WLAN that incorporates advanced PHY-layer blind detection and MUD techniques to implement MPR

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Ying Jun Zhang, Peng Xuan Zheng, Soung Chang Liew. 2007-10-03. Wireless Local Area Networks with Multiple-Packet Reception Capability. https://arxiv.org/abs/0710.0789

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Caching Policies based on Object Sizes

We evaluate eviction policies that consider the lengths of the objects being cached for different cache sizes (cost) and different workloads. Workloads include the Independent Reference Model and real-world production traces. In particular, hybrid policies are considered for segmented caches. A working-set approximation is developed for SIEVE as well as its length-aware extension.

cs.PF↗

Top-Down Microarchitecture Analysis Without Causal Modelling Is Dangerous!

Top-Down Microarchitecture Analysis (TMA) is the standard for identifying CPU bottlenecks. However, TMA implicitly models performance via a single causal path: Workload(dataset, algorithm) => CPU(CPI) => System(Performance) (microarchitectural efficiency path). It overlooks two hidden causal paths: Workload(dataset, algorithm) => Instructions(Retired) => System(Performance) (algorithmic efficiency path) and Workload(dataset, algorithm) => Instructions(Retired) => CPU(CPI) => System(Performance) (microarchitecture-algorithm efficiency path). This causal blindness often misleads architects into futile hardware optimizations. To address this, we propose Causal Top-Down Microarchitecture Analysis (CTMA). Utilizing the object causal model, CTMA explicitly models these three causal paths among the workload, instructions, CPU, and system. We validate CTMA across Intel, AMD, and ARM platforms. Our experiments reveal counterintuitive insights: (1) CPI Profiling Blindness: Algorithmic instruction bloat can double elapsed time while the CPI profile remains frozen. (2) Over-Speculation Congestion: Throttling the Frontend paradoxically improves performance in pointer-chasing algorithms. (3) ILP Window Collapse: Extreme data topologies shift bottlenecks from Backend ROB capacity to Frontend fill-rate starvation. (4) Op-Cache SMT Overlap: Ultra-small footprints yield SMT speedups on Intel but cause severe thrashing on AMD. (5) "Ghost State" Artifact: Stale pipeline mitigations on Intel Xeon Gold 5120T artificially boost performance by 22.75% on SPEC CPU2017 and 42.2% on SPEC CPU2026. Based on this, we propose a dynamic speculation throttling mechanism.

cs.PF↗

How the Dirty Set Moves: Characterizing Schedule Reuse in Incremental Sparse Matrix Multiplication

Sparse matrices, in which most entries are zero, are central to scientific simulation, graph analytics and machine learning, and their multiplication with dense inputs is a core parallel kernel. In many applications the matrix stays fixed while only a few input rows change per step, so the result can be updated from those rows alone, which we call the dirty set. Sparse kernels often add a second optimization based on the inspector-executor principle, in which a tiled schedule is prepared once and reused across calls. However, when this reuse remains profitable as the dirty set moves is not well characterized. In this paper, we show that retained tiled execution rarely beats direct CSC in incremental sparse matrix multiplication, although incremental execution itself remains highly profitable. Across 21 SuiteSparse matrices and controlled patterns of motion, a direct column-wise incremental update is 2.1-8.2x faster than the best of eight full-recomputation codes, among them Intel oneMKL and PyTorch. Yet the same direct update outperforms a tiled executor that retains tile preparation and caches assembled schedules in 779 of 837 workloads. Separating reuse into per-tile preparation and cached schedules shows that the benefit comes from preparation; extra cache capacity seldom helps because a tile set rarely returns after a different one has intervened. Tiling is faster only when tiles merge many entries into each output write, a structural property that we predicted before measurement and confirmed on four held-out matrices of the same family. These results show that the structure of the matrix and the motion of the dirty set, rather than the sophistication of the schedule, determine whether reuse is profitable. We anticipate that our methodology and guidelines will help developers decide when to build schedule reuse into incremental sparse runtimes.

cs.PF↗