Multiple rates Study Group
•	Revised Document from May Meeting
•	Added explanations to response for comments
TOC from D. Bagby
•	Positions on the issue within 802.11: 
–	Positon 1: There are no problems (2 people, Jan ‘96 minutes)
–	Position 2: That there are probelms, but that they can accept the D3 mechanism.
–	Position 3: There are problems that are unacceptable.
•	The problems asserted are:
•	No requirement that entire frame exchange is sent at a common rate, when there is more than one basic rate (DS case) - Duration field impossible to determine in advance.
TOC (ctd..)
•	There is no management service interface to control rate selection on a per frame basis - MIB attributes may not be used for this.
•	There is no data service interface to control rate selection on a per frame basis - MIB attributes may not to be used for this.
TOC (ctd...)
•	No mechanism wihtin the MAC is described for selecting rate at which to transmit a frame - this creates interopera bility concerns.
–	No mechanism is described to allow the selection of higher rates
–	No mechanism is specified to allow fallback to lower rates
•	When frames are sent at a non-basic rate, duration information for fragment bursts is lost to basic-rate-only stations near the source that do not hear the destination’s ACKs - results in lower reliability of CSMA/CA
•	Use of multiple rates without explicitly required mechanisms for rate determination virtually guarantees that a multi-rate BSS has a lower throughput than a single, low-rate BSS
•	Many areas of the draft do not support multi-rate
–	Many MIB attributes and almost all MAC timing is dependent upon there being only a single rate
TOC (ctd...)
•	Because duration info is sent at rate used for frame, basic rate stas do not always get duration info.
•	Serious limits to to thruput increases claimed make value of mechanism questionable - due to gaps , frames, plcp Headers not scaling with rate, and only 2:1 ratio of rates.
•	There have been other system solutions proposed (co-located single rate BSS) to accomplish multi-rates in a LAN that do not exhibit these technical issues.
•	IR Phy uses two diff PLCP headers for diff rates that won’t work with MAC.
Charter for Wed evening
•	Special subcmtee chaired by Pablo Brenner will resolve the multirate issues listed above in the TOC and the PLCP header “duration in usec” issue.
•	The issues are individually addressed in the following sections.
Issue #1
•	No requirement that entire frame exchange is sent at a common rate, when there is more than one basic rate (DS case) - Duration field impossible to determine in advance.
–	Resolved, when we can specify that the CTS and Ack are returned at the same rate if that rate is part of the Basic Rate set, or else, the maximum rate as specified in the Basic Rate set.
Issue #2
•	There is no management service interface to control rate selection on a per frame basis - MIB attributes may not be used for this.
•	Resolutions:
–	Isn’t this covered by the use of the Tx-Vector, as specified in the PHY?
–	Isn’t this part of the PHY service interface definition.
Issue #3
•	There is no data service interface to control rate selection on a per frame basis - MIB attributes may not to be used for this.
•	Not considered needed when the Rate Selection Algorithm is in the MAC Mngt or Station Mngt.
Issue #4
•	No mechanism wihtin the MAC is described for selecting rate at which to transmit a frame - this creates interopera bility concerns.
–	No mechanism is described to allow the selection of higher rates
–	No mechanism is specified to allow fallback to lower rates
•	Unclear how it does effect interoperability.
•	This is not considered part of the standard.
–	This is a decision that has to be made by the Transmitter, and we have included the basic information needed for this decision in the standard.
»	This is available as the “Supported Rate” field.
Issue 4 (ctd...)
•	Can describe an example policy / algorithm in an informative annex.
–	It would be good when we can specify a result criteria.
–	So how should the mechanism behave.
–	Performance should improve by switching the rate.
–	Objective of rate switching is to increase throughput. Need to state this as a requirement. Add to 9.6
–	Need a statement in 9.6 that specifies that a station should only transmit at rates that the destination can operate at. 
–	Need an interface statement (not a MIB entry) with a “Rate Switching Algorithm” box.
Issue 4 (ctd...)
•	This is similar to for instance the situation that we currently do not specify when a station is to start scanning for a new AP.
Issue #5
•	When frames are sent at a non-basic rate, duration information for fragment bursts is lost to basic-rate-only stations near the source that do not hear the destination’s ACKs - results in lower reliability of CSMA/CA
–	A solution for this problem has already been suggested in the  “Smart DIFS” proposal made in the Nov 94 meeting.
Issue #5 (ctd...)
–	This discussed that the MAC would consider all invalid receptions where the CRC was not correct (CCA stil indicating “Medium Busy”), and assume a conservative DIFS, that is SIFS+ACK+DIFS long.
»	MAC need to be able to distinct such a situation.
»	PHY does need to provide RxVector.
–	Another mechanism that we need to settle among all the PHY’s is to specify the coexistance between the PHY’s.
»	This can be done by adopting the comments at this meeting, to specify the Length field in the PLCP Header in usec, and assure that this is translated into a “Medium Busy” indication as long as PLCP crc is correct.  
Issue #6
•	Use of multiple rates without explicitly required mechanisms for rate determination virtually guarantees that a multi-rate BSS has a lower throughput than a single, low-rate BSS
–	This is the same subject as addressed above (Slide 4).
–	Criteria suggested resolves this.
Issue #7
•	Many areas of the draft do not support multi-rate
–	Many MIB attributes and almost all MAC timing is dependent upon there being only a single rate.
–	Need to be more specific
»	Basic Rate Set not defined in MIB.
»	Timeouts:   How accurate do they need to be??
»	Ad Hoc group needs to identify these points.
Issue #8
•	Because duration info is sent at rate used for frame, basic rate stas do not always get duration info.
–	Correct, but where does this matter.
–	Only applicable to fragmented frames.
–	COVERED
Issue #9
•	Serious limits to to thruput increases claimed make value of mechanism questionable - due to gaps , frames, plcp Headers not scaling with rate, and only 2:1 ratio of rates.
–	There are no claims being made.
–	Performance increase criteria have been defined.
Issue #10
•	There have been other system solutions proposed (co-located single rate BSS) to accomplish multi-rates in a LAN that do not exhibit these technical issues.
–	Solutions suggested do all support Concurrent Multirate support within a BSS.
–	So there is no reason for another mechanism.
Issue #11
•	IR Phy uses two diff PLCP headers for diff rates that won’t work with MAC.
–	Being addressed in the IR group.
Dinner (Dave visits, lights on, but dim)
Tasks for Wed late-night session:
•	Go through real LB comments, and identify how we addressed them, with reference to the resolutions we devised in the above sections.
•	PLCP discussion not yet completed.
•	see results below ...
Review of the original LB comments
•	C#72 c7 BO - addressed
–	Wants rate-switching mechanism defined (See 6.2.1.1. and 9.6)
•	C#74 c7 JZ - addressed
–	We came with a better mechanism to accept thatm accepted by Johny.
•	C#2 c9 MSU - addressed
–	Declined, accepted by Mack.
•	C#9 c9 BO - addressed
–	Declined, there is a mechanism defined now.
•	C#84 c9 BO - addressed
–	9.6 Specifies that the objective is to improve performance, and that a station shall not transmit at a rate that it knows the destination does not support.
•	C#85 c9 JZ - withdrawn
Review of comments (ctd...)
•	C#141 c9 SB - addressed by “EIFS”
–	EIFS document
•	C#7 c11 ES - addressed by “Smart DIFS”
–	EIFS document
•	C#8 c11 ES - addressed  ????? (needs confirmation)
–	He wants MultiRate....So this seems to help
•	C#9 c11 ES - addressed (yes, we considered it)
•	C#67 c11 TT - accepted
–	The new rules of 9.6 take care of the ambiguity
•	C#91 c11 SB - accepted; 
–	delete Rate_FActor MIB var and add a variable for calculation
Review of comments (ctd...)
•	C#92 c11 TT - addressed by deleting the text in question
–	accepted, deleted the attribute
•	C#100 c11 TT - addressed
–	Redefined CTSTime, as CTSSize, and we defined the rules to calculate the time.
•	C#2 c12 JZ - withdrawn
•	C#76 c16 MIF - addressed by IR PHY group
•	C#124 general DB - addressed 
•	
review of PLCP duration field change to usecs
•	lack of bits for encoding would prevent Tx of max sized (4096?) MPDUs.
•	CCA provides most of the remedy for lack of directly conveyed duration information (no need to adopt a marginal improvement)
•	as a result of this info and Wed night’s effort, Johnny withdraws his LB comment
•	unfortunately, adopting this would create new NO votes
Summary of required text changes
•	“Smart DIFS”
–	Modifies basic access rules to defer SIFS + ACK_time.1M + DIFS after:
»	RXEND with an error condition (e.g. carrier loss)
»	MPDU CRC error
–	Retain the normal mechanism of deferring DIFS after a correctly received frame.
–	9.2.3.: See 96/71
–	9.2.3.3: See 96/71
–	9.2.4: 96/71
Changes Required (ctd...)
–	9.2.5.1: 96/71
–	9.2.5.2: 96/71
–	9.2.10: 96/71
–	12.3.5.11.3: 96/71
»	PLCP PHY_RXSTART.indicate
»	generate an indication even if the PLCP header indicates an unsupported rate.
–	12.3.5.12.x: 96/71
»	PLCP PHY_RXEND.indicate
»	add an error code for “unsupported PLCP data rate”
Changes Required (ctd...)
•	Control-frame rate rules
–	9.6 
»	CTS/ACK same (if basic) or max basic rate
»	PS Poll, and so on ...
•	Duration calculation parameters
–	7.2.x
»	duration calculation based on ACK/CTS times dictated in 9.6
Changes required (ctd...)
•	MIB variables definitions
–	11.???
»	aBSS_BASIC_RATE_SET
»	aPREFERRED_RATE
»	(done pb, called maxRate)
–	9.2.5.3
»	ACK_TIMEOUT
–	11.4.4.2.30
»	ACK_TIMEOUT
•	Supported rates/ association
–	7.3.1.9
»	add a new status code for “association denied due to lack of support for the basic rate set”
»	(pb done)
Changes required (ctd...)
•	Multirate requirements
–	9.6
»	the objective of multirate is to improve performance
»	never send at a rate that is known not to be supported by the destination STN
»	Rate switching mechanism interface statement
»	
»	(pb done)
Changes Required (ctd...)
–	6.2.1.1 (add to Effect of Receipt paragraph)
»	The transmission rate of each transmitted frame is controlled by the rate switching mechanism (i.e. the unspecified rate switching algorithm).
»	(done pb)
»	A MIB variable (input to the rate switching mechanism) defines the preferred data rate.
»	(paragraph 11? pb)
•	PHY notes
–	12.x.x.x.x
»	xxxx
•	
•	That’s all folks ....
•	
•	Motion to empower the multirate subsubgroup to make the text changes as identified and present at or before the next meeting.
–	JZ, Wayne: 30,0, 1