Backend
Re-Planning Budgets under Admission Control in Grant-Free LEO Beam-Hopping Access
arXiv math.IT0 views
arXiv:2611.07592v1 Announce Type: cross Abstract: Reordering low-Earth-orbit (LEO) beam-hopping visits can reduce grant-free update delivery even when each region receives the same service time. We derive the largest limit on inter-frame position changes that meets a prescribed delivery-rate loss tolerance when every group is visited once per frame. The guarantee concerns a protected beam's spatially averaged long-run delivery rate relative to optimized periodic service under exogenous re-planning. Fixed admission can favor irregular visits, whereas admission optimized for each revisit interval makes the per-visit reward concave under sufficient conditions on transmission success. Periodic service is then optimal at a fixed mean interval. The shortest and longest allowed intervals determine the exact worst-case loss, attained by feasible alternating visit orders that respect every group's displacement limit. The resulting budget requires no estimate of the revisit-interval distribution and extends to independent stationary renewal updates. In a collision example with 40 groups and 40 resources per slot, increasing the loss tolerance from zero to 1% raises the limit from 17 to 24 positions. With independent priorities, the latter retains over 90% of the priority-weighted waiting-cost reduction achieved by unrestricted ordering. Received-power simulations under Rayleigh fading support the predicted loss.
Source:https://arxiv.org/abs/2611.07592PreviousDesign of a Speech Enhancement-Based Deep Semantic Autoencoder for Wireless CommunicationsNextJoint Flexible Beamforming, Resource Allocation, and Task Buffering for Movable-Antenna Enabled MEC Systems
Related posts
Designing an AI incident agent for 3 a.m.: making memory visible
0dev.to UX
From Best Buy To Meta Lab: The Current XR Retail Experience
0dev.to UX
Stamp an Expiry on Every AI Approval Before the Agent Acts
0dev.to UX
Same AI, two answers: what happened when we gave our on-call agent a memory
0dev.to UX
Same AI, two answers: what happened when we gave our on-call agent a memory.
0dev.to UX
Same AI, two answers: what happened when we gave our on-call agent a memory..
0dev.to UX