My threshold for a satisfactory OBSS solution

1. My threshold for a satisfactory OBSS solution Authors: Date: 2008-10-31 Brian Hart, Cisco Systems

2. Abstract • Overlapping Use Case • State of the Art • Four technical problems of scheduled access: • Synchronization • Absolute or Relative • Scheduling • Fairness • Trust • Non-AP STA relaying • Summary Brian Hart, Cisco Systems

3. Overlapping Use Case Brian Hart, Cisco Systems

4. State of the Art • HCCA for an isolated Point Controllers (PCs) • Problems when PCs attempt to schedule the same time in the same neighborhood • How might a scheduling scheme extend to the general OBSS problem? • A focus area of 11aa, & the topic of this presentation • EDCA-AC with acceptance of overlapped admission controllers • Also a focus area for 11aa Brian Hart, Cisco Systems

5. Synchronization • In order for overlapping PCs to avoid each others’ time allocations (“allocs”), they first need to agree on a time frame of reference • i.e. Synchronization • Typically, PC1 is in range of PC2 is in range of PC3 is in range of PC4, etc so pairwise sync is inadequate – we need solutions for large areas • Absolute (“global”) Sync – think GPS • Relative Sync – think tracking your neighbors’ offsets Brian Hart, Cisco Systems

6. Approach to Absolute Time Synchronization • GPS in every device and good sky access (haha), or • A few devices with good GPS time references declare themselves as GPS Level 0 references • Use a tree to distribute time to GPS-incapable neighbors and neighbors of neighbors • Other devices • Lock to the best reference (lowest Level and error stddev) as their parent. Define the parent to be Level n-1 • Measure the error stddev of their clock wrt the Level n-1 parent • Report themselves as Level n and having some measured stddev, for the benefit of Level n+1 devices • Self forming and self-healing tree • If no GPS master in an area, a non-GPS device is elected as sync master, and the sync domain forms around them • But GPS is still preferred when a GPS-enable becomes available Brian Hart, Cisco Systems

7. Residual Problems with Absolute Time Sync • Requires an adequate proportion and distribution of GPS-enabled devices to limit the size of each sync domain • E.g. Every consumer device includes GPS, and the few with good sky views become sync masters • But large scale, dynamic and practical effects are troubling • What if no-one has GPS working? • A sync master is elected • Since errors accumulate, then the maximum tree depth is limited, say to M hops. • Nodes at Level M+1 and above must form their own sync domain • Without GPS, we have adjacent unsynchronized sync-domains • In static environments, sync domains could partition themselves at boundaries of larger pathloss to maximize C/I between sync domains • If one GPS device is added some distance from the master of a non-GPS-rooted sync tree, then the tree has to completely reform centered on the GPS device • If the one GPS device is mobile, the sync tree continuously reforms around it • What if one device has hyper-cost-reduced GPS, was built on Friday afternoon, had a bad experience with an oven once, then another bad drop experience, and is running 20degC over its design temperature, yet is still advertising itself as a GPS master? • But, this is a weak candidate as GPS is expensive for the home Brian Hart, Cisco Systems

8. Problem with Relative Time Synchronization • Overlapping PCs may start by scheduling disjoint time “allocs” • But without sync these allocs slide over time • Assuming a fixed frequency offset, an “alloc collision” will occur when two PCs’ allocs first overlap Brian Hart, Cisco Systems

9. Approach to Relative Time Synchronization • Each PC continuously determines its time and frequency offset to all its neighbors • But doesn’t change its own clock • Allocs need to be predictable – regular period and duration • Yet BC/MC after DTIM is like a variable-length alloc • Alloc collisions are predicted, and avoided by temporarily time-shifting the allocs • 11aa defines a suitable rule: e.g. newer allocs adapt to older allocs, temporary time shifts are advertised ahead of time • Prediction and avoidance is harder and less reliable with more PCs, greater frequency offsets, imperfect clocks (phase noise, micro-jumps, temp-variation, aging etc), and when a higher percentage of the medium is allocated • Bonus: PCs could gently adjust their clocks over time to the local mean of the neighborhood • This reduces the rate of alloc collisions • Seems a weak candidate if allocs are limited to say 30% of the medium time and remaining (unsynchronized) time is still accessed via contention Brian Hart, Cisco Systems

10. Scheduling • Distributed scheduling is NP-hard • Therefore we must expect suboptimal performance • Need to check if it even beats EDCA • Step 1: Using 11k-like mechanisms, each PC determines which devices are neighbors • Step 2: PCs broadcast their schedules and use these broadcasts to determine the schedules of their neighbors • Schedules need to be long lived • Step 3: PCs avoid scheduling time already reserved by other PCs • Step 4: PCs can compare their respective loads and request/grant time from each others if joint QoS can be improved • Akin to MDA in 802.11s, yet with absolute/relative sync TBD • Like MDA, schedules are not respected by nearby non-MDA devices Brian Hart, Cisco Systems

11. Hand-Waving Scheduler • At its simplest, create logical orthogonal channels by converting N overlapping APs on 1 physical channel to N APs on N logical channels where every Nth slot is assigned to each AP • Actually due to complicated overlap graphs and the complexity of searching even for a feasible solution, it is likely that every Mth >> Nth slot is assigned to each AP • More sophisticated algorithms may assign more slots to APs with greater traffic requirements • And/or keep some proportion of slots spare for contention-based access Brian Hart, Cisco Systems

12. Fairness • Fairness – open-ended debate – enough said Brian Hart, Cisco Systems

13. Trust • Adjacent homes are disjoint trust domains • Manual authorization • Householder Alice creates public and private “neighborhood” keys • Alice contacts a neighbor, Bob, promises her AP is (and will continue to) run a WiFi-certified SW image, and asks Bob to add Alice’s AP (with the given public neighborhood key) to Bob’s AP as a trusted STA • Bob trusts Alice and agrees • Repeat for each neighboring Bob, for each householder Alice, every few months • User experience can be improved yet still ultimately depends on neighbors explicitly choosing to trust other neighbors • Reputation • Depends on identity over time • Packets are identified by MAC addresses • MAC addresses are easy to fake • Reputation requires a change to the security model so that MAC addresses cannot be faked (e.g. add a MIC to each packet using a new “neighborhood” key?) • Erratic system behavior; harder to troubleshoot • Both, other …? Brian Hart, Cisco Systems

14. Non-AP STA Relaying • A non-AP STA between two PCs that don’t see each other needs to relay sync, scheduling, fairness and trust information between PCs • Increases sync errors • Increases schedule distribution delay • And power requirements upon non-AP STAs • More complicated trust model • E.g. PC distributes its private neighborhood key to its associated STAs, then hopes they’ll forget the key once unassociated • Probably nothing fatal here Brian Hart, Cisco Systems

15. Summary • Overlapping networks are typical in home WLANs • EDCA-AC is already proven in the enterprise • A scheduling system needs 5 problems to be solved • There are candidate sync solutions: • Absolute sync solutions using GPS • Relative sync solutions that track neighbors’ schedules and continuously adapt to avoid collisions • Distributed scheduling is NP-hard so an actual scheduler in high OBSS will not be super-efficient • Need to check if it even beats EDCA • Isolated APs can still get great results • Fairness – open-ended debate – enough said • Trust • Adjacent homes are disjoint trust domains • This might be surmounted, via manual means, or via reputation with new security features • Non-AP STA relaying Brian Hart, Cisco Systems

16. Open Ended Thoughts • OBSS is a very hard problem • A distributed scheduling system is a hard engineering problem • The successful operation of your product is much more closely dependent on the bug-free operation of another vendor’s product • The benefits of a distributed scheduling system are low until a high proportion of APs support the system • Non-WiFi products will never support a distributed scheduling system • Can we convince ourselves that this is a good direction for the industry? Brian Hart, Cisco Systems