1. 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.

2. 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.

3. Service class IEEE Std. 802.11-1999 defines two services:
Month 2002
doc.: IEEE /xxxr0
November 2002
Service class
IEEE Std 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

4. Motion on Service classes
Month 2002
doc.: IEEE /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, , and
K.Amann, et. al.
John Doe, His Company

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

6. 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.

7. 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.

8. 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
K.Amann, et. al.

9. 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.

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

11. 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 , and do not allow the setting of the duration field for longer than the next MPDU.
Inconsistent with and may handicap EDCF bursting.
Suggest it needs to cover all the cases described in for CP.
K.Amann, et. al.

12. 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 , and
K.Amann, et. al.

13. Duration value when No ack is used
November 2002
Duration value when No ack is used
The rules for duration value in 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
K.Amann, et. al.

14. Duration value for polled TXOPs
November 2002
Duration value for polled TXOPs
Text in conflict at several places in clauses and
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.

15. 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 and
K.Amann, et. al.

16. Duration rule for EDCF TXOP when Group Ack is used
November 2002
Duration rule for EDCF TXOP when Group Ack is used
(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.

17. 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.

18. 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 and restore it to the text in the approved base standards ( and d).
K.Amann, et. al.

19. 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.

20. 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.

21. 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.

22. 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
K.Amann, et. al.

23. Recovery in a polled TXOP
November 2002
Recovery in a polled TXOP
Paragraph 1 of 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.

24. 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
K.Amann, et. al.

25. 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.

26. 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.

27. 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.

28. 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.