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