Getting physical with VoIP

Developing robust, manageable T1/E1, T3/E3 or Sonet/SDH physical layer interfaces is far more complex than simply establishing connectivity between data pipes. This article discusses what is involved and how to avoid common errors.

VoIP engineers face all the same set-up, monitoring, problem isolation/resolution issues found in traditional WANs, with the added complication of a network that is even more likely to traverse multiple carriers and technologies – T1's within T3's within Sonet and then on to Ethernet pipes (see Fig. 1). For this reason, fault isolation and correction are more complex, making compliance with service level agreement (SLA) a bigger challenge than usual.

When worlds collide
Network convergence means that voice and data requirements may "collide," because the optimal delay/accuracy characteristics for each one is almost diametrically opposed to the other. Protocols to implement VoIP have improved significantly, but this collision issue can still come into play.

Voice quality has always been impacted by excessive jitter, as well as by end-to-end, and round-trip, delay. Packet implementations introduce other potential sources of quality issues, including new forms of jitter, packet delay and packet transmission integrity. The effect of all these sources of quality degradation is cumulative, and the entire system must be carefully engineered to stay within acceptable limits.

Good WAN engineering minimizes the delay and jitter introduced by the local equipment. It also provides good line control and early warning of emerging problems. This gives the VoIP traffic the best chance of accurate packet transport, short delays, maximum up-time and controlled rerouting.

The fast lane
Designing high-speed, high-bandwidth WAN interfaces also requires hardware designers to acquire a thorough knowledge of regulatory issues such as FCC rules and T1/T3 standards, carrier requirements such as environmental issues and voltage protection, and high-speed signal design, which is necessary to address the higher clock rates needed for VoIP.

Careful designing for high-speed signals is a must. The faster the interface transmits and receives packets (as represented by the clock rate), the faster the hardware needs to be to process the payload and overhead information. This translates into increasingly higher frequencies running through the board. Just as with the visible spectrum, higher frequencies are more “delicate” and are easily contaminated or overwhelmed by nearby signals. They can even be the source of contamination themselves. Higher frequencies experience more power loss over a given length of wire; so their physical placement on the printed circuit board and signal strength must be considered.

Common pitfalls
The most common mistakes made when engineering VoIP interfaces are: incorrect clocking, insufficient processing power, and incomplete WAN overhead management found in the alarm, performance monitoring (PMON) and signaling code. Compared to traditional voice networks, the VoIP physical layer interface is frequently under-featured, poorly integrated and less robust.

Missing features impact the potential to identify and correct problems prior to a hard failure, reduce the ability to isolate and repair hard failures quickly, and make it difficult to maintain a stable call environment in the presence of intermittent glitches on the line.

The Layer 1 code often doesn’t fully comply with all the applicable standards and regulatory requirements from ANSI, CCITT, ITU, Telcordia, legacy AT&T standards, and various existing carrier standards. And, because real-time voice and data applications drive their continued evolution, these standards are moving targets.

Incorrect clocking
When dealing with a synchronous communication protocol, accurate clocking for reading and writing data is imperative. It must meet certain minimum quality standards and be in the same frequency and phase. The simplest solution is for every element to use the same clock, and if synchronization fails, to have a clock recovery scheme and an alternate clock source plan. The minimum clock quality required for wide-area networks is noted in Table 1:

Clock traceability also is very important. In a hierarchical network, clock traceability is fairly straightforward, and manageable with respect to quality and source. In non-hierarchical Sonet/SDH networks, this can be more difficult. However, it is even more important because, not only are these newer networks flat, they tend to be populated by many different providers.

To address this, Sonet/SDH adds a new mechanism, the sync status message (SSM), which is processed according to GR-253, ETSI 300-417-6-1 and G.781. The SSM can identify the quality and traceability of the clock source and permits the network to choose the best clock available in the event a problem arises.

In both flat and hierarchical networks, the clocking scheme and control must be designed to ensure that:

• it is possible to trace to an identifiable primary clock reference source
• higher stratum clocks are never slaved to lower stratum clocks
• all network elements have both a primary and a secondary source in case of a primary failure
• loop timing is avoided

Clocking is fundamental to a successful VoIP implementation. Clock issues are frequently the root cause of networks that 'sort of' work, because they lack robust line quality.

Processing power
Insufficient processing power can create enormous problems. However, these problems can easily be avoided by calculating the MIPS needed by all processes and then doubling that number.

Insufficient MIPS can result in problems that seem to be anomalies. Furthermore, they may not fully manifest themselves until the equipment is under load, or until certain things happen concurrently. WAN interfaces are real-time systems, which means that they must be able to complete a task in a known timeframe. If a system is under-configured and cannot meet these time criteria, it will fail.

A WAN interface equipped with a 10mS timer has enough resolution for robbed-bit or channel associated signaling (CAS). If the CPU is over-burdened and the timer becomes unreliable, the system may fail. If this occurs, the task that fails may not be the real source of the problem. This, in turn, can cause hours of troubleshooting headaches.

Budgeting for the WAN burden is fairly straightforward. For most framers with direct memory access architectures, each span (T1, E3, etc.) will consume roughly one-fourth of a MIP. If signaling is added, as it is in a gateway application, the MIPS consumption goes up to 1 to 1.5 MIPS per span (assuming all DS0s are running voice signaling). For parts with indirect accesses, MIPS consumption will increase even more. Sonet/SDH budgeting is similar, but somewhat more complex as it is dependent on the specific configurations that are used. Budgeting for the worst-case scenario is advisable.

Importance of standards
The ability to segment the network to pinpoint the location of service failures is increasingly important in an environment where a growing number of carriers and private networks are found between the two end points. Repeaters have traditionally been used not only to boost signal strength, but also to perform segmentation. Used between networks, repeater handoff is of a known signal quality and power. Identifying whether problems originate within, or between, networks, the owner of the segment can monitor for, and correct problems prior to, hard failure. The alarm and performance monitoring functions present in repeaters yield the same benefits in any WAN interface, especially in VoIP networks.

The WAN interface technology required for VoIP is defined by several domestic and international standards (see Fig. 2). In North America, the ANSI T1.231¹ family of standards applies to the physical layer of T1, T3 and Sonet. In addition, T1.403 and T1.404 govern T1 and T3, respectively. T1.105 applies to Sonet.

Typically, little attention is paid to compliance with standards — at least until problems arise. Developing sound VoIP WAN interfaces demands an understanding of the standards that apply to three critical physical layer interface functions: alarm processing, performance monitoring and signaling.

Alarm processing
Alarm processing, the most important function after the raw ability to carry payload, provides a critical ability to inform the end points, hold transmissions when required, identify the source of problems, and ensure call stability.

Alarm conditions specified in T1.231 include loss of signal (LOS), out of frame (OOF), or a number of other events. Alarm software must do three things:

• handle multiple events,
• respond to simultaneous defects, and
• be able to transmit alarms back into the network as required.

A traditional voice application is more complex than a data application. In the event of momentary glitches on the phone line, calls in progress must be maintained. This is accomplished by freezing the signaling bits in their last known good state. If the signaling bits are not "frozen," an OOF or LOS will garble the signaling bits. This causes the system to interpret the glitch as a change-of-call state, and calls are likely to be dropped.

In this scenario, when OOF or LOS is detected, not only does the integration timer need to be started, but signaling states also need to be frozen while the system determines whether or not there is a persistent problem on the line. If the OOF/LOS never integrates into a failure alarm, all call states remain as they were, and no calls are lost. If an LOS/OOF failure is indicated, all calls are taken down and RAI is transmitted.

Similar mechanisms are used to insure stable VoIP calls. Although Layer 1 is not part of the SIP specification, physical media failure means that packets can’t be exchanged. To determine whether the physical layer is accessible, some VoIP systems use latency-prone mechanisms like "keep-alive" messages. By using established WAN technology like defect and alarm detection, physical layer failures can be incorporated into VoIP call processing.

The examples given here are simpler than situations that occur in real-world scenarios, where complex alarm conditions involve multiple, simultaneous defects. Compliance with WAN management standards ensures the ability to achieve optimal service levels under complex conditions.

Performance monitoring
Important even in VoIP applications, performance monitoring (PMON) is designed to provide warning of problems prior to hard failures. Proper warning gives the physical layer of the network the information required to perform automatic re-routing, thus minimizing packet loss. As a line degrades, PMON allows network managers tosee that packets are being lost, to identify the root causes of the failure, and to take focused, corrective action.

PMON provides the detail necessary for remote troubleshooting and isolates the exact location of failures arising from poorly configured systems and inadequately provisioned services. T1, T3, Sonet and DSL each have distinct PMON parameters. T1 parameters, for example, include bipolar violations (BPV), excessive zeros (EXZ), cyclic redundancy check (CRC-6) errors, frame bit errors (FE), loss of signal (LOS), out of frame (OOF) and alarm indication signal (AIS). Engineers need to understand the parameters applicable to the specific technology being implemented.

One-second performance report messages (PRMs) and near-end information are captured over time and provide advanced notice of degraded line service. T1.231 defines the data necessary to identify and resolve impending problems prior to catastrophic failures. Data is captured in 15-minute buckets over 48 hours for near- and far-end information. This data and related loopback tools, which are used to test lines and the stages inside transceivers, are referred to as maintenance or performance monitoringPMON. PMON provides problem isolation in the event of hard failures, yet it is often missing or incorrectly implemented.

A final source of performance information is found in threshold crossing alerts (TCAs), which provide notification when a monitored parameter reaches or exceeds a preset level. Since TCAs are 'alarms' for emerging problems, failure to implement them deprives managers of the opportunity to initiate corrective action before problems reach critical levels.

Telephony gateways & signaling
For the gateway application, the same VoIP WAN platform can be used with the addition of the appropriate signaling translation or interface. Robbed-bit signaling, channel associated signaling or PRI D-channel must be implemented as specified in the product requirements. And bit freezing also must be implemented at this point.

When connecting to the public network, SIP or other protocol signaling from the IP side is translated into signaling recognized in the traditional network. Traditional methods for handling voice traffic signaling include robbed bit signaling, CAS and PRI D-channel for ISDN usually at the access side, and SS7 in the core network. VoIP protocols operate at the IP layer, but in gateway applications, they must interface with the traditional protocols in Layers 1 through 3. Proper translation is required both into, and out of, the VoIP network, requiring precise knowledge of both sides.

The signaling function in VoIP gateway equipment must accommodate many different signaling models to insure wide application. There are more than 40 varieties of signaling models found in North American networks including the use of toggling bits to extend the limitations in the older 2-bit systems. If signaling models are not matched, complete failure often results.

Incorrect translation at the gateway can result in everything from call instability to outright failure. And worse, calls might be connected to the wrong party. Since gateways by their nature add delay, inefficient implementations can create connections with an echo or a sound quality like that of walkie-talkies.

WAN development
The WAN physical layer is more challenging than other parts of VoIP development, because engineers often underestimate the complexity of WAN interfaces.

The VoIP side of the interface may rely on a traditional WAN circuit for IP packet transmission. Typically, an Ethernet phone is routed through a PBX to the demarcation point at the gateway. Everything from the VoIP phone to the gateway is the responsibility of the equipment manufacturer and is proprietary. But beyond the demarcation point, standards compliance is a must (see Fig.3).

Beyond clear specification of requirements, the primary considerations are ensuring enough processing power and the ability of the OS to support the real-time requirements of the technology. WAN development can then be done in parallel. The choice of framer depends on whether different hardware will be produced for different parts of the world and whether population-build options will be used.

Charting success
WAN networks have been around for a long time, and the physical layer has many, feature-rich interfaces that interact with each other. Any feature by itself is simple enough, but taken together, they exponentially increase complexity.

Engineering a solid physical layer VoIP interface is a non-trivial effort. Yet a WAN interface will differentiate one product from another if it does not work properly.

Although it lacks the sex appeal of other aspects of VoIP, getting the Layer1 code right is important. This is true whether a company develops everything internally, engages consultants who are experts in engineering WAN interfaces, integrates off-the-shelf source code and software, or purchases a turnkey solution with pre-integrated hardware and software. The only wrong choice is to underestimate the complexity of the physical layer code and omit features needed for a solid and robust VoIP implementation.

About the author
John Brandte is vice president of marketing and business development at NComm, a provider of wide area networking source code, software and custom consulting. Mr. Brandte is the co-author of The Communications Developer's Handbook. His experience in the communications industry spans multiple disciplines, including engineering, standards development, business planning and analysis. He can be reached at john@ncomm.com.

References

1. Can be purchased at www.atis.org/atis/docstore/doc_display.asp?ID=3142