1 / 34

Hybrid Coordination Function (HCF) Frame Exchange and NAV Details

Hybrid Coordination Function (HCF) Frame Exchange and NAV Details. First version: 2001-02-07 Revision 1: 2001-02-26 Revision 2: 2001-03-12 (including material from 00/452r2). Michael Fischer

ishi
Download Presentation

Hybrid Coordination Function (HCF) Frame Exchange and NAV Details

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. Hybrid Coordination Function (HCF) Frame Exchange and NAV Details First version: 2001-02-07Revision 1: 2001-02-26 Revision 2: 2001-03-12 (including material from 00/452r2) Michael Fischer Intersil Corporation4242-3 Medical DriveSan Antonio, TX 78229voice: +1-210-614-4096fax: +1-210-614-8192mfischer@choicemicro.com Michael Fischer, Intersil

  2. Brief Intro to HCF for New Participants If you want the TGe QoS draft to go to sponsor ballot with • 3 nested QoS conformance levels (in addition to legacy 802.11-1999) • Level 1: only prioritized QoS under {E}DCF, • Level 2: only prioritized QoS under {E}DCF and EPCF, • Level 3: prioritized QoS under {E}DCF and parameterized QoS under EPCF; • 2 new, and extremely different, sets of frame exchange rules, • With multiple mechanisms for accomplishing the same result, and • A large number of subsets, each of which will need interoperability testing. . . . Then DON'T vote for HCF, Because HCF offers • A SINGLE QoS conformance level, and • A SINGLE set of frame exchange rules, usable in both CP and CFP. . . . But HCF needs to be adopted before we go to ballot • Because HCF involves coordinated changes in far too many places to be practical to achieve within the ballot comment resolution process. Michael Fischer, Intersil

  3. Introduction • The Hybrid Coordination Function (HCF) combines the enhanced DCF with generalized PCF features to simplify the QoS conformance model: • ESTAs use a common set of frame exchange rules in both CP and CFP. • The HCF provides numerous operational benefits while reducing implementation complexity by simplifying the header encodings and frame exchange rules. • The mandatory ESTA functionality is identical for all QoS levels in D0.1, so the QoS conformance model collapses to a single level. • With HCF plus appropriate definition of QoS signaling the normative distinction between prioritized and parameterized QoS goes away. • The HCF provides operational benefits in many areas while simplifying the MAC over what is required by continuing the approach in D0.1. • The HCF is more robust than the EPCF in the presence of interference from overlapping BSSes, while also being friendler to legacy STAs. Michael Fischer, Intersil

  4. Why Define an HCF? There are significant concerns about several aspects of QoS in D0.1: • The conformance model with 3 nested QoS levels is too complex and will result in confused customers and frustrated users. • Using the EPCF to carry periodic, low-latency traffic can lead to inefficient use of the WM if the service rate is greater than the DTIM rate, • but shortening the DTIM period increases protocol overhead and curtails the ability to doze by stations in power save mode. • Parameterized QoS is only available during the CFP under (level 3) EPCF. • which limits functions like reserved periodic service, as well as options such as FEC, to occur exclusively during the CFP. • The proposals to include a CF-burst mechanism in the EDCF will increase complexity, adding yet another set of frame exchange rules; and creating new latency variation, TBTT jitter, and inter-BSS interference scenarios. • The HCF proposal addresses many of these concerns in a manner which is likely to reduce complexity and objections during ballotting. Michael Fischer, Intersil

  5. The HCF is… • A generalization and merging of a pair of protocol feature sets that are presently being considered separately: PCF and CF-Bursts. • A coordination function on top of the {E}DCF to provide contention free and controlled contention transfers during both CP and CFP: • HCF can operate over any of the proposed EDCFs, or over legacy DCF. • An EDCF to provide relative priority differentiation is highly desirable. • HCF can grant TXOPs for parameterized QoS during both CP and CFP. • Thereby avoiding tradeoffs between service rate and DTIM rate. • HCF uses CCA and NAV in a manner which limits the temporal extent of undetected interference both to and from overlapping BSSes. • Frames carry duration values to set the NAV during both CP and CFP. • The use of PIFS, rather than SIFS, between sequential group-addressed CF transmissions allows rapid detection of inter-BSS interference. • Hence HCF is simultaneously more "overlap aware" and more "legacy friendly" than the (E)PCF. Michael Fischer, Intersil

  6. The HCF is NOT… • A new channel access mechanism: • The contention-based access mechanism of the {E}DCF is used. • The contention-free mechanism is available during both CP and CFP. • The (relevant) frame formats and frame exchange rules for contention free transfers are are identical during the CFP and during CF-Bursts. • A replacement for the PCF, • Indeed, the HCF is a type of point coordination function, just not the point coordination function specified for PCF or EPCF. • However, the HCF does eliminate the need to use a "monolithic" CFP to support parameterized QoS, so we can remove EPCF from the draft. • The HCF generates CF-Bursts as needed to to create what are, in effect, a plurality of "mini-CFPs" within the CP, as needed to meet traffic specs. • This allows those applications which require parameterized QoS (e.g. periodic TXOPs) to operate in both CP and CFP, rather than being limited to using the CFP as is the case with the current baseline. Michael Fischer, Intersil

  7. Origins • Contention free bursts are a concept from the early years of 802.11, and were used for "time bounded services" in the WMAC proposal (1993): • 93/070: A Distributed Access Protocol proposal supporting Time Bounded Services, Wim Diepstraten. • Contention free bursts were proposed to TGe in May, 2000: • 00/113: Suggested 802.11 PCF Enhancements and Contention Free Bursts, Maarten Hoeben and Menzo Wentink. • Solicited polling, and adaptation of several CF concepts for use during the CP were introduced in: • 00/367 & 00/367r1: p-DCF for Prioritised MAC Service, Jin-Meng Ho, Sid Schrum and Khaled Turki. • 00/467r2: Contention-Free and Contention-Based Access in Contention Period, Jin-Meng Ho, Sid Schrum, Khaled Turki, Donald P. Shaver and Matthew B. Shoemake. • The potential of using a hybrid approach to reduce complexity and improve robustness of the QoS solution was explained in : • 00/448: An Integrated 802.11 QoS Model with Point-controlled Contention Arbitration, Robert Meier. Michael Fischer, Intersil

  8. Terminology • HC: Hybrid Coordinator • The entity controlling QBSS operation under the HCF. The HC is a type of point coordinator which uses different rules than today's PC and EPC. • TXOP • A bounded-duration time interval during which an ESTA may transmit on the WM. An ESTA obtains a TXOP either by winning an instance of EDCF contention or by receiving a QoS (+)CF-Poll from the HC. • CFB: Contention Free (CF-)Burst • A sequence of SIFS-separated frame exchange sequences during the CP. • Controlled Burst • A CFB in which all frame exchanges are initiated either by the HC or in direct response to a QoS (+)CF-Poll from the HC. Any unqualified use of "CFB" should be assumed to refer to a controlled burst. • Autonomous Burst • A CFB in which a second WSTA transmits (certain frames) pursuant to receipt of a QoS Data frame from a WSTA (rather than the HC). Michael Fischer, Intersil

  9. Summary of Changes to TGe D0.1 • Changes are made to certain frame formats and field contents: • Additional QoS information in Beacon and Probe Response frames • Transfer of the QoS control bits from the 14 LSb of the Duration/ID field to the 12 LSb of the TCID field, with encoding changes to fit in 12 bits • This allows QoS Data frames to be sent during the CP, and QoS Data frames sent during the CFP to carry a duration value for NAV updates • Modified formats for CC and RR frames • Changes are made to QoS frame exchange sequences and timing: • Rules for operation of the HC • Rules for using DIFS, PIFS, and SIFS for QoS frame exchanges • Rules for duration value calculation and NAV update and usage • Rules for using QoS-related frame types during the CP • Rules for using CC and RR frames during the CP • Rules for using QoS Null for a WSTA to request QoS polling by the HC Michael Fischer, Intersil

  10. Items Deleted from TGe D0.1 • The concept of "QoS Level" • There is now just an "optional QoS facility" which is indicated by a single bit in the capability information field. • The EPCF • Which has been replaced by the HCF • Frames of several control subtypes: • CC+CF-Ack • CF-Multipoll+CF-Ack • CF-Schedule Michael Fischer, Intersil

  11. Additional QoS Information in Beacon One fields is added to a QoS information element in Beacon frames: • EDCF TXOP limit (16 bits, units of aSlotTime) • Maximum medium occupancy by an ESTA that wins EDCF contention. • Legacy STAs continue to observe the DCF rule of sending one MPDU or MMPDU per successful contention. • If EDCF TXOP limit=0, or in an IBSS, and EDCF TXOP may last no longer than the time required to transmit one max-length, non-fragmented MPDU at the lowest rate in the BSS operational rate set. Michael Fischer, Intersil

  12. Contents of Duration/ID and TCID Fields • All frame subtypes that are specified in D0.1 to use the Duration/ID field for QoS information (QoS Data, CC, RR, Container) are permitted during the CP, where a duration value is required, so the Duration/ID fields in these frames revert to holding a duration value. • The rules for calculating these durations are given on a subsequent slide. • This duration value is also used for these frames during the CFP or a CFB. • The QoS information from the low-order 14 bits of the Duration/ID field in D0.1 moves to the low-order 12 bits of the TCID field. • This set of information is is referred to as the "QoS Control" field. • The encodings and units used for QoS Control have been simplified from those in the D0.1. • The TCA format specified in 7.1.3.6 (of D0.1) is still used in the feedback field of CC frames and in certain elements, but is no longer used in RR. Michael Fischer, Intersil

  13. Revised CC Frame Format • The changes to the CC frame format are hilighted in red below. • There is no longer a CC-unique TCID format. • The priority limit is replaced by a bitwise priority mask. • The CCOP length is in units of 16 microseconds. • The CCI is protected by NAV, as shown below. • The PIFS before the first CCOP gives the ESTAs time to generate RRs. Michael Fischer, Intersil

  14. Revised RR Frame Format The changes to the RR frame format are hilighted in red below. • The TCA field is replaced by a (new format) TCID in RR frames so that ESTA queue state reporting is identical in RR and QoS Data frames. • Bit 15, designated TS on slide 12, indicates whether the low-order 10 bits contain the size of the transmit queue for the TC designated by bits 14-12, or the duration of the next, non-periodic TXOP needed by this ESTA. • Non-periodic TXOP length is now indicated in microseconds rather than octets. • The request is generated from the transfer time the ESTA already calculates. • To grant these requests, the HC doesn't need to guess the data rate in use. • A 2-octet field containing the AID of the requesting ESTA is added immediately after the TCID field to identify the request source. Michael Fischer, Intersil

  15. A Brief QoS Null FAQ • How does QoS Null differ from QoS Data with a 0-octet frame body? • Each MA-UNITDATA.request generates 1+ (QoS) Data frames. Each (QoS) Data frame reception generates MA-UNITDATA.indication, even for MSDU length =0. • QoS Null and other noData=1 subtypes are used for internal functions which need to exchange MAC header and QoS control information via the WM. Because there is no provision to carry an MSDU, these frames are invisible above the MAC SAP. • If PrivacyInvoked=True, QoS Data frames have IV/ICV fields, even with 0 octets of encrypted payload. QoS Null has no frame body and never includes IV/ICV fields. • Why are there separate separate subtypes for Null and QoS Null? • The two nulls are a direct result of the data subtype encoding, see slide 16. In essence, QoS CF-Poll, QoS CF-Ack, and QoS CF-Poll+CF-Ack are variants of QoS Null which piggyback control functions on "noData" rather than on an MPDU. • Are both Null and QoS Null necessary? --Yes, for the following reason: • Null, in its current form, is required by normative provisions of 802.11-1999. QoS Null is used to send headers which include QoS control and/or TCID information. Creating a special case variant of Null or of QoS Data to serve the alternate purpose would be more difficult to implement, and would offer no functional benefits. Michael Fischer, Intersil

  16. Bit: 0 1 2 3 4 5 6 7 0 0 1 0 QoS noData +CF- Poll +CF- Ack Subtypes of Frame Type "Data" • The subtype field of data type frames (both in 802.11-1999 and D0.1) has bitwise significance to simplify decode of piggybacked functions. • There is no comparable encoding of control and management subtypes. • A detailed breakdown of the low-order byte of the Frame Control field in QoS Data frames is shown below to illustrate this bitwise encoding: Version Type Subtype QoS Data 1 0 0 0 = QoS + Data + (noPoll) + (noAck) QoS Data+CF-Ack 1 0 0 1 = QoS + Data + (noPoll) + CF-Ack QoS Data+CF-Poll 1 0 1 0 = QoS + Data + CF-Poll + (noAck) QoS Data+CF-Poll+CF-Ack 1 0 11 = QoS + Data + CF-Poll + CF-Ack QoS Null (no data) 1 1 0 0 = QoS + noData + (noPoll) + (noAck) QoS CF-Ack 1 1 0 1 = QoS + noData + (noPoll) + CF-Ack QoS CF-Poll 1 11 0 = QoS + noData + CF-Poll + (noAck) QoS CF-Poll+CF-Ack 1 111 = QoS + noData + CF-Poll + CF-Ack Michael Fischer, Intersil

  17. Rules Pertaining to the HC • Like a PC, the HC is permitted to initiate transmissions upon detection of the WM free (both CCA and NAV) for a PIFS interval. • But not during a TXOP which the HC has granted unless it detects either a QoS data frame with NF=0 or a DIFS period with the medium idle. • Once an EDCF mechanism is selected, the appropriate means of dealing with inter-HC collisions can be determined. • The HC is typically collocated with the AP. • The EDCF traffic monitor function should also be collocated with the HC. Michael Fischer, Intersil

  18. IFS Usage for HCF QoS Transfers • SIFS • Used within frame exchange sequences as well as between frame exchange sequences during the CFP and CF bursts. • Not used between contention free transmissions of broadcast or multicast data and management frames. • PIFS • Used for priority channel access by the HC to send beacons and start CFPs. • Used between successive CF transmissions of group addressed frames to allow detection of inter-BSS CFB collisions during BC/MC delivery. • The CFP or CFB ends immediately if CCA(busy) is detected at the PIFS boundary between successive group addressed frames. • DIFS/EIFS • The minimum used for all other inter-frame spaces during the CP. Michael Fischer, Intersil

  19. TXOP Limit from CF-Poll TxOp granted by CF-Poll CF-Poll SIFS D I F S NAV from CF-Poll Duration Value Calculation • The duration transmitted by ESTAs in ACK frames and +CF-Ack frames is the duration value from the frame being acknowledged diminished by the duration of the frame carrying the acknowledgement plus aSIFSTime. • This is equivalent to what is done in 802.11-1999 for CTS (using duration from RTS) and for ACKs to fragments (based on duration from data being ACKed). • Duration of QoS-Null is DIFS • Duration of CC is (CCI length + 2*PIFS) • Duration of RR is zero • Duration in frames in {E}DCF TXOPs is set as specified in 802.11-1999. • Duration of (+)CF-Poll covers the length of the granted TXOP + DIFS • Under HCF the NAV is used to protect individual TXOPs, not the entire CFB. Michael Fischer, Intersil

  20. Acktime time stolen byHC for data TXOP Limit from +CF-Poll CF- Poll QoS Data (NF=1) CF- Ack QoS Data (NF=1) QoS Data +CF-Poll+CF-Ack QoS Data(NF=0) CF- Ack SIFS SIFS SIFS SIFS SIFS SIFS stolen timereplaced TXOP Limit from initial CF-Poll Polled TXOPs • An ESTA's TXOP ends upon occurrence of any of the following: • The end of a frame exchange sequence for a QoS data frame with NF=0 or any management type frame. • The TXOP duration from the most recent QoS (+)CF-Poll has elapsed. • The ESTA allows the WM to remain idle for PIFS. • Typically this is a SIFS non-response where the ESTA fails to resume at PIFS. • The HC is allowed to resume transmitting at DIFS. • The CFB ends when the WM remains idle for DIFS. • The HC uses QoS Data+CF-Poll+CF-Ack when piggybacking an MPDU with the Ack to QoS Data (ToDS=1, NF=1). The ESTA's TXOP is extended by this +CF-Poll, replacing the time "stolen" by the HC to send data, as shown below: Michael Fischer, Intersil

  21. Autonomous Burst TXOP in QBSS • An ESTA never has to participate in an autonomous burst. • When an ESTA in a QBSS receives the final or sole QoS Data frame in a TXOP, this ESTA may transmit a single MPDU after SIFS, provided: • The received QoS Data/Null has NF=0, ToDS=FromDS=0, and SA=RA of most recent (+)CF-Poll when poll is more recent than WM idle for DIFS. • Requiring this ESTA to have heard the (+)CF-Poll makes it likely the HC will be able to hear the autonomous burst transmission. • Priority of pending MPDU is not less than priority of the received frame. • Sufficient time is available prior to TBTT, and any relevant medium occupancy boundaries and/or BSS overlap mitigation silence periods. • If DA of pending MPDU = SA of received frame, a QoS Data+CF-Ack may be used, otherwise outgoing MPDU is sent SIFS after reception is acknowledged. NOTE: These rules limit QBSS autonomous bursts to the polled ESTA plus one other ESTA, which covers the most common case: bilateral, intra-QBSS ESTA-ESTA transfers. This limitation is desirable for implementation simplicity, allowing removal of 2 words from the beacon, and creating shorter periods when the HC cannot obtain control of the WM. Michael Fischer, Intersil

  22. Autonomous Burst TXOP in IBSS • An ESTA never has to participate in an autonomous burst. • When an ESTA in an IBSS receives the final or sole QoS Data frame in a TXOP, this ESTA may begin its own TXOP, just as if it had won an (E)DCF contention, after SIFS, provided: • The received QoS Data/Null is a unicast to this ESTA from a sender in the same IBSS with NF=0 and ToDS=FromDS=0. • The priority of MPDU(s) transmitted during this TXOP must not be less than priority of the received frame. • The ESTA's last TXOP was before the last instance of WM free for DIFS. • This ensures that an ESTA has at most one TXOP per autonomous burst. • Sufficient time is available prior to TBTT, and any relevant medium occupancy boundaries and/or BSS overlap mitigation silence periods. • If DA of pending MPDU = SA of received frame, a QoS Data+CF-Ack may be used, otherwise outgoing MPDU is sent SIFS after reception is acknowledged. NOTE: These rules allow IBSS autonomous bursts of length bounded only by the number of ESTAs in the IBSS, although the practical limit is usually much lower. Michael Fischer, Intersil

  23. Additional NAV Rules for ESTAs • If ESTA NAV set at receipt of a QoS frame needing acknowledgement, always send QoS CF-Ack(no data), even if a (+)CF-Poll was received. • On NAV update using the duration value from a (+)CF-Poll with own BSSID, ESTAs should set TXsrc := RA(RxFrame) • Clear TXsrc on NAV update by other than (+)CF-Poll, also when NAV:=0 • Clear NAV & TXsrc on receipt of QoS Data type frame with SA=TXsrc and NF=0 (own BSSID), also Management frame with SA=TXsrc • Send CTS (do not clear NAV) in response to RTS if TXsrc=TA(RTS) • Other NAV rules • If NAV protection is desired for a transmission to the HC in response to (+)CF-Poll, it is allowed to send CTS with TA=RA=ownAddr to set NAV in own vicinity. An RTS is unnecessary because the NAVs in vicinity of HC was set by the (+)CF-Poll frame. Michael Fischer, Intersil

  24. HCF Frame Exchange Rules at ESTA • A TXOP obtained by winning EDCF contention can be used to send a single MPDU or MMPDU with total medium occupancy time not exceeding the TXOP limit from the QoS information in the beacon. • A TXOP pursuant to a (+)CF-Poll uses the specified TXOP limit. • ESTAs use QoS data format for all exchanges to/from HC/EAP, and may (should) use QoS data format for ESTA-to-ESTA transfers. • Traffic monitor and HC assume all non-QoS frames are best effort traffic • ESTAs may use +CF-Ack to acknowledge receptions from the HC. • ESTAs may only use +CF-Ack for ESTA-to-ESTA if the +CF-Ack is attached to a QoS-Data frame addressed to the same ESTA, as will often be the case during autonomous bursts. • ESTAs must respond to a (+)CF-Poll • A response of QoS-Null(+CF-Ack) is used when there is nothing to send or when the frame to send will not fit in the TxOp. The HC can distinguish these cases by the queue state in the TCID field. Michael Fischer, Intersil

  25. Requests Using CC/RR and QoS Null • The HC can send a CC at any time (e.g. during the CP as well as CFP). • ESTAs send RR frames only in response to CCs. • The HC is required to initiate at least 1 CCI per DTIM interval. • The number of CCOPs in this CCI shall be at leastmax(2,ceiling(0.25*(#Assoc_ESTAs - #ESTAs_with_TXOPs))) • ESTAs may request to be polled by sending a QoS Null in any TXOP: • The TCID field contains the TC/priority and requested TXOP duration. • A TxOp longer than the EDCF TXOP limit can be requested by sending a QoS Null with the desired duration after winning EDCF contention. • If the nonAck QoS control bit is =0, the HC must respond to this QoS Null with a CF-Poll+CF-Ack, but is not required to grant a TXOP of the requested length. Michael Fischer, Intersil

  26. Symbols for Frame Exchange Diagrams • Frames are shown using 4- and 6-sided symbols, with enclosing round-cornered rectangle to show the scope of optional or repeatable subsets: • (E)DCF contention and IFS periods are shown using 3- and 5-sided symbols: Michael Fischer, Intersil

  27. Legacy Frame Exchange Sequences • To the right are the frame exchanges defined in Table 21 of 802.11-1999 illustrated using this symbology. Note: The last CF-Sequence ofeach CFP includes 1 instanceof CF-End followed by DIFS.All other CF-Sequences include0 instances of CF-End. Michael Fischer, Intersil

  28. HCF Frame Exchanges for CF-Bursts • To the right are the frame exchanges required for HCF QoS Data transfers. • Each CF-Burst comprises one or more TxOp. Note: Management frames can only be sent as the sole or final frame of a TxOp, since with no TCID field they default to NF=0. Michael Fischer, Intersil

  29. Start of TXOP Details • There is one null and one non-null case for the start of a polled TXOP. • There are three possible optimizations/deoptimizations of the non-null case. Michael Fischer, Intersil

  30. End of TXOP Details • There are two cases for the end of a TXOP, based on whether the HC has additional traffic to transmit and/or additional ESTAs to poll. Michael Fischer, Intersil

  31. TXOP Requests • QoS Null with TS=1 can be used to activate or deactivate periodic polling under an admitted Tspec. • QoS Null with TS=0 can be used to request an immediate TXOP longer than the current EDCF TXOP limit. • CC defines a controlledcontention interval (CCI)when WSTAsthat need morebandwidth maysend RR frames. Michael Fischer, Intersil

  32. Recovery from Non-Responses • If the addressed ESTA does not respond to RTS or QoS Data at SIFS, the TXOP holder may resume transmission at PIFS unless PHY reports CCA(busy). • If the TXOP holder does not resume transmission at PIFS, the TXOP terminates and the HC may resume transmission at DIFS or may allow the to CFB end. Michael Fischer, Intersil

  33. NAV Usage During TXOP • This diagram shows the periods covered by the NAV, based on Duration field values in the various frames of a TXOP during which the polled ESTA initiates several QoS Data frame exchanges. Michael Fischer, Intersil

  34. Multicast Delivery by HC • Both HCF and PCF transmit queued broadcast and multicast frames directly following DTIM Beacons. • The HC uses PIFS immediately after each broadcast/multicast frame, and terminates the CFP early if CCA(busy) is detected during any such PIFS. • The HC typically sends CF-End immediately after the last queued broadcast/multicast frame, and provides reserved bandwidth and priority access for QoS traffic using controlled TXOPs during the CP. However, the HC may provide some TXOPs as CF-Sequences during the CFP. Michael Fischer, Intersil

More Related