1. Floyd Backes, Propagate Networks Michael Montemurro, Chantry Networks
November 2004
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 Proposed Solution
Month 2002
doc.: IEEE /xxxr0
November 2004
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
John Doe, His Company

3. Brief Intro to IEEE 802 Wireless Networks
November 2004
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
Backes, Montemurro

4. RF Management Sometimes it’s useful to:
November 2004
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
November 2004
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?
November 2004
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?
November 2004
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?
November 2004
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 to connect to the ISP, and to connect to the home LAN).
addresses how to hand off, not why
Backes, Montemurro

9. Why interoperability is so important for Wireless Networks
November 2004
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?
November 2004
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
November 2004
Historical Motivation for Consistency Across MACs
utilizes a huge installed base of wired 802.3
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
Backes, Montemurro

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

13. Cognitive Radio and SDR
November 2004
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. November 2004
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
Backes, Montemurro

15. November 2004
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 STA across a set of APs
Stability is a requirement!
Backes, Montemurro

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

17. This is A Control System
November 2004
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
November 2004
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
November 2004
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
November 2004
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
November 2004
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
November 2004
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. November 2004
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
November 2004
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
November 2004
Example RF Management Architecture
Backes, Montemurro

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

27. Example MAC Status Parameters
November 2004
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
November 2004
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. November 2004
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
November 2004
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
Backes, Montemurro

31. Backup slide – Real problems
November 2004
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
November 2004
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
November 2004
Backup slide – Real problems
Configuration problems
33% of residential customers call the help desk
High return rates
Unhappy customers
Backes, Montemurro