A break from Tradition: Using IP for an STL

Publish date:

A break from Tradition: Using IP for an STL

Jan 1, 2008 12:00 PM, By Doug Irwin, CPBE AMD

Image placeholder title


A station's studio to transmitter link (STL) is an integral part of its mission-critical transmission system � linking the site that generates the program material to the transmitter location itself. As such, the quality and reliability of STL equipment has always been of paramount importance. One critical aspect of an STL system has historically been lack of contention in its use; in other words, the facility wasn't shared in any way. If you had phone lines, they were yours and yours alone; if you used a radio frequency, it was licensed and coordinated among other users so the negative effects of interference were mitigated.

The cellular telephone system came in to wide use in the early to mid-1980s and many changes manifested themselves at mountain-top transmitter sites and other tower farms. Telcos began installing high-capacity data circuits via fiber optics, and the obvious result was the availability of more and more tributary data circuits, such as T-1s. The nature of the installations made them very reliable and the introduction of STL systems that used this new capability (notably Intraplex, Graham-Patten Systems and QEI) allowed more and more radio stations to take advantage. These STL links were still non-contentious in that the radio station had the private use of all the timeslots that were paid for. The STL systems were all based on time domain multiplexing (TDM).

Image placeholder title

APT Oslo

In the mid- to late 1990s, usage of the Internet (which we all referred to as the World Wide Web in those days) began to take off. It became common to use the Internet to retrieve technical manuals and e-mail; so it wasn't very long before broadcast engineers began getting their networks extended to the transmitter site via WAN. Intraplex made it particularly easy to extend Ethernet from a studio to the transmitter site with the DS64NC card that could be used in its T-1 shelf.

From there it snowballed. Network access from the transmitter site to get on the Internet wasn't enough. Then the RBDS encoder was placed at the transmitter and accessed via Ethernet. Then more bandwidth was needed for the HD Radio system. Then the station added a webcam and a remote control with SNMP to send e-mail messages if something went wrong. Need I go on? We are bandwidth hungry.

Practical connections

Image placeholder title

Harris Netxpress

If you go this far � adding a high bandwidth LAN or WAN connection to your remote transmitter site � the question of using some of it for yet another STL system soon arises. Likely it is a completely separate system from the main (non-contentious) STL system. How practical is it to use an IP-based STL system, one that contends with other users of the same bandwidth?

It is practical, but within the limits of the available connectivity. If you are using a contentious network then you can expect far less performance than you would from your own private network (that may still be built on top of a TDM network, of course).

And while the telcos are making use of IP technology to use their bandwidth more efficiently (or economically), I'm not suggesting that is the reason for using an IP-based STL. If you have a high-bandwidth WAN connection at the transmitter site anyway � with enough room (i.e., data bandwidth) left over � then this is something to seriously consider. Let's take a look at some of the products available to do just that.

Image placeholder title


A fairly new player in the STL field is APT. Its most sophisticated and capable product is known as Oslo. This 3RU product is comprised of a frame into which various modules are placed in order to achieve the functionality needed. The basic modules are power supply (redundant power supply module is available) and the MCU (or controller) module. The MCU communicates via Ethernet, and is controlled locally by way of GUI software installed on the user's computer. The far end is then communicated with via in-band management over the particular type of data connection, which can be via (non-contentious) TDM (either T-1 or E-1) or via IP with the appropriate interface module. Plug-in audio modules can be of the simplex or duplex variety; analog or AES flavor. Enhanced Apt-x, MPEG layer 2, J.57, J.41 or linear audio (32- or 48kHz sample rate, 16-bit word) are the options for encoding the audio. Using the IP interface, an audio stream can be generated that corresponds to each of (up to) seven stereo audio pairs; likewise, up to seven stereo audio pairs can be received via streams and outputted on the appropriate modules. Duplicate streams can be sent to an additional 10 clients.

1 2 Next

A break from Tradition: Using IP for an STL

Jan 1, 2008 12:00 PM, By Doug Irwin, CPBE AMD

Image placeholder title

Musicam Suprima

Harris/Intraplex is well-known in the STL field. A fairly new product is called Netxpress, which basically uses the same form-factor as the legacy T1/E1 shelf. This unit accepts the current line of Intraplex audio, video and data modules, and connects to the far end via IP. It has a total payload bandwidth of 8Mb/s and can accommodate up to 32 data streams (point-to-point unidirectional or bidirectional; or point-to-multipoint unidirectional multicast). It comes with a network management system that allows the user to control the packet size on a per-stream basis; a packet-jitter buffer that allows the user (also on a per-stream basis) to minimize the negative effects of issues such as packet delay, and the restoration of out-of-sequence packets; priority tagging, which can be used to give audio stream payload packets a higher-priority; and finally user-adjustable forward error correction (FEC) that is used to help the far end rebuild lost or dropped audio packets. Network statistics are available for current and cumulative packets sent, received, lost and delayed on a per-stream basis.

Musicam offers the Suprima-a 1RU, two-channel analog or AES interface audio codec (full-duplex). Communication with the far end is accomplished via ISDN or IP. Compression algorithms supported include MPEG 1/2 (layers 2 and 3), AAC LC, AAC LD, Apt-x (standard and enhanced), uncompressed PCM, G.722 and G.711 (with echo cancellation). The two channels can operate completely independent of one another if the compression algorithm is G.711, G.722 or MPEG. The send and receive directions can use different algorithms. Auxiliary contact closures are available in all MPEG modes. IP protocols supported include TCP, UDP and real time audio streaming. The Suprima has a built-in Web server so a browser can control it remotely. I don't want to forget the front-panel headphone jack that can be used to monitor audio in either direction. That's always a handy feature.

Image placeholder title

Telos Zephyr Iport

Telos is making its presence known in this field and has recently introduced the Zephyr Iport. This 2RU device can send eight stereo audio feeds over IP networks. It uses the Livewire standard for networked audio over Ethernet and typically would be part of an Axia IP audio network. (If the unit isn't part of an Axia IP-audio network, use of the Iport will require the acquisition of an Axia AES or analog audio node.) Compression algorithms include AAC LD, AAC and MPEG 3 (layers 2 and 3). Full configuration, and remote control is done via the embedded Web browser.

Perhaps you want to ease in to the whole audio-over-IP technology; if so then the product line from Barix may be exactly what you are looking for. The Instreamer 100 is a small, stand-alone audio encoder that connects to the far end via IP. It makes use of the MPEG 3 compression algorithm (16 to 48kHz sample rate, up to 192kb/s variable bit-rate) with stereo audio, RCA inputs or coaxial or optical S/PDIF. Control is accomplished via embedded web browser or RS-232. The complementary decoder is the Exstreamer 100: This unit will decode MPEG 3 (up to 320kb/s fixed or variable bit-rate) or Windows Media encoder (up to 384kb/s). Audio outputs are delivered via RCA connectors; control is done via embedded Web browser or RS-232.

Image placeholder title

Barix Instreamer

There are several other players to consider � some that you may have not previously thought of. The first is a company well known for making transmitters: Energy Onix. Its offering in this field is the Tele-link III. This is a single-rack unit codec built on top of a small industrial computer running Linux. Audio inputs and outputs are balanced analog; the network connection is handled through an RJ-45, connecting at 10 or 100Base T. The necessary data rate is 128kb/s for 48kHz sampling, with a 16-bit word, by way of either the MP3 or Ogg-Vorbis compression algorithms. All control is done by way of the front panel.

MDO-UK also has a single rack unit solution for audio over IP. Its product is known as Audio-TX STL-IP. Audio inputs and outputs are done by way of balanced AES. The unit will accept wordclock. The codec can generate up to six streams, while receiving audio from one remote location (TCP/IP, UDP or UDP multicast). Audio can be sent in an uncompressed fashion (assuming bandwidth can accommodate it) or at reduced data rates making use of any one of the following compression algorithms: MPEG 2 layers 2 or 3, ADPCM, AAC, AAC-LD or AACPlus. FEC is built-in. The configuration and control are done via a Web browser.

Image placeholder title

Energy-Onix Tele-link III

Audio over IP for STL applications is not a new idea, by any means. Having LAN and/or WAN connectivity at a transmitter site, even one that is way out in the sticks, is becoming more and more common � and we've gotten to the point where we expect just about every electronic device to have some sort of network connection. Even though the world is going this way, I'm not ready to hand over my main STL to a contentious network just yet. Still, as time goes by, it's conceivable that type of network will provide the same level of reliability, all things considered, as the type of networks and links we use today. Now might be a good time for you to learn how it's done.

Irwin is the chief engineer of WKTU-FM, New York City.

Resource Guide




Harris Intraplex

+44 121 256 0200



Previous 1 2