Figure 5 shows the client side of Intel VoIP over WLAN architecture, which consists of the following key components:

1. Softphone application.
2. Intel WLAN Softphone Application Programming Interface (API): Softphone applications use this interface to convey VoIP profile information to the WLAN QoS Manager. A VoIP profile is a collection of application-level parameters that defines the QoS requirements of the application. This API provides profile and flow management functionality. In addition, this can also be used to collect statistics for a VoIP flow such as packet loss, delay, and jitter, which can be used by the application for troubleshooting or for renegotiating the call.
3. WLAN QoS Manager: The WLAN QoS Manager is the interface between the softphone application and the WLAN driver. This is represented by the " Winsock Layer/GQoS API" block in Figure 5. It provides translation of a VoIP profile into appropriate parameters as understood by the WLAN MAC layer, i.e., traffic specification (TSPEC) and traffic classifier (TCLAS) information as defined in IEEE 802.11e/WMM.
4. WLAN MAC Layer: The Client WLAN MAC layer is split across the WLAN driver and the WLAN NIC. It contains both standards-based implementations of IEEE 802.11/.11e as well as any optimizations that Intel VoIP over WLAN architecture provides for improving the VoIP experience.
5. Intel Management Application: Intel management application can be used by IT managers to configure new VoIP profiles and to delete/modify existing VoIP profiles.

Figure 5: VoIP over WLAN client architecture
click image for larger view
 

Note that VoIP and signaling packets generated by the softphone application (and its peer application/call manager) traverse the path shown through the Winsock [7] layer, TCP/IP stack, and the WLAN subsystem. The control path shown on the right side of the diagram is used to set up a VoIP flow over the WLAN network between the client and the AP.

Figure 6 shows an example sequence of VoIP flow creation in the Intel VoIP over WLAN architecture. When the softphone (VoIP) application is ready to initiate or accept a VoIP call, it first queries the list of VoIP profiles supported by the Intel WLAN VoIP API. From this list, the application picks a VoIP profile, depending on the codec and frame rate it has selected for the call, and it issues a Create Flow request to the VoIP API with the selected profile and a classifier, that describes the VoIP traffic. The VoIP API and QoS Manager map the VoIP profile to a WLAN Traffic Specification (TSPEC) and the classifier to WLAN TCLAS and request the WLAN driver to add a traffic stream over the air using these parameters. The WLAN driver sends the request to the AP according to the protocol specified in WMM/IEEE 802.11e. If the request for Create-Flow is accepted, the AP allocates medium time to the VoIP call and returns a successful response to the client. Otherwise, the AP simply returns a failure response to the client. The WLAN driver then processes the response and returns a success or a failure to the QoS Manager for the Created-Flow request. Lastly, the QoS Manager makes a callback into the softphone application via the VoIP API to inform it of the result of the call creation.

In case of a failure response, the softphone application may generate a busy signal indicating to the user that resources for the call are not available. The user may try the call again at a later time.

Figure 6: Example of VoIP flow creation over WLAN
click image for larger view
 

VPN Implications

Most VPN technologies rely on "tunneling" the original data traffic from one VPN endpoint to another using some form of encapsulation. Since the original data packet is encrypted before it is transported over a VPN tunnel, header attributes from the original packet such as UDP/TCP port numbers, IP addresses etc. are not visible to a WLAN driver when it examines a VPN packet. This limits the ability of WLAN drivers to correctly identify and prioritize a flow. As an example, if an application creates a VoIP flow reservation in the WLAN driver and provides a classifier containing source/destination IP addresses, port numbers and protocol, the driver will be able to create the flow but will fail to identify packets that belong to this flow. Thus the VoIP packets will not be assigned to the correct flow reservation and will not get the priority over WLAN that they deserve. To avoid this, when a VPN connection is in use, the application should use only a DSCP value as a classifier instead of using a full transport layer classifier. When the application detects the presence of a VPN, it can use a classifier consisting only of tunnel source and destination IP addresses and/or DSCP value in the IP header instead of using a full transport layer classifier.

Today's VPN products give more importance to security than performance. Both L2TP and PPTP (two popular VPN tunneling protocols) bring in performance issues due to the processing and overhead involved in encrypting and encapsulating the packets. In PPTP, the packet is encapsulated inside a Generic Routing Encapsulation (GRE) packet, which is then encapsulated inside an IP packet before being sent across the tunnel. In L2TP, packets are encapsulated 4 to 6 times depending on the IPSec policy used. It also provides additional levels of security through the use of DES/3DES encryption which impacts performance.

To avoid performance and classification problems in the WLAN driver, it is highly recommended that enterprises use the IEEE 802.11i/WPA2 method instead of VPNs to encrypt WLAN traffic within the enterprise.