AnsweredAssumed Answered

Bug report: 802.11ac with LDPC

Question asked by hmc on Feb 21, 2018
Latest reply on Jun 1, 2018 by jonathan.falco

Like • Show 0 Likes0
Comment • 8

I have a N5182B signal generator with a WiFi licence, allowing me to generate WiFi packets using N7617B Signal Studio for Wireless LAN (latest version 3.4.0.0).

I believe there is a bug affecting many configurations of 802.11ac with LDPC encoding. More specifically, it appears that under certain configurations, an insufficient number of OFDM symbols is generated (1 fewer than is suggested by the 802.11ac standard, according to my interpretation). I have attached a WLAN configuration file which I believe reproduces the issue (Note: changing Data Length from 64 to 65 or 66 seems to produce valid packets).

My other main point of reference is Matlab's WLAN toolbox. Out of the box, their implementation is incorrect, but after a series of communications with Mathworks, three bugs have been fixed and I now agree with their interpretation of the 802.11ac standard (i.e. for the attached configuration, their transmissions would contain one extra OFDM symbol).

I know the procedure for determining the number of OFDM symbols in LDPC packets is slightly convoluted (and in 802.11ac there is an extra flag in the VHT-SIG whose role I may have misinterpreted). Therefore, I would greatly appreciate any assistance in establishing what the correct behaviour should be.

Many thanks in advance.

Harry

jonathan.falco

Jun 1, 2018 9:14 AM

Correct Answer

Hello,

After further testing and analysis, we think N7617 software correctly generated 33 data symbols (not 32 symbols as reported). Please see the attached .scp file.

We played back the 802.11ac waveform on a MXG, and measure it with 89600 VSA software connected to a MXA.

From the 89600 screen capture, the time length between the two markers (marked about at the edges of the RF burst) are 131.875 + 39.875 = 171.75us.
From the N7617 screen capture, what was shown/generated in N7617 is 33symbols (172us).

Thank you for your patience,

Jonathan

See the reply in context

Attachments

802.11ac LDPC bug.scp.zip3.1 KB

No one else had this question

Outcomes

hmc Feb 22, 2018 12:09 AM

Is this even a suitable place to report a bug? I couldn't find any way to contact Keysight directly.

Would it be useful for me to provide more details? If it helps, I can provide all the numbers involved in the calculation of the number of OFDM symbols.

Actions

jonathan.falco

@ hmc on Mar 14, 2018 11:07 AM

Hello Harry,

I am following up on this and I'll let you know what happens.

Thank you!

Jonathan

1 person found this helpful

Actions

jonathan.falco

Mar 22, 2018 10:10 AM

Hello Harry,

According to chapter 21.3.10.5.4 of Draft P802.11revMD_D1.0, the Nsym,init is 32 symbols, and the final symbols is 33 with 1 extra symbol.

The following is the calculation details when setting the Data Length to 64 Bytes:
APEP_LENGTH = 102 * 8 (Length of A-MPDU)
Nservice = 16
MSTBC = 1
NDBPS = 26

therefore
Nsym,init = 32

Are there any differences in the parameters or calculation formulas we used from what you used?

Hope this helps!

Jonathan

4 people found this helpful

Actions

hmc @ jonathan.falco on Mar 22, 2018 1:41 PM

Yes, I think that describes the bug exactly. The total number of OFDM symbols should be 33, but only 32 are transmitted.

Actions

jonathan.falco

@ hmc on Mar 23, 2018 12:12 PM

Hello Harry,

I will continue to follow up with this.

Meanwhile, if this is urgent for you, go to Contact an Expert: Signal Studio Software | Keysight and call the toll free number. There we can better assist you, rather than just back and fourth on the forums.

Jonathan

1 person found this helpful

Actions

jonathan.falco

Apr 4, 2018 7:53 AM

Hello Harry,

Just wanted to give you an update. I have been in communication with some coworkers from all around the world. They are aware of the issue as someone else has reported a similar issue.

We will do further investigation for the problem and get back to you with findings/comments.

Thank you,

Jonathan

Actions

jonathan.falco

@ jonathan.falco on Jun 1, 2018 9:14 AM

Hello,

After further testing and analysis, we think N7617 software correctly generated 33 data symbols (not 32 symbols as reported). Please see the attached .scp file.

We played back the 802.11ac waveform on a MXG, and measure it with 89600 VSA software connected to a MXA.

From the 89600 screen capture, the time length between the two markers (marked about at the edges of the RF burst) are 131.875 + 39.875 = 171.75us.
From the N7617 screen capture, what was shown/generated in N7617 is 33symbols (172us).

Thank you for your patience,

Jonathan

Attachments

802.11ac LDPC test.scp.zip3.1 KB

1 person found this helpful

Actions

hmc May 23, 2018 7:39 AM

It is confusing that this question keeps getting marked as "ASSUMED ANSWERED", when it clearly hasn't been.

Actions

8 Replies

hmc Feb 22, 2018 12:09 AM
Mark Correct
Correct Answer
Is this even a suitable place to report a bug? I couldn't find any way to contact Keysight directly.

Would it be useful for me to provide more details? If it helps, I can provide all the numbers involved in the calculation of the number of OFDM symbols.
Like • Show 0 Likes0
Actions
- jonathan.falco @ hmc on Mar 14, 2018 11:07 AM
  Mark Correct
  Correct Answer
  Hello Harry,
  
  I am following up on this and I'll let you know what happens.
  
  Thank you!
  Jonathan
  1 person found this helpful
  Like • Show 2 Likes2
  Actions
jonathan.falco Mar 22, 2018 10:10 AM
Mark Correct
Correct Answer
Hello Harry,

According to chapter 21.3.10.5.4 of Draft P802.11revMD_D1.0, the Nsym,init is 32 symbols, and the final symbols is 33 with 1 extra symbol.

The following is the calculation details when setting the Data Length to 64 Bytes:
APEP_LENGTH = 102 * 8 (Length of A-MPDU)
Nservice = 16
MSTBC = 1
NDBPS = 26
therefore
Nsym,init = 32
Are there any differences in the parameters or calculation formulas we used from what you used?

Hope this helps!
Jonathan
4 people found this helpful
Like • Show 4 Likes4
Actions
- hmc @ jonathan.falco on Mar 22, 2018 1:41 PM
  Mark Correct
  Correct Answer
  Yes, I think that describes the bug exactly. The total number of OFDM symbols should be 33, but only 32 are transmitted.
  Like • Show 0 Likes0
  Actions
  - jonathan.falco @ hmc on Mar 23, 2018 12:12 PM
    Mark Correct
    Correct Answer
    Hello Harry,
    
    I will continue to follow up with this.
    
    Meanwhile, if this is urgent for you, go to Contact an Expert: Signal Studio Software | Keysight and call the toll free number. There we can better assist you, rather than just back and fourth on the forums.
    
    Jonathan
    1 person found this helpful
    Like • Show 1 Like1
    Actions
jonathan.falco Apr 4, 2018 7:53 AM
Mark Correct
Correct Answer
Hello Harry,

Just wanted to give you an update. I have been in communication with some coworkers from all around the world. They are aware of the issue as someone else has reported a similar issue.

We will do further investigation for the problem and get back to you with findings/comments.

Thank you,
Jonathan
Like • Show 0 Likes0
Actions
- jonathan.falco @ jonathan.falco on Jun 1, 2018 9:14 AM
  Unmark Correct
  Correct Answer
  Hello,
  
  After further testing and analysis, we think N7617 software correctly generated 33 data symbols (not 32 symbols as reported). Please see the attached .scp file.
  
  We played back the 802.11ac waveform on a MXG, and measure it with 89600 VSA software connected to a MXA.
  From the 89600 screen capture, the time length between the two markers (marked about at the edges of the RF burst) are 131.875 + 39.875 = 171.75us.
  From the N7617 screen capture, what was shown/generated in N7617 is 33symbols (172us).
  
  Thank you for your patience,
  
  Jonathan
  Attachments
  - 802.11ac LDPC test.scp.zip3.1 KB
  1 person found this helpful
  Like • Show 1 Like1
  Actions
hmc May 23, 2018 7:39 AM
Mark Correct
Correct Answer
It is confusing that this question keeps getting marked as "ASSUMED ANSWERED", when it clearly hasn't been.
Like • Show 0 Likes0
Actions

Bug report: 802.11ac with LDPC

Attachments

Outcomes

Attachments

Related Content

Recommended Content