From: Mark Rison <m.rison@xxxxxxxxxxx>
Date: Fri, May 15, 2020 at 2:21 AM
Subject: RE: CID 4137
To: David Goodall <dave@xxxxxxxxxxxxxx>, M Montemurro <montemurro.michael@xxxxxxxxx>
Cc: Yujin Noh <yujin.noh@xxxxxxxxxxxx>, mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>, Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Hello David,
As I previously stated, I do not think that a field that causes
the frame to be rejected by the receiver if it is set to the
"wrong" value should be called "Reserved". "Reserved" should be
reserved for fields that are available for future extension because
they are ignored by current receivers.
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:
David Goodall <dave@xxxxxxxxxxxxxx>
Sent: 15 May 2020 04:44
To: M Montemurro <montemurro.michael@xxxxxxxxx>
Cc: Mark Rison <m.rison@xxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: Re: CID 4137
Hi Mike,
I think this comment can be rejected. For 802.11ah it is clear what to do when these particular bits are not set to 1, which is basically what I was looking for. The original reject reason is sufficient:
REJECTED (PHY: 2020-02-14 15:27:30Z) - To be specific, the Reserved SIG Indication is used as one of criteria in PHY receive procedure whether the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) in different amendments (e.g. 11ac, 11ah and 11ax) when its reserved bit set to 0.
With respect to the note I'll do some more research on the topic of PHY signal field bits which are reserved and set to 1, but there's no need to hold things up for that now.
Thanks,
Dave
On Wed, May 13, 2020 at 1:09 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:
Hey folks,
I'm just following up on this CID? Do we have a resolution yet? It looks like we were working towards one but I couldn't find any proposal for editing instructions.
Thanks,
Mike
On Mon, Mar 23, 2020 at 6:28 PM David Goodall <dave@xxxxxxxxxxxxxx> wrote:
Hi Mark,
>> Set to 1 (used for PHY header validation and PAPR mitigation)
That looks good to me. The PHY header validation is true and I guess we'll wait for the PHY designers to confirm PAPR mitigation was their intent as well.
>> ? We could optionally have something like a "NOTE---A receiver
considers [or "might consider"] a PPDU with this subfield equal
to 0 as invalid."
From Yujin's earlier comment I think I found the relevant text that covers the reserved bits in 802.11ah signal fields in 23.3.19 PHY receive procedure:
"Reserved SIG or SIG-A Indication is defined as an SIG or SIG-A with Reserved bits equal to 0 or a combination not valid as defined in 23.3.8.2.2.5 (SIG definition), 23.3.8.2.3.2.5 (SIG-A definition), or 23.3.8.3.5 (SIG definition), or a combination of S1G-MCS and NSTS not included in 23.5 (Parameters for S1G-MCSs) or any other SIG or SIG-A field bit combinations that do not correspond to modes of PHY operation defined in Clause 23 (Sub 1 GHz (S1G) PHY specification(11ah))."
So receiving a signal field with a reserved bit set to 0 results in a Reserved SIG Indication which causes a PHY_RXEND.indication (FormatViolation) after which EIFS is observed. If we did want to add a note it could be something like:
Receiving a signal field with a reserved bit set to 0 results in a Reserved SIG Indication
Thanks,
Dave
On Mon, Mar 23, 2020 at 11:12 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Dave,
> Reserved for PAPR mitigation. Must be set to 1
I would not be comfortable calling a field that is not ignored by
the received "reserved". If the direction we're going into for this
field is "set to 1 on tx and receiver is entitled/expected to reject
the PPDU if it's not set to 1" then I would suggest something like:
Set to 1 (used for PAPR mitigation)
Actually, we've been discussing how it's being used to sanity-check
PHY headers, so surely it should be:
Set to 1 (used for PHY header validation and PAPR mitigation)
? We could optionally have something like a "NOTE---A receiver
considers [or "might consider"] a PPDU with this subfield equal
to 0 as invalid."
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: David Goodall <dave@xxxxxxxxxxxxxx>
Sent: 20 March 2020 23:11
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: Yujin Noh <yujin.noh@xxxxxxxxxxxx>; M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: Re: CID 4137
Hi Mark, Yujin,
Thanks for looking at this. I got an insight from someone who has been involved in 802.11 OFDM PHY specification, design and implementation since 802.11a days:
· >>
· For the SIG fields, there’s no scrambling, so if you have too many 1s or too many 0s, you get a bad PAPR.
- This drives most of the reserved-set-to-1 bits
<<
So I think that if the PHY designers have, in a specific case, set a specific bit to 1 in order to deal with bad PAPR ( peak-to-average power ratio) then the description should be something like:
Reserved for PAPR mitigation. Must be set to 1
Making that change would require confirmation and agreement from the people who designed the various signal fields.
- Dave
On Sat, Mar 21, 2020 at 5:42 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
Hello Yujin,
OK, then it sounds to me as if from your implementation perspective
the bit is not reserved but "must be 1".
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: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Sent: 20 March 2020 18:37
To: Mark Rison <m.rison@xxxxxxxxxxx>; David Goodall <dave@xxxxxxxxxxxxxx>
Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: RE: CID 4137
Hi Mark,
As for 11ah at least,
the 11ah products from Newracom are implemented based on the interpretation that given CRC ok and the Reserved bit setting 0, the 11ah PPDU includes error.
Thank you.
Regards,
Yujin
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, March 20, 2020 10:20 AM
To: Yujin Noh <yujin.noh@xxxxxxxxxxxx>; David Goodall <dave@xxxxxxxxxxxxxx>
Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: RE: CID 4137
Hello Yujin,
Sure, we can open it up the reflector. In the meantime, though, what
is the intention as regards S1G PPDUs?
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: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Sent: 20 March 2020 16:42
To: Mark Rison <m.rison@xxxxxxxxxxx>; David Goodall <dave@xxxxxxxxxxxxxx>
Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: RE: CID 4137
Hi, Mark and David.
Thanks for initiating the discussion.
However it seems not right to stay “here” to keep going on because this would impact on not only 11ac and 11ah but also 11ax, 11bd and etc which are under development.
How about to put this into 11 reflector for people who are interested in this topic?
Regards,
Yujin
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, March 20, 2020 5:56 AM
To: David Goodall <dave@xxxxxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: RE: CID 4137
Hello,
I guess there's a question of what is intended.
If it's "in the future I will extend the signalling but existing devices
can just ignore it" then the bit has to be specified as ignored by the
receiver. This is the classic "reserved".
If it's "in the future I will extend the signalling but ensure that
only devices that support this extended signalling see the new value"
then it might be possible to argue that the bit can be just specified
as set to a fixed value, with the implication that the receiver could
reject the packet if the bit didn't have that value.
But in the context of a PHY header bit, since everyone gets it,
you'd want to make sure it wouldn't e.g. cause EIFS to be invoked.
Which case applies 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: David Goodall <dave@xxxxxxxxxxxxxx>
Sent: 20 March 2020 05:51
To: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Cc: M Montemurro <montemurro.michael@xxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Mark Rison <m.rison@xxxxxxxxxxx>
Subject: Re: CID 4137
Hi,
I think that Mark Rison is on the right track in saying that bits that must be set to 1 are not reserved. Why are bits in the 802.11ah and 802.11ac signal fields reserved and set to 1 in this manner?
More than one 802.11ah implementor is using these bits for additional sanity checking of signal fields so I feel obliged to follow this up or there may be interop problems later.
Thanks,
Dave
On Thu, Mar 19, 2020 at 4:56 AM Yujin Noh <yujin.noh@xxxxxxxxxxxx> wrote:
Hi,
Thanks for handling this well.
Welcome anytime if you need my assistance.
Regards,
Yujin
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, March 18, 2020 10:32 AM
To: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Cc: David Goodall <dave@xxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Mark Rison <m.rison@xxxxxxxxxxx>
Subject: Re: CID 4137
Thanks Yujin,
After looking through the minutes, the CID was assigned to Mark Rison.
I will consult with Dorothy, but if there is no agreed resolution we will work towards a rejection reason for the comment.
I really appreciate your help on resolving these S1G comments.
Cheers,
Mike
On Wed, Mar 18, 2020 at 1:07 PM Yujin Noh <yujin.noh@xxxxxxxxxxxx> wrote:
Hi Mike
Thanks for catching up this CID.
As you can see the attached, I cannot move forward without additional inputs.
The Reserved field is used in common for different amendments.
According to the e-mail attached, the similar comments were collected such that corresponding descriptions (even though no comment submitted) should be handled all together.
Regards,
Yujin
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, March 18, 2020 9:06 AM
To: Yujin Noh <yujin.noh@xxxxxxxxxxxx>; David Goodall <dave@xxxxxxxxxxxxxx>
Subject: Re: CID 4137
Sending again with the proper email for David. :-)
On Wed, Mar 18, 2020 at 12:02 PM M Montemurro <montemurro..michael@xxxxxxxxx> wrote:
Hi Yujin and David,
I was wondering if you have heard from Mark Rison regarding the following comment. The resolution discussed in TGmd was to reject the comment for the following reason (see below). Mark Rison was supposed to follow-up with both of you but I've heard nothing.
We'd like to keep moving forward with REVmd and get the comment resolved. Any comments on the resolution below? (Yujin, I believe you proposed this).
Thanks,
Mike
REVmd PHY adhoc comments for SB1
CID
Page
Clause
Duplicate of CID
Resn Status
Comment
Proposed Change
Resolution
4137
3370.00
23.3.8.2.2.5
Why is bit 0 of the SIG-1 symbol of the short preamble reserved and set to 1 rather than 0? Is it reserved for future use or is it reserved for some other reason? If it will always be the value 1 then we can use it to further verify the short preamble signal field, which is protected by a weak CRC4.
Add a note saying why b0 of the S1G-1 symbol of the short preamble is reserved.
REJECTED (PHY: 2020-02-14 15:27:30Z) - To be specific, the Reserved SIG Indication is used as one of criteria in PHY receive procedure whether the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation) in different amendments (e.g. 11ac, 11ah and 11ax) when its reserved bit set to 0.
However, not to add the note -
a proposed note is not necessary because 1) weak CRC4 is not a technical approach 2) when CRC8 is supported in 11ac, the bits are set to 1.
--
--
--
--
|
|
