WARP Project Forums - Wireless Open-Access Research Platform

northk wrote:

Hi,

I would like to study the ACK error rate in my experiment.
Thus, I want to get the number of control packets with good FCS and bad FCS.
I set:
mac_param_rx_filter = (RX_FILTER_FSC_ALL | RX_FILTER_HDR_ALL);
in wlan_mac_low.c.

This should work, but just FYI you don't have to modify any C software in order to change this filter. That parameter is exposed all the way up through the wlan_exp framework with the wlan_exp.node.WlanExpNode.set_low_to_high_rx_filter command.

northk wrote:

Then, I run "log_capture_two_node_two_flow.py" and modify "log_process_detail.py" to get the number of control packets.
I use
  n_good_ctrl = np.sum((rx_good_fcs['pkt_type'][addr_idx]==21))
to get the control packets with good FCS in log_process_detail.py.
However, the number of received control packets is always zero for packets with good FCS.
Did I miss anything?

How is "addr_idx" defined? If you remove that filtering and simply sum across all pkt_type==21 cases, is n_good_ctrl nonzero? I suspect what you may be seeing is that, unlike management and data frames, control frames have no addr2 field. ACKs only have the address of who they are intended for. It could be that your script is trying to match the source of an ACK transmission to a non-existent source address in the frame.

I set the filter using wlan_exp framework and regenerate the hdf5 files.
I get the good ctrl packets using the new hdf5 files. Maybe I didn't set up it properly using c codes. Thanks.

Still another question, can I get the record of how many ACK the nodes transmit? Is it being recorded in the hdf5 files?

Last edited by northk (2015-Apr-06 13:27:44)

We don't currently report TX LOW events for control frames, but you can infer them directly by looking at the RX log entries. You can get the number of transmitted ACKs by counting the number of received unicast frames with good FCS. This is safe since the Rx log reports all receptions (including duplicates).

You can't quite calculate the ACK error rate that way. The problem occurs in the case where an MPDU is retransmitted the maximum number of times (7 total transmissions by default). Suppose your receiver successfully decodes the final retransmission and sends an ACK. The originator of that MPDU is going to move on to the next MPDU in its queue whether or not that ACK is received. I don't think you can calculate ACK error rate using just a single log file. Instead, I think you want:

ACK error rate = (# of received ACK frames with addr1 of MPDU transmitter) / (# of received unicast frames with good FCS {including duplicates} at MPDU receiver)

The above only works if you have only 2 nodes in the experiment. If your MPDU transmitter might receive other ACK frames from other nodes, you can't disambiguate those from the ACKs you care about since there is only a single address in the frames. The only way to disambiguate different ACKs from multiple parties is to account for the timing (i.e., an ACK that is a SIFS after a Tx is the one you care about). There is an easy way to do this also -- just let the board worry about it. The board already figures out which ACKs it should listen to via the timeout mechanism after a Tx. It raises a flag inside each TX_LOW log entry for transmissions for which it receives a valid ACK. The "flags" field in the TX_LOW event will be set to 0x01 in the case that an ACK was successfully received for that transmission. It will be 0 otherwise. As such, another way to calculate the ACK error rate is:

ACK error rate = (# of TX_LOW entries whose flags are set to 0x01) / (# of received unicast frames with good FCS {including duplicates} at MPDU receiver)

The above expression is general to a network of arbitrary size. Also, you no longer need to fill the log with actual control packets. You could restrict the filter back to only MPDUs.


Also, just a tip for performing these kinds of error calculations. Make sure to account for the edge conditions of your experiment where traffic might still be going on while you are grabbing the log from one of your nodes. For this experiment, you want to make sure the LTG start and LTG stop events occur before pulling any logs from the boards. Furthermore, stopping an LTG doesn't immediately stop all transmissions. Anything that is backlogged in the queue will continue to transmit after that event. So, you also should have a reasonable-length pause in your python code after stopping the LTG and prior to reading the log info from the boards. You can speed things up by calling the "queue_tx_data_purge_all()" python method, but even that won't fully eliminate the need for a pause. Whatever MPDU is currently in-flight down in CPU_LOW won't get removed by that method.