WARP Project Forums - Wireless Open-Access Research Platform

(1) Thanks for finding this. This is a bug in the .96 Reference Design that will be fixed in the next release. Thankfully, it is a one line change to wlan_mac_nomac.c to fix this, so you don't need to wait for the next release. Specifically, in frame_transmit, add the following line of code anywhere in the top of that function after "mpdu_info" is assigned (e.g. Line 187):

mpdu_info->num_tx = 1;

With NOMAC, every MPDU transmission for CPU_HIGH results in exactly 1 low transmission. In the DCF, this value can be between 1 and 7 if the frame required retransmissions. By neglecting to set this to 1 in NOMAC, the existing code incorrectly informed CPU_HIGH that this MPDU transmissions took 0 transmissions. While clearly bogus, CPU_HIGH dutifully used this value to construct 0 TX_LOW log entries. Your packets were being transmitted, its just that the TX_LOW log entries were not created.

(2) num_tx_max is set by CPU_HIGH for each MPDU that it wants to transmit. For example, for a multicast transmission like a beacon, the num_tx_max is set to 1. For unicast transmissions, this value is typically set to 7. For example, the AP sets the default values for various transmissions parameters here. The #define for MAX_NUM_TX is set here.

So if there are two NOMAC stations, they will transmit the packet when they get one from the upper layer. Their packets may collide in the air.

How the transmission time is decided in NOMAC, as there is no SIFS, DIFS and contention window?

The nomac code literally implements no medium access control - packets are transmitted once, immediately when they are received from the upper layer. This is not a good MAC design. As you note it will frequently cause collisions which, since there are no re-transmissions, means lots of lost packets. We built nomac as an example project to demonstrate the minimum code to interact with the the upper-level MACs and the Tx/Rx PHYs. Nomac is a great starting point for custom MAC implementations; it is not a good MAC design on its own.

The minimum inter-transmission time will be determined by the actual duration of the transmission plus the processing overhead in CPU high and low. For a 1400 byte LTG payload the over-the-air MPDU will be 1428 bytes long (24 byte MAC header, 8 byte LLC header, 12 byte LTG header, 1380 byte random payload, 4 byte FCS). The Tx duration for a given payload depends on the PHY rate; see IEEE 802.11-2012 section 18.4.3 or calc_tx_time() in wlan_exp.log.util.

Also, keep in mind that the PHY is half-duplex. Transmissions defer to incoming receptions, even in nomac. If your node is receiving packets the inter-Tx-time will reflect the time the node spent receiving and processing Rx packets.

As you mentioned, NOMAC PHY is half-duplex. I think the Tx/Rx activities should be "Tx Rx Tx Rx Tx Rx Tx Rx...", rather than "Rx Rx Rx Rx Rx Rx Tx"  or "Rx Tx Tx Tx Tx Tx Tx". How could current situation happen?

Assuring a fair division of Tx and Rx between nodes would require a MAC protocol. Two nomac nodes sending each other fully-backlogged traffic have zero coordination. There will be many collisions at both nodes. On the rare chance that one node begins transmitting slightly before the other, the early Tx might get through. The purpose of a MAC protocol is to coordinate behaviors of multiple nodes all contending for the same medium. The 802.11 DCF is a good MAC protocol. Nomac is a good platform for building your own protocol. But by itself nomac will not do a good job dividing medium time fairly.

Can you clarify- what is your hardware setup? 2 nodes (AP + STA) or 3 nodes (AP + STA1 + STA2)?

(2) I applied
>n_sta_1.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_ap.wlan_mac_address, 1400, 0, 0), auto_start=True)
>n_sta_2.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_ap.wlan_mac_address, 1400, 0, 0), auto_start=True)
to define to LTG payload of STA1/2.
n_ap.wlan_mac_address here means the destination MAC address. I checked the RX_OFDM entry, and found that the LTG payload of AP is also 1400.

This will start one traffic flows at each STA node, both addressed to the AP node. The AP log will have RX_OFDM entries from STA1 and STA2. The STA logs will both have RX_OFDM entries from the other STA.

Then I changed the above sentences to >n_sta_1.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_ap.wlan_mac_address, 100, 0, 0), auto_start=True)
>n_sta_2.ltg_configure(wlan_exp_ltg.FlowConfigCBR(n_ap.wlan_mac_address, 100, 0, 0), auto_start=True)
Then the LTG payload of STA1/2 is changed to 100.
However, the LTG payload of AP is also changed to 100.

Do you mean the AP log showed RX_OFDM entries with length 100? This is what you expect when you change the LTG payload size at the transmitting nodes.

The only way for you to have the STA receive packets from the AP but not from the other STA is to have them physically hidden from each other (i.e. the classic hidden node problem). You want (1) STA1 be in carrier sensing (CS) range of the AP, (2) STA2 in CS range of the AP, and (3) STA1 and STA2 not in CS range of one another. Those three pieces together are going to create lots of collisions at the AP, which I think is the goal. There are a few ways to do this:

1) If you don't need actual over-the-air effects, you could use RF cabling and an RF power splitter to create the hidden node topology. You could set it up like this appendix to the multi-flow application note. You would want to put additional attenuation on ports 1 and 2 of the splitter and probably remove the attenuation from the S port of the splitter. This would allow both the links to the AP to have the same SNR but would hugely reduce the link power between the two STA devices.

2) If you need over-the-air effects, the best case would be to use a channel emulator. I've used Azimuth's channel emulators pretty extensively during my PhD work. With this, you could not only create a truly hidden system where STA1/STA2 don't see each other, but the links to the AP could have genuine multi-path effects like those that occur over-the-air.

3) If you don't have access to a channel emulator and you do need over-the-air effects, then you'll have to actually go over-the-air and construct the hidden topology. Basically you want a linear topology where STA1 and STA2 are far apart from one another yet close to the AP. Most indoor laboratory environments aren't large enough to be able to get STA1/STA2 far enough apart from one another so they are hidden. In this case, you could lower their transmit powers to effectively increase the pathloss they see. Or you could add an attenuator in-between the radio's SMA port and the antenna. Doing this will also lower Rx sensitivity, however.