# [USRP-users] FDD transmission with b210?

Marcus Müller marcus.mueller at ettus.com
Mon Mar 28 16:09:59 EDT 2016

Hi Ernest,
sorry for the delay!

First of all: I think I might have misunderstood your first email; with
Full Duplex, you were hinting at same-frequency full duplex
applications, right?

4G does use a pretty flexible OFDM scheme -- each user can be assigned a
set of "ressource blocks" in the time-frequency domain.
However, it still uses separate up- and downlink bands, it just shares
these bands among the different users.

Really, if you want to build a very sensitive receiver, you'd want to
keep your transmitter, which is bound to be an easy 60dB more powerful
you're power-constrained (which LTE handsets definitely are); no matter
how well you can "ignore" your TX signal in the digital domain, your RX
amplifier would need to stay linear in the face of the full min(RX
signal)–max(TX signal) dynamic range. A nowadays often discussed
approach is simple self-cancellation in the analog domain.

Now, same-frequency full duplex radio is a currently very hot topic in
research (again, I guess). I remember doing a bit of exemplary math on
that; The Email is in the USRP-users mailing list archives [1].
The original question why the B210 doesn't include any self-cancellation
circuitry, so that same-frequency full duplex operation would be
possible. To explain my (and others') answer in a nutshell:
Self-cancellation is very application- and frequency-specific, and
hence, can't be implemented on a /universal/ software defined radio
peripheral. Also, even assuming a really bad way of dividing one
frequency band in two half-bands (and leaving one third of spectrum
unused, i.e. wasting one third of spectrum), and even neglecting the
non-linearization effects of strong self-interference, you'd need much
more cancellation than what the original paper[2] the email exchange
referred to was able to demonstrate.
I'll just paste the important calculation of my mail on that topic
below; hope that is an interesting read!

Best regards,
Marcus

[1] "On the full-duplex ability of B210", December '15
[2] http://sing.stanford.edu/fullduplex/
> The upper boundary for the number of bits that you can get across any
> channel per second is given by Shannon's capacity C.
> So let's just consider RX:
> to the RX signal (these assumptions lead to a best-case for the
> same-frequency full-duplex):
> $C_\text{same > freq.}=B\log_2\left(1+\text{SNR}_{\text{TX}\rightarrow\text{RX}} \right)$,
> with $B$ being the full used bandwidth, and
> $\text{SNR}_{\text{TX}\rightarrow\text{RX}}$ being the ratio of RX
> signal power to power of unsuppressable TX signal, which we assume to
> quantization noise.
> Now, let's simply take one half of the bandwidth for up- and one for
> downlink. Let's assume that means that we only get one third of usable
> bandwidth, because in this world, the perfect rectangular filter
> doesn't exist, but that we, as a side effect, only see out-of-band
> emissions/filter sidelobes of the TX signal at a power of $\frac1a$ of
> the original TX power:
> $C_\text{halfband channels}=\frac13 > B\log_2\left(1+a\text{SNR}_{\text{TX}\rightarrow\text{RX}} \right)$.
>
> Let's have a look at a comparison of what's possible with either:
>
>
> \documentclass{article} \usepackage[utf8x]{inputenc}
> \usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb}
> \usepackage{trfsigns} \DeclareMathOperator*{\argmin}{arg\,min}
> \usepackage{tikz} \usepackage{circuitikz}
> \usepackage[binary-units=true]{siunitx} \sisetup{exponent-product =
> \cdot} \DeclareSIUnit{\dBm}{dBm} \newcommand{\imp}{\SI{50}{\ohm}}
> \newcommand{\wrongimp}{\SI{75}{\ohm}} \pagestyle{empty}
> \begin{document} \begin{align*} \frac{C_\text{halfband
> channels}}{C_\text{same freq.}} &= \frac{\frac13
> B\log_2\left(1+a\text{SNR}_{\text{TX}\rightarrow\text{RX}} \right)}
> {B\log_2\left(1+\text{SNR}_{\text{TX}\rightarrow\text{RX}} \right)}\\
> &= \frac13
> \frac{\log_2\left(1+a\text{SNR}_{\text{TX}\rightarrow\text{RX}}\right)}{\log_2\left(1+\text{SNR}_{\text{TX}\rightarrow\text{RX}}
> \right)} \end{align*} \end{document}
>
> Typical values of $a$ might be let's say $10^3$, if you used mediocre
> to really bad filters; with SDR and a sufficiently well-configured
> B210, a few orders of magnitude higher would seem plausible, too.
> So here's a plot of the ratio given above for different
> $\text{SNR}_{\text{TX}\rightarrow\text{RX}}$ (source code attached):
> capacity comparison
>
> As you can see, the same-frequency full duplex TX-self-cancellation
> approach is only better than a really cheap two-frequency FDD if your
> S(i)NR after the cancellation is bigger then let's say 15dB (30dB
> terrible-filtering FDD) or 25dB (50dB mediocre filtering FDD). But
> what is a realistic value for this S(i)NR?
>
> Assuming a TX power of 10dBm, and a RX signal strength of -50dBm
> (==60dB dynamic between RX and TX, ie. 60dB path loss in a symmetric
> setup, eqv. to , which happens to coincide with what the authors
> assume in their Mobicom paper), and taking the 45dB they attest a
> "industrial grade" Balun-based cancellation, the get a meagre -15dB of
> S(i)NR. Which means that FDD is better by a factor of ~40 (30dB
> out-of-channel suppression in FDD), or ~90 (50dB).

On 23.03.2016 20:02, Ernest Szczepaniak wrote:
> Dear Marcus,
>
>
> My question was asked from PHY designing perspective. When im looking
> at baseband, pre IFFT frame (in frequency domain), I can assign
> carriers for the whole system (these carrier indices are used for
> respectively), making it more flexible for the future. It could be
> done by tunning RX and TX to different frequencies, but now, carrier
> indices have to be calculated for both sides independently (dunno if
> you understand this way of thinking :D ). And this, as you said, is
> achievable from hardware perspective.
>
> Im trying to make a system similar to 4G style.
>
> And now correct me if im wrong.
>
> Does LTE FDD mode works that way? (transmitter and receiver working on
> same frequency). Or is it just impossible to be done? I read that in
> constellation mapping, and after that, even so called "distribution
> carriers. I think it would be impossible to receive this with TX and
> RX working on different frequencies. Correct or not?
>
> Im curious after this movie:
>
>
> Best regards,
> Ernest
>
>
>
> 2016-03-23 16:07 GMT+01:00 Marcus Müller <usrp-users at lists.ettus.com
> <mailto:usrp-users at lists.ettus.com>>:
>
>     Dear Ernest,
>
>     On 23.03.2016 12:19, Ernest Szczepaniak via USRP-users wrote:
>     > Does B210 supports full duplex transmission?
>     Yes!
>     > Any reference to detailed information about how it is realized onboard?
>     Well, on the ettus.com <http://ettus.com> product page you'll find
>     the product brief PDF
>     with a schematic. You'll notice that all parts in the signal chain are
>     fully duplexed (which is true down to everything but the USB interrupt
>     handling in the USB controller processor).
>     So maybe you could specify that question.
>     >
>     > Is it possible to design system like this? (thats my mathworks
>     topic)
>     >
>     >
>     >
>     Well, the idea of FDD is that, yes, signals overlay each other in
>     time,
>     but not in time domain, so you can just build a receiver that listens
>     only to specific frequencies, and not the ones it's transmitting on.
>
>     From a hardware perspective, when doing FDD, you're always tempted to
>     tune RX so that the TX is not even in RX's analog input, which could
>     otherwise lead to nonlinearity, and hence, RX distortion, due to the
>     fact that sensitive receivers become non-perfect when exposed to high
>     powers (like the crosstalk from the TX antenna at the same frequency).
>
>     Now, I've seen FDD be done with USRPs, and I think it's easy to do, as
>     long as the sender and receiver aren't too far apart even with RX
>     and TX
>     tuned to the same frequency. For more complicated situations, one
>     would
>     calculate the TX and RX as two separate passbands, and use the
>     fact that
>     you can use analog filters to limit the crosstalk.
>
>     Can you give us a few corner data of your planned FDD setup?
>
>     Best regards,
>     Marcus
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2428 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 607 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1122 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 586 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2826 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5985 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 571 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 699 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 80977 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160328/63dfa564/attachment-0008.png>