It is sheer curiosity that led me to some recent experiments with 4G wireless Internet.
For some time now, it has been a commonplace amongst certain groups that our old standby technology for remote broadcasts, ISDN, is dead. Well, if not quite dead, then on its back, limbs flailing helplessly. It’s time to bury it and convert all our audio to packets that travel through the cloud.
It sounds appealing, like the early days of jet travel before the seats shrank.
Although I may regret this, I’ll admit that I was there with other engineer dinosaurs at the dawn of the ISDN era. I remember a sales representative at a broadcast conference standing on stage and yelling out the number toll-free number 1-800-GET-ISDN so you knew who to call to get it.
For those of us without a Marti RPU, who previously had been confined to either plain telephone lines or equalized broadcast loops, ISDN was nothing short of miraculous. With a limited lead time you could get almost any of the Bell Operating Companies to install a digital circuit that would pass clean and clear audio (assisted by an audio codec, of course) to and from almost anywhere in the United States and much of Europe.
ISDN quickly became a radio favorite.
PLAN FOR THE FUTURE
Fast-forward 10 years. Entire national networks of ISDN-equipped studios fed a surge in talk and information programming that is still with us. ISDN remains the gold standard of studio interconnections when audio quality is desired and the distance is further than the horizon.
Hacked Linksys WRT54 router and Verizon MiFi. The Linksys receives a signal from the MiFi and connects to the codec via a CAT-5 cable.
Sadly, few other data customers followed suit in adopting ISDN. In the quest for faster connections, data technologies progressed from the analog modem to DSL and high-speed data over consumer cable networks. By stripping off precise timing and packetizing the content, data transfer speeds could be accelerated radically.
Lowly old ISDN fell far behind. It remains what could be only termed a “niche” service. There are still many radio and studio ISDN customers, and they use a lot of long-distance time, but the growth is limited. The fear of someday finding ISDN unavailable is a valid one. Some of the regional telephone companies have openly threatened to abandon all their copper lines.
At my day job, working for WBUR in Boston, I have the responsibility of planning for remote broadcasts. Since the days of ISDN may be numbered, I have made investments in audio codecs that support both ISDN and what has come to be known as “IP” connections.
We have printed articles in Engineering Extra that describe the special requirements for an IP codec: It must have the ability to buffer packets to account for the sometimes bursty nature of Internet data transfer, and it must be able to provide good quality at low data rates for when the Internet connection is not good. IP codecs must be able to handle the non-synchronous delivery of data where bits show up whenever they can and must then assembled back into the correct order and timing to pass real time audio.
From a manufacturing perspective, it seems fairly cost-effective to combine the operations of an ISDN codec with the IP part. The encoding and decoding process remains essentially the same. The trick is to get the ones and zeroes back into order in a synchronous stream, error-free, after they have gone hurtling through the public Internet. That’s the IP part of an IP codec.
INTO THE WILD
With equipment in hand, it became hard for me to resist trying it out. Perhaps this was a technology that could save me money on remotes and even improve the quality. Coincidentally, Verizon Wireless began to offer 4G data services in the Boston area in January of 2011. Karl Voelker, our manager of information systems, picked up a MiFi device from Verizon to test it out.
The wireless modem in the MiFi connects to Verizon’s 700 MHz band 4G data services. In turn it wirelessly provides a connection to a 802.11b/g/n-enabled device like a laptop computer.
In a neat reverse hack, Karl turned a surplus consumer Linksys wireless router into the interconnection device for our codecs, which do not have 802.11 adapters. Instead of taking in a wired Internet connection and creating a wireless signal for a computer, as I do with mine at home, this router connects wirelessly to the MiFi and outputs a wired connection to the codec.
If you think about the previous sentence a second, you’ll see that it runs exactly backwards.
It took a bit of fiddling with the IP codecs to get them to connect to the router correctly. For some reason they would not DHCP properly, meaning that when they asked to be connected to the network, they would not get a valid address and directions on how to see the public Internet. Once I had figured out how to get that working we tried our first connections.
Sure enough, I could enter the public IP address of our studio codec and it would connect right up. For this first test I was in my shop connecting to a codec down the hall but in real terms it was flying out to a 4G tower somewhere, connecting to the public Internet, routing its way to our university network and then directly to my uniquely named device. Seeing it frame for the first time was one of those purely geeky moments that the engineer in me loves. Cool.
SEE DAD, I TOLD YOU
Next I tried to use my home DSL connection. This worked easily, but I learned pretty fast the connections required for real-time audio have to be, well, pretty fast. Sadly my home DSL wasn’t up to the task. Though I could create a connection at 128 kilobits per second that delivered good audio quality, it would not hold stable for very long. About every three to four minutes it would mute for a few seconds. By lowering the data rate down to 64 kbps and adjusting the buffer I could get it to stay longer but it would still fail.
Undoubtedly this was in no small part due to the fact that I have two teenage sons whose social lives consist largely of their Internet use. They have been telling me for years that we have “lousy Internet” at my house. With chagrin I have to acknowledge they are probably right.
Note there is only so much buffer storage that can be applied for a typical remote broadcast before conversation between the studio and remote site become strained beyond usable. While heroic levels of buffering (like 20 seconds worth) might have given me stability it would not have worked for a broadcast.
We had tested the performance of the 4G MiFi and found it to deliver download and upload speeds in excess of 20 Mbps at times. This was much faster than a typical home DSL, so for our next test we tried using the IP codec at an outdoor event on the Esplanade along the Charles River. The main link was an ISDN but we also built a backup link using the 4G.
I’m happy to say that the 4G worked pretty well. With a modest buffer and a data rate of 64 kbps we could hold a good connection for most of an hour. There was still the occasional mute but I feel that with some further experimentation or perhaps an antenna we could eliminate this.
HEAD SHOT
Our final test was at a remote from a function room at the Marriott Hotel near Copley Square. The event was a conference dedicated to Web journalism. Our initial walkthrough and tests showed the 4G to have good signal strength and excellent upload speed. Again, we contracted for an ISDN circuit to be the main feed but we planned to use the 4G as a backup service.
While we had some initial problems with the MiFi, we solved them early on the morning of the remote, and connected up around two hours before the broadcast. From the studio I ran a stream monitor to gather statistics on this link, and it was fabulous for those two hours, with no dropouts, and high-quality audio passing both ways without a single mute or packet loss.
I suppose the part about the conference being aimed at Web journalism should have been a warning sign, but it wasn’t until later that we thought about that. Precisely eight minutes into our live broadcast, the wireless connection dropped out hard, and we did not get a reliable connection for the entire time of the remote. It was able to connect for perhaps one minute at a time before dropouts. We tried adjusting the buffer, moving the MiFi and dropping the data rate but no dice. There just were too many devices competing with ours for data and it did not work. At all.
MAKE SURE THERE’S A PLAN B
From my experience I would say that right now it takes the truly brave to enter this New World of IP audio, particularly when it comes to wireless remotes.
We found to our delight that 4G has more than enough bandwidth to handle audio with excellent quality. We also discovered that there isn’t really a way to know for sure if a particular site will work or not at the exhilarating moment the remote site goes live. Even after two flawless hours before the broadcast, it took just eight minutes for the crowd to get going and turn our wireless connection from framed to folly.
My advice is to keep on ordering those ISDN lines if you can, because right now they remain the most reliable way to cover high-quality remotes without a radio link. The uncertain popularity of a particular event can determine if too many users are present to reliably use wireless systems.
But by all means go out there and experiment. For short, newsy feeds, this service is flexible, comes in small packages and is reasonably easy to use. It takes newsgathering just about anywhere you can get a signal. That’s a first step on what we all expect to be the eventual future of audio. Just be careful out there.
Have success story of an IP remote? Send me a note at [email protected] and let us know how it went.
