1. Introduction to the TGe Hybrid Coordination Function (HCF)
May, 2001
Introduction to the TGe Hybrid Coordination Function (HCF)
Presented to 5GSG on May 15, 2001
Derived from material in documents 00/453r3 and 01/109r2
Michael Fischer
Intersil Corporation Medical Drive San Antonio, TX voice: fax:
Michael Fischer, Intersil

2. May, 2001
Introduction
The Hybrid Coordination Function (HCF) combines the enhanced DCF with generalized PCF features to simplify the E MAC:
A SINGLE QoS conformance level, and
A SINGLE set of frame exchange rules, usable in both CP and CFP.
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 mechanisms and reducing implementation complexity.
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

3. May, 2001
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

4. May, 2001
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

5. The HCF is NOT… A new channel access mechanism:
May, 2001
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.
The HCF is a point coordination function, but not the point coordination function specified for PCF.
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

6. May, 2001
Origins
Contention free bursts are a concept from the early years of , 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 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 QoS Model with Point-controlled Contention Arbitration, Robert Meier.
Michael Fischer, Intersil

7. Terminology HC: Hybrid Coordinator
May, 2001
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: Transmission Opportunity
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. During a CFB all frame exchanges are initiated either by the HC or in direct response to a QoS (+)CF-Poll from the HC.
Michael Fischer, Intersil

8. Additional QoS Information in Beacon
May, 2001
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

9. May, 2001
New TCID Field Layout
Contents of TCID ( ) and TCA ( ) fields change as shown:
TS is =1 if the traffic for the indicated TC is subject to a Tspec.
Non-Ack is =1 if no response is to be sent after SIFS. The ESTAs can distinguish "delayed-Ack" from "no-Ack" using information in the Tspec.
Non-Final is =1 if another frame exchange is pending for this TXOP.
Michael Fischer, Intersil

10. May, 2001
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 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

11. Subtypes of Frame Type "Data"
May, 2001
Subtypes of Frame Type "Data"
The subtype field of data type frames (both in 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
+CF-
Ack
Poll
noData
QoS 1 2
Bit: 3 4 5 6 7
QoS Data = QoS Data + (noPoll) + (noAck)
QoS Data+CF-Ack = QoS Data + (noPoll) + CF-Ack
QoS Data+CF-Poll = QoS Data + CF-Poll + (noAck)
QoS Data+CF-Poll+CF-Ack = QoS Data + CF-Poll + CF-Ack
QoS Null (no data) = QoS + noData + (noPoll) + (noAck)
QoS CF-Ack = QoS + noData + (noPoll) + CF-Ack
QoS CF-Poll = QoS + noData + CF-Poll + (noAck)
QoS CF-Poll+CF-Ack = QoS + noData + CF-Poll + CF-Ack
Michael Fischer, Intersil

12. Rules Pertaining to the HC
May, 2001
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

13. IFS Usage for HCF QoS Transfers
May, 2001
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

14. Duration Value Calculation
May, 2001
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 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
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.
CF-Poll
NAV from CF-Poll
SIFS
D I F S
TxOp granted by CF-Poll
TXOP Limit from CF-Poll
Michael Fischer, Intersil

15. May, 2001
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:
CF-
Poll
TXOP Limit from initial CF-Poll
SIFS
QoS Data
(NF=1)
QoS Data +CF-Poll +CF-Ack
time stolen by HC for data
Ack time
TXOP Limit from +CF-Poll
Ack
stolen time replaced
QoS Data (NF=0)
Michael Fischer, Intersil

16. Additional NAV Rules for ESTAs
May, 2001
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

17. HCF Frame Exchange Rules at ESTA
May, 2001
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

18. Revised CC Frame Format
May, 2001
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

19. Revised RR Frame Format
May, 2001
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

20. Requests Using CC/RR and QoS Null
May, 2001
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 least max(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

21. Symbols for Frame Exchange Diagrams
May, 2001
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

22. Legacy Frame Exchange Sequences
May, 2001
Legacy Frame Exchange Sequences
To the right are the frame exchanges defined in Table 21 of illustrated using this symbology.
Note: The last CF-Sequence of each CFP includes 1 instance of CF-End followed by DIFS. All other CF-Sequences include 0 instances of CF-End.
Michael Fischer, Intersil

23. HCF Frame Exchanges for CF-Bursts
May, 2001
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

24. May, 2001
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

25. May, 2001
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

26. May, 2001
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 controlled contention interval (CCI) when WSTAs that need more bandwidth may send RR frames.
Michael Fischer, Intersil

27. Recovery from Non-Responses
May, 2001
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

28. May, 2001
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

29. Multicast Delivery by HC
May, 2001
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