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