TDD and FDD

Currently, there are discussions in the Media and most certainly in Boardrooms and Labs about whether forms of FDD should be applied to WiMAX networks and TDD should be applied to LTE networks.

Since it’s once again a hot topic in the industry, I’ve decided to revisit the issue:

An expression used quite frequently in the wireless world over the last few
years is TDD. I would refrain from calling TDD a technical term because it’s more
realistically a marketing expression that’s oxymoronic. TDD stands for “Time
Division Duplexing”. Duplexing in the time domain, isn’t duplexing at all, as those of us
that have been in the radio business for longer than this term has been used, already
know. It is a simplex operation, much like “push-to-talk”, where the channel is shared
by both ends of the communications path. “Push-to-talk” doesn’t sound sexy to most
marketing folks.

Duplex (FDD, Frequency Division Duplexing) systems use different frequencies or
channels for transmission and reception, and the devices used at each end of the
communications path contain duplexers. Duplexed systems require some amount of
frequency separation and the design is based on the amount of circuit “Q” achievable
or economially available, as well as, the amount of available spectrum. They also allow
for simultaneous transmission and reception. Systems that use “Half Duplex” usually
have a duplexer at only one end of the communications path. The 802.11b systems
that we are all familiar with use TDD.

What is most important here is that we understand the significance of the term. Wireless broadband systems that incorporate TDD, have the advantage of operating in
a limited amount of spectrum. A second advantage is that, if we negate the effects of
time, it’s fairly safe to say the propagation path is the same for both ends of the communications link. This second advantage is being capitalized on by some newer systems, which use an adaptive array antenna network to optimize the link from the access point.

TDD is not without it’s disadvantages. Time is TDD’s worst enemy; the system must
switch between transmit and receive, and this takes time. The amount of time depends
on many factors including, but not limited to, the system bandwidth, transmitter power and the ability to predict the exact time to make the transition. Another factor is propagation delay, where the communicating devices must keep the frequency clear for the responding unit while the signal makes “the trip” from one end to the other.

The access point must also have silent periods for service requests from the CPE. The time is dependant on the distance between the access point and the CPE. This system induced latency makes the platform inefficient when compared to FDD systems. If the latency is too great, some TCP/IP clients sense a broken connection. In the case of the old Compuserve, and certainly now VPN’s the browser, email client or a portion of the application must be restarted. VoIP in the form of SIP works quite well when used on many WiFi systems, so the latency is of little concern, there.

A common circuit path can also be problematic, for TDD systems, as it becomes difficult to add amplifiers or frequency converters for the transmitter or receiver individually.

With the aforementioned in mind, can a TDD system be considered “always on”? By
the way, isn’t FDD a redundant expression?

This entry was posted in Uncategorized. Bookmark the permalink.

One Response to TDD and FDD

  1. Ty Kontir says:

    This is a great explanation of TDD and FDD for a “technical PM” and still learning the ropes of the wireless broadband space.

    Thanks Dan!

Leave a Reply