doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 1 Some Clarifications to IEEE e, Draft 3.2, August 2002 H.L. Truong and G. Vannuccini IBM Research Division Zurich Research Laboratory

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 2 Objectives To seek for clarifications on some issues not well specified in the current Draft D3.2, mainly regarding: General definitions of UP, TC, AC, TS, and TSPEC EDCF TXOP operation Polled TXOP operation  To propose possible solutions to some of those issues

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 3 General Issues G1) Number of User Priorities D3.2 § : The maximum number of User Priorities (UPs) is set to 8, with UP being defined for both TCs (with a 1:1 mapping) and TSs (via the TSPEC).  Such a limitation cannot be enforced at the MAC layer, due to the connectionless nature of TCs. The MAC layer can only limit the number of TSs, but not the number of TCs!

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 4 General Issues G2) Mapping between UP and AC D3.2 § HCF contention-based channel access (EDCF): “One or more UPs are assigned to each AC.” The mapping between UP and AC is however not standardized. This will lead to the following issue.  Issue: Since the mapping between UP and AC is not standardized, ACs in different WSTAs may have different control parameters (depend on which lowest UP is assigned the AC). Thus, it cannot be guaranteed that MSDUs of the same UP will get the same relative priority in the different WSTAs. That also means, an application using a certain UP may get different performance depending on which WSTA it is running, which, in our opinion, does not make sense.  We propose to standardize the mapping between UP and AC to avoid the mismatching of performance shown above.  See next slide for more details

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 5 General Issues G3) Mapping between UP and AC D3.2 § , footnote 8: “Using the mapping between UP and traffic types found in IEEE 802.1D Annex H.2 is recommended”  802.1D specifies the mapping between UP and traffic type. However, it does not specify any mapping between UP and AC (AC is not defined in 802.1D).  We propose that the mapping between UP and AC is standardized as done in IEEE 802.1Q Tab.8-3 (Outbound Access Priorities), in which a fixed mapping between UP and Access Priority is specified. In this table, the Access Priority would be replaced by the Access Category. A similar mapping is found also in IEEE 802.1Q Table 8-2, “Recommended user priority to traffic class mappings”.

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 6 General Issues G4) User Priority and TSPEC D3.2 § (Interpretation of TID): “Outgoing MSDUs with priority parameter values 8 through 15 are handled by MAC entities at QSTAs in accordance with the local significance of the user priority value determined by the priority parameter in the selected TSPEC, and using any non-null values in the selected TSPEC in place of the default values for the corresponding QoS parameters”.  Can we derive from this statement that, even for TSs, it may be in theory possible to use EDCF-based access? And, moreover, to what does it refer the: “in place of the default values for the corresponding QoS parameters”? To the default EDCF access parameters in QoS Parameter Set Element (e.g. CWMin, CWMax,..) or to what?  We propose to change the statement into: “Outgoing MSDUs with priority parameter values 8 through 15 are handled by MAC entities at QSTAs in accordance with the local significance of the user priority value determined by the priority parameter in the selected TSPEC.” Since it is straightforward that the non null values of TSPEC will be interpreted, and, moreover, the TSPEC has no default values, since the null values are interpreted as “unspecified”, and not as defaults.

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 7 General Issues G5) TSID and AC In §3.65 it is stated that the TCs are mapped to ACs. However, to our knowledge, there is no explicit statement denying the mapping of TSs to ACs.  Although this may be in general possible, we find it confusing to mix up the concepts of Traffic Stream, Traffic Category, Contention Access and Polled Access.  We propose, in order to simplify the understanding of the model, that there should be a clear separation between TCs and TSs, i.e.  TCs are allocated to ACs and use EDCF TXOPs to access the media, while  TSs are characterized by TSPECs and use polled TXOPs to access the media.

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 8 EDCF TXOP Issues E1) EDCF TXOP, QoS Parameter Set Element with TXOP Limit = 0 D3.2 § (Description of TXOP Limit field) states that, if TXOP limit in QoS Parameter Set Element is 0, then only one MPDU can be transmitted during that TXOP  Wouldn’t it be more efficient to allow a whole MSDU to be transmitted in this case? If for instance the fragmented MPDU length is larger than the RTSThreshold, then a new RTS/CTS would be issued for every fragment, which seems to be not very efficient? Moreover, this makes the e not compliant with the DCF, where a whole MSDU can be sent per transmission interval.

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 9 EDCF TXOP Issues E2) EDCF TXOP, recovery procedure with TXOP Limit >0 D3.2 § (Error Recovery Procedure for EDCF): What happens if, during an EDCF TXOP, an ACK/CTS times out, and the remaining EDCF TXOP is non-zero? What should be done in this case: Check retry limits and if they are not reached resend the MPDU/RTS, or end the TXOP and backoff?  Proposal: In case of ACK or CTS timeout, end TXOP and backoff.  Rationale: Since the timeout is caused most probably by collision events, then backoff would reduce the probability of further collisions.

doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 10 Polled TXOP Issues P1) Recovery procedure in polled TXOP D3.2 § (Recovery from the absence of an expected reception): What happens if, during a polled TXOP, an ACK/CTS times out, and the remaining TXOP time is non-zero? What should be done in this case? Check retry limits and if they are not reached retry to send the MPDU/RTS, or go to backoff and thus end the TXOP? Proposal: it would be more efficient to retry than going to backoff Rationale: in this case, differently from E2), the probability of collisions would be rather small, being in polling mode, so a better efficiency could be achieved by retrying the transmission.