Design Article

IMG1

Enable VoIP Quality of Service from the Design Platform

John Warner and Frank Fruth, Director, Texas Instruments, Dr. Alan Clark, Telchemy

7/10/2007 11:16 PM EDT

Increased attention to voice quality in IP networks is placing more focus on the evolving standards that are needed by quality initiatives. The use of quality monitoring and advanced real-time algorithms requires a standardized architecture in which quality metrics can be exchanged between endpoints and communicated to a quality monitoring agent for more comprehensive analysis. There are many architectural and technological options currently available to implement this functionality. For core carrier networks, a standardized quality architecture is needed before any large-scale, next-generation quality assurance system can be deployed. This article describes several of the most pertinent quality architecture issues as they relate to IP networks, and existing circuit switched and cellular networks.

The need for a 'Quality Overlay'
In the past, the goal of IP Quality of Service (QoS) initiatives has been to guarantee a certain level of service for a particular service. These QoS schemes attempted to guarantee a minimum throughput speed or a maximum delay time, and they provide a framework for preferential treatment to certain customers or types of traffic. They did not guarantee a fault-free environment nor protect against network packet loss or jitter.

Thus, QoS initiatives typically do not guarantee a quality user experience for real-time applications such as voice and video. Also, they do not enable remedial actions in the event of service degradation. Another critical piece that is missing from these approaches is a view of the signaling layer that is used throughout the network to establish and maintain user connections. In today's complex IP network topology, it is not uncommon for a user's connection to traverse 10 or more different "networks" to establish a complete channel. These various networks may involve IP or Asynchronous Transfer Mode (ATM) technologies, the Public Switched Telephone Network (PSTN), and a variety of cellular radio frequency (RF) air interfaces.

A comprehensive quality architecture is needed to more effectively address these and various handoffs issues among the networks. Existing mechanisms, which typically are limited to allocating bandwidth and minimizing delay, are simply inadequate. Establishing a complete and quality architecture requires distributed intelligence throughout the network and across service provider boundaries. Placing intelligence in network endpoints is the initial step in realizing this goal.

Endpoints
The most commonly conceived endpoint instrument in any telephone call is the handset. It is easy to visualize two IP phones as the endpoints in a conversation. Besides the call itself, these IP phones could also transmit statistics on call quality. However, the definition of an endpoint should be extended to include any point in the total communications infrastructure involving any media or any technology, including cable, PSTN, wireless and others, where a transition in protocol or coding occurs. Under this definition all gateways and transcoding nodes qualify as endpoints. Figure 1 provides an illustration of endpoints for the purposes of this discussion.


Figure 1. IP Network Endpoints

Intelligence within IP phones and wireless handsets provide the most reliable and objective indicator of the user experience because this is the closest possible monitoring point to the user where both packet and content impairment data is accessed. In the case of IP phones, statistics can easily be accessed through the IP network. A variety of protocols are available for this purpose. (See sidebar located at the end of the article: "Protocols for compiling user experience statistics on IP networks,") In the case of mobile cell phones, quality metrics can be sent as data and require minimal bandwidth over today's cellular networks.

The design of the PSTN precludes quality reporting from a Plain Old Telephone Service (POTS) telephone because there is no data channel associated with the instrument. For the most part this is not needed because the 4kHz POTS voice channel is dedicated bandwidth with a fixed delay. This is not to say that problems don't arise in this environment; however, there are no mechanisms for gathering user quality experience metrics. For the most part, a POTS device is an "on/off" technology; it either works or it doesn't.

Placing a call from any phone to any other phone requires multiple gateways within today's communications landscape. For example, calls from an IP phone in a modern digital home can be connected to remote and often primitive villages in far away lands. Multiple types of gateways are involved in all of these complex connections. Sometimes these gateways perform the complex task of converting from traditional circuit switched technology, as found in the PSTN, to IP technology. In this case, both the PSTN and IP connections are effectively terminated and the gateway is in an ideal position to report on voice quality from both directions.

As mobile networks have evolved, several voice coding techniques have been developed. This evolutionary process is still going on today with many new codecs under development. When subscribers to a particular mobile network want to talk with a subscriber who may be on a different wireless, broadband or even the PSTN network, transcoding is likely to be required. This process tears apart and reassembles the voice packet. This is another point in the network where quality monitoring can take place in an unobtrusive manner.

The user quality monitoring functionality described above requires unobtrusive technologies that will not unduly affect the user experience itself or the processing load on the endpoint device. This scalable processing functionality is most often provided by a Digital Signal Processor (DSP). Because of their programmability and flexibility, DSPs are well suited to the changing landscape of today's communications infrastructure. As new codecs are developed and features and functionality evolves to meet the demands of new applications, the flexibility of DSPs will be put to good use.

Reporting quality metrics
In addition to the quality data gathered at the endpoints, probes can be deployed in a network to collect and analyze a variety of quality metrics. Historically these metrics have been used for troubleshooting. Active or passive probes strategically placed in the network could acquire the data needed for troubleshooting. Today, these probes can be embedded as software into endpoints, allowing for more comprehensive and real-time fault isolation and providing for an economic and scaleable way of monitoring performance on the edges of the network. In addition, specialized agent probes can be downloaded to endpoints when certain faults are detected.

Whether it is from an endpoint or from a network probe, equipment vendors and network operators can choose from any of several protocols for reporting quality metrics. New standards for this purpose are currently being developed and existing standards are evolving. (See sidebar below) In addition, new quality management overlay systems for the IP network are evolving which can collect information from intelligent endpoints on the quality of real-time voice or video services. These sorts of quality management overlay systems are capable of expert analysis of call quality data and are designed to integrate into existing SNMP-based management architectures. These overlay quality systems allow the service provider to proactively identify degradations in the quality of the user experience and to take remedial actions.


Figure 2. Embedded Software Agents Monitoring Quality

Figure 2 illustrates how industry standards can be used to overlay a quality management system on an IP network. The drawing shows embedded software probes, such as industry-standard VQMon agents in IP phones, monitoring call quality in real time. These agents create RTCP XR messages that are exchanged every five to 15 seconds to provide both quality feedback and to allow more accurate estimates of quality, since each endpoint can incorporate information on the quality of the service provided by the other endpoint, such as echo level. At the end of a call, a SIP QoS report is sent to a call quality management system (Telchemy's SQmediator is shown in Figure 2). Voice Quality Manager can then provide comprehensive summaries and analysis via SNMP to network managers.

Ensure quality now
Many of the capabilities of a quality architecture that could be overlaid onto IP networks already exist today. As previously mentioned, industry standards have been developed and approved that enable endpoints to monitor and accurately report quality data on a regular basis. Being based on open standards enhances the scalability of an overlaid quality architecture, a critical feature for rapidly expanding IP networks.

Moreover, such quality architecture must be able to rapidly respond to ongoing conditions. Interrogating endpoints in real time to determine the root cause of a fault or degraded service could initiate corrective actions to mitigate the degraded conditions immediately. Mid-level points in the network would collect and manage the quality data generated at the endpoints. Of course, the deployment of such architecture must be cost-effective and its impact on the performance of endpoints should be negligible.

Moving pieces into place
Even though all of the pieces for a quality architecture are already available, establishing an architecture to address voice quality will not happen overnight. It is likely that regulatory and privacy issues as well as inter-carrier issues like the unwillingness to share quality metrics will slow the process. For example, exactly what parameters reported in RTCP-XR would be considered private and not shared? Furthermore, will Carrier A allow the transmission of quality metrics from its subscribers' IP phones to the IP phones of Carrier B? Or will Carrier B transmit quality metrics from its session border controllers or gateway systems to the IP phones of Carrier C? These issues delve into uncharted waters and they will certainly have an effect on how quickly any quality architecture can be deployed.

Nevertheless, the nature of IP and the desire for a higher quality user experience has shown itself to be a driving force in moving standards forward to address quality issues. This trend is likely to gather momentum. Once in place, this same infrastructure can support video in addition to voice communications.

Sidebar: Protocols for Compiling User Experience Statistics on IP Networks

RTCP Voice Quality Reports

  • RTCP-XR (VoIP Metrics) or "XR" has been defined in RFC-3611 and includes such parameters as packet loss rate, packet discard rate, burst density and duration, gap density and duration, round trip delay, end system delay, signal level, noise level, Residual Echo Return Loss (RERL), MOS-Listening Quality, MOS Conversational Quality, and information on jitter. TI's PIQUA quality technology, for example, uses VQMon from Telchemy which provides the MOS score values. VQMON provides a proven method for accurately measuring MOS scores.
  • RTCP HR or "High Resolution" is currently under development in the Internet Engineering Task Force (IETF) and is intended to augment the existing RTCP XR by adding new block types for reporting higher-resolution metrics as needed by some applications in carrier networks.

Session Initiation Protocol (SIP)
SIP is one of many protocols that can be used to provide end-of-call quality reports. With SIP voice quality information can be pushed to a call server at the end of each call for off-line analysis and reporting.

Real-Time Streaming Protocol (RTSP)
RTSP is a diagnostic protocol by which remote clients set-up and configure one or more diagnostic flows that can include the selective collection of all available system statistics and diagnostics. Once the diagnostic flows are set-up, the diagnostics streams are pushed to the client where it is collected, processed and forwarded as required. Standard RTSP methods such as SETUP, PLAY, PAUSE, TEARDOWN, GET_PARAMETER and SET_PARAMETER are used to set-up and configure the diagnostic streams.

Other Relevant Standards

  • Signaling-based reporting:
    H.248.30--Megaco extensions
    H.460.9 Annex B--H.323 extensions
  • Standards that mandate RTCP XR:
    G.799.1--VoIP trunking gateway specification
    PacketCable 1.5--U.S. cable industry specification

About the Authors
Dr. Alan Clark is the founder and CEO of Telchemy. He was previously CTO of Hayes Corporation, Director of Research for Dowty Communications and System Architect with British Telecom. Clark played a key role in establishing industry-wide voice/data integration standards and is the inventor of the V.42bis data compression algorithm and the architect and editor of the V.58 network management standard. Published widely, he has nine granted and five patents pending and is recognized as a major authority in QoS and Packet Voice research and development.

Clark has a Ph.D in Information Theory, has driven the development of the performance management framework for VoIP within IETF and ITU, was the developer of the V.42bis compression algorithm, has twelve granted patents and has been actively involved in the development of networking and telecom technology for over 20 years

Frank Fruth, Director, Multimedia application software development, manages the development efforts for multimedia application software within TI's DSP Systems group. Prior to his current role, he directed the development of core voice over packet software technologies deployed in a broad range of TI's VoIP products, including voice over cable applications. Since joining Telogy Networks in 1997, Frank has been involved in the development of voice, fax, and modem over packet solutions.

Frank holds a BSEE and MSEE from the University of Maryland.

John Warner is a high density Product Manager. Prior to joining Texas Instruments' Voice over Packet business unit, Warner served as the Director of Pre-Sales Engineering for several optical companies including Kirana Networks, Lucent Technologies and Chromatis Networks. Previously, Warner held the position of Senior Sales Engineer for Nortel's Remote Access Server and SS7 Gateway products.

Warner has also held positions in technical support, operations, engineering and systems analysis for Computer Sciences Corporation and GE Spacenet. He has over 25 years experience in the communications industry.

Warner received a bachelor's of science degree in computer science from Indiana University of Pennsylvania. Instruments He can be reached at: jwarner@ti.com


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm