Trends in Technology: Robust IP STL

July 16, 2014


Years ago, as the chief engineer for KJAZ in San Francisco, I put together an STL system that I thought was pretty infallible—a dual-monaural 950 MHz radio link. This was a common method in the 1980s and early 1990s. The new equipment configuration allowed me to retire a very old composite STL and re-locate the station''s stereo generator to the transmitter site where I felt it belonged.

The system quickly instilled confidence because it was a lot quieter than the old composite radio. It sounded better, and, unlike the composite system, it had inherent equipment redundancy with dual radio pairs. Everything worked smoothly until one day when my pager went off with the KJAZ studio number. The disc jockey reported to me an incredibly annoying “thump” (for lack of a better description) that was going out over the air at seemingly random times. To make matters worse, it was occurring in both channels. We started looking for the interference source immediately, but it was difficult to find due to its random nature. The interference consisted of strong, wideband bursts of RF that lasted less than a second. I quickly ordered a set of equalized stereo phone lines from Telco—but we had to deal with the ‘thump'' until the lines were installed. It was bad.

The lesson here is that the system I had built lacked in diversity. Sure, it had frequency and equipment diversity—but that was not enough. As a result of this difficult lesson, I''ve maintained both radio and wireline links to the transmitter site for every station I''ve maintained over the last 25 years.

What is the most up-to-date means by which a station can build adequate diversity into an STL system in 2014? That''s what this article is about. It isn''t just about STLs necessarily; you could apply the same methodology we''re going to go over to any point-to-point connection, such as studio facility to studio facility, studio to satellite uplink, or studio to booster (SFN) site. The methodology used really depends upon how serious you are about maintaining the connection.

In order to develop a technologically diverse system, we''ll still make use of both radio and wireline (Telco) connections. The reason for multiple path technologies is because some catastrophe that “takes out” one likely will not affect the other simultaneously. For example, an intruding interference source that appears one day can effectively kill a radio system but won''t affect a wireline link. Conversely, something that impairs the closest telco central office (and thus the wirelines) likely won''t harm the radio link. In the past, there may have been just a single station at the transmitter site. Now it''s likely there are 2, 3, or even more, and the requirements for the link are much greater. Fortunately, we can now get both radio and wireline links that carry significantly more information than in the “old days.”

- continued on page 2



The biggest change in the technology of STL systems over the past 25 years is the use of digital techniques as opposed to analog. In the last 7 or 8 years the change has been from use of TDM to that of IP-based systems. When doing so, we take advantage of all the techniques that have been developed to use for all manner of communications systems, not just for broadcast, and that has opened up a world of possibilities.

Let''s take a look at a hypothetical system design now. The basic requirements are thus:

  • -This will be an IP-based system; all program transport will be done via IP
  • -The system will have technological diversity, based on a private radio system as well as leased facilities from the local exchange carrier (LEC)
  • -Point A will be the studio facility; Point B will be a multiple-station transmitter site

Figure 1: Studio network topology

So let''s take a look at Figure 1. This particular system is composed of IP audio codecs with dual Ethernet interfaces. To provide redundancy in the links, one of which will be a radio link, and the other a “wireline” link, we''re going to use separate layer-3 switches. Managed switches will be required, because VLANs and VLAN trunks will need to be configured. VLAN trunks are layer-2 connections that carry packet traffic associated with multiple VLANs, but over the same physical layer connection between devices. You would have the choice of putting all of the codec streams in the same VLAN, or making them separate. The “business network” (what you would consider your normal LAN around the office, and for use at the transmitter site) will enter this layer-3 switch on a separate port.

The point of creating VLANs is to restrict traffic. You do not want anyone using the LAN at the transmitter site to accidentally “swamp” the portion of the network that is carrying the program audio. Use of VLANs and VLAN priority will also allow you to tell the link to make sure the packets related to program audio “get through first” over and above the run-of-the-mill LAN traffic such as e-mail, web browsing, and file transfer. That being said, since the codecs in use have both of their Ethernet ports associated with different VLANs, and carrying program traffic, in order for you to manage them from the business network, you''ll need a switch that will allow you to route between VLANs so that you can manage the codec from your desk. This is where a layer-3 capable switch comes in to play.

Each of the layer-3 switches will be trunked to the Ethernet interface that carries traffic back and forth to the transmitter site. A requirement of the gear used for these particular links is that it must support VLANs and VLAN trunking.

Figure 2: Transmitter site network topology

Now, on to Figure 2—the transmitter site. Each of the links is connected to a layer-2 switch, carrying the VLAN trunks from the far end. Again, each codec maintains a physically separate layer-2 connection to a redundant network. You''ll be restricted at this end in terms of access to the VLANs carrying program traffic. In the configuration of the switch, you''ll make the appropriate VLANs accessible on the appropriate ports on the near end so that the codec can be reached by all the packets transmitted at the far end, and so that it in turn can send packets back to the far end.

One optional feature that I''ll mention: back at the studio end, I showed two separate “business network” LAN connections. How would you actually make use of both of those at the transmitter site end? One way would be to configure spanning tree on the switches; that way, if the LAN connection is lost via either the radio or wireline link, the switch at the transmitter site end will start using the other link automatically.

With an understanding of the network architecture now in mind, we need to discuss the means of getting our packets delivered to the far end, both by wire and by radio links. In Los Angeles, AT&T provides metro Ethernet to Mt. Wilson, where the majority of the area''s radio and TV transmitters are located. The “hand-off” from AT&T is a physical Ethernet interface on both ends. Pricing is very reasonable and different speeds are available. For example, at our Burbank studio facility AT&T has specified a 100 Mbps connection. On the far end, they''ve specified 20 Mbps “drops” to each of our transmitter rooms.

- continued on page 3



Worldcast Oslo Network Management Software monitoring redundant IP paths

Now, I can''t over-generalize, but I''m quite sure that Mt. Wilson is not the only transmitter site in the country with access to metro Ethernet. A little research will reveal whether or not this type of service is provided in your area and who the provider would be.

The radio part of the equation has become much easier in the last several years since the FCC relaxed the part 101 rules allowing use of 6 and 11 GHz licensed radio links for the “last mile” connection to a transmitter site. With the proliferation of cellular telephone systems, a very large market for “backhaul” radio systems has developed, and many manufacturers are doing their best to get a piece of it. For purposes of this system, the basic need is a layer-2 (Ethernet) interface to the radio, and support of VLAN trunking across the link. Those are very common features now, offered by many radios. For example: Ceragon offers their FibeAir IP-10E series; Aviat, their WTM-3200 series; Dragonwave, the Horizon Packet radio; Exalt, the Extend-Air G2 series; and Proxim, the Tsunami GX-810.

With the licensed radio links, you''ll of course need to go through the prior coordination and application process with local spectrum users (since the frequencies are shared) and the FCC. The coordination and licensing process sounds more difficult than it really is. There are a number of firms that will do this work for you, such as Comsearch, Micronet, V-Soft, RFEngineers.com, and Terrestrial RF Licensing Corporation.

With the design for your redundant IP-based STL system in place, you''ll now have to select a set of IP audio codecs. The devices I''m about to mention are all similar in functionality and features; it''s likely that you''ll make a choice based on personal preference. Many have dual-Ethernet interfaces, but some do not. You could choose to place one such single interface codec on each LAN segment to maintain the redundancy we''re striving for.

Take, for example, the Mayah C10. This is a dual-channel codec, with dual Ethernet interfaces, that supports several of the well-known lossy audio codecs such as MPEG Layer 2, MPEG Layer 3 and AAC. More importantly for this application, it supports 16 or 24 bit linear PCM audio. Both analog and AES/EBU digital audio I/O are provided. Analog I/O is via XLR connectors with AES/EBU on a DB9 connector.

Another codec option is the AEQ Venus It is a 4-channel codec system with a single Ethernet interface. Other features include the option of an adaptive buffer in order to compensate for network jitter, along with FEC, and automatic reference clock adjustment to synchronize both ends of the communications link. The unit has balanced analog audio I/O through XLR connectors as well as AES/EBU digital audio I/O on a DB15 connector. ControlPhoenix management software is used to configure and manage the system. Linear PCM audio is supported at 32 or 48 KHz sample rates and various bit depths. Venus also has an embedded data stream that allows continuous serial communications from end-to-end, up to 38.4 kbps.

When I think of Telos, it''s usually for gear to do remotes; but the Z/IP is completely suited to “nailed up” connections as well. The device has dual Ethernet interfaces for streaming and control. It supports linear PCM audio along with a suite of lossy audio codecs. “ACT” (Agile Connection Technology) is used to sense network conditions and adapt codec parameters as necessary to maintain audio quality. Management of the device is done via an embedded web server. The unit features an RS-232 serial port for transmission of data such as RBDS, and an 8-channel parallel GPIO port. Analog audio I/O is supported via XLR connectors, in addition to Livewire AoIP via Ethernet.

Comrex offers the BRIC-Link, a dual-channel IP codec with a single Ethernet interface. Analog or AES/EBU digital audio I/O are available on ¼” TRS connectors. BRIC technology incorporates a jitter buffer manager that automatically balances delay and stability, dynamically adjusting delay based on network performance. Contact closures, and serial communications can be sent end-to-end on 9-pin and 8-pin DIN connectors respectively. The BRIC-Link includes an embedded web server for management, though initial configuration is done via a windows-based setup utility that runs on the same LAN segment as the unit.

- continued on page 4



The Musicam Suprima is another dual-channel IP codec. It supports the well-known lossy audio codecs as well as linear PCM. Analog and AES/EBU digital audio I/O are supported. Configuration of the unit is performed via IP or from the front panel. A 7-channel GPIO port is available as well. One unique feature of the Suprima is that it can send Dolby “E” via the AES/EBU I/O (when configured in its “transparent” mode) meaning that you could send up to 8 channels of audio through a codec that would normally just carry just two.

The Tieline Genie STL has some great features. It is another 1RU dual-channel codec, with linear PCM support at up to a 96 KHz sample rate. It has dual gigabit Ethernet interfaces (with IPv6 compatibility) allowing seamless redundancy by switching back and forth, without loss of audio, from a primary data link to a backup link if one fails and then subsequently recovers. When redundant audio streams are sent, the receiving codec automatically reconstructs audio into a single stream on a first packet arrived basis. Tieline''s Codec Management System is used for control, in addition to an integrated web GUI. A 4-port GPIO comes standard, along with in-band RS-232 communications capability.

The GatesAir Intraplex IP Link is another entrant into this field. The IP Link 100 is a dual-channel, full-duplex audio codec; the IP Link 200 accommodates two separate pairs (4 channels total) of bi-directional audio. For our application, it will encode in a linear fashion, though it can make use of lossy codecs as well. In addition, it will transport AES/EBU at a 192 KHz sample rate, thus allowing it to transport digitally sampled “composite” from end to end. IP Link comes with three independent Ethernet interfaces for network redundancy, and it has what GatesAir is calling ‘Dynamic Stream Splicing'' to provide glitch-free performance over IP networks. The user can prioritize stream sources at the output for automatic switch over and switch back between primary and secondary streams. Programmable FEC, time diversity, and interleaving of streams guard against burst packet losses. Analog and AES/EBU digital audio I/O is provided via XLR connectors, and a 4-port GPIO is available as well. Configuration and management is done via an embedded web GUI.

WorldCast Systems offers the Horizon Nextgen, a 1 RU, dual-channel IP codec. It''s a good match for this application since it comes with dual Ethernet interfaces, which can be configured to use separate IP networks for program transmission. Analog and AES/EBU audio I/O is supported via XLR connectors. The AES/EBU sample rate is selectable as 32, 44.1, or 48 KHz. Linear PCM coding is supported, again fitting well with our application. An auxiliary data input is available to transport serial data across the link, with rates up to 115.2 kbps. Control and configuration, including management of packet size, buffers, and QoS levels, is done via the embedded web server, or using the Worldcast NMS software. The unit also features WorldCast''s “Scripteasy” remote control software.

By the way, I''m not saying that you could get by with just an IP codec with dual Ethernet interfaces; clearly this device would be a single-point-of-failure in that situation. In the case of STLs, ideally you would continue to use one of the legacy systems as a secondary, or even tertiary, backup system.

Maybe you''ve read this far because you''re wondering how I eventually resolved the interference issue I described in my KJAZ radio STL system. I hired another local engineer in San Francisco (Bill Ruck) to figure it out with his Tektronix 2710 spectrum analyzer. Ultimately, he found a new paging transmitter that had been installed downtown was producing a nasty burst of wideband RF “junk” in its output when keyed. A bandpass filter on the transmitter''s output solved the problem. However, if I had the amount of experience then that I have now, I wouldn''t have trusted just a radio link to be the sole means of that one station''s program transport. That mistake caused some serious problems and disappointed a lot of listeners to the jazz station. I hope that I''ve convinced you to build the most robust system possible for your stations. Not only is it good engineering practice, you''ll likely sleep better at night.


Irwin is RF engineer/project manager for Clear Channel, Los Angeles. Contact him at doug@dougirwin.net



Want to read more stories like this?
Get our Free Newsletter Here!

Comments