IEEE 802.11
Wireless Access Method and Physical Layer Specifications
Title:	Extended Interframe Space (EIFS)
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 suggested text changes to P802.11/D3.1 to implement the “Smart IFS” proposal put forward by the Multirate Working Group to ameliorate the impact of unsupported data-rate transmissions on neighboring BSSs.
Action:	Adopt the text changes proposed in this paper for inclusion in P802.11/D4.0.

Introduction
At the March 1996 meeting in La Jolla, a Multirate Working Group was formed to come up, once and for all, with an approach to the problems associated with supporting multiple different data rates. Among the recommendations of the group was adoption of a “Smart IFS” approach to dealing with traffic for which it is not possible to determine valid Duration information (whether it is due to bit-errors during reception or to the frame being transmitted at an unsupported data rate). To simplify things, I have coined the term “Extended Interframe Space (EIFS)” to refer to the situation where a station extends the normal IFS by a specific amount to account for one of these situations.
This document is an attempt to show the text changes to the draft necessary to implement this mechanism. Basically, it is necessary to add to the interframe timing specifications in Clause 9 the restriction that a station not transmit so soon after detecting a frame that it cannot process that it would clobber an ACK that someone else may be generating for that frame. It is also necessary to refine the PLCP procedures slightly in clause 12 to mandate that the PHY not indicate that the medium is free immediately after it decides it cannot support the data rate associated with a transmission, and to ensure that the clear channel assessment procedures for each PHY comply with this restriction.
The goal of the mechanism is to ensure that there is a modicum of politeness between different data rates operating in different BSSs that are able to hear one-another. One shortcoming of the mechanism is that if one BSS sends its control frames at a higher rate than another overlapping BSS, the stations in the faster BSS will begin contending for the medium sooner than the stations in the other BSS that cannot receive at the higher rate. There does not seem to be a way of escaping this other than redefining the PLCP procedures for all the PHYs to ensure that every 802.11 station that implements a particular variety of PHY will be able to detect (precisely) the end of every frame. The sentiment of the working group was that making such a major change simply to improve fairness in the case where overlapping BSSs use different data rates for control frames, and fail to implement appropriate RSSI-based CCA techniques, and are overlapping a significant portion of the time, and are so busy that the slow stations don’t get a chance to get a word in edgewise was unwarranted.
Thus the text below requires either that the PHY sense the medium and use that to determine the end of the frame being received, or assume the frame was being sent at 1.0 Mbps (i.e. be conservative in how long you wait before seizing the medium again). So what happens whenever an unsupported data rate frame is received is that the PHY_CCA.indicate(BUSY), PHY_RXSTART.indicate(RXVECTOR) and PHY_RXEND.indicate(Unsupported_Data_Rate) primitives all happen one right after the other, but the PHY_CCA.indicate(IDLE) doesn’t happen until the station no longer senses power or has waited a long enough time to be certain the frame transmission has concluded. This division of labor (i.e. the MAC relying on the PHY to figure out its best guess as to when the medium is once again free) seems most consistent with the current architecture of 802.11.
Notice that the mechanism also handles the case where a CRC error prevents the MAC from determining the Duration field contained in a frame. That is, it fixes another problem in the MAC definition as well.
The text following this sentence represents the text changes proposed for incorporation into the next revision of the 802.11 specification.

9.2.3	 Inter-Frame Space (IFS)
The time interval between frames is called the inter-frame space.  A STA shall determine that the medium is free through the use of the carrier sense function for the interval specified.  Four different IFSs are defined so as to provide of priority levels for access to the wireless media. The following four different IFSs are defined:
a) SIFS		Short Interframe Space
b) PIFS		Point Coordination Function (PCF) Interframe Space
c) DIFS		Distributed Coordination Function (DCF) Interframe Space
d) EIFS		Extended Interframe Space

The different IFSs are independent of the station bit rate. The IFS timings are defined as time gaps on the medium, and are a fixed per each PHY (even in multi-rate capable PHYs). PHY MIB parameters are specify IFS values.

Figure 1, IFS Relationships
9.2.3.1	Short-IFS (SIFS)
The Short Interframe Space shall be used for an ACK frame, a CTS frame, a Data frame of a fragmented MSDU, and by a STA responding to any polling as is used by the Point Coordination Function (PCF) ; and may be used by a point coordinator for any types of frames during the contention free period(See clause Error! Reference source not found., Point Coordination Function). The SIFS is the time from the end of the last symbol of the previous frame to the beginning of the first symbol of the pre-amble of the subsequent frame as seen at the air interface. The valid cases where the SIFS  may or shall be used are listed in Frame Exchange Sequences found in clause Error! Reference source not found..
The SIFS timing will be achieved when the transmission of the subsequent frame is started at the Tx_SIFS Slot boundary as specified in clause 0.
This is the shortest of the interframe spaces. It is used when stations have seized the medium and need to keep it for the duration of the frame exchange they have to perform. Using the smallest gap between transmissions within the frame exchange prevents other stations, which are required to wait for the medium to be free for a longer gap, from attempting to use the medium, thus giving priority to completion of the frame exchange in progress.
9.2.3.2	PCF-IFS (PIFS)
The PCF Interface Space shall be used only by the PCF to gain priority access to the medium at the start of the Contention Free Period (CFP).  The PCF shall be allowed to transmit contention free traffic after it detects the medium free at the Tx-PIFS slot boundary as defined in clause 0. Clause Error! Reference source not found. describes the use of the PIFS by the PCF.
9.2.3.3	DCF-IFS (DIFS)
The DCF Interframe Space shall be used by the DCF to transmit data and management  MPDUs.  A STA using the DCF shall be allowed to transmit if it detects the medium to be free at the Tx_DIFS slot boundary as defined in clause 0 after a correctly-received frame, and its backoff time has expired. A STA using the DCF shall not transmit within an EIFS after it detects the medium to be free following reception of a frame for which the PHY_RXEND.indicate primitive contained an error or for which the MAC CRC value was not correct.
9.2.3.4	Extended-IFS (EIFS)
The Extended Interface Space shall be used by the DCF whenever the PHY has indicated to the MAC that a frame transmission was begun that did not result in the correct reception of a complete MPDU with a correct CRC value. The duration of an EIFS is defined in clause 9.2.10. The EIFS interval shall begin following indication by the PHY that the medium is free after detection of the erroneous frame, without regard to the virtual carrier-sense mechanism. The EIFS is defined to provide enough time for another station to acknowledge the incorrectly-received frame before the STA commences transmission.
9.2.4	 Random Backoff Time
A STA desiring to initiateo transfer of data and management MPDUs shall utilize both the physical and virtual carrier sense functions to determine the state of the medium.  If the medium is busy, the STA shall defer until after a DIFS  is detected, or an EIFS if last frame detected on the medium was not received correctly, and then generate a random backoff period for an additional deferral time before transmitting.  This process minimizes collisions during  contention between multiple STA that have been deferring to the same event.
Backoff Time = INT(CW * Random()) * Slot time
where:

CW  =	An integer between the values of MIB variables aCWmin and aCWmax
Random() = Pseudo random number between 0 and 1
Slot Time  =  The value of MIB variable aSlot_time

The Contention Window (CW) parameter shall take an initial value of aCWmin for every MPDU queued for transmission.  The CW shall take the next value in the series at every retry to send a particular MPDU until it reaches the value of aCWmax. A retry is defined as the entire sequence of frames sent to attempt to deliver an MPDU. The CW will remain at a value of aCWmax for the remaining retries.  This improves the stability of the access protocol under high load conditions.  See Figure 2.
The set of CW values are 7 (Cwmin), 15, 31, 63, 127, 255 (CWmax).

Figure 2, Exponential Increase of CW
aCWmin and aCWmax are MAC constants that should be fixed for all MAC implementations, because they effect the access fairness between stations.
9.2.5	 DCF Access Procedure
The CSMA/CA access method is the foundation of the Distributed Coordination Function. The operational rules vary slightly between Distributed Coordination Function and Point Coordination function.  
9.2.5.1	Basic Access
Basic access refers to the core mechanism a STA uses to determine whether it may transmit.
A STA may transmit a pending MPDU when it is operating under the DCF access method, either in the absence of a Point Coordinator or in the Contention Period of the PCF, when it detects the free medium for greater than or equal to a DIFS, or an EIFS if the medium-busy event was caused by detection of a frame that was not received with a correct MPDU CRC value. If, under these conditions, the medium is busy when a STA desires to initiate the initial frame of one of the frame exchanges described in clause Error! Reference source not found., exclusive of the CF period, the Random Backoff Time algorithm shall be followed. 

The basic access mechanism is illustrated in the following diagram.

Figure 3, Basic Access Method
9.2.5.2	Backoff Procedure
The backoff procedure shall be followed whenever a STA desires to transfer an MPDU and finds the medium busy as indicated by either the physical or virtual carrier sense mechanism (Figure 4).
To begin the backoff procedure, the STA shall select a backoff time from the equation in clause 0 Random Backoff Time. All backoff slots occur following a DIFS period during which the medium is free for the duration of the DIFS period, or following an EIFS period during which the medium is free for the duration of the EIFS period following detection of a frame that was not received correctly.
A STA in backoff must monitor the medium for carrier activity during backoff slots. If no carrier activity is seen for the duration of a particular slot, then the random backoff process shall decrement its count by aSlot_time.
If there is carrier activity sensed at any time during a slot, then the backoff procedure is suspended, that is, the backoff timer shall not be decrement for that slot; The medium must be sensed as idle for the duration of a DIFS or EIFS (as appropriate) period before the backoff procedure is allowed to resume. Transmission shall commence whenever the Backoff Timer reaches zero.

Figure 4, Backoff Procedure
A station that has just transmitted an MSDU and has another MSDU ready to transmit (queued), shall perform the backoff procedure.  This requirement is intended to produce a level of fairness of access amongst STA to the medium.  
The effect of this procedure is that when multiple stations are deferring and go into random backoff, then the station selecting the lowest delay through the random function will win the contention.  The advantage of this approach is that stations that lost contention will defer again until after the next medium busy event, and will then likely have a shorter backoff delay than new stations entering the backoff procedure for the first time.  This method tends toward fair access on a first come, first served basis.

9.2.10	DCF Timing Relations
The relationships between the IFS specifications are defined as time gaps on the medium. The associated MIB variables are provided per PHY.

Figure 5, DCF Timing Relationships
All timings are referenced from the end of the transmission are referenced from the last symbol of a frame on the medium. The beginning of transmission refers to the first symbol of the next frame on the medium.
The aSIFS_Time, and aSlot_time are defined in the MIB, and are fixed per PHY.
aSIFS_Time is: aRx_RF_Delay + aRx_PLCP_Delay + aMAC_Prc_Delay + aRxTx_Turnarounf_Time.
ASLoT_time is: aCCA_Asmnt_Time + aRxTx_Turnaround_Time + aAir_Propagation_Time
The PIFS and DIFS are derived by the following equations, as illustrated in Figure 5.
PIFS = aSIFS_Time + aSlot_time
DIFS = aSIFS_Time + 2 * ASLoT_time
aAir_Propagation_Time is fixed at 1 usec.
The EIFS is derived from the SIFS and the DIFS and the length of time it takes to transmit an Acknowledge control frame at 1 Mbps by the following equation:
EIFS = aSIFS_Time + aACK_Time + aDIFS_Time
Figure 5 illustrates the relation between the SIFS, PIFS and DIFS as they are measured on the medium and the different MAC Slot Boundaries Tx_SIFS, Tx_PIFS and Tx_DIFS. These Slot Boundaries define when the transmitter can be turned on by the MAC to meet the different IFS timings on the medium, after subsequent detection of the CCA result of the previous slot time.
The following equations define the MAC Slot Boundaries, using parameters defined in the MIB, which are such that they compensate for implementation timing variations. The reference of these slot boundaries is again the end of the last symbol of the previous frame on the medium.
Tx_SIFS = SIFS - aRxTx_Turnaround_Time
Tx_PIFS = Tx_SIFS + ASLoT_time
Tx_DIFS = Tx_SIFS + 2 *aSlot_time.
The tolerances are specified in the PHY MIB, and will only apply to the SIFS specification, so that tolerances will not accumulate.
12.3.5.11 PHY_RXSTART.indicate
12.3.5.11.1 Function
This primitive shall be an indication by the PHY sublayer to the local MAC entity that the PLCP has received a valid start frame delimiter and PLCP header.
12.3.5.11.2 Semantics of the Service Primitive
The primitive shall provide the following parameters:
	PHY_RXSTART.indicate (RXVECTOR)
	The RXVECTOR represents a list of parameters that the PHY sublayer shall provide the local MAC entity upon receipt of a valid PLCP header.  This vector may contains both MAC and MAC Management parameters.  The required parameters are listed in clause Error! Reference source not found..
12.3.5.11.3 When Generated
This primitive shall be generated by the local PHY entity to the MAC sublayer whenever the PHY has successfully validated the PLCP header error check CRC at the start of a new PLCP_PDU. Note that this includes the case where the PLCP header indicates a data rate that the station does not support.
12.3.5.11.4 Effect of Receipt
The effect of receipt of this primitive by the MAC is unspecified.
12.3.5.12 PHY_RXEND.indicate
12.3.5.12.1 Function
This primitive shall be an indication by the PHY sublayer to the local MAC entity that the MPDU currently being received is completed. It shall also be used to indicate that the MPDU currently being received has terminated due to an error, such as loss of carrier or unsupported data rate.
12.3.5.12.2 Semantics of the Service Primitive
The primitive shall provide the following parameters:
	PHY_RXEND.indicate (RXERROR)
	The RXERROR parameter can be one or more of the following values: No_Error, Format_Violation, Unsupported_Data_Rate, or Carrier_Lost.  A number of error conditions may occur after the PLCP's receive state machine has detected what it thought may be a valid preamble and start frame delimiter.  This service primitive shall be generated immediately upon detection of an error condition by the PHY. The following describes the parameter returned for each of those error conditions.
No_Error.  This value shall be used to indicate that no error  occurred during the receive process in the PLCP.
Format_Violation.  This value shall be used to indicate that the format of the received PLCP_PDU was in error.
Unsupported_Data_Rate.  This value shall be used to indicate that the PLCP header was correctly decoded but indicated a data rate for the PLCP_PDU at which the station is unable to receive.
Carrier_Lost.  This value shall be used to indicate that during the reception of the incoming MPDU, carrier was lost and no further processing of the MPDU can be accomplished.
12.3.5.12.3 When Generated
This primitive shall be generated by the PHY sublayer for the local MAC entity to indicate that the receive state machine has completed the reception of the MPDU, or to indicate that reception could not take place due to an unsupported data rate.
12.3.5.12.4 Effect of Receipt
The effect of receipt of this primitive by the MAC is unspecified.
14.3.3.3.1 Receive State Machine
The PLCP receive procedure shown in Error! Reference source not found. includes functions that must be performed while receiving the PLCP_PDU data.  The PLCP receive procedure begins upon detection of a valid start frame delimiter and PLCP header in the CS/CCA procedure.  The PLCP shall set a PLCP_PDU byte/bit counter to indicate the last bit of the packet, receive the PLCP_PDU data bits and perform the data whitening decoding procedure shown in Error! Reference source not found. on each PLCP_PDU bit.  The PLCP shall pass correctly received data octets to the MAC with a series of PHY_DATA.indicate(DATA).  After the last PLCP_PDU bit is received and the last octet is passed up to the MAC, the PLCP shall send a PHY_RXEND.indicate(RXERROR= no_error) to the MAC layer.  Upon error-free completion of a packet reception, the PLCP shall exit the receive procedure and return to the PLCP CS/CCA procedure with TIME_REMAINING=0.
If any error was detected during the reception of the packet, the PLCP shall immediately complete the receive procedure with a PHY_RXEND.indicate(RXERROR=error type) to the MAC, and return to the CS/CCA procedure with TIME_REMAINING set to indicate the predicted end of the frame given thebyte/bit count remaining. In the event that the PLCP header indicates an unsupported data rate, the PLCP shall immediately coplete the receive procedure (RXERROR=Unsupported_Data_Rate), and return to the CS/CCA procedure with TIME_REMAINING set to 0. Stations that do not use received power level to detect the end of the frame shall use a TIME_REMAINING value calculated as though the frame were being sent at 1.0 Mbps.
15.2.7	PLCP Receive Procedure
The PLCP receive procedure is shown in Error! Reference source not found..
In order to receive data, PHY_TXSTART.request shall be disabled so that the PHY entity is in the receive state.  Further, through Station Management via the PLME, the PHY is set to the appropriate CHNL_ID and the CCA method is chosen.  Other receive parameters such as RSSI, SQ (signal quality), and indicated RATE may be accessed via the PHY-SAP.
Upon receiving the transmitted energy, according to the selected CCA mode, the PMD_ED shall be enabled (according to clause 12.4.8.4) as the RSSI strength reaches the ED_THRESHOLD and/or PMD_CS shall be enabled after code lock is established.   These conditions are used to indicate activity to the MAC via PHY_CCA.indicate according to clause 12.4.8.4.  PHY_CCA.indicate(BUSY) shall be issued for energy detection or code lock prior to correct reception of the PLCP frame.  The PMD primitives PMD_SQ and PMD_RSSI are issued to update the RSSI and SQ parameters reported to the MAC. 
After PHY_CCA.indicate is issued, the PHY entity shall begin searching for the SFD field.  Once the SFD field is detected, CCITT CRC-16 processing shall be initiated and the PLCP 802.11 SIGNAL, 802.11 SERVICE, and LENGTH fields are received.  The CCITT CRC-16 FCS shall be processed.  If the CCITT CRC-16 FCS check fails, the PHY receiver shall return to the RX Idle state as depicted in Error! Reference source not found..  Should the status of CCA return to the IDLE state during reception prior to completion of the full PLCP processing, the PHY receiver shall return to the RX Idle state.
If the PLCP header reception is successful, a PHY_RXSTART.indicate(RXVECTOR) shall be issued. The RXVECTOR associated with this primitive includes the SIGNAL field, the SERVICE field, the LENGTH field, the antenna used for receive,  PHY_RSSI, and PHY_SQ. If the PLCP header indicates that the frame is being sent at a data rate the station does not support, a PHY_RXEND.indicate primitive shall immediately be generated with an error of Unsupported_Data_Rate. If the station does not support energy detection as a means for detecting the end of the current frame, the PHY entity shall issue a PHY_CCA.indicate(IDLE) primitive no sooner than the 8.0 microseconds times the number of octets indicated in the PLCP header (that is, it shall assume the frame is being transmitted at 1.0 Mbps).
The received MPDU bits are assembled into octets and presented to the MAC using  a series of PHY_DATA.indicate(DATA) primitive exchanges.  The rate change indicated in the 802.11 SIGNAL field shall be initiated with the first symbol of the MPDU as described in clause 12.2.5. The PHY proceeds with MPDU reception.  After the reception of the final bit of the last MPDU octet indicated by the PLCP preamble LENGTH field, the receiver shall be returned to the RX Idle state as shown in Error! Reference source not found..   A PHY_RXEND.indicate(No_Error) primitive shall be issued.   A PHY_CCA.indicate(IDLE) primitive shall be issued following a change in PHY_CS and/or PHY_ED according to the selected CCA method.
In the event that a change in PHY_CS or PHY_ED would cause the status of CCA to return to the IDLE state before the complete reception of the MPDU as indicated by the PLCP LENGTH field, the error condition PHY_RXEND.indicate(carrier_lost) shall be reported to the MAC.  The DSSS PHY shall ensure that the CCA shall indicate a busy medium for the intended duration of the transmitted packet.
A typical state machine implementation of the PLCP receive procedure is provided in Error! Reference source not found.. 
16.2.5.2	PLCP Receive Procedure
The steps below are the receive procedure:
a)	CCA is provided to the MAC via the PHY_CCA.indicate.  When PHY senses activity on the medium it indicates that the medium is busy with a PHY_CCA.indicate with a state value of BUSY.  This will normally occur during the SYNC field of the PLCP preamble.  
b)	The PHY entity will then begin searching for the SFD field.  Once the SFD field is detected the PHY entity will receive the PLCP header.  After receiving the DR and DCLA fields the CRC processing is initiated and LENGTH field is received.  The change indicated in the DR field is initiated with the first symbol of the LENGTH field.  The CRC-CCITT will be processed.  
c)	If the CRC-CCITT check fails  then NO  PHY_RXSTART.indicate will be issued.  When the medium is again free, the PHY will issue PHY_CCA.indicate with a state value of IDLE. If the PLCP indicates an unsupported data rate, the PHY_RXSTART.indicate pimitive shall immediately be followed by a PHY_RXEND.indicate primitive with an error value of Unsupported_Data_Rate. The PHY shall ensure that it does not issue a PHY_CCA.indicate(IDLE) primitive until the medium is sensed to be free.
d)	If the PLCP preamble and PLCP header reception is successful, the PHY sends a PHY_RXSTART.indicate, including the parameters RATE and LENGTH. 
	A PHY must guarantee that the length reported to its MAC in the RXVECTOR of PHY_RXSTART.indicate is equal to the length sent from the peer MAC to the peer PHY entity in the TXVECTOR of PHY_TXSTART.request.
e)	The received PSDU L-PPM symbols are assembled into octets and presented to the MAC using a series of PHY_DATA.indicate primitives.  The PHY proceeds with PSDU reception. 
f)	Reception is terminated after the reception of the final symbol of the last PSDU octet indicated by the PLCP header LENGTH field.  After the PHY_DATA.indicate for that octet is issued, the PHY will issue PHY_RXEND.indicate.
g)	After the PHY_RXEND.indicate, when the medium is no longer busy, the PHY will issue PHY_CCA.indicate with a state value of IDLE.