1 / 16

Collaborative Spectrum Management for Reliability and Scalability

Collaborative Spectrum Management for Reliability and Scalability. Heather Zheng Dept. of Computer Science University of California, Santa Barbara. The Critical Need for Dynamic Spectrum Management. Explosion of wireless networks and devices Static spectrum assignments are inefficient

becca
Download Presentation

Collaborative Spectrum Management for Reliability and Scalability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Collaborative Spectrum Management for Reliability and Scalability Heather Zheng Dept. of Computer Science University of California, Santa Barbara

  2. The Critical Need for Dynamic Spectrum Management • Explosion of wireless networks and devices • Static spectrum assignments are inefficient • Under-utilization + over-allocation • Artificial spectrum scarcity • Solution: Migrate from long-term static spectrum assignment to dynamic spectrum access

  3. Challenges Facing DSA Dynamic, Heterogeneous Spectrum Demand Dynamic, Heterogeneous Spectrum Availability Large number of nodes Manhattan (Courtesy of Wigle.net)

  4. outage Requirements for DSA • Scalability and speed • Support a large number of nodes • Adapt to time-varying demands • Efficiency + Fairness • Maximize spectrum utilization • Avoid conflict • Reliability • Provide QoS • Minimize outages

  5. A Few Observations

  6. Collaborative Spectrum Allocation Goal: Allocate spectrum to maximize system utility Assumption: 100% willingness to collaborate Node Collaboration • Action: Iterative Explicit Coordination • Self-organize into coordination groups • Negotiate to allocate spectrum in each group • Iteratively set up groups to improve utility • Fast convergence: coordination stops when no local improvement can improve utility Cao & Zheng, SECON 2005, Crowncom07, JSAC08, MONET08

  7. Analytical Properties Fast Convergence: The system converges after at most O(N2) local adjustments, N= network size Node Collaboration Guaranteed Spectrum Allocation: Each node n’s allocated spectrum A(n) ≥ Poverty Line PL(n) Cao & Zheng, SECON 2005 Total usable spectrum Conflict degree

  8. Tightness of Poverty Line Percentage of Instances A(n)/PL(n)

  9. Bandwidth-Aware Poverty Line • Each channel i has a weight of Bi(n) • Each node’s spectrum allocation A(n)= ∑ ai(n)Bi(n) • Extended poverty line A(n) > PL(n) Cao & Zheng, Crowncom07

  10. Traffic-Aware Poverty Line • Each infrastructure node n supports tn users • Maximize end-user fairness • Each infrastructure node’s spectrum has a lower bound

  11. Making it Work in Practice: Distributed Coordination Protocol • Poverty line is an integrated knowledge about spectrum sharing • Use it to initiate coordination • Enable multiple parallel coordination events • Minimize adaptation delay

  12. Simulations: Coordination Delay # of Local coordination scales linearly with the # of APs Adaptation delay flattens out because of parallelism. 1Mbps Wireless Backhaul running CSMA/CA among APs

  13. Rule Regulated Spectrum Allocation Goal: Allocate spectrum to maximize system utility Assumption: comply to rules, no handshaking Implicit Coordination • Action: Iterative Independent adjustments • Nodes observe spectrum usage in proximity • Independently adjust self spectrum usage • Regulated by predefined rules Poverty Line based Rules: Rely on poverty line to determine whether to adjust and how to adjust. The same analytical Poverty Line Bounds and O(N2) complexity Zheng & Cao, DySPAN 2005 JSAC 2008

  14. Required Hardware Functionality • Conflict Detection • Explicit coordination  A control path among conflicting peers • Implicit coordination  Sophisticated environmental sensing module • Non-contiguous spectrum usage • Behavior enforcement

  15. outage From Adaptation to Reliability See LiliCao’s Poster Tomorrow

  16. Lessons Learned • Much of large-scale distributed wireless systems depend on mutual cooperation • To build robust systems that can be deployed in real life, we need to be flexible in our design to allow for flexible levels of cooperation • Hybrid architecture helps to provide reliability • Controlled regulation at a coarse time-scale • Individual adaptation at a fine time-scale • Interference makes it very challenging • Current: Simplification via conflict graph • Future: Addressing physical interference constraints

More Related