WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#76 2017-Sep-08 08:58:08

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

Re: Experiment with TokenMAC

Those two types of queues at the AP are in addition to the per-RA queues that are set up once STAs are associated with the AP. You can see how the various queues are accessed in the poll_tx_queues() function. In this context the AP cycles through queues to see if anything can be dequeued and passed down to CPU_LOW for transmission.

Regarding testing and characterization, one suggestion I have is to consider using the Debug Header in the User I/O section of the board. If you have an oscilloscope, you can explicitly measure durations between events like transmission, receptions, and any arbitrary point in the C code by adding the code described in the previous link.

Offline

 

#77 2017-Sep-13 10:02:35

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

Re: Experiment with TokenMAC

Many thanks for your response.

In the given section https://warpproject.org/trac/wiki/802.1 … ebugHeader, benchmark code (as shown below) is written only for v1.5.3, as I am currently using v1.3 can you provide the benchmark macros for the version 1.3 please?

Code:

//
// Assert pin 15
wlan_mac_set_dbg_hdr_out(0x80000000); //assert p15
{ /* Benchmark code here */ }
wlan_mac_clear_dbg_hdr_out(0x00000000); //clear p15
//

Many thanks

Offline

 

#78 2017-Sep-14 13:15:17

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

Re: Experiment with TokenMAC

In the v1.3 design the only pins [14, 13, 12] can be controlled from software.

From CPU Low the pins are controlled via the WLAN_RX_DEBUG_GPIO register in the Rx PHY:
REG_SET_BITS(WLAN_RX_DEBUG_GPIO, 0x1); // assert debug pin 12

From CPU High the pins are controlled via an axi_gpio instance. The high framework has helper functions to set pins:
wlan_mac_high_set_debug_gpio(0x1); // assert debug pin 12

The actual debug pins are driven by the logical OR of the two CPU's settings for the pin. If one CPU asserts a pin, the debug pin will be high, even if the other CPU sets it low.

It's possible I got bit orders backwards above - I'd suggest trying these functions and testing which pins assert with your oscilloscope.

Offline

 

#79 2017-Sep-28 11:04:59

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

Re: Experiment with TokenMAC

I have following query regarding calculation of STA queue length.

I need to calculate the amount of packets that needs to be unicasted to the AP at each STA, this can be identified as
current_sta_qsize = queue_num_queued(UNICAST_QID);
This is defined in a function within mac_sta.c.

As this fucntion can only be called at mac_sta.c and I pass 'current_sta_qsize' as an extern global variable defined in mac_high.c. Since I need the value 'current_sta_qsize' to be used in mac_ap.c currently this is done using a called back at the start/end of the IPC variables NEW RESERVATION/END_RESERVATION (from CPU Low to CPU High) using a callback function. Actually in an ideal situation I need to invoke this function from any point from mac_ap.c.

Once debug the code (using 'xil_printf') it seems this method does not update the global variable.
Can you advise on this please.

Thanks

Offline

 

#80 2017-Sep-28 12:10:46

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

Re: Experiment with TokenMAC

The AP does not have a single unicast queue. The AP maintains a queue for management packets (some of which are unicast) and a dedicated queue for unicast packets to every associated STA. In the AP code you can call "queue_num_queued(queue_id)" anywhere in the code, using helper macros to translate the associated STA's AID to a queue ID, like this line in the v1.3 AP code.

Offline

 

#81 2017-Sep-29 04:50:09

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

Re: Experiment with TokenMAC

Many thanks for your prompt response.
What I am interested in is not the AP maintained (downlink) STA queues, but the uplink data queues in STA. When there is data at the STA that needs to transmitted (Unicasted) to the AP (such as in the uplink case). This can be obtained by the code 'queue_num_queued(UNICAST_QID);' at wlan_mac_sta.c. But I need this to be called in wlan_mac_ap.c instead. Can you point me how to achieve this please?

Thanks again.

Offline

 

#82 2017-Sep-29 09:20:33

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

Re: Experiment with TokenMAC

I'm afraid I don't understand. The wlan_mac_ap.c source file is not compiled or executed by the STA software project. The top-level source file for the STA project is wlan_mac_sta.c.; wlan_mac_ap.c is the top-level source for the AP project. These two files are never compiled as part of the same project.

Offline

 

#83 2017-Oct-04 03:58:01

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

Re: Experiment with TokenMAC

Hi Murphpo,
Many thanks for this clarification.
Is there a way to pass a value between the two source projects; AP project and STA project? In other ways passing a value between wlan_mac_sta.c and wlan_mac_ap.c.

Thanks

Offline

 

#84 2017-Oct-04 12:55:53

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

Re: Experiment with TokenMAC

As murphpo said, the AP and STA projects do not exist simultaneously on a single programmed board. The board's role is one or the other. If you want a STA node to have some value from an AP node (i.e. two different boards each with their own project), then you have to create a data frame to send between them and put the value in the payload of that data frame.

Offline

 

#85 2018-Jan-22 05:37:24

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

Re: Experiment with TokenMAC

Hi,
I have successfully implemented the operation of two different MACs in the same design and managed to call each MAC based on the position of the DIP switch.

For example for a given position of DIP switch value DCF is called and for another position of the DIP switch scheduled_MAC is in operation. This is achieved by switching to the preferred MAC based on the DIP switch position similar to the suggestion of using a global variable. In current state this runs one MAC at a time as the DIP switch is set in both AP and STA to the preferred MAC position and once the FPGA is programmed, the corresponding MAC is called accordingly.

My question is that I need to switch between the two MAC implementations within the same operation or in the real time.
For this to happen I would need to interrupt each MAC operation after a certain time of operation (in every 100ms) or wait until each MAC cycle finishes. Once each MAC is called how do I find out the end of the operation? Do I need to check the packet buffers/queues etc?
Could you please give some guidance and discussion on this issue please.

Thanks in advance

Offline

 

#86 2018-Jan-22 10:25:52

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

Re: Experiment with TokenMAC

warp_user wrote:

My question is that I need to switch between the two MAC implementations within the same operation or in the real time.
For this to happen I would need to interrupt each MAC operation after a certain time of operation (in every 100ms) or wait until each MAC cycle finishes. Once each MAC is called how do I find out the end of the operation? Do I need to check the packet buffers/queues etc?
Could you please give some guidance and discussion on this issue please.

I think it would be safe to make the switch in the main while loop of either MAC. In that loop any existing transmission has fully completed (e.g. the DCF will have completed a transmission and any necessary retries before returning to the main loop).

Before making the switch, you'll need to update the callbacks that occur at the top of the main function. Then, when wlan_mac_low_poll_frame_rx() or wlan_mac_low_poll_ipc_rx() is called the appropriate MAC's Rx and Tx functions are called.

Offline

 

#87 2018-Jan-23 05:48:21

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

Re: Experiment with TokenMAC

In the current design there is only one main() function to access the relevant MAC. Each MAC is defined as separate source files (*.h and *.c file) within the same project. Relevant sections of each file is as below. Could you please suggest a method of switching based on this design between MAC during real time in a single operation? Many thanks

This is the relevant pseudo code in main()

Code:

while(1){
		if(DIP SWITCH Position 1) {
			main_NONDCF();
			}
		if(DIP SWITCH Position 2) {
			main_DCF();
			}
		}

Relevant code in the first MAC: main_DCF()

Code:

main_DCF() {
wlan_mac_low_set_frame_rx_callback((void*)frame_receive_DCF);
wlan_mac_low_set_frame_tx_callback((void*)frame_transmit_DCF);

while(1){
	//Poll PHY RX start
	wlan_mac_low_poll_frame_rx();

	//Poll IPC rx
	wlan_mac_low_poll_ipc_rx();
	}
}

Relevant code in the second MAC: main_NONDCF()

Code:

main_NONDCF() {
	wlan_mac_low_set_frame_rx_callback((void*)frame_receive_NONDCF);
	wlan_mac_low_set_frame_tx_callback((void*)frame_transmit_NONDCF);

	while(1){
		poll_reservation_time();

		//Poll PHY RX start
		wlan_mac_low_poll_frame_rx();
		//Poll IPC rx
		wlan_mac_low_poll_ipc_rx();
		}
}

Offline

 

#88 2018-Jan-24 11:05:34

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

Re: Experiment with TokenMAC

Hi,
Are there any example designs where multiple APs are considered? I need to implement a functionality between AP and a STA similar to handover where a single AP will disassociate from one AP (AP1) and then associate with another AP (AP2) operating on a different channel.
Is this something already in the current WARP 802.11g design? In effect plan is to design an AP controller coordinating multiple APs.
Thanks in advance

Offline

 

#89 2018-Jan-24 15:55:42

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

Re: Experiment with TokenMAC

warp_user wrote:

In the current design there is only one main() function to access the relevant MAC. Each MAC is defined as separate source files (*.h and *.c file) within the same project. Relevant sections of each file is as below. Could you please suggest a method of switching based on this design between MAC during real time in a single operation? Many thanks

There are a lot of ways to achieve this. In general, you'll need to return out of the while() loop from one of the submain functions and back to the top-level main() whenever some criteria is met (e.g. after some duration of time has elapses while polling the System Time). Once returned, your while() function in your top-level main() can recognize this has occurred and jump into the submain function of the other MAC. One gotcha that you should watch out for: much of the MAC Low Framework initialization function calls at the top of the main_NONDCF() and main_DCF function() should only be called once at boot. You don't want to call them each time you switch between the MACs. I would pull these calls out of the submain functions and insert them at the top of your top-level main(). Really the only thing that needs to be called on each switch is the setters for the Rx and Tx callbacks.

warp_user wrote:

Are there any example designs where multiple APs are considered? I need to implement a functionality between AP and a STA similar to handover where a single AP will disassociate from one AP (AP1) and then associate with another AP (AP2) operating on a different channel.
Is this something already in the current WARP 802.11g design? In effect plan is to design an AP controller coordinating multiple APs.
Thanks in advance

No, we don't support any Extended Service Set (ESS) behaviors at this time. That's been a low priority for us since we've found that virtually all modern Wi-Fi stations are smart about jumping to a new AP if it has a stronger signal. For example, a modern phone will seamlessly jump from one AP to another AP if they share the same WARP-AP SSID. No special behaviors are needed in our AP to enable this. However, our STA implementation does not do this automatically. It would be straightforward to modify the STA to monitor the quality of its link to its BSS using whatever metric of your choice and then have it trigger a new active scan and join like it does at boot once that metric falls below some tolerable threshold. You'd also need to modify the active scan and join to join the best AP it finds if more than one exists with the same SSID. Currently, the STA will attempt to join the first AP it finds that matches the SSID criteria.

Offline

 

#90 2018-May-02 09:50:35

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

Re: Experiment with TokenMAC

I would like to introduce a basic power control to AP and STA.
Both in AP and STA transmit power is a fixed value at 15dBm. I want to test with different values first. What is the maximum transmit power that can be applied without overloading the radio? 

Code:

#define  WLAN_DEFAULT_TX_PWR                     15

In addition if you can provide some thoughts on implementing power control algorithm on 802.11g will be appreciated.

Thanks

Offline

 

#91 2018-May-02 13:51:36

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

Re: Experiment with TokenMAC

You can safely set that power to anything in the range of -9 to 21 dBm. If you set it to anything outside that range, the underlying framework will automatically lower the value to 21 or raise the value to -9.

Note: we leave the default at 15dBm despite there being some extra headroom in the PA in order to keep Tx EVM down. See the Tx EVM characterization.

Offline

 

#92 2018-Jun-04 10:56:01

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

Re: Experiment with TokenMAC

I have been working on merging DCF and nonDCF MAC design into run as a single model and successfully implemented the operation of two different MACs in the same design (selection of each MAC is based on the position of the DIP switch). Many thanks for the advise and guidance provided in completing this which is based on CPU Low functions. 

With respect to CPU High functions I tried the same concept in deciding AP and STA functions that needs to be called in DCF and nonDCF MAC designs.
This takes a similar pattern for both AP and STA functions as defined in wlan_mac_ap.c and wlan_mac_sta.c.

while(1){
        if(DIP SWITCH Position 1) {
            AP/STA_NONDCF();
            }
        if(DIP SWITCH Position 2) {
            AP/STA_DCF();
            }
        }

In the case of nonDCF there are some additional callback functions generated as token request and token response are required to generate in the nonDCF model.

This works well when run with the DIP switch in one position, for example when DCF all the way or nonDCF all the way without switching between the MACs.

I have extended the design to accommodate change of DIP switch and encountered several issues. I assumed before any MAC is called AP and STA has to to agree on the following:
(a)    AP and STA Authentication
(b)    AP and STA Association

These are done at the initialisation of AP and STA (done only once at the beginning).

First I have tested/debugged when DIP switch position change from nonDCF to DCF.
During nonDCF phase both AP and STA performs successfully (tested using Ethernet bridge setup).
Once changed from DCF to nonDCF there are still beacon signals coming from the AP but there is no association from STA side.


I have noticed during a successful AP/STA association phase the following function is used to get a response from the AP and (definitely occurs at the start during nonDCF phase) but once changed the DIP switch position to DCF this function is not called.
Both AP and STA boot completes and there is association between AP and STA (LED displays ‘1’).


Code:

void mpdu_rx_process(void* pkt_buf_addr) {

case (MAC_FRAME_CTRL1_SUBTYPE_ASSOC_RESP):
// Association response
.....
break;

Can you please let me know what are the implications that can happen when switched between different MAC designs and any advise and suggestions to help solving this problem is highly appreciated.


Many thanks

Offline

 

#93 2018-Jun-05 15:28:48

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

Re: Experiment with TokenMAC

It might be worth ruling out OTA association handshakes before debugging further. The wlan_exp Python framework can explicitly set the association state of the STA and AP, so you can jump directly to the post-associated state to see if you are still seeing a lack of receptions.

Furthermore, you'll want to make sure your nodes don't try to automatically associate at boot. You can do this by raising the leftmost bit on the DIP switch of the User I/O section of the board. If that bit is raised while the node is booting, the AP and STA designs will boot up inert and wait for the BSS to be configured via wlan_exp.

Offline

 

#94 2018-Jun-06 03:44:49

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

Re: Experiment with TokenMAC

Many thanks for your sugesstions, I will follow them through.
Regarding the point you made on leftmost bit on the DIP switch of the user I/O, is it valid for version 1.3 (this is the design I am currently using)?

Offline

 

#95 2018-Jun-06 10:52:40

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

Re: Experiment with TokenMAC

I think so. I was looking through the changelog and it seems we added that functionality in the 1.0 release.

Offline

 

#96 2018-Jul-26 09:57:46

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

Re: Experiment with TokenMAC

Hi,
I am still having problems in association between AP and STA when MAC is switched among DCF and non-DCF.
For testing purposes I use hard association between AP and STA with hardcoded MAC addresses.

Once AP and STA are already assigned (hard association) it can be seen beacon generation function is still needed for DCF and non-DCF transmission. My understanding is need of beacons are only for auto association purposes.
Can you please explain the purpose of following beacon functions in the AP code.

Thanks in advance


Code:

//				beacon_schedule_id = wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, (my_bss_info->beacon_interval * BSS_MICROSECONDS_IN_A_TU), SCHEDULE_REPEAT_FOREVER, (void*)beacon_transmit);
				//  Periodic check for timed-out associations
//				wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, ASSOCIATION_CHECK_INTERVAL_US, SCHEDULE_REPEAT_FOREVER, (void*)association_timestamp_check);

Offline

 

#97 2018-Jul-26 10:51:11

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

Re: Experiment with TokenMAC

My understanding is need of beacons are only for auto association purposes.

Beacons serve multiple purposes in 802.11. APs use beacons to advertise BSS parameters, including MAC and PHY capabilities. The periodic transmission of beacons also permits power-saving STAs to sleep between beacons, waking up only to check if the new beacon indicates the AP has packets to send to that STA. All nodes use beacons to synchronize their MAC Times ("TSF" in 802.11 lingo).

Code:

//				beacon_schedule_id = wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, (my_bss_info->beacon_interval * BSS_MICROSECONDS_IN_A_TU), SCHEDULE_REPEAT_FOREVER, (void*)beacon_transmit);

This call sets up a scheduled event in CPU High to periodically create a new beacon and enqueue it for transmission.

Important note - the current (v1.7.7) 802.11 Ref Deign for WARP v3 does not use this code. We redesigned the beaconing code in v1.5 to move beacon transmission control to the DCF code in CPU Low. CPU High still defines beacon contents (via IPC messages), but CPU Low is responsible for scheduling the actual beacon Tx. This change was required to adopt the proper 802.11 behavior wherein a beacon might be transmitted in between re-transmissions of a non-beacon packet (i.e. to transmit at the required Target Beacon Transmission Time (TBTT)).

Offline

 

#98 2018-Jul-30 03:00:08

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

Re: Experiment with TokenMAC

Many thanks for the explanation on beacon transmission.
While debugging the code it can be seen that when MAC is switched from non_DCF (in this case Token MAC) to DCF in the AP side there are still new reservation requests are generated. May be this is the reason that during DCF, AP does not associate with the STAs.
Is there a way to terminate the IPCs which create new reservations once MAC is switched to DCF?

Thanks in advance

Offline

 

#99 2018-Jul-30 08:46:36

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

Re: Experiment with TokenMAC

There is no safe way to delete IPC messages in the mailbox after they have been sent. The mailbox hardware implements a 32-bit-wide FIFO. The 802.11 code wraps this with a simple multi-word message format which assumes complete messages are always transmitted and received. If you reset the mailbox at runtime it is possible the other CPU will have written/read a partial message and would then get stuck. Your best option is to figure out a scheme to ignore IPC messages rather then delete them.

Offline

 

#100 2018-Jul-30 08:52:25

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

Re: Experiment with TokenMAC

Not really. Once the IPC message has been fired off there isn't a good way to claw it back without having a bunch of really difficult race conditions to deal with. You'll have to make your design robust to changes that happen while one of those messages is in flight. If you have successfully switched to the DCF, CPU_LOW should ignore any vestigial TOKEN_NEW_RESERVATION messages sitting in the mailbox.

If there are packets in the Tx packet buffers in CPU_LOW waiting to be sent at the time of the switch, how are you getting the DCF to start sending them? CPU_HIGH won't try to send any more IPC_MBOX_TX_MPDU_READY messages if it has already filled in the ping/pong packet buffers. It's up to CPU_LOW to finished sending those packets before CPU_HIGH will dequeue anymore.  Something like that could lead to the behavior you are seeing. The AP would be waiting on the DCF to finish sending packets it passed down a while ago while the DCF is waiting for the AP to send it more packets.

Offline

 

Board footer