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

Re: [STDS-802-11-TGBE] [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding



Thanks Yan.

 

From: Yan(msi) Zhang [mailto:yan.zhang_5@xxxxxxx]
Sent: Wednesday, September 2, 2020 3:08 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Hi Wook Bong,

 

   I think it is logical to mandate AP to set LDPC Extra Symbol Segment field to 1 when it benefits performance at AP side. Thanks for pointing it out. I will update the text.

 

Thanks

Yan

 

From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Wednesday, September 2, 2020 11:53 AM
To: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Hi Yan,

 

Thanks for your effort.

 

I have one comment on LDPC extra symbol for TB PPDU.

I know you captured the text from 11ax.

 

The AP should set the LDPC Extra Symbol Segment field in the Common Info field of the Trigger frame to 1 if the calculations described in the LDPC encoding process indicate the need for an LDPC extra symbol segment for any STA solicited by the AP for HE TB PPDU transmission using LDPC.

 

NOTE—The AP might set the LDPC Extra Symbol Segment field to 1 regardless of these calculations. The AP might select a value for the Pre-FEC Padding Factor field that differs from that derived from the calculations described in the BCC or LDPC encoding process.

 

In my opinion, set to LDPC Extra Symbol Segment field to 1 regardless of these calculation is fine. But we shall add

“AP shall set the LDPC Extra Symbol Segment field in the Common Info field of the Trigger frame to 1 if the calculations in AP indicate the need for an LDPC extra symbol segment for any STA solicited by the AP for HE TB PPDU transmission using LDPC.”

 

Otherwise, performance of a STA which requires extra symbol will be bad.

It may be bit late for 11ax, but for 11be, we can mandate this so that we can guarantee performance.

 

Best regards,

Wook Bong Lee

 

From: Yan(msi) Zhang [mailto:yan.zhang_5@xxxxxxx]
Sent: Tuesday, September 1, 2020 8:53 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Hi Yujin,

 

  I agree the bracket is not needed. But it is not wrong to have it either, right? The contents inside bracket just indicate the portion of the bits in the last segment. I am not adding m_stbc outside the bracket. I know STBC feature is removed. I can remove the bracket if you think it is more readable.

 

Thanks

Yan

 

From: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Sent: Monday, August 31, 2020 11:44 PM
To: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Caution: EXT Email

Hi Yan,

 

As for the Table, I missed the point you mentioned which is valid.

Thank you for the clarification.

 

By the way, a_init should be 3 in Eq. 34-3.11.5-11. What I intended was just to remove bracket in the Equation.

Removing mSTBC (in STBC is decided not to be supported in 11be), the bracket is not necessary anymore.

 

Regards,

Yujin

 

From: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>
Sent: Monday, August 31, 2020 8:33 PM
To: Yujin Noh <yujin.noh@xxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Hi Yujin,

 

   Thank you for your comments. I will update the document after all MCS values are finalized. a_init = 3 is typo, it should be 4.

 

   For Nsd,short for 3x996, since it is 2x996+996, if we use the 3xNsd,short for 996 tone, then the last segment is much larger than the first 3 segments, while simply adding Nsd_short for 2x996 and Nsd,short for 996, it is much more balanced among 4 segments. That’s why I choose 732 instead of 720 as Nsd_short for 3x996. Also for other MRUs, we just simply summing up the Nsd,short for corresponding RUs.

 

Thanks

Yan

 

From: Yujin Noh <yujin.noh@xxxxxxxxxxxx>
Sent: Monday, August 31, 2020 1:34 PM
To: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] RE: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Caution: EXT Email

Hi Yan,

 

Thank you for sharing the draft.

Please find my comments in attached.

 

By the way, the link below is not correct.

 

Regards,

Yujin

 

From: Yan(msi) Zhang <yan.zhang_5@xxxxxxx>
Sent: Monday, August 31, 2020 11:02 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] PDT-PHY-Data-field-Coding

 

Dear Data field Coding TTT,

 

I have uploaded the draft for Data field Coding  to the server https://mentor.ieee.org/802.11/dcn/20/11-20-1339-01-00be-pdt-phy-mathematical-description-of-signals.docx. Please review it and give your feedback.....

 

Thanks

Yan

 


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1