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
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
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
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
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.
SEE DAD, I TOLD
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.
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.
THERE’S A PLAN B
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
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
Have success story of an IP remote? Send
me a note at firstname.lastname@example.org and let us know how it went.