You are not logged in.
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
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
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
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
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