Download
1 / 13
130 likes | 237 Vues
EDCF Issues and Suggestions. Sunghyun Choi * , Woo-Yong Choi + , and Javier del Prado - * Seoul National University, + Electronics and Telecommunications Research Institute (ETRI), - Philips Research USA. Background. 802.11e/D4.0 has improved explanation about EDCF
E N D
EDCF Issues and Suggestions Sunghyun Choi*, Woo-Yong Choi+, and Javier del Prado- *Seoul National University, +Electronics and Telecommunications Research Institute (ETRI), -Philips Research USA S. Choi, Seoul National University, et al.
Background • 802.11e/D4.0 has improved explanation about EDCF • However, there still exist inconsistencies throughout the draft, especially, between 9.1.3.1 and 9.10.1 • There are some unclear explanations as well S. Choi, Seoul National University, et al.
Duration/ID Set Rule (1) • The rule in item (c) of 7.1.3.2 is not clear at all. The text says … (c) In all other frames transmitted in a contention period (CP) following a contention access of the channel, the Duration/ID field is set to one of the following three values: • If Ack policy of normal acknowledgement is used, the time required for the transmission of one ACK frame (including appropriate IFS values). • If Ack policy of normal acknowledgement is used, the time required for the transmission of one ACK followed by another MPDU and its ACK (including appropriate IFS values). • The duration of the entire burst as determined by the STA. S. Choi, Seoul National University, et al.
Duration/ID Set Rule (2) • Does it mean that any one of three values can be used? Is it desirable? • What is the definition of the “burst”? • We believe that the second one is the best choice! • The first one does not protect the CFB • Assuming that the burst is an “intended” CFB, the third one cannot be a good one since the TXOP holder may not complete the intended CFB due to a transmission failure. S. Choi, Seoul National University, et al.
Frames during EDCF TXOP (1) • 9.1.3.1 (e) and 9.10.1.4 say different rules about which frames can be transmitted during an EDCF TXOP after the initial MPDUtransmission. • 9.1.3.1 says … (e) During an EDCF TXOP won by an AC, a QSTA may initiate multiple frame exchange sequences to transmit MMPDUs and/or MSDUs within the same AC or a higher-valued AC. • 9.10.1.4 says … Note that, as for an EDCF TXOP, a continuation TXOP is granted to a channel access function, not to a non-AP STA or AP, such that a continuation TXOP only permits transmission of a frame of the same priority as that which was granted the EDCF TXOP. S. Choi, Seoul National University, et al.
Frames during EDCF TXOP (2) • We prefer the rule in 9.10.1.4, but it should be revised as follows: Note that, as for an EDCF TXOP, a continuation TXOP is granted to a channel access function, not to a non-AP QSTA or QAP, such that a continuation TXOP only permits transmission of a frame of the samepriority access category as that which was granted the EDCF TXOP. S. Choi, Seoul National University, et al.
Four ACs within HC (1) • 9.1.3.1 says there is a single AC within HC even if it may have multiple queues • However, 9.10.1 implies that the HC has also multiple ACs • According to HCF, the HC can grab the channel after a PIFS idle time whenever it wants, and hence one can conclude that the HC does not need four ACs • This may result in unfairness between donwlink TCs and up/direclink TCs • However, if the HC implements four ACs, the HC may experience more delays for its donwlink TCs • since there will be more downlink TCs than up/directlink TCs typically S. Choi, Seoul National University, et al.
Four ACs within HC (2) • This needs more discussion within the group, we believe! S. Choi, Seoul National University, et al.
QoS Parameter Set (1) • Basically, QoS Parameter Set has two types of fields • One for EDCF access (AIFS[AC], CWmin[AC], Cwmax[AC], TXOPLimit[AC]) and the other for distributed admission control • We believe that the values of the first set will rarely change while the second set will be updated in each beacon! S. Choi, Seoul National University, et al.
QoS Parameter Set (2) • Considering the added beacon overhead due to 802.11e, we propose to divide these two sets into two information elements • Say, EDCF Access Parameter element and Distributed Admission Control parameter element • Then, we have to allow that the “EDCF Access Parameter” element needs not to be in every beacon! S. Choi, Seoul National University, et al.
Queue Size in QoS Control Field (1) • Queue Size is included in QoS Control Field for all QoS Data Frames sent by non-AP QSTAs: • For both TSs and TCs • The Queue Size value can be used by the HC: • To schedule downlink frames and to schedule polled TXOPs! • That applies to TCs as well (if the HC can poll TCs?) • It is not clear in D4.0 if polling TCs is allowed • Note that the HC’s scheduling can affect the non-AP QSTA’s EDCF access! • HC can adjust its scheduling depending on the TC queue sizes in order not to degrade the EDCF access performance S. Choi, Seoul National University, et al.
Queue Size in QoS Control Field (2) • However, the Queue Size field is essentially optional • The queue size can be actually unspecified if the value is 255 • We believe that the Queue Size field shouldn’t be optional! • Moreover, the Queue Size value for a TC frame should specify the pending traffic amount for the corresponding AC, not the corresponding TC (or TID) as specified in 7.1.3.5.5! S. Choi, Seoul National University, et al.
dot11EDCFTableAIFS Value Range • According to Annex D, the dot11EDCFTableAIFS value can be from 0 to 10. • In order not to interfere with the HC, the dot11EDCFTableAIFS should be at least 1. • Moreover, we don’t understand why it should be upper-bounded by 10. S. Choi, Seoul National University, et al.
