Unless your studio or production facility is collocated with your transmitter site, you need to connect the two in a reliable, economical fashion. Whether this connection will be public or private is up to you, of course, and each type has its benefits and liabilities.
Let’s consider the means by which we can use either (or both, in some circumstances) to get your program up to the transmitter site.
Public
First let’s discuss public connections. “Public” in this context means internet connectivity that is shared amongst all types of users: home internet, office connectivity, mobile connectivity. It’s cheap, ubiquitous and quick to deploy.
As a user you will be subject to network congestion and occasional outages. It will be incumbent upon you to manage security of the system as well. The last thing you want is for a bad actor to “hack” an AoIP codec.
The “cheap” aspect means that you should lower your expectation of reliability from the start. Likely, the network you attach to will be designed to handle a certain amount of traffic, and when that traffic exceeds the design, all users suffer in some fashion.
Most applications for users on public networks use TCP/IP and thus have error correction built in. However, the AoIP streams generally use UDP (“best effort”) to reach the other side and don’t do as well with network congestion. Lost or delayed packets can cause gaps in the audio, which clearly we don’t want.
As one would expect, most AoIP codecs have built-in features to mitigate audio problems; but you will likely run into circumstances in which even the best codecs will exhibit noticeable problems with some public connections at some times.
Common types of public connectivity include 5G (or even LTE); broadband access provided by cable TV companies; wireless ISPs; and finally, Starlink. Multiple connections can be put together using SD-WAN (more on that below). A good resource if you are looking to make this type of connectivity work for you is MaxxKonnect.
Direct Internet Access
By Direct Internet Access I mean a network connection from a large ISP such as AT&T, Verizon, Spectrum, Frontier and numerous others. Speeds of 1 GB per second and higher typically are provided, and the assumption by the user is that the service (though not private) is going to be more reliable than connectivity previously described.
Also, though you may have DIA at your studio facility, if your transmitter site lacks that, the issues I’ve described still come into play.
Mitigating issues
Because of the shared nature of public internet connections (including DIA), you should use VPN tunneling; in that fashion you provide a large degree of security for both ends of the connection.
Another advantage to this technique is that multiple networks can be essentially “added” together at different sites to make what acts like one virtual network. This will be especially handy if you intend to communicate between more than one site.
At least two features of most AoIP codecs can be used to mitigate late and/or lost packets through public networks: configurable “jitter” buffer depth and forward error correction, or FEC.
In the context of streaming media, “jitter” just means that the packets from the origination point are not arriving at the destination with a consistent latency. By adding to the buffer “depth” on the receive end, the likelihood of all the packets being available for decoding to audio, without gaps, is increased.
Codecs may have a configurable buffer depth (good for point-to-point connections) or dynamic depth (more likely used for remote broadcasts). This adds to the delay of the entire system throughput, but if this link is for an STL, that delay is likely irrelevant.
FEC is a way to recover at least some lost packets: By using FEC, the sending side of the connection is sending multiple copies of them. If one packet is lost, a copy of the same packet will (hopefully) make it through.
FEC is specified in percentage, meaning that 100% FEC is effectively sending an entire copy of the stream along with the original.
The FEC packets typically are delayed slightly (likely configurable), the idea being since network congestion is dynamic, a slight delay may avoid whatever problem was encountered by routers inside your providers network, just milliseconds before.
I mentioned use of UDP as “best effort,” but Secure Reliable Transport (SRT) over UDP is frequently used as well. It’s beyond the scope of this article, but suffice it to say that SRT has built-in error correction to facilitate packet recovery, among other features, that are meant to cope with the issues of public internet usage.
SD-WAN
Software-Defined Wide Area Networks are gaining in popularity in broadcast applications because of some of the issues with “public” internet I’ve mentioned.
The premise of SD-WAN is that more than one IP pathway is used to connect sites together and that VPN tunneling is built in on each. In this fashion, if one connection fails, the SD-WAN gear moves all traffic over to the other, this providing (nearly) seamless operation.
Clearly the studio and the remote sites need access to more than one ISP in order for this to work; but they don’t necessarily have to be the same ISPs. A quick search online reveals countless SD-WAN providers like AT&T, Verizon, Spectrum Business (and others) and their equipment manufacturing partners, such as Cisco, Juniper, Palo Alto networks, F5 and others. For more detail on SD-WAN, see the recent Radio World article “Connectivity in the SBE Spotlight.”
If you or your staff have a high level of networking expertise, you can of course build your own version of SD-WAN. One way to do that has been previously covered in Radio World ( “NYPR Uses CloudJuncxion”). “Seeker SD-WAN” can be deployed in software or via hardware from that supplier; it can make use of multiple connections, thus providing a high-level of redundancy; and finally it can also be used to connect multiple sites together.
Another important aspect of its operation is that copies of the data streams pass over each of its networks. This is a valuable feature because of the nature of AoIP streams, as mentioned previously.
950 MHz radio
Now we turn to private connectivity — methods that are not only under your control and usually not shared with other users. I also won’t restrict this category to audio over IP.
If you are not already using 950 MHz radio channels, this may still be a viable option for you.
It can be difficult (sometimes impossible) to find spectrum that works at mountaintop transmitter sites or antenna farms that already accommodate multiple companies and FM stations. However, in some cases companies may have abandoned previously licensed systems after moving to wired connections. In other words, what may have been impossible 10 years ago may be possible now.
Bext and Moseley manufacture various types of radios for the 950 MHz band. Bext can accommodate composite baseband; Moseley is strictly a digital system (though one can apply analog or AES versions of the audio).
Unlicensed
Unlicensed radio links that work in the 2.4 and 5.8 GHz ISM bands are an option in certain cases. They are inexpensive, easy to install and configure, and can provide consistent service.
The problem is that you are using shared spectrum. What works one day may not work the next (or may simply work but not as well as it did the day before).
The FCC limits the ERP on either side (since these are duplex links), so distance may be limited. In any case it’s likely you’d be working with signals that aren’t that strong and subject to the vagaries of propagation, like any radio link.
Part 101 licensed radio links
The FCC’s Part 101 rules allow for the licensing of radio spectrum in the 6, 11, 18 and 23 GHz bands. Systems in these bands can provide high-speed, duplex connectivity.
This is typically used for IP-based traffic and backhaul, but can be utilized for a variety of purposes.
In order to license a channel in one of these bands you’ll need to make use of frequency coordination, followed by issuance of a Prior Coordination Notice (PCN), followed by a license application and grant by the commission.
Unlike the ISM bands, once you have licensed a channel as described, the likelihood of interference is low, and you can expect consistent service — subject of course to the vagaries of propagation, though your system design (completed before any PCNs are issued) should account for those.
Metro Ethernet
Metro Ethernet is a layer-2 network service that providers may offer across a geographical area that meets your needs.
From a practical standpoint you can think of it as a layer-2 switch connection “in the cloud.” If I build a 10-dot network on one end, that same 10-dot network shows up on the other end. Typical throughput is 100 Mbps.
Due to the “cloud” nature of this service I can’t describe it as anything but a shared service; look at the offered service level agreement before entering into any contracts. AT&T, Verizon and Spectrum offer this service, and I’m sure there are others.
Putting it all together
In order to build a highly redundant STL system you would make use of more than one of the types of connections I’ve described, together with an AoIP system that can be deployed over multiple links.
The major codec manufacturers have feature sets that can use multiple IP links for redundancy, such as the Worldcast Surestream, GatesAir Stream Splicing, Comrex CrossLock and Tieline Smartstream.
As I have written over the years, it’s wise to combine “wire” and “radio” in some fashion. In Los Angeles our AoIP codecs use both an 11 GHz and a Metro ethernet circuit simultaneously to pass audio from our studios up to Mount Wilson. Over the last eight years this system has performed well. It was configured in-house and we’ve expanded it over the greater LA. area over those same years (outside the scope of this article!).
You could also use the SD-WAN idea with the types of connections I have described, perhaps using economical public connections in addition to a private one.
Finally I will advise you never to place too much confidence in any particular connection. Experience has shown that circumstances can occur to take any service out.
I prefer private connections to public, though we use public connections extensively, because I like to have control over them. Regarding a public connection: Ask yourself what will happen if this circuit fails on the Wednesday before Thanksgiving? If your provider can’t be trusted to get it fixed at any time, it can’t be relied upon for the 24/7/365 service level that we all need.
Comment on this or any article. Email [email protected] with “Letter to the Editor” in the subject field.
