Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGM] Fwd: CID 4137

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

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

 

From: David Goodall <dave@xxxxxxxxxxxxxx>
Sent: Thursday, 16 July 2020 21:59
To: M Montemurro <montemurro.michael@xxxxxxxxx>
Cc: Mark Rison <m.rison@xxxxxxxxxxx>; stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] Fwd: CID 4137

 

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.

 

Thanks,

Dave

 

 

 

 

On Fri, Jul 10, 2020 at 11:06 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

+Adding the reflector again.

 

Thanks Mark,

 

We'll discuss your proposal and the way forward on the July 15 teleconference.

 

Cheers,

 

Mike

 

On Fri, Jul 10, 2020 at 5:54 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, 9 July 2020 19:45
To: David Goodall <dave@xxxxxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>; 'mark.hamilton2152@xxxxxxxxx' <mark.hamilton2152@xxxxxxxxx>; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>; Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Fwd: CID 4137

 

Adding the reflector.

 

Mark,

 

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

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, July 9, 2020 11:32:50 AM
To: M Montemurro <montemurro.michael@xxxxxxxxx>; David Goodall <dave@xxxxxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>; 'mark.hamilton2152@xxxxxxxxx' <mark.hamilton2152@xxxxxxxxx>; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGM] Fwd: CID 4137

 

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

 

From: Mark Rison
Sent: Monday, 29 June 2020 22:29
To: 'M Montemurro' <montemurro.michael@xxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; 'David Goodall' <dave@xxxxxxxxxxxxxx>; Yujin Noh <yujin.noh@xxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx; Jong-ee Oh <jongee.oh@xxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGM] Fwd: CID 4137

 

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

 

From: ***** 802.11 REVm - Revision Maintainance List ***** <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx> On Behalf Of M Montemurro
Sent: Monday, 29 June 2020 21:27
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Fwd: CID 4137

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

 

---------- Forwarded message ---------
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.

 



--

Dave Goodall

Morse Micro

 

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwMzIwMTI1NjM4ZXVjYXMxcDFlNTUzYjE5OTIyY2M0ZmNkODQ5OTIwODA0MTkzZDRmZiZyZWNpcGllbnRBZGRyZXNzPXl1amluLm5vaEBuZXdyYWNvbS5jb20_

 

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwMzIwMTcyMDQ3ZXVjYXMxcDFmZWY1ZGQ1NTZjMDBhNWI0NGQ5YzAwMWQ5MGY5NzdmZiZyZWNpcGllbnRBZGRyZXNzPXl1amluLm5vaEBuZXdyYWNvbS5jb20_

 

 

  

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwMzIwMTg0MjE5ZXVjYXMxcDFlMTExNWM2ZGIxZTcwMDM2NDY5YjhjNzhiYzdmNWQxOSZyZWNpcGllbnRBZGRyZXNzPWRhdmVAbW9yc2VtaWNyby5jb20_



--

Dave Goodall

Morse Micro

 

 

  

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwMzIzMTIxMjU0ZXVjYXMxcDFhZDU2ZmE4OGU4OWE1MDk4N2E0MzQ4ZWE1YmYwZTM4MiZyZWNpcGllbnRBZGRyZXNzPWRhdmVAbW9yc2VtaWNyby5jb20_



--

Dave Goodall

Morse Micro



--

Dave Goodall

Morse Micro

 

 

  

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwNTE1MDYyMTIzZXVjYXMxcDJkMmZiNGVkNWQ0NDg5ZTViN2RhNzQ2YzAzNWNkNWY5NyZyZWNpcGllbnRBZGRyZXNzPW1vbnRlbXVycm8ubWljaGFlbEBnbWFpbC5jb20_

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

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwNzA5MTUzMjU3ZXVjYXMxcDE1ZWIwYWU0ZWZlOGMzOWVjODAwNjEyNzM3YjFkYWJkNSZyZWNpcGllbnRBZGRyZXNzPW1vbnRlbXVycm8ubWljaGFlbEBHTUFJTC5DT00_

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjAwNzEwMDk1NDAyZXVjYXMxcDE1NGU1MGQzZTdhMTFhMWYwM2E1YjU1Mjk2Njk5MzAyMiZyZWNpcGllbnRBZGRyZXNzPW1vbnRlbXVycm8ubWljaGFlbEBnbWFpbC5jb20_



--

Dave Goodall

Morse Micro

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