1 / 20

Distributed Channel Assignment for minimal islands of connectivity

This research paper explores the issue of addressing overlapping basic service sets (OBSS) scenarios in wireless networks. It evaluates various channel allocation algorithms to minimize the extent of connectivity graphs in realistic scenarios.

zoll
Download Presentation

Distributed Channel Assignment for minimal islands of connectivity

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. Distributed Channel Assignment for minimal islands of connectivity Authors: Date: 2009-03-06 Raghuram Rangarajan, Cisco Systems

  2. The proposal for TGaa to limit the addressed OBSS scenarios is unsatisfactory • It has been suggested that TGaa not address all OBSS scenarios • ie not address larger “extents” • However, user expectations mean that this is only a useful strategy if it works “most of the time” • Assumption: users will not accept their video working perfectly for 29 days and poorly on day 30 (invariably the day of a big event) • The open question is whether OBSS scenarios outside the scope of current proposals occur “frequently” enough to matter • The unfortunate answer is they do in realistic scenarios and so current proposals to address OBSS are unsatisfactory • This is before even considering some of the other “hard problems related to OBSS Raghuram Rangarajan, Cisco Systems

  3. Simulation shows scenarios outside scope of current proposals occur frequently enough • An AP layout in a typical residential location was simulated using: • A set of reasonable model parameters • The “extent” of “connectivity graphs” • A variety of channel allocation algorithms • Previous results show large extents result from the use of a “classic” channel selection algorithm in a typical scenario • New simulation work with refined channel selection algorithms shown large extents in many typical (and realistic) scenarios Raghuram Rangarajan, Cisco Systems

  4. An AP layout in a typical residential location was simulated Pool Distance (m) Raghuram Rangarajan, Cisco Systems

  5. A set of reasonable model parameters was selected • AP every 700 sq. ft. (approximate apartment size) • Or AP every 1400 sq. ft. (for larger apartments) • Transmit power 15dB • Transmit & receive gain 2dB • General loss at 1m is 47dB • Path loss 35dB every 10m • Floor decay 10dB per floor • 5-7dB shadowing variation • APs turn on randomly Raghuram Rangarajan, Cisco Systems

  6. The simulation uses the “extent” of “connectivity graphs” • Define a “connectivity graph” as: • an `island' of APs where every AP can be connected via edges to every other AP • Define “extent” of a connectivity graph as: • the minimum (across APs in the connectivity graph) • of the maximum (across pairs of APs) • of the shortest path (between a given pair of APs) Raghuram Rangarajan, Cisco Systems

  7. The simulation uses the “extent” of “connectivity graphs” Graph with 11 nodes. Extent of the graph is 3 Graph with 8 nodes. Extent of the graph is 1 Raghuram Rangarajan, Cisco Systems

  8. The simulation is based on a variety of channel allocation algorithms • There are a wide variety of channel allocation algorithms to establish a minimal extent network • The simulation explores a variety of obvious and optimal algorithms based on a basic framework • The algorithm framework is as follows: • The AP scans all channels and records the number and RSSIs of all APs per channel • The AP may also request the connectivity graph and related parameters of other APs • e.g. via Public Action request/response frames • The AP selects the best channel according to a first, second and third sort key Raghuram Rangarajan, Cisco Systems

  9. The simulation is based on a variety of channel allocation algorithms Typical 1st sort keys Typical 2nd sort keys Typical 3rd sort keys 1a) Channel with 0 APs 1b) Channel with minimum connectivity extent (after assigning the AP to that channel) 1c) Channel with minimum number of APs 2a) Channel with minimum number of edges in the connectivity graph (after assigning the AP to that channel) 2b) Channel with minimum number of vertices in the connectivity graph (after assigning the AP to that channel) 2c) Null (i.e. skip to the third sort key) 3a) Channel with minimum maximum (across neighboring APs) RSSI (i.e. join the most distant connectivity graph) 3b) Channel with maximum maximum (across neighboring APs) RSSI (i.e. join the nearest connectivity graph) 3c) Random Raghuram Rangarajan, Cisco Systems

  10. The simulation is based on a variety of channel allocation algorithms • The connectivity metrics are calculated after adding the AP to that channel • Since multiple small disjoint graphs may be connected into one large graph by adding the AP. • Different algorithms are created by selecting different sort keys. • 1a-2c-3a is a classic algorithm that tries to find an empty channel, or the channel with most distant APs. • 1b-2c-3b is better to minimize the connectivity extent • Cost and complexity of obtaining metrics is assumed to be zero • Yet clearly obtaining up-to-date topology information is complicated, incurs overhead, and any information may be readily spoofed • Most complicated after a power cut, where APs are dynamically choosing channels, changing the topology moment by moment Raghuram Rangarajan, Cisco Systems

  11. The simulation is based on a variety of channel allocation algorithms • In the following graphs, we compare the performance (in terms of connectivity extents) of the following algorithms • Classical approach: 1a-2c-3a • One example of extent-optimal algorithm: 1b-3b • 1b-3c • 1b-3a • 1b-2b-3b • 1b-2b-3a • Other variations could also be tried and evaluated for performance Raghuram Rangarajan, Cisco Systems

  12. Previous work shows large extents result from the use of classic 1a-2c-3a algorithm in a typical scenario • The use of the classic 1a-2c-3a algorithm results in a large extent • See 08/1250 • Centralized scheduling in this case is very challenging • Can we do better? Raghuram Rangarajan, Cisco Systems

  13. New simulation work with new algorithms show large extents in many typical scenarios • The results of the simulations show large extents in many typical scenarios • All algorithms simulated at 2.4GHz (with three channels) result in unsatisfactorily large extents • Insensitive APs using 20MHz channels worked most of the time at 5GHz, but it is not a realistic scenario • Insensitive APs using 40MHz had an extent >1 up to 8% of the time at 5GHz, but it is not a realistic scenario • Sensitive APs using 40MHz commonly had large extents at 5GHz, with associated challenges • This is even before addressing denser situations like Manhattan or Hong Kong Raghuram Rangarajan, Cisco Systems

  14. All algorithms simulated at 2.4GHz (with three channels) result in unsatisfactorily large extents • Assumptions • Channels = 3 @2.4GHz • AP sensitivity = -82dBm • All algorithms simulated at 2.4GHz (with three channels) result in large extents • This is unsatisfactory in the context of OBSS resolution Raghuram Rangarajan, Cisco Systems

  15. Insensitive APs using 20MHz channels worked most of the time at 5GHz, but it is not a realistic scenario • Assumptions • Channels = 20,20MHz @5GHz • Sensitivity of APs =-82dBm (insensitive) • All algorithms perform very well: • Optimal algorithm: 100% extent of 1 • Classic algorithm: 2% with extent >1, ie 2% are problematic • Unfortunately 11n at 20 MHz is less realistic Only classic and optimal plotted as all minimal extent approaches are similar Raghuram Rangarajan, Cisco Systems

  16. Insensitive APs using 40MHz had an extent >1 up to 8% of the time at 5GHz, but it is not a realistic scenario • Assumptions • Channels = 10,40MHz @5GHz • Sensitivity of APs =|-82dBm (insensitive) • The classic algorithm performs poorly • Other algorithms perform well but still leave 4-8% beyond an extent of 1, with associated scheduling and sync challenges • However, in the era of 11n, -82 dBm sensitivity is less realistic Raghuram Rangarajan, Cisco Systems

  17. Sensitive APs using 40MHz commonly had large extents at 5GHz, with associated challenges • Assumptions • Channels = 10,40MHz @5GHz • Sensitivity of APs =|-95dBm (sensitive) • All algorithms performs poorly, with extents of 2-3-4 • Sync and scheduling are very challenging in this environment Raghuram Rangarajan, Cisco Systems

  18. The current OBSS proposals are unsatisfactory given they do handle large extents • Islands of connectivity with large extent happen in a sufficiently interesting number of cases that we need to be concerned about them • And yet the current OBSS proposals do not address them, except by suggesting dropping back to EDCA • However, simply dropping to EDCA remains problematic • Either 11aa’s OBSS work adds nothing to the user experience in which case we should not bother • Or it adds something, but then dropping to EDCA operation is unsatisfactory for users previously enjoying the fruits of 11aa’s labors Raghuram Rangarajan, Cisco Systems

  19. The simulations avoided the other hard problems related to OBSS • Channel assignment is but one piece of the OBSS puzzle • Other known problems include • Communications overhead • The problems of sync (now “easy”) • Distributed scheduling (now “easier”) • Fairness (?) • Trust/security (tough across administrative domains) • non-AP STA relaying (PS?) Raghuram Rangarajan, Cisco Systems

  20. The bottom line is that OBSS remains a hard problem without good answers • OBSS is hard and has been known to be so ever since an attempt was made to resolve it in TGe • Any complete solution is going to have to address more scenarios • And many of the other challenges that we are now ignoring • The TG should avoid jumping to a solution unless there is consensus that the solution is workable – this is a standardisation organisation after all and not a research organisation Raghuram Rangarajan, Cisco Systems

More Related