This section describes important factors that you must consider when you design and implement an RToWLAN solution.
Hardware and software selection
When you select the hardware and software for an RToWLAN solution deployment, you must consider feature sets, standards and capabilities that are supported, and compatibility of the hardware and software. It is important to ensure that the selected wireless and collaboration infrastructure and the devices that are deployed on that infrastructure deliver the required features and capabilities, whether you are selecting wireless LAN controllers and access points, collaboration platforms and applications, or the endpoint devices.
As a general rule, you should choose products that support a rich set of advanced network and application features, and at the same time, meet approved wireless and collaboration protocol standards to ensure interoperability and compatibility with a wide variety of systems. For example, when you choose wireless infrastructure components, consider full support for 802.11 wireless standards (802.11a, 802.11g, and the newer 802.11n and 802.11ac wireless access standards, as well as advanced wireless standards like 802.11e and 802.11r) as minimal requirements. Support for these standards ensures that necessary bandwidth with minimal delay and best effort treatment are provided for real-time traffic like voice and video.
When you design collaboration and communications infrastructure, a system that provides advanced capabilities (location and availability awareness, fixed mobile convergence, voice and video over IP, dual-mode device support, and so on) is needed to deliver the appropriate feature set that mobile workers require with RToWLAN deployments.
Voice and video over WLAN
It is critical that you plan and deploy a finely tuned, QoS-enabled, and highly available WLAN network to enable voice and video calling and other real-time traffic applications to ensure a successful RToWLAN solution deployment.
Because the 802.11 RToWLAN endpoints rely on the WLAN infrastructure for carrying both critical call signaling and real-time voice and video media traffic, you must deploy a WLAN network that is optimized for both data and real-time media traffic. A poorly deployed WLAN network results in a large amount of interference and diminished capacity, leading to poor RToWLAN application and service performance. In the case of voice and video calling, issues include not only poor call quality but in some cases dropped or missed calls. The poor application performance renders the WLAN deployment unusable for making and receiving calls or using other real-time applications.
Another basic requirement is that you must conduct a WLAN radio frequency (RF) site survey before, during, and after deploying an RToWLAN solution. This ensures that cell boundaries, configuration and feature settings, capacity, and redundancy are optimized to support RToWLAN applications and services. The site survey must verify that the WLAN RF design minimizes same-channel interference and also provides sufficient radio signal levels and nonadjacent channel overlap which helps to maintain acceptable real-time traffic throughput and voice and video quality as the RToWLAN endpoint device moves or roams from one location to another.
With appropriate site survey and careful planning, the wireless infrastructure conforms to the following collaboration and unified communications application minimum network requirements:
Average IP packet loss for collaboration or other communications application traffic of less than or equal to one percent.
Average end-to-end delay variation or jitter for collaboration or other communications application traffic of less than or equal to 30 ms.
Average one-way packet delay for collaboration or other communications application traffic of less than or equal to 150 ms.
If you implement an RToWLAN network that is intended to carry voice or video traffic where the one-way delay exceeds 150 ms, it introduces issues not only with the quality of the voice and video calls but also with call setup and media cut-through times. These problems occur because several call signaling messages must be exchanged between each endpoint and the call control platform to establish the call.
While conducting a site survey and carefully planning an RToWLAN network ensures a successful deployment on the 2.4 GHz WLAN band (802.11b/g/n), Cisco recommends that you use the 5 GHz WLAN band (802.11a/n/ac) whenever possible for RToWLAN endpoint connectivity. 5 GHz WLANs enable higher density device deployments and provide better traffic throughput and less interference than 2.4 GHz WLANs. Higher density, higher throughput, and less interference are important network characteristics for RToWLAN applications and services, that include voice and video calling. In addition, with the prevalence of Bluetooth headsets and other Bluetooth peripherals, interference on enterprise 2.4 GHz WLANs is hard to avoid. When you use the 5 GHz band for RToWLAN deployments, Bluetooth interference is not a concern.
In dual-band WLANs (WLANs with both 2.4 GHz and 5 GHz bands), devices can roam between 802.11b/g/n and 802.11a/n with the same service set identifier (SSID), provided the RToWLAN endpoint is capable of supporting both bands. However, with some devices, a dual-band WLAN can cause gaps in the real-time traffic path. To avoid these gaps, use only one band for real-time traffic applications and services.
Quality of Service
One critical component for successful RToWLAN solution deployments is to implement Quality of Service (QoS) at the network and application layer. QoS ensures that different types of network traffic are given access to specific amounts of bandwidth or are given priority over other traffic as they traverse the network. You can use a variety of methods to provide different levels of network throughput and access based on traffic type.
For real-time traffic, QoS methods fall into the following two categories:
Packet marking Packet marking determines how packets are queued as they ingress and egress network interfaces along the traffic path. Based on packet marking, certain types of traffic are allocated more or less bandwidth or can be transmitted more quickly and more often. Generally, when traversing the network, real-time media traffic is given priority treatment in all transmit queues along the network path. Real-time signaling traffic that is used to set up calls or facilitate application features is allocated dedicated bandwidth amounts based on the expected overhead of this signaling and other control plane traffic. Real-time signaling and other non-media traffic must never be assigned to priority traffic queues.
Packet queuing Packet marking may or may not be performed at the application or endpoint level, but most IP networks are capable of marking or re-marking traffic flows as they traverse the network. Marking or re-marking of traffic flows by the network is usually based on IP port numbers or IP addresses. The client application or device performs the packet marking at the endpoint level based on specific application requirements or based on standardized marking guidelines (for example, voice media should be marked as Layer 2 802.11 WLAN User Priority 6, and Layer 3 IP packet marking should be Class of Service of 5, Differentiated Services Code Point of 0x46, or Per-Hop Behavior Expedited Forwarding).
802.11 WLAN packet marking at layer 2 (User Priority, or UP) presents challenges for many RToWLAN applications and endpoints. While some applications and endpoints do mark RToWLAN traffic flows at Layer 2 according to standard guidelines, many endpoint devices, particularly multifunction mobile devices, may not support Layer 2 802.11 UP marking. Unless endpoint devices are fully 802.11e and WMM compliant, and the operating system supports UP values as marked by applications, you cannot rely on Layer 2 QoS marking to provide improved RToWLAN traffic throughput on the wireless network.
Packet marking at Layer 3 is more common in RToWLAN applications and endpoints. Many applications and endpoints mark RToWLAN traffic flows at Layer 3. When the application and endpoints are marking traffic according to recommended guidelines, existing wired network QoS policy should not be modified, because real-time traffic automatically receives appropriate treatment based on standard QoS policy (priority treatment for voice and dedicated bandwidth for video and control plane traffic).
While correct packet marking is important, whether by application or endpoint, it is also important that you trust that the correct packet marking is applied to the correct type of traffic by the application or endpoint. If the packet marking of even some network traffic generated by an RToWLAN endpoint cannot be trusted, then administrators can decide to rely on network-based packet re-marking for all traffic. In this case, all traffic is re-marked according to enterprise policy based on traffic type (port number or protocol) and IP address to ensure that network priority queuing and dedicated bandwidth are applied to traffic flows. As a general rule, you must not trust the packet marking from RToWLAN endpoints unless the enterprise has complete control over the endpoints and the applications that are running on those devices. Besides re-marking packets for untrusted devices or applications, administrators can also enable network-based policing and rate limiting to ensure that untrusted devices or applications do not consume too much network bandwidth.
In some deployments, RToWLAN endpoints securely connect to the enterprise network to utilize RToWLAN applications and services. Because these connections traverse the Internet, there is no end-to-end QoS on the IP path. All packet marking is ignored and all traffic is treated as best effort. RToWLAN application performance cannot be guaranteed over these types of connections.
When you deploy wireless endpoints, consider the security mechanisms that are used to control access to the network and to protect the network traffic. Wireless LAN infrastructure and RToWLAN endpoints support a wide range of authentication and encryption protocols, including WPA, WPA2, EAP-FAST, and PEAP. Generally, the authentication and encryption method that you choose for securing the wireless LAN should align with the IT security policies that are supported by both the WLAN infrastructure and the RToWLAN endpoint devices that you deploy.
An authentication and encryption method that supports fast rekeying such as Proactive Key Caching (PKC) or Cisco Centralized Key Management (CCKM) is important for real-time traffic solution deployments. It is critical because it ensures that active voice and video calls and other RToWLAN applications can maintain connectivity and operations as the RToWLAN endpoint is roaming from one access point in the network to another.
Another important security consideration is seamless attachment to the WLAN network. The endpoints must automatically attach to the WLAN network without user intervention to maximize the utilization of RToWLAN applications and services. Certificate-based identity and authentication facilitates an excellent user experience by eliminating user intervention (after initial provisioning) for network connection and minimizing authentication delay. However, deployments where enterprise security policy requires two-factor authentication or one-time passwords, user intervention is required for network attachment. In such cases, access to RToWLAN applications and services gets delayed.
Remote secure attachment
With appropriate security infrastructure and configuration in place, 802.11 RToWLAN endpoints are able to connect to the enterprise from remote locations using public or private 802.11 WLAN networks or Wi-Fi hot spots. While this securely enables RToWLAN application and service delivery for remote attached endpoints, you must consider whether to deliver RToWLAN applications and services over these types of remote connections.
The two key reasons that makes it problematic to enable RToWLAN applications and services over remote secure connections are as follows:
Nonenterprise 802.11 WLAN Public and private 802.11 WLAN networks like wireless hot spots that are found at coffee shops and airports are typically not optimized for real-time traffic applications and do not deliver enterprise-class security or performance. Acceptable RToWLAN solution performance (voice and video quality, connection reliability, and so on) can never be guaranteed over nonenterprise class 802.11 WLANs.
Internet traversal Because remote connections result in real-time traffic traversing the Internet between the enterprise and the endpoint, RToWLAN application performance, including voice and video quality, may be poor. Connectivity across the Internet is never guaranteed and always best effort. There is no end-to-end QoS on the IP path and all packet marking is ignored. All traffic is treated as best-effort. Acceptable RToWLAN solution performance can never be guaranteed over these Internet-based network connections.