WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#26 2016-Jul-05 17:07:39

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

Re: Experiment with TokenMAC

warp_user wrote:

There is data in sta_two_node_two_flow_capture.hdf5 but nothing in ap_two_node_two_flow_capture.hdf5.

Can you clarify what you mean by "data" in this context? Is the content of the STA's log file RX_OFDM events from the AP? Or RX_EVENTS from someone else? Or Tx Events? Does the AP's log have no entries at all, or only Tx entries to the STA?

If the AP -> STA flow is working but the STA -> AP flow is not, I think that's consistent with the token passing message being lost or not sent for some reason. If neither flow seems to be working, then it may be something else.

There isn't too much else I can say without knowing more. Try printing to UART whenever NOMAC is sending a token request (e.g. sometime after the call to wlan_create_token_offer_frame()). Does that print periodically like you expect at the node acting as the AP? If so, then move on to the STA side and print when you are processing the request and generating the reply. That can help narrow down where the problem is coming from. Be sure to lower the rightmost dip switch in the User I/O section of WARP v3 to output the CPU_LOW UART over the micro-USB connection.

Offline

 

#27 2016-Jul-13 07:50:54

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Answering to your question there is no data at all in the ‘ap_two_node_two_flow_capture.hdf5’.

Then I have followed a suggestion in the following link,
http://warpproject.org/forums/viewtopic … 10#p14710; and modified the parameter in MAC_HW_LASTBYTE_TOKEN(9) to 9 bytes.
This is in figure (1).

This generates data for both AP and STA once characterized with WARPnet (using the steps specified in https://warpproject.org/trac/wiki/802.1 … terization).

I have used 'log_capture_two_node_two_flow.py' in WARPnet framework.
Then I have used 'log_process_summary.py' to read those hdf5 files.
The output recognizes data at 12Mbps instead of 18Mbps as used in the python script, as specified in figure (2) – AP data - and figure (3) – STA data.

Furthermore I have used Wireshark monitor mode to sniff packets during the operation and manage to filter similar to token_offer and token_request being generated. These correspond to the frames 442 to 445 in the figure (4). But this change is from Authentication to Data only and could not find any instance for change of direction in data transfer.

Please note that, MangoCom_03:96 is the AP and MangoCom_03:06 is the STA.

Thanks in advance for any insight and guidance on the above issues.

Figure (1)
http://wikisend.com/download/342818/f1.png

Figure (2)
http://wikisend.com/download/150306/f2.png

Figure (3)
http://wikisend.com/download/363180/f3.png

Figure (4)
http://wikisend.com/download/732486/f4.png

Offline

 

#28 2016-Jul-14 09:41:54

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

Re: Experiment with TokenMAC

First, I have a couple of general debugging suggestions. wlan_exp is really good for two things:
A) Characterizing a known working design
B) Debugging large-scale protocol problems. For example, suppose a node that seems to get access to the medium unfairly in an unexpected way. wlan_exp can help track down the OTA packet interactions that led to that behavior.

wlan_exp is less well-suited for debugging fundamental protocol issues like the ones you are seeing. It's simple, but a really powerful debugging strategy is simply adding xil_printf() calls at various parts of the code to make sure they are executing and in the order your are expecting. Using UART to debug like this is useless when you are trying to measure anything timing sensitive (like throughput) since it takes a long time to print relative to wireless behaviors. But it's great for making sure that code is executing like you expect.

Here are a couple of more concrete suggestions on places to look:

1. Before even starting any traffic flow, make sure the token handshake is working properly. If you aren't seeing the reservation reliably alternate between the AP to the STA, there is no point in going any further until you figure out why. You'll want to add some prints to NOMAC. To view UART prints from CPU_LOW, be sure to lower the right-most switch on the user IO DIP switch
1a) Print "Create Token Offer" at the end of wlan_create_token_offer_frame().
1b) Print "Create Token Response" at the end of wlan_create_token_response_frame().
1c) Print "Received Token Offer" in frame_receive() here:

Code:

if(unicast_to_me && (rx_header->frame_control_1 == MAC_FRAME_CTRL1_SUBTYPE_TOKEN_OFFER)){
        ...
        mpdu_info->state = wlan_mac_dcf_hw_rx_finish();
        if(mpdu_info->state == RX_MPDU_STATE_FCS_GOOD){
                xil_printf("Received Token Offer\n");
        ...

1d) Print "Received Token Response" in frame_receive() here:

Code:

} else if(unicast_to_me && (rx_header->frame_control_1 == MAC_FRAME_CTRL1_SUBTYPE_TOKEN_RESPONSE)) {
        ...
        mpdu_info->state = wlan_mac_dcf_hw_rx_finish();
        if(mpdu_info->state == RX_MPDU_STATE_FCS_GOOD){
                xil_printf("Received Token Response\n");
        ...

With those changes you should see the AP print:

Code:

...
Create Token Offer
Received Token Response
Create Token Offer
Received Token Response
...

The STA should print

Code:

...
Received Token Offer
Create Token Response
Received Token Offer
Create Token Response
...

2. Figure 4 you posted is very suspicious. It looks like the AP (MangoCom_03:96) is hemorrhaging authentication messages. It's important to figure out why this is happening. First, verify this is happening even without the involvement of your wlan_exp script by printing a message like "Enqueued an Authentication Response" on line 1382 of wlan_mac_ap.c. Does that print repeatedly? If it does, that mean the STA, for some reason, is sending its authentication request repeatedly so you can track that down by adding similar prints in the wlan_mac_sta.c code.

Offline

 

#29 2016-Sep-20 04:18:21

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have updated NoMAC design accordingly (for release 1.5.2) as suggested in Token MAC tutorial. Once the updated design is compiled successfully hardware boards are programmed using SD cards.
For the case of release 1.5.2, in STA design the hex display shows '--' instead of '0' at the start (http://warpproject.org/forums/viewtopic.php?id=3121).

To fix this issue I have changed the original line 'sta_update_hex_display(0xFF)' to 'sta_update_hex_display(0x00)' in function 'main()' of 'wlan_mac_sta.c'
I want to first test this design in WARPnet environment.
I have started with 'blink_nodes_leds.py' and this fails to identify the STA node (AP identification is successful). This problem is very similar to the issues in http://warpproject.org/forums/viewtopic.php?id=3063.
I am using WARP V3 with Release v1.5.2, ISE 14.4 in a Ubuntu environment.
Awaiting for a favourable response soon,
Many thanks

Offline

 

#30 2016-Sep-21 11:56:56

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

Re: Experiment with TokenMAC

For the case of release 1.5.2, in STA design the hex display shows '--' instead of '0' at the start

This is the intended behavior when the node is configured to boot with a null BSS and will not attempt to join the default BSS. This mode is selected via the DIP switch - refer to the user guide for details. When you're running experiments with wlan_exp we recommend using the "null BSS" mode at all nodes and explicitly configuring the desired BSS state at all nodes via Python.

I have started with 'blink_nodes_leds.py' and this fails to identify the STA node (AP identification is successful).

The blink_node_leds example uses a broadcast packet to execute the "identify" command at all nodes on the local network. If one of your nodes does not respond to this command, it means it is not receiving the broadcast packet. Check that the node has booted successfully (check the UART output) and that its ETH B interface is connected via 1Gb Ethernet to the local network switch.

Offline

 

#31 2016-Sep-28 05:35:47

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have modified the ‘nomac’ model in version 1.5.2 towards a token MAC implementation as suggested in the tutorial and encounter issues once debugged for the behavior of token MAC. From my understanding it seems the problem occurs in the ‘frame_receive’ function. When frame_receive() is called via the main function the receive packet buffer is not called accordingly.
As there are several changes and modifications added upgrading from version 1.3 to version 1.5.2 in most cases I had to study the codes carefully when upgrading token MAC for version 1.5.2.
In addition I have named token mac structure as 'schmac' with the intention of keeping 'nomac' project for benchmarking the extended models in the future. I would appreciate if you can have a look at the attached model in resolving this issue. In addition to the zip file including the extended model there is also an accompanying document highlighting the changes and modifications.
EDK project is uploaded in http://wikisend.com/download/789806/sch … _debug.zip and the document is in http://wikisend.com/download/555426/schmac_model.zip


Thanks in advance and awaiting a favourable reply soon

Last edited by warp_user (2016-Sep-28 05:37:15)

Offline

 

#32 2016-Oct-18 11:49:02

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I would like to use the TOKEN MAC in an application similar to wireless/wired bridge set up as in http://warpproject.org/trac/wiki/OFDMRe … ns/Bridge. I am currently testing the performance using WARPnet framework and would like your help in understanding the steps in replacing the LTGs (in WARPnet framework) with a real application similar (to VLC or any other streaming).
I am using the TOKEN MAC design provided for version 1.3 (with plans to test in v 1.5 in future).
Would appreciate your assistance in resolving this issue. Many thanks.

Offline

 

#33 2016-Oct-18 11:55:55

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

Re: Experiment with TokenMAC

The 802.11 Ref Design implements wired-wireless bridging between the WARP v3 node's ETH A interface and the wireless interface. This bridge operates in parallel with the LTG framework. LTG traffic will only be generated if enabled explicitly via Python or C code. The bridge will generate traffic any time Ethernet packets arrive at ETH A.

One common setup is to connect the AP's ETH A interface to an Ethernet network with internet access and a DHCP server (i.e. the "LAN" side of a home router), and connect the STA's ETH A interface to a PC's Ethernet interface. The PC will then use the 802.11 Ref Design link for its internet connection. You can then stream whatever traffic you want between the STA PC and a PC on the AP's Ethernet network (iperf, VLC, etc).

Offline

 

#34 2016-Oct-19 11:15:01

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for the reply, it is really helpful.
Could you please point me to the part of the 802.11 Ref Design which handle the association of AP and the STA? I need to use the Token MAC design for a streaming application with with association of STA and AP at the boot instead of using WARPnet framework.
Thanks in advance

Offline

 

#35 2016-Oct-20 12:46:25

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

Re: Experiment with TokenMAC

In the v1.5 code all BSS state is configured in the configure_bss() function. The AP creates its BSS via configure_bss(). The STA uses its scan-and-join state machine to find the AP's BSS, then executes the association handshake, then updates its own BSS state via configure_bss().

In v1.3 the basic processes are the same just less centralized. The STA uses the same scan-and-join state machine to discover the AP's BSS and executes the association handshake. This process is implemented in wlan_mac_sta_join_fsm.c.

You can skip the scan-and-join process if you know the AP and STA MAC addresses ahead of time. You could modify the AP C code to add the STA to its association table, and modify the STA to boot up in the associated state. We don't have example code for this - I would recommend following the code path for the wlan_exp "node_ap.add_association(node_sta)" call.

Offline

 

#36 2016-Nov-03 12:15:43

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have followed the suggested approach as in wlan_exp “node_ap.add_association(node_sta)” and managed to test successfully for the for the NoMAC bridge application (version 1.3).
But when I tried to run the Ethernet - wireless bridging application for Token MAC the machine connected to the STA cannot associate with the AP.
Once debugged using UART output it can be seen that token offers and responses are passed between AP and the STA successfully.
Are there any additional measures needed to consider in Token MAC to bridge Ethernet packets to Wireless design?
The following are the codes added to the AP and STA (just before the last while in main function) to bypass the scan and join process.
Thanks in advance

Code:

////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Associate with the device - additional code in AP
// //////////////////////////////

static u8 wlan_mac_addr_sta[6] = { ‘STA address here’}; // STA MAC address
interrupt_state_t prev_interrupt_state;
station_info* temp_station_info = NULL;
u32 temp_flags;

// Set default value for the flags
temp_flags = STATION_INFO_FLAG_DISABLE_ASSOC_CHECK;

if( my_bss_info->associated_stations.length < wlan_mac_high_get_max_associations() ) {
// Disable interrupts so no packets interrupt the dis-associate
prev_interrupt_state = wlan_mac_high_interrupt_stop(); // needs to include

// Add association
// ADD_ASSOCIATION_ANY_AID is a defined constant used only in association
temp_station_info = wlan_mac_high_add_association(&my_bss_info->associated_stations, &statistics_table, wlan_mac_addr_sta, ADD_ASSOCIATION_ANY_AID);

temp_station_info->flags = temp_flags;

//Re-enable interrupts
wlan_mac_high_interrupt_restore_state(prev_interrupt_state);

// Set return parameters and print info to console
if (temp_station_info != NULL) {
// Log association state change
add_station_info_to_log(temp_station_info, STATION_INFO_ENTRY_NO_CHANGE, WLAN_EXP_STREAM_ASSOC_CHANGE); 
xil_printf("AP and STA association complete: \n");

memcpy(&(temp_station_info->tx), &default_unicast_data_tx_params, sizeof(tx_params)); // update tx parameters

// Update the hex display
ap_write_hex_display(my_bss_info->associated_stations.length);
	}
}

/////////////////////////////////

Code added for the STA, in addition the function -‘wlan_mac_sta_scan_and_join(access_point_ssid, 0);'- is not called in the main()

Code:

////////////////////////////////////////////////////////////////////////////
	// association at the start (similar to association in WARPNet Framework from STA and AP)
	
	static u8 wlan_mac_addr_ap[6] = { ‘AP address here; // AP MAC address
	u16 sta_aid=1;
	int sta_status;
	interrupt_state_t sta_prev_interrupt_state;

	// Disable interrupts so no packets interrupt the associate
	sta_prev_interrupt_state = wlan_mac_high_interrupt_stop();

	// Stop any active scans
	wlan_mac_scan_disable();

	// Add the new association
	
	bss_info* sta_bss_temp = wlan_mac_high_create_bss_info(wlan_mac_addr_ap, access_point_ssid, mac_param_chan);

	if(sta_bss_temp != NULL){
	sta_bss_temp->state = BSS_STATE_ASSOCIATED;
	sta_bss_temp->capabilities = (CAPABILITIES_ESS | CAPABILITIES_SHORT_TIMESLOT);
	wlan_mac_sta_return_to_idle();

	sta_status = sta_set_association_state(sta_bss_temp, sta_aid);
	} else {

	sta_status = -1;
	}

	// Re-enable interrupts
	wlan_mac_high_interrupt_restore_state(sta_prev_interrupt_state);

/////////////////////////////////

Offline

 

#37 2016-Nov-04 09:52:33

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

Re: Experiment with TokenMAC

warp_user wrote:

I have followed the suggested approach as in wlan_exp “node_ap.add_association(node_sta)” and managed to test successfully for the for the NoMAC bridge application (version 1.3).
But when I tried to run the Ethernet - wireless bridging application for Token MAC the machine connected to the STA cannot associate with the AP.

Can you clarify what you mean by the computer connected to the STA not being able to associate with the AP? I can interpret that comment one of two ways:

(1) The WARPv3 STA is failing to perform an over-the-air association with the WARPv3 AP. This is independent of any Ethernet traffic or interactions with the computer connected to the STA.
(2) That the WARPv3 STA is fully associated but, for some reason, the Ethernet bridging isn't working.

Do the hex displays of both the AP and STA show the value "01" after they boot up? If so, the AP and STA are associated and the problem appears to be scenario (2).

warp_user wrote:

Once debugged using UART output it can be seen that token offers and responses are passed between AP and the STA successfully.

This would also strongly indicate scenario (2) above. The changes to the AP and STA suggested by the app_note ensure the AP only sends the STA a reservation token if that STA appears in the AP's association table. So, it seems like the nodes are associated.

None of the TokenMAC changes in the app_note discriminate between LTG traffic (which you have seen work with wlan_exp) or Ethernet traffic. Does Ethernet bridging work for you in the unmodified design? If not, then the problem isn't related to the TokenMAC changes but rather something more fundamental to your particular network setup. If this is the case, let me know and we can debug that problem further and ignore the TokenMAC complication for the time being. The two biggest causes of issues for users using Ethernet bridging are (a) the use of a 100Mbps NIC or Ethernet switch with a design that is built for 1Gbps Ethernet and (b) MAC address filters on the wired side of the network. This is fairly common in corporate/university networks (see this post for more details)

Offline

 

#38 2016-Nov-07 09:29:24

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for the useful infomation, I have couple more questions on this.
Once tested with NoMAC Ethernet bridge works well.

(1) In addition to AP and STA association at the start, are there any other changes needed for the following parameters in the current TokenMAC design? Their values are set as;
allow_new_mpdu_tx        = 0;
pkt_buf_pending_tx       = -1;
in_reservation = 0;

(2) Also in 'wlan_mac_sta.c' once the function 'sta_set_association_state(...)' is called it disassociates the node via calling 'status = sta_disassociate()'. Is this necessary in the first instance of assocaition?

(3) In addition when TokenMAC is tested with wlan_exp (using LTG traffic flow) the transmission stops after a short while. Are there any constraints on buffer size for Ethernet packets which needs to be increased (for the case of wlan_exp experiments and Ethernet bridge applciation)?

Thanks in advance

Offline

 

#39 2016-Nov-08 11:09:19

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

Re: Experiment with TokenMAC

warp_user wrote:

(1) In addition to AP and STA association at the start, are there any other changes needed for the following parameters in the current TokenMAC design? Their values are set as;
allow_new_mpdu_tx        = 0;
pkt_buf_pending_tx       = -1;
in_reservation = 0;

These are just internal variables used by the TokenMAC algorithm described in the application note. You shouldn't manually change these starting values. For example, "in_reservation" represents whether or not a token is current issued to that node. Its default value gets changed in token_new_reservation() function that gets added to NoMAC.

warp_user wrote:

(2) Also in 'wlan_mac_sta.c' once the function 'sta_set_association_state(...)' is called it disassociates the node via calling 'status = sta_disassociate()'. Is this necessary in the first instance of assocaition?

This call to sta_disassociate() just reverts the STA to a sane disassociated state prior to setting whatever new association state is proved to sta_set_association_state(). A call to sta_disassociate() when the node is currently disassociated doesn't do anything.

warp_user wrote:

(3) In addition when TokenMAC is tested with wlan_exp (using LTG traffic flow) the transmission stops after a short while. Are there any constraints on buffer size for Ethernet packets which needs to be increased (for the case of wlan_exp experiments and Ethernet bridge applciation)?

The LTG traffic flow should run as long as the script tells it to. The log_capture_two_node_two_flow.py script in the v1.3 release runs for a total of 60 seconds broken up into 3 different phases (AP->STA, AP<->STA, AP->STA). Can you clarify what you mean by the transmission stopping after a "short while"?

Offline

 

#40 2016-Nov-25 07:10:30

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

In the Token MAC extension in (http://warpproject.org/trac/wiki/802.11 … extensions)
Can you clarify in the following code, the value assigned for TOKEN_RES_BYTES_EFFICIENCY_THRESH which is 2000 bytes instead of 2000 bits?

Code:

#define TOKEN_RES_MULT_FACTOR_MIN 1
#define TOKEN_RES_MULT_FACTOR_MAX 50

#define DEFAULT_RESERVATION_DURATION_USEC 2000

//Ignoring all overhead, a 6 Mbps PHY rate
//could theoretically deliver (6e6*2000e-6) = 12 kBytes
//in 2ms. Let's define our "success" threshold at (an arbitrary) 1/6 of that: 2000 bytes.
//Delivering more than this threshold in 2ms will grant access to the larger
//token reservation period
#define TOKEN_RES_BYTES_EFFICIENCY_THRESH 2000

Thanks

Offline

 

#41 2016-Nov-25 09:44:45

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

Re: Experiment with TokenMAC

The idea behind TOKEN_RES_BYTES_EFFICIENCY_THRESH is to provide a threshold to determine whether or not a STA properly used or "wasted" its reservation period. The AP uses this value to "audit" the previous reservation and decide whether or not an associated STA is given the full DEFAULT_RESERVATION_DURATION_USEC reservation duration or something shorter.

For a nominal reservation duration of DEFAULT_RESERVATION_DURATION_USEC = 2000 usec, a 6Mbps PHY rate can deliver no more than 12000 bytes in a reservation period. A TOKEN_RES_BYTES_EFFICIENCY_THRESH of 2000 bytes is arbitrary -- it's 1/6 of that maximum 12000 bytes. If a STA can deliver more than 2000 bytes in 2000 usec, it will be issued a long reservation next time of DEFAULT_RESERVATION_DURATION_USEC* TOKEN_RES_MULT_FACTOR_MAX (100ms).

Offline

 

#42 2016-Nov-28 04:28:11

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

Many thanks for your reply.
In the example, the PHY rate of 6 Mbps (Megabits per second) provides 12000 bits and why is it considered as 12000 bytes in the given reservation period of 2000 microseconds?

Thanks again.

Offline

 

#43 2016-Nov-28 07:11:56

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

Re: Experiment with TokenMAC

My apologies -- you are absolutely correct. I was just repeating those (incorrect) comments because I misunderstood your question.

You're right. In 2ms, the 6Mbps rate can nominally deliver 12000 bits (1500 bytes). So, actually, a threshold of 2000 bytes wouldn't even work for the 6Mbps rate. It worked itself out in the characterization because we used the 18Mbps rate (which can potentially achieve 4500 bytes in the 2ms period). If you want to use lower rates, you'll need to lower the value of TOKEN_RES_BYTES_EFFICIENCY_THRESH.

Offline

 

#44 2016-Dec-05 11:04:20

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have implemented the Token MAC extension but cannot get the increase in throughput (during the phase where only AP to STA flow is available) as presented in Token MAC extension tutorial in (http://warpproject.org/trac/wiki/802.11 … extensions)
Once debug the code using 'xil_printf' statements I noticed that 'token_stats_end' function is not called at all.

Once investigated further can see the following callback functions are defined to start and end collection of statistics based on number of bytes transmitted within a reservation period.

Code:

void wlan_mac_high_set_token_stats_start_callback(function_ptr_t callback){
  token_stats_start_callback = callback;
}

void wlan_mac_high_set_token_stats_end_callback(function_ptr_t callback){
  token_stats_end_callback = callback;
}

In addition, the following code in the main() assigns 'token_stats_start_callback' to the function 'token_stats_start'

Code:

wlan_mac_high_set_token_stats_start_callback((function_ptr_t)token_stats_start);

But cannot find an assignment of callback for the function 'token_stats_end'. Can you please look into this issue?
Thanks in advance

Offline

 

#45 2016-Dec-07 11:18:24

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

Re: Experiment with TokenMAC

You should connect the "token_stats_end" function to the WLAN MAC High Framework with the following at the top of the code where other callbacks are set:

Code:

wlan_mac_high_set_token_stats_end_callback((function_ptr_t)token_stats_end);

Offline

 

#46 2017-Jan-12 10:36:41

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I have tested successfully TOKEN MAC implementation on WARP using WARPnet framework and get similar results as in https://warpproject.org/trac/wiki/802.1 … terization

I understand that in WARPnet, traffic is generated as software packets using LTGs. I would like to test TOKEN MAC protocol in a practical scenario and have used an iPerf session running between the AP and STA both in UDP and TCP traffic scenarios.
I assume WARPnet LTG scenario is similar to a UDP session.
My question is I am not getting data rates similar to WARPnet results (The data rates generated from iPerf are very low compared to the values provided by WARPnet). Could you please let me know a suitable approach for testing and deriving similar data rates as WARPnet results in a practical scenario?
In addition iPerf can only generate a single session at a time either from AP to STA or vice cersa. Are there any test applications that can be used to emulate simultaneous multiple sessions (AP to STA and STA to AP) as used in period B of https://warpproject.org/trac/wiki/802.1 … terization

Thanks in advance

Offline

 

#47 2017-Jan-13 09:23:19

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

Re: Experiment with TokenMAC

warp_user wrote:

I understand that in WARPnet, traffic is generated as software packets using LTGs. I would like to test TOKEN MAC protocol in a practical scenario and have used an iPerf session running between the AP and STA both in UDP and TCP traffic scenarios.
I assume WARPnet LTG scenario is similar to a UDP session.
My question is I am not getting data rates similar to WARPnet results (The data rates generated from iPerf are very low compared to the values provided by WARPnet). Could you please let me know a suitable approach for testing and deriving similar data rates as WARPnet results in a practical scenario?

Yes, the constant bit rate LTG is analogous to a UDP stream. We've successfully used iperf to test links successfully before (primarily back before we had created wlan_exp). As a debugging step, I'd suggest trying the iperf test with a stock design that hasn't been modified with TokenMAC. Do you see a similarly low data rate from iperf in this setup? If so then we can rule out any problems introduced by the TokenMAC changes. Assuming you continue to see iperf throughput issues with the stock design, another thing to check is that an iperf2 client has a -b flag to tell it how much bandwidth it should try to use. Are you setting this? Something like "-b 30M" should suffice since 30Mbps exceeds what you can hope to sustain across the link. Everything else will dropped and your throughput measurement will tell you the maximum throughput that can be sustained. The throughput measurement will be low if the client is only attempting to drive the default 1Mbps across the link. Note: I don't have much experience with iperf3, but it must have a similar option.

warp_user wrote:

In addition iPerf can only generate a single session at a time either from AP to STA or vice cersa. Are there any test applications that can be used to emulate simultaneous multiple sessions (AP to STA and STA to AP) as used in period B of https://warpproject.org/trac/wiki/802.1 … terization

I think iperf should be able to do this. On the client side you can use the -d flag for a dualtest. That will actually run an iperf server on the client side and instruct the original server to also send a UDP stream the other direction back to you.

Offline

 

#48 2017-Jun-01 10:57:29

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

I would like to extend the Token MAC design for multiple nodes (AP with two STAs).
Can you point out where in the code (CPU Low and CPU High) changes are required for adding new STAs, generation of Token offers and Token responses and is there a priority between STAs in this scenario? Furthermore can you please let know of the required RF isolation when connecting WARP radio boards for this purpose.

Thanks

Offline

 

#49 2017-Jun-02 09:44:10

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

Re: Experiment with TokenMAC

warp_user wrote:

I would like to extend the Token MAC design for multiple nodes (AP with two STAs).
Can you point out where in the code (CPU Low and CPU High) changes are required for adding new STAs, generation of Token offers and Token responses and is there a priority between STAs in this scenario?

I haven't tested it with more than the 1 AP + 1 STA setup, but I wrote that application note with supporting an arbitrary number of stations in mind. The implementation of "set_new_reservation()" loops through all associated stations, so I think you don't need to modify any code to have it work. All you need to do is associate the 2nd STA to the AP's network. You can do this via wlan_exp. One of the 3 node examples like the hidden nodes with RTS/CTS shows how to set up the 3 node network.

The order of reservation period is just round robin between every device, so it would be (AP, STA 1, STA 2, AP, STA 1, STA2, etc.).

warp_user wrote:

Furthermore can you please let know of the required RF isolation when connecting WARP radio boards for this purpose.

Meaning the amount of attenuation needed between a Tx radio and Rx radio to prevent damage? You'd need at least 30dB of attenuation to prevent damage, but you'll probably want around 50dB of attenuation for a more reasonable "high SNR" environment. Are you going to cable together the three kits with a power splitter?

Offline

 

#50 2017-Jun-05 03:50:46

warp_user
Member
Registered: 2014-Feb-27
Posts: 70

Re: Experiment with TokenMAC

In terms of associating STAs to the AP network, I am planning to use hard association with STA MAC addresses already assigned to the AP at the start (rather than going through the registration via beacons). This will let me test in a real setup compared to wlan_exp set up. In addition can you let me know how to test that both stations are correctly assigned for reservations in the "set_new_reservation()" loop in the right order?
With respect to connecting WARP radio boards, I use cabling with SMA connectors and currently there is a 50dB attenuation between the AP and the STA. Can you elaborate how to extend this for multiple STAs, with the use of a power splitter and essential attenuation between the STAs?

Offline

 

Board footer