IEEE 802.11
Wireless Access Method and Physical Layer Specifications
Title:	Frame Exchange Sequences
Presented by:	Johnny Zweig
Xircom, Inc.
2041 Landings Drive
Mountain View, CA 94043
Tel:	(415) 691-2500
Fax:	(415) 691-1064
Email:	jzweig@xircom.com
Abstract:	This paper provides revised text for P802.11/D3.1 Clause 9.7 that corrects inadequacies in the current wording of the frame exchange sequences definition.
Action:	Adopt the text changes proposed in this paper for inclusion in P802.11/D4.0.
Introduction
The tables of allowable Frame Exchange Sequences (currently in Clause 9.7) have undergone a sequence of revisions and editing over the course of the last few years that have left them confusing and inefficient. In order to address a number of Letter Ballot comments from D2.0 and D3.0 that complain about those shortcomings, I have revised the notation somewhat and added text to explain all of the entries. The text below is, I believe, complete, correct, efficient (in the sense of not using multiple entries in the table to define the same thing) and understandable. That is, it states the intent of D3.1 in a notation that does not involve redundancies, asterisks, superscripts or other hindrances to comprehension.
As the text of clause 9.7 is normative (other clauses refer to 9.7 as their definition of what frames may be sent with an SIFS interval between them), it is important that the notation be concise, unambiguous and intelligible.
The one thing that the revised version of the tables does not describe (though I believe it is adequately specified elsewhere in the draft) is what happens when one of the frames in a multriframe sequence is not received correctly. That is, it does not specifically point out that if a frame sequence is interrupted (such as an unacknowledged fragment of an MSDU or MMPDU or a CF-Poll going unresponded-to), recovery procedures specified elsewhere need to be followed. For instance, even if something goes wrong during the contention free period, the CF-End that marks its finish needs to be sent, and the CF period can continue after the appropriate PIFS and so forth.
Notice the term “MMPDU” in the table. I used this term (MAC Management Protocol Service Data Unit) to refer to what we used to (incorrectly) call “management frames”. The previous terminology was incorrect because certain management PDUs may be long enough to require fragmentation and may, therefore, be sent as a sequence of frames. Protocol Data Unit is, I believe, the technically correct term. Notice that in the description of the notation, the terms involved do indeed refer to individual frames, so I believe the text below is both precise and correct in the table note and the description of the notation.
I am not sure whether we need the word “shall” in the first sentence of the clause. I think it is questionable whether to say the text “summarizes” the allowable sequences, given that certain sequences (in particular the PS-Poll/Data/ACK sequence) are not in fact defined elsewhere. I think the way to address that problem is to define the semantics and limitations of all frame exchange sequences elsewhere in the document.
The text following this sentence represents the text that should be adopted into the next revision of the 802.11 specification.
9.7	Frame Exchange Sequences
The allowable frame exchange sequences are summarized in tables 19 and 20.

Sequence	Frames in
Sequence	Usage	
Data(bc/mc)	1	broadcast or multicast MSDU	
Mgmt(bc)	1	broadcast or multicast MMPDU	
{ RTS Ð CTS Ð } [ Frag Ð ACK Ð ] Last Ð ACK	2 Ð 22	directed MSDU or MMPDU	
PS-Poll Ð ACK	2	deferred PS-POLL response	
PS-Poll Ð [ Frag Ð ACK Ð ] Last Ð ACK	3 Ð 21	immediate PS-POLL response	
DTIM(CF) Ð [ <CF-Sequence> Ð ] CF-End	2 or more	Contention-Free period	
Table 1, Frame Sequences
Where:
Items enclosed in brackets  Ò[É]Ó  may occur zero or more times in the sequence.
Items enclosed in braces  Ò{É}Ó  may occur zero or one time in the sequence.
An isolated hyphen  ÒÐÓ  represents an SIFS interval separating the pair of frames.
ÒData(bc/mc)Ó  represents any frame of type Data with a broadcast or multicast address in the Address1 field.
ÒMgmt(bc)Ó  represents any Management type frame with a broadcast address in the DA field.
“RTS” represents a control frame of subtype RTS.
“CTS” represents a control frame of subtype CTS.
“ACK” represents a control frame of subtype ACK.
ÒFragÓ  represents a frame of type Data or Management with an individual address in the Address1 field that has the More Fragments field set to ‘1’.
ÒLastÓ  represents a frame of type Data or Management with an individual address in the Address1 field that has the More Fragments field set to ‘0’.
“PS-Poll” represents a control frame of subtype PS-Poll.
ÒDTIM(CF)Ó  represents a management frame of subtype Beacon and that contains a DTIM information element with a nonÐzero value in the CF_Dur_Remaining field of its CF Parameter Set element.
ÒCF-EndÓ  represents a control frame of type CF-End, or (if the final frame of the immediately preceding <CF-Sequence> was a directed data or management frame requiring acknowledgment by the AP) of type CF-End+Ack.
ÒBeacon(CF)Ó  represents a management frame of subtype Beacon with a nonÐzero value in the CF_Dur_Remaining field of its CF Parameter Set element.
ÒData(dir)Ó  represents any frame of type Data with an individual address in the Address1 field.
“CF-Ack(no data)” represents a data frame of subtype CF-ACK (no data).
ÒCF-Poll(no data)Ó  represents a data frame of subtype CF-Poll (no data).
“Null(no data)” represents a data frame of subtype Null Function (no data).
The notation “{+CF-Ack}” indicates that the frame may or may not include a contention-free acknowledgement.
The notation “+CF-Ack” indicates that the frame includes a contention-free acknowledgement.
The notation “+CF-Poll” indicates that the frame includes a contention-free poll.
<CF-Sequence>  represents a sequence of one or more frames sent during a contention free period.  A valid <CF-Sequence> shall consist of one of the frame sequences shown in table 20.  The collection of sequences of frame exchanges corresponding to the [<CF-Sequence>] from table 19 may occur in any order within the contention free period.

CF Frame Sequence	Frames in
Sequence	Usage	
Beacon(CF)	1	beacon during CF period	
Data(bc/mc)	1	broadcast or multicast MSDU	
{CF-Ack(no data) Ð } Mgmt(bc)	1 or 2	broadcast MMPDU	
Data(dir)+CF-Poll{+CF-Ack} Ð Data(dir)+CF-Ack	2	poll and ack sent with MSDUs	
Data(dir)+CF-Poll{+CF-Ack} Ð CF-Ack(no data)	2	poll of station with empty queue	
Data(dir)+CF-Poll{+CF-Ack} Ð ACK	2	alternate ack if station queue empty or station is not CF-aware	
Data(dir)+CF-Poll{+CF-Ack} Ð Data(dir)+CF-Ack Ð ACK	3	polled station sends to station in BSS	
CF-Poll(no data){+CF-Ack} Ð Data(dir)	2	separate poll, ack sent with MPDU	
CF-Poll(no data){+CF-Ack} Ð Data(dir) Ð ACK	3	polled station sends to station in BSS	
CF-Poll(no data){+CF-Ack} Ð Null(no data)	2	separate poll, station queue empty	
Data(dir){+CF-Ack} Ð ACK	2	ack if not CF-aware or not polled	
Table 2, CF Frame Sequences