--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello, Mark.
Continuing our discussion during the TGmd call today, here is the updated proposed resolution.
|
Comment:
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.
|
|
Proposed Change (by the commenter):
Add a note saying why b0 of the S1G-1 symbol of the short preamble is reserved.
|
|
Resolution:
Revised
Note to Commenter:
23.3.19 (PHY receive procedure) clearly states that S1G STAs “shall maintain PHY-CCA.inditation(BUSY, channel-list) for the predicted duration of the transmitted PPDU … for
all … Reserved SIG or SIG-A Indication” (D3.3 P3434L28). This allows future 802.11 amendment(s) to set the reserved bit to the ‘other’ value (0 in this case), and S1G STAs will defer for the duration of that ‘new’ PPDU and not interfere with it. This allows
S1G and future amendment STA to successfully coexist, and thus is a ‘reserved’ bit (reserved for future use).
The reserved bit is set to the value 1 because the SIG field is not scrambled, hence could have a long string of contiguous 0 bits, which could lead to high PAPR of the SIG
symbol. Hence, reserved bits in PHY preamble are typically set to 1 to avoid such occurrence of long string of 0 bits.
During the review of the comment, however, it was found that “Reserved SIG-B Indication” at REVmd D3.4 P3442.8 is not defined. While the comment was on short preamble, and
SIG-B exists only for long preamble, this is deemed an error worth correcting. The instruction to editor below defines that term.
Instruction to Editor:
Add the following sentence at REVmd D3.4 P3442L8.
“Reserved SIG-B Indication is defined as a SIG-B with any of the Reserved bits equal to 0 or MCS not included in 23.5 (Parameters for S1G-MCSs).”
|
Regards,
Youhan
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Monday, July 20, 2020 12:56 AM
To: Youhan Kim <youhank@xxxxxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: dave@xxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] Fwd: CID 4137
CAUTION: This email
originated from outside of the organization.
Thanks for your suggestion, Youhan.
Resolution:
Rejected
23.3.19 (PHY receive procedure) clearly states that S1G STAs “shall maintain PHY-CCA.inditation(BUSY, channel-list) for the predicted
duration of the transmitted PPDU … for all … Reserved SIG or SIG-A Indication” (D3.3 P3434L28). This allows future 802.11 amendment(s) to set the reserved bit to the ‘other’ value (0 in this case), and S1G STAs will defer for the duration of that ‘new’ PPDU
and not interfere with it. This allows S1G and future amendment STA to successfully coexist, and thus is a ‘reserved’ bit (reserved for future use).
Hm, so you think it's a "reserved" bit in MAC terminology, but a
few lines down (D3.4/3440.55) it says:
If the SIG or SIG-A indicates an invalid CRC or Reserved SIG or
SIG-A Indication, the PHY shall issue the error condition PHY-RXEND.indication(FormatViolation).
So, which is it? It sounds as if this bit is not a "reserved" bit
in MAC terminology after all. Sounds as if there *is* confusion?
[YK] No, I didn’t say that ‘reserved’ was a MAC terminology. What I said was that, yes, MAC designates value 0 for Reserved bits/fields, but there
is no need for PHY to follow that convention (of using value 0). I also wrote in the resolution reason that there is no confusion as the RX procedure describes what the RX behaviour is for the reserved bits.
Also, you say:
PHY Receive Procedure sections in each PHY clauses describes the behavior on the RX side based on the setting of the reserved PHY preamble fields
but at D3.4/3442.8 there is a reference to "Reserved SIG-B Indication",
which I cannot find defined anywhere. So are the bits currently shown
as "Reserved" in Table 23-16—Fields in the SIG-B field for MU PPDU
actually reserved (i.e. ignored on rx) or are they actually fixed
(i.e. can/should be checked on rx)?
[YK] Please see the updated resolution.
Incidentally,
change the name of preamble field names of published PHY standards which may cause confusion to billions of devices already deployed
seems specious to me. I don't think deployed devices will consult
802.11-2020 before responding to PPDUs. Indeed, that's exactly why
we have reserved bits, so that the standard can evolve without breaking
deployed devices.
[YK]
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi.
I do not support changing the name of ‘Reserved’ bits in the PHY preambles. PHY Receive Procedure sections in each PHY clauses describes the behavior on the RX side based
on the setting of the reserved PHY preamble fields, and there is no technical reason at this point to change the name of preamble field names of published PHY standards which may cause confusion to billions of devices already deployed based on the published
standards. Furthermore, I see no reason why PHY reserved bit definition needs to be aligned with that of the MAC.
My suggested resolution to CID 4137 is the following.
|
Comment:
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.
|
|
Proposed Change (by the commenter):
Add a note saying why b0 of the S1G-1 symbol of the short preamble is reserved.
|
|
Resolution:
Rejected
23.3.19 (PHY receive procedure) clearly states that S1G STAs “shall maintain PHY-CCA.inditation(BUSY, channel-list) for the predicted duration of the transmitted PPDU … for
all … Reserved SIG or SIG-A Indication” (D3.3 P3434L28). This allows future 802.11 amendment(s) to set the reserved bit to the ‘other’ value (0 in this case), and S1G STAs will defer for the duration of that ‘new’ PPDU and not interfere with it. This allows
S1G and future amendment STA to successfully coexist, and thus is a ‘reserved’ bit (reserved for future use).
The reserved bit is set to the value 1 because the SIG field is not scrambled, hence could have a long string of contiguous 0 bits, which could lead to high PAPR of the SIG
symbol. Hence, reserved bits in PHY preamble are typically set to 1 to avoid such occurrence of long string of 0 bits.
|
Regards,
Youhan
CAUTION: This email
originated from outside of the organization.
Thanks for these thoughts, David.
As the commenter for 4137 I am ok with rejection of the comment because I now understand the mechanism, i.e. when the particular bit referenced in the comment is not 1 then the receiver
raises a FormatViolation. More than one current implementer of 802.11ah had raised that question, which is why the comment was made.
But this is the whole point: the spec is not for people who already
understand the intent (they don't need a spec!), it's for people who
want to understand the intent. The confusion you and the other
implementers you refer to faced is one that should be addressed in
the spec wording.
Also note that the current spec is technically broken, since it
uses but does not define "Reserved SIG-B Indication" (at D3.4/3442.8).
The reserved bit in the 802.11a PHY header is not assigned a value by the specification that I could see (see Section 17.3.2.1 General) so it is apparently only by convention that
it is set to zero.
I think it is specified to be zero, although it's not trivial to find
because it's often referred to as the R bit or by its position.
The location is:
17.3.4.4 Parity (P), Reserved (R), and SIGNAL TAIL fields
Bit 4 is reserved. It shall be set to 0 on transmit and ignored on receive.
There's also:
17.3.4.1 General
Bit 4 shall be reserved for future use.
However, note that this means I was wrong: the spec
does say that this
bit should be ignored on rx for the OFDM PHY, so it really is a reserved bit,
not a fixed bit.
Having said that, I think that many vendors' implementations do check
this bit and use it to shore up the P(arity) bit, so it would be better
not to require it to be ignored on rx. Especially since I think that
for the HT PHY and VHT PHYs bit 4 of what they call L-SIG is not specified
to be ignored on receive (see 19.3.9.3.5 L-SIG definition and
21.3.8.2.4 L-SIG definition).
I would raise separate comments for 802.11me for items 1 and 2 rather than attempting to resolve them in 802.11md.
I see no reason to wait until D4.0, let alone REVme, now that the issue
has been identified and the changes identified (OK, so I'll need an r8
for the above).
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
I won't be able to make the next 802.11md call. Since Graham asked what the commenter's opinion was on the July 15 call in the chat window I have added my thoughts below.
As the commenter for 4137 I am ok with rejection of the comment because I now understand the mechanism, i.e. when the particular bit referenced in the comment is not 1 then the receiver
raises a FormatViolation. More than one current implementer of 802.11ah had raised that question, which is why the comment was made.
The discussion of 4137 has raised two further issues which I feel are out of scope of the original comment:
1. The understanding of a reserved bit or field in the MAC parts of 802.11 is that it may change in future. From the discussion on the last 802.11md call the use of the term reserved
in the PHY appears now to be different from the usage in the MAC. That raises the question of how to reserve bits or fields in the PHY for future use. Given that aspects of MAC are now included in PHY fields, for example NDPs and NDP CMAC frames, there needs
to be a consistent understanding of what reserved means.
2. For the original Clause 17 PHY (802.11a), experienced implementers know to check that certain bits are zero on receive. These bits are defined as reserved but there is no requirement
to raise a FormatViolation if the bits are not found to be zero when received. The reserved bit in the 802.11a PHY header is not assigned a value by the specification that I could see (see Section 17.3.2.1 General) so it is apparently only by convention that
it is set to zero. Note that the reserved bits in the 802.11a service field are set to zero and ignored on receive (see Section 17.3.5.2 SERVICE field) so presumably the original understanding of reserved was the same in the Clause 17 PHY as generally for
the MAC.
I would raise separate comments for 802.11me for items 1 and 2 rather than attempting to resolve them in 802.11md.
+Adding the reflector again.
We'll discuss your proposal and the way forward on the July 15 teleconference.
OK, having examined the (updated) minutes 20/0956, the chronology is apparently:
- 2020-06-29: proposal to reject comment; I objected; comment was reassigned to me
- 2020-06-29: I made an initial suggestion on the reflector
- 2020-06-30: I briefly presented a more detailed suggestion
- Scheduled for further discussion on 2020-07-15
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
Adding the reflector.
We originally presented a resolution of no changes required on the call last week based on
discussions with S1G folks.
Based on the discussion, you agreed to propose a set of changes to address the comment. I
believe we scheduled an agenda item but I can't remember when that was.
Cheers,
Mike
Hello,
Can you remind me where we are with this one? I think I presented briefly
in some teleconf but I guess we need to go through it again? My current
proposal is (I found a typo which is fixed below (and will be fixed in r7)):
|
Identifiers
|
Comment
|
Proposed change
|
|
CID 4137
David Goodall
23.3.8.2.2.5
3370.6
|
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.
|
Discussion:
As the commenter indicates, the intent of reserved fields is to allow for forward compatibility: new information can be signalled in the field in the future, but existing implementations will be unaffected as they are directed to ignore
it. This is distinct from fields that have a fixed value, that existing implementations are directed to validate.
There is a tricky case for b4 of the OFDM PHY SIGNAL field (often referred to as “L-SIG” in PHYs that build on it). This is described as reserved, but implementations are known to validate it as a means to strengthen the poor validation
offered by the single parity bit (b17). So this bit should be described as fixed, but should not explicitly be stated to be validated by the receiver. Note that the situation is different for the SERVICE field, where it is explicitly stated that “All reserved
bits shall be set to 0 on transmission and ignored on reception.”, i.e. the canonical definition of reserved bits.
Similarly DMG uses the canonical definition (“Reserved bits are set to 0 by the transmitter and shall be ignored by the receiver.” in 20.4.3.2.1 General and 20.5.3.1.1 General) as do CDMG and CMMG.
The status of the “Reserved” bit in the SERVICE field for VHT is not clear: it is specified to be set to 0 in Table 21-16—SERVICE field but not specified to be validated on receive. Ditto for the “Reserved” bits in VHT-SIG-B. [The wording
is “Reserved VHT-SIG-A Indication is defined as a VHT-SIG-A with Reserved bits equal to 0”.]
Proposed changes:
In D3.0:
[Clause 23 = S1G]
In 23.3.4.2.3 Construction of SIG-A and 23.3.4.2.6 Construction of SIG-B and 23.3.4.3.3 Construction of SIG and 23.3.4.4.3 Construction of 1 MHz SIG change “the reserved bits” to “the fixed bits”.
In Figure 23-7—SIG-1 structure change “Reserved” (vertical, under B0) to “Fixed”.
In Table 23-11—Fields in the SIG field of short preamble, at 3370.6
change "Reserved" / "Reserved. Set to 1." to "Fixed" / "Set to 1".
In Figure 23-12—SIG-A2 structure for SU PPDU change “Reserved” (vertical, under B12) to “Fixed”.
In Figure 23-13—SIG-A1 structure for MU PPDU change “Reserved” (vertical, under B2) to “Fixed”.
In Figure 23-14—SIG-A2 structure for MU PPDU change “Reserved” (vertical, under B1) to “Fixed”.
In Table 23-13—Fields in the SIG-A field of S1G_LONG preamble SU PPDU, at 3378.25
change "Reserved" / "Reserved. Bit set to 1." to "Fixed" / "Set to 1".
In Table 23-14—Fields in the SIG-A field of S1G_LONG preamble MU PPDU, at 3379.9 and 3380.10
change "Reserved" / "Reserved. Bit set to 1." to "Fixed" / "Set to 1"
and in the row for B20-23 at 3379.36 change “is reserved” to “is fixed” (4x).
In Table 23-16—Fields in the SIG-B field for MU PPDU change “Reserved” to “Fixed”.
In 23.3.8.2.3.3.6 CRC calculation for SIG SIG-B field change “Reserved field” to “Fixed field” (2x).
In Figure 23-16—Structure of the 6 symbol SIG field of S1G_1M PPDU change “Reserved” to “Fixed” (vertical, under B6).
In Table 23-18—Fields in the SIG field of S1G_1M PPDU, at 3391.6
change "Reserved" / "Reserved. Set to 1." to "Fixed" / "Set to 1".
In Table 23-19—SERVICE field change “Reserved” to “Fixed”.
In 23.3.19 PHY receive procedure (at 3434.39) change "Reserved bits equal to 0" to "any Fixed field equal to 0".
and at the end of the para at 3436.1 add “Invalid SIG-B Indication is defined as a SIG-B with the Fixed field not all-1s or an S1G-MCS not included in 23.5 (Parameters for S1G-MCSs).”
At 3434.30 change “Reserved SIG or SIG-A Indication” to “Invalid SIG or SIG-A Indication”. At 3434.37 change “Reserved SIG-A Indication” to “Invalid SIG-A Indication”. At 3434.39 change “Reserved SIG or SIG-A Indication” to “Invalid
SIG or SIG-A Indication” and “an SIG” to “a SIG”. At 3434.55 change “Reserved SIG or SIG-A Indication” to “Invalid SIG or SIG-A Indication”.
[Clause 17 = OFDM]
In 17.3.2.1 General change “reserved bit” to “fixed bit” (2x).
In Figure 17-1—PPDU format, Figure 17-18—PHY transmit state machine, Figure 17-19—Receive PHY, change “Reserved” to “Fixed”.
[Clause 19 = HT]
In 19.3.9.3.5 L-SIG definition change “reserved bit” to “fixed bit”.
In Figure 19-5—L-SIG structure change “R” to “F” above “4”.
In Table 19-11—HT-SIG fields (at 3015.41) change "Reserved" to "Fixed".
In Figure 19-6—Format of HT-SIG1 and HT-SIG2 change “Reserved” to “Fixed” (above “2” in HT-SIG2).
In 19.3.21 PHY receive procedure (at 3072.40) change "Reserved field = 0" to "Fixed field = 0".
Change “Reserved HT-SIG Indication” to “Invalid HT-SIG Indication” at 3072.18 (2x), 3072.24, 3072.27, 3072.33 (2x), 3072.36, 3072.39, 3072.64.
[Clause 21 = VHT]
In 21.3.4.5 Construction of VHT-SIG-A and 21.3.4.8 Construction of VHT-SIG-B change “the reserved bits” to “the fixed bits”.
In 21.3.8.2.4 L-SIG definition change “The Reserved (R) field” to “The Fixed (F) field”.
In Figure 21-18—VHT-SIG-A1 structure change “Reserved” (2x vertical under B2 and B23) to “Fixed”.
In Figure 21-19—VHT-SIG-A2 structure change “Reserved” (3x inc. 1x vertical under B9) to “Fixed”.
In Table 21-12—Fields in the VHT-SIG-A field
change “Reserved” / “Reserved. Set to 1.” to “Fixed” / “Set to 1” at 3190.10
and change “The bit is reserved and set to 1” to “The bit is fixed and set to 1” at 3190.58
and change “Reserved” to “Fixed” at 3190.61
and change “this field is reserved and set to 1” to “this field is fixed and set to 1” at 3191.19
and change “is reserved and set to 1” to “is fixed and set to 1” (4x) in the row for B4-B7 at 3191.28
and change “Reserved and set to 1” to “Fixed and set to 1” at 3191.49
and change “Reserved” / “Reserved and set to 1” to “Fixed” / “Set to 1” at 3191.52.
In Table 21-14—Fields in the VHT-SIG-B field change “Reserved” to “Fixed”.
In Table 21-16—SERVICE field and Figure 21-23—VHT-SIG-B and SERVICE field relationship change “Reserved” to “Fixed”.
In 21.3.20 PHY receive procedure (at 3246.12) change "Reserved bits equal to 0" to "any Fixed field equal to 0".
Change “Reserved VHT-SIG-A Indication” to “Invalid VHT-SIG-A Indication” at 3246.9/10/19.
Proposed resolution:
REVISED
Make the changes shown under “Proposed changes” for CID 4137 in <this document>, which make a distinction between reserved fields, which are ignored by the receiver, and fixed fields, which are checked by the receiver and typically cause
the PPDU to be rejected if they do not have the expected value.
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
OK, so here's my suggestion:
In D3.0:
In Table 23-11—Fields in the SIG field of short preamble, at 3370.6
change "Reserved" / "Reserved. Set to 1." to "Fixed" / "Set to 1".
Ditto in Table 23-14—Fields in the SIG-A field of S1G_LONG preamble MU PPDU, at 3379.9 and 3380.10.
Ditto in Table 23-18—Fields in the SIG field of S1G_1M PPDU, at 3391.6.
At 3434.39 change "Reserved bits equal to 0" to "any Fixed field equal to 0".
In Table 19-11—HT-SIG fields, at 3015.41, change "Reserved" to "Fixed".
At 3072.40 change "Reserved field = 0" to "Fixed field = 0".
In Table 21-12—Fields in the VHT-SIG-A field, at 3190.10
change "Reserved. Set to 1." to "Set to 1".
At 3246.12 change "Reserved bits equal to 0" to "any Fixed field equal to 0"
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
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
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
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.
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.
>> 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
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
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.
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
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
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
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
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
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.
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.
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. :-)
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).
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.
|
--
--
--
--
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
--
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
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
|