doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 1 MAC enhancements for Media Independent RF Management of Wireless 802 Networks Floyd Backes, Propagate Networks Michael Montemurro, Chantry Networks

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 3 Brief Intro to IEEE 802 Wireless Networks Various MACs exist or are under development –E.g , , , , , , addresses how to hand-off between different MAC types. I will talk about as an example Infrastructure vs. Ad Hoc –I will talk about Infrastructure as an example

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 4 RF Management Sometimes its 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 havent even thought of yet

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 6 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 Why does this require standardization?

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 7 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 Why does this require standardization?

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 8 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 to connect to the ISP, and to connect to the home LAN) addresses how to hand off, not why Why does this require standardization?

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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 dont belong to the same owner! You can control access but you cant control the laws of physics

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 10 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 Why does this require standardization?

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 11 Historical Motivation for Consistency Across MACs utilizes a huge installed base of wired All this stuff is supposed to work together –success of was due in large part to the extent that it worked well with 802.3

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 12 Beyond Motherhood and Apple Pie Even more compelling technical reasons –Stability –Determinism

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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 its RF environment will offer much greater quality of service

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 14 Analogy A SDR changing from b to a 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 a to b, they will eventually be able to switch to , , or other technologies ( facilitates this) Consistent mechanisms to determine when to switch are highly desirable

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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, lets say a set of STA across a set of APs Stability is a requirement!

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 16 APs and STAs = Access Point = Station (STA) Distribution Service (DS) – often a wired LAN An Association

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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.

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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!

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 23 Assertion Common management and common configuration algorithms are essential to the long term viability of heterogeneous LAN

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 25 Example RF Management Architecture

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 26 Example MSDU Parameters received_power_level (dBm) transmitted_power_level (dBm)

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 27 Example MAC Status Parameters known_BSS –base_BSS –load_factor –path_loss –max_power receive_treshold

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 28 Why This issue spans all wireless MACs This is architecture –802.1has the most protocol expertise –802.1 has the most management expertise is the logical place to eventually work on applications which may make use of the interface

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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 a? b? –Leads to bad behavior in some network configurations

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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 –Cant tell from looking at the standard what behavior to expect of management and control protocols –in heterogeneous LANs, STAs show up in multiple places

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 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 doesnt 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

doc.: IEEE /xxxr0 Tutorial November 2004 Backes, MontemurroSlide 33 Backup slide – Real problems Configuration problems –33% of residential customers call the help desk –High return rates –Unhappy customers