Voice Quality Paper

Strategy for ensuring

Solution

Voice Quality

December 2002

This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Lucent), except in accordance with applicable agreements, contracts or licensing, without the express written consent of the Customer Documentation organization and the business management owner of the material.

Publisher

Lucent Technologies

P. O. Box 52179

Phoenix, Arizona 85072-2179

623-582-7000

Notice

Every effort was made to ensure that the information in this Technical Overview was complete and accurate at the time of printing. However, information is subject to change.

Mandatory Customer Information

Trademarks

IMerge™ is a trademark of Lucent Technologies.

Other product and corporate names may be trademarks or registered trademarks of other companies and are used only for explanation and to the owner’s benefit, without intent to infringe.

Any changes or modifications not expressly approved by the manufacturer could void the user’s authority to operate the equipment.

Support Telephone Numbers

Information Product Support Number

For AG Communication Systems, 1–888–888–AGCS (1–888–888–2427)

For Lucent Technologies, 1–800–225–7822

Disclaimer

The information contained in this document is for system planning information and is subject to change. This feature prospectus does not represent a commitment by Lucent Technologies to develop this service, or any associated service, in its entirety or in part.

Table of Contents

1Introduction

1.1Purpose and Scope

1.2Document Organization

1.3Standards

2IP Telephony Interoperability

2.1What It Takes to Be Carrier Ready

2.1.1Introduction

2.1.2Functional Interoperability Testing

2.1.3Voice Quality Testing for each CPE Device type

2.1.4Subjective voice quality testing

2.1.5PSQM and MOS statement

2.1.6Objective voice quality testing

2.1.7Internal Field Trial

2.1.8Conclusion

3EVALUATING NETWORK QoS

4WAN Evaluation and Design Guidelines

4.1Introduction

4.2WAN Evaluation Criteria

4.2.1Introduction

4.2.2Existing Telecom Infrastructure

4.2.3Performance Needs

5Quality of Service

5.1.1Traffic Classification Types

5.1.2Trust Boundaries

5.1.3Traffic Classification at Layer 3

5.1.4Delay

5.1.5Jitter

5.1.6Packet Loss

5.2Summary of Generic Guidelines

- 2 -

1Introduction

1.1Purpose and Scope

This document provides a high-level overview of voice quality and testing methods that Lucent uses to measure the voice quality of the iMerge Voice over IP (VOIP) system. This document also covers some LAN and WAN design guidelines.

1.2Document Organization

The remainder of this document provides the following information:

Section 2 IP Telephony Interoperability: What It Takes to Be Carrier Ready. This section covers the methods of iMerge solution and CPE testing that Lucent employs to approve the iMerge solution and associated CPE for use.

Section 3 Excerpt from an article fromCommunications Convergence “Measuring VoIP Voice Quality, Part 2”

Section 4 WAN Evaluation and Design Guidelines: This section addresses the need for WAN evaluations and guidelines for the design of the VOIP network.

Section 5Quality of Service,as itshould be implemented into the enterprise LAN.

1.3Standards

This document assumes that the reader has a fundamental understanding of packet-based voice telephony, as well as a conceptual understanding of voice quality testing methods and the architectural elements that comprise a packet voice telephony network.

2IP Telephony Interoperability

2.1What It Takes to Be Carrier Ready

2.1.1Introduction

To ensure that customer premises equipment (CPE) devices provide the right features, capability, and performance, CPE vendors are provided with two complete sets of documentation. The Equipment Interface Document (EID) explains the signaling interface required for CPE products to interoperate with iMerge. Additionally, the Functional Specification Document defines the CPE functionality that is mandatory, or considered highly desirable by Lucent’s existing and potential customers. These documents are used as the foundation for generating the test suites used during interoperability testing. Interoperability is achieved after successfully passing tests that require the CPE to:

Functionally Interoperate with iMerge. e.g., comply with the iMerge Centrex Feature Gateway (CFG) Equipment Interface Document (EID) and Functional Specifications.

Demonstrate appropriate Voice Quality.

Demonstrate acceptable performance, stability, usability and maintainability

Perform successfully in a real world trial.

The first phases of testing are performed in a controlled laboratory setting where all aspects of the testing are under the control of the tester. In the last phase of testing, the internal employee trial, the CPE devices are used by real customers (company employees) in their normal day-to-day telephone activities. This testing methodology assures that customers who purchase the iMerge and approved CPE devices will receive a level of service that satisfies or exceeds all needs and expectations.

The iMerge supports the following broad classes of Customer Premises Equipment.

IP Phone– IP Phones are self-contained telephone sets that provide similar operation to a conventional analog or ISDN phone set with the exception that they directly connect to an Ethernet carrying the VoIP signaling and packetized payload from the iMerge.

Soft Phone– Softphones are PC software used to implement the IP Phone functionality described above. In other words a softphone application running on a PC terminates the VoIP signaling and packetized payload from the iMerge and uses the PC’s audio connections to provide voice transmit and receive functions. The softphone uses the PC’s display and user input devices to emulate the user interface on an IP phone.

Access Gateway – Access gateways are CPE devices that interconnect the VoIP signaling and packetized payload from the iMerge with one or more conventional (loop connected) phones. Different models of gateway are used to connect to Analog, P-Phone, and ISDN phones, stand alone device or component, DSL IAD, Cable modem (also known as EMTA or BTI). Application may limit the use of particular CPE. Refer to the application documents to determine the access gateway model.

2.1.2Functional Interoperability Testing

This phase of testing is primarily designed to validate that the CPE device can communicate effectively with the iMerge and to assess how well it complies with the EID and Functional Specifications.

The functional interoperability test plan has test cases in the following major areas:

Registration and Provisioning / Basic Call Processing
DHCP / Maintain Stable Calls
Phone Functionality/User Interface / IP Network
Subjective Call Capabilities / Stress loading
Documentation / Security
Administrative Capabilities / Diffserv tagging
Call Features (message waiting, distinctive ringing, three way, etc.) / Call traffic capacity testing

These areas cover the entire range of CPE operation, from basic operation to how well it can be configured and administered by a system administrator in a customer network environment.

Certain CPE-specific capabilities or features (such as CPE call logs, stored dialing directories, documentation, line features, etc.) may be verified coincidentally during interoperability testing. However, the CPE vendor remains responsible for fully testing any such features that are not directly related to the iMerge interoperability.

2.1.3Voice quality testing of the iMerge Solution for each CPE Device type

This phase of testing involves evaluating the voice quality of the CPE device. How humans perceive sound and in turn judge voice quality is not straightforward enough to allow voice quality to be easily or accurately measured solely with objective test methods. The voice quality evaluation approach includes both subjective and objective testing, but overall emphasis is placed on subjective testing, since voice quality is subjectively perceived.

2.1.4Subjective voice quality testing of the iMerge Solution

For subjective voice quality testing, experienced/expert listeners, who are trained to listen for and identify impairments in voice quality, are used. This method has advantages in that it provides judgments as to general voice quality as well as providing additional information as to the actual impairments heard and surrounding circumstances. This also allows further investigation, problem resolution and provides the information needed to test updates to the product to validate impairment resolution.

In most cases, evaluation starts with subjective conversational testing since it is the most straightforward and expedient way to obtain initial voice quality measurements. Also, there are some impairments that may only show up in conversational testing.

Examples of some of the voice clarity problems that can be identified in this phase of testing are:

Distorted speech

Speech too loud

Speech not loud enough

Clipping of speech or noise, in double talk situations

Clipping of speech or noise (without double talk)

Dial tone, Ringing, Ringback, Hookflash delay

Echo

Awkward conversation interaction -- delay

Lack of comfort noise, sounds like connection dropped

Extra annoying noise(s)

Fluctuating speech or noise levels

2.1.5PSQM and MOS statement

Perceptual Speech Quality Measure (PSQM), and other similar tools, are analysis tools designed to identify potential perceptible quality degradations, they are not a measure of voice quality. PSQM can vary without human perceptible differences in audio quality. In addition, some serious voice quality degradations (e.g. delay, echo, etc.) will not show up in PSQM. These tools point out potential problem areas, but should not used to provide an overall assessment of voice quality.

Lucent does not currently use Mean Opinion Score (MOS) to determine speech quality. Instead, "expert listeners", who are trained in detecting human perceptible voice quality problems in VoIP telephony, work with product developers to ensure a high-level of voice quality. These expert listeners work with the latest ITU-T and IETF recommendations for measuring voice quality, as well as several proprietary methods, to make certain the product meets voice quality measures.

2.1.6Objective voice quality testing of the iMerge Solution

Objective test methods are used to measure attributes related to voice quality by utilizing test equipment.

Examples of objective testing are.

Latency or delay

Packet loss

These testing methods are used to point out potential problems and are excellent tools for analyzing impairments and their root causes. An additional conversational test method used for evaluating voice quality and for reproducing impairments is the recorded conversational method (RCM). For RCM testing, digitally recorded two-way conversations between various types of voices (i.e., male to male, male to female, female to female) are played through the system, and the resultant listening path is digitally recorded. The digital recording of the listening path is then played back and analyzed for perceptible quality degradations.

The initial testing for determining if echo is a problem is accomplished through the conversational tests mentioned above. Another method used is the composite source signal (CSS) echo loss test. This test is performed by playing a digital recording into the device under test, recording the return listening path and analyzing the recording for instances of echo. A G.168 echo loss test is also used for echo detection. This echo loss test varies slightly from the CSS test in that it tries to match the echo loss test mentioned in G.168 documentation.

To measure the delay component of voice clarity, periodic measurements are taken and then an average is calculated. Test equipment which utilizes a recorded signal, rather than a pulse to measure delay, is the primary method used. For this test, a signal that contains many different properties of speech is delivered in a single recording. The recorded .wav file analysis method is also used for measuring delay. This test is performed by simultaneously playing a digital recording (pulse followed by speech) into the path, recording the listening path on both ends of the connection and analyzing the recordings using a software program.

Other factors that can influence voice quality which are considered during voice quality evaluation are:

Packetization rates

Jitter Buffer

Codecs

Voice packet loss

Voice packet jitter

2.1.7Internal Field Trial of the iMerge Solution

The last phase of iMerge Solution testing involves subjecting the iMerge Solution and associated CPE to a real-life environment where “live” end users (company employees) actually use the CPE devices as their everyday business phones.

In the case of analog IP phones and ISDN IP phones, the users’ usual desk phone is replaced by one of these devices. The IP phone is connected to an iMerge and then to the Centrex switch which provides their telephone services. For analog and ISDN access gateways, the normal desk phone will be routed to the gateway and then to the iMerge, which is connected to the Centrex switch. For both the IP phone and the access gateway application, the user will continue to use the same telephone features he/she has used up to the point of converting to the new connection.

Softphones are handled in a very similar manner. Employees are provided the software and hardware, where applicable, and they utilize the device in a direct LAN hook-up or in a remote dial-up environment. For remote dial-up applications, the user/employee is provided connection to the building modem pool, which provides access to the iMerge and the company Centrex switching system, thereby providing them with the same telephone services they would have while working in their office. This is the iMerge Roadwarrior/Teleworker application. The Centrex switch used in the Internal Field Trial is a live switch connected to the PSTN that has all of the characteristics of a switching system used in live customer environments.

During the trial period, the end users are canvassed to provide information regarding performance and satisfaction level. In addition to obtaining valuable feedback from real users, very important information regarding application guidelines (i.e., how to configure the device in a non-lab network) is obtained. The internal trial is a very important part of the testing. It provides the confidence that each CPE device and the features associated with that device can operate in a real-world environment.

2.1.8Conclusion

By subjecting the iMerge Solution and associated CPE to the comprehensive battery of testing discussed, a robust solution can be demonstrated to a carrier whose customers have high expectations of reliability and quality for their communication systems. Many IP telephony systems have not met those expectations – they have been plagued by poor reliability, limited functionality, and disappointing audio quality. Carriers are looking beyond the hype attached to voice over Internet protocol and are holding the performance of these products to the same standards as traditional systems. A testing regimen as previously described provides assurances that the iMerge Solution offers high reliability and quality of service.

3EVALUATING NETWORK QoS

This is an excerpt out of an article fromCommunications Convergence

“Measuring VoIP Voice Quality, Part 2”.

“Nothing can destroy VoIP quality more quickly than a degraded network. The two primary degradation components that conspire to undo quality from even the best of VoIP gateways are packet loss and latency. Packet loss occurs on congested networks and can cause reconstructed speech to sound choppy and distorted. The more latency, or delay, on your network, the more difficult it is to conduct a real-time conversation. Even in the absence of packet loss on such a circuit, humans start to get annoyed when more than about 250 ms of delay exists, usually turning a call into a "I talk, then you talk" half-duplex affair.

“Other network impairments, including jitter, can also affect voice quality. Jitter occurs when packets are received at uneven time intervals, even though they were sent at equal intervals. Gateways compensate for this by accumulating the received packets into an internal buffer and "playing them out" at the proper time intervals and in packet order. The more jitter, the greater latency of the call, since the gateways have to build deeper buffers. So, before deploying a VoIP network, you must qualify the network segments that VoIP calls will ride.”[1]

Because Lucent is in agreement with this article we have created several documents that are focused on design guidelines for the carriers network and the enterprise network.

4WAN Evaluation and Design Guidelines

4.1Introduction

With the addition of Voice over IP traffic, Service Providers need to evaluate their existing or new data infrastructure to determine if they meet the requirements for the IP Telephony solution. On existing data network infrastructure, additional bandwidth, consistent performance, and higher availability may all be required. For new data network infrastructure, the equipment needed to support the required bandwidth, performance and availability must be determined. This section describes general guidelines and issues for both new and existing WAN infrastructures for an IP Telephony solution.

4.2WAN Evaluation Criteria

4.2.1Introduction

Before deployment, an evaluation must be made of current voice and data infrastructure in terms of:

Existing telecom infrastructure

Performance requirements

Availability requirements

Potential network capacity

An analysis of the above items will help in gaining an understanding of the data networking needs to support IP Telephony and basic network availability, performance, and feature requirements.

4.2.2Existing Telecom Infrastructure

The existing telecom infrastructure and level of voice traffic between the Local Digital Switch (LDS) and Remote Digital Terminal (RDT) needs to be identified. In addition, the current peak traffic load and the calling types between the LDS and RDT need to be identified. Finally, the number and types of IP phones also need to be identified. This information along with the call traffic patterns can be used to determine the expected traffic through the system. This analysis is identical to the analysis needed for any GR303 RDT.

An analysis should also be made of the existing or proposed Centrex business group. In particular the following items should be analyzed: