Fig. 1. The basic architecture of a UMA service deployment.
Source of information: http://www.arubanetworks.com/pdf/technology/whitepapers/wp_FMC_UMA.pdf
Advances in voice-over-IP (VoIP), and cellular networking technologies are driving opportunities for businesses to improve productivity while saving on telecommunication expenses. One fast-developing area, Fixed-Mobile Convergence (FMC) allows mobile phones to connect to Wi-Fi networks when available, taking advantage of the low cost, high bandwidth and extensive indoor coverage of Wi-Fi networks.
Within enterprise FMC there are several different architectural options that differ, depending on how closely the mobile phone is linked to the enterprise PBX, where the phone number is hosted and what voice and data calling features are offered on the phone. The different architectures can be classified into three categories:
In a PBX-centric architecture the corporate PBX is the anchor-point for calls. All incoming calls are directed to the PBX number (usually a direct inward-dial number as used by a PBX extension on a desk), and all outgoing calls are originated from the PBX, (the ‘caller-ID’ seen by the recipient is the PBX number). When a phone is within range of the corporate Wi-Fi, VoIP protocols connect it directly to the PBX, like a deskphone, and custom software on the phone allows it to emulate feature keys like the deskphone. When outside Wi-Fi coverage, the phone continues to act as a client of the PBX. An incoming call at the PBX is passed to the phone’s cellular number for completion, whereas when an outgoing call is launched from the phone, it calls back to the PBX which then directs the call to the destination. While in communication with the PBX, the phone can provide many of the features of a deskphone.
PBX-centric solutions are designed and marketed by PBX vendors, and require the addition of custom software clients to the cellphone, and call-anchoring FMC software to the IP PBX server. Every PX-centric solution is specific to a particular PBX product family: a phone set up to work with one vendor’s FMC solution will not work with a solution from a different vendor. A PBX-centric architecture is likely to appeal to businesses where there is a strong, single-vendor IP PBX solution in place. They allow for the extension of useful PBX features as the user roams, whether in Wi-Fi or mobile coverage.
Similar to PBX-centric architectures in that the equipment is owned by the enterprise and installed on-site, PBX-independent architectures are based on third-party adjunct servers that work with different types of IP PBXs. The server acts as an anchor point for call handover, but usually relies on the PBX and its telephony gateways to dial outside calls. This architecture uses special client software on the handset, primarily for Wi-Fi connection and handovers, but also provides PBX features and optionally presence and instant messaging (IM) capabilities.
While the solutions above are focused on equipment installed on an enterprise’s premises and involve some level of integration with an existing IP PBX, mobile operators have followed a different path to FMC. They have focused on connecting mobile phones to Wi-Fi networks, but the phones continue to receive all their services from the mobile operator. This approach allows consumers to compensate for poor in-home cellular coverage by installing a Wi-Fi access point, and depending on the tariff, to save money on calls made when in Wi-Fi coverage.
PBXs are not involved in a carrier centric architecture: the handset behaves as a standard mobile phone everywhere, and the subscriber continues to receive the same set of mobile services whether in cellular or Wi-Fi coverage. The mobile number used for all calls, but the cellular network transports calls over Wi-Fi only when the phone is registered via an access point.
The most successful form of carrier-centric FMC to date is known as UMA (unlicensed mobile access). UMA is a Global System for Mobile communications (GSM) standard and is in service with many GSM operators worldwide. Because UMA is a mobile industry standard, all major mobile handset vendors now offer UMA-enabled phones off-the-shelf. In the USA, T-Mobile offers a UMA service branded ‘HotSpot @ Home’. While primarily marketed for use by consumers with residential Wi-Fi networks, HotSpot @ Home has several advantages for different business uses. Aruba Networks and Kineto Wireless have investigated how to best leverage UMA service, and this document is intended to assist enterprises as they evaluate FMC architectures and services.
UMA is a mobile industry standard that enables carriers to deliver mobile services over Wi-Fi networks. By deploying UMA, mobile operators can enable subscribers with UMA-enabled dual-mode cellular/Wi-Fi mobile handsets to automatically roam and handover between cellular and Wi-Fi networks. As subscribers transition between networks they receive a consistent set of mobile voice and data services.
From the mobile operator’s perspective, UMA effectively turns Wi-Fi networks into seamless extensions of their outdoor cellular network. From the subscriber’s perspective, UMA service enables them to receive high-performance, low-cost mobile voice and data services whenever their handset can connect over a Wi-Fi network.
The diagram above shows the basic architecture of a UMA service deployment. Installed in the mobile operator’s core network, the UMA Network Controller (UNC) is a gateway between the mobile service core and the Internet. To the core mobile network, the UNC emulates a standard Base Station Controller (BSC), while on the Internet side it supports IP protocols, notably IPSec. When a UMA phone connects over Wi-Fi, it must first authenticate via the UNC to the mobile core network: this happens based on its Subscriber Identity Module (SIM), the small card identifying the user in GSM networks. Following authentication, a UMA phone establishes an IPSec tunnel to the UNC for GSM signaling, while voice conversations are carried using VoIP technology. The UNC translates these streams (signaling and bearer) back into the protocols recognized by the mobile core network.
Breaking this down in more detail, the exchange proceeds as follows:
- First the phone must recognize it is in range of a suitable Wi-Fi access point. This involves configuring an SSID and other parameters on the phone. T-Mobile UMA phones are pre-configured for the T-Mobile HotSpot @ Home Wi-Fi home router and public T-Mobile hotspots, but more can be added. The phone will automatically associate to these access points when they are detected;
- Following this the phone obtains an IP address through DHCP, and in establishing a connection over the Internet it negotiates the corporate firewall and traverses a network address translation (NAT) service;
- The phone must find the appropriate UNC security gateway (SeGW). This will be carrier-dependent: T-Mobile uses the Domain Name System (DNS). The phone requests a ‘xxxx.t-mobilesgws.com’ DNS lookup, and DNS then returns the IP address of the appropriate SeGW;
- The handsets use certificates to authenticate the SeGW. Currently operators use their own certificates so handsets are set up to always use the operator’s own network. In time, operators may use certificates from popular certificate authorities, allowing handsets may roam between operators when using Wi-Fi;
- Next the phone connects to the UNC, specifically the SeGW, using Internet key exchange (IKE) to derive keys to set up an IPSec tunnel to the UNC. Thereafter, all communications over the Internet are encrypted;
- Within the IPSec tunnel, the UMA signaling protocol is very similar to that used over GSM. When a call is set up, it will use GSM codecs such as the adaptive multi-rate codec (AMR) over IP transport within the IPSec tunnel;
Mobile data services such as short message service (SMS), multimedia message service (MMS) and the operator’s mobile portals are also carried over UMA. SMS, MMS and other mobile operator services are always directed to the UNC and the mobile core, but depending on the handset and the carrier, it is possible for non-operator data services to reach the phone outside the UMA tunnel, e.g. Web browsing traffic from some phones can bypass the UNC;
- In UMA, handovers between the mobile and Wi-Fi networks occur in a similar fashion to handovers between cell towers on the outdoor mobile network. For example, when a mobile phone is on a call and connected over a Wi-Fi network in which the Wi-Fi signal degrades, the phone can signal to the mobile core network that it would like to handover to another cell tower. At this point the network instructs the phone to switch over to the target outdoor cell tower and the mobile network moves the voice call from the UNC to the BSC serving the target outdoor cell tower. In the early stages of development, most UMA phones assumed single, isolated Wi-Fi access points, and whenever the Wi-Fi signal deteriorated past a threshold, the phone would switch to cellular without looking for an adjacent access point. More recent phones are much better at inter-access point roaming, but may not incorporate all of the sophisticated handover features found in other Wi-Fi phones. Some UMA phones provide an option to enable or disable inter-access point roaming for each SSID in its list of Wi-Fi profiles.
An enterprise with a state-of-the-art Wi-Fi network can support UMA phone service, providing benefits such as assured coverage, lower-cost calls and simple configuration. However, several hurdles must be overcome to match the capabilities of an enterprise wireless LANs (WLANs), which differ considerably from home Wi-Fi networks.
Security. As an open medium, Wi-Fi is impossible to contain, and anyone deploying a WLAN must assume it can be monitored from outside the premises. Following an early false start with wired equivalent privacy (WEP), Wi-Fi networks secured with Wi-Fi protected access (WPA2) and 802.1x are considered more secure than most wired LANs. The challenge is to introduce UMA phones into a secure corporate environment without having the phone introduce a point of vulnerability;
Quality of Service. Whereas WLANs that are not properly secured pose a threat, unreliable networks are useless. It is important that the UMA user’s experience on Wi-Fi be satisfactory at a minimum, and that this new service does not adversely affect other WLAN users.
These potential issues can be mitigated in different ways, However, before addressing these issues we will turn first to a discussion about the level and type of access given to UMA devices, as these will inform the discussion about migration options.
Most corporate WLANs offer secure network service to employees within the corporate firewall, providing access roughly equivalent to a wired Ethernet connection. Guest access for visitors to the enterprise is also provided, usually on an open SSID, and with a captive portal Web page for terms of service and/or login with guest credentials. Following guest authentication, traffic is typically directed outside the firewall.
Either use an existing, open SSID, or configure a new one for the desired UMA carrier and service. Phones will need to be configured with the ‘guest’ SSID (but only once per phone) unless the SSID used is one of the carrier’s ‘well-known’ SSIDs. For T-Mobile, two SSIDs are pre-configured on all phones: the HotSpot @ Home Wi-Fi router is ‘XXXX’ and the T-Mobile hotspot service is ‘tmobile’.
The phone does not have the capability to negotiate captive portal Web pages, so it will be necessary for the Wi-Fi network either to identify that this is a UMA phone seeking service, or to remove the captive portal. Identification of UMA-specific traffic is explored later in this paper.
With this configuration, UMA service will be enabled over the corporate WLAN but isolated from the enterprise intranet. Note that using an open SSID implies either providing a completely open SSID with no captive portal, or a new SSID specifically for UMA service. Also, any UMA subscriber of the specific carrier, e.g. T-Mobile, will be able to access service via the corporate WLAN even if they are not an employee of the enterprise or simply in range of the network. These considerations may make this a less attractive option to some network managers, but alternate deployment models are available to mitigate such concerns.
In this model, UMA traffic is still kept separate from the corporate intranet, but rather than allowing open, unauthenticated access to any device, the WLAN uses network-specific credentials that permit a network manager to restrict access to only enterprise-owned UMA phones. The simplest way to implement this is to use a pre-shared key (PSK) and either WPA or WPA2 authentication.
Use an SSID for the desired UMA carrier and service with a WPA or WPA2 pre-shared key. Phones will need to be configured with these credentials, but only once per phone.
Firewall or VLAN policies can be configured to allow devices on this SSID to communicate only with the UMA operator’s SeGW. This means devices cannot use this SSID to gain intranet access except for UMA.
Since UMA phones do not have the capability to negotiate captive portal Web pages, a firewall or traffic segregation policy takes the place of captive portal authentication.
This approach is especially appropriate for UMA phones that are not 802.1x-capable.
The alternate form of access is to use a ‘normal’ SSID on the corporate WLAN. The state-of-the art is to use WPA2 authentication/encryption with 802.1x, normally with keys derived from a RADIUS server. The goal of this deployment model is that phones should use the same level of security as laptop computers, a goal that is already attainable.
Some enterprises use a separate SSID for voice, while others prefer to have one SSID for voice and data services. The proliferation of smartphones generating both voice and data simultaneously makes this distinction moot. Indeed, the more important distinction today is they type of battery-powered clients used, since different settings may be useful for extending battery life on a ‘handheld’ SSID. In any case, the configuration requires that quality of service (QoS) capabilities be enabled on both the network and the voice clients.
- The phone must be configured to look for the appropriate corporate WLAN SSID;
- The phone first associates and authenticates to the enterprise WLAN, in the same way as a PC. This will normally use some form of RADIUS-based WPA2/802.1x method such as EAP/PEAP. Configuring a phone for this is a technically sophisticated task, as it may need certificate information to recognize the corporate network, and some credentials and options must be configured. Each phone must be configured in this way, but only once;
- WPA2 requires the device to authenticate with a password whenever it connects to the WLAN, a procedure with which corporate PC users are familiar. WPA2-capable UMA phones follow the same regime, but to simplify connections, it is possible as an option to pre-configure the password on the phone rather than require the user to key in the password every time they enter Wi-Fi coverage. If such a phone is lost or stolen, it will continue to receive service until it is deactivated or blacklisted on the corporate WLAN or RADIUS server – and, of course, it will have mobile network service until the operator is informed. However, because 802.1x allows individual passwords rather than pre-shared keys as in the previous model, a single compromised password does not affect other users of the network;
- Following this the phone uses DHCP to lease a corporate IP address;
- The phone must now traverse the corporate firewall and NAT. There are two options: either the firewall can allow all corporate-initiated flows unconditionally, or ‘pinholes’ must be opened for UMA service. If the latter option is chosen, different rules must be written for each supported UMA carrier. As noted elsewhere, the specific requirements are for ISAKMP/IKE and IPSec, assuming DNS is already enabled. Firewall rules could for instance restrict IPSec flows to only ‘well-known’ UMA UNC IP addresses.
As noted above, it is important to ensure that UMA users experience good performance on their voice calls. The key to providing priority for voice traffic over data is the wireless multimedia (WMM) feature, a certification of the Wi-Fi Alliance. Today’s enterprise-grade WLAN equipment supports WMM for QoS, where WMM recognizes the diffserv tags on frames and maps the 802.1d classes of service to four queues defined in 802.11e. An incoming frame with high priority will be mapped to the high priority queue and will be allowed preference when contending for a transmit opportunity on the wireless medium.
Most UMA phones support WMM, so the frames they transmit will be at high ‘voice’ priority. By default, this priority tagging will be respected by the Wi-Fi infrastructure and maintained throughout the network. Even though UMA uses an IPSec tunnel, phones usually apply voice priority tags to the outside of the tunnel.
If a phone does not use WMM, it is still possible to provide good QoS over Aruba infrastructure by writing a firewall rule to recognize UMA traffic and assigning all such traffic high priority. Such a rule might be targeted at IPSec protocols where the destination is a UNC gateway IP address. This example will cover all traffic streams except those upstream from the phone to the access point, though it has been found that priority queuing, even if only in the downstream direction, is a very effective QoS implementation.
While QoS ensures that voice traffic receives priority over data, it is possible to overload an access point when the amount of voice traffic approaches its capacity. Under these conditions, some or all the voice calls will be impacted. Call admissions control (CAC) is a feature that limits the number of calls below this threshold, typically between 12-25 active calls per access point. Most enterprise WLANs implement CAC, however, UMA traffic is carried in IPSec tunnels and WLANs may require enhancement to recognize UMA packets as voice traffic. In the absence of such an enhancement, the network manager should use network design and traffic engineering to ensure that the maximum number of simultaneous UMA calls per access point is less than the limit. A dense deployment of access points in which each access point serves only a small area, combined with a load-balancing feature, will keep the number of active calls per access point below the CAC threshold.
While residential UMA service assumes a single Wi-Fi access point, enterprise WLANs cover large buildings by deploying many access points with overlapping coverage. This means that in an enterprise deployment, a handset will hand over voice calls between access points as the user roams around the facility. Enterprise WLANs typically include features to facilitate fast, accurate inter-access point handover. Included among these is a provision for the infrastructure to maintain the same IP address as a client moves, thereby obviating the delays – and interruptions to voice calls – associated with leasing new IP addresses through DHCP.
Additionally, when using the WPA2 protocol to achieve high security, a key feature is opportunistic key caching. OKC allows centralized WLANs to significantly reduce the time required to generate new security keys, necessary when roaming between access points. This feature can reduce voice call interruptions from several hundred milliseconds to sub-fifty millisecond levels. Some UMA phones already implement OKC today, others will be coming to market soon.
Apart from voice calls, modern GSM phones support data services. Certain mobile data services such as SMS and MMS depend on functionality in the mobile core network, so this traffic is always directed via the UMA IPSec tunnel.
However, some UMA phones now allow for non-operator mobile data services, such as email or Web browsing, to be directed outside the UMA service tunnel and directly to servers on the corporate network or the Internet. The diagram above shows how this works. Note that the phone has one Wi-Fi association on a single SSID, but maintains two or more traffic streams.
Although UMA service was developed with the consumer and residential service in mind, it has immediate applicability to businesses. In this paper, we identified and quantified the main benefits to employees associated with using UMA service.
Providing reliable coverage in the office is as important for a business as home coverage is for the consumer. For a modest investment in Wi-Fi infrastructure and Internet connectivity – which most businesses already have to some degree – it is possible to compensate for poor cellular coverage and enable the reliable use of cellphones at work.