Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
> [1] 19/2160r2:
the proposed resolution for the 89 CIDs Thanks for these resolutions.
Here are my comments on the proposed resolutions to the 89 "review" comments in 19/2160r2: CID 4063: I think it needs to be "NOTE 1" and "NOTE 2" not "NOTE1" and "NOTE2" CID 4069: Has to be REVISED because proposed change has duplicate "54" CID 4070: No, this comment should be REJECTED.
The point is that the BFee does not fragment if the CBR fits in the
BFer's max MPDU
len capability. So if for example the CBR is 10k and the
BFer's max MPDU
len capability is 11k, then the BFee does not fragment, even if the
BFee's max MPDU len capability on
rx is 4k (which one might think might also be its max on tx).
This is the subtlety the NOTE is capturing.
Indeed, The VHT
beamformee might therefore have to transmit an MPDU that is bigger than the VHT
beamformer is capable of receiving. would be plain wrong: it never does that. CID 4072: Actually, the spec is inconsistent as to the
enum names for the (EDMG_)BEAM_TRACKING_REQUEST parameter: Table 20-1: Beam
tracking requested or Beam
tracking not requested Table 24-1: Beam
tracking requested or
beam tracking not requested and Enhanced
beam tracking requested or
enhanced beam tracking not requested Table 25-1: Beam
tracking requested or Beam
tracking not requested I suggest making the first letter of each word uppercase, so in addition to the above the following need fixing: 10.42.7 BEAM_TRACKING_REQUEST to Beam Tracking Requested BEAM_TRACKING_REQUEST parameter shall be set to Beam Tracking Not Requested BEAM_TRACKING_REQUEST parameter in the RXVECTOR set to
Beam Track Requested BEAM_TRACKING_REQUEST parameter in the TXVECTOR to Beam Tracking Requested BEAM_TRACKING_REQUEST to
beam tracking not requested BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to
beam tracking not requested 10.42.9 ENHANCED_BEAM_TRACKING_REQUEST to
enhanced beam tracking requested ENHANCED_BEAM_TRACKING_REQUEST parameter shall be set to
enhanced beam tracking not requested ENHANCED_BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to
enhanced beam tracking requested ENHANCED_BEAM_TRACKING_REQUEST parameter in the TXVECTOR to
enhanced beam tracking requested ENHANCED_BEAM_TRACKING_REQUEST parameter in the TXVECTOR to
enhanced beam tracking requested ENHANCED_BEAM_TRACKING_REQUEST parameter in the RXVECTOR equal to
enhanced beam tracking requested Also, in 20.9.2.2.1 "Beam Tracking Request (if present) equal to 0" should (I presume) have "field" before the parenthesis.
Or maybe, looking at the wider sentence structure, instead delete "the" in "the PPDU Type" (also in next bullet)? CID 4074: I'm not sure "following" should be deleted.
I think it's referring to the immediately following PPDU, so maybe a better fix would be to add "immediately"?
Note there are 4 other "following PPDU"s: 2059.63, 2064.24/25, 4405.59. CID 4123: "The thickness of the line at the bottom of Aggregation is very thin because it is not the end of the table." is a nice theory, but in practice there are many tables split across pages where the line at the bottom of one page is not very thin.
Can't this be made some kind of global setting? CID 4241: Re the note to commenter, I think the two locations should be fixed even if they don't match the comment string.
Also 230.2 "transmissions from the AP to itself", 1838.7 "CTS to itself", 2213.19/2214.27 "SPs allocated to itself". CID 4251: Did I really not miss any in CID 4252? CID 4254:
Also "Unless another value is mandated by regulatory authorities, the default value is 256." at 3896.39, "The default value is null." at 3941.57, 3942.44, 3951.43, 3957.23, 3962.5, 3966.45, 3979.14, 3996.61, 4002.8, 4003.48, 4010.49, 4040.28, 4043.7, 4043.25, 4044.54, 4070.27, 4079.59, 4081.19, "The default value of this attribute is …" at 4113.3, 4113.22, 4160.64, 4174.39. CID 4275: Did I really not miss any in CID 4276? CID 4518 and CID 4770: Are the resolutions exactly the same (slight miracle if so!)? CID 4627: Should it maybe be "RCPI parameter", by analogy with other locations? 15.2.3.6 PHY-RXEND.indication parameter RCPI(#2560) The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 9.4.2.37 (RCPI element). This parameter is a measure by the PHY of the received channel power. The performance requirements for the measurement of RCPI are defined in 15.4.6.6 (Received Channel Power Indicator Measurement). 17.2.3.6 PHY-RXEND.indication parameter RCPI(#2560) The allowed values for the RCPI parameter are in the range 0 to 255, as defined in 17.3.10.7 (Received Channel Power Indicator Measurement). This parameter is a measure by the PHY of the received channel power. RCPI indications of 8 bits are supported. RCPI shall be measured over the entire received frame or by other equivalent means that meet the specified accuracy. [which leads to] 17.3.10.7 Received Channel Power Indicator Measurement The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire received frame or by other equivalent means that meet the specified accuracy.
The RCPI encoding is defined in 15.4.6.6 (Received Channel Power Indicator Measurement). [which leads to] 15.4.6.6 Received Channel Power Indicator Measurement The
RCPI is
a measure
of the
received RF
power in
the selected
channel for
a received
frame. This parameter shall be a measure by the PHY of the received RF power in the channel measured over the entire received frame or by other equivalent means that meet the specified accuracy.
The encoding of received power to RCPI is defined in 9.4.2.37 (RCPI element). CID 4645: 2061.61 also needs a "the" CID 4775: I find: 446 "µs" (the right micro, namely U+00B5) 269 "μs" (the wrong micro, namely U+03BC) 213 "microsecond" (of which about 50 in the MIB, where it has to be ASCII) so I think the comment should be ACCEPTED. CID 4794: There are two more, broken across a line, at 2056.50 and 3469.20 > [2] 19/2163r2:
I will have an additional 15 - 20 CIDs for discussion. I attach my comments on 19/2163r2. > [3] 19/2160r2:
a few CIDs that need discussion or assignment to volunteer(s) Which are these? The 15 with status Discuss are addressed in 19/2163r2. So that just leaves CID 4315 and 4784, which do indeed need a submission (for the latter, the commenter has said he will provide a submission.) 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 > -----Original Message----- > From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxx> On Behalf Of > Edward Au > Sent: 2 January 2020 06:10 > To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx > Subject: [STDS-802-11-TGM] Proposed resolution for 89 CIDs uploaded (19/2160r2) > > --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- > > Hi Dorothy, and all > > Proposed resolution for 89 CIDs, which are relatively straightforward, > are uploaded at > https://mentor.ieee.org/802.11/dcn/19/11-19-2160-02-000m-revmd-editor2-standards-association-ballot- > > The ad-hoc status of these 89 CIDs in the spreadsheet is "Review" and > these 89 CIDs are listed as follows: > > 4794, 4789, 4788, 4775, 4773, 4770, 4724, 4684, 4675, 4674, > 4673, 4666, 4665, 4664, 4660, 4645, 4644, 4638, 4627, 4621, > 4619, 4610, 4609, 4532, 4518, 4504, 4502, 4500, 4484, 4481, > 4472, 4464, 4461, 4434, 4426, 4412, 4411, 4407, 4387, 4385, > 4367, 4359, 4357, 4356, 4350, 4348, 4346, 4337, 4333, 4332, > 4331, 4330, 4316, 4302, 4300, 4290, 4280, 4279, 4278, 4276, > 4275, 4268, 4255, 4254, 4252, 4251, 4241, 4228, 4215, 4211, > 4210, 4200, 4199, 4187, 4186, 4185, 4184, 4183, 4180, 4130, > 4128, 4127, 4124, 4123, 4074, 4072, 4070, 4069, 4063 > > Please review and let me know if you have any comment/question. > > Regards, > Edward > > _______________________________________________________________________________ > > IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this > CLOSED reflector. We use this valuable tool to communicate on the issues at hand. > > SELF SERVICE OPTION: > Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and > then amend your subscription on the form provided. If you require removal from the reflector > press the LEAVE button. > > Further information can be found at: https://protect2.fireeye.com/url?k=ad318a15-f0e2d3ab-ad30015a- > 0cc47a31ba82-a85575ba8fc22529&u=http://www.ieee802.org/11/Email_Subscribe.html > _______________________________________________________________________________
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1 |
Attachment:
11-19-2163-02-000m-resolutions-for-some-initial-sa-ballot-comments-on-11md-d3-0-mgr.docx
Description: 11-19-2163-02-000m-resolutions-for-some-initial-sa-ballot-comments-on-11md-d3-0-mgr.docx