88w9098, set extended range in HE PHY capabilities

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

88w9098, set extended range in HE PHY capabilities

Jump to solution
2,798 Views
javadR3
Contributor III

Hi,

I need to enable HE extended range SU PPDU format. I think to achieve that, you have to enable BIT64 and BIT68 in HE PHY capabilities(correct me if I am wrong).

javadR3_0-1703074277054.png

I figure out that you can set HE PHY capabilities to any value via mlanutl(e.g I tried to set both bits to 1)

 

$ /usr/share/nxp_wireless/mlanutl r0ap0 11axcfg 11axcfg.conf
Set 11axcfg: len=55
02 ff 00 1a 00 23 01 08 00 82 00 08 04 70 7e c9 
fd 01 a0 0c 11 3d 00 fa ff fa ff e1 ff c7 71 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00

11axcfg: len=55
02 ff 00 1a 00 23 01 08 00 02 00 08 04 70 7e c9 
fd 01 a0 0c 11 3d 00 fa ff fa ff e1 ff c7 71 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00

 

 But in driver code, I see that when driver is being registered to cfg80211, these bits are masked.

woal_cfg80211_setup_he_cap function:

 

woal_request_get_fw_info(priv, MOAL_IOCTL_WAIT, &fw_info);
	if (band->band == NL80211_BAND_5GHZ) {
		phe_cap = (mlan_ds_11ax_he_capa *)fw_info.hw_he_cap;
		hw_hecap_len = fw_info.hw_hecap_len;
		woal_uap_update_11ax_ie(BAND_5GHZ, phe_cap); ---> this funtion will mask those bits
	} else {
		phe_cap = (mlan_ds_11ax_he_capa *)fw_info.hw_2g_he_cap;
		hw_hecap_len = fw_info.hw_2g_hecap_len;
		woal_uap_update_11ax_ie(BAND_2GHZ, phe_cap);
	}

 

woal_uap_update_11ax_ie function:

 

hecap_ie->he_phy_cap[7] &= UAP_HE_PHY_CAP7_MASK;
hecap_ie->he_phy_cap[8] &= UAP_HE_PHY_CAP8_MASK;

 

 

and masks are as follow:

 

/*
===============
11AX CAP for uAP
===============
Note: bits not mentioned below are set to 0.

5G
===
HE MAC Cap:
Bit0:  1  (+HTC HE Support)
Bit25: 1  (OM Control Support. But uAP does not support
	   Tx OM received from the STA, as it does not support UL OFDMA)

HE PHY Cap:
Bit1-7: 0x2 (Supported Channel Width Set.
	     Note it would be changed after 80+80 MHz is supported)
Bit8-11: 0x3 (Punctured Preamble Rx.
	      Note: it would be changed after 80+80 MHz is supported)
Bit12: 0x0 (Device Class)
Bit13: 0x1 (LDPC coding in Payload)
Bit17: 0x1 (NDP with 4xHE-LTF+3.2usGI)
Bit18: 0x1 (STBC Tx <= 80 MHz)
Bit19: 0x1 (STBC Rx <= 80 MHz)
Bit20: 0x1 (Doppler Tx)
Bit21: 0x1 (Doppler Rx)
Bit27-28: 0x1 (DCM Max Constellation Rx)
Bit31: 0x1 (SU Beamformer)
Bit32: 0x1 (SU BeamFormee)
Bit34-36: 0x7 (Beamformee STS <= 80 MHz)
Bit40-42: 0x1 (Number of Sounding Dimentions <= 80 MHz)
Bit53: 0x1 (Partial Bandwidth Extended Range)
Bit55: 0x1 (PPE Threshold Present.
	    Note: PPE threshold may have some changes later)
Bit58: 0x1 (HE SU PPDU and HE MU PPDU with 4xHE-LTF+0.8usGI)
Bit59-61: 0x1 (Max Nc)
Bit75: 0x1 (Rx 1024-QAM Support < 242-tone RU)
*/

#define UAP_HE_MAC_CAP0_MASK 0x00
#define UAP_HE_MAC_CAP1_MASK 0x00
#define UAP_HE_MAC_CAP2_MASK 0x00
#define UAP_HE_MAC_CAP3_MASK 0x02
#define UAP_HE_MAC_CAP4_MASK 0x00
#define UAP_HE_MAC_CAP5_MASK 0x00
#define UAP_HE_PHY_CAP0_MASK 0x04
#define UAP_HE_PHY_CAP1_MASK 0x23
#define UAP_HE_PHY_CAP2_MASK 0x3E
#define UAP_HE_PHY_CAP3_MASK 0x88
#define UAP_HE_PHY_CAP4_MASK 0x1D
#define UAP_HE_PHY_CAP5_MASK 0x01
#define UAP_HE_PHY_CAP6_MASK 0xA0
#define UAP_HE_PHY_CAP7_MASK 0x0C
#define UAP_HE_PHY_CAP8_MASK 0x00
#define UAP_HE_PHY_CAP9_MASK 0x08
#define UAP_HE_PHY_CAP10_MASK 0x00

 

My question is why this masking has been done? Does that mean firmware does not support extended range format?

if yes, why are we able to set any value via mlanutl?

 

Regards,

Javad

Labels (1)
0 Kudos
Reply
1 Solution
2,394 Views
javadR3
Contributor III

Hi @ocourson,

I thought HE capability should be same for all interfaces(mlan0, uap0), because it is radio-specific, but interestingly we realized that interfaces can have different HE capabilities(for example you can have ER set for mlan0 but not set for uap0).

We are using hostapd for starting AP and wpa_supplicant for starting STA. Fortunately wpa_supplicant(default build) unlike hostapd, doesn't change HE capabilities.

We are only interested to support ER in STA mode, so all we need is to setthose bits via IOCTL command before starting a STA.

 

Regards,

Javad

View solution in original post

0 Kudos
Reply
7 Replies
2,734 Views
ocourson
NXP TechSupport
NXP TechSupport

Dear @javadR3 

 

I am not sure if the 88W9098 FP68 specific SW you are using is supporting HE extended range feature, I am checking that internally.

 

But for sure the generic FP92 SW available on github is supporting that feature.

 

Here is the test I did, with this setup:

- i.MX8MQ Linux 6.1.36

- 88W9098 base Azurewave AW-XM458-MA module, with PCIE9098--17.92.1.p136.131-MM6X17408.p2-GPL-(FP92) SW

- default wifi_mod_para.conf driver parameters (see attached file)

- using 88W9098 as STA (see attached wpa_supplicant.conf file)

 

By default HE extended range is not enabled, as we can see in the probe requests:

default-HE cap.png

 

I stopped mlan0 interface, changed 11ax config using the attached 11axcfg.conf file:

mlanutl 11axcfg config/11axcfg.conf

Then started mlan0 interface; we can see the HE extended range is enabled:

HE cap - ext range.png

0 Kudos
Reply
2,702 Views
ocourson
NXP TechSupport
NXP TechSupport

Dear @javadR3 

 

I also tested that HE extended range can be enabled on PCIE9098--17.68.1.p136.58-MXM5X17366.p32-GPL, with the same procedure.

 

Regards,

Olivier

0 Kudos
Reply
2,664 Views
javadR3
Contributor III

Hi @ocourson,

thank you for testing, but you have tested in STA mode. Could you repeat your test in AP mode and see HE capabilities in propagated beacon packets?

In that case you would see the problem.

 I believe driver is doing differently in case of STA and AP. I mean if you run a STA, driver doesn’t change pre-set HE capabilities via mlanutil.

Or you can change HE capabilities via mlanutil and then query them via netlink(iw phy). You would see that they are not same.

0 Kudos
Reply
2,491 Views
ocourson
NXP TechSupport
NXP TechSupport

Dear @javadR3 

It seems we do support partial ER (please see below reference snippet from captures on beacons), that's why that bit is enabled and we already verified we can transmit and receive in 106 RU tone.
Sniffer reference for beacon:

partial-er.jpg

Regards,

Olivier

0 Kudos
Reply
2,395 Views
javadR3
Contributor III

Hi @ocourson,

I thought HE capability should be same for all interfaces(mlan0, uap0), because it is radio-specific, but interestingly we realized that interfaces can have different HE capabilities(for example you can have ER set for mlan0 but not set for uap0).

We are using hostapd for starting AP and wpa_supplicant for starting STA. Fortunately wpa_supplicant(default build) unlike hostapd, doesn't change HE capabilities.

We are only interested to support ER in STA mode, so all we need is to setthose bits via IOCTL command before starting a STA.

 

Regards,

Javad

0 Kudos
Reply
2,772 Views
javadR3
Contributor III

Hi @ocourson,

 

1, 2: custom yoco linux, using IMX8 as processor

3:  

 

 

$ /usr/share/nxp_wireless/mlanutl r0ap0 version             
Version string received: PCIE9098--17.68.1.p136.58-MXM5X17366.p32-GPL-(FP68)-dbg 

 

 

 

4:

 

 

sudo insmod mlan-dbg.ko
sudo insmod moal-dbg.ko mod_para=nxp/wifi_mod_para.conf

 

 

attached wifi_mod_para.conf(renamed file because .conf was not allowed to be attached).

BTW, I don't think the problem would be related to any requested info.

Regards,

Javad

0 Kudos
Reply
2,779 Views
ocourson
NXP TechSupport
NXP TechSupport

Dear @javadR3 

 

Can you please confirm you setup ?

1/ host used

2/ host OS and version

3/ wifi SW version (driver and firmware)

4/ commands used to initialise the wifi driver

 

Regards,

Olivier

0 Kudos
Reply