Volume Number: 19 (2003)
Issue Number: 4
Column Tag: Wireless Networking

Serious Wireless

Looking to get Point-to-Point Wireless between locations? Here's a truly robust solution.

by Neil Ticktin

Some of you may recall my first wireless article a few years back (MacTech Magazine, January 2000 issue, "Going Wireless!" <http://www.mactech.com/articles/mactech/Vol.16/16.01/GoingWireless/>). In that article, I wanted to implement a reliable wireless link between my house, and the office. I specifically wanted to do anything and everything that I could to avoid the phone company for my net connection. Wireless gave me the ability to get high quality, reliable access that was completely within my control, and without any monthly fees. Sounded good to me!

And it was great. For years, I reliably had a 1.4 mbps connection between my house and my office ... a drive of about 2.5 miles, and about 1.5 miles as the bird flies. I was able to do it with off the shelf materials ... Lucent boxes (very similar technology to what's in the original Airport Base Stations, but with Lucent software to glue it all together).

The problem is, 1.4 mbps is not what it was 3+ years ago. More importantly, even though I was physically fairly close to the office, I was suffering latencies in the 30-millisecond range. Now while that's not a problem for things like web browsing, certain functions like access to our FileMaker Server were way too slow for me to use the way I wanted to.

You see, some applications move a lot of very small pieces of data around. The theory we had with our FileMaker sluggishness is that the latency was too great (especially compared to the LAN at the office), and essentially, it was causing the network to "thrash" when certain functions performed. As we saw in installing the new setup, reducing latency made a huge difference in the way these systems worked.

By the way, in case you were thinking about utilizing the new 802.11g standard at 54 mbps, beware of something. 802.11g is great for indoor LANs, but the standard is still in flux, and more importantly, the amount of distance you can get (at least inside) is about 1/3 of what is available with 802.11b. So far, I've not heard of anyone using 802.11b for outdoor point-to-point access.

You may remember from the previous article that I don't have line of sight from my house to the office. The solution? I knocked on the door of a neighbor up on the hill and offered him a great Internet connection in exchange for having some equipment on his roof. As you might well imagine, that's a deal that works out well for all. So, unlike many installations, I actually have a point to point-to-point connection between my house and the office. In other words, my connection goes from my house to David's house, to the office ... point to point to point.

What I needed to do now is find new equipment that could reduce the latency, as well as increase the bandwidth. I turned to my friends over at Westlink Wireless http://www.westlinkwireless.com. Eddie West helped me to take a look at the problem and recommended that we look at some of the proprietary radios out there.

We selected the Trango Broadband radios <http://www.trangobroadband.com>. Specifically, the Access5800 Wireless Broadband Access Solution. Specifically, we're using a combination of their "Access Points" (AP) and their "Subscriber Units" (SU). The APs are typically located at the center of a network, or head-end of a wireless point of presence, and they communicate with one or more SUs. You can have up to 500 SUs per AP unit. We're using the Access Point, M5800S-AP-60, $895; and a 3 Mile Subscriber Unit, M5800S-SU, $495. (There's also a 10-mile Subscriber Unit, which has a DirecTV style dish on it.)

Radios have a certain amount of range where the signal is "visible". In Trango's terms, their AP units have a 60-degree sector. Because my house and my office are not within the same sector of visibility (they are on opposite sides of David's house), I need to have to Access Points each talking to a Subscriber Unit (4 radios in all). Put another way, the AP at my house talks to a SU at David's which is connected through a small Ethernet switch to an AP at David's which talks to an SU at my office.

The radios, and antennae are all combined into a single, weatherproof unit. No power is necessary on the roof, only at the power injector, which is likely near your router or switch. The units use a "power injector" over Ethernet. The radio can be 100 meters from the power injector. The injector has three connections -- a power cable, and two Ethernet ports (one to your LAN and one to the radio). For some installations, not having power at the radio is critical ... and it's almost always handy.

These Trango radios are pretty cool. A specific benefit to us is that they are not based on one of the 802.11 standards, and are therefore they were able to do some special things, are high performance and secure. Specifically, they are based on Direct Sequence Spread Spectrum technology that operates in the ISM 5.7 - 5.8 GHz range. They theoretically deliver up to 10 Mbps user throughput reliably. An Access Point can be up to 20 miles from the SU, and supports QoS and have on the fly bandwidth throttling. Spread spectrum has the inherent advantage over other forms of transmission in that it can still recover data even in the most noisy of RF environments where other architectures fail. This isn't something new, just something very reliable and robust.

Using a proprietary protocol called SMARTPolling, the Trango radios are able to discover one another, as well deliver bandwidth more efficiently. And, if you are concerned with balancing the signal between SUs at different distances, the APs have a "power leveling" feature. As part of the "power on" sequence, the AP determines how far away a given SU is, and actively diminishes or increases its output power to ensure a quality of service.

To keep usage under control, you can optimize the Committed Information Rate / Maximum Information Rate (CIR/MIR) and provide bandwidth management/throttling per individual SU.

One of the more interesting features is the Dynamic RF Packet Sizing allows the radios to optimize data bandwidth utilization with maximum RF sensitivity. Unlike other solutions which use fixed RF packet sizes, the Access5800's protocol dynamically analyzes each Ethernet packet and transmits at an optimal length, 64 bytes (in the case of URL requests) to 1600 bytes.

SU's can be remotely managed through the AP using a host of commands or via HTTP web interface, telnet, or serial interface. The radios have a built in RSSI LED and RSSI Telnet Command for SU antenna alignment.

And, there's a fallback channel provision on the SU which offers built in redundancy. In the event an SU cannot communicate with its primary AP, the SU will intelligently search for a pre-programmed fall back AP to communicate with. This feature allows the network operator to actually sleep at night knowing that each user's network link will still be up in the morning.

But there are two features that are super cool, especially if you are familiar with installing wireless networks. First, there are internal dual polarized antennas that are software switchable -- yes, you can change the polarity through the software interface! Second, the radios have built in site survey tools that allow you to check for interference (see Listing 1).

ss> survey 3 v
Running site survey for 30 secs.
Press [space] then [enter] to stop
Vertical Polarization        Channel is clear if avg & max < -92dBm
freq   max    avg               freq   max    avg
Mhz    dBm    dBm    clear      Mhz    dBm    dBm    clear
5724   -87    -97     *no*      5788   -93    -99     yes 
5728   -81    -95     *no*      5792   -93    -99     yes 
5732   -80    -95     *no*      5796   -93    -99     yes 
5736   -79    -95     *no*      5800   -93    -99     yes 
5740   -79    -95     *no*      5804   -89    -99     *no*
5744   -80    -93     *no*      5808   -88    -97     *no*
5748   -82    -97     *no*      5812   -82    -97     *no*
5752   -91    -99     *no*      5816   -81    -95     *no*
5756   -93    -99     yes       5820   -80    -91     *no*
5760   -93    -99     yes       5824   -65    -80     *no*
5764   -93    -99     yes       5828   -57    -77     *no*
5768   -93    -99     yes       5832   -57    -85     *no*
5772   -93    -99     yes       5836   -57    -83     *no*
5776   -93    -99     yes       5840   -57    -83     *no*
5780   -93    -99     yes       5844   -59    -85     *no*
5784   -93    -99     yes       5848   -63    -79     *no*

With all the talk about security over Wi-Fi, you may be concerned about the security offered by a wireless solution like this. I'm not. First, because these radios are proprietary, it will take a lot more effort for someone to figure them out. Second, the radios will only talk to another radio that it knows the hardware (aka MAC) address of. Third, Trango has built these radios with security in mind. I have a lot greater concerns about other attacks on our network than I do about someone entering in through this wireless entry point.

If you are still using AppleTalk protocols in your network, no worries. These radios can handle them. Since AppleTalk uses AARP, you will need to turn the multicast packet switch to off (disabled). Once you do that, AppleTalk Phase 1 and 2 pass traffic with no problems. It's pretty cool to pull up a zone at my house from the office ... in fact, I have a Home Automation server at the house that stores my MP3s, and I play them in iTunes over File Sharing on a machine in my office.

One of the cool things about these radios is that you can have the Access Point broadcast changes to the APs. This is, obviously, especially useful if you have many SUs talking to the AP ... and again, shows the heritage of this radio being targeted for ISPs.

These radios are intended for ISPs looking to deploy in their network. On one hand, that's great because that market won't tolerate a lot of problems ... the radios need to be robust. The flip side to this is that this is not a product that is currently being marketed to the end user. In part, that's because you should have some expertise when deploying it.

Unless you are an expert yourself, you should talk to someone who is. Our experience with Westlink Wireless showed the importance of this. Eddie's ability to size up the network environment and to work out the kinks was important to our install (mostly because we were doing point to point to point instead of point to point as most people would.) For example, I never would have known that it was better to have an AP and SU at David's instead of two AP's.

You need to make sure of several things. First, do you have radio line of sight? From my previous article, radio line of sight takes into account the shape of the zone that the radio waves travel in. This is called the "Freznel" zone. Basically, the radio waves travel between the antennas covering an area that is shaped long an elongated football. In other words, the clearance that you need halfway between the antennas is greater than right at each antenna. In many cases, this means that you are at an advantage if one of the antennae locations is at a higher elevation than the other.

You also need to make sure that you aren't trying to send the signal through or near items that could cause interference. For example, the metal flashings around the top of a chimney might be a problem if you are mounting the radio to a chimney. Or, if you were thinking that you could should the signal through foliage, some may be more tolerant than others. (I learned the hard way that pine trees are really tough to deal with and should always be avoided.)

My recommendation? Either plan for a bunch experimentation and learning, or better yet, buy the radio through a reseller like Westlink Wireless so that you have somewhere to consult if you run into issues.

One of the things that I didn't like about the Lucent solution that I had was that it required that I talk to it through a piece of Windows software. VirtualPC, as always, came to the rescue so that I could use my Mac to configure the radios ... and VirtualPC 6 is better than ever in this way.

The Trango radios, though, can be configured not only through a web interface, but also via telnet. A quick overview of the command set gives you an idea of all that you can do with this interface.

* ALL
? [command]                                         !
cd [..|main|net|rf|fw|ss]                           date
date <month> <day> <year>         help [command]
logout                                              opmode [ap]
reboot                                              restart
sysinfo                                             systemsetting <backup|restore>
sw [<sw #> <on|off>]                    time
time <hour> <min> <sec>
updateflash 
<mainimage|fpgaimage|sumainimage|sufpgaimage|systemsetting|sudb>

* MAIN
bcastscant <all|suid> <ch#> <h|v> [<ch#> <h|v> ...
bcastsuimage <all|suid> <regular|fast> <target hw_ver>
bcastsuimage [stop]                                 password
_password <new password> <new password>
set suid <id>                                 set apid <id>
set baseid <id>                               set ip <ip addr>
set defaultopmode [ap|su] <min,0..60>
set defaultopmode off                               set mir [on|off]
set mir threshold <kbps>
set rssitarget <threshold> <fade margin>
su <suid> [nonstop]                           su all [nonstop]
su changechannel <all|suid> <ch#> <h|v>  su [live|poweroff|priority]
su <ping|info|status> <suid>            su reboot <all|suid>
su restart <all|suid>                         su testrflink <all|suid> [r]
su powerleveling <all|suid> [target dB]
su sw <suid> <sw #> <on|off>      sudb [dload | view]
sudb add <suid> <pr|reg> <cir,kbps> <mir,kbps> <device id,hex>
sudb delete <suid>                            sudb modify <suid> <cir|mir> <kbps>
sudb modify <suid> <su2su> <group id,hex>
sudb view
* NET
ping <ip addr>                                tftpd [on|off]
* RF
cf2cf ap [default|<size>]                     freq scantable
freq channeltable                                   freq writescan [<ch#> <h|v>] ...
freq writechannel [<ch#> <freq>] ...
freq <ch #> <h|v>                       polar <h|v>
power set <dBm>                               power table
rfreport [reset]                                    rfrxthreshold <off|-80|-75|-70 |-65>
rfrxthreshold table
* FW
mainupdate                                          fpgaupdate
* SS
survey <time, sec> <h|v>                rssi <ch #> <h|v>
apsearch <secs> <ch#> <h|v> [<ch#> <h|v>]...

In general, I love these Trango products. You can't believe how useful it is to change polarity of antennae in software ... or to do a site survey from a telnet interface. More importantly, these are robust radios that are serious business, and I'm thrilled to have them in my network.

There are a couple of things that got to me on these radios, and are worthy of mention here. First, and these are minor, the RJ-45 jack on the power injector is backwards. The clip is against the wall, and it can be very difficult to pull the cord out without having a small flathead screwdriver. Also, the arm that the radio mounts on could be easier to articulate, but it's not bad.

The one thing that I truly despise in these radios is what I can best describe as an over the top security feature. Once set up, you can really only configure these units from one side of the connection because it limits where you can log in from. Remember, these things were designed for ISPs who deploy one or more APs and then have tons of SUs. The idea is that you wouldn't' want a customer to be able to telnet into a SU, so everything needs to happen from the head end side of things. Now, it is possible to log in from the SU side, but you have to do so within the first 30 or so seconds from when it's been power cycled. This is quite the pain and for me, almost useless as I want to manage things remotely, not on site. I have no problem with this feature being available as a software switch, but even if I was an ISP, I wouldn't want this feature turned on by default -- I want to be able to configure these things from both sides! And, this one sided nature doesn't stop there, you can't even ping the radio from the client side. This means that an ISP can't even ask their customer if they can ping a radio when the connection is down! What a pain for those in tech support who have chased problems only to find that the client unplugged a cable somewhere. Unfortunately, because it would take a complete rewrite to fix, I don't expect this feature to go away soon.

Another limitation is their use of "opmodes". Radios are usually configured when they are not running in either the Access Point or Subscriber Unit "opmode". Disable the opmode, and you disable the link. Enable the opmode, and you can't configure the unit. This is different from other types of radios that seem to be able to do both.

There are some new things coming down the pike on these radios. A new firmware upgrade will have SNMP capability (this will be a free upgrade). And, there's a dual-band version (5.3/5.8 GHz) coming soon too. Lastly, expected in May 2003, there will be a true point-to-point version of the radios, which may interest many of you.

Proof is in the pudding, right?

These radios are fast ... I'm seeing communications at under 300 microseconds (not milliseconds) between the radios. But, a radio ping is different from an IP ping which is what we really care about.

In my point to point to point setup, I came from my older set up doing 1.4 mpbs with 30 millisecond latency to a new set up of 6-8 mbps (depends on the direction) with 5 milliseconds latency. The speed is so different and so much better that, using Retrospect Server, I'm actually now running backups of my home computers to tape drives at the office.

Doesn't get much better than that.

Neil is the publisher of MacTech Magazine. As a closet geek, he tends to experiment with some of the more interesting forms of technology, and then frightening the magazine staff by announcing he'll write about them. You can reach him at publisher@mactech.com