I get many questions about IP audio transport. Generally, these involve technical issues of one sort or the other. This article takes a different approach. Instead of tech, we will look at the management analysis involved in evaluating if IP audio transport is suitable for your application. And, if so, what analyses are needed during pre-deployment and deployment.
First we’ll examine project scope, and then take a look at risk, some comments on implementation, and finally we’ll look at cost.
Project scope
APT has worked with projects ranging from dozens of stations linked in a fully meshed network across distances of hundreds of miles, to simple STL links to 10 watt repeater stations 20 miles away.
Rolf Taylor On large-scale projects, like that which the BBC has recently deployed in Scotland, IP makes sense for several reasons:
- Modern MPLS networks can offer a fully meshed network where each site has equal access to another site, all with controlled quality (delay, jitter and packet loss all guaranteed by a Service Level Agreement).
- Such networks also allow your IP traffic to be handled within a multiple class-of-service hierarchy. Therefore, your IP audio can utilize the same network as your general wide-area network (WAN) data traffic between the various sites. For example, IP audio may be given the highest priority, followed by VoIP traffic, followed by general business traffic.
On the opposite side of this spectrum are the needs of small, typically nonprofit stations that need STL connectivity to low-power repeaters. The number of listeners on a repeater may be quite small, so typical STL options are often too expensive. There is also a strong aversion to licensed STLs. In this case generic IP paths can be an attractive for the following reasons:
- A variety of xDSL and cable modem options means that odds are good you can get something at your sites.
- Simple to order, and license not needed.
- Professional-grade codecs include extensive support, which can be leveraged during deployment.
Between these two examples are the many customers who have implemented IP radio connectivity (both licensed and unlicensed) between two or more sites. In this particular case, the skills required include RF site design, as well as IP and audio skills. There are advantages here as well:
- Complete control of the IP environment.
- The simplicity of configuration in IP over the tedious configuration of T1 time slots and drop and inserts that would be required for complex multisite projects.
A key consideration will be not only the current scope of the project but also the potential future scope of the network. IP itself is flexible and easily upgradeable when bandwidth requirements change but the associated equipment, chiefly audio codecs, may not be. A modular, card-based system is recommended for applications where future expansion is a possibility.
Considering risk
In most cases, IP audio transport techniques are fairly young and in some cases you may be one of the first to implement it in a specific way.
Needless to say, there is always some risk involved in being an “early adopter.” Of course, this risk generally is balanced by the benefits of new technology. In any case, it behooves one to understand the risk involved, and take steps to ameliorate it whenever possible.
Some factors to consider are:
- The skill set of the implementers. A solid in-house IT person can be a valuable asset; it is important to involve him/her early in the process so as not to appear that the audio project is intruding on their turf. Ideally, a certified network engineer would be involved, though this is often not the case. In the case of a large scope project, this is a requirement. In the smallest deployments this is certainly not required.
- If RF IP links are involved, extra care must be taken to ensure the path calculations prioritize reliability over speed. Typical IP applications allow data to be re-sent, and therefore are generally optimized for speed. Audio networks require error rates that are lower by several orders of magnitude and thus this must be taken into account during the design stage or results will suffer.
- The reputation and reliability of your suppliers. Ensure that your codec supplier has experience in deploying the equipment in IP applications relevant to your own and that the units have been tested in the field.
- In medium- to large-scope projects you will need to ensure that the network meets the quality level required for audio. In many cases this means ensuring the IP provider can guarantee, in writing, that service will be maintained within pre-determined limits. Typically this involves the carrier using a Quality of Service (QoS) mechanism, and you need to ensure that your equipment supports the method to be used. The parameters for acceptable performance must be addressed in the negotiation/ordering phase and the carrier should provide you with a “Service Level Agreement” (SLA), which outlines these details in a legally binding agreement. Be sure to get this prior to signing the contract, and review it with your IT team and codec provider before doing so. A handshake will not do in place of an SLA!
Implementation
- Expect to qualify/test your network end-to-end as soon as it is available. This should be done rigorously over a period of at least a week and can generally be performed rather easily with software tools on a regular PC. Even simple tools such as the “ping –t” command can provide substantial information. Your codec manufacturer should be able to recommend additional tools (or e-mail us at [email protected] for a copy of APT’s IP Verifier Tool). Compare your results to the SLA. In some cases the network provider has online tools that will also allow you to monitor the connection, but at the time of initial testing it is important to use other tools as well.
- If the network will handle non-audio data, pay careful attention to assign equipment to the correct “Class of Service” (CoS) using Difserv or other QoS mechanism. The amount of data at a given CoS level must not exceed the amount specified in your contract or severe problems can result.
- Considering the above, it is recommended that your second-round testing be configured to emulate the audio data closely (for example, APTs IP Verifier software tool can be configured with the same bit rate, QoS and IP ports you will be using for audio). Next start adding applications (starting with those at the lowest CoS) to the network. Once all non-audio applications are working successfully, and your testing continues to show that the top COS is working properly, deploy the audio network. Then use the diagnostics built into your codecs to continue to monitor a few weeks further.
Costs
While the dollar discussion comes last in this article (as indeed it should within the analysis of the various options available for audio delivery), it will not be considered ancillary at the station manager and CFO levels; in fact, it will be the decision.
As with any WAN upgrade, the migration to an audio over IP platform has both “hard” and “soft” costs associated with it. Specifically, the challenge of the engineering and IT departments is to capture all of the costs associated with a new private IP MPLS network (both hard and soft) and articulate these in an all-embracing Total Cost of Ownership (TCO) model that reflects true Return-on-Investment (ROI).
The TCO model compares two different solutions (the existing “business as usual” to the “the proposed private IP network”) over a period of time (typically five years) in “today’s dollars.”
Hard costs include access and port costs, along with premiums for 100 percent real-time CoS required for audio transmission (along with other time-sensitive applications such as VoIP and video teleconferencing). It is vital that all existing hard costs are captured.
For example, a radio station’s core competency may be audio broadcast but it is also communicating with the outside world on a private data level (to other stations and corporate headquarters, for example), on an Internet level and with voice calls. Modern MPLS-powered private IP networks typically are capable of aggregating all types of traffic (audio, data and voice) through the same MPLS port.
The soft costs are even more interesting. How about down-time? With the fully-meshed topology of MPLS private networks and the (typical) “five 9s” service guarantee of most Tier One carriers, there are a number of options available outside the audio application that are not typically possible in an Internet or in many of the current WAN environments. Just one example is intra-corporate video conferencing.
A final word about cost savings of migration to a private IP network powered by MPLS: It is our experience that the new port and access costs often will cost more than the current solutions, but not much more, particularly if care is taken to capture all STL, MAN and WAN costs currently in place.
Furthermore, it does not take too much of a deep dive to uncover the hidden advantages such as flexibility and scalability that will be enjoyed through migration to the MPLS platform, in most cases resulting in a positive ROI for the investment for years to come.
APT has garnered great experience of working in partnership with broadcasters facilitating the migration to an IP audio infrastructure. From major national, country-wide networks to individual STLs or remote links, the key principles are always the same. Take utmost care in the selection of your service provider and codec equipment and plan to ensure optimum reliability, optimum audio quality and minimal risk.
The author is applications/support engineer with APT.
The company offers “A Practical Guide to IP Audio Networking,” available by e-mailing [email protected].
