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).

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

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.

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.