Results of Ballot on Draft Standard D3.0
Comments on clauses 10 and 11 and resolutions

Seq. #	Section number	your initials	Cmnt type
E, e, T, t	Part of NO vote	Comment/Rationale	Corrected Text	Disposition/Rebuttal	
1.		10
9.1
	WD	E	n	The figures 35 (MAC Architecture Block Diagram) and 53 (GET and SET Operations) do not match.
In particular, figure 35 shows a Sublayer Management interface that is not described in section 10. It is suggested to delete this interface from the figure 35.	Delete Sublayer Management interface from figure 35.	Section 9 problem	
2.		10
9.1
	WD	E	n	The figures 35 (MAC Architecture Block Diagram) and 53 (GET and SET Operations) do not match.
In particular, figure 35 shows a Sublayer Management interface that is not described in section 10. It is suggested to delete this interface from the figure 35.	Delete Sublayer Management interface from figure 35.	Section 9 problem	
3.		10.1	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The latter two SAPs support identical primitives, and in fact may be viewed as a single SAP (called the PLME SAP) which could be used either directly by  MLME or by SM.  In this fashion, the model reflects	Accepted in Plenary Motion 8	
4.		10.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	This shall be used to initialize the management entities, the MIBs and the datapath entities.  It may include a list of parameters for items to be initialized to non-default values.  The .confirm shall indicate success or failure of the request.  
	Section 9 problem	
5.		10.3	sb	t	n	MLME SAP Interface primitives are for explanatory purposes only. Include prescribed text. 	Scope and Field of Application:
Specified here are the services provided by the MAC Layer Management Entity (MLME) to the Station Management Entity (SME). These services are described in an abstract way and do not imply any particular implementation or exposed interface.	Accepted.	
6.		10.3.2.1	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	When Generated
This primitive is generated by the Local SMT when a STA wishes to determine if there are other BSS’ which it may join. 
	Accepted in Plenary Motion 8	
7.		11	ES	t	Y	NAV must be accessible to both 1Mb/s and 2Mb/s (and possibly higher data rates) devices.	Move duration to the PLCP	Passed to Section 9 group	
8.		11	ES	t	Y	No provisions where made to enable the design of incompatible higher (>2Mb/s) data rate FH-PHYs with compatible 1/2Mb/s fall-backs.	Allocate in the current standard in the PLCP field (Table 28) a pattern unique to incompatible higher date rates. Existing 1/2Mb/s devices will decode the duration of the frame and reject the body of the frame.	Passed to Section 9 group	
9.		11	ES	T	Y	802.11 should consider higher data rate FH PHYs before forwarding the draft to the sponsor ballot		Passed to Section 9 group	
10.		11.1.1.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	Beacons and Probe Responses carry a TSF time element.  A station receiving such a frame from another station in an IBSS with the same ESS ID shall compare the TSF time with its own TSF time.   If the	Accepted in Plenary Motion 8	
11.		11.1.2.1
11.1.3.3
11.1.5
7.2.3.1
7.2.3.9
7.3.1
	WD	T	Y	Currently the synchronization between stations in an IBSS and between stations and AP is determined by the adoption of the TSF timer according to a defined update mechanism.
However the most essential information for the MAC is to determine when the next and subsequent TBTT synchronization points are located. Similar for Fhopping stations they need to know when the next Dwell boundary is to occur.
The TBTT is currently defined as the instance in time when TSF timer MOD Beacon Interval = 0
Sinse the TSF timer is defined as a 64 bit value, it is a complex modulo operation to calculate the next TBTT, which needs to be performed after every Association and Reassociation.
It is important for stations to know pretty accurate, when that next TBTT occurs, because that will usually determine when that station is to wake-up, to be ready to receive the next Beacon. In addition it determines when in a PCF, stations are supposed to set their NAV, to prevent contention with the PCF.
The Modulo operation can be quite complex, if the Beacon Interval is not a power of two value in usec.

It is therefore suggested to include an extra “Next TBTT” parameter in the Beacon and Probe response frames, that does allow a station to simply derive the next TBTT.
This 16 bit parameter should be the least 16 bit Kusec value of the TSF timer, when the next TBTT occurs.

A similar provision can be made in the FH Parameter Set field, by specifying a “Next Dwell” field in exactly the same way.	Modify section 7.2.3.1, and 7.2.3.9:
Insert the “Next TBTT” paremeter at position 2 in the Beacon and Probe response frame formats.

Add a section 7.3.1.11 Next TBTT
This field represents when the next TBTT will occur. The length of the Next TBTT field is two octets, and defines the Kusec boundary at which this field equals the bits 11 till 26 of the TSF Timer.

Modify section 7.3.2.3
Add one subfield in figure 27, between Dwell Time and Hop Set, called “Next Dwell”.
Add subsequent text to define the “Next Dwell” subfield as follows:
The Next Dwell field represents when the next Dwell boundary will occur. The length of the Next Dwell subfield is two octets, and defines the Kusec boundary at which this field equals the bits 11 till 26 of the TSF Timer.

Add to section 11.1.2.1, below the Figure 54.
Beacons and Probe Response frames will also include a field that specify when the “Next TBTT” does occur.  Stations should not rely on the “Next TBTT field alone, because it is possible that Beacons will be missed by that station.

Add at end of  section 11.1.3.3 :
At every synchronization event stations can use the next TBTT field in the Beacon or Probe response frames to synchronize its TBTT predictions to the BSS.

Add at end of section 11.1.5:
The Next dwell subfield in the FH Parameter Set field present in each Beacon or Probe response frame, will help stations to synchronize to the next dwell boundary. They will however need to maintain their own “Next Dwell” boundary, by subsequently adding acurrent_Dwell_Time each time the Dwell boundary is reached to prevent that all Beacons need to be successfully received to maintain synchronization.
	Since a simplification of the next TBTT process described is clearly desirable, another method of avoiding the calculation was agreed upon. The fix proposed by this comment was modified to add this field to the Association Response.

WD agrees, it now becomes a matter for the group addressing sections 7 and 9.  He agreed to bring it up with that group.

Next Dwell is not a clause 11 issue.  WM agrees to forward this to the correct group.
	
12.		11.1.2.1	TT	t	Y	Need a reference point for calculating when the next DTIM will occur.  Since time 0 is a TBTT it can also be a DTIM i.e. DTIM count = 0.  Also for completeness it can be the first CFP for BSSÕs with a PC.  This makes it possible to determine exactly at which beacon the next DTIM and CFP will occur once a beacon is received.	Add to second sentence:
...time units apart, time zero is defined to b a TBTT, with the Beacon being a DTIM and the beginning of a CFP.	Accepted	
13.		11.1.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	Beacons shall be scheduled at the nominal beacon interval. This is shown in Error! Reference source not found.  
	Accepted in Plenary Motion 8	
14.		11.1.2.1	jz	T	Y	Multicast/Broadcast reliability is compromised by the power save mechanism. We should adopt the mechanism is 96/15 and 96/16 to fix this. My “No” vote will only change to a “Yes” vote if we adopt these changes or else mandate the use of a stripped-down PCF to enhance multidestination reliability.	<<Adopt changed text for this section from 96/15.>>	Deferred to full MAC group	
15.		11.1.2.1	TT	t	Y	Need a reference point for calculating when the next DTIM will occur.  Since time 0 is a TBTT it can also be a DTIM i.e. DTIM count = 0.  Also for completeness it can be the first CFP for BSSÕs with a PC.  This makes it possible to determine exactly at which beacon the next DTIM and CFP will occur once a beacon is received.	Add to second sentence:
...time units apart, time zero is defined to b a TBTT, with the Beacon being a DTIM and the beginning of a CFP.	Accepted (duplicate)	
16.		11.1.2.2	ge	e		last sentence should refer to 11.2, not 8.2	“... in 11.2”	editorial	
17.		11.1.2.2	TT	t	Y	Need to clarify what happens to the random delay when you actually receive a beacon.  Since a TBTT can happen in the middle of attempting to retry an MPDU, the STAs CW may not be at aCWmin. 

It is implied that at TBTT each STA will be doing a random delay and no frames other than beacons will be initaited after TBTT.	Add after 1)

1a)  Set NAV for the length of this delay.

Add to end of this section:

4)  if a Beacon has arrived during the delay period then clear the random delay and NAV and calculate a new backoff starting at the CW that was in use prior to TBTT.	DISCUSSION IN PROGRESS: The comment is accepted, but the proposed solution to require the use of the NAV was rejected.

Unable to resolve

18.		11.1.2.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The Beacon transmission shall always occur during the Awake Period of stations that are operating in a low power mode. This is described in more detail in  ??.
	Accepted in Plenary Motion 8	
19.		11.1.2.2	TT	t	Y	Need to clarify what happens to the random delay when you actually receive a beacon.  Since a TBTT can happen in the middle of attempting to retry an MPDU, the STAs CW may not be at aCWmin. 

It is implied that at TBTT each STA will be doing a random delay and no frames other than beacons will be initaited after TBTT.	Add after 1)

1a)  Set NAV for the length of this delay.

Add to end of this section:

4)  if a Beacon has arrived during the delay period then clear the random delay and NAV and calculate a new backoff starting at the CW that was in use prior to TBTT.	duplicate	
20.		11.1.2.2
11.4.4.1.27	sb	t	n	IBSS Beacon transmission delay is random between 0 and CW_max. The problem with this is that CWmax is a large number (255 * 50ms = 12.75ms) and could easily be longer than the ATIM window (default 1ms). Better use CWmin ?
Default ATIM window is pretty silly at 1ms. ATIM packet is 344ms so two would get through. Better to set ATM window default to 5ms. 	Change CWmax to CWmin in 11.1.2.2

Change default value of aATIM_Window to 5000.	Accepted with modifications: value chosen is 2 * Cwmin

aATIM_Window was set 4096	
21.		11.1.3	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	A Station shall operate in either a Passive Scanning mode or an Active Scanning mode depending on the current value of the system variable aScan_Mode, which may take the values PASSIVE or ACTIVE.  
	Accepted in Plenary Motion 8	
22.		11.1.3
7.1.3.4.3	sb	t	n	For D3 we changed the IBSS BSSID to be the least significant 46 bits of the TSF timer. The idea here was to overcome the problem of a STA starting and IBSS, other stations joining, then the original station going away, coming back into range and wanting to start another IBSS. The new proposal doesn’t fix this problem. Suppose a station starts an IBSS, it decides to do this after a set time scanning and all the rest. It then initialises its TSF timer and starts transmitting Beacons. The question arises as to at what TSF point you choose to set your BSSID. If it is after initialising you always come up with a BSSID close to 0. This therefore makes the original problem more likely. You need something unique to both station and time here. I propose that we use some of the original idea with a random element to cure the original problem. The proposal is then to use the least significant 30 bits of the IEEE address of the STA starting the IBSS with a 16 bit random number. 	The value of this field in an ad-hoc network (IBSS), shall be a locally administered IEEE MAC address. The least significant 16 bits of the address shall be set to a random number between 0 and 65535. The upper 30 bits shall be set equal to the least significant 30 bits of the universal IEEE address of the STA initiating the BSS. The Individual/Group bit of the address shall be set to ‘0’. The Universal/Local bit of the address shall be set to ‘1’. This mechanism is used to ensure a high probability of selecting an unique BSSID.	Accepted spirit of comment, but declined to specify specific algorithm.  Instead described the requirements of the RNG	
23.		11.1.3.3	sb	t	n	Seems to be a problem here, text says: ‘Else if the Capability Information field designates an independent BSS, a STA may determine the BSSID, select channel synchronisation, … , and start transmitting Beacons
Where is the capability field referred to here located? (No frames have been received).
Surely you just do this … or is there another managed object !	b) If a BSS of the appropriate type with the specific ESSID is found, adopt the BSSID, channel synchronization information, TSF timer value of the BSS.
	Else a station may determine the BSSID, select channel synchronization, select a beacon period, initialize and start the TSF timer, and begin transmitting Beacons.
		Else indicate failure to find a network matching the ESSID.	Accepted	
24.		11.1.3.3
,7.2.3.1
7.2.3.9
7.3.1.(new)
	mif	T	Y	The timestamp and beacon interval fields in the Beacon and Probe Response frames providea timebase reference point and interval which is minimally sufficient to allow a station to synchronize with the beacon interval of a BSS.  However, these fields do not provide enough information to permit power efficient synchronization, because there is nothing which says how long until the next TBTT.  If power consumption were not an issue, the STA could simply remain active until the next Beacon frame from the BSS is received.  However, the inclusion of one additional field in certain management frames completely solves this problem, allowing the STA to know the time remaining until the next TBTT.

This new field is a 2-octet field with the number of Kmicroseconds (rounded down) until the Next TBTT.  This value is readily calculated, since it is equal to bits 10 through 25 of the value the TSF timer will have at the next TBTT.  As a minimum, the new Next TBTT field should be added to Beacon and Probe Response frames	Add a 2-octet field, ÒNext TBTTÓ  to the frame body of Beacon and Probe Response frames.  The recommended location is as field 2 or 3 (either just before or just after the Beacon Interval field, my preference is just after Beacon Interval & before Capability Information).
7.3.1.(new)	Next TBTT
This field shall contain the number of Kmicroseconds (rounded down) between the time represented in the Timestamp field of this frame and the next Target Beacon Transmission Time (TBTT).  The value of this field shall be equal to, or shall be one less than, the value that  bits 10Ð25 of the timestamp (TSF timer) will hold at the next TBTT.  The length of the Next TBTT field is two octets.
It may also be worth mentioning the Next TBTT field in clause 11.  The most important place is sub-clause 11.1.3.3:
b) If a BSS of the appropriate type with the specific ESSID is found, adopt the BSSID, channel synchronization information, TSF timer value of the BSS.  The Next TBTT field permits synchronization with the beacon timing of the BSS without waiting for as much as a full beacon interval.
	Resolved as per item #11	
25.		11.1.5 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	Stations shall use their TSF timer to time the aCurrent_Dwell_Time. The aCurrent_Dwell_Time is the length of time that stations shall stay on each frequency in their hopping sequence. Once stations are synchronized, they have the same TSF timer value.
	Accepted in Plenary Motion 8	
26.		11.11.4.1.2.2,
11.4.2.2.1,
11.4.3.2.2,
11.4.4.2.30
9.2.5.3,
	ch	t	Y	9.2.5.3:
CTS_TimeoutTimeout is misspelled, and not defined,
and the value sof CW is not doubled

Change the next paragraph to be consistant with the first and refer to the correct MIB variables, and add some punctuation for clarity

The conditions for using aShort_Retry_limit and aLong_Retry_limit do not match what is described in the MIB definitions of those variables, so I suggest changing the text here. 

clause 11:
there is no reason for aACK_Timeout to be a MIB variable. It is the sum of two other MIB variables and can be defined as such in the text.	9.2.5.3:
If after an RTS is transmitted, the CTS_Timeout expires without reception of a CTS, then a new RTS shall be generated while following the basic access rules for backoff.  Since this pending transmission is a retransmission attempt, the CW shall be increased (per the backoff rules) as per the backoff rules. This process shall continue until the number of attempts reaches aShort_Retry_Max. CTS_Timeout is equal to aCTS_Time plus aSIFS_Time.

The same backoff mechanism shall be used when no ACK frame is received within a predetermined ACK_Timeout, after a directed DATA frame has been transmitted. ACK_Timeout is equal to aACK_Time plus aSIFS_Time.  Since this pending transmission is a retransmission attempt the CW shall be increased (per the backoff rules).  This process shall continue until the number of attempts reaches either: aLong_Retry_Max for DATA frames the length of which exceed aFragmentation_Threshold; or, aShort_Retry_Limit for DATA frames the length of which do not exceed aFragmentation_Threshold.
11.4.1.2.2:
aACK_Time,
aShort_Retry_Limit,

11.4.2.2.1:
aACK_Time	GET,
aShort_Retry_Limit	GET-REPLACE,

11.4.3.2.2:
aACK_Time,
aShort_Retry_Limit,

11.4.4.2.30:
	Only clause 11 comment considered:  rejected. 

Rationale: there are other outstanding comments to change the definition to be a value other than the sum of two other MIB variables.	
27.		11.2.1	ch	e		grammer	The AP shall not arbitrarily transmit MSDUs to stations operating in a power saving mode,	editorial	
28.		11.2.1	ch	e		punctuation	In a BSS operating under the DCF, or during the contention period of a BSS using the PCF, upon determining	editorial	
29.		11.2.1	ch	e		spelling	and deliver them to all stations immediately following the next Beacon frame containing a Delivery TIM (DTIM) transmission.	Editorial	
30.		11.2.1	ge	e		last sentence should refer to Clause 9.	“... single frame exchange sequence, as described in Clause 9.”	Editorial	
31.		11.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	(PS) shall transmit a short PS-Poll frame to the AP, which shall respond with the corresponding	Accepted in Plenary Motion 8	
32.		11.2.1	jz	t	Y	Add to the end of the third paragraph:	The AP should take each associated station’s aListen_Interval parameter into account when determining the lifetime of buffered frames.	Comment accepted.  Resolution: already addressed by 11.2.1.9., no text change required.	
33.		11.2.1.1	ch	e		grammer	In PS Mode, a station will be in the Doze state and will enter the Awake state to receive selected Beacons, to receive broadcast and multicast transmissions following certain received Beacons,	editorial	
34.		11.2.1.1	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	A station may be in one of two different power states:
	Accepted in Plenary Motion 8	
35.		11.2.1.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	Power Save or PS
Station listens to selected Beacons (based upon its aListen_Interval) and sends PS-Poll frames to the AP if the TIM element in the most recent Beacon indicates a directed MSDU buffered for that station.  The AP shall transmit buffered directed MSDUs to a PS station only in response to a PS-Poll from that station, or during the contention free period in the case of a CF-Aware PS station.  In PS Mode, a station shall be in the Doze state and shall enter the Awake state to receive selected Beacons, to received broadcast and multicast transmissions...	Accepted in Plenary Motion 8	
36.		11.2.1.1	jjk	T	Y	There is a problem with terminals in the PS state that go to AM in order to transmit.  They are a type of “hidden” node with cannot know the state of the medium.  When they awake they may send and interfere with another stations reception of a message.  Also,  if the station uses RTS/CTS,  then the attribute aShort_Retry_Limit combined with the backoff ranges will not allow the station to transmit its message (the totol retry and backoff time is less that a maximum frame time).  This cause both interference and a failure to deliver. There are two solutions here.  1) Force the dozing station to defer at least a maximal length packet time (at the lowest bit rate in BSS).  This solves both problem.  2) Make aShort_Retry_Limit big enough that the previously dozing station will keep trying past the end of the frame it is interfering with.	Solution 1.  Add text at end of section.
A station that is changing from PS to AM in order to transmit will  perform CCA until a frame sequence is detected by which it can correctly set its NAV or until the time required to transmit a maximum length MPDU and  ACK at the lowest bit rate in the BSS has transpired.
Solution 2. Change text in section 11.4.4.2.31
BEHAVIOUR DEFINED AS 
"This attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to aFragmentation_Threshold, that will be made before a failure condition is indicated.  The default value of this attribute shall be 7.";
	Accepted solution #1, but changed to using PS is doze, AM is awake.  MPDU to aProbe_Delay

Accepted by commentor	
37.		11.2.1.2	ge	e		first sentence should refer to Clause 7.	“... as described in Clause 7”.	editorial	
38.		11.2.1.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The TIM shall identify the stations for which traffic is pending and buffered in the AP.  This	Accepted in Plenary Motion 8	
39.		11.2.1.3	ch	E		its aDTIM_Period, not aDTIM_Interval	aDTIM_Period	editorial	
40.		11.2.1.3	ge	e		last sentence should say “Broadcast and multicast”	“Broadcast and multicast MSDUs are sent ...”	editorial	
41.		11.2.1.3	jz	t		Add clarification to the end of the third paragraph:	Note that the second station will fail to receive broadcast/multicast frames, since it opts not to power up its receiver for all DTIMs.	Accepted	
42.		11.2.1.4	AS	T	y	Multiple PS-Polls from the same station should not cause the AP to queue more than one transmission to an STA. Only after a frame has be successfully transfered or max retried shall the AP recognize a PS-Poll from that STA.	Original Text:
A single buffered MSDU or management frames for a station in the PS mode shall be forwarded to the station after a PS-Poll has been received from that station. The More Data field  shall be set to indicate the presence of further buffered MSDUs or management frames for the polling station.
Replacement Text:
A single buffered MSDU or management frames for a station in the PS mode shall be forwarded to the station after a PS-Poll has been received from that station. The More Data field  shall be set to indicate the presence of further buffered MSDUs or management frames for the polling station. Further PS-Poll frames from the same station shall be ACKed and ignored until an MSDU or management frame has either been successfully transferred of nax retried. This will prevent a retried PS-Poll from being treated as a new request.		
43.		11.2.1.4

11.2.1.6	TT	T	Y	As this draft standard has evolved over the last few years some features remain in the standard even though the original intent of the feature has been changed.  The mechanism of Power saving is such a feature.  

Originally the intent was that the AP send data within a SIFS time in response to a PS-Poll.  Then this was changed to allow the PS-Poll to be ACKed and the data following later.  With the proposed algorithm described below and the comment in section 9.7 the first sequence should be eliminated.  

Currently the standard says that a power saving STA shall Poll until no more MSDUs or managmenet frames are buffered for that station.  This means that the STA must stay awake until it either sees the More Data bit clear in a received frame or sees itÕs TIM bit clear in a beacon.

The question is: Why does the STA need to send a PS-Poll for every buffered frame since it is awake anyway?  Also:  What does the AP do with extra PS-Polls it receives? (They canÕt be filtered as duplciates since there is no sequence number).

The text changes proposed amount essentially to another state the AP keeps which says a particular STA is currently Awake.  This state is entered when receiving a PS-Poll from the STA and can be assumed to be exited when a frame is successfully delivered with the More Data bit cleared or a beacon is sent with the STAs TIM bit cleared.

	Change11.2.1.4 part f) to read as follows:

All buffered MSDU or managmenet frames for a station in the PS mode shall be forwarded to the station after a PS-Poll has been received from that station.  The more Data field shall be set to indicate the presence of further buffered MSDUs or management frames for the polling station.  All subsequent PS-Polls from the polling station shall be ignored until all buffered frames have been delivered at which point the arrival of more data for the polling station shall be buffered and only sent if another PS-Poll is received.

Change 11.2.1.6 part d) to read as follows:

If the More Data field in the received MSDU or management frame indicate that more traffic for that station is buffered, the station shall remain in the Awake State until it either receives an MSDU or management frame with the More Data field cleared, or it receives a Beacon frame with the stationÕs TIM bit cleared, at which point it may resume its Power saving and return to the Doze state.		
44.		11.2.1.4	jz	T	Y	Multicast/Broadcast reliability is compromised by the power save mechanism. We should adopt the mechanism is 96/15 and 96/16 to fix this. My “No” vote will only change to a “Yes” vote if we adopt these changes or else mandate the use of a stripped-down PCF to enhance multidestination reliability.
Rephrase (e) thus:	e) Immediately after every DTIM, the AP shall transmit all buffered broadcast/multicast MSDUs.  The More Data field  shall be set to indicate the presence of further buffered broadcast/multicast MSDUs. The AP shall continue to transmit broadcast/multicast frames, separated by a PIFS, until it has processed all buffered broadcast/multicast traffic.	Defered	
45.		11.2.1.4

11.2.1.6	TT	T	Y	As this draft standard has evolved over the last few years some features remain in the standard even though the original intent of the feature has been changed.  The mechanism of Power saving is such a feature.  

Originally the intent was that the AP send data within a SIFS time in response to a PS-Poll.  Then this was changed to allow the PS-Poll to be ACKed and the data following later.  With the proposed algorithm described below and the comment in section 9.7 the first sequence should be eliminated.  

Currently the standard says that a power saving STA shall Poll until no more MSDUs or managmenet frames are buffered for that station.  This means that the STA must stay awake until it either sees the More Data bit clear in a received frame or sees itÕs TIM bit clear in a beacon.

The question is: Why does the STA need to send a PS-Poll for every buffered frame since it is awake anyway?  Also:  What does the AP do with extra PS-Polls it receives? (They canÕt be filtered as duplciates since there is no sequence number).

The text changes proposed amount essentially to another state the AP keeps which says a particular STA is currently Awake.  This state is entered when receiving a PS-Poll from the STA and can be assumed to be exited when a frame is successfully delivered with the More Data bit cleared or a beacon is sent with the STAs TIM bit cleared.

	Change11.2.1.4 part f) to read as follows:

All buffered MSDU or managmenet frames for a station in the PS mode shall be forwarded to the station after a PS-Poll has been received from that station.  The more Data field shall be set to indicate the presence of further buffered MSDUs or management frames for the polling station.  All subsequent PS-Polls from the polling station shall be ignored until all buffered frames have been delivered at which point the arrival of more data for the polling station shall be buffered and only sent if another PS-Poll is received.

Change 11.2.1.6 part d) to read as follows:

If the More Data field in the received MSDU or management frame indicate that more traffic for that station is buffered, the station shall remain in the Awake State until it either receives an MSDU or management frame with the More Data field cleared, or it receives a Beacon frame with the stationÕs TIM bit cleared, at which point it may resume its Power saving and return to the Doze state.	Duplicate	
46.		11.2.1.5 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	SID of CF-Aware stations.  A CF-Aware station for which the TIM element of the most recent Beacon indicated buffered MSDUs or management frames shall be in the Awake state at least until the receipt of a directed frame from the AP in which the Frame	Accepted in Plenary Motion 8	
47.		11.2.1.6	jjk	e		a value between 0 and Cwmin is not a time interval	b)	When a station detects that the bit corresponding to its SID is set in the TIM, the station shall issue a PS-Poll to retrieve the buffered MSDU or management frame.  If more than one bit is set in the TIM, the PS-Poll shall be transmitted after a delay of a random number of Slot Timesuniformly distributed between zero and aCW_min.
	editorial	
48.		11.2.1.6	ch	T	Y	If a STA missed the last broadcast after a DTIM, without this rule it would have to stay awake until more broadcasts were sent, which could be a long time.	e)	To receive broadcast/multicast MSDUs, the station shall wake up so as to receive every DTIM.  A station receiving broadcast/multicast MSDUs shall remain awake until the More Data field  of the broadcast/multicast MSDUs indicate there are no further buffered broadcast/multicast MSDUs or a TIM is received indicating there are no more buffered broadcast/multicast MSDUs buffered.	Accepted	
49.		11.2.1.7	BO	E			a)	Stations shall enter Awake state so as to receive the Beacon frame (which contains a DTIM) at the start of each contention free period.	editorial	
50.		11.2.1.7	ch	T	Y	Corrections to PS mode behaviour during CFP	a)	When a station detects that the bit corresponding to its SID is set in the DTIM at the start of the contention free period, the station shall remain in Awake state for at least that portion of the contention free period through the time that station receives a directed MSDU or management frame from the AP with the More Data field  in the Frame Control field indicating no further traffic is buffered.
b) 	To receive broadcast/multicast MSDUs, the station shall wake up so as to receive every DTIM which may be sent during the CFP.  A station receiving broadcast/multicast MSDUs shall remain awake until the More Data field  of the broadcast/multicast MSDUs indicate there are no further buffered broadcast/multicast MSDUs or a TIM is received indicating there are no more buffered broadcast/multicast MSDUs buffered.
c)	If the More Data field  in the Frame Control field of the last MSDU or management frame received from the AP indicate that more traffic for the station is buffered when the contention free period ends, the station may remain in Awake state, and transmit PS-Poll frames during the contention period to request the delivery of additional buffered MSDU or management frames, or may enter Doze state during the contention period (except when DTIMs are expected during the contention period), awaiting the start of the next contention free period.
	Part A must remain, since in the CFP the STA must remain awake
Part B, parenthetical statement not deleted; it is informational.
New part B accepted and moved in front of old B.	
51.		11.2.1.7	TT	t/e	Y	Subpart a) seems to not be finished.	Add to end of subpart a)

...DTIM in Beacon had SID 0 set indicating the presence of broadcast or multicast traffic.	Accepted,  addressed by change to 11.2.2.1.	
52.		11.2.1.7	TT	t/e	Y	Subpart a) seems to not be finished.	Add to end of subpart a)

...DTIM in Beacon had SID 0 set indicating the presence of broadcast or multicast traffic.	Accepted,  addressed by change to 11.2.2.1.	
53.		11.2.2	sb	e	n	Irregular fonts throughout this section	-	editorial	
54.		11.2.2.1	ch	T	Y	broadcast ATIMs are not acknowledged	An ATIM will have a destination address of broadcast/multicast for broadcast/multicast MSDUs. All stations shall remain awake if they receive an ATIM with a broadcast/multicast destination address. ATIMs with broadcast/multicast destination address are not acknowledged.
	Accepted	
55.		11.2.2.1	TT	t	Y		Fourth paragraph, second sentence, change to:

All stations will remain awake until the next ATIM window if they receive an ATIM with a broadcast/multicast destination address.	Accepted	
56.		11.2.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	stations are awake. The announcement is done via an Ad Hoc Traffic Indication Message (ATIM). A power conserving station listens for these announcements to determine if its receiver shall be left on.
When a MSDU is to be transmitted to a destination station that is in a Power Save (PS) mode, the transmitting station first transmits an ATIM frame during the ATIM Window, in which all the stations including those operating in a Power Save (PS) mode are awake. The ATIM Window is defined as a specific period of time following a beacon during which only ATIM frames may be transmitted. ATIMs are randomized after the beacon using the backoff procedure. ATIMs are acknowledged. If a station receives an ATIM frame during the ATIM Window, it shall acknowledge the ATIM and stay awake for the entire Beacon Interval waiting for the announced MSDU(s) to be received. If a Station does not receive an ATIM, it may go back to PS Mode after the end of the ATIM Window. MSDUs announced by ATIMs are randomized after the ATIM Window using the backoff procedure. If a station transmitting the ATIM does not receive an acknowledgment, the station shall execute the backoff procedure for retransmission of the ATIM. 
It is possible that an ATIM may be received from more that one station and that a station that receives an ATIM may receive more than a single MSDU from the transmitting station. ATIM frames are only	Accepted in Plenary Motion 8	
57.		11.2.2.1 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	An ATIM shall have a destination address of broadcast/multicast for broadcast/multicast MSDUs. All stations shall remain awake if they receive an ATIM with a broadcast/multicast destination address.
	Accepted in Plenary Motion 8	
58.		11.2.2.1	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	The estimated power saving state of another station may be based on the power management information transmitted by that station and additional information available locally such as history of failed transmission attempts. The use of RTS/CTS in an Independent BSS may reduce the length of transmissions to a station that is in Power Save mode. If a RTS is sent and a CTS is not received, the transmitting station may assume that the destination station is Power Save mode. The method of estimating the power management state of other stations in the IBSS is outside the scope of this standard.
	Accepted in Plenary Motion 8	
59.		11.2.2.1	jz	T	Y	Multicast/Broadcast reliability is compromised by the power save mechanism. We should adopt the mechanism is 96/15 and 96/16 to fix this. My “No” vote will only change to a “Yes” vote if we adopt these changes or else mandate the use of a stripped-down PCF to enhance multidestination reliability.	<<Adopt changed text for this section from 96/16.>>	Deferred	
60.		11.2.2.1	TT	t	Y		Fourth paragraph, second sentence, change to:

All stations will remain awake until the next ATIM window if they receive an ATIM with a broadcast/multicast destination address.	duplicate	
61.		11.2.2.2	ch	t		wrong parameter set name	a)	A STA joining an existing IBSS by the procedure in subclause 8.1.3.3 shall replace its aATIM_Window MIB attribute with the value contained in the ATIM Window field of the IBSS Parameter Set element within the Beacon, or Probe Response Management frame received during the scan procedure. 
b)	A STA creating a new IBSS by the procedure in subclause 8.1.3.3 shall set the value of the ATIM Window field of the IBSS Parameter set element within the Beacon Management frames transmitted to the value of its aATIM_Window MIB attribute.	Accepted	
62.		11.2.2.2	ch	t		If the ATIM windows must be static through the life of the IBSS, then can a PS station never join an IBSS which was formed by a non-PS station (assuming that the non-PS station will have started the IBSS with a zero length aTIM_Window?

I don’t really care, I just want to amke sure that is the intent, and it didn;t just happen by accident.		Accepted	
63.		11.2.2.2	ch	T	Y	Clarity - I don’t think this formula makes sense (although, it is getting late). Since I don’t know what it is trying to mean, I don’t have a suggestion of how to fix it either. Sorry

c)	The start of the ATIM Window shall be the Target Beacon Transmission Time, defined in subclause 8.1.2.2.. The end of the ATIM Window shall be defined as [TSF timer]MOD aBeacon_Interval – aATIM_Window=0.
		Accepted, it is correct as it is but confusing, changed to [TSF timer]MOD aBeacon_Interval = aATIM_Window	
64.		11.2.2.4	BO	T	Y	Wasn’t this already done when sending the ATIM?  If what is meant is that the first frame sent after the ATIM window should be randomized, make the changes shown.	g)	Immediately following the ATIM Window, a STA shall begin transmission of buffered MSDUs to STAs for which a valid acknowledgment for a transmitted ATIM frame was received. All STAs shall use the backoff procedure defined in clause Error! Reference source not found. for transmission of the first frame following the ATIM Window.	Accepted, but expanded to make all STAs behave as if media was busy and perform backoff.  All broadcast traffic shall be transmitted first, then directed traffic which has been announced and ACKd with an ATIM, then any Broadcast/Multicast traffic.  	
65.		11.2.2.4	BO	T	Y	No mechanism is described allowing stations to discard frames buffered for transmission that it is no longer desirable to transmit or no longer desirable to buffer.	k)	A station may discard frames buffered for later transmission to power saving stations if the station determines that the frame has been buffered for an excessive amount of time or if other conditions internal to the station implementation make it desirable to discard buffered frames, e.g., buffer starvation.  In no case shall a frame be discarded that has been buffered for less than aBeacon_Period.	Accepted. 	
66.		11.4.1.2.2	ch	E		its aDTIM_Period, not aDTIM_Interval	aDTIM_Period	editorial	
67.		11.4.1.2.2
11.4.3.2.2

11.4.2.2.1	TT	t	Y	In stations that have PHYs with more than one basic rate another MIB variable is needed to inform the MAC what rate it should transmit control and management frames since aRate_Factor is used to tell the MAC what rate to transmit data frames.	Add attribute  aStation_Basic_Rate to agOperation_grp.

Add attribute aStation_Basic_Rate to oMAC as GET-REPLACE.

Add MIB description of aStation_Basic_Rate
BEHAVIOUR DEFINED AS
ÒThis attribute indicates the current rate (in kbits/s) selected from the Basic_Rate_Set, which the STA is to use for transmission of Control and Management frames.  The default value of this attribute shall be 1 000.Ó;
	Defer to discussion of multi-rate	
68.		11.4.1.2.2
11.4.3.2.2

11.4.2.2.1	TT	t	Y	In stations that have PHYs with more than one basic rate another MIB variable is needed to inform the MAC what rate it should transmit control and management frames since aRate_Factor is used to tell the MAC what rate to transmit data frames.	Add attribute  aStation_Basic_Rate to agOperation_grp.

Add attribute aStation_Basic_Rate to oMAC as GET-REPLACE.

Add MIB description of aStation_Basic_Rate
BEHAVIOUR DEFINED AS
ÒThis attribute indicates the current rate (in kbits/s) selected from the Basic_Rate_Set, which the STA is to use for transmission of Control and Management frames.  The default value of this attribute shall be 1 000.Ó;
	duplicate	
69.		11.4.2.2.1	ch	e		missing “,”	aLong_Retry_Limit  GET-REPLACE,
	editorial 	
70.		11.4.2.2.1	AS	t	y	aCWmin and aCWmax should be get only		Accepted, refer to #73	
71.		11.4.2.2.1

11.4.3.2.2

11.4.4.2.38	TT	t	Y	aDTIM_Interval is the same as aDTIM_Period.	Remove aDTIM_Interval from oMAC list.

Remove aDTIM_Interval from agOperation_grp.

Delete 11.4.4.2.38	Accepted	
72.		11.4.2.2.1

11.4.3.2.2

11.4.4.2.38	TT	t	Y	aDTIM_Interval is the same as aDTIM_Period.	Remove aDTIM_Interval from oMAC list.

Remove aDTIM_Interval from agOperation_grp.

Delete 11.4.4.2.38	Duplicate	
73.		11.4.2.2.1,
11.4.4.2.27,
11.4.4.2.28
9.2.4,
	ch	t		aCWmin and aCWmax are fixed, aren’t they? If they’re not, isn’t an unfair advantage gained by someone who chooses to use 31 as a minimum instead of 7?	9.2.4:
aCWmin and aCWmax are MAC constants that are for all MAC implementations, because they effect the access fairness between stations.

11.4.2.2.1:
aCW_max       GET-REPLACE,
aCW_min       GET-REPLACE,

11.4.4.27
"This attribute indicates the maximum size of the contention window, in slots.  The value of this attribute shall be 255."

11.4.4.28:
"This attribute indicates the minimum size of the contention window, in slots.  The value of this attribute shall be 7."

	Accepted 	
74.		11.4.4.1.15
8.3.2
	WD	e	n	Update Clause 8 reference
And Clause 5.3.2 reference		editorial	
75.		11.4.4.1.15	sb	e	n	aWEP_Key_Mapping does not have full registration details	Add full registration.	Editorial	
76.		11.4.4.1.16	BO	T	Y	Default value must be specified.	Exclude_Unencrypted  ATTRIBUTE
WITH APPROPRIATE SYNTAX 
boolean;
BEHAVIOUR DEFINED AS
“When this attribute is true, the station shall discard received MSDUs that have the WEP Frame Control bit equal to zero.  When this attribute is false, the station may accept MSDUs that have the WEP Frame Control bit equal to zero.  The default value of this attribute shall be false.”;	Accepted	
77.		11.4.4.1.20	TT	t	Y	Time spent on any one channel during a passive scan should result in the chance of hearing at least one frame.  In an idle network this would be the Beacon frame, therefore passive scan duration default should be the same as aBeacon_Period.	Change last sentence of BEHAVIOUR DEFINED AS to:

The default value of this attribute shall be equal to aBeacon_Period.	Accepted	
78.		11.4.4.1.20 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	“This attribute defines the maximum time, in kmicroseconds, that a station shall remain on a single channel during a passive scan of that channel.  The default value of this attribute shall be	Accepted in Plenary Motion 8	
79.		11.4.4.1.20	TT	t	Y	Time spent on any one channel during a passive scan should result in the chance of hearing at least one frame.  In an idle network this would be the Beacon frame, therefore passive scan duration default should be the same as aBeacon_Period.	Change last sentence of BEHAVIOUR DEFINED AS to:

The default value of this attribute shall be equal to aBeacon_Period.	duplicate	
80.		11.4.4.1.22	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"Scan_Mode is an enumerated type that may take on the values ACTIVE or PASSIVE.  The default value of this attribute shall be PASSIVE.”;
	Accepted in Plenary Motion 8	
81.		11.4.4.1.24	ch	t	Y	Subclause 7.3.2.5 says that the field in the DTIM beacon is CFP_Period (not rate) and is defined in units of DTIM Intervals (not beacon intervals).

Correspoding comment has been made in 9.3.1 which explains the use of CFP_Rate	This attribute indicates the number of DTIM intervals between the DTIMs that start contention free periods.  The default value of this attribute shall be 5.	Accepted	
82.		11.4.4.1.24	TT	t	Y	aCFP_Rate must always be an integral number of  DTIM periods.  A default number in units of Beacon Periods would potentially conflict when the aDTIM_Period parameter is changed.  Therefore this aCFP_Rate should be in units of DTIM Periods.	Change BEHAVIOUR DEFINED AS to:

ÒThis attribute indcates the number of DTIM Periods between the beacons that start contention free periods.  The default value of this attribute shall be 1.Ó;	Accepted	
83.		11.4.4.1.24	TT	t	Y	aCFP_Rate must always be an integral number of  DTIM periods.  A default number in units of Beacon Periods would potentially conflict when the aDTIM_Period parameter is changed.  Therefore this aCFP_Rate should be in units of DTIM Periods.	Change BEHAVIOUR DEFINED AS to:

ÒThis attribute indcates the number of DTIM Periods between the beacons that start contention free periods.  The default value of this attribute shall be 1.Ó;	duplicate	
84.		11.4.4.1.25	ch	t	Y	In subclause 9.3.3.4 it define snim and max, which should be here also. Wh ynot use min as default?.	The default, and minimum, value of this attribute shall be twice aMAX_MPDU_Time plus the time required to send one Beacon and One CF-End frame. The maximum value of this attribute shall be defined by the following equation, when operating with a contention window of aCW_min:
aCFP_Rate - (aMax_MPDU_Time + aHandshake_Overhead + aACK_Time)	Acceot specification of min, add specification of max  by calculation 	
85.		11.4.4.1.26
9.3.3.4

&
	WD	T	Y	The current definition of the CFP_Max_Duration limit is not sufficient to allow non-CF_aware stations to succesfully transfer data, with such transfer delays that are acceptable to higher protocol layers.
Known values of such timeout mechanisms are in the 400-600 msec range, after which a protocol layer message is expected to be received. This means that a station should at maximum have an opertunity to send every 200 msec or so, otherwise the higher layer times out, and retransmits the same message with a limited maximum retry limit.
Currently the CFP_Period can be specified as multiple integers of the DTIM interval, where the MIB default is set to 5.
We need to specify that the CFP_Period should be limited to 200 msec maximum.

Change the MIB defaults such that this setting would not violate the 200 msec maximum	Add to the end of section 9.3.3.4:
The CFP_period shall be no larger then 200 msec to allow sufficient response time for a non-CF-Aware station to access the medium.

Modify section 11.4.4.1.24:
Change the default value to 1

Modify section 11.4.4.1.26:
Change the default to 2.	Partially accept: default value is less than 200 ms.  Rationale for rejection: no need to limit upper level protocol control.	
86.		11.4.4.1.27 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	“This attribute defines the period of time, in microseconds, after a target beacon transmission time in an IBSS during which stations buffering frames for Power Save mode stations shall attempt to notify those stations by transmitting an ATIM frame. The ATIM window begins at the	Accepted in Plenary Motion 8	
87.		11.4.4.2.19	sb	t	n	On what basis is aError_Count incremented ? No  behaviour defined. ISO/IEC 10165-2 defines as the total number of corrupted PDUs received. Corrupted PDUs will could an FCS failure, be runt frames, too long frames, invalid fields - eg protocol version. Behaviour should be defined as including all the intended types. 
	Add: BEHAVIOUR DEFINED AS
The total number of PDUs discarded due to error, including CRCs, invalid length frames and invalid frame formats	Accepted	
88.		11.4.4.2.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"A set of MAC_Addresses identifying the multicast addresses for which this station may receive frames.  The default value of this attribute shall be null."
	Accepted in Plenary Motion 8	
89.		11.4.4.2.21	BO	T	Y	Incorrect definition.	Frame_Duplicate_Count  ATTRIBUTE
DERIVED FROM
"ISO/IEC 10165-2":counter;
	Accepted	
90.		11.4.4.2.22	BO	E			Rate_Factor ATTRIBUTE
WITH APPROPRIATE SYNTAX 
integer;
BEHAVIOUR DEFINED AS 
"This attribute shall indicate the current rate (in bits per second) at which data is transferred across the medium.  The default value of this attribute shall be 1 000 000.";
	editorial 	
91.		11.4.4.2.22	sb	t	n	Use of aRate_Factor is not clear. Current rate at which data is transferred across medium could change on a per packet basis. Suggest deletion of this MIB entry. 	Delete text	Defer to discussion of multirate	
92.		11.4.4.2.22	TT	t	Y	aRate_Factor Numbers and description donÕt match.	Change BEHAVIOUR DEFINED AS to:

ÒThis attribute indicates the current rate in kbits/s at which frames are transferred accross the medium (except where certain frame types are fixed at a given rate, e.g. Control frames using an FH PHY).  The default value of this attribute shall be 1 000.	Defer to discussion of multirat	
93.		11.4.4.2.22	TT	t	Y	aRate_Factor Numbers and description donÕt match.	Change BEHAVIOUR DEFINED AS to:

ÒThis attribute indicates the current rate in kbits/s at which frames are transferred accross the medium (except where certain frame types are fixed at a given rate, e.g. Control frames using an FH PHY).  The default value of this attribute shall be 1 000.		
94.		11.4.4.2.24	BO	T	Y	Value is not correct since the length WEP-expanded frames may exceed this value and the intent was to have RTS/CTS off by default.	RTS_Threshold ATTRIBUTE
WITH APPROPRIATE SYNTAX 
integer;
BEHAVIOUR DEFINED AS 
"This attribute shall indicate the number of bytes in an MPDU, below which an RTS/CTS handshake will not be performed.  An RTS/CTS handshake shall be performed for all frames where the length of the MPDU is equal to or larger than this threshold.  Setting this attribute to be larger than the maximum MSDU size will have the effect of turning off the RTS/CTS handshake for frames transmitted by this station. Setting this attribute to zero will have the effect of turning on the RTS/CTS handshake for all MPDUs for frames transmitted by this station.  The default value of this attribute shall be 3000.";
	Accepted	
95.		11.4.4.2.24	TT	t	Y	aRTS_Threshold default is chosen so that RTS/CTS is not active.  The default must be greater than the largest MPDU, not the largest MSDU since the size of the MPDU is used to determine whether or not to use RTS/CTS handshake. 

The largest MPDU =  Frame Control 	2
		      Duration		2
		      Address 1 - 4	24
		      Sequence Control	2
		      Frame Body (+WEP)	2312
		      CRC		4
		      -------------------------------------
		      Total:		2346	Change last sentence of BEHAVIOUR DEFINED AS to:

The default value of this attribute shall be 2347.	Accepted with modifications as per #94	
96.		11.4.4.2.24 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute indicates the number of bytes in an MPDU, below which an RTS/CTS handshake shall not be performed.  An RTS/CTS handshake shall be performed for all frames where the length of the MPDU is equal to or larger than this threshold.  Setting this attribute to be larger than the maximum MSDU size shall have the effect of turning off the RTS/CTS handshake for frames transmitted by this station. Setting this attribute to zero shall have the effect of turning on the RTS/CTS handshake for all MPDUs for frames transmitted by this station.  The default value of this	Accepted in Plenary Motion 8	
97.		11.4.4.2.24	TT	t	Y	aRTS_Threshold default is chosen so that RTS/CTS is not active.  The default must be greater than the largest MPDU, not the largest MSDU since the size of the MPDU is used to determine whether or not to use RTS/CTS handshake. 

The largest MPDU =  Frame Control 	2
		      Duration		2
		      Address 1 - 4	24
		      Sequence Control	2
		      Frame Body (+WEP)	2312
		      CRC		4
		      -------------------------------------
		      Total:		2346	Change last sentence of BEHAVIOUR DEFINED AS to:

The default value of this attribute shall be 2347.	duplicate	
98.	
99.	
	11.4.4.2.27
9.2.4
	WD	T	Y	The initial aCWmin default should be increased.
This parameter determines the residual collision probability during the collision avoidance process of selecting the backoff delay after a defer.
A high collision probability does directly influence the successrate of  Broadcast and Multicast traffic, including the Beacon frame used within 802.11.
It will further have a negative effect on the efficiency of medium use, resulting in a lower overall throughput of the total system, as demonstarted in the simulations as described in doc P802.11 95/80.
The simulation shows a very high “lost Frame” probability for the Cwmin parameter as is currently specified.
It is therefore suggested to increase the CWmin parameter as suggested in doc 95/80.
The subject of Contention resolution, and Lost frame probability was also addressed in doc 95/182 and 183, with suggestions to decrease the collision probability that was based on the already suggested much larger Cwmin =32. HIPERLAN uses a different mechanism, but their goal is to achieve a maximum collision probability of 3.5 % maximum. The currently specified Cwmin=7 does represent a much much higher collision probability in the 20-30% range.
Subsequent simulation results will be presented at the meeting where feasible.
Several users that gained experience with the access method using prototype implementations have testified to me that the suggested Cwmin =7 is too low.

This Cwmin parameter should be the same for all stations that do contend for the medium within the same area, because they affect the access fairness between stations, and can therefore be specified on a per PHY basis, unlike described in section 9.2.4, which specifies this value to be the same accross all PHY’s.	Change 9.2.4, just above figure as follows:
The set of CW values are CW=2^k*Cwmin-1, with k ranging from 0 to a value that results in a CW=255.
CWmin should be 32 for a DS PHY.
CWmin should be TBD for a FH PHY.
Cwmin should be TBD for an IR PHY.	Deferred 	
100.		11.4.4.2.28	TT	t	Y	aCTS_Time being a measure of the time it takes to transmit a CTS frame is obviously dependant on the bit rate used to transmit the CTS.  For the FH PHY this is not a problem since all control frames must be transmitted at the one and only Basic Rate of 1 Mbit/s.

For the DS and IR PHYs the Basic Rate can be 1 or 2 Mbit/s which implies that a station waiting to receive a CTS will not know at what rate the other station will be transmitting. 

Therefore aCTS_Time must represent the time to transmit the CTS at the lowest bit rate of the Basic Rate Set.

This means that slot time synchronization may be lost when a node does not hear a 2 Mbit/s CTS but other nodes around it did.  The only way to solve this problem would be to have all control frames sent at the lowest rate or to limit operation in a BSS to only one rate at a time for all STAs	Add to:
BEHAVIOUR DEFINED AS

ÒFor PHYs that have multiple basic rates this time will be calculated for the lowest rate.Ó	Defered – multirate issue	
101.		11.4.4.2.28	TT	t	Y	aCTS_Time being a measure of the time it takes to transmit a CTS frame is obviously dependant on the bit rate used to transmit the CTS.  For the FH PHY this is not a problem since all control frames must be transmitted at the one and only Basic Rate of 1 Mbit/s.

For the DS and IR PHYs the Basic Rate can be 1 or 2 Mbit/s which implies that a station waiting to receive a CTS will not know at what rate the other station will be transmitting. 

Therefore aCTS_Time must represent the time to transmit the CTS at the lowest bit rate of the Basic Rate Set.

This means that slot time synchronization may be lost when a node does not hear a 2 Mbit/s CTS but other nodes around it did.  The only way to solve this problem would be to have all control frames sent at the lowest rate or to limit operation in a BSS to only one rate at a time for all STAs	Add to:
BEHAVIOUR DEFINED AS

ÒFor PHYs that have multiple basic rates this time will be calculated for the lowest rate.Ó	Defered – multirate issue	
102.		11.4.4.2.29	TT	t	Y	aACK_Time being a measure of the time it takes to transmit a ACK frame is obviously dependant on the bit rate used to transmit the ACK.  For the FH PHY this is not a problem since all control frames must be transmitted at the one and only Basic Rate of 1 Mbit/s.

For the DS and IR PHYs the Basic Rate can be 1 or 2 Mbit/s which implies that a station waiting to receive an ACK will not know at what rate the other station will be transmitting. 

Therefore aACK_Time must represent the time to transmit the ACK at the lowest bit rate of the Basic Rate Set.

This means that slot time synchronization may be lost when a node does not hear a 2 Mbit/s ACK but other nodes around it did.  The only way to solve this problem would be to have all control frames sent at the lowest rate or to limit operation in a BSS to only one rate at a time for all STAs	Add to:
BEHAVIOUR DEFINED AS

ÒFor PHYs that have multiple basic rates this time will be calculated for the lowest rate.Ó	duplicate	
103.		11.4.4.2.29	TT	t	Y	aACK_Time being a measure of the time it takes to transmit a ACK frame is obviously dependant on the bit rate used to transmit the ACK.  For the FH PHY this is not a problem since all control frames must be transmitted at the one and only Basic Rate of 1 Mbit/s.

For the DS and IR PHYs the Basic Rate can be 1 or 2 Mbit/s which implies that a station waiting to receive an ACK will not know at what rate the other station will be transmitting. 

Therefore aACK_Time must represent the time to transmit the ACK at the lowest bit rate of the Basic Rate Set.

This means that slot time synchronization may be lost when a node does not hear a 2 Mbit/s ACK but other nodes around it did.  The only way to solve this problem would be to have all control frames sent at the lowest rate or to limit operation in a BSS to only one rate at a time for all STAs	Add to:
BEHAVIOUR DEFINED AS

ÒFor PHYs that have multiple basic rates this time will be calculated for the lowest rate.Ó	duplicate	
104.		11.4.4.2.3	db	T	Y	This ability represents a sever security hole for 802.11. It shoould not be possible for any adaptor to listen to all traffic - the proper place for this is in net analyzer equipment (which by definition of ot’s operation is unlikely to be 802.11 compliant).
	Remove entire MIB attribute and associated ability.	Accepted	
105.		11.4.4.2.30

11.4.1.2.2

11.4.2.2.1	TT	t	Y	Since both aACK_Time and aCTS_Time are defined then we also need both timeout values.  Currently only aACK_Timeout is defined.  Need to add aCTS_Timeout.	Add identical attribute as 11.4.4.2.30 aACK_Timeout called aCTS_Timeout with: 
BEHAVIOUR DEFINED AS

ÒThis attribute spcifies the length of time, in microseconds, in which an CTS frame will be received in response to an RTS frame, timed from receive of PHY_Data.confirm at the MAC.  The following equation is used to determine aCTS_Timeout: aSIFS_Time + aCTS_TimeÓ;	Accepted	
106.		11.4.4.2.30 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute specifies the length of time, in microseconds, in which an ACK frame may be received in response to transmission of a frame which requires acknowledgment, timed from receipt	Accepted in Plenary Motion 8	
107.		11.4.4.2.30

11.4.1.2.2

11.4.2.2.1	TT	t	Y	Since both aACK_Time and aCTS_Time are defined then we also need both timeout values.  Currently only aACK_Timeout is defined.  Need to add aCTS_Timeout.	Add identical attribute as 11.4.4.2.30 aACK_Timeout called aCTS_Timeout with: 
BEHAVIOUR DEFINED AS

ÒThis attribute spcifies the length of time, in microseconds, in which an CTS frame will be received in response to an RTS frame, timed from receive of PHY_Data.confirm at the MAC.  The following equation is used to determine aCTS_Timeout: aSIFS_Time + aCTS_TimeÓ;	duplicate	
108.	
	11.4.4.2.31
11.4.4.2.32
9.2.5.3
	WD	T	Y	The intend of  having two Retry Limits is to cope with two significant different situations. One is that retries are needed to retry a transmission that failed primarily due to residual access collisions in the contention resolution process of CSMA/CA.
The other case is primarily geared toward a “Hidden Station” situation, where frames are primarily lost, or CTS is not returned. because the medium is busy in the vicinity of the receive station.
In the latter case the defer mechanism does not work for the stations that compete for the medium, and hence a higher value for the Retry Limit is needed to increase the probability that subsequent transmissions are separated in time so that they do not overlap and interfere with each other.
So in general the Retry Limit needs to be a higher value in the cases when “Hidden Node” protection is targetted for. This can be detected by looking at the aRTS_Threshold parameter, which is 2305 or higher when the RTS/CTS mechanism is switched off.
The current mechanism, together with the values specified in the MIB, causes a reverse behaviour. In addition, when the correct (changed) default values are specified in the MIB, then the effect is that the Short_Retry_Limit (the higher value) is then always used when the RTS/CTS mechanism is effectively turned off.
The suggested text corrects this problem, by selecting the Short_Retry_Limit only when the RTS_Threshold parameter is lower then the default 2305.
In addition it does reverse and change the defaults values specified in the MIB.
It also corrects the problem in the MIB, which inadvertently defines aFragmentation_Threshold rather than RTS_Threshold.	Change text in section 9.2.5.3
Add the following at the end of the  last sentence:
, unless aRTS_Threshold is higher then 2304, in which case aLong_Retry_Limit should always be used.

Change text in section 11.4.4.2.31:
Change “aFragmentation_Threshold” into “aRTS_Threshold”.
Change the default value 5 into 7.

Change text in section 11.4.4.2.32:
Change “aFragmentation_Threshold” into “aRTS_Threshold”.
Change the default value 7 into 4.	Items pertaining to section 11 accepted	
109.		11.4.4.2.31 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute indicates the maximum number of transmission attempts of a frame, the length of which is less than or equal to aFragmentation_Threshold, that shall be made before a failure condition is indicated.  The default value of this attribute shall be 5.";
	Accepted in Plenary Motion 8	
110.		11.4.4.2.32 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute indicates the maximum number of transmission attempts of a frame, the length of which is greater than aFragmentation_Threshold, that shall be made before a failure condition is indicated.  The default value of this attribute shall be 7.";
	Accepted in Plenary Motion 8	
111.		11.4.4.2.33	TT	t	Y	The name, aMax_Frame_Length, of this attribute is misleading since it refers to Frame whereas the attribute is specifying the size of an MSDU.	Change the name of this Attribute from aMax_Frame_Length to: aMax_MSDU_Length.	Rejected: name reflects other 802 standards names.	
112.		11.4.4.2.33 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute specifies the maximum MSDU length that shall be accepted for transmission.  The value of this attribute shall be 2304 octets.";
	Accepted in Plenary Motion 8	
113.		11.4.4.2.33	TT	t	Y	The name, aMax_Frame_Length, of this attribute is misleading since it refers to Frame whereas the attribute is specifying the size of an MSDU.	Change the name of this Attribute from aMax_Frame_Length to: aMax_MSDU_Length.	duplicate	
114.		11.4.4.2.34	BO	E			Fragmentation_Threshold ATTRIBUTE
WITH APPROPRIATE SYNTAX 
integer;
BEHAVIOUR 
"This attribute shall specify the current maximum size, in octets, of the MPDU that will be delivered to the PHY.  An MSDU shall be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers.  The default value for this attribute shall be equal to aMPDU_Max_Lngth of the attached PHY and shall never exceed the aMPDU_Max_Lngth of the attached PHY.  The value of this attribute shall never be less than 256.  The default value of this attribute shall be 2304.";
	editorial	
115.		11.4.4.2.34	TT	t	Y	There are two conflicting definitions of the default value for the aFragmentation_Threshold attribute.  The first one which is based on the max PSDU fo the attached PHY is the correct one.	Delete last sentence of BEHAVIOUR ÒThe default value of this attribute shal be 2304Ó.
	Rejected: value chosen to reflect payload, overhead, and WEP expansion.  Also TT’s suggestion implies order of initialization.	
116.		11.4.4.2.34 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"This attribute specifies the current maximum size, in octets, of the MPDU that may be delivered to the PHY.  An MSDU shall be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers.  The default value for this attribute shall be equal to	Accepted in Plenary Motion 8	
117.		11.4.4.2.34	TT	t	Y	There are two conflicting definitions of the default value for the aFragmentation_Threshold attribute.  The first one which is based on the max PSDU fo the attached PHY is the correct one.	Delete last sentence of BEHAVIOUR ÒThe default value of this attribute shal be 2304Ó.
	duplicate	
118.		11.4.4.2.38	BO	T	Y	Redundant with 11.4.4.1.26		Accepted	
119.		11.4.4.2.6	TT	t	Y	aOctets_Transmitted_Count description does not define at which interface the count is taken.  The main count of interest would seem to be the number of data bytes sent therefore this should be a count of MSDU bytes.	Add:
BEHAVIOUR DEFINED AS
ÒThis counter shall be incremented by the number of octets in each successfully transmitted MSDU.Ó;	Rejected: ISO standard counter type, 802.11 defines only those entities which differ from commonly used items (ref ISO 10165-2).	
120.		11.4.4.2.6	TT	t	Y	aOctets_Transmitted_Count description does not define at which interface the count is taken.  The main count of interest would seem to be the number of data bytes sent therefore this should be a count of MSDU bytes.	Add:
BEHAVIOUR DEFINED AS
ÒThis counter shall be incremented by the number of octets in each successfully transmitted MSDU.Ó;	duplicate	
121.		11.4.4.2.9	BO	T	Y	The definition is no longer correct.	Failed_Count ATTRIBUTE
DERIVED FROM
"ISO/IEC 10165-2":counter;
BEHAVIOUR DEFINED AS 
"This counter shall increment when a frame is not transmitted due to the number of transmit attempts exceeding either the aShortRetryLimit or aLongRetryLimit.";
	Accepted	
122.		11.4.5.2.2 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"The Add_Group_Address action shall add the specified group address to the list of group addresses that shall be accepted by the station.";
	Accepted in Plenary Motion 8	
123.		11.4.5.2.3 
A.4.4	db	T	Y	w/o the requested change the Draft is technically incorrect - since approved “standard” language was not used the draft does not corectly convey operational requirements.	"The Delete_Group_Address action shall remove the specified group address from the list of group addresses that shall be accepted by the station.";
	Accepted in Plenary Motion 8	
124.									

Seq. #	Section number	your initials	Cmnt type
E, e, T, t	Part of NO vote	Comment/Rationale	Corrected Text	Disposition/Rebuttal