Network Performance Requirements When Using Svp - Polycom SpectraLink 8020 Deployment Manual

Deploying SpectraLink 8020/8030
Wireless Telephones
July 2009
handsets unless a VIEW Certified layer-3 roaming infrastructure is used in accordance with the VIEW
deployment guidelines.
In one deployment scenario for accommodating multiple subnets, each subnet is treated independently
with respect to the SVP Servers and wireless network, but each subnet can still provide service to a
single IP telephony server. One or more SVP Server(s) can be deployed on each subnet just as with a
single subnet system, including identifying the registration SVP via DHCP option 151 or static
configuration. In the second scenario, a single SVP Server (or set of SVP Servers with one registration
SVP) is deployed, generally on the same subnet as the IP telephony server. The single (Registration)
SVP Server is identified to all phones via DHCP option 151 or static configuration, regardless of what
subnet the phone is operating in. This scenario requires fewer SVP Servers to be installed, but requires
higher performance from the router (see performance requirements in Section 4.1).
The ability to cross a subnet boundary exists in either scenario, but the SpectraLink handsets will need to
be power cycled to obtain a new IP address within the new subnet. In addition, other configuration
considerations must be addressed. Because users will not want to re-administer the wireless telephones
to a separate subnet, Extended Service Set Identifier (ESSIDs) should be the same or the handsets
should be set to the "Learn Always" mode, the security mode and associated key should be the same or
turned off, and DHCP should be used.
7.3

Network Performance Requirements When Using SVP

Ethernet packets containing voice as their payload have short, useful lifetimes, making the timely delivery
of voice packets essential. Routers can introduce latency and delay between the SVP Server and the
APs, or the call server and the APs in Wi-Fi Standard QoS mode when the SVP Server is not present,
resulting in poor voice quality.
Ethernet connectivity from the call server or other voice endpoint to the SVP Server should never exceed
100 milliseconds of network delay (one way), 30 milliseconds of network jitter, and 2 percent packet loss
end-to-end, regardless of the physical properties of the link. The link from the SVP Server to the APs
should be under 100 milliseconds of network delay, one millisecond of jitter and less than two percent
packet loss. In both cases, the jitter requirements are for wired network jitter and do not include the RF
link.
When using SVP for QoS, one function of the SVP Server is to control the timing of packets through the
AP. The SVP server delivers audio packets to the wireless telephone every 30 millisecond when in call.
The delay between the SVP Server and the AP needs to be controlled and consistent. Wired QoS
(DSCP) is one aspect of ensuring voice packets have highest priority. The jitter requirement between the
call server and the SVP Server is a function of how the audio is packetized for encapsulation in the
SpectraLink Radio Protocol (SRP) and the packet queuing in the SVP Server.
Jitter between the SVP Server and the AP should be measured at the wired Ethernet connection to the
AP. If the AP is a lightweight AP attached to a wireless controller and Polycom has VIEW Certified the
system, jitter can be measured at the entry to the wireless controller. However it is better to measure jitter
at the AP‟s Ethernet interface if the AP does not connect directly to the wireless controller. For this
handset in call measurement, the SVP Server is delivering packets at 30 millisecond intervals with no
jitter. The time is measured from the arrival of one packet from the SVP Server directed to a single
wireless telephone to the next packet from the SVP Server to the same wireless telephone. The jitter
measurement is the time difference from the ideal 30 millisecond arrival of packets at the AP. See Figure
13.
©2009 Polycom, Inc. All rights reserved.
Polycom and the Polycom logo are registered trademarks of Polycom, Inc. All other trademarks are the property of Polycom, Inc. or their respective companies.
43
Best Practices Guide