Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
Disclaimer: as I said, I'm very confused by all this stuff, so some/all of the following may be bogus. With respect to the excerpt of the discussion below, at least as far as EDCA is concerned, I think the
behavior in terms of the TID field value and BA/SN should be the same for a TS, irrespective of whether or not it has an associated TCLAS. To my understanding, the only differences between TS “with” and “without” TCLAS are as follows: - When TCLAS is present, it explicitly defines rules used by higher layers for classifying MSDUs in the
TS. If TCLAS is not present, the rule is not defined and is presumably determined based on local policies or some other mechanism. - When TCLAS is present, the UP associated with the TS is as defined in that element. If TCLAS is not
present, the UP associated with the TS is as defined in the TSPEC element instead. Do we agree that the UP in the TCLAS element is not the UP to be used for DUs matching that TCLAS, but the optional UP to be used when looking for a TCLAS match?
9.4.2.30 TCLAS element says: When the UP field contains a value that is less than or equal to 7, the value specifies the UP of the associated MSDUs. When the UP field contains a value that is greater than or equal to 8 and less than or equal to 11, the value specifies the access category of the associated MPDUs. The UP field value 255 is reserved and indicates that the UP of the MSDU and the access category of the MPDU are not
compared as part of the traffic filter. [I am not sure whether the fact that the first sentence talks of MSDUs and the second of MPDUs is significant/deliberate or an error.] Either way, the higher layers set the Priority parameter of MA-UNITDATA.request
for the MSDUs in the TS to the TSID (8 thru 15), and the MAC is responsible for mapping the TSID to a UP (using either TCLAS or TSPEC element, per above). And since we are talking EDCA, the TID subfield is set to the UP from 0 to 7 (not the TSID). (There is language in 5.1.1.3 which refers to the receiver inferring the UP by mapping the TSID in TID
subfield based on TSPEC/TCLAS, but I think that only applies to non-EDCA cases since, as defined in Table 9-12, the TID subfield always contains the UP for EDCA). Regarding this: >> BA is set up and identified on a per-UP (not per-TSID) basis It seems this is quite a fundamental concept, but I am unable to find any clear statements in the standard
(although I’m sure there are some experts who know better than I). It is obvious that BAs are negotiated for a given “TID”, however a TS used with EDCA is in the odd situation where a TSID (8-15) is defined yet the TID subfield is set to the UP (0-7). If the
MAC receives an MPDU with TID subfield in the range 0-7, the only way it could know it is actually related to a TS is to try matching its content against the classifier (e.g. TCLAS), which does not sound reasonable for BA window handling. This suggests to
me that MPDUs in an EDCA TS would be treated in the same BA agreement as other MPDUs with the same UP (?) Well, for the ADDBA Request frame, 9.4.1.13 Block Ack Parameter Set field says: The TID subfield contains the TC or TS for which the BlockAck frame is being requested. and 6.3.27.2 MLME-ADDBA.request says that the TID parameter is in the range 0-15, so at least at that level it could be a TSID (8-15) or it could be a (UP/)TC (0-7). Are you saying that a TSID (8-15) can only be used for ADDBA requests when the TSPEC element Access Policy field indicates HCCA or HEMM, not when it indicates EDCA?
And that when it's EDCA then the same BA agreement is used for both stuff sent under the TSID that maps to a certain UP, and stuff sent directly on that UP (which, going back to 20/0814 and Osama's CIDs, might also/instead be a TC here?)? Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From:
Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector ---
Thanks Mark and Osama for working on this. With respect to the excerpt of the discussion below, at least as far as EDCA is concerned, I think the behavior in terms of the
TID field value and BA/SN should be the same for a TS, irrespective of whether or not it has an associated TCLAS. To my understanding, the only differences between TS “with” and “without” TCLAS are as follows: - When TCLAS is present, it explicitly defines rules used by higher layers for classifying MSDUs in the TS. If TCLAS is not present,
the rule is not defined and is presumably determined based on local policies or some other mechanism. - When TCLAS is present, the UP associated with the TS is as defined in that element. If TCLAS is not present, the UP associated
with the TS is as defined in the TSPEC element instead. Either way, the higher layers set the Priority parameter of MA-UNITDATA.request for the MSDUs in the TS to the TSID (8 thru 15),
and the MAC is responsible for mapping the TSID to a UP (using either TCLAS or TSPEC element, per above). And since we are talking EDCA, the TID subfield is set to the UP from 0 to 7 (not the TSID). (There is language in 5.1.1.3 which refers to the receiver inferring the UP by mapping the TSID in TID subfield based on TSPEC/TCLAS,
but I think that only applies to non-EDCA cases since, as defined in Table 9-12, the TID subfield always contains the UP for EDCA). Regarding this: >> BA is set up and identified on a per-UP (not per-TSID) basis It seems this is quite a fundamental concept, but I am unable to find any clear statements in the standard (although I’m sure there
are some experts who know better than I). It is obvious that BAs are negotiated for a given “TID”, however a TS used with EDCA is in the odd situation where a TSID (8-15) is defined yet the TID subfield is set to the UP (0-7). If the MAC receives an MPDU with
TID subfield in the range 0-7, the only way it could know it is actually related to a TS is to try matching its content against the classifier (e.g. TCLAS), which does not sound reasonable for BA window handling. This suggests to me that MPDUs in an EDCA TS
would be treated in the same BA agreement as other MPDUs with the same UP (?) Best Thomas ====== As you can see from my CID 7796 I too find the terms and their intent confusing.
· As for your statement; “The TSID is a number in the range 8-15 identifying a defined traffic stream or a frame that is part of this stream
(but the frames in this stream are, in EDCA, identified over the air by the UP for that stream)”
This is a very confusing statement. How EDCA can be applied to TS? The UP in the TSPEC element is the UP of the MSDUs or A-MSDUs belonging to the TS as defined
in “UP subfield(#2494) indicates the actual value of the UP to be used for the transport of MSDUs or A-MSDUs belonging to this TS when relative prioritization is required. When the TCLAS element is present in the request, the UP subfield in TS Info field
of the TSPEC element is reserved.” This UP value cannot be included in the TID field because the TID field will include the TSID in this case. Perhaps this one of the areas where the spec is not clear and need to be clarified, but it is beyond the scope
of the CIDs I am resolving. I'm not sure I can answer this question. I'm hoping maybe the Chair of the ARC SC (copied) might be able to help. My guess at this point is that there are three paths: 1) Data not subject to a TCLAS or TSPEC just uses UPs throughout. At the MAC SAP it's called the priority, in QoS Data frames it's in the TID field (so the msb is 0). TSID and TC are N/A. 2) Data sent under a TSPEC without a TCLAS is associated with a TSID that has b3 set and a UP. The TSID is used at the MAC SAP, but apparently (per that statement above) over the air they go out with the UP, not the TSID, in the TID field in the QoS Control field. TC is N/A. 3) Data sent under a TSPEC with an associated TCLAS has a TSID and no UP per se. It has a TC, which is then used in the TID field in the QoS Control field. It's possible that for the latter two cases the ADDBA uses the TSID not the UP as the TID. At this point I'm floundering, and again hoping some ARC guru can rescue me. [osama] I think the spec is not clear here and needs to be fixed.
· BA is set up and identified on a per-UP (not per-TSID) basis [think
group response was "No, can be TSID (see e.g. 669.65). In case of TS can have TCLAS. Use TC if no TSPEC in ADDBA Req, use TS(ID) otherwise"] even for defined traffic streams (hm, so why 16 replay counters? Or maybe you can have BAs under HCCA/HEMM/SPCA/SEMM?) So at least then the direction was that you couldn't just delete TC because it was involved in TCLASes. I thought you were going to go off and examine this point. [osama] I don’t know you reference. P669.65 in draft 3.0 doesn’t have any text. I am not sure what you are referring to. My recollection is the TCLAS never been
mentioned during the discussion. Theminutes doesn’t include any reference to TCLAS. I looked at clause 9.4.2.30 of draft 3.0 and there is no mention of traffic category in the context of TCLAS element even though there is a UP field. On July 20, 2020 at 1:02:01 PM, Osama AboulMagd (osama.aboulmagd@xxxxxxxxxx) wrote:
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |