WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Jan-09 01:34:26

Tomi
Member
Registered: 2014-Oct-17
Posts: 58

about wlan_low_nomac

wlan_mac_802_11_defs.h contains definitions of 802.11 packets that are required by both the upper and lower level CPUs.

Basically, there are three types of packets: management, control, an data.
For mac_low_dcf, all three types of packets are included.
Then how about mac_low_nomac? Are all three types of packets are supported, or only data packet is supported here?

I checked the frame_transmit() in wlan_mac_dcf.c:
tx_frame_info* mpdu_info = (tx_frame_info*) (TX_PKT_BUF_TO_ADDR(pkt_buf));    mac_header_80211* header = (mac_header_80211*)(TX_PKT_BUF_TO_ADDR(pkt_buf) + PHY_TX_PKT_BUF_MPDU_OFFSET);

in wlan_mac_nomac.c:
tx_frame_info* mpdu_info = (tx_frame_info*) (TX_PKT_BUF_TO_ADDR(pkt_buf));

It seems there is no mac_header_80211 in NOMAC mode. Then how can I know the type of packet transmitted in NOMAC mode?

Because in mac_low_dcf, I used following sentences to enable/disable jumboTX/RX mode:

***************************************************************************
if((header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
     REG_SET_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN); //Enable JumboTx
} else{
     REG_CLEAR_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN);
}

if((rx_header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
    REG_SET_BITS(WLAN_RX_REG_JUMBO, WLAN_RX_REG_JUMBO_EN);//Enable JumboRx
} else{
    REG_CLEAR_BITS(WLAN_RX_REG_JUMBO, WLAN_RX_REG_JUMBO_EN);//Disable JumboRx
}
***************************************************************************

In mac_low_nomac, how can I distinguish the data message with other types of messages, as there is no mac_header_80211?
I want to enable/disable jumboTX/RX mode in mac_low_nomac, too.

Thanks.

Last edited by Tomi (2015-Jan-09 03:06:34)

Offline

 

#2 2015-Jan-09 09:40:35

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: about wlan_low_nomac

Tomi wrote:

wlan_mac_802_11_defs.h contains definitions of 802.11 packets that are required by both the upper and lower level CPUs.

Basically, there are three types of packets: management, control, an data.
For mac_low_dcf, all three types of packets are included.
Then how about mac_low_nomac? Are all three types of packets are supported, or only data packet is supported here?

NOMAC has as the same visibility that the DCF has. In the interest of keeping NOMAC simple for its purpose of being a direct "passthrough" layer without any real processing, I removed any variable assignments that relied on 802.11 definitions that weren't necessary for NOMAC. You can definitely add those back in if your design needs them.


Tomi wrote:

I checked the frame_transmit() in wlan_mac_dcf.c:
tx_frame_info* mpdu_info = (tx_frame_info*) (TX_PKT_BUF_TO_ADDR(pkt_buf));    mac_header_80211* header = (mac_header_80211*)(TX_PKT_BUF_TO_ADDR(pkt_buf) + PHY_TX_PKT_BUF_MPDU_OFFSET);

in wlan_mac_nomac.c:
tx_frame_info* mpdu_info = (tx_frame_info*) (TX_PKT_BUF_TO_ADDR(pkt_buf));

It seems there is no mac_header_80211 in NOMAC mode. Then how can I know the type of packet transmitted in NOMAC mode?

This is a good example of what I was discussing above. The DCF code needs access to the mac_header_80211 struct for some of its IBSS functionality that allows it to cancel outgoing beacon transmissions upon the reception of other beacons in the IBSS. The NOMAC code is much simpler and doesn't implement this feature, so I simply left out the definition of "header." You can actually just add exactly the same definition of "header" into NOMAC and it will work. It is not that NOMAC cannot know that information, it is simply that it does not need to know it for its default behavior.


Tomi wrote:

Because in mac_low_dcf, I used following sentences to enable/disable jumboTX/RX mode:

***************************************************************************
if((header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
     REG_SET_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN); //Enable JumboTx
} else{
     REG_CLEAR_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN);
}

if((rx_header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
    REG_SET_BITS(WLAN_RX_REG_JUMBO, WLAN_RX_REG_JUMBO_EN);//Enable JumboRx
} else{
    REG_CLEAR_BITS(WLAN_RX_REG_JUMBO, WLAN_RX_REG_JUMBO_EN);//Disable JumboRx
}
***************************************************************************

In mac_low_nomac, how can I distinguish the data message with other types of messages, as there is no mac_header_80211?
I want to enable/disable jumboTX/RX mode in mac_low_nomac, too.

Thanks.

This will definitely work in NOMAC, you just need to similarly define "header" and "rx_header". You should be able to copy and paste those definitions from the DCF code.

Offline

 

#3 2015-Jan-11 05:48:18

Tomi
Member
Registered: 2014-Oct-17
Posts: 58

Re: about wlan_low_nomac

Thanks for your reply.

As we know,
(1) In the 802.11 spec the LENGTH value in the SIGNAL field occupies 12 bits, limiting the maximum number of bytes to 4096
(2) The 4KB divisions of the Tx/Rx pkt buffers

so I think the max Tx/Rx packet sizes supported by current wlan_low_nomac should be 4KB.

Today I applied wlan_low_nomac, and made following modifications to enlarge the max Tx/Rx packet sizes from 2KB to 4KB (JumboTx/Rx function is *disabled* here):

in wlan_phy_util.c
wlan_phy_rx_set_max_pkt_len_kB(4);
wlan_phy_tx_set_max_pkt_len_kB(4);

in wlan_mac_entries.h
#define MAX_MAC_PAYLOAD_LOG_LEN        4000

in wlan_mac_queue.h
#define QUEUE_BUFFER_SIZE    0x1000     //4KB

in ltg.py
LTG_PYLD_MAX                           = 4000

And I applied throughput_two_nodes.py to check the throughput of two nodes.

node1_ltg_id  = node1.ltg_configure(wlan_exp_ltg.FlowConfigCBR(node2.wlan_mac_address, payload, 0, 0), auto_start=True)
node2_ltg_id  = node2.ltg_configure(wlan_exp_ltg.FlowConfigCBR(node1.wlan_mac_address, payload, 0, 0), auto_start=True)

If the payload value is less than 2000, the I can get the throughput correctly.
If the payload value is between 2000 and 4000, then the throughput is always *zero*.

The testing result showed that the max Tx/Rx packet sizes under current wlan_low_nomac can only reach 2KB, rather than 4KB.
Are there any other parts limit the max Tx/Rx packet size to 2KB?

Thanks.

Last edited by Tomi (2015-Jan-11 05:53:05)

Offline

 

#4 2015-Jan-12 10:44:54

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: about wlan_low_nomac

This looks like a bug in the Rx PHY. In 'Detect & Decode/Decode/Ctrl' there is a counter which increments for each pair of LLR's input to the Viterbi decoder. This counter has "2+ceil(MAX_NUM_BYTES)" bits. That 2 should be 3 (1 byte = 2^3 bits). This bug results in a maximum receivable packet size of ~MAX_NUM_BYTES/2, or around 2KB when you set Tx/Rx max_pkt_len_kB(4). We'll correct this in the next ref design release.

Offline

 

#5 2015-Jan-12 16:31:44

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: about wlan_low_nomac

We'll have the next Reference Design out this week and it will incorporate this bug fix. Also, I thought of one other thing you should be aware of when using the DCF with longer packets. We haven't built RTS/CTS into the design yet, but I did start to stub out places in the code where those changes will take place. One of them is in the definition of RTS_THRESHOLD. It's currently set to 2000 since that's larger than any packet we see. You'll want to raise that accordingly so that all of your packets fall under the RTS threshold.

Offline

 

Board footer