Mitel SX 200 IP NODE Instructions Guide

							1
 LAN Design Guidelines for the Implementation of SX-200 IP NODE
This Technical Bulletin is intended for Customer Service and Installation personnel involved in the installation of Mitel
Networks SX-200 IP NODE.
Issued January, 2003
NOTICE
The information contained in this document is believed to be accurate in all respects but is not warranted by Mitel
Networks Corporation (Mitel).  The information is subject to change without notice and should not be construed in any way
as a commitment by Mitel or any of its affiliates or subsidiaries. Mitel and its affiliates and subsidiaries assume no
responsibility for any errors or omissions in this document.  Revisions of this document or new editions of it may be issued
to incorporate changes.
™, ® - Trademark of Mitel Networks Corporation
© Copyright 2002, Mitel Networks Corporation
May 2002 
						

							2
1. NETWORK GUIDELINES FOR VOICE OVER IP INSTALLATIONS .......................................................................... 3
1.1 EXECUTIVE SUMMARY............................................................................................................................................ 3
2. SUMMARY OF GUIDELINES ...................................................................................................................................... 
3
3. GUIDELINES AND EXPLANATIONS .......................................................................................................................... 4
3.1 INTRODUCTION...................................................................................................................................................... 4
3.2 TERMINOLOGY EXPLANATIONS...............................................................................................................................4
3.2.1 Delay ........................................................................................................................................................... 4
3.2.2 Echo ............................................................................................................................................................ 4
3.2.3 Jitter ............................................................................................................................................................ 4
3.2.4 Packet Loss ................................................................................................................................................ 4
3.2.5 Available Bandwidth ................................................................................................................................... 5
3.2.6 Packet Priority Mechanisms........................................................................................................................ 5
3.2.7 WAN Connections ...................................................................................................................................... 5
3.2.8 Transcoding and Compression ................................................................................................................... 5
3.2.9 Hubs Versus Switched ................................................................................................................................ 5
3.2.10 LAN Architecture ......................................................................................................................................... 6
MAINTAINING VOICE QUALITY OF SERVICE ................................................................................................................... 6
3.3 NETWORK MEASUREMENT CRITERIA...................................................................................................................... 6
3.4 BANDWIDTH REQUIREMENTS.................................................................................................................................. 6
3.5 CODEC SELECTION.............................................................................................................................................. 7
3.6 AVAILABLE BANDWIDTH.......................................................................................................................................... 8
3.6.1 LAN ............................................................................................................................................................. 8
3.6.2 WAN............................................................................................................................................................ 8
3.7 S
ERIALISATION DELAY........................................................................................................................................... 9
3.8 NETWORK PRIORITY............................................................................................................................................ 10
3.8.1 LAN Layer 2 Priority .................................................................................................................................. 10
3.8.2 WAN Layer 3 Priority ................................................................................................................................ 12
3.8.3 Network Topology with Priority ................................................................................................................. 13
3.8.4 Use of Subnets ......................................................................................................................................... 14
4. MAINTAINING AVAILABILITY OF CONNECTIONS................................................................................................. 
15
4.1 SYSTEM CAPABILITIES......................................................................................................................................... 15
4.2 TRAFFIC.............................................................................................................................................................. 15
4.2.1 WAN traffic worked example..................................................................................................................... 15
4.3 IP T
RUNKING LIMITS............................................................................................................................................. 16
4.3.1 IP Trunk Limit working example ................................................................................................................ 17
5. GETTING STARTED .................................................................................................................................................. 
19
5.1 START-UP SEQUENCE FOR PHONES: ..................................................................................................................... 19
5.2 START-UP SEQUENCE FOR THE CONTROLLER....................................................................................................... 19
5.3 DHCP OPTIONS.................................................................................................................................................. 19
5.4 DHCP LEASE TIME.............................................................................................................................................. 20 
						

							3
1.  Network Guidelines for Voice over IP Installations
The following information is to be used in determining the suitability and requirements for a Voice over IP installation. The
MITEL Networks SX-200 IP NODE will be used to illustrate some of these areas.
The contents of this document should be used in assessing the capabilities of a particular network with respect to
maintaining voice quality and usability of the IP-Phones and associated controllers.
Networks by definition do not always follow specific architectures, so whilst every effort is made to give accurate
information, requirements may differ between different installations. As a result the information enclosed is typically
generic in nature. Specific information on how the configure the MITEL Networks SX 200 IP NODE and network
equipment should be referred back to manuals and relevant training on those devices.
1.1 Executive Summary
The main requirement in assessing and configuring the network is maintaining the voice quality and functionality to the
user. This may require that certain changes take place within an existing network, or that equipment with certain
capabilities is installed.
The main issues that affect the voice quality within a network are:
• Network Delay
• Network Jitter
• Network Packet Loss
Care has been taken in the design of the IP-Phones and controllers to cater for delay through the inclusion of echo
cancellation devices. The jitter and a certain degree of packet loss are also taken care of by the inclusion of jitter buffers
and the mechanism to control these.
In implementing a network to handle Voice over IP the following areas need to be considered. These are
recommendations, and there will always be exceptions, but these should be considered:
• QoS (Quality of Service) Quality of service is that provided to the user, not network equipment settings. However,
certain network equipment configurations can greatly assist in ensuring adequate QoS to a user. These include:
• IEEE802.1p/Q: This may also be known as VLAN Tagging, priority or COS (different from the telecom Class of
Service). This operates at layer2 to ensure highest priority for voice traffic.
• DiffServ: This is a fixed field in the Layer3 information that is also used to define different service categories,
through TOS, priority and Precedence. DiffServ and Type of Service are similar, with the older Type of Service
values being backward compatible into DiffServ.
• Switched Networks: Use switched networks, which then allow full bandwidth capability to all end points. Networks
with Hubs include shared bandwidth and no priority mechanisms are available, see above.
• Network Topology: The networks should be designed in a hierarchical manner where bandwidth between devices is
controlled and understood. Simply linking switches in a long chain will work for data, but this also introduces
bottlenecks between devices that are unnecessary, as well as introduction of jitter.
• Network Pre-Installation and post-installation analysis: The network should be investigated before installation to
determine suitability for Voice over IP. The following sections of the document will provide guidelines of areas to
investigate. Once an installation is completed, it should also be tested to ensure that the guideline limits are not
being exceeded.
• NAT and Firewall: Although there are emerging standards to allow Voice over IP through firewalls and NAT devices,
these are still in early development. Typically to allow voice through a firewall a number of ports need to be opened
up, since one controller may use a range of ports that are dynamically assigned. Opening up all possible ports
negates the usefulness of the firewall. NAT needs to change addresses, but may have difficulty in mapping a single
controller device to multiple Internet addresses, or translating IP addresses that are buried in control messages.
Generally these issues are overcome through the use of VPNs.
• VPN: Virtual Private Networks are simply a pipe or tunnel across an ISP network which allows a remote device to
react as though it was still connected to the enterprise network. Beware that the VPN may be across an unknown
network. It may be required to get certain Service Level Agreements (SLA) to ensure timely delivery of data. Where
encryption is used additional delay may also be added to the data.
2.  Summary of Guidelines
In brief, the guidelines are exactly that: guidelines. Because LANs are so diverse and equipment changes so quickly the
following recommendations are listed below to provide the best operating conditions.
•  Use networks with VLANs (IEEE802.1p/Q) with dual port phones
•  The network should be fully switched. Hubs do not support priority queuing.
•  The ports must allow for the interface speed to be configured either manually or automatically.
•  Routers or Layer3 switches must be available to connect between VLANs
•  Spanning Tree should be disabled at the IP NODE connection, or set to ‘PortFast’ to inhibit test disconnection 
						

							4
•  Only one LAN connection should be made from the ICP controller to the network
•  The IP NODE should be located behind a network Layer2 switch
•  Ensure that the PPS rate of the routers and switches is adequate for the amount of voice traffic expected
•  Wherever possible, provide the most bandwidth. Use Full duplex in preference to Half duplex.
•  If the network consists of multivendor units, do they all inter-work correctly?
•  Use MTU on routers especially for slower speed links (anything less than T1 rates)
•  Ensure that end-to-end delay, jitter and packet loss are within acceptable bounds
•  Ensure that there is sufficient bandwidth on a WAN link for the amount of expected traffic. Don’t overload, otherwise
everyone suffers
•  Provide a realistic blocking number for IP Trunking restriction, i.e. consider bandwidth
•  Don’t share the voice VLAN with data devices
•  Don’t put servers or printers behind a dual port phone, provide a dedicated port for these devices.
•  Ensure Routers support DHCP forwarding, or provide multiple DHCP servers and copy phone specific information
between DHCP servers to ensure phones start up correctly.
•  Ensure Routers support ‘ICMP Redirect’. This reduces bandwidth requirements when the ‘default gateway’ device is
not the correct one to direct traffic to.
•  To get the maximum data rate from phone, connect a 100BaseT NIC on the PC to the phone and ensure that it is
configured for ‘auto-negotiation’. The phone will default to the slowest speed for both ports. The faster, the better!
•  Ensure CAT5 or better cabling is installed to get best performance. CAT3 does work, but only up to 10BaseT. CAT6
may be needed for patch cables if a number of patch panels are used in a wiring run.
3.  Guidelines and Explanations
3.1 Introduction
The main issues that affect system installation and user perceptions are:
•  Quality of service: Voice quality during the call., and
•  Availability of the service: Setting up and Clearing voice connections (signalling).
The challenge is to engineer the network to ensure that these quality requirements are met. In the TDM world, this is
possible by providing dedicated connections to the desk. In the IP world the network has to share connections with other
devices, such as PCs. The requirements of the PC and an IP-Phone differ, and this is where the challenge starts. The PC
requirement is to send data as quickly as possibly using all available bandwidth. The IP-Phone on the other hand has
limited data, but it must be sent and received on a very regular basis with little variation (jitter).
In summary this can be considered as placing connection oriented devices into a connectionless environment and still
maintaining expected operation.
3.2 Terminology Explanations
Some areas that affect the installation are described below with a brief explanation of their importance:
3.2.1 Delay
As delay increases in a conversation it becomes increasingly difficult to hold a normal two-way conversation. Such a
conversation rapidly changes from an interactive conversation to an ‘over to you’ radio conversation. This starts to
become apparent at about 150ms to 200ms, and is definitely apparent by 400ms delay. The phones and gateway, in the
controller, introduce some necessary delay. The guidelines identify the delays that can be tolerated to ensure that
conversation voice quality is maintained.
3.2.2 Echo
Echo generally results from poor termination of a PSTN line or acoustic feedback. When delay is short, this is usually not
heard due to the level of local side-tone. But, as delay is introduced, this echo becomes noticeable. To counteract this, the
gateway device includes echo cancellation up to 64ms looking towards the PSTN. The IP-Phone includes echo-
suppression to remove acoustic echo.
3.2.3 Jitter
This is the variation in delay that can occur in networks. The major source is generally due to serialisation delay. This
occurs when a packet cannot be sent at the ideal time because another packet is already being sent on the same
connection. The result is that the packet must wait. For high-speed links a maximum packet of about 1500 bytes will be
sent in microseconds, so jitter is negligible. However for slower WAN connections, such as over a Frame Relay
connection, this delay becomes significant.
3.2.4 Packet Loss
Packet loss within the network can occur for a number of reasons. The main ones include congestion of a connection. At
some point the buffers overflow and data is lost. Packets may also be lost at the gateway or IP-Phone device because the
jitter is so variable that the packet arrives too late to be used for voice. Out of sequence packets can also occur over WAN
connections. These look like packets with excessive jitter and hence result in packet loss. 
						

							5
Although some packet loss can be handled on an ongoing basis, if the loss becomes bursty the user will start to notice.
Thus a network with 0.1% packet loss over time will sound a lot different to one that encounters a burst loss or 3 or more
packets, but still at 0.1% loss
3.2.5 Available Bandwidth
If a connection is rated at a particular bandwidth, this does not necessarily mean that all of this bandwidth is available.
Connections between LAN and WAN network devices include a certain amount of overhead for inter-device traffic
including inter-device and general broadcast traffic. A collision in a shared network and guard time between packets also
reduces the available time in which data can be sent. This is a result of the fact that the data is asynchronous to the
connection. In the TDM world this is taken care of through strategies such as framing and clock synchronisation. So, the
available bandwidth is always less than the connection bandwidth.
3.2.6  Packet Priority Mechanisms
In a network oriented towards data devices, absolute delay is not too important, but accuracy is. For voice traffic, a certain
amount of incorrect, or lost information, can be accepted, but information delivered in an untimely manner cannot be
accepted. The issue is therefore to ensure that any voice traffic gets ‘pushed’ to the front of any connection queue. If PC
type data is delayed a fraction this is less important. There are two similar mechanisms at work to help with priority. At
Layer 2, IEEE802.1p/Q can be invoked; at Layer 3 DiffServ (formerly Type of Service) can be used.
3.2.7 WAN Connections
Best Quality of Service is obtained when the customer has control of the external WAN connections. This can be achieved
by using dedicated leased lines between sites, or alternatively by ensuring a guaranteed Service Level Agreement (SLA)
from the external network provider.
When specifying a SLA it is important that the guaranteed Committed Information Rate (or similar) is specified and this
should also include a guard band. Data sent in excess of the CIR is likely to be discarded during congestion periods in
order to maintain guarantees on the SLA. It may therefore also be advantageous to split Voice traffic from normal data
traffic with different SLA.
For more dedicated links some additional protocols can be used to improve bandwidth usage. The data in an Ethernet
LAN connection includes a data layer for Ethernet and also for the IP layer. In a WAN connection, this Ethernet layer is
not needed. However, other layers are needed in order to transport the IP layer (and voice data). As a result of this,
certain WAN protocols can give bandwidth advantage, i.e. use less. These include the more dedicated links such as PPP
and Compressed PPP.
3.2.8 Transcoding and Compression
Transcoding is seen as the changing of voice information sent with one CODEC type into that from a different CODEC.
However, most CODEC devices rely on G.711 as the base entry level. Thus, transcoding could be seen as going from
G.729 to G.726, but this is likely to be via G.711. Compression is seen as simply reducing the amount of data, and in the
voice world this could be achieved by going from G.711 to G.729, for example. The terms are often used interchangeably.
Any form of voice compression works by removing a certain amount of information which it deems to be non-essential.
This may include not sending data during silence periods as well as sending only the main frequency elements of the
voice rather than the full bandwidth. The result of this is that some information will always be lost. Compressed voice will
therefore never be as good as uncompressed voice, but the main requirement is to carry the intelligibility. Of the
compression CODECs seen, G.729 has good bandwidth reduction as well as maintaining a good voice quality and
intelligibility.
In the LAN environment where bandwidth is ‘plentiful’ there is probably little reason to compress voice, and so G.711 will
normally be the CODEC of choice. In a WAN environment, where access bandwidth may be limited, use of the G.729
CODEC could increase the amount of voice traffic that can be carried on a particular link. There may be instances where
G.711 is still preferred, for voice quality, but this will limit the voice traffic of the link.
3.2.9  Hubs Versus Switched
The best network configuration is to be entirely switched. This allows full network bandwidth to be made available to the
end user and greatly reduce collisions with a resulting network utilisation decrease, i.e. making more bandwidth available
for another application, such as voice!
A Hub works by sharing bandwidth between a number of devices. They ‘fight’ each other for access. The devices that fail
to get access need to wait for an available slot. Hubs also don’t implement any form of QoS control. Where data needs to
be sent in a timely manner, there is a high probability of introducing unnecessary jitter with potential packet loss.
In a switched environment, all ports can pass data to a LAN switch. Data is passed to queues and priority can be given to
types of data, such as those marked by IEEE8021.p/Q tags. Where two devices share a common LAN switch they can
effectively pass data to each other at high speed as though they were the only devices on the network, whilst other 
						

							6
devices could equally be doing the same. Use of a switch is almost the same as having multiple networks. Network
efficiency is greatly improved, as well as network management.
Since connections in a switched network are typically point to point, there is also the possibility of configuring the
connection to be Full Duplex. This virtually doubles the bandwidth, since data can be sent and received at the same time.
In a half duplex environment data can only be sent or received sequentially. Equipment configured with ‘auto-negotiation’
will always determine the highest possible data rate and make that available on a connection by connection basis. Simple
hubs are generally ‘bottom of the shop’, fixed at 10BaseT half duplex.
3.2.10 LAN Architecture
Networks usually consist of different layers. The two main parts are the ‘core’ network and the ‘access’ network.
The ‘core’ network will potentially have data on dedicated links at 1Gbits/s or even higher. The switches at this level will
probably include some Layer2 and Layer3 switching and will agglomerate a number of sub-nets onto one, or a small
number of units. These units will almost certainly have UPS backup and will be cross-connected in redundant
configurations, such that failure of one device is unlikely to result in total network failure.
The ‘access’ network connects to the core units by single or multiple connections. It provides the slower 10/100BaseT
type of connections to the user. These may be cross-connected within geographic locations. If a device fails here, then
only the locally connected devices will fail. These units may or may not have UPS backup. This should be considered
when voice devices are connected to these access devices.
Ideally the MITEL SX-200 IP NODE should have a connection higher up in the network, located more towards the core
than at an access point. A Typical location would be within the Distribution Network or in a location that would normally be
used with a Server device.
Maintaining Voice Quality of Service
A number of areas affect voice quality of service. In the IP world these are primarily:
•  End to End Delay
•  Jitter, or delay variation
• Packet Loss
•  Due to link congestion resulting in discarded or out of sequence packets
•  Due to forced loss of packet due to excessive jitter
3.3 Network Measurement Criteria
Assuming that jitter and packet loss are taken care of, the one parameter left that affects the voice and conversation
quality is end-to-end delay. From ITU-T recommendations (and practical experience) the end-to-end delay for a voice call
should not exceed 150ms. The characteristics of the end devices such as the gateway (Ethernet and TDM bridge in the IP
NODE) and the IP-Phones are known.
So, in assessing a network the following network limits should be considered:
‘Ping’ delay is the value obtained from using a PC ‘Ping’ utility. Typically in a network, equal delays are seen on the send
and receive paths. Jitter can be estimated from using ‘Ping’ over a short and longer-term period. Packet loss can be
estimated by using ‘Ping’ over a longer period. Longer means a number of hours such as 24 hours plus.
Other tools, such as network analysers can also be used to determine packet loss. Many now look for VoIP and RTP
packets, and can identify when a packet is missing as well as average jitter.
3.4 Bandwidth Requirements
A MITEL IP-Phone is capable of providing a number of CODEC types. These currently include:
•  G.711 : Same as TDM, both A-Law and u-Law
• G.729a
Typically the G.711 CODEC provides the best voice quality and is comparable to TDM type connections. G.729a provides
a good reduction in bandwidth with only minor loss in voice quality. Typically G.711 would be used where bandwidth is
available, such as in a LAN environment, whereas G.729a would be used in a WAN access environment, where
bandwidth is not so readily available.
Packet Loss JitterEnd-to-End Delay Ping Delay

						

							7
The table, below, shows typical wire data rates for different protocols and LAN/WAN interfaces. Note, for example, that a
Half-Duplex link uses twice the bandwidth on the connection than a similar Full Duplex connection for the same voice
connections. This is because the Half-Duplex connection is shared with other devices and one transmitter must also send
data on the receive path for all other devices to hear.
From the statement some recommendations ensue:
•  Use Full Duplex wherever possible. This requires point to point connections
•  Use a switched environment, rather than hubs
As we can see from the table the physical ‘wire’ bandwidth required by the IP-Phone is typically:
• G.711: about 100kbits/s
• G.729: about 40kbits/s
¾  What is wire bandwidth? This is what you pay for.
¾  How is this different from IP (data payload) bandwidth? IP is a number of layers removed from the real connection. It
encapsulates the data with routing and address information. It is the basis on which other protocols are then added,
such as Frame Relay or Ethernet, to get the data physically moved around, i.e. each of these protocols adds its own
overhead on top of the fixed IP bandwidth. See section 3.8 Network Priority for more detail on the frame breakdown
for Ethernet. Compare IP bandwidth in the table above with the real wire bandwidth requirements.
3.5 CODEC selection
The selection of the CODEC to use on a particular connection can be dependent upon a number of issues, including:
•  Voice Quality expected by the user
•  Available bandwidth, especially on a WAN link
•  Number of devices on a link, and how many are active based on traffic, see section 4.2 below
The voice quality of the CODECs available is usually expressed in terms of a Mean Opinion Score (MOS). The scores
range in value from 0 to 5. Typically, anything above 4 is considered as acceptable speech quality. Some typical MOS
scores for the CODECs is shown in the table below:
Data Type LAN Usage at 
10Mbits/sIP Data 
PayloadVoice Data Rate (End 
toEnd)Voice streaming at 
physical connection
IP Phone (G.711) Signalling Burst 0.2% 80kbit
G.711 IP Phone 20ms     
(LAN - Half Duplex)2% 80kbits/s 64kbits/s 193.6kbits/s
G.711 IP Phone 20ms    
(LAN - Full Duplex)1% 80kbits/s 64kbits/s 96.8kbits/s
G.729 IP Phone 20ms    
(LAN - Half Duplex)0.8% 24Kbits/s 8kbits/s 81.6kbits/s
G.729 IP Phone 20ms    
(LAN - Full Duplex)0.4% 24Kbits/s 8kbits/s 40.8kbits/s
G.711 IP Phone 20ms   
(W AN - IP over FR)Dependent upon 
W AN link rate80kbits/s 64kbits/s 94kbits/s
G.729 IP Phone 20ms   
(W AN - IP over FR)Dependent upon 
W AN link rate24kbits/s 8kbits/s 38kbits/s
G.711 IP Phone 20ms   
(W AN - PPP)Dependent upon 
W AN link rate80kbits/s 64kbits/s 84kbits/s
G.729 IP Phone 20ms   
(W AN - PPP)Dependent upon 
W AN link rate24kbits/s 8kbits/s 28kbits/s
G.711 IP Phone 20ms   
(W AN - Compressed PPP)Dependent upon 
W AN link rate65.2kbits/s 64kbits/s 68kbits/s
G.729 IP Phone 20ms   
(W AN - Compressed PPP)Dependent upon 
W AN link rate9.2kbits/s 8kbits/s 12kbits/s 
						

							8
CODEC TypeMOSLAN Bandwidth
G.711 4.3 ~100kbits/sG.729 4.0 ~40kbits/s
As can be seen the G.711 CODEC gives the better speech quality, but also requires more bandwidth in order to achieve
this. For this reason it may be desirable to use the G.711 CODEC in a LAN environment, but switch to G.729 in a WAN
access connection. In the MITEL SX-200 IP NODE the switch of CODEC can be configured through The SX-200 CDE
form 23 Route Definition “Show IP” Compression Y/N’. Or in the case of a remote Set by Class of Service.
3.6 Available Bandwidth
When a link is advertised at a particular rate, this is the ‘speed’ at which the data travels. It is not necessarily the available
data rate. In practice, a percentage of this bandwidth is lost due to communication between end devices and because the
data is asynchronous and requires certain guard bands. In a synchronous telecom link these issues are taken care of
through mechanisms such as framing data into fixed time-slots.
This results in some simple guidelines for LAN and WAN links:
Data Connection TypePercentage of BandwidthAvailableExample
LAN – 10BaseT Half Duplex 40% 10Mbits/s => 4Mbits/s availableLAN – 10BaseT Full Duplex 80% 10Mbits/s => 8Mbits/s availableLAN – 100BaseT Half Duplex 40% 100Mbits/s => 40Mbits/s availableLAN – 100BaseT Full Duplex 80% 100Mbits/s => 80Mbits/s available
WAN – 1.5Mbits/s Frame Relay without
QoS mechanism in Router40% 1.5Mbits/s => 600kbits/s available
WAN – 1.5Mbits/s Frame Relay with QoS
mechanim in Router70% 1.5Mbits/s => 1.05Mbits/s available
3.6.1 LAN
This also leads to some simple guidelines for LAN connections (assuming that all the available bandwidth is used for
voice traffic only):
Cable CapacityBandwidth %Phone Usageat G.711“Voice Channels”G.711“Voice Channels”G.729 (x 2.5)
10BaseT Half 40% 2% 20 5010BaseT Full 80% 1% 80 200100BaseT Half 40% 0.2% 200 500100BaseT Full 80% 0.1% 800 2000
This is the maximum capability of a LAN link assuming that the link is used purely for voice traffic. If the link is shared with
other devices, such as PCs, then some priority mechanism will be needed to ensure that the voice gets the available
bandwidth when needed. Also, in a busy network with multiple broadcasts the available bandwidth will reduce by this
percentage. For example, in a network with 10% broadcast traffic (at 10Mbits/s) the 40% available bandwidth will reduce
to 30% for a half-duplex link, and the number of ‘voice channels’ accordingly.
Why is the ratio from half-duplex to full duplex four and not two? Well conversations need both a talk and a listen path.
And, for half duplex both paths share the same physical wire, whereas for full duplex both send and receive can occur
simultaneously on different wire pairs.
Thus for half-duplex the channel availability is 10M x 40% / (2 x 100k) = 20 channels. Only 40% of the bandwidth is
available due to collisions and the collision avoidance mechanisms. For full duplex connections there are no collisions, so
utilisation can double to 80%. Also there are separate paths for send and receive data, so only half the connection
bandwidth is used. Thus 10M x 80% / (1 x100k) = 80 channels.
3.6.2 WAN
A WAN link is generally point to point between routers and so is always a full duplex link. The link speed for access WAN
connections are also slower, so the number of available ‘voice channels’ is reduced.
So, for example a 1.5Mbits/s link might support the following number of ‘voice channels’:
Cable CapacityBandwidth %“Voice Channels”G.711“Voice Channels”G.729 (x 2.5)
1.5Mbits/s without
QoS mechanism40% 6 15
1.5Mbits/s with QoS
mechanism70% 10 26 
						

							9
When a WAN link is shared with other data devices there are other considerations including the introduction of waiting
delay. The end device sees this as jitter resulting in potential packet loss and the user experiencing voice quality
degradation. All these need to be considered.
3.7 Serialisation Delay
Serialisation delay is due to the fact that data is queued in a particular device, but cannot be sent because another packet
is currently being sent. In a fast link, such as in the LAN, this delay is fairly small (orders of a few milliseconds) and is
easily taken care of with the end-device jitter buffer.
However, in a WAN access connection, the data rate is potentially not as high as within the LAN. In this case the waiting
delay, or serialisation delay, increases as the data rate reduces. If a particularly large packet (1500 bytes) is being sent,
then other devices must wait until that has gone before they can get access.
The IP-Phone and gateway devices are capable of handling delay variations up to 30ms, but this is the limit. A more
reasonable working limit is 20ms. The following chart shows waiting delay against link speed as well as against MTU.
From the graph, below, it can be seen that when a packet of 1500 bytes is sent, in order to meet the 20ms ideal working
position, that a data-rate of about 700kbits/s is needed.
Through modifying the router MTU value to 500, larger packets will be cut down and sent in smaller chunks. The result of
this is that there are three times as many opportunities to send the voice data. Thus the data rate link could be reduced to
300kbits/s. Note that RFC791 suggests a minimum MTU of 576 and some router devices may not accept values less than
this.
Beware, as some packets may not allow MTU to cut them down. Video may be one of these. In this case the router with
the lower MTU could reject these packets, effectively denying access.
Although the data rates above are minimum recommendations, slower speeds have been used. However, these involve
links with strict control of priority queuing and may involve physical restrictions such as available for PC or Phone but not
both simultaneously.
Serialisation delay Frame R elay
0.0 10. 0 20. 0 30. 0 40. 0 50. 0 60. 0 70. 0 80. 0 90. 0 100.0
50
150
250
350
450
550
650
750
850
950
W AN Da ta  Ra te
Delay (ms)
MTU1500
MTU500
Limit 30ms 
						

							10
For slower speed links then the recommendation is to reduce the MTU in the routers/gateways to provide more
opportunity for the voice traffic. A value of 500 has been found to work well.
3.8 Network Priority
There are two areas where priority mechanisms operate in the network to ensure that voice traffic maintains high priority.
These are:
•  Layer 2 in the LAN through use of IEEE802.1p/Q
•  Layer 3 in the WAN through use of DiffServ/TOS/Precedence
The picture blow highlights an Ethernet packet format, and the location of the Layer 2 Priority and Layer 3 Priority fields.
This view is of a Tagged frame, since it included IEEE802.1p/Q information.
3.8.1  LAN Layer 2 Priority
The priority mechanism used relies on that described in IEEE802.1p. This is a sub-section of IEEE802.1Q also known as
VLAN tagging.
One potential issue is the different ways in which these specifications have been interpreted. There are a number of
switches appearing on the market that provide VLAN capability, but these may not use all of the sections specified in
802.1Q. The method of configuring the switch ports may also differ.
The main requirements are thus:
•  Ports should be configurable to provide VLAN tagging to incoming untagged information and remove this tagging
when passing out of the switch. This is used by the controller and associated applications
•  Ports should be configurable to pass all active VLANs with tagging from one switch to another; i.e. there is no
untagged information present in the connection. This is used between LAN switches and maintains priority
information between units.