November 2004 doc IEEE 802 1 04xxxr 0

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

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 2 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 3 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Qo. S 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 Tutorial 4 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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” Tutorial 5 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 d. B – Sometimes an absolute power measurement in d. Bm Tutorial 6 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Qo. S mechanisms • No standard encryption mechanisms Tutorial 7 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 8 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 9 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 10 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 11 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Beyond Motherhood and Apple Pie • Even more compelling technical reasons – Stability – Determinism Tutorial 12 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Cognitive Radio and SDR • Software defined radios will mean that connections may morph from one media access method to another • Cognitive capabilities will benefit SDRs – A radio which is cognizant of it’s RF environment will offer much greater quality of service Tutorial 13 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Analogy • A SDR changing from 802. 11 b to 802. 11 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 802. 11 a to 802. 11 b, 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 Tutorial 14 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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! Tutorial 15 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 APs and STAs = Access Point = Station (STA) An “Association” “Distribution Service” (DS) – often a wired LAN Tutorial 16 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 17 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 18 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 19 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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. Tutorial 20 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 21 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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! Tutorial 22 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Assertion Common management and common configuration algorithms are essential to the long term viability of heterogeneous LAN Tutorial 23 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 What I propose to be done Start with: • Consistent RF Management Architecture • Consistent set of additional MSDU parameters • Consistent set of MAC Status Parameters Tutorial 24 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Example RF Management Architecture Tutorial 25 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Example MSDU Parameters • received_power_level (d. Bm) • transmitted_power_level (d. Bm) Tutorial 26 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Example MAC Status Parameters • known_BSS – base_BSS – load_factor – path_loss – max_power • receive_treshold Tutorial 27 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Why 802. 1 • This issue spans all wireless MACs • This is architecture – 802. 1 has 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 Tutorial 28 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 29 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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. 11 a? 802. 11 b? – Leads to bad behavior in some network configurations Tutorial 30 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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 Tutorial 31 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 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” Tutorial 32 Backes, Montemurro

November 2004 doc. : IEEE 802. 1 -04/xxxr 0 Backup slide – Real problems • Configuration problems – 33% of residential customers call the help desk – High return rates – Unhappy customers Tutorial 33 Backes, Montemurro