Unify OpenScape WLAN Phone WL4 Manual técnico
System Planning
OpenScape WL 4 / OpenScape WL4 Plus
Planning Guide
A31003-M2000-P103-01-76A9
As reseller please address further presales related questions to the responsible presales organization at
Unify or at your distributor. For specific technical inquiries you may use the support knowledgebase, raise - if
a software support contract is in place - a ticket via our partner portal or contact your distributor.
Our Quality and Environmental Management
Systems are implemented according to the
requirements of the ISO9001 and ISO14001
standards and are certified by an external
certification company.
Copyright © Unify Software and Solutions GmbH & Co. KG 29/04/2020
All rights reserved.
Reference No.: A31003-M2000-P103-01-76A9
The information provided in this document contains merely general descriptions
or characteristics of performance which in case of actual use do not always
apply as described or which may change as a result of further development of
the products. An obligation to provide the respective characteristics shall only
exist if expressly agreed in the terms of contract.
Availability and technical specifications are subject to change without notice.
Unify, OpenScape, OpenStage and HiPath are registered trademarks of Unify
Software and Solutions GmbH & Co. KG. All other company, brand, product
and service names are trademarks or registered trademarks of their respective
holders.
unify.com
Contents
Contents
1 Introduction................................................................................................................................4
2 Overview.....................................................................................................................................5
2.1 Introduction to Wireless Planning............................................................................................ 5
2.1.1 Physical Separation.......................................................................................................... 6
2.1.2 Logical Separation............................................................................................................ 6
2.2 5GHz Radar Protection in DFS Channels............................................................................... 7
2.3 Support for 802.11 krv............................................................................................................. 8
3 Wired LAN and Backbone Requirements.............................................................................10
3.1 Quality of Service Recommendations....................................................................................10
3.1.1 IEEE 802.11 Priority Field...............................................................................................10
3.1.2 IEEE 802.1q Priority Field.............................................................................................. 10
3.1.3 DiffServ, DSCP Value..................................................................................................... 11
3.2 End-to-End Quality of Service............................................................................................... 11
3.2.1 Uplink : Handset to Access Point................................................................................... 11
3.2.2 Downlink to Wired Network............................................................................................ 11
3.2.3 Downlink : Access Point to Handset...............................................................................12
4 Security Considerations......................................................................................................... 13
5 Basic Cell Planning.................................................................................................................14
5.1 Transmission Rate................................................................................................................. 16
5.2 RF Signal Corruption in VoWiFi System................................................................................16
5.2.1 Free Space Loss............................................................................................................ 16
5.2.2 Distance Attenuation.......................................................................................................16
6 Co-Channel Interference.........................................................................................................18
6.1 Clear Channel Assessment................................................................................................... 18
6.2 Hidden Node Problem............................................................................................................19
7 AP Placement for Optimal Performance...............................................................................21
7.1 Conflicting Interests with RTLS Placement............................................................................22
8 Infrastructure Dependant Features....................................................................................... 23
8.1 Automatic RF Adaptations in WLAN Systems.......................................................................23
8.2 Load Balancing...................................................................................................................... 23
9 Regulatory Domain - 802.11d.................................................................................................24
10 Related Documents...............................................................................................................25
11 Migration.................................................................................................................................26
11.1 Interoperability OpenScape WLAN Phone WL4.................................................................. 26
11.2 Client Behavior Experience..................................................................................................26
11.3 Replacing Handsets: Test and Evaluation Considerations...................................................26
A31003-M2000-P103-01-76A9, 29/04/2020
System Planning, Planning Guide iii
Introduction
Introduction
This document describes how to plan for an optimal VoWiFi System when deploying the OpenS-
cape WLAN Phone WL4. This document is intended as a guide for considerations on Wireless
Local Area Network (WLAN) infrastructure planning and installation to obtain maximum perfor-
mance with respect to voice quality. The document handles the Radio Frequency (RF) aspects
in the 2.4 GHz and 5 GHz band of a multi-cell WLAN system with a focus on Access Point (AP)
placement.
In addition to theoretical discussions of the RF environment in a WLAN system, this document
also provides practical examples of how to place APs and verify the placement with the built-in
site survey tools included in the VoWiFi Handset.
How to Use this Document
We recommend the use of the WLAN infrastructure manufacturer's installation guide for system
planning, logical connection, and configuration of the WLAN system and APs. This document is
intended for use with the WLAN manufacturer’s documentation to maximize the voice quality in
the VoWiFi system.
A31003-M2000-P103-01-76A9, 29/04/2020
4System Planning, Planning Guide
Overview
Introduction to Wireless Planning
Overview
Data and voice traffic have different characteristics and thus put different requirements on the
design of the WLAN. This chapter describes how to set up a WLAN designed for mission-critical
data communication, especially Voice over Internet Protocol (VoIP) traffic.
Introduction to Wireless Planning
When designing for mission-critical data communication, it is important to have short roaming
times and low-latency communication to avoid disruptions/breaks in the voice communication.
Most data traffic functions well even if all the considerations for a mission-critical, low-latency
network are not met.
Data applications, like browsers, try to use the maximum packet size that is allowed to trans-
port the relative high amount of data that modern web pages contain. They also use Transport
Control Protocol (TCP) as transport protocol and therefore the connection to the web server can
withstand delays and loss of packets since the protocol is defined to overcome any glitches in
the transfer of data.
Voice applications, on the other hand, use a relatively small packet size, but instead require reg-
ular access to the radio channels because packets are generated in a steady stream. Since the
voice data packet is small, it is important that the overhead created by the protocols is as small
as possible. Using User Datagram Protocol (UDP) instead of TCP reduces the overhead. The
acknowledgements that are used in the TCP protocol for every packet sent are also eliminated
in the UDP protocol. Since UDP also lacks other features that TCP has, an additional protocol
is used, so packets can be sorted in the right order and the voice recorded is played back at the
correct time. This protocol is Real-time Transport Protocol (RTP).
The following table illustrates the differences:
Data transport Voice transport
Protocol FTP, HTTP over TCP RTP over UDP
Packet size Varies from small to large up
to maximum size depending
on application.
Small. All the same size < 300
Bytes.
Sensible to lost packets No. Uses built-in recovery
process in TCP.
Yes. Results in bad voice qual-
ity.
Sensible for delays No. Can stand delays of sev-
eral minutes.
Yes. Requires steady access
to the channel.
Sensible for disconnection Not always. Session may be
restored where interrupted.
Call can be dropped.
In short, the behavior of the two traffic types - data and voice - makes it difficult to design a
WLAN for mixed traffic. The demand they put on the WLANs design is nearly diametrical on
every point.
Many current WLAN networks are used for data only and seem to be working just fine. Most
users do not notice that the WLAN may suffer congestion, packet loss, retransmissions, and
so on. The applications are tolerant against such errors and there is no information visible on a
laptop about the performance of the network. Slow loading of web pages are accepted and is
blamed either on the software or on the Internet and not on the WLAN. When adding VoWiFi to
such a network, those problems rise to the surface and they are experienced as bad voice quali-
ty and they are blamed on the handset.
A31003-M2000-P103-01-76A9, 29/04/2020
System Planning, Planning Guide 5
Overview
Furthermore, the design problems get even more complex if Wi-Fi RFID tagging and location
traffic are also using the WLAN, because they require a completely different design.
The best solution to avoid these design problems is to separate traffic types, either physically
( see Physical Separation on page 6) or logically (see Logical Separation on page 6), so
they do not interfere with each other.
Physical Separation
A WLAN network can either operate on the IEEE 802.11 2.4 GHz or a 5 GHz band. Depending
on the WLAN APs used, a network may support either one of those bands or both if the AP is
equipped with dual radios. In such a case, the WLAN network can be thought of as two indepen-
dent WLANs that are physically separated by the usage of different frequencies.
An AP that has only one radio must be using protocol features that mitigate the effects of having
different traffic types and patterns in the WLAN.
Physical separation of traffic types in a wire line network is achieved by pulling two cables side
by side. It is quite common that IT departments build a second totally independent network used
only for the management of infrastructure devices that have additional management ports, for
example a WLAN controller. The management network will still be functional if the normal net-
work breaks down. Physical separation of Wi-Fi traffic is, however, not possible in any another
way than using different radio channels for different traffic types.
If voice has to share the channels with any other type of data, Wi-Fi Multimedia (WMM) priority
protocol must be used.
Logical Separation
All clients in a wireless cell have equal access rights to the air if priority schemes are not used.
Laptops that use streaming audio and video applications, like a video conferencing tool, require
not only high bandwidth but also steady regular access to the network. The large video packets
take up a lot of the bandwidth and thus the available airtime for a voice call is less.
Using the IEEE 802.11e standard or WMM gives voice packets, if configured correctly, a higher
probability to use the air than other types of packets. This standard stops data clients from mo-
nopolizing the WLAN.
In a network it is possible to use information found in the headers of the packets to identify traffic
types and to treat the traffic differently on its route to the destination based on that information.
The information that is written to or read from the headers can be used to prioritize a certain traf-
fic type above another type.
Logical Separation of Voice and Data Traffic on the Same
Channel
In a wired converged data network, traffic types are often logically separated using Virtual Local
Area Network (VLANS). This allows the administrator of the network to set up rules in the switch-
es and routers that treat the traffic types differently depending on the VLAN association of a de-
vice. Having devices on separate VLANs (but still on the same physical LAN) hides the visibili-
ty of a device from any other device that is not on the same VLAN. It also reduces the impact of
broadcasts sent in the LAN since only devices in the same VLAN receive broadcasts. The LAN
is actually divided into smaller broadcast domains, each with its own range of IP-addresses.
Some of the benefits of using VLANs are:
• Creating a separate subnet for managing devices and thus blocking any normal user from
tampering with configuration.
• Separating guest traffic from corporate data traffic, which only gives guests access to the In-
ternet.
A31003-M2000-P103-01-76A9, 29/04/2020
6System Planning, Planning Guide
Overview
5GHz Radar Protection in DFS Channels
• Reducing the broadcast domain.
• Separating traffic types.
• Protecting devices from access by unauthorized personnel.
• Giving priority in the network for some kind of traffic.
• Using role-based access rights and access to a VLAN depending on user group membership.
• Creating security rules and allowing the use of internal firewalls.
It is important to understand that devices on separate VLANs are not able to talk with each other
if there are no devices in the network that route the traffic between the virtual networks.
Thus, if using separate VLANs for voice and data devices, there must be a route for managing
traffic coming from the data network to the device.
NOTICE: Do not implement VLAN without having a clear understanding of which
devices need to talk with each other.
NOTICE: Virtual LANs have nothing to do with today's popular Virtual Machine
Technology.
VLANs in the Air
When using VLANs, a special tag is inserted into the wired data frame, indicating which of the
VLANs a frame belongs to. This tag is not defined in a wireless frame and consequently VLANs
do not exist in the air. To logically separate traffic types in the air, it is possible to create several
Service Set IDentifiers (SSIDs) on the APs. Different SSIDs can be used for different staff cate-
gories and guests. In the APs the SSIDs on the wireless side are mapped together with defined
VLANs on the wired side and thus give the impression of having VLANS defined in the wireless
media.
SSID information is sent out in the beacon packet from the AP normally every 100ms as broad-
cast packets. Broadcast packets are sent out from the AP at the lowest configured supported
speed. Most vendors are using multiple beacons, one for each SSID. The total airtime taken up
by the beacons, probe requests, and probe responses then rises significantly.
Some APs today allow configuration of up to 16 SSIDs per radio. This traffic can easily consume
more than 30% of the bandwidth. A WLAN client may also pick up SSID information from neigh-
boring WLANs, which makes this effect even more pronounced.
It is recommended to limit the use of multiple SSIDs, and turn off the lowest speeds.
5GHz Radar Protection in DFS Channels
This section briefly explains how radar detection in Dynamic Frequency Selection (DFS) chan-
nels works, and how to mitigate its impacts on wireless networks.
Several of the radio channels (the DFS-channels) available in the 5 GHz band are also used by
a multitude of radars both for civilian and military purposes, for an example in aviation, weather
radars.
At regular intervals the AP continuously probes for radar detection and moves away from the
channel if a radar is detected. Then the AP must dynamically select another channel to use. The
probing sequence is quite slow but happens without any disruption in the traffic to/from the as-
sociated clients. When the AP moves to another channel, the client may be disassociated for a
short while.
The handset supports 802.11h channel-switch announcements, but these are not guaranteed to
make the switch seamless. For example, if the AP chooses another DFS channel, the AP must
probe for radar on that channel for 60 seconds; hence, the clients associated are dropped. If the
A31003-M2000-P103-01-76A9, 29/04/2020
System Planning, Planning Guide 7
Overview
Support for 802.11 krv
handset is dropped by the AP due to such a switch, the data traffic is delayed for a short while.
This may result in a short disruption in a voice call, but would probably not be noticed for other
types of data traffic. Because of this, it is recommended to avoid using DFS channels for voice. If
DFS channels must be used due to channel planning make sure that all non-DFS channels also
are used.
The following table lists the DFS and non-DFS channels on the 5 GHz band:
Band Channel Type of channels
UNII-1 36,40,44,48 Non-DFS
UNII-2 52,56,60,64 DFS
UNII-2e 100, 104, 108, 112, 116, 120, 124,
128, 132, 136, 140, 1441 2
DFS
UNII-3 149, 153, 157, 161, 165 Non-DFS, allowed in some coun-
tries
Due to the regulations of the DFS channels, a client that does not support radar detection is not
allowed to actively scan for APs in these channels. The client then has to perform passive scan-
ning, which means that it only listens for beacons. For a voice client, this affects an ongoing call
to some degree by introducing a slight increase in jitter in the voice stream.
The handset can use the DFS channels, but the voice quality may be distorted and roaming de-
layed. The DFS channel scan algorithm is optimized and uses both passive scanning and active
scanning when it is regulatory ensured that transmitting is allowed.
Support for 802.11 krv
The handset normally monitors the Received Signal Strength Indication (RSSI) level and per-
forms a scan to find a better AP when the signal strength drops below a certain level. If it finds a
better candidate AP, it attempts to roam to it. If not, it continues to scan periodically.
The more channels the handset has to scan, the longer each scan round takes. This is espe-
cially true for DFS channels, where only time-consuming passive scanning can be performed.
Longer scan times mean bigger risk that voice quality is affected. This is why it is strongly recom-
mended to limit the number of channels the handset has to scan, and avoid using DFS channels
if possible.
One recommended way to limit the number of channels the handset has to scan is to enable
802.11k in infrastructure.
NOTICE: For OpenScape WLAN Phone WL4, 802.11k should be enabled both
in the infrastructure and the handsets.
1Channel 144 is slightly outside the specified band (5.710–5.730 GHz).
2In some countries the following rules apply for the UNII-2e band:
• Devices will not transmit on channels that overlap the 5600 - 5650 MHz band (Ch 120,
124 and 128).
• For outdoor use any installation of either a master or a client device within 35 km of a
Terminal Doppler Weather Radar (TDWR) location shall be separated by at least 30
MHz (center-to-center) from the TDWR operating frequency. Table of current TWDR
can be found in the FCC document “443999 D01 Approval of DFS UNII Devices
v01r04”.
A31003-M2000-P103-01-76A9, 29/04/2020
8System Planning, Planning Guide
Overview
When 802.11k is used, each AP holds a list of the channels used by its neighbors, and sends
this list to newly associated clients. Then the handset only needs to scan the channels present
in the latest received Neighbor List when trying to roam from an AP. In this setup, a full scan of
all channels is performed only if the OpenScape WL4 handset has failed to find a roaming candi-
date in the Neighbor List.
It is of vital importance for the roaming performance that the APs deliver a good-quality Neighbor
List when 802.11k is used.
Similar functionality is achieved with the part in 802.11v standard called BSS Transition Manage-
ment. With this functionality the handset asks the AP for the best roaming candidates and scans
in a similar way to when receiving a neighbor list.
NOTICE: OpenScape WLAN Phone WL4 does not currently support 802.11v.
Use the standard 802.11k(v) together with 802.11r fast roaming to ensure the fastest roaming.
To improve the performance of the occasional full scans, take into account the following configu-
ration guidelines:
• The amount of channels enabled on the handset should be minimized to the channels that
are used in the WLAN system. Based on the used product, see the Configuration Manual,
OpenScape WLAN Phone WL4 to get the details on how to limit the amount of channels.
• The amount of channels enabled in the WLAN system should be minimized.
If 802.11k(v) is enabled, following these guidelines increases handset and network performance.
If 802.11k(v) is not used, it is highly recommended to follow these guidelines.
A31003-M2000-P103-01-76A9, 29/04/2020
System Planning, Planning Guide 9
Wired LAN and Backbone Requirements
Quality of Service Recommendations
Wired LAN and Backbone Requirements
Quality of Service Recommendations
To be able to provide voice grade communication over WLAN, the use of WMM or 802.11e is
a necessity. These standards define the mapping of priorities on the WLAN to priorities on the
wired LAN using either Layer 2 (CoS, Class of Service) or Layer 3 priorities Differentiated Ser-
vices Code Point (DSCP).
Traffic shaping in the switches should be avoided and instead packet-based priority by the Sta-
tions (STAs) should be used. Each packet is prioritized, according to the standards mentioned
above, depending on the packet type. Priority is primarily needed for wireless prioritization and
secondarily for wired LAN prioritization.
The User Priority (UP) or DSCP value of the frame determines what Access Category (AC) will
handle the frame.
Four ACs are defined in the WMM specification:
• AC_BK (background)
• AC_BE (best effort)
• AC_VI (video)
• AC_VO (voice)
WMM maps the UP used in the 802.11 frames to a corresponding priority on the wired LAN
802.3 frame.
• Layer 2 priority uses the 802.1p priority field in the 802.1Q VLAN tag, on the wired side of the
AP/controller.
• Recommended value for 802.1p priority for voice is 6. For both the wired and wireless side of
the AP or controller.
• Recommended value for the DSCP value is 46 (EF, Expedited Forwarding) for Real-time
Transport Protocol (RTP) frames.
• SIP signalling DSCP value (0x1A (26), Assured Forwarding 31 for both handset types).
IEEE 802.11 Priority Field
The 802.11 UP is sent using the 2-bit QoS Control Field in the 802.11 Medium Access Control
(MAC) header.
IEEE 802.1q Priority Field
The structure of the VLAN tag defined in 802.1Q is illustrated in Figure 1: Structure of a VLAN
Tag on page 10.
8
7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
2
1
Prirority Mark VLANIdentif er (VID)
= 1 Bit
Octets
Figure 1: Structure of a VLAN Tag
A31003-M2000-P103-01-76A9, 29/04/2020
10 System Planning, Planning Guide
Otros manuales para OpenScape WLAN Phone WL4
5
Este manual sirve para los siguientes modelos
1
Tabla de contenidos
Otros manuales de Auricular de Unify
