Nortel 9110 User manual

Remote Gateway 9100 Series Network Engineering Guidelines
Product Release 1.6 Standard 1.6 June 2005
555-8421-103
Copyright © 2000–2005 Nortel. All Rights Reserved.
Printed in Canada.
All information contained in this document is subject to change without notice. Nortel reserves the
right to make changes to equipment design or program components, as progress in engineering,
manufacturing methods, or other circumstances may warrant.
*Nortel, the Nortel logo, the Globemark, Unified Networks, Meridian 1 PBX, Communication Server
1000 (CS 1000), and Communication Server 2100 (CS 2100) are trademarks of Nortel.

2 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005

Remote Gateway 9100 Series Network Engineering Guidelines 3
Standard 1.6 June 2005
Contents
In this document
About this document 4
Introduction to packetized voice 5
The E-model to measure audio quality and user satisfaction 7
Compressed audio quality under ideal conditions 8
Compressed audio quality under packet loss conditions 11
Evaluating your network 13
Bandwidth usage table 26
Quality of service issues 28
Ordering ISDN lines 35

4 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
About this document
The Remote Gateway 9100 Series Network Engineering Guidelines
(NTP 555-8421-103) is written for individuals who are responsible for the
installation, configuration, and day-to-day management of the Remote Gateway
9100 Series units and the Reach Line Card (RLC).
This document describes the network engineering guidelines for the Remote
Gateway 9150 unit, Remote Gateway 911x series unit (9110 and 9115), Digital
Telephone IP Adapter unit (internal and external), and the RLC.
This document provides:
a clearer understanding of how you should plan your network
a detailed description of Nortel's patented QoS Transitioning Technology
instructions on how to order ISDN lines
Terminology
Throughout this document, the term “host PBX” refers to the following Nortel
PBXs:
Meridian 1 PBX
Communication Server 1000 (CS 1000)
Communication Server 2100 (CS 2100)
Unless otherwise specified, the term “Remote Gateway 9100 Series units” refers
to the following products:
Remote Gateway 9110 unit
Remote Gateway 9115 unit
Remote Gateway 9150 unit
Digital Telephone IP Adapter unit (Internal and External)
The product name “Remote Gateway 9100 Series” refers to all of the “Remote
Gateway 9100 Series units” as well as the RLC.

Remote Gateway 9100 Series Network Engineering Guidelines 5
Standard 1.6 June 2005
Introduction to packetized voice
The Public Switched Telephone Network (PSTN) has evolved into a stable, high
quality communications medium. When you take a telephone off-hook, dial tone
is immediate. Connection time is quite fast and clarity of the audio is excellent.
With the development of packetized communications such as Voice over
Internet Protocol (VoIP), the same high quality experience can be realized -
when engineered properly.
To correctly engineer a VoIP system, you must use subjective testing results
performed by numerous companies and independent labs to understand the
factors that affect the quality of the VoIP. The main factors are categorized as
follows:
audio levels
The PSTN has been built around clear rules of Loss Level Planning – the
level of transmitted and received audio. The audio levels are such that the
conversation is comfortable and highly intelligible. You can converse
without having to strain to hear the caller.
extra audio (echo, clicks, pops)
Extra audio can be created in many ways. The most common extra audio is
echo, or a reflection of your own speech. In traditional PSTN telephony,
echo is present, but the Loss Level Planning reduces the amplitude, and the
small amount of echo delay makes it unperceivable. With VoIP systems, the
inherent audio processing and network delays can make the echo
perceivable, if the echo is not cancelled/managed properly.
Clicks and pops can be heard when packet loss is occurring on the network.
The severity of the click or pop is determined by the size and duration of
the packet loss experienced, as well as the audio compression and
decompression scheme (Codec) chosen. A Codec compresses audio,
reducing the amount of bandwidth required to have a conversation.
— G.711 (64 Kbps data rate - equivalent to a wired telephone [no
compression])
— G.726 (32 Kbps data rate - reduces the required bandwidth by one half
in trade for a slightly lower audio fidelity)
— G.729A (8 Kbps data rate - high level of compression in trade for lower
audio fidelity)

6 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
missing audio (drop-outs, reduced fidelity)
Missing audio is often a result of packet loss on the network. Reduced
audio fidelity is a subjective factor that varies greatly by system user. The
G.711 and G.726 Codecs provides wire line quality when the network
conditions are ideal. Packet loss with high compression Codecs such as
G.729A lead to an even lower audio fidelity.
conversational delay
When speaking to a person face to face, your speech audio is transmitted
and received instantaneously. You also have the added benefit of being able
to see the other person, and therefore can use body language, expressions
and gestures to assist in the communication. With telephony, it is the tone,
phrasing and timing of speech that is transmitted. VoIP systems can affect
the fidelity of the audio but the greatest impact can be in the area of
conversational delay. For example, assuming that you are speaking, your
audio must be compressed, packetized, transmitted across a network,
decompressed and transmitted to the final destination. These processes all
take a small measurable amount of time. If the delay is too great, the
conversation can be awkward, with each talker speaking over one another.
trans/dual encoding
Transcoding is a term used when audio is processed through one Codec,
decompressed then passed through another Codec. Each time the audio is
compressed (G.726 or G.729A), the audio fidelity reduces.
With these factors in mind and the industry subjective testing results as a
reference, you can engineer a high quality VoIP system. One of the best
references available to “rate” the quality and factors that impair VoIP systems is
the International Telephony Union G.107 Recommendations (ITU-G.107). This
document and the subsequent G.108 and G.113 documents have been developed
by industry leaders, including Nortel.
Many of the ITU recommendations have been “rolled” into the TIA TSB116
document that clearly outlines the methods of engineering an excellent
packetized voice system.

Remote Gateway 9100 Series Network Engineering Guidelines 7
Standard 1.6 June 2005
The E-model to measure audio quality and
user satisfaction
The ITU developed what is called the E-model. The E-model uses the factors
described in “Introduction to packetized voice” on page 5 to derive a quality
value corresponding to the quality experienced by the VoIP system users.
The following graph shows the E-model rating, R value, versus the traditional
Mean Opinion Score (MOS) values.

8 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
Compressed audio quality under ideal
conditions
The following graph shows the Remote Gateway 9100 Series Codecs graphed
against the R value and conversational delay.
Note: T is one-way delay in milliseconds (ms).
To fully use this graph, you must know the Remote Gateway 9100 Series
inherent delay values. The critical values are as follows:
Codec
Encoding/
Decoding
BRI
Serialization
911x V.32
Serialization
G.711 - 64 Kbps 30 ms 25 ms -
G.726 - 32 Kbps 30 ms 12 ms -
G.729A - 8 Kbps 35 ms 10 ms 90 ms
Remote Gateway 9100 Series Codecs - No Impair ments
50
60
70
80
90
100
0 100 200 300 400 500
T
R
G.711
G.726
G.729A
Exceptional
limiting case
Very
satisfactory
Satisfactory
Some users
dissatisfied
Many users
dissatisfied
User Satisfaction

Remote Gateway 9100 Series Network Engineering Guidelines 9
Standard 1.6 June 2005
There are additional delays experienced that are a function of the customer
network:
end-to-end delay
The time it takes to pass an Internet Protocol (IP) packet from the RLC to
the Remote Gateway 9150 unit (or the opposite direction)
jitter buffer depth
If the network has low jitter, the jitter buffer can be reduced. The
configurable values in the Remote Gateway 9100 Series product are 30, 60,
or 90 ms.
Conversational delay calculation examples
Remote Gateway 9100 Series units over IP
When using the Remote Gateway 9100 Series units over IP, the controllable
delay factors are the jitter buffer and the network delay. For example, assuming
you are using G.711 with a 60 ms jitter buffer:
30 ms (G.711 encoding/decoding) + 20 ms (one-way network delay) + 60 ms
(jitter buffer) = 110 ms one-way delay
Remote Gateway 9150 unit over PSTN
In the following example, the RLC and Remote Gateway 9150 unit is
configured to use G.729A to reduce bandwidth requirements:
35 ms (G.729A encoding/decoding) + 10 ms (serialization delay) + 60 ms (jitter
buffer) = 105 ms one-way delay
Remote Gateway 911x series unit over PSTN
The Remote Gateway 911x series unit uses a V.32 modem emulation to provide
connectivity over the PSTN. In this configuration, you must use G.729A.
35 ms (G.729A encoding/decoding) + 90 ms (serialization delay) + 60 ms (jitter
buffer) = 185 ms one-way delay

10 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
Remote Gateway 9150 unit to Remote Gateway 9150 unit
When a customer environment uses multiple Remote Gateway 9150 units, the
audio must be treated by each individual Remote Gateway 9150 unit. Therefore,
the delay each Remote Gateway 9150 unit experiences is added together. For
example, assuming one Remote Gateway 9150 unit over IP (G.711)
communicating to another Remote Gateway 9150 unit over BRI (G.729A):
30 ms (G.711 encoding/decoding) + 20 ms (one-way network delay) + 60 ms
(jitter buffer) + 35 ms (G.729A encoding/decoding) + 10 ms (serialization delay)
+ 60 ms (jitter buffer) = 215 ms one-way delay
Notes:
1. Since the audio has been compressed by the G.729A Codec, each user
experiences the quality provided by the G.729A Codec.
2. When calls are made from Remote Gateway 9150 unit to Remote Gateway
9150 unit as described, it is possible that the Echo Cancellers in the Remote
Gateway 9100 Series product can cause periods of audio clipping when the
conversational delay is large. To minimize this possibility, you must
manage network delay and jitter so that the jitter buffer depth can be
reduced as much as possible.
As you have calculated, when using IP connectivity, the network performance
can affect the jitter buffer depth and network delay, thus increasing the
conversational delay. The network can also have periods of high jitter or packet
loss that can greatly affect the audio quality.

Remote Gateway 9100 Series Network Engineering Guidelines 11
Standard 1.6 June 2005
Compressed audio quality under packet loss
conditions
The following graph shows the effect of random packet loss on the Remote
Gateway 9100 Series G.711 Codecs.
Note: T is one-way delay in ms.
G.711 w ith Random Packet Los s
50
60
70
80
90
100
0 100 200 300 400 500
T
R
0
0.01
0.02
0.03
0.04
0.05
Exceptional
limiting case
Very
satisfactory
Satisfactory
Some users
dissatisf ied
Many users
dissatisfied
User Satisfaction

12 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
The following graph shows the effect of random packet loss on the Remote
Gateway 9100 Series G.729A Codecs.
Note: T is one-way delay in ms.
G.729A w ith Random Packet Los s
50
60
70
80
90
100
0 100 200 300 400 500
T
R
G.711
0%
1%
2%
3%
4%
5%
Exceptional
limiting case
Very
satisfactory
Satisfactory
Some users
dissatisfied
Many users
dissatisfied
Us er Satisfaction

Remote Gateway 9100 Series Network Engineering Guidelines 13
Standard 1.6 June 2005
Evaluating your network
Now that you fully understand the effects of packet loss, jitter, and delay on the
audio quality that can be experienced on packetized voice equipment, the next
step is to ensure that the network is capable and configured to support
packetized voice.
A network is a dynamic entity – the characteristics change daily, hourly, by the
second as various applications push and pull data across it. The method of
evaluation best suited for packetized voice is testing with pseudo voice traffic
for extended periods of time.
There are numerous Personal Computer (PC) based software tools available that
generate a configured number of calls, using a specific Codec, for a configured
duration. The tool then provides various reports showing the jitter, packet loss,
and the equivalent audio quality (MOS or R-value). You can and should use this
tool before installing the VoIP equipment. You should run tests for an extended
period of time.
To ensure success, network evaluation is a critical step in engineering a VoIP
solution. Do not skip this critical step, as it is the foundation for the projects
success.
Nortel can provide network evaluation services, either directly or through our
business partners.
Network engineering for real time traffic
Packetized voice, or VoIP, is a form of real time traffic where delays and
retransmission cannot be tolerated. Typical PC and server traffic is non-real time
and, therefore, can tolerate a certain level of delay and retransmission. To ensure
that the VoIP traffic receives the most expedited treatment possible, there are a
number of techniques that you can use.
Let's look at the various techniques starting at the VoIP devices themselves and
working out into the Local Area Network (LAN) or Wide Area Network
(WAN).

14 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
LAN access points
The RLC and Remote Gateway 9100 Series units all have Ethernet interfaces
that you can use for VoIP connectivity. Use the following table to locate
connectivity options at the device level:
It is common that the Remote Gateway 9100 Series product is directly plugged
into a hub or a switch as shown in the following illustration:
Consideration 1
When using a hub, the shared media causes all other hub traffic to be presented
to the Remote Gateway 9100 Series device also. The Remote Gateway 9100
Series product reports this traffic as multicast packets – packets that were not
specifically addressed for the Remote Gateway 9100 Series product itself. Since
the Remote Gateway 9100 Series product must read the packet to determine that
it should be ignored, a high level of multicast packets can be disruptive to real
time traffic. Keep the multicast traffic to less than five percent of the segment
traffic.
Product Capability Minimum Revisions
RLC 10 M half or full-duplex 1.3.5 firmware for full-
duplex
Remote Gateway 9150
unit
10 M half or full-duplex 1.4.0 hardware and
firmware for full-duplex
Remote Gateway 911x
series units and Digital
Telephone IP Adapter
units
10 M half-duplex 1.3.1 firmware

Remote Gateway 9100 Series Network Engineering Guidelines 15
Standard 1.6 June 2005
Recommendation 1
A switch manages the traffic so only packets addressed for the Remote Gateway
9100 Series product are transmitted to the Remote Gateway 9100 Series product.
Nortel recommends that you connect the Remote Gateway 9100 Series product
to a data switch as shown in the following illustration:
Consideration 2
When the VoIP traffic is passed to the switch, the switch forwards the packet at
essentially wire line speed. When multiple devices receive multiple packets,
with the destination being on the uplink side of the switch, the switch must
temporarily buffer the packets as it manages the uplink media. Low end switches
do not provide a mechanism to manage the buffer process. Therefore, real time
traffic can experience a small amount of jitter due to buffering.
Recommendation 2
The Remote Gateway 9100 Series products support a prioritization methodology
called 802.1Q tagging. When the feature is enabled in the Remote Gateway
9100 Series products, the Ethernet Media Access Control (MAC) frame is
“tagged” with three bits that define the priority of the packet. When using a data
switch that is 802.1Q aware, the tagged data receives the appropriate priority
over low priority or untagged packets. The Remote Gateway 9100 Series
products set the 802.1Q code point to a hex value of C000. The following
illustration shows aggregation point uplink prioritization:

16 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
Consideration 3
The uplink for the switch or hub is connected to either another switch or a router.
If it is an additional switch, recommendation 2 still applies, as well as using
802.1Q Virtual Local Area Network (VLAN) techniques to keep the real time
traffic prioritized at the Layer 2 level.
If you use a router as the uplink device, there are a number or prioritization
methods that can be used. Remember that even though prioritizing the traffic in
all directions is beneficial, the critical direction is when data is aggregated from
high speed links to a slow speed link.
There are three critical steps in managing real time traffic through a router, as
follows:
1. Recognizing that the traffic requires prioritization
2. Placing the traffic in the appropriate queues
3. Passing the traffic onto the next segment in a prioritized manner
Recommendation 3
The Remote Gateway 9100 Series products have the capability of marking IP
packets with a Differentiated Services (DiffServ) CodePoint. A router that is
aware of the DiffServ prioritization levels places the Remote Gateway 9100
Series traffic in the highest priority queue.
If DiffServ cannot be used to identify the real time traffic, the source,
destination, or port in the IP packet can be used to identify the Remote Gateway
9100 Series traffic. UDP port 0x5000 (20480) is used for voice traffic. UPD port
0x5002 (20482) is used to test during QoS Transition. TCP port 0x3200 (12800)
is used for the Remote Gateway 9100 Series product and telephone signaling.
Note: All packets are tagged with the DiffServ CodePoint you configure in
Remote Gateway 9100 Series Configuration Manager on the IP Configuration
property sheet for your specific unit. Refer to your Remote Gateway 9100 Series
unit’s Installation and Administration Guide for further details.

Remote Gateway 9100 Series Network Engineering Guidelines 17
Standard 1.6 June 2005
There are multiple methods of creating queues in a router, each with different
depths, prioritizations, and so on. The queue that the voice traffic is placed in
must be deep enough to ensure that packets are not lost due to the queue being
full, but not too deep to cause excessive packet delay. Most router venders
follow the well known standards. Configuration of these techniques, however,
could vary greatly. Consult your equipment vendor for the exact configurations.
Routers can be provisioned to honor 802.1Q markings, and also honor or mark
the packets DiffServ setting at layer 3.
Understanding queuing techniques
Slower WAN links can add inherent delay to voice packet transversal. Often,
these types of links have voice and data converged, competing for the same
bandwidth availability. How this converged link affects voice quality is
completely dependant on the WAN link speed and encapsulation protocol.
Queuing techniques help to provide the most efficient method for guaranteeing
VoIP delivery while sharing the bandwidth with other data traffic.
Recommendation 4
For WAN serial links 768 Kbps or less, Nortel recommends that you use the
following packet fragmentation and queuing techniques:

18 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
Recommendation Definition
packet fragmentation Fragmentation helps prevent a smaller VoIP packet
from being delayed behind a large data packet.
Fragmentation must be enabled on both ends of the
serial link. Depending on link speed, serialization
delay of a large, 1500 byte packet can cause a
smaller, 160 byte voice packet to exceed the end-
to-end budget delay of 150 ms. Fragmentation
breaks up the train of packets into evenly sized
packets. It is important not to fragment the VoIP
packets, only the competing data packets. Method
of fragmentation can vary, depending on the WAN
protocol. Frame Relay, as an example, can make
use of the FRF.12 standard and fragment at layer 2.
Point-to-Point Protocol (PPP) also has the ability to
fragment at layer 2. High-Level Data Link Control
(HDLC) links, however, can only be fragmented at
the IP layer, layer 3 by setting a maximum
Maximum Transmission Unit (MTU) size. Nortel
does not recommend this method due to the added
processing requirements, and unreliable results.
Note: Some Web applications can mark the packet
as “do not fragment”.
interleaving Interleaving is a technique to mix the VoIP packets
into a stream of data traffic. As an example, a large
file download can have multiple packets required to
complete the session. Fragmentation breaks up the
large packets into regular sized packets, while
interleaving inter-weaves VoIP packets with the
data packets.

Remote Gateway 9100 Series Network Engineering Guidelines 19
Standard 1.6 June 2005
queuing techniques Queuing techniques help to isolate priority traffic,
such as VoIP, from the normal data traffic. By
placing the priority voice traffic into a separate
queue, or holding bucket, this type of traffic can be
given special treatment. As an example, the priority
traffic can be given dedicated bandwidth when the
link is congested. This helps ensure a timely
delivery of the VoIP packets. The different queuing
methods are as follows:
Priority Queuing (PQ) This is the legacy method of queuing to guarantee a
certain amount of available bandwidth. This
method has some inherent problems. As an
example, PQ can be very Central Processing Unit
(CPU) intensive, and starve other traffic types of
bandwidth. As long as the PQ queue is full, it does
not service the other queues. Today, PQ is
incorporated into more advance queuing methods
such as CBWFQ and LLQ. Refer to page 20 for
further details on CBWFQ and LLQ.
Customer Queuing (CQ) Developed to solve the PQ problems of bandwidth
starvation for the non-priority traffic. This method
uses a “round-robin” method to service the
difference queues.
Weighted Fair Queuing
(WFQ)
This is the most common default method of
queuing for interfaces 2 Mbps or less. WFQ
attempts to share the available bandwidth equally
for all applications by identifying the different
conversations. The “weighted” part of WFQ takes
note of the DiffServ CodePoint at layer 3 to give
priority treatment. Today, this method is combined
with the other queuing techniques (PQ and CQ) to
provide more queuing options.

20 Remote Gateway 9100 Series Network Engineering Guidelines
Standard 1.6 June 2005
The following illustration shows high speed to low speed aggregation:
Consideration 5
The real time traffic is now in the appropriate queue waiting to be passed onto
the next segment. The timeliness of the delivery is important. Therefore, you
must review multiple considerations.
Class Based Weighted
Fair Queuing (CBWFQ)
This technique makes use of the WFQ method of
queuing and adds the ability to separate traffic into
different classes. The classes allow for more
flexibility for controlling traffic on a network. It
does not use the “guaranteed bandwidth” PQ
method, but does allow you to set aside a particular
amount of bandwidth for VoIP traffic. It also allows
you to configure different queuing methods for
other types of traffic, such as Web traffic.
Low Latency Queuing
(LLQ)
Known as PQ/CBWFQ, this technique adds the PQ
to CBWFQ by allowing you to guarantee a certain
amount of bandwidth for priority traffic, such as
Vo I P.