Improving reliability of delivery of multicast frames in an Infrastructure BSS
IEEE P802.11
Wireless Local Area Networks

Matthew Fischer - AMD
January 10, 1996
San Diego, CA

motion
•	to use PIFS before all multicast including beacons with a restriction against new TX at TBTT by non-AP, w or w/o more bit by adopting the text changes presented within this presentation 
»	(for MORE bit, see section 8.2.1.4 - already in the d2.1 doc)
MORE BIT in frame format sec.
•	section 4.1.3.1.8., use of more bit in multicast frames
»	Add another paragraph:
•	The More Data field shall be set to “1” in broadcast/multicast frames transmitted by the AP, when additional broadcast/multicast frames remain to be transmitted by the AP during this beacon interval. The More Data field shall be set to “0” in broadcast/multicast frames when no more broadcast/multicast frames remain to be transmitted by the AP during this beacon interval.
More bit use in multicast
•	section 8.2.1.4., use of more bit, multicast frames
•	already has reference, subsection e)
•	reference is to old name, update ref.
»	old text:
•	The power management bits shall be set to indicate the presence of further buffered broadcast/multicast MSDUs.
»	new text:
•	The More Data field shall be set to indicate the presence of further buffered broadcast/multicast MSDUs.
•	(all of section 8 has this name reference problem)
PIFS
•	section 6.2.3.2. modify first sentence of first paragraph and add one new sentence, cite new additional use of PIFS
»	new text to replace first sentence of first paragraph, section 6.2.3.2.:
•	The PCF Inter Frame Space shall be used by the PCF to gain priority access to the medium at the start of the Contention Free Period (CFP). PIFS is also used by an AP for the IFS that preceeds all multicast transmissions which have the To_DS bit clear (including beacons, broadcast and multicast frames).
no Backoff req’d before m-cast
•	section 6.2.4., no B-off before multicast
»	existing first paragraph, leave unchanged:
•	A STA desiring to initiate 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, and then generate a random backoff period for an additional defferral time before transmitting. This process minimizes collisions during contentno between multiple STA that have been deferring to the same event.
»	new paragraph for insertion after 1st paragraph:
•	An exception to this procedure shall be followed for the case of transmission of multicast frames by an AP. In this case, the AP shall utilize both the physical and virtual carrier sense functions to determine the state of the medium. If the medium is busy, the AP shall defer until after a PIFS is detected, and then, without generating a random backoff period, shall immediately commence transmission of the multicast frame. This techinique shall be applied to the transmission of all multicast frames, including the Beacon frame.
Backoff
•	section 6.2.5.2., eliminate backoff before multicast
»	first paragraph, add phrase to the end of the paragraph to yield the following updated text:
•	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 41), except when the next MSDU to be transmitted is a multicast frame frame with the To_DS bit clear, and the transmitting station is an AP.
»	2nd from last paragraph in 6.2.5.2., change paragraph to read as follows:
•	A station that has just transmitted an MSDU and has another MSDU ready to transmit (queued), shall perform the backoff procedure, except when the next MSDU to be transmitted is a multicast frame frame with the To_DS bit clear, and the transmitting station is an AP. This requirement is intended to produce a level of fairness of access amongst STA to the medium.
blanket rule on backoff after TX
•	section 6.2.5.5., another textual instance of backoff that needs an exception for multicast
»	at very end of section we find the following text:
•	When an MSDU has been successfully delivered, and the station has a subsequent MSDU to transmit, then it shall go through a backoff.
»	replace the above paragraph with the following paragraph:
•	When an MSDU has been successfully delivered, and the station has a subsequent MSDU to transmit, then it shall go through a backoff, except when the next MSDU to be transmitted is a multicast frame frame with the To_DS bit clear, and the transmitting station is an AP.
multicast burst
•	section 6.2.7. first paragraph needs to be split into two paragraphs
»	delete existing 1st paragraph:
•	In the absence of a PCF, when Broadcast or Multicast MPDUs are transferred from an STA with the To_DS bit clear, only the basic access mechanism shall be used. Regardless of the length of the frame, no RTS/CTS excange shall be used. In addition, no ACK shall be transmitted by any of the recipients of the frame.
»	1st paragraph, case of ad-hoc multicast, uses basic mechanism:
•	When Broadcast or Multicast MPDUs are transferred from a STA that is not the AP and that is not associated with an infrastructure BSS, (the To_DS bit shall be clear), only the basic access mechanism shall be used. Regardless of the length of the frame, no RTS/CTS exchange shall be used. In addition, no ACK shall be transmitted by any of the recipients of the frame.
multicast burst
»	2nd new paragraph, case of AP, uses multicast burst:
•	When Broadcast or Multicast MPDUs are transferred from a STA that is an AP for an infrastructure BSS and there is no PCF, (the To_DS bit shall be clear), then the AP shall transmit multicast frames by using the basic access mechanism with the exception that PIFS shall be used instead of DIFS, and backoff before transmission shall not be performed. If any of the associated STA are in PS mode, then all multicast frames shall be buffered and shall then be transmitted immediately following the next DTIM transmission. The first multicast frame transmitted after the next DTIM shall be transmitted after waiting for PIFS medium free time following the completion of the DTIM transmission. Each subsequent multicast frame (if more are buffered) shall follow the previous multicast frame transmission after waiting for PIFS medium free time, without performing any backoff. If the medium is sensed busy at any time, then wait for PIFS is restarted when the medium returns to the idle state, and after PIFS, the next multicast frame in the queue shall be transmitted.
more from 6.2.7.
•	last paragraph of this section talks about unreliability
»	replace last paragraph of section with the following new text:
•	There is no MAC level recovery on Broadcast or Multicast fames except for those frames sent with the To_DS bit set. However, due to the use of the PIFS for multicast frame transmissions that have the To_DS bit clear, these transmissions will effectively be granted a priority and will enjoy a reasonable proabability of delivery.
TBTT & Carrier Sense
•	section 6.2.1, carrier sense mechanism needs to include TBTT as causing Carrier Sense to be asserted for SLOT TIME sec
»	after 3rd paragraph, add new paragraph
•	A second virtual carrier sense mechanism called TBTT_BUSY shall be provided by a MAC while operating in an infrastructure BSS, in order to allow multicast traffic (including beacons) to be delivered to stations within a BSS that includes an AP. This mechanism forces a medium busy condition in all STA within an infrastructure BSS and all APs for one SLOT TIME beginning at each TBTT.
TBTT & Carrier Sense
•	section 6.2.1. modify first sentence of last paragraph, new text:
•	The NAV state is combined with the TBTT_BUSY indication and the physical carrier sense to indicate the busy/free state of the medium.
•	what about interference from an adjacent BSS on the same channel?
»	adjacent BSS will not know of TBTT for my BSS, so while adjacent BSS on same channel may through DCF allow some protection for non-multicast frames, first multicast frame in burst might be squashed until PIFS kicks in
Beacon generation
•	section 8.1.2.1., beacon to use PIFS
»	replace first paragraph with the following text:
•	The Access Point shall define the timing for the entire BSS by transmiting Beacons according to the aBeacon_Period parameter within the AP. This defines a series of Target Beacon Transmission Times (TBTTs) exactly aBeacon_Period time units apart, time zero is defined to be a TBTT. At each TBTT, the AP shall schedule a Beacon as the next frame for transmission. If the medium is sensed to be unavailable, the AP shall delay the actual transmission of a Beacon until immediately following the next PIFS medium idle time such as is described for multicast frames in section 6. No backoff shall be performed preceeding this transmission. (Note that the beacon frame is a multicast frame.) The beacon period is included in beacon and probe Response frame, and stations shall adopt that beacon period when joining the BSS.
global change to 8.2.1.4.-7.
•	Change references to Power Management bits to Power Management Bit, or More Data bit, as appropriate in order to conform to new bit names in section 4
AP’s role
•	AP will sense medium beginning at TBTT
•	AP watches for PIFS medium idle time before commencing all multicast (incl. Beacon) transmission
»	AP also implements TBTT_BUSY virtual carrier sense mechanism
•	need to note that after DTIM, first traffic out is multicast