WARP Project Forums - Wireless Open-Access Research Platform

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

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

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)

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).

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.

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)

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"?

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).

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.

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:

wlan_mac_high_set_token_stats_end_callback((function_ptr_t)token_stats_end);

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.

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?