Network and Telecom Strategies Blog

Comparing beamforming technologies

posted by: Paul DeBeasi

This is the fifth post in a series that delves into the subject of beamforming.   In this post, we compare all three beamforming methods (static, transmit, dynamic). 

Although all three beamforming technologies provide SNR gain, they are quite different. In addition, all types of beamforming can exacerbate the following problems:

Sticky client problem: The sticky client problem occurs when stations (STAs) remain associated with a distant AP (i.e., when they are “stuck” to an AP), even when a closer AP can offer the STA a better data rate or voice call quality. 

Hidden node problem: The hidden node problem typically occurs when one or more STAs on the same channel cannot “hear” one or more of the other STAs, resulting in channel interference. In some beamforming instances, this can also be true of STAs not hearing the AP.  

A static beamforming array, such as the Xirrus product, is useful in dense deployments such as a large conference room. In addition, a directional antenna can be used to form a static beam to direct energy down a hallway or toward the interior of a building.

The extent to which transmit beamforming (TxBF) will reliably improve SNR is dependent on many factors such as the effectiveness of sounding the channel between the AP and the STA. The WLAN industry is in the early stages of TxBF deployment and I expect that the industry will gain useful real-world experience with Cisco’s proprietary TxBF solution (ClientLink). I also anticipate that silicon vendors will eventually integrate standards-based TxBF mechanisms once the IEEE ratifies implicit and/or explicit beamforming.

Dynamic beamforming is useful in many deployments because it can provide SNR gain for all STA types in the uplink and downlink directions. Since dynamic and transmit beamforming operate in ways that are complimentary, it is conceivable that future enterprise products will combine both techniques to provide even greater SNR gain. Dynamic beamforming will not likely become widely deployed unless WLAN silicon vendors support this feature, thus driving down development cost and complexity.  

Refer to the chart for a more detailed comparison of each beamforming method. 

 Chart: Beamforming comparison

Dynamic beamforming

posted by: Paul DeBeasi

This post continues my discussion of beamforming and in this post we discuss dynamic beamforming. 

Dynamic beamforming focuses RF energy in a particular direction and with a particular shape in order to increase the SNR. In a sense, it is like static beamforming in that it focuses RF energy, but it is different because the antenna array’s radiation pattern can change from frame to frame (see Figure).

 

Figure 1: Dynamic beamforming

Dynamic beamforming is also different from TxBF in several ways because it can:

* Dynamically change the propagation pattern on a frame-by-frame basis in order to optimize the pattern for every STA over time

* Provide SNR gain for both legacy and 802.11n STAs without requiring any changes in the STA

* Be used in conjunction with other 802.11n performance-enhancing techniques such as spatial multiplexing

* Improve both downlink and uplink performance

* Provide interference rejection

Dynamic beamforming has the potential to offer the highest SNR gain of the three beamforming technologies. Note that broadcast traffic, such as Beacon frames, will usually be transmitted using an omnidirectional pattern in order to communicate with nearby STAs in all directions. The only vendor currently offering an enterprise class dynamic beamforming technology is Ruckus Wireless.

Next time we will compare all three beamforming methods. 

Transmit beamforming

posted by: Paul DeBeasi

In this post, we continue my discussion of beamforming by focusing on transmit beamforming. As previously mentioned, beamforming is a method of concentrating radio frequency (RF) energy in order to improve the signal to noise ratio (SNR) at the receiver, thereby improving network performance and predictability.   

Transmit beamforming (TxBF) is a method of transmitting two or more phase-shifted signals so that they will be in-phase at particular points in space where the transmitter believes the receiver to be, thereby increasing SNR. Two forms of TxBF are optional components of the IEEE 802.11n draft amendment to the 802.11 standard.  Explicit and implicit TxBF require feedback from 802.11n stations (STA) and thus will not operate with legacy stations at all. Enterprise WLAN vendors do not support implicit and explicit TxBF at this time because the 802.11n chipsets do not currently support either form of TxBF.

Cisco has introduced a proprietary form of TxBF called ClientLink. ClientLink can work with 802.11b/g/a STAs because it requires no modifications in the STA. ClientLink is designed to improve the SNR for legacy STAs in the downlink (AP-to-STA) direction only. A boost in SNR can improve the STA’s “rate over range” performance because the modulation rate for 802.11 STAs will increase as the SNR increases. Improving rate over range performance is particularly important for legacy STAs because they can consume considerably more airtime than 802.11n STAs, and therefore can reduce the achievable throughput of 802.11n STAs. Alternatively, Air Time Fairness (ATF) mechanisms can also regulate legacy STA airtime consumption.

TxBF changes the phase of the original signals in relation to each other and transmits the phase-shifted signals using two or more antennas to the STA (see figure). As the signals propagate through the air, they additively combine at various points in space.  The figure shows an example of two out-of-phase signals propagating from an AP to a legacy STA. The green dots represent the points in space where the two out-of-phase signals combine to form a signal with an SNR that is up to 3 dB higher than (i.e., twice as high as) the original signal. In a multipath-rich environment, even higher levels of gain are theoretically possible. Cisco is the first enterprise WLAN vendor to implement TxBF, and it claims it can achieve 4 to 6.5 dB of SNR gain in a multipath-rich environment. A 6.5 dB gain is an increase of approximately 4.5 times the original signal.

 

Figure 1: Transmit beamforming

The challenge with TxBF is figuring out how to modify the transmit signal phases for the greatest possible gain. In the ClientLink implementation, the AP uses frames received from the STA in the uplink direction to determine how to modify the phase in the downlink direction. TxBF assumes that the uplink channel characteristics and the downlink channel characteristics are “reciprocal” (i.e., the same) in both directions. In reality, the uplink and downlink channels may not be reciprocal, especially when the STA is moving. So, in practice, TxBF performance gains will vary from moment to moment and STA to STA.

Unlike static and dynamic beamforming, TxBF does not change the antenna radiation pattern. Cisco’s TxBF implementation uses omnidirectional antennas that cause the signals to radiate in a doughnut-shaped pattern. Therefore, referring to TxBF as “beamforming” is somewhat misleading because it does not actually form a directed beam. Cisco’s TxBF achieves an SNR gain at “points in space” (i.e., the green dots in the figure). So the receiving STA must be located at the right point in space in order to achieve the maximum SNR gain. In contrast, static and dynamic beamforming achieve SNR gain throughout the radiated coverage area because both techniques focus the radiated energy.

TxBF and spatial multiplexing are mutually exclusive. This is because spatial multiplexing transmits different signals on each antenna, whereas TxBF transmits the same (phase-shifted) signals on each antenna. So, it is impossible to use TxBF and spatial multiplexing at the same time. That is why enterprises should use TxBF to provide SNR gain for legacy STAs only. In contrast, static and dynamic beamforming can operate in conjunction with spatial multiplexing.

Next time, we will look at dynamic beamforming. 

AT&T Reaches for Your Wallet - Again

Posted by Michael Disabato

AT&T has finally admitted New York and San Francisco have network problems. I wonder when they’ll admit the rest of their network is in the tank as well.

Before you reach for the reply key, remember one really important thing: this is not the old AT&T where proper engineering was de regeur. The old AT&T would not be having these problems. This is the NEW AT&T, otherwise known as SBC. And SBC always had this kind of problem. SBC did it on the cheap, cutting corners where they could without regard to customer service.

I watched them take Ameritech and kill the excellent service we had. I watched them take AT&T wireless into Cingular and repeat the process. And now we are reaping what they have sown.

The old AT&T might have realized the iPhone is a game changer, and they might just have to upgrade in advance of its release. The new AT&T only saw customer lock-in and more revenue. AT&T has not reduced churn because of its network. It’s reduced churn because the iPhone is exclusive to it. Once that agreement dies, and it will, the churn rate will go through the roof.

As for the network, AT&T is now whining that iPhone users consume more bandwidth than their other smartphone users. No kidding. Their other smartphones can’t stream video, download apps, or use location services, all of which suck bits over the air. Did they think we were going to buy these things and just look at them??? Yeah. Right.

So to compensate for their poor planning, they plan to raise rates. I wouldn’t have a problem with that if the service improved, but it won’t. So I’ll end up paying more and getting less. So will you.

It’s time to end the exclusive lock-ins with the mobile operators. If customers were free to vote with their wallets, the network load would even out. Of course, that’s not going to happen, because AT&T will lose revenue.

It’s up to you, folks. Get on your congress critters to change this around and give us control of the devices we’ve paid for. Make sure you tell AT&T what you think of their price increases, and if all else fails, jailbreak the phone and go to another carrier.

It’s your wallet.

Michael

Static beamforming

posted by: Paul DeBeasi

This post continues my discussion on beamforming.  Beamforming is a method of concentrating radio frequency (RF) energy in order to improve the signal to noise ratio (SNR) at the receiver, thereby improving network performance and predictability.  In this post, we discuss static beamforming. 

Static beamforming provides a fixed radiation pattern by using a directional antenna. Virtually every vendor provides APs with removable antennas so it is easy to swap an OMNI antenna for a directional antenna. Some vendors, such as Xirrus, use an array of static beamforming antennas to create densely packed multiple channels in much the same way that a cellular tower uses directional antennas to create cellular sectors. By assigning a different channel to each beam, many non-overlapping channels can be densely packed together within a single array (see Figure).

 

Figure 1: Static beamforming

Static beamforming can provide an signal-to-noise (SNR) benefit to both legacy wirless protocols like 802.11a/b/g and newer 802.11n stations.  Since the antenna propagation pattern is static, the AP cannot adjust the radiation pattern on a frame-by-frame basis in order to track a station as it moves through the enterprise. Therefore, unlike transmit beamforming and dynamic beamforming, it does not take advantage of knowledge of the WLAN channel between the AP and the station in order to further optimize signal propagation. An array of directional antennas, such as the Xirrus Array, can improve SNR in 360 degrees. 

Next time we'll look at Transmit beamforming. 

Introduction to beamforming

posted by: Paul DeBeasi

Beamforming is a method of concentrating radio frequency (RF) energy in order to improve the signal to noise ratio (SNR) at the receiver, thereby improving network performance and predictability. Enterprise WLAN vendors are now integrating beamforming technology into their access points (APs) so it is important to understand the types of beamforming and the benefits that beamforming can provide. 

Beamforming is not new.  At the most basic level, beamforming affects the radiation pattern of a wireless signal.  The radiation pattern refers to the way in which the electromagnetic waves propagate outward from the antenna element. For example, the most commonly deployed antenna is the omnidirectional antenna. The radiation pattern for the omnidirectional antenna is in the shape of a doughnut (see Figure 1). This type of antenna is a good choice for hotspots or any environment where the intent is to propagate the WLAN signal in a broadly dispersed pattern. 

Figure 1: OMNI antenna radiation pattern

WLAN venders currently offer three types of beamforming.  Each type affects radiation patterns in different ways.

Static beamforming involves the use of internal or external antennas that have a fixed radiation pattern (such as a YAGI antenna) that emits a directional radiation pattern (see Figure 2).  A directional pattern is a good choice in environments where the intent is to propagate the WLAN signal in a particular direction, such as down a hallway or toward the interior of a building.

Figure 2: Directional antenna radiation pattern

Transmit beamforming propagates two or more phase-shifted copies of a signal on a frame-by-frame basis, so that they will be in-phase at particular points in space where the transmitter believes the receiver to be, thereby increasing SNR.

Dynamic beamforming changes the antenna radiation pattern on a frame-by-frame basis using a central processing unit (CPU) controlled antenna array in order to increase the SNR at the receiver.

In subsequent posts we will look at each of the beamforming types.  Next time, we will look at static beamforming.

Remote Access During A Pandemic?

Posted by: Eric Siegel

(Edited Oct 18, 2009, with probably more edits in the future!)

It's late at night; it's a good time for worrying.

Current worry: pandemics. Swine (H1N1) Flu.

What happens if there's a pandemic, and your staff has to work from home?

First, see the U.S. Government website: http://www.pandemicflu.gov

But second, how are we going to handle the communications problem? If your staff is going to work from home, using their consumer-grade Internet connections (DSL, cable), they may be in for a bad surprise. I worry that everybody is going to have that same idea, and your staff will have to compete for the access paths with millions of people downloading movies and music and YouTube and Facebook. Remember, the first groups of people who will be sent home will almost certainly be schoolchildren, and I'd guess that they'll be heavy users of high-bandwidth applications.

Unless the government or the service providers insist on traffic restrictions; for example, bandwidth-limiting YouTube at the YouTube servers (which might interfere with videos that are important for flu sufferers) or bandwidth-limiting peer-to-peer file sharing, I'm guessing that a lot of oversubscribed consumer-grade Internet access will be a congested mess. A lot of kids (and adults) doing a lot of video-watching and file sharing during the day, combined with a lot of working-from-home parents, may overload the access networks. And it will be a really tempting time for criminals to launch DDoS attacks; service provider staffs will be thin and will be overstretched.

Indeed, a U.S. Department of Homeland Security study published in December 2007 ("Pandemic Influenza Impact on Communications Networks Study") using a pandemic model based on Chicago and a telecommuting exercise by the Federal Reserve Board showed that "In the 40 percent absenteeism pandemic scenario, the telecommuting strategy is expected to be significantly impacted for most telecommuters during the peak of the pandemic," and "In the high absenteeism [90 percent; e.g., local quarantine] scenario, the telecommuting strategy is expected to be unusable for the majority of telecommuters during the peak of the pandemic."

So what should we do?

One option is clearly to have business-class dedicated lines or business-class VSAT to some selected members of the staff.

Another option would be plain old dial-up modem service. It won't work for the beginning of a crisis; there will be too much use of cellular and land telephone lines. But after that, I'd guess that the public switched telephone network will be more stable and less congested and more available than any consumer-grade Internet access. Just dust off those old modem racks in your basement, and be sure you have connectivity. And be sure your users have a modem at home or built in to their laptops. "Application remoting" (e.g., Citrix XenApp or Microsoft Terminal Services) can help provide good performance over dial-up modem links; the new software WAN optimization products (e.g., from Blue Coat, Cisco, Citrix, Expand, Riverbed, Stampede) can also help.

And I have more worries: will your server room's Internet access, firewalls, and VPN equipment have enough capacity to handle all of those incoming Internet and POTS remote users?

That's assuming that you have your server rooms functioning, with some staff available to handle all of the dial-in users and their service desk problems! But that's a different question, for another night's worry. I'll do some more digging on this topic and post more blog entries. And, of course, I'd love your comments!

QoS Problems With VoIP Over Wireless

Posted by: Eric Siegel

A fascinating article, "Coexistence of VoIP and TCP in Wireless Multihop Networks," was just published in the June 2009 edition of IEEE Communications Magazine (vol 47, issue 6, pp 75-81; the authors are Kyungtae Kim and Dragos Niculescu [NEC Laboratories America] and Sangjin Hong [Stony Brook University - SUNY]).

Burton Group has been warning that using VoIP over wireless LAN (VoWLAN) is tricky because "QoS alone cannot completely regulate the bandwidth provided to flows on a wireless network... a single wireless station on a shared wireless channel can degrade performance for all other stations on the channel...." We've been saying that: "A reasonable alternative is to avoid voice over WLAN altogether, substituting cellular voice, possibly with femtocell or in-building repeater technology." (See the Burton Group reports "Quality of Service (QoS) Alternatives Demystifying Radio Management;along with the Technical Position "Quality of Service".)

This new article shows that the problems created by VoIP over wireless LAN are even worse than I'd thought. The authors did some experiments, and they found that TCP and VoIP do not coexist well on a wireless LAN. TCP's large frame sizes, large receive windows (RWIN), bursty traffic, and retransmission when a frame is lost make it interfere with short, evenly-spaced VoIP frames. The TCP frames will dominate radio transmissions because of the frame lengths and frequency during a burst. (Frames can't be interrupted after they start to transmit; therefore, long, frequent TCP frames will dominate over infrequent, short VoIP frames.)

Worse, the self-interference and half-duplex characteristics of a wireless LAN system increase the probability that the long TCP data bursts will need retransmission, further increasing their burstiness and their domination of the channel when compared to short VoIP frames. (Self-interference occurs when a single flow interferes with itself as it travels over the wireless system. When transmission and reception share the same half-duplex radio channel, a stream may compete with its own acknowledgements for radio time, delaying or destroying some data and acknowledgement packets. If transmission hops over a couple of radio links in sequence, then each hop's transmission may interfere with transmissions on other hops that are within reception range; a flow may interfere with itself.)

The authors of the new article show that no standard type of queuing algorithm in routers adjacent to the wireless network, even Priority Queuing (PQ), can handle these problems. And they also show that five standard TCP variants used in end stations (TCP Reno, TCP Vegas, TCP Westwood, TCP CUBIC [used in Linux], and C-TCP [used in Windows Vista and Server 2008]) do not handle these problems. In all cases, the TCP flows dominate and degrade the VoIP flows.

What should be done? Well, Burton Group has recommended that cellular should be considered instead of VoWLAN. The authors of the study make additional suggestions that sound interesting, but they also warn that none of them is a panacea - they all are only partial solutions, at best. The authors warn that "the methods examined here have straight-forward application only when the wireless capacity is fixed. In reality, the capacity is highly variable." They also warn that P2P, uploading traffic, and interactive streaming, such as Skype, that use TCP for voice will complicate the situation even more.

The paper's most interesting recommendations are:

• Use unusually-small TCP receive windows and eliminate TCP bursts on the wireless LAN. This may need to be done by gateways at the wired:wireless interface. The gateway would use smaller TCP packets and a small receive window; it would also use a buffer to ensure that any bursts were smoothed out and that TCP packets were spaced out to reduce self-interference and interference with VoIP frames.
• Use a traffic shaping system. The article says, "After a packet of size pkt_size goes out over the air, the next packet is scheduled no earlier than pkt_size/R. The gateway chooses R based on the network status to determine how much to send as well as when to send."

Other papers have recommended different methods, such as doing priority queuing at all intermediate wireless nodes and combining that with traffic shaping.

At this time, it seems to me that avoiding sharing the same channel between TCP and voice is still the best solution.

What were they thinking????

Posted by: Michael Disabato

By now, you've no doubt read about the Baby Shaker app that briefly hit the iTunes App Store. Apple has profusely apologized, which they should, but this brings up the topic of Apples control of the App Store. There still seems to be little rhyme or reason to what they are doing. I have a handful of apps that still randomly crash, and I though Apple was supposed to keep apps like that from being posted.

Then there's the interference with Skype, restricting it to WiFi connections. And don't even get me started about NetShare. Luckily I managed to snag that one before it was removed.

Apple needs to do several things:

Learn that people who buy iPhones do not want limits on how their property is used
Take more care about the content of an application before it is released
Be much more transparent about the approval process

As a parent, I found the baby shaker app abhorrent to say the least. But I find Apple's behavior surrounding the App Store reprehensible.

Michael

Palm's Pre: the iPhone Killer - Not

Posted by: Michael Disabato

After too many years to remember, and more changing of owners and management than I care about, Palm is finally releasing a new handset based on a new operating system. The press has had a lot of favorable comment, including "iPhone killer." I'm here to tell you that's ludicrous and why the Pre, and Palm, are destined for less success than everyone thinks.

First, it's the software, stupid! Palm used to have 15,000 - 20,000 developers writing really good code for the Palm OS. When Palm abandoned that, they abandoned them, and many have moved on to other projects like iPhone, Android, and Windows Mobile. It will be hard to convince them to come back to a new OS requiring new skills and investment during these economic times.

Second, there is the uncertainty of Palm's future. The company has been sold and handed around several times in the last few years, with no clear indication of its solvency or direction. No clearer indication of this could be had by seeing that Palm's last Windows Mobile device was shunned by all the mobile operators and ended up being sold directly by Palm to customers as an unlocked device with no subsidies.

Lastly, the Pre is a CDMA device with exclusivity on Sprint. If you wanted to find a smaller network that is in trouble or about to be acquired, I don't know where you'd look. Sprint's problems with ClearWire, and their insistence on sticking with WiMAX for voice (say what??) is making subscribers think twice about it's future. I don't know... Maybe Palm could not find any GSM takers for Pre, but without a GSM handset in the offing. you have a marginalized handset maker on the edge of oblivion partnered with a marginalized carrier who may be joining them.

iPhone killer? Gimme a break. The thing will be lucky to survive.

Michael