Suggested changes to Tge D3.3 November 2002 Suggested changes to Tge D3.3 Keith Amann, Spectralink Srinivas Kandala, Sharp Kevin Karcz, University of New Hampshire Partho Mishra, Airgo Networks K.Amann, et. al.

MIB MIB in the draft is not correct. November 2002 MIB MIB in the draft is not correct. 02/680r0 contains the correct definitions of the MIB. Move to incorporate the text in 02/xxxr0 into the Tge draft. K.Amann, et. al.

Service class IEEE Std. 802.11-1999 defines two services: Month 2002 doc.: IEEE 802.11-02/xxxr0 November 2002 Service class IEEE Std. 802.11-1999 defines two services: StrictlyOrdered and ReorderableMulticast Reordering is allowed in Tge within a Traffic category or Traffic Stream. There have been comments in the letter ballot that the wording in the draft make the legacy devices non-compliant. We tend to agree with this viewpoint. Suggest changing the wording to indicate that reordering is specifically allowed only in QSTAs and non-QoS STAs may still support StrictlyOrdered class. K.Amann, et. al. John Doe, His Company

Motion on Service classes Month 2002 doc.: IEEE 802.11-02/xxxr0 November 2002 Motion on Service classes Move to instruct the editor to incorporate in the Tge draft, the changes to the draft text indicated in document 02/679r0 regarding service classes in clauses 6.1.3, 6.2.1.1.2, 6.2.1.2.2 and 6.2.1.3.2. K.Amann, et. al. John Doe, His Company

Sequence number assignment for management frames November 2002 Sequence number assignment for management frames Clause 7.1.3.4.1 says (line 23, page 23): Sequence numbers for management type frames sent by QSTAs and QAPs are assigned as specified in 7.2.3. No description of sequence number assignment for management type frames is described in 7.2.3. General agreement in the group that all management frames are assigned sequence number from a single modulo-4096 counter. K.Amann, et. al.

Sequence number assignment for multicast/broadcast frames November 2002 Sequence number assignment for multicast/broadcast frames Multicast/broadcast frames may also be protected using WEP or Tgi enhancements. To protect from replay attacks, the sequence number assignment should be done from unique sequence counters. Suggest adding wording to allow this. K.Amann, et. al.

Sequence number assignment for QoS (+) Null frames November 2002 Sequence number assignment for QoS (+) Null frames QoS data frames of subtype QoS Null and QoS +CF-Ack usually need to be generated within SIFS duration of the previous frame in most cases: Makes it hard in implementations where the software assigns the sequence number. If Group Ack is used then some of the intervening sequence numbers may be used for these frames. All of these frames are essentially of control type and sequence number does not serve any purpose. Propose to use the sequence number of 0 for all QoS (+) Null frames, i.e., QoS Null, QoS CF-Ack, QoS CF-Ack+CF-Poll and QoS CF-Poll. K.Amann, et. al.

Motion for Sequence number assignment November 2002 Motion for Sequence number assignment Move to instruct the editor to incorporate in the Tge draft, the changes to the draft text indicated in document 02/679r0 in clause 7.1.3.4.1. K.Amann, et. al.

Sequence number allocation November 2002 Sequence number allocation Currently, sequence numbers are allocated from separate counters per TID per destination address. Per TID is required to allow reordering across TIDs and possible to circumvent replay attacks. Per destination is desirable if Group Ack is used, but not essential as “Sent Count” subfield can be used even if the MSDUs sent to a particular destination within a group are not in a sequnce. Poll for keeping/removing “per destination address” If the poll result suggests removing “per destination address”, then move to delete on page 23, line 21 of Tge draft, the phrase, “that they source to a unique destination” from the draft. K.Amann, et. al.

November 2002 Duration Rules K.Amann, et. al.

Duration field in RTS, data and management frames November 2002 Duration field in RTS, data and management frames The duration rules for RTS, data and management frames in 7.2.1.1, 7.2.2 and 7.2.3 do not allow the setting of the duration field for longer than the next MPDU. Inconsistent with 7.1.3.2 and may handicap EDCF bursting. Suggest it needs to cover all the cases described in 7.1.3.2 for CP. K.Amann, et. al.

Motion for Duration field in RTS frames November 2002 Motion for Duration field in RTS frames Move to instruct the editor to incorporate in Tge draft, the changes to the draft text indicated in 02/679r0 in clause 7.2.1.1, 7.2.2 and 7.2.3. K.Amann, et. al.

Duration value when No ack is used November 2002 Duration value when No ack is used The rules for duration value in 7.1.3.2 do not include the appropriate setting for frames that require no acknowledgement. Move to instruct the editor to incorporate in Tge draft, the changes to the draft text indicated in 02/xxxr0 in clause 7.1.3.2. K.Amann, et. al.

Duration value for polled TXOPs November 2002 Duration value for polled TXOPs Text in conflict at several places in clauses 9.10.2.2.2 and 9.10.2.3.2. The duration value should be set to the TXOP duration + aSlotTime Text has aSlotTime at a few places, DIFS at a few places and even 0 at one place. Suggest we correct the text and make it aSlotTime at all places. K.Amann, et. al.

November 2002 Motion Move to instruct the editor to incorporate in the Tge draft, the changes to the draft text in 02/679r0 in clauses 9.10.2.2 and 9.10.2.3.2. K.Amann, et. al.

Duration rule for EDCF TXOP when Group Ack is used November 2002 Duration rule for EDCF TXOP when Group Ack is used 9.11.3 (Line 7, page 76) says: the duration field of the final frame in the TXOP shall protect at least the GroupAck frame. Forces the GroupAckReq/GroupAck frame exchange to be the final frame exchange in EDCF. In conflict with the paragraph above it where frames can be sent in multiple bursts. Unnecessary restriction. Move to strike the above line from the draft. K.Amann, et. al.

CIF and ECF in Probe Request November 2002 CIF and ECF in Probe Request Capability Information field follows one or more information elements. CIF is a fixed field and can not be parsed correctly and will be interpreted as another information element. Capability Information field and Extended Capability Information field in probe request have been added for the purpose of WSTAs determining the capabilities of another WSTA for direct frame transfer. DLP has its own request/response exchange and a WSTA does not need to rely on probe request/response exchange. Suggest eliminating these two fields in the probe request frame. K.Amann, et. al.

Motion on Probe Request November 2002 Motion on Probe Request Move to instruct the editor to delete all the changes, in the Tge draft, that are made to clause 7.2.3.8 and restore it to the text in the approved base standards (802.11 and 802.11d). K.Amann, et. al.

November 2002 Probe Response In some environments, there may be multiple BSS and a STA may have the option of choosing the one it wants to join. The choice is probably dependent on the load on each of the BSS. QoS Parameter Set gives the EDCF parameters that may be useful to determine if the STA wishes to join any given BSS. Adding QoS Parameter Set to Probe Response frame. To make it consistent with the beacon, order QoS Parameter Set between QBSS load and Extended Capability Information field. K.Amann, et. al.

Motion on probe response November 2002 Motion on probe response Move to instruct the editor to add QoS Parameter Set to Table 12 and make the order consistent with Table 5 in the Tge draft. K.Amann, et. al.

Handling of frames that are associated with a TS at the AP November 2002 Handling of frames that are associated with a TS at the AP Currently, there is no description on how a frame associated with a TS should be handled at the receiver. Suggested rules: Extract the user priority from the TSID in the QoS Control field. If the received frame has a destination address within the BSS, and there is a TSPEC set up for the frame, the AP determines the TSID for further transmission (with the aid of classification function available) and the corresponding transmit queue. If the received frame has a destination address within the BSS and there is no TSPEC set up for the frame, the AP shall determine the transmit queue according to the UP mappings in Table 0.1. If the frame has a destination address reachable through the bridge, the AP shall signal to the bridging layer the recovered 802.1D priority which is the UP. K.Amann, et. al.

November 2002 Motion Move to instruct the editor to incorporate into the Tge draft, the changes to the draft text indicated in 02/679r0 in clause 6.1.1.1 K.Amann, et. al.

Recovery in a polled TXOP November 2002 Recovery in a polled TXOP Paragraph 1 of 9.10.2.1.2 says: QSTAs, including the HC, are required to respond within any frame exchange sequence after a SIFS period. If the beginning of reception of an expected response, as detected by the occurrence of PHY-CCA.indication(busy) at the QSTA which is expecting the response, does not occur during the first slot time following SIFS, that QSTA may initiate recovery by transmitting after PIFS from the end of the last transmission. This recovery after PIFS is only permitted by the QSTA expecting the response. In the case of HC, we agree with “may initiate recovery” In the case of WSTA, it does not make sense to wait for longer than PIFS: If the recipient is the HC, it is unlikely that the transmission error was due to a collision, as the NAV of all other STAs is set (and there will be negligible intereference). If the recipient is another WSTA, the sending WSTA should be able to send frames to other recipients. Suggested change: Split the above into two cases. Keep the “may” for HC, and make it to “shall” for the WSTA K.Amann, et. al.

November 2002 Motion Instruct the editor to incorporate into the Tge draft, the changes to the text relating to the recovery rules indicated in 02/679r0 in clause 9.10.2.1.2. K.Amann, et. al.

TXOP Duration Request vs TC Queue Size November 2002 TXOP Duration Request vs TC Queue Size Currently there are two alternate ways to indicate the bandwidth requirements. TXOP duration request appears to be useful when the STA wishes to indicate the amount of time it takes to transmit one MPDU. TC queue size is useful for optimization of scheduling by the HC. However, this creates confusion and we should have some specific rules as to what is used in which context. There are four ways of resolving the issue: Use only TXOP duration requested Use only TC queue size Use both of them, but the HC gets to decide which one is used (through a capability element) Use both of them – reserve TXOP duration request only when an allocated TXOP is not sufficient to send at least one MPDU; use TC queue size otherwise. A poll would be helpful as to how the group wants to move on this. K.Amann, et. al.

November 2002 Action frame formats The frame format for action frames in Tgh are different from that of Tge. Tgh has been approved at WG level. In some sense, Tge has better definitions, but some of the features may be unnecessary: Need for having a request/response pair Activation delay and Action-related Status in each of the frames as they may not be needed/suitable in certain cases. Need direction from the group if we should make any changes. K.Amann, et. al.

Polled TXOPs for UP traffic November 2002 Polled TXOPs for UP traffic Before the removal of CC/RR, WSTAs which do not set up TSPECs are allowed to request for bandwidth using QoS Control field in RR frame or QoS data frame. The HC may schedule if there is sufficient bandwidth available. Poll to determine if we still want to support it? K.Amann, et. al.

Change to Figure 11.1 Figure is correct only for WEP. November 2002 Change to Figure 11.1 Figure is correct only for WEP. The enhancements required by Tgi will be made by Tgi, as required. Motion: Replace Encryption by WEP in figure 11.1. K.Amann, et. al.