IEEE 802.11

802 LAN Access Method for Wireless Physical Medium

DATE:	January 6, 1994

AUTHOR:	Chandos A. Rypinski,

Chief Technical Officer

LACE, Inc.	Tel: +01 415 389 6659

655 Redwood Highway #340	Fax: +01 415 389 6746

Mill Valley, CA 94954 USA	E-m: rypinski@netcom.com

TITLE:	EVALUATION OF THE DFWMAC

SUMMARY

The DFWMAC is gravely flawed if measured against the stated objectives of the 802.11 Committee. This contribution summarizes the most serious of these as slides for presentation.

One approach to a remedy is to amend the requirements until there is a partial fit to the capabilities. Some possibilities along this line are also shown.

The general thrust of the points chosen, are those which are architectural rather than detailed. Examination of these objections will show fundamental philosophical differences with much of the constituency for the DFWMAC--specifically:

Contrary to assertion of the primacy of "peer-to-peer" usage, most applications will generate traffic that is primarily "client-server" oriented, and large gains may be made by taking advantage of this fact. This assertion does not exclude peer-to-peer for default or secondary use.

Negative or absence of information cannot be used in a radio wireless system as a criteria permitting transmission without grave limitations on reliability and capacity

A method of dealing with co-channel use other than LBT is imperative for continuous area coverage.

Further description of better alternative philosophies is given in a second contribution -- IEEE P802.11/94-13.

EVALUATION OF THE DFWMAC

Table of Contents	Page

DISQUALIFYING PROBLEMS	1

SERIOUS FUNCTIONAL LIMITATIONS

IN THE CONTENTION-ALLOWED TIME ALLOCATION	1

SERIOUS PROBLEMS WITH BEACON AND FRAME FORMAT PRESENT	2

DIFFICULTIES OF OMISSION	2

POTENTIAL NON-RESPONSIVENESS TO 802.11 FUNCTIONAL REQUIREMENTS	3

Table I -- Selected Results from Tables 3.5-3.8 in P802.11/92-20	3

CONSEQUENCES OF SELECTING DFWMAC	4

Table II -- Relative Raw Capacity of DFWMAC and SAMAC in 2.4 GHz ISM Band

(abridged)	4

REMEDIAL POSSIBILITIES	5

Figure 1 -- Suggested alternate diagram for the DFW Protocol Stack

shown in Figure 3-5 of P802.11-93/90	5

DISQUALIFYING PROBLEMS

1.	Absence of a plan for frequency reuse and continuous area coverage (apart from the CSMA/CA transmit inhibit), and therefore also inability to provide connection-free services over the same area as the contention services.

2.	Use of absence of or negative information to enable transmit in the carrier sensing and Network Access Vector (network access vector function) functions leading to unnecessary and excessive loss of capacity.

3.	A magnitude of transfer delay and available bandwidth for connection-type services which is only useful and acceptable for a local voice intercom function.

SERIOUS FUNCTIONAL LIMITATIONS

IN THE CONTENTION-ALLOWED TIME ALLOCATION

1.	Use of absence of or negative information to enable transmit in the carrier sensing, prioritization and NAV functions leads to unnecessary and excessive loss of capacity:

a.	from unnecessary deferral to other apparent signals,

b.	excessive retry with backoff,

c.	instability without timeout added,

d.	degradation to a pure Aloha access method when power control and adaptive receiver threshhold are added.

e.	There will be difficulty in screening irrelevant NAV messages causing unnecessary transmit inhibits.

2.	High susceptibility to accidental and malicious jamming and impolite access methods

a.	The carrier sensing will be easily bypassable enabling use of "channel grabbers" possibly combined with low level "channel holders."

b.	Other systems have watchdog timers required to prevent accidental transmitter "lock-on."

3.	Absence of packet segmentation or limitation on packet length beyond those in associated LANs results in:

a.	one transmission can "hog" channel time.

b.	increased probability of access contention at the end of long transfers and increase use of backoff.

c.	increases probability of flawed transfers particularly when there is no PHY level FEC.

4.	Absence of central power management function creates inherent access delay as long as one "sleep" time.

5.	Material time loss, added power drain and potential for gross malfunction from "Scan for better AP" located in Stations.

SERIOUS PROBLEMS

WITH BEACON AND FRAME FORMAT PRESENT

1.	There are one or more wait states inherent in the time partitioning used which separates the parts of one transaction.

2.	The only defined connection-type service is compressed voice. The talk-spurt advantage is much more difficult to realize in a slot-allocated reservation system than is apparent. If implemented, these features should be at application level, not in the MAC.

3.	The in-built worst-case transfer delays for reservation-related services can reach two and generally exceed one ("super") frame length, and therefore will result in 24- 48 milliseconds of transfer delay.

4.	The polling method of access control results in further initial worst-case access delays with a further compounding of wait states and frame length delays. Using polling for for access control, requires much more frequent polls than are required for background polling.

5.	The proposed PCF (point coordination function) only incorporates those functions that are absolutely unavailable any other way. There remains a number of functions in station MAC which are simpler and more economical implemented in the PCF.

6.	The MAC Service Model (Fig 3-5 of 93/190) does not correctly portray the function by over simplification. There is far less independence between the PCF and the minimal required functions than portrayed, and this difference will make implementation very difficult.

DIFFICULTIES OF OMISSION

1.	There is no defined coordination function common to multiple point coordination functions, and therefore:

a.	The presumption is that a station moving from one coverage to another must be rerouted through a further distributed network.

b.	There is no way to take advantage of messages successfully received at a different AP/PCF than that to which the station is currently associated.

c.	There is no data base and coordination system for addressing and subrouting which can make outside access common for a number of BSAs in a ESA.

2.	There is no mechanism for recognizing that the availability of the channel may be increased and more accurate by considering the status of other contiguous BSAs.

3.	Absence of any planned use of the advantages of a server associated privileged access point with higher assurance of coverage to all of the associated stations.

POTENTIAL NON-RESPONSIVENESS

TO 802.11 FUNCTIONAL REQUIREMENTS

1.	Since the reservation portion of the DFWMAC is optional, it will be present on a fraction of all stations putting at risk a common station type for all systems regardless of size.

2.	The statement in 802.11-93/190 para 3.2 limiting the PCF to only certain environments, this plan cannot provide its required services over a large percentage (99.9% required) of the service area provided by the contention service. Even with the 15-25 channels that the FH PHY might provide for separation of coverages, this would only be enough to reduce the malfunctions to a minor proportion of transactions.

3.	In a multiple BSA environment, there is no way to define how much traffic can be carried within constrained access delay and lost attempts to obtain service. The plan cannot comply with any minimum performance specification.

4.	The nominal transfer delays targeted in "WLAN Functional Requirements" (802.11/92-20) cannot be achieved by the DFWLAN contention free service.

Table I -- Selected Results from Tables 3.5-3.8 in P802.11/92-20

Parameter	Asynchronous	Synchronous
Median	Std dev	Median	Std Dev
Nominal Transfer Delay	10	164	30	0
Target Nominal Transfer Delay	2	5	10	1
Units	millisec	millisec	millisec	millisec

CONSEQUENCES OF SELECTING DFWMAC

1.	The amount of time and effort to document this protocol in standards form is much larger than is either available, necessary or acceptable.

2.	If the technical method proposed is implemented in the presented form, the resulting system will be unserviceable for:

a.	connection-type services because of excess transfer delay and the existence of interference or medium contention from contiguous user clusters; and for

b.	connectionless services requiring equivalence to 802 defined accuracy and transfer rate with the presently proposed PHY layers; and for

c.	a served user density and capacity demand level which is a decade or more inferior to infrastructure-based and interference-limited competing system designs.

3.	Since the optional contention-free aspects will not be more than partially satisfactory, the actual shipped product will be only the contention mode accompanied by promises.

4.	If the system implements distributed adaptive receiver threshhold, the system will degenerate into an Aloha protocol under medium to high load conditions.

Relative Raw Capacity of DFWMAC and SAMAC in 2.4 GHz ISM Band

PARAMETER	DFWMAC	DFWMAC	SAMAC	SAMAC
PHY	1 Mbps FH	2 Mbps DS	2 Mbps DS	6 Mbps DS
Reach--mtrs:	100	50	50	35
AP Illumin'n:	Omni	Omni	Omni	Corner
Cell area--m2:	20,000	5,000	5,000	625
Reuse factor:	36 (19 chnl)	16 (3 chnls)	9 (3 chnls)	4 (1 chnls)
Raw cap/cell:	1 Mbps	2 Mbps	2 Mbps	6 Mbps
Raw capacity adjusted--

Mbps/km2:	10.56/chnl

200.6

per band	25 /chnl

75

per band	88.8 /chnl

266.6

per band	3,600/chnl

3,600

per band

REMEDIAL POSSIBILITIES

1.	Classify the contention-only (pure peer-to-peer) portion of the DFWMAC as an entry-level subset of plural 802.11 standards with a factual representation of its capabilities. The use of this MAC should be defined only for the 2.4 GHz PHYs.

2.	For better performance, develop a CSMA/CA repeater-based architecture where sleep-mode management, filtering, automatic power control, association and some other functions become part of a minimal PCF that is a new primary mode.

3.	Undertake to gain relief from incompatible 802.11 Functional Requirements for this MAC alone; or undertake to change and reduce the Functional Requirements to that which can be satisfied.

4.	Undertake parallel effort on a MAC with the changes necessary to meet all of the Functional Requirements competently.

THE MAC SERVICE MODEL