WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2016-Jun-14 08:07:41

ggalieroc
Member
Registered: 2015-Oct-08
Posts: 24

Change wlan channel during a traffic flow

Hello,

I have one question about how do the warp boards change from the different wlan channels. I am mostly interested in this situation:

2 WARPv3 boards: AP(Ref. Design 802.11) and STA(Ref. Design 802.11)
Downlink/Uplink traffic running (file transfer, ping, etc)

I modified the AP software so it is able to identify if there is a heavy background traffic, so that when this condition is true, the AP will change its operation to another wlan channel. Let's assume a user do it by hand using the keyboard for UART console. How do the boards perform? Is the traffic stopped and re-initialized once the STA joins again the AP? Or we have to stop the traffic by some mechanism and then re-start again the traffic?

Thanks beforehand.

Offline

 

#2 2016-Jun-14 10:14:59

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

Re: Change wlan channel during a traffic flow

It is possible for nodes to switch channels without interrupting any association state or ongoing traffic. 802.11 uses the "Channel Switch Announcement" (CSA) for this in either beacon or action management frames. We have not implemented this yet, but plan to in the future. The v.1.5.1 code base has all of the primitives needed to build CSA support. Doing so would allow your AP to detect that a channel is busy, inform any associated clients that it is jumping to a new channel, and then finally tune to the new channel and meet the clients there.

Offline

 

#3 2016-Jun-21 07:45:33

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: Change wlan channel during a traffic flow

Hi,

I have my WARP-AP up and running on Ch1, and two stations are attached: 1 WARP board as STA, and an OSX host.

If I re-code my AP to now operate on Ch11, and reprogram the WARP-AP board, once it comes up I see that the OSX host will seamlessly reconnect to "WARP-AP" on Ch11.

However, the WARP STA does not do this. The STA's console 'j' command lists detected APs and I note that "WARP-AP" still appears on Ch1 (and not 11 as it should be). Even if I type 'j' followed by "WARP-AP", it fails to join the AP now on Ch11.

If I reprogram the AP to operate back on Ch1 again, then the STA joins as it originally did (along with the OSX host).

My interpretation of this is the STA code doesn't seem to re-scan for channels/SSIDs. Especially since I notice "WARP-AP" still appears on the STA's console list, even after I power off the WARP-AP. This was tested on: Mango_802.11_RefDes_v1.5.1.zip

Does anyone know if there's an easy way to enable re-scanning on the STA, so that it can "follow" an AP, as the AP changes channels? I'm looking at this occurring on a minute++ timescale (and am OK in the resulting user-data outage during this changeover period).

-vick

Last edited by vick (2016-Jun-21 08:11:47)

Offline

 

#4 2016-Jun-21 16:15:13

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

Re: Change wlan channel during a traffic flow

Hi vick,

Most Wi-Fi STA clients are pretty aggressive about trying hop onto a better AP than the one they are currently associated with. Even if the current AP is still available, I have definitely seen smartphones disassociate and attempt to associate with other APs that meet some internal criteria (e.g. a better Rx power of MCS capability set). When you move your AP off of Channel 1 and on to Channel 11, a natural consequence of this behavior is that the commercial Wi-Fi STA will see the moved AP on the next active scan and try to re-associate with it.

The default STA implementation in the 802.11 Reference Design doesn't time out on an association and restart an active scan, but this would be straightforward to add:

- The AP code has a remove_inactive_station_infos() function that is called periodically. This function looks at metadata for each associated STA and decides whether or not to "boot" the STA from the network based upon how long it has been since the last time the AP heard from that STA. If you take a look at that function, you can see the implementation is pretty straightforward -- "rx_latest_activity_timestamp" is compared against the current system time. If the gap between those values is larger than ASSOCIATION_TIMEOUT_US, the STA is deauthenticated and booted. You can create a similar function and hook it up the scheduler in the STA implementation that inspects how long it has been since the last time the STA heard from the AP. If that amount of time is too long, you could infer the AP has jumped to a new channel and "start over" with an active scan and association check.

- If you want the STA to disassociate from the current AP (say, after a timeout event described in the previous bullet), then you only need to call configure_bss(NULL).

- To start a new active scan and attempt to rejoin the "new" AP on the previous channel, you can basically copy and paste the content inside the if() clause on Line 292. That tells the join state machine to begin the process again.


vick wrote:

However, the WARP STA does not do this. The STA's console 'j' command lists detected APs and I note that "WARP-AP" still appears on Ch1 (and not 11 as it should be). Even if I type 'j' followed by "WARP-AP", it fails to join the AP now on Ch11.

If I reprogram the AP to operate back on Ch1 again, then the STA joins as it originally did (along with the OSX host).

My interpretation of this is the STA code doesn't seem to re-scan for channels/SSIDs. Especially since I notice "WARP-AP" still appears on the STA's console list, even after I power off the WARP-AP. This was tested on: Mango_802.11_RefDes_v1.5.1.zip

I just looked -- the implementation of the "j" letter UART processing is pretty broken. It slipped through testing prior to release; sorry about that. What you are seeing is a stale list of networks because the "j" processing isn't actually performing a new active scan. It's just showing you the list of networks it knows about. As far as it knows, "WARP-AP" is still on channel 1 since it never tuned to channel 11 to see the "new" network.

Actually getting the "j" implementation to work as-advertised is surprisingly tricky. The active scan uses a hardware timer and interrupts to transition through channels. Because the UART Rx processing is also happening in an interrupt context, it can't "wait" for an active scan to complete -- the scanner can't do anything while in the UART ISR. It's not very elegant, but the easiest fix to this is to break up the scanning and joining in the UART handling. Replace the entire "case ASCII_j:" with the following:

Code:

// ----------------------------------------
// 's' - Scan
//
case ASCII_s:				
	xil_printf("\f");
	
	// Check if node is currently in a scan
	is_scanning = wlan_mac_scan_is_scanning();
​
	// Stop the current scan to update the scan parameters
	if (is_scanning) {
		xil_printf("Stopping Scan\n");
		wlan_mac_scan_stop();
	} else {
		xil_printf("Starting Scan\n");
​
		// Get current scan parameters
		scan_params = wlan_mac_scan_get_parameters();
​
		// Free the current scan SSID, it will be replaced
		if (scan_params->ssid != NULL) {
			wlan_mac_high_free(scan_params->ssid);
		}
​
		// Set to passive scan
		scan_params->ssid = strndup("", SSID_LEN_MAX);
​
		wlan_mac_scan_start();
	}
break;
// ----------------------------------------
// 'j' - Join
//
case ASCII_j:
	uart_mode = UART_MODE_JOIN;
​
	xil_printf("\f");
​
	// Check if node is currently in a scan
	is_scanning = wlan_mac_scan_is_scanning();
​
	// Stop the current scan to update the scan parameters
	if (is_scanning) {
		wlan_mac_scan_stop();
	}
​
	// Print results of the scan
	print_bss_info();
​
	// Print prompt
	xil_printf("Enter SSID to join, please type a new string and press enter\n");
	xil_printf(": ");
break;

With that code snippet, you can press "s" on your keyboard to start an active scan. After waiting some time, then press "j" like normal. It will now have the updated entry showing the new channel. You can then type in the SSID and proceed with the re-association. I just tested this using your same experimental setup of moving an AP from channel 1 to channel 11 and telling the STA to rejoin it without having to reset the STA.

Offline

 

#5 2016-Jun-28 09:58:32

vick
Member
From: Stockholm, Sweden
Registered: 2008-Feb-19
Posts: 79

Re: Change wlan channel during a traffic flow

Hi Chris,

Apologies for the slow response, and a big thanks for your detailed suggestions.

I took the easiest approach and went for the code snippet you provided, which enabled me to do what I want using the 's' plus 'j' combination, to enable an STA to rejoin an AP now on a new channel. That seems to work fine - except when there's user data flowing through the pair of boards. I was hoping to relocate an ongoing UDP stream from ChA to ChB but found this UART keystroke combination approach to not work.

I managed to find a workaround for this so it's not a problem for now. However, I'll take a closer look at the code hints you provided when I need to do this 'more properly' in future.

Thanks again for the suggestions,
vick

Offline

 

Board footer