1 / 28

Suggested changes to Tge D3.3

This document proposes various changes to the Tge draft for IEEE 802.11, including corrections to the MIB, service class definitions, sequence number assignments, duration rules, and more.

jolivia
Download Presentation

Suggested changes to Tge D3.3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  9. 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. Duration Rules K.Amann, et. al.

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

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

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

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

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

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

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

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

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

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

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

More Related