WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2018-Aug-09 14:09:16

lizhuqi
Member
Registered: 2017-Oct-17
Posts: 14

Concurrent flow with 802.11 reference design.

Hi,

I want to use 802.11 reference design to do some concurrent transmission.

For example, I have four warps, A, B, C, D. I want to transmit from A to B at frequency 1 and transmit from C to D at frequency 2.

I am wondering whether I can achieve this by modifying this script??

https://warpproject.org/trac/browser/Re … o_nodes.py

Thanks in advance.

Offline

 

#2 2018-Aug-09 14:56:17

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

Re: Concurrent flow with 802.11 reference design.

Yeah, there are a few ways you could achieve that behavior. They can all be on an ad-hoc network using the IBSS design, or A and C can be APs while B and D are associated STAs. The script you linked two could be extended to support either of those scenarios.

Offline

 

#3 2018-Aug-09 15:42:33

lizhuqi
Member
Registered: 2017-Oct-17
Posts: 14

Re: Concurrent flow with 802.11 reference design.

Thank you for the answer,

I have tried my experiments on fours warps, but I founded that two concurrent links do not scale the throughput. In the code, I have configured the two links at different frequencies. But it seems that they are using media sharing protocol to limit the sending speed. I have attached the screenshot of the result. Do you have any idea about how to solve this problem??

The throughput result when both two flow work:
https://drive.google.com/open?id=1mbZra … 7VpBn9y3Zx

The throughput result when only one works:
https://drive.google.com/open?id=1TtXE8 … apWlR07DxJ

Thanks!!

Offline

 

#4 2018-Aug-10 09:09:21

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

Re: Concurrent flow with 802.11 reference design.

lizhuqi wrote:

In the code, I have configured the two links at different frequencies. But it seems that they are using media sharing protocol to limit the sending speed.

It isn't sufficient they they are on different frequencies for you to get full spatial reuse. The (Node 1, Node 2) pair need to be on an orthogonal frequency to the (Node 3, Node 4) pair (e.g. Channel 1 and Channel 6 or Channel 11). It's also worth trying the 2.4 GHz band on one pair and the 5 GHz band on the other pair just to have another data point. But even if they were all on the same channel, you should still be seeing some throughput from every link. So the problem is more than some out-of-band deferral issue.

You'll have to dig deeper to figure out what's going on to rule out any problems with your test script vs. there being actual unexpected 802.11 behavior issues. Those screenshots don't really tell us any details other than it isn't working the way you expect. Some concrete examples of things to try:

- Lower the LTG packet rate so there is excess capacity on the medium to support all 4 flows. Do the zero throughput flows remain zero throughput? If yes, that points to there being an error in the setup of your experiment. If no, that suggests the OTA behavior itself is doing something unexpected like causing some of your nodes to permanently defer to the backlogged transmissions of others.

- Use the wlan_exp event log to verify that you see TX_HIGH events from the nodes you expect to be transmitting but are getting small or zero throughputs throughputs.

- Replace antennas with SMA terminators to see if you are reliably able to change which nodes are able to achieve a link. So, for example, if you are in the setting that led to your second screenshot and you then terminate the RF connection on Node 1, does repeating the experiment allow either of the Node 3 or Node 4 links start to work?

- This is similar to the SMA terminator test, but using your script you should also try disabling the Node 1 -> Node 2 and Node 2 -> Node 1 LTGs. When you do so do the Node 3 -> Node 4 and Node 4 -> Node 3 LTGs work?

Offline

 

#5 2018-Aug-10 11:08:35

lizhuqi
Member
Registered: 2017-Oct-17
Posts: 14

Re: Concurrent flow with 802.11 reference design.

Thank you for the reply.

The problem of "zero throughput" is because that I disabled the backward traffic generation, (it is not actually a problem)

The real problem I faced is that two flows at two different frequency band seem to interfere with each other.

http://warpproject.org/trac/wiki/WARPLab6/Architecture

I have referred to the link above. It seems that we do not have anti-alias filtering before ADC in the warp hardware design. This may cause the signal from high band aliasing back to our communication band. It will further trigger a medium sharing protocol which degrade the overall throughput.

I don't know whether my hypothesis is correct. Please let me know your thoughts.

Zhuqi

Offline

 

#6 2018-Aug-11 09:30:03

lizhuqi
Member
Registered: 2017-Oct-17
Posts: 14

Re: Concurrent flow with 802.11 reference design.

Hi Chunter,

I did more experiments on the four warp setting and got some new results.

We set the frequency band of two channels as none-overlapped bands (e.g. 1 and 6). But we still can see the degradation of overall throughput, like the result in this figure.

https://drive.google.com/file/d/1ri4dxX … sp=sharing

Then we moved an iron shelf between AB and CD, blocked the direct path from AB and CD. The result is shown in the following figure

https://drive.google.com/file/d/1OIHzCp … sp=sharing

It seems that separation between two concurrent flows actually increases throughput. I think maybe the CSMA protocol in warp sense the incoming power of a very large band, the concurrent transmission pairs at different frequencies can detect power from each other, which triggers time-sharing between two flows at different frequencies.

I am wondering whether this hypothesis is correct. I am also curious about whether this problem can be solved by changing mac low from dcf to nomac.

Best,
Zhuqi

Offline

 

#7 2018-Aug-13 10:02:58

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

Re: Concurrent flow with 802.11 reference design.

It seems that separation between two concurrent flows actually increases throughput. I think maybe the CSMA protocol in warp sense the incoming power of a very large band, the concurrent transmission pairs at different frequencies can detect power from each other, which triggers time-sharing between two flows at different frequencies.

The physical carrier sensing logic in the 802.11 Reference Design on WARP v3 uses the MAX2829 RSSI signal to observe instantaneous Rx power. The RSSI circuit estimates Rx power at baseband after the Rx low pass filters. Thus transmissions on orthogonal channels will be attenuated by the LPF but for high enough Rx power could still trigger physical carrier sensing. You could test this theory by disabling physical carrier sensing (wlan_platform_enable_phy_cs(0) in wlan_mac_low.c : wlan_mac_low_init()).

Offline

 

#8 2018-Aug-13 22:37:40

lizhuqi
Member
Registered: 2017-Oct-17
Posts: 14

Re: Concurrent flow with 802.11 reference design.

Hi murphpo,

Thank you very much for your reply. I have tried to disable physical carrier sensing. The two concurrent flow at different frequency still seems to transmit in time division way.

That means carrier sensing is not the reason for performance degradation of two concurrent flows at different frequencies.

Now, I guess it might be the RTS and CTS packets that lead to this time sharing. I am wondering whether the RTS and CTS packets are spread to the whole 2.4Ghz bandwidth??

Zhuqi

Offline

 

#9 2018-Aug-14 11:04:24

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

Re: Concurrent flow with 802.11 reference design.

RTS/CTS are disabled by default in the design via an RTS threshold of 2000 bytes. So unless you've explicitly turned that feature on, it's not a source of the behavior you are seeing.

I'd like to repeat my suggestion from my earlier response to try tuning one group to 2.4 GHz and the other to 5 GHz and observe any changes in behavior. Depending on the result of that experiment, you'll need to construct an experiment to determine the source of the unexpected capacity splitting. For example, is the lower-than-expected throughput caused by nodes transmitting less often? Or are packets being lost due to collisions? If your nodes are transmitting less often than expected, is that being caused by CSMA deferrals? Or is it being caused by larger contention windows because of losses due to collisions? You can investigate these questions and more by using the wlan_exp log and doing things like explicitly bypassing the binary exponential backoff procedure and fixing contention windows.

Offline

 

Board footer