November 2004
Backes, MontemurroSlide 1
doc.: IEEE 802.1-04/xxxr0
Tutorial
MAC enhancements for Media Independent RF Management of
Wireless 802 Networks
Floyd Backes, Propagate NetworksMichael Montemurro, Chantry Networks
November 2004
Backes, MontemurroSlide 2
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 3
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 4
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 5
doc.: IEEE 802.1-04/xxxr0
Tutorial
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”
November 2004
Backes, MontemurroSlide 6
doc.: IEEE 802.1-04/xxxr0
Tutorial
• 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?
November 2004
Backes, MontemurroSlide 7
doc.: IEEE 802.1-04/xxxr0
Tutorial
• 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?
November 2004
Backes, MontemurroSlide 8
doc.: IEEE 802.1-04/xxxr0
Tutorial
• 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
Why does this require standardization?
November 2004
Backes, MontemurroSlide 9
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 10
doc.: IEEE 802.1-04/xxxr0
Tutorial
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?
November 2004
Backes, MontemurroSlide 11
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 12
doc.: IEEE 802.1-04/xxxr0
Tutorial
Beyond Motherhood and Apple Pie
• Even more compelling technical reasons– Stability– Determinism
November 2004
Backes, MontemurroSlide 13
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 14
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 15
doc.: IEEE 802.1-04/xxxr0
Tutorial
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!
November 2004
Backes, MontemurroSlide 16
doc.: IEEE 802.1-04/xxxr0
Tutorial
APs and STAs= Access Point
= Station (STA)
“Distribution Service” (DS) – often a wired LAN
An “Association”
November 2004
Backes, MontemurroSlide 17
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 18
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 19
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 20
doc.: IEEE 802.1-04/xxxr0
Tutorial
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.
November 2004
Backes, MontemurroSlide 21
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 22
doc.: IEEE 802.1-04/xxxr0
Tutorial
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!
November 2004
Backes, MontemurroSlide 23
doc.: IEEE 802.1-04/xxxr0
Tutorial
Assertion
Common management and common configuration algorithms are essential to the long term viability of heterogeneous LAN
November 2004
Backes, MontemurroSlide 24
doc.: IEEE 802.1-04/xxxr0
Tutorial
What I propose to be done
Start with:
• Consistent RF Management Architecture
• Consistent set of additional MSDU parameters
• Consistent set of MAC Status Parameters
November 2004
Backes, MontemurroSlide 25
doc.: IEEE 802.1-04/xxxr0
Tutorial
Example RF Management Architecture
802.1 RFManagement
Agent
802.1 RFManagement
Agent
802.1 RFManagement
Agent
802.11 SME
MAC PHY
802.16 SME
MAC PHY
802.20 SME
MAC PHY
MAC Primitives MAC Primitives MAC Primitives
RF ManagementPrimitives
RF ManagementPrimitives
November 2004
Backes, MontemurroSlide 26
doc.: IEEE 802.1-04/xxxr0
Tutorial
Example MSDU Parameters
• received_power_level (dBm)
• transmitted_power_level (dBm)
November 2004
Backes, MontemurroSlide 27
doc.: IEEE 802.1-04/xxxr0
Tutorial
Example MAC Status Parameters
• known_BSS– base_BSS– load_factor– path_loss– max_power
• receive_treshold
November 2004
Backes, MontemurroSlide 28
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 29
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 30
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 31
doc.: IEEE 802.1-04/xxxr0
Tutorial
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
November 2004
Backes, MontemurroSlide 32
doc.: IEEE 802.1-04/xxxr0
Tutorial
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”
November 2004
Backes, MontemurroSlide 33
doc.: IEEE 802.1-04/xxxr0
Tutorial
Backup slide – Real problems
• Configuration problems– 33% of residential customers call the help desk– High return rates– Unhappy customers