Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Dave Taht <dave.taht@gmail.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] full duplex wifi?
Date: Tue, 16 Sep 2014 20:08:43 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1409161946350.11481@nftneq.ynat.uz> (raw)
In-Reply-To: <alpine.DEB.2.02.1409161757330.13860@nftneq.ynat.uz>

On Tue, 16 Sep 2014, David Lang wrote:

> On Tue, 16 Sep 2014, Dave Taht wrote:
>
>> It would be very nice to get some TXOPs back:
>> 
>> Is this crazy or not?
>> 
>> http://web.stanford.edu/~skatti/pubs/sigcomm13-fullduplex.pdf
>
> I start of _extremely_ skeptical of the idea. While it would be a 
> revolutionary improvement if it can work, there are some very basic points of 
> physics that make this very hard to achieve.
>
> If they can do it, they double the capacity of existing wireless systems, 
> which helps, but it's not really that much (the multipath directed 
> beamforming helps more)
>
> I'll read though the paper and comment more later.

Ok, they are working on exacty the problem I described. They do a significant 
amount of the work in digital, which is probably why they get an 87% improvement 
instead of a 2x improvement. This also will eat a fair bit of the DSP processing 
capacity.

As they note, this only works with single antenna systems. They list support for 
multi-antenna systems as future work, and that's going to be quite a bit of work 
(not impossible, but very hard)

This will be a great thing for point-to-point infrastructure type links, but 
isn't that useful for more 'normal' situations (let alone high density 
environments)

MIMO multi-destination can provide as much or more airtime saving when you 
actually have multiple places to send the data

think of it as the core frequency vs core count type of tradeoff.

David Lang

>
> warning, radio primer below
>
> the strength of a radio signal drops off FAST ( distance^3 in the worst case, 
> but close to distance^2 if you have pretty good antennas)
>
> you loose a lot of signal in the transition from the antenna wire to the air 
> and from the air to the antenna wire.
>
> The result of this is that your inbound signal is incredibly tiny compared to 
> your outbound signal.
>
> In practice, this is dealt with by putting a very high power amplifier on the 
> inbound signal to make it large enough for our electronics to deal with. to 
> do this effectively for signals that vary wildly in strength, this amplifier 
> is variable, and amplifies all the signals that it gets until the strongest 
> one is at the limits of the amplifier's output.
>
> Because of this, a receiver without a good input filter can get into a 
> situation where it cannot recive it's desired signal because some other 
> signal somewhat near the signal it wants is strong enough to cause problems.
>
> digital signal processing is no help here. If you digitize the signal (let's 
> talk 8 bits for the moment, although 12-14 bits is more common in the real 
> world), and you have one signal that's 100 times as strong as the other 
> (which could be that one is 10 ft away and the other 100 ft away), the near 
> signal is producing samples of 0-255, while the far signal is producing 
> samples 0-2. there's not much you can do to get good fidelity when your only 
> hvae 3 possible values for your data.
>
> Real radios deal with this by having analog filters to cut out the strong 
> signal so that they can amplify the weak signal more before it hits the 
> digital section.
>
> But if we are trying to transmit and receive at the same time, on the same 
> channel, then we are back to the problem of the transmit vs receive power.
>
> Taking a sample radio, the Baofeng uv-5r handheld (because I happen to have 
> it's stats handy)
>
> on transmit, it is producing 5w into a 50ohm load, or ~15v (v=sqrt(P*R)), 
> while it is setup to receive signals of 0.2u volt.
>
> being able to cancel the transmitting signal perfectly enough to be able to 
> transmit and at the same time receive a weak signal on a nearby frequency 
> with the same antenna is a HARD thing to do, and the tools to do so tend to 
> be very finicky (read temperature sensitive)
>
> David Lang
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

  reply	other threads:[~2014-09-17  3:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 16:38 Dave Taht
2014-09-17  1:22 ` David Lang
2014-09-17  3:08   ` David Lang [this message]
2014-09-19  0:18     ` dpreed
2014-09-19  5:55       ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1409161946350.11481@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox