Fig. 1: Xohm-Supplied WiMax Express Card With PC Card Adapter We’ve long heard rumors of a new, ubiquitous wireless data network on the way called WiMax, and we at Comrex have been longing to spec out its performance using our Access IP codecs. I got my chance recently when I received a WiMax Express card for testing.
Fig. 2: The Xohm External Modem The first widespread commercial deployment of WiMax technology is coming from a division of Sprint Wireless dubbed Xohm. They currently offer commercial service in the Baltimore market only, with several other cities coming online around the end of 2009. After enough begging, we got hold of a sample card, shown in Fig. 1, with intention of finding a way to have Access Portable utilize the card, and then finding a friendly broadcaster in the Baltimore area to help us try it out.
As it turns out, the card offers literally no Linux support at this time, so the project of including direct support for it was shelved for a different day. For future tests, I recommend using the available external modem, shown in Fig. 2, which should theoretically have no such interface issues. It may have an advantage as well, since building penetration at the 2.5 GHz frequency used by Xohm can sometimes be challenging. Utilizing the external modem would allow you to position it near a window, and run an Ethernet cable to where the action is.
Fig. 3: This will be easier than I thought! Before I booked my flight to Baltimore, a little Googling produced some reports that Baltimore WiMax users have migrated to some other “soon to be covered” cities and had success with their Xohm hardware there. Since one of the reported cities was Boston, I ventured out on a little site survey to see if I could conduct the testing closer to home. Lo and behold, the card in my laptop lit up in various areas in the city and around the Route 128 technology corridor (Fig. 3).
So I found a convenient location to our office in Devens, Mass., which turned out to be the shopping area in Burlington. I went back a few days later, staked a location in a shopping center parking lot (Fig. 4), and began testing.
Fig. 4: Scene of the Crime First, I did a round of speed and ping tests. The Xohm Windows client has a built-in link to Speedtest.net, so I ran a couple of tests there. A typical result is in Fig. 5.
The tools at DSLreports.com weren’t quite as charitable on the downlink side, but we really care more about uplink speed for codecs, and it still appeared to be plenty (Fig. 6).
Fig. 5: 3.6 Mbps downlink! 740K up! Very nice. But bandwidth is only half the battle, since the IP codec application is so reliant on low network delay. This has been an issue with 3G networks, which can often instill a large fraction of a second of delay in each direction. So some ping tests were performed (Fig. 7).
The results, an average of 80 msec delay, were pretty respectable.
The last factor that will affect delay is the overall jitter performance of the network. Since the decoder needs to buffer the incoming packets to account for late arrivals, this buffer will add to the overall delay. Now keep in mind, the network I was using was purely in its test phase, and I’m pretty sure I was sharing it with virtually nobody else. So the final results will probably vary from mine.
Fig. 6. Still Not Too Shabby As mentioned, attaching the card directly to the codec was a non-starter, so I needed to lash up a laptop running the card to a portable Access. This is done via the Windows utility called Internet Connection Sharing (ICS). I ran an Ethernet crossover cable to the Access and that resulted in the mess shown in Fig. 8, but voilà! It works!
Because the Access rack back in my lab has online statistics available, I was able to monitor the network quality and jitter rates on both ends simultaneously. I was very impressed.
Fig. 7: Ping Test to Google (81 mS avg) and to My Lab Codec (80 mS avg) I was running the AAC-ELD stereo option, which utilizes around 80 kbps in each direction. The network jitter on the return link, as read on the portable, required a jitter buffer of about 60 mS for stable operation. And stable it was, without so much as a packet drop over the hour-long testing (Fig. 9).
But of course, the real test is what was getting back to the lab, since that would be the “over-the-air” link. Luckily the WiMax link had plenty of extra bandwidth for me to log into the Web page of my lab unit to check that (Fig. 10).
So the test “broadcast” was perfect. Sounded great in my car, and the remote stats page showed it sounded perfect in the lab as well. What was the overall delay? The numbers:
- AAC-ELD coding and decoding cycle: 50 mS
- ½ Ping time transmission delay: 40 mS
- Decode jitter buffer: 60-80 mS
Total one-way delay of this system was around 170 mS. That’s in the same range as some digital mobile phones. Given a mix-minus feed, it should be quite manageable on an interactive basis.
Fig. 8: Ugly but Effective
SUMMARY
While I must add a couple of caveats in that the Xohm WiMax system is not heavily deployed or used, early tests are extremely promising for use of this technology for remote broadcasts using Access IP codecs. We’ll gather more info as customers get subscriptions (and hopefully support the card directly) and will update our Web site with the latest details.
Tom Hartnett is technical director at Comrex.
Fig. 9: Portable RX stats — holding up very well.
Fig. 10: Perfect Transmission With Jitter Buffer Around 80 mS
