MAC enhancements for Media Independent RF Management of Wireless 802 Networks

1. MAC enhancements for Media Independent RF Management of Wireless 802 Networks Floyd Backes, Propagate Networks Michael Montemurro, Chantry Networks Backes, Montemurro

2. Overview • What is RF management • Problem Definition • Changing personalities • SDRs and Cognitive Radio • An example • Proposed Solution • Consistency across MACs • First need is for common, well defined interface • Interface abstraction Backes, Montemurro

3. Brief Intro to IEEE 802 Wireless Networks • Various MACs exist or are under development • E.g. 802.11, 802.16, 802.15.1, 802.15.3, 802.15.4, 802.20, 802.22 • 802.21 addresses how to hand-off between different MAC types. • I will talk about 802.11 as an example • Infrastructure vs. Ad Hoc • I will talk about Infrastructure as an example Backes, Montemurro

4. RF Management • Sometimes it’s useful to: • cause the APs to select different channels • In order to avoid “co-channel interference” • In order to distribute energy across the spectrum over a given geographical area • adjust the transmit power • See above • Enhanced privacy • direct STAs to associate to certain APs • For load balancing purposes • To manage interference issues • For other considerations of QoS • To enforce other sorts of policies • enquire of APs and STAs their sense of the RF environment • E.g. what other STAs and APs can you hear and at what signal strength? • Detection of “Rogue APs” • Detection of attempted intrusions • To gather locality information about APs or STAs • do stuff we haven’t even thought of yet Backes, Montemurro

5. Some things That Wireless MACs Have in Common • A radio • One or more channels • The ability to interfere and to be interfered with • STAs or MSUs are not physically connected to the network • In wired LANs, physical connection provides a hint about what network a device should belong to • Concept of “associations” Backes, Montemurro

6. Why does this require standardization? • No standard statistics reporting mechanisms • Different chip sets report signal strength in different ways • Sometimes just a relative signal strength (RSSI) in dB • Sometimes an absolute power measurement in dBm Backes, Montemurro

7. Why does this require standardization? • No standard control plane for security mechanisms • There is no standard interface to set transmit power • Management applications must muck about in the chip driver • Management applications must be ported individually to every bit of hardware • No standard QoS mechanisms • No standard encryption mechanisms Backes, Montemurro

8. Why does this require standardization? • There is no interoperability between different management applications • MIBs are not up to date • MIBs are inconsistent across different MACs • Boxes will be built that will interconnect different wireless technologies (e.g. 802.16 to connect to the ISP, and 802.11 to connect to the home LAN). • 802.21 addresses how to hand off, not why Backes, Montemurro

9. Why interoperability is so important for Wireless Networks • All the afore mentioned reasons plus: • Radio waves do not respect administrative boundaries • Neighbors cannot cooperate on channel selection even if they wanted to • Increasingly dense deployments, and all the APs don’t belong to the same owner! • You can control access but you can’t control the laws of physics Backes, Montemurro

10. Why does this require standardization? The lack of a standard RF management interface for different implementations of a given MAC as well as different wireless MACs prohibits multi vendor, interoperable wireless network management Backes, Montemurro

11. Historical Motivation for Consistency Across MACs • 802.11 utilizes a huge installed base of wired 802.3 • All this stuff is supposed to work together • success of 802.11 was due in large part to the extent that it worked well with 802.3 Backes, Montemurro

12. Beyond Motherhood and Apple Pie • Even more compelling technical reasons • Stability • Determinism Backes, Montemurro

13. Cognitive Radio and SDR • Software defined radios will mean that connections may morph from one media access method to another to another • Cognitive capabilities will benefit SDRs • A radio which is cognizant of it’s RF environment will offer much greater quality of service Backes, Montemurro

14. Analogy • A SDR changing from 802.11b to 802.11a is analogous to a node automatically selecting between 100 BT or 10 BT, except that when the SDR (PHY) adapts it may be switching to a different AP or even a different network! • If Radios can switch from 802.11a to 802.11b, they will eventually be able to switch to 802.15, 802.16, 802.20 or other technologies (802.21 facilitates this) • Consistent mechanisms to determine when to switch are highly desirable Backes, Montemurro

15. Example • Imagine a system that would evenly distribute users across a set of resources, based on service level, load and $$ • For a simple example, let’s say a set of 802.11 STA across a set of 802.11 APs • Stability is a requirement! Backes, Montemurro

16. APs and STAs = Access Point = Station (STA) An “Association” “Distribution Service” (DS) – often a wired LAN Backes, Montemurro

17. This is A Control System • Requires consistent expectations about what is being measured and for how long • In order to make the system stable it is extremely helpful to have: • Consistent expectations about delay and gain when making measurements • Consistent expectations about delay and gain when rearranging the topology Backes, Montemurro

18. Imagine Doing this Across Multiple Technologies Stability is required yet… • Information about the topology and how long it takes to obtain it varies from MAC to MAC • The algorithm and metrics to make decisions to change the topology vary from MAC to MAC Backes, Montemurro

19. The plot thickens • The system quickly becomes complex • A change in a timing parameter in one part of the system has complicated effects on the rest of the system Backes, Montemurro

20. Why commonality is needed Anytime a device has the option of operating in more than one kind of environment at the same time, or that may switch from operating in one environment to another or n other environments and back again, it had better be following a consistent set of rules for choosing which environment to operate in, lest it run the risk of never making up its mind. Backes, Montemurro

21. Historical Analogy • Source Routing versus Transparent Bridging • Eventually 802 mandated interoperability which led to: • ST-TB bridges • SRT Bridges • Experience in developing those standards taught that achieving a stable system with deterministic behavior was the greatest challenge Backes, Montemurro

22. Bridging Interoperability • That was back in the days when end points more or less: • remained fixed to a single connection point • more or less stayed acting like the same kind of MAC • Today: • end points can change personalities at will • can instantly roam to any other logical point in the network at any time! Backes, Montemurro

23. Assertion Common management and common configuration algorithms are essential to the long term viability of heterogeneous LAN Backes, Montemurro

24. What I propose to be done Start with: • Consistent RF Management Architecture • Consistent set of additional MSDU parameters • Consistent set of MAC Status Parameters Backes, Montemurro

25. Example RF Management Architecture Backes, Montemurro

26. Example MSDU Parameters • received_power_level (dBm) • transmitted_power_level (dBm) Backes, Montemurro

27. Example MAC Status Parameters • known_BSS • base_BSS • load_factor • path_loss • max_power • receive_treshold Backes, Montemurro

28. Why 802.1 • This issue spans all wireless MACs • This is architecture • 802.1has the most protocol expertise • 802.1 has the most management expertise • 802.1 is the logical place to eventually work on applications which may make use of the interface Backes, Montemurro

29. Conclusions • A management interface that is consistent across all MACs is needed to insure interoperability and stability • There are lessons to be learned from the past • A common management interface should come first • The work should be done in 802.1 Backes, Montemurro

30. Backup slide – Real problems • Addressing in dual radio APs • Some share a common BSS on both radios • Some assign each radio a different BSS • Makes roaming and load balancing a bear • Single radio, dual band APs • When should you be 802.11a? 802.11b? • Leads to bad behavior in some network configurations Backes, Montemurro

31. Backup slide – Real problems • No agreed upon AP architecture model • Leads to inconsistencies in how and what gets tunneled to a WLAN switch • Makes it difficult to design automatic configuration protocols • No agreed upon DS architecture model • Can’t tell from looking at the standard what behavior to expect of management and control protocols • in heterogeneous LANs, STAs show up in multiple places Backes, Montemurro

32. Backup slide – Real problems • Management of heterogeneous WLANs is a headache • Different set of management and configuration tools needed for each brand of gear • Interoperability problems between gear based on different chipsets • Certification doesn’t catch everything, because there is no architecture on which to base the certification • Channel conflicts between neighbors • People are walking door to door • Necessity for neighborhood “Channel Map Committees” Backes, Montemurro

33. Backup slide – Real problems • Configuration problems • 33% of residential customers call the help desk • High return rates • Unhappy customers Backes, Montemurro