Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
a) (#290)A MAC header, which comprises frame control, optional duration (not in PS-Poll frames),address, optional sequence control information, optional QoS Control information (only in QoSData frames), and optional HT Control fields (only in +HTC frames);b) A variable length frame body, which contains information specific to the frame type and subtype;c) An FCS, which contains a 32-bit CRC based on ITU-T Recommendation V.42 [B54] (see 9.2.4.9(FCS field)).
Mike,
Really not trying to be argumentative… ! But, I can’t find anything that says (or even implies) that 2304 must be supported on recieve. The table(s) we’re looking at in this comment, for example, all seem to imply this is a maximum size, which could be interpreted as a requirement on the TXer to never send anything bigger than that. But, I’m having a hard time finding a statement (or implied statement) that I can point to, that says an RXer must support receiving the maximum size. If you can find such a hint, I would really appreciate that!
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, February 8, 2022 7:16 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)
Hi Mark,
All frame format requirements are normative so 2304 must be supported. That has always been the case. A STA that does not support 2304 is non-compliant.
Cheers,
Mike
On Mon, Feb 7, 2022 at 8:29 PM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
All,
Does anyone know if there is a normative statement that 2304 must be supported, or an implied requirement to that effect, such that these implementations that don’t support it are non-compliant? If so, then I have a real problem with a Standard that lays out a bunch of requirements, but then has NOTE(s) that say “Oh, by the way, some implementations don’t meet the requirement, so your implementation (to the reader) had better adapt.”
On the other hand, if there really is no such a requirement, just a hint/implication that an implementation _should_ handle this, then we are in a different direction. If we’re in that direction, my only concern with Mark R’s proposal is the quoting of a specific size that might work better, when I’ve seen no evidence supporting that number. I’d rather leave the number out, and just NOTE that using smaller Beacons might be beneficial due to this problem. (However, I would still struggling internally that we don’t actually have normative text saying what is required – but I agree that would be very difficult to add at this point.)
Mark
From: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Monday, February 7, 2022 3:08 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)
--- This message came from the IEEE 802.11 Working Group Reflector ---
Mark,
Why not leave the Standard open and allow external testing and developers to identify the optimum size that they would like to use?
There is not a reason to limit this in the standard.
Kind regards,
Jon
-----------------------------------------------------------------------------
Jon Rosdahl Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023 10871 North 5750 West
cell: 801-376-6435 Highland, UT 84003
A Job is only necessary to eat!
A Family is necessary to be happy!!
On Mon, Feb 7, 2022 at 11:09 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Following discussions in TGme today, re the following comment on 11me/D1.0:
It is not clear that all implementations support Beacon frames that are 2304 octets long
I would like to propose the following change:
After the table in 9.2.4.8.1 add "NOTE <n>---Some implementations might not support 2304-octet Beacon or Probe Response frames. Restricting Beacon and Probe Response frames to a maximum of 1536 octets might improve interoperability." and in the "MMPDU size" cell add "(see NOTE <n>)"
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
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
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