1 / 16

Group Polling for DCF Based Reservation Request

Group Polling for DCF Based Reservation Request. Jin-Meng Ho Texas Instruments Incorporated 12500 TI Blvd. Dallas, Texas 75243 (214) 480-1994 jinmengho@ti.com Michael Fischer Intersil Corporation 4242-3 Medical Drive San Antonio, Texas 78229 (214) 614-4096 x107 mfischer@choicemicro.com.

lael
Download Presentation

Group Polling for DCF Based Reservation Request

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Group Polling for DCF Based Reservation Request Jin-Meng Ho Texas Instruments Incorporated 12500 TI Blvd. Dallas, Texas 75243 (214) 480-1994 jinmengho@ti.com Michael Fischer Intersil Corporation4242-3 Medical DriveSan Antonio, Texas 78229 (214) 614-4096 x107mfischer@choicemicro.com

  2. Prelude • An improvement of the CC/RR mechanism • Slotted Aloha  CSMA/CA • A compromise of the CC/RR mechanism with (E)DCF • New access method  DCF access method • A replacement of the controlled contention mechanism • Controlled contention  Group polling + CSMA/CA contention • Whichever view you take depends upon your vantage point.

  3. Introduction • Grouped Request Polling vs. Directed Data Polling • Directed data polling: suitable for periodic/synchronous sources • Stations having traffic to send are known deterministically and are polled individually for their data transmissions. • Grouped request polling: effective for bursty/asynchronous sources • Stations having traffic to send are known statistically and are polled as a group for their reservation request transmissions. • Polled TXOP Request vs. EDCF TXOP Request • EDCF TXOP request: contending with data traffic (even at highest priority) • Collision and access delay increase, and hence channel throughput decreases, rapidly with increasing traffic load. • Polled TXOP request: contending among requesters (sending small frames) • The number of transmitting requesters, and hence the number of successful requesters, may be held constant even as the number of requesters increases. • The channel throughput, in conjunction with directed polling, remains at maximum even under high load.

  4. Background--ATIM Operation Alternating backoff counters for ATIM and “data” transmissions

  5. Change • Low level access: Slotted Aloha  Slotted CSMA/CA • High level report: Single TC/TS  Multiple TC/TS CCI • HC sends a CC specifying a CCI length in units of CCOPs • A requester sends an RR into a randomly chosen CCOP CC CC: Contention Control RR: Reservation Request CCI: Controlled Contention Interval CCOP: Controlled Contention Opportunity CCOP RR/RR RR PIFS SIFS • HC sends an RP specifying an RPI length in units of time and a CWrr in units of slots • A requester sends an RR upon expiration of a backoff timer set randomly between [0, CWrr] RPI RP RP: Request Polling RR: Reservation Request RPI: Request Polling Interval CWrr: Contention Window for RR RR/RR RR RR PIFS SIFS Slot CWrr is set to 2n-1 for easy implementation and because of the freedom in choosing RPI

  6. ATIM versus RPI • Complexity • Residual backoff state carryover between ATIM windows: Yes. • Residual backoff state carryover between RPIs: No. • Recognition • Knowledge of the existence of the ATIM window must be hard coded into each STA's IBSS support. • (Q)STAs honor the RPI due to their existing NAV implementation and the duration value in the RP frame. • Effectiveness • Lack of an ACK to a directed ATIM precludes transmission of the corresponding frame in the CP after the ATIM window. • Lack of feedback to an RR does not preclude the WSTA from sending the corresponding frame(s) into polled or contention TXOPs after the RPI. • In fact, this lack of feedback TELLS the WSTA that it should NOT expect a polled TXOP for the subject transfer, so it may issue another RR in a subsequent RPI AND/OR attempt transmission in a contention-based TXOP.

  7. Request Polling (RP) Frame Format • The Duration/ID field contains the time in microseconds for the request polling interval (RPI). • If the RP frame is used solely for feedback on the reception status of previous RR transmissions, both the RPI and Duration/ID fields are set to 0. • The RA field is the broadcast group address. • The BSSID field is set as defined in 7.1.3.3.3. • The Request Control field comprises a CW Exponent subfield in bits 0-3, a Preamble subfield in bits 4-6, and a reserved subfield in bit 7. • The CW Exponent subfield specifies a value of N such that CWrr = 2^N –1 defines the contention window in aSlotTimes for the backoff procedure used by WSTAs in sending RR frames in the ensuing RPI. • The Preamble subfield specifies what preamble must be used for RR frames sent in the ensuing RPI, as defined in Table X. Octets: 2 2 6 6 1 1 0, 2, 4, … 4 Frame Control Duration/ID RA BSSID Request Control RPI Length Feedback AIDs FCS

  8. Request Polling (RP) Frame Format (Cont) Table X -- Preamble subfield encoding

  9. Request Polling (RP) Frame Format (Cont) • The RPI Length field specifies the length of the RPI, in units of 16 microseconds, that follows the end of this RP frame. • Qualified WSTAs each attempt to send an RR frame within this RPI using the backoff precedure defined in 9.10.4.2. • The RPI Length may be set to 0 for the RP frame to acknowledge previously received RR frames without allocating a new RPI. • The Feedback AIDs field contains the AIDs of the WSTAs that have successfully sent an RR frame to the HC since the last RP frame, with each AID occupying 2 octets. • This field is null if no such WSTAs are to be acknowledged. Octets: 2 2 6 6 1 1 0, 2, 4, … 4 Frame Control Duration/ID RA BSSID Request Control RPI Length Feedback AIDs FCS Figure 21.5 – RP frame

  10. Reservation Request (RR) Frame Format • The Duration/ID field carries, in bits 0-13, the AID of the WSTA transmitting this RR frame, with bit 14 set to 0 and bit 15 set to 1. • The RR frame uses the Duration/ID field to convey an AID as in PS-Poll frames (but with an unambiguous encoding of bits 14 & 15) for the same efficiency reason as for PS-Poll, that of minimizing transmission time. • The RR is NAV-protected by the duration value in the RP frame covering the whole RPI. The Duration/ID field, with bit 15 set to 1, has a value greater than 32768 and is thus not used to update the NAV at other (Q)STAs. Octets: 2 2 6 2 6 4 Frame Control Duration/ID BSSID TID Bitmap Requested TXOPs FCS For comparison only

  11. Reservation Request (RR) Frame Format (Cont) • The BSSID field is set as defined in 7.1.3.3.3. • The TID Bitmap field comprises 16 bits each defining a TXOP request indication of a TC or TS sourced at the WSTA sending this RR frame, with bit N (0N15) corresponding to a TC or TS with a TID of N. • A bit in the bitmap is set to 1 if a requested TXOP is indicated in the next field for the corresponding TC or TS, and to 0 otherwise. • The Requested TXOPs field contains the TXOP durations, each in units of 16 microseconds, requested for the TCs and/or TSs whose corresponding bits in the previous field are set to 1, and arranged in the same order as those TCs and/or TSs are represented in the TID Bitmap. • Each requested TXOP duration occupies 1 octet. • An RR frame may request TXOPs for up to 6 TIDs. Octets: 2 2 6 2 6 4 Frame Control Duration/ID BSSID TID Bitmap Requested TXOPs FCS Figure 21.6 – RR frame

  12. Request Polling and Reservation Request 9.10.4 HCF Request Polling The HCF request polling mechanism enables WSTAs of bursty sources to request new contention-free TXOPs without having to contend with (E)DCF traffic. These requests are for one-time TXOPs to transfer new traffic bursts generated from asynchronous sources, as defined by TSs of aperiodic TS type and TCs of bursty nature. Every HC shall be capable of conducting request polling, while every WSTA shall be capable of responding to request polling and maintain a backoff counter (referred to as the RR backoff counter) for sending the response in the form of an RR frame, as defined in this subclause. 9.10.4.1 RP transmission The HC may initiate an instance of request polling in the CFP or CAP, by transmitting an RP frame, to grant WSTAs contention-based TXOPs for RR transmissions. In the RP frame, the HC shall specify the length of the RPI to bound the time used for RR transmissions by WSTAs following the RP frame. The HC shall also specify the contention window CWrr to randomize and optimize the access by WSTAs in their RR transmissions. The HC shall further specify the type of the PLCP preamble to be used by WSTAs in sending their RR frames. In each instance of request polling, the HC shall ensure that the RP frame and the ensuing RPI fit within a single CFP or CAP, as well as a single instance of medium occupancy pursuant to dot11MaxDwellTime and/or dot11MediumOccupancyLimit. The HC shall, without preempting MSDU transfers from TSs with finite delay bounds, initiate at least one instance of request polling during the first CAP of each DTIM interval. That is, an HC allocates an RPI if and only if WM bandwidth is still available after delay sensitive traffic has been serviced. The RPI length shall be at least equal to RT*max(2.5, 0.2 * N_WSTA), where RT is the time required to transmit an RR frame at the highest rate of the BSS Basic Rate Set and with the use of the PLCP preamble as determined by the HC, while N_WSTA is the number of WSTAs currently associated with the QAP/HC. The HC may initiate another instance of request polling any time after a SIFS interval of the end of the current instance, subject to the restrictions imposed on the CFP or CAP limits. Figure 62.2 shows an instance of request polling, including the RP frame and the RR responses. NAV RPI RP RR/RR RR RR PIFS SIFS Slot Figure 62.2 – An instance of request polling

  13. Request Polling and Reservation Request 9.10.4.2 RR response WSTAs having new data that belong to TSs of aperiodic/asynchronous TS type may send an RR frame in the RPI following a received RP frame to request a new contention-free TXOP, using the backoff procedure as defined below. Upon receipt of an RP frame from the QAP/HC with which they are associated, such WSTAs shall set the RR backoff counter to BackoffTime = Random × aSlotTime, where aSlotTime is the value of the correspondingly named PHY characteristic, and Random is a pseudorandom integer drawn from a uniform distribution over the interval [0, CWrr], with CWrr = 2^N – 1 and N being the CW Exponent specified in the RP frame. It is important that designers recognize the need for statistical independence of the pseudorandom number streams among WSTAs. (a) All the WSTAs wait for a PIFS interval after the end of the received RP frame. (b) The WSTAs having an RR backoff counter of zero value shall send an RR frame if such an RR frame will be fully transmitted by the end of the current RPI or shall send none otherwise. In either case, these WSTAs shall not have further attempt to transmit in the remaining RPI. (c) The WSTAs having an RR backoff counter of nonzero value shall invoke the carrier-sense mechanism to determine the busy/idle state of the medium for the following backoff slot if the remaining RPI is long enough for transmitting an RR frame, or otherwise shall not have further attempt to transmit in the remaining RPI and shall not save the residual backoff counter values . (d) Those of the WSTAs in (c) that find no medium activity in that backoff slot shall decrement their RR backoff counters by aSlotTime and proceed from (b). (e) Those of the WSTAs in (c) that find medium activity in that backoff slot shall freeze their RR backoff counters. (f) Those of the WSTAs in (e) that find the medium is idle again and for a SIFS duration shall immediately decrement their RR backoff counters by aSlotTime and proceed from (b). The WSTAs shall use the PLCP preamble as specified in the RP frame in the transmission of their RR frames. The WSTAs that are incapable of using the specified PLCP preamble for their RR transmission shall not send any RR frames in the current RPI and hence need not go through the backoff procedure as defined above. The WSTAs may use any of the data rates and modulation schemes that are supported by the HC in sending their RR frames. The WSTAs each may request TXOPs in a single RR frame for up to six outgoing TCs and/or TSs. The WSTA each shall transmit at most one RR frame within an RPI, without regard to the successful/failed reception status of the RR frame. The WSTAs shall not transmit an RR frame beyond the end of the RPI. The WSTAs shall not save the value of their RR backoff counters at the end of the RPI. WSTAs having not successfully requested needed new aperiodic TXOPs shall reset their RR backoff counters in the next RPI based on the CWrr specified in the next RP frame. WSTAs shall not set their backoff counters nor transmit RR frames following receipt of an RP frame specifying a zero length RPI as sent exclusively to acknowledge WSTAs that transmitted an RR frame in the preceding RPI.

  14. Request Polling and Reservation Request 9.10.4.3 RR acknowledgment and retransmission The HC shall explicitly acknowledge successful receipt of RR frames in the Feedback field of the next RP frame within the current CFP or CAP, but not necessarily following the end of the previous RPI. The first RP frame sent in any given CFP or CAP, used solely for initiating an instance of request polling, does not have a Feedback field but does have a non-zero RPI length. The last RP frame sent in the CFP or CAP, used solely for acknowledging the RR frames sent in the previous RPI, has a zero RPI length and may or may not have a Feedback field, depending on whether any of those RR frames was received correctly by the HC. Other RP frames, if any, may have a Feedback field providing acknowledgment to the previously sent RR frames and a non-zero RPI length initiating another instance of request polling. If the previous RP frame specified a zero RPI length, the next RP frame does not have a Feedback field. If the previous RP frame specified a non-zero RPI length, the next RP frame has a Feedback field only if at least one RR frame sent in that RPI was received correctly by the HC. A WSTA may retransmit an RR frame in the next RPI following the same procedure as defined in 9.10.4.2 for RR response, subject to the following conditions: The WSTA does not find its AID in the Feedback field of the next RP frame, nor has successfully sent since its last RR transmission any QoS Data (+ CF-Ack) or QoS Null frames containing the TIDs of all the TCs and TSs indicated in that RR frame. A WSTA may send a new RR frame containing a TID that was not contained in the last RR frame the WSTA sent, regardless of the reception and acknowledgment status of that last RR frame. This allows the WSTA to request new TXOPs for some TCs and TSs for which no TXOPs were requested earlier.

  15. Summary • This proposal defines a mechanism of group polling for CSMA/CA based reservation request, combining the best of • Directed polling • CSMA/CA contention • Group acknowledgment • ATIM transmission • IBSS beacon generation • No new access method is introduced!

  16. Motion • To replace the CC-RR controlled contention mechanism as described in the current IEEE 802.11e draft standard with the RP-RR request polling mechanism as described in slides 7-14 of this document for the IEEE 802.11e draft standard.

More Related