5.1.1 A note on application development

As mentioned previously, mobile broadband is about more than providing just IP connectivity for end-users. With the ability of mobile devices to connect directly to the Internet, the nature of application development becomes much more dynamic; in essence the mobile networks are opened up to the same potential for innovative application development as has been experienced on the Internet; a plethora of different applications will become available, created by companies, developer communities and individuals [, Mulligan, 2009]. A detailed discussion of application development is beyond the scope of this book – a brief overview of application development trends is provided below in order to frame the role of EPC in delivering the promise of mobile broadband applications and services that end-users will pay for.

Perhaps the most fundamental paradigm shift that will occur in the mobile industry due to the advent of mobile broadband and an all-IP core is therefore the location of application development. For nearly 30 years, applications have been developed specifically for mobile phone networks, for example voice mail or voice conferencing services. These applications were developed either in-house or by application developers skilled in telecommunications protocols and network architecture. The operator networks were closed entities. Thanks to EPC and advances in processing capacities of the terminals, this limitation on who will be creating the applications will be lifted; now any developer who has an understanding of IP technology will be able to create an application. As software development becomes simpler and new tools are developed, even end-users will be able to create their own applications. The tremendous success of products such as the Apple iPhone and the emerging open source initiatives is the key indicator to the potential for growth in these markets. As the industry progresses more and more such services and devices will be released.

The need to provide appropriate tools for the different emerging technologies has not gone unnoticed within the mobile industry and several initiatives have been developed in this area; some of these are from established players in the mobile telecommunications arena, while others are more Internet based. Those readers who wish to have more information about cutting-edge application development environments for mobile broadband and its services are referred to, Appendix C.

It should also be noted that voice and data services will, over the years, no longer come to be viewed as separate services. They will be combined together in many different ways, from multimedia communications that link in, or mash-up, content from the Internet to more complex applications such as combining voice services with the deep web or semantic web technologies that are emerging today on the Internet. The limit to the type of applications that will emerge is only the imagination. Mobile broadband allows the tremendous innovative potential of the Internet for application development to be harnessed in a mobile terminal. The delivery of voice services is covered in the next section; it should be remembered that it is fully possible to combine the voice services described below with other applications and services running on the all-IP infrastructure that EPC provides.

5.2.1 Voice services based on circuit-switched technology

Circuit switching is the traditional technology used in a telephony network. In this technology, a continuous link is established between two end-users in a phone call.

A central part of the circuit-switched network architecture is the Mobile services Switching Centre (MSC). This is the core network function supporting voice calls, handling both the signalling related to the calls and switching the actual voice calls. Modern deployments of circuit-switched core networks are normally designed with a separation of the signalling functions (handled by the MSC-Server) from functions handling the media plane (handled by the Media Gateway). Figure 5.2.1.1 shows a simplified architecture.

Here, the MSC-Server includes call control and mobility control functions, while the media, that is the actual data frames making up the voice calls, flows through a Media Gateway that can convert between different media and transport formats, as well as invoke specific functions into the voice calls, such as echo cancellation or conferencing functions. The MSC-Server controls the actions taken by the Media Gateway on a specific call and interacts with the Home Location Register/Home Subscriber Server (HLR/HSS) which handles subscription data for users of circuit-switched services.

While voice calls in mobile networks have been converted into streams of digital data since the early 1990s, the data frames themselves are not sent between mobile devices and the networks using shared channels or IP technology.

This means that unique resources in the network need to be dedicated to each voice call throughout the duration of the call. The connection is established at call setup, and is maintained until call termination when the network resources are released. Circuit-switched connections therefore consume network resources with a fixed bandwidth and a fixed delay for the duration of the call. This is also valid if no actual communication takes place, that is neither part has anything to say. As long as the call is ongoing, the allocated network resources are not available to other users. There is no obvious way to optimize these resources across multiple users.

It should be noted that this, however, is somewhat of a simplification. In order to improve the resource usage for circuit-switched services, some mechanisms have been designed to enable a somewhat more efficient usage of the available bandwidth, for example through taking advantage of silent periods in the voice calls and enabling multiplexing of several users onto a common channel. Also, in a wireless system, the available bandwidth varies to some extent, due to that the characteristics of the radio channel as such changes during the call. This may result in variations of the voice quality as the voice coder adapts to the changing radio environment.

Since the voice data for circuit-switched services are not transported using IP packets between the devices and the network, there is also no way to multiplex several services onto the same service stream, nor to provide a standard Application Programming Interface (API) towards other services or applications in the device.

The packet data services in GSM, WCDMA and LTE, however, offer IP connectivity between the mobile device and a gateway node. This IP connectivity can be used for any IP-based application and may be utilized by multiple applications simultaneously. One of these applications is naturally voice. Furthermore, the call as such can be more than a voice call and consist of several media components in addition to the voice media itself. In the EPC, carrier-grade multimedia services are provided with a technology called IMS, which is covered in the next section.

5.2.2 Voice services with IMS technology

IMS (IP Multimedia Subsystem) was originally designed by 3GPP in order to enable IP-based multimedia services over GSM and WCDMA systems, but was later on expanded to support also other access networks. The IMS concept is based around the Session Initiation Protocol (SIP), defined in IETF RFC3261. This protocol was designed by the IETF as a signalling protocol for establishing and managing media sessions, for example voice and multimedia calls, over IP networks. As mentioned in Chapter 2 the 3GPP re-uses appropriate protocols from other standards bodies within their specifications and SIP is one such protocol. It should also be noted that after the merger of the work between TISPAN, 3GPP2 and 3GPP into the ‘Common IMS’, all IMS specifications are handled by 3GPP. Both fixed and mobile networks use the same IMS specifications. It is also important to note that the voice services described within this chapter are able to be used with non-3GPP accesses, as well as the ones specified by 3GPP. As stated several times, one of the key design points for the EPC was ensuring that both 3GPP and non-3GPP accesses would be able to connect to and utilize such services.

IMS is defined as a subsystem within the mobile network architecture. It consists of a number of logical entities interconnected via standardized interfaces. Note that these are logical entities, and that vendors of IMS infrastructure equipment may combine some of these entities on the same physical product or products (Figure 5.2.2.1).

At the core of the IMS subsystem is the Call Session Control Function (CSCF). This is the node handling the SIP signalling, invoking applications and controlling the media path. The CSCF is logically separated in three different entities:

• The Proxy-CSCF (P-CSCF)

• The Serving-CSCF (S-CSCF)

• The Interrogating-CSCF (I-CSCF).

These three entities may very well reside as different software features on the same physical product.

The primary role of the P-CSCF is as a SIP proxy function. It is in the signalling path between the terminal and the S-CSCF, and can inspect every SIP message that is flowing between the two end points. The P-CSCF manages quality-of-service and authorizes the usage of specific bearer services in relation to IMS-based services. The P-CSCF also maintains a security association with the terminal as well as may optionally support SIP message compression/decompression.

The S-CSCF is the central node of the IMS architecture. It manages the SIP sessions and interacts with the HSS (Home Subscriber Server) for subscriber data management. The S-CSCF also interacts with the application servers (AS).

The primary role of the I-CSCF is to be the contact point for SIP requests from external networks. It interacts with the HSS to assign an S-CSCF that handles the SIP sessions.

The HSS manages IMS-related subscriber data and contains the master database with all subscriber profiles. It includes functionality to support access and service authorization, mobility management and user authentication. It also assists the I-CSCF in finding the appropriate S-CSCF.

The Media Resource Function Processor (MRFP) is a media plane node that can (but does not need to) be invoked to process media streams. Examples of use cases where the media data is routed via the MRFP are conference calls (where mixing of multiple media streams are needed) and transcoding between different IP media formats.

The Media Resource Function Controller (MRFC) interacts with the CSCF and controls the actions taken by the MRFP.

The Breakout Gateway Control Function (BGCF) handles routing decisions for outgoing calls towards circuit-switched networks. It normally routes the sessions to a Media Gateway Control Function (MGCF).

The Media Gateway (MGW) provides interworking including conversion and transcoding between different media formats used for IMS/IP and circuit-switched networks.

The MGCF provides the logic for IMS interworking with external circuit-switched networks. It controls the media sessions through ISUP signalling towards the external network, SIP signalling towards the S-CSCF, and through controlling the actions of the MGW.

The Session Border Controller (SBC) is an IP gateway between the IMS domain and an external IP network. It manages IMS sessions and provides support for controlling security and quality of the session. It also supports functions for firewall and NAT traversal, that is when the remote IMS terminal resides behind a device (for instance, a home or corporate router) which provides IP address conversion.

The AS (Application Server) implements a specific service and interacts with the CSCF in order to deliver it to end-users. Services may be defined within 3GPP, but thanks to the use of IP technology, it is not necessary for all services to be standardized. One example of a service that is defined by 3GPP is Multimedia Telephony (MMTel). MMTel has been designed to support voice calls using IMS, but MMTel can provide more than telephony in that other media can be added to the voice call, turning this into a complete multimedia session.

It is beyond the scope of this book to provide a more detailed description of IMS. For a more in-depth description, see, for example, [Camarillo, 2008].

5.2.3 Realization of voice over LTE

The LTE radio access has been designed to be optimized for IP-based services. This means that LTE has no support for dedicated channels optimized for voice calls. It is a packet-only access with no connection to the circuit-switched mobile core network. This is different to GSM, WCDMA and CDMA, which support both circuit- and packet-switched services and it naturally impacts the technical solution for how to deliver voice to LTE users.

Depending on the network operator build-out plans and the frequency bands used for LTE, the radio coverage can be assumed to be non-continuous or even spotty, at least in the initial stages of LTE deployment. Voice as a service, however, relies on a continuous service coverage. In a mobile network, the support for continuous service coverage is realized through handovers between radio cells and between base stations.

For EPC, two basic approaches have been guiding the work in defining voice ­service support. Simply put, either voice services for LTE users are produced using the circuit-switched infrastructure that is used for voice calls in GSM, WCDMA and CDMA, or alternatively, IMS technology and the MMTel application are used.

5.2.4 Voice services using IMS technology

MMTel is the standardized IMS-based service offering for voice calls. It offers more possibilities than a traditional circuit-switched voice call, in that additional media components, for example video or text, may be added to the voice component, thus enhancing the communication experience and value for the end-user. Since EPS is designed to efficiently carry IP flows between two IP hosts, MMTel is a natural choice for offering voice services when in LTE coverage.

In order to realize full-service coverage as well as service continuity, however, one cannot rely on the fact that LTE coverage is present everywhere the user may want to make a voice call. Full voice service coverage therefore relies on the following facts:

• other access networks are complementing the LTE access network in terms of coverage

• the device used to make the voice call (a traditional mobile phone or another device) also supports these access technologies and the technology used for voice calls in that technology (like circuit-switched procedures in, e.g., GSM)

• inter-system handovers are possible.

Figure 5.2.4.1 shows the dark small areas that illustrate LTE coverage while the large lighter area that illustrates a technology with much better radio coverage.

There are three different use cases that need to be considered:

1. A voice call is established when in LTE coverage (dark area), and the user is not moving outside LTE coverage during the duration of the call. For this use case, MMTel would be used to provide the voice service over LTE.

2. A voice call is established when outside LTE coverage (light area). The call would then instead be established using circuit-switched access over, for example, GSM. Depending on the solution, the call could be converted into a SIP-based call and handled by the IMS system, or it can be handled as a traditional circuit-switched call by the MSC.

3. A voice call is established when in LTE coverage (dark area) and during the voice call, the user moves outside LTE coverage. If the system depicted as a light area can support IMS/MMTel voice services, this would be handled through a ‘Packet Handover’ between LTE and the other system (e.g. WCDMA/HSPA or eHRPD) and the voice service would continuously be served as an IP-based service and handled by the IMS infrastructure. If this is not the case, specific measures are needed to secure service continuity when LTE coverage is lost. The 3GPP solution for this is called Single-Radio Voice Call Continuity (SRVCC).

5.2.5 Single-radio voice call continuity

SRVCC is designed to allow for the handover of a voice call between a system that supports the IMS/MMTel voice service and a second system where there is insufficient radio access support for carrying the MMTel service. This could be, for instance, due to insufficient bandwidth for IP services, or insufficient QoS support in the network.

SRVCC hence defines a solution for how an IP-based voice call in ‘system A’ (dark grey area) can be handed over to ‘system B’ (light grey area) which serves the voice call using circuit-switched procedures.

So why is this called a ‘Single Radio’ procedure? Additional complexity of this handover procedure comes from the fact that a ‘normal’ mass market terminal (the end-user device) cannot be connected to both system A and system B at the same time. It instead has to execute a very quick handover in order not to cause a serious service degradation such as an annoyingly long interruption during the voice call. This is because the end-user device would require more complex and expensive radio filters, antennas and signal processing if simultaneous connections to two systems would need to be maintained. This is where the ‘Single Radio’ comes in. It extends the 3GPP Rel-7 VCC solution which allows for handovers between IMS-based service over WLAN and circuit-switched services over, for example, GSM. In Rel-7 VCC, the assumption is, however, that dual-radio is used, that is the terminal is simultaneously connected to both WLAN and GSM at the same time. This is possible due to the difference between a system with local coverage and low transmitting power (WLAN) and a system with wide coverage and relatively high transmitting power (GSM).

3GPP has specified the following combinations for SRVCC (system A to system B):

• LTE to GSM

• LTE to WCDMA

• WCDMA (HSPA) to GSM

• LTE to 1xRTT.

The solution is based on that IMS is kept as the system serving the user for the complete duration of the call (it is the ‘service engine’ for the voice call), also when the user is served by system B. SRVCC includes interaction between the MME of the EPC core network and the MSC-Server of the circuit-switched core network, as well as an IMS VCC Domain Transfer Function (DTF).

The details of SRVCC are described in, Section 12.6.

It should be noted that in some countries, some features are needed from a regulatory perspective in order to offer a telephony service. These are scheduled for completion in Rel-9 of the 3GPP specifications. This is specifically the support of location services as well as the support for prioritization of IMS-based emergency calls.

5.2.6 Circuit-switched fallback

Circuit-switched fallback (CSFB) is an alternative solution to using IMS and SRVCC to provide voice services to users of LTE. The fundamental differences are that IMS is not part of the solution, and in fact, voice calls are never served over LTE at all. Instead, CSFB relies on a temporary inter-system that switches between LTE and a system where circuit-switched voice calls can be served.

The solution is based on the fact that LTE terminals ‘register’ in the circuit-switched domain when powered and attaching to LTE. This is handled through an interaction between the MME and the MSC-Server in the circuit-switched network domain.

There are then two use cases to consider – voice calls initiated by the mobile user or voice calls received by the mobile user:

1. If the user is to make a voice call, the terminal switches from LTE (system A) to a system with circuit-switched voice support (system B). Any packet-based services that happened to be active on the end-user device at this time are either handed over and continue to run in system B but on lower data speeds or suspended until the voice call is terminated and the terminal switches back to LTE again and the packet services are resumed. Which of these cases that apply will depend on the capabilities of system B.

2. If there is an incoming voice call to an end-user that is currently attached to LTE, the MSC-Server will request a paging in LTE for the specific user. This is done via the interface between the MSC-Server and the MME. The terminal receives the page, and temporarily switches from LTE to system B where the voice call is received. Once the voice call is terminated, the terminal switches back to LTE.

The details of CSFB are described in, Section 12.7.

5.2.7 Comparing SRVCC and CSFB

The two approaches on how to offer voice services to LTE users are fundamentally different.

The main strengths of IMS/MMTel and SRVCC include:

• Allowing for simultaneous usage of high-speed packet services over LTE and voice calls

• MMTel offers an enhanced experience to the end-user, enabling the addition of extra media components within the voice call itself.

While the main strengths of CSFB include:

• No need to rely on a deployment of IMS infrastructure and services before offering voice as a service to LTE users

• Same feature and service set offered for voice services when in LTE access as when in a system supporting circuit-switched voice calls. The circuit-switched core network infrastructure can be utilized also for LTE users.

As discussed above, both approaches rely on the end-user device used for the voice call being capable of supporting access to not only LTE but also systems with presumed wider radio coverage (e.g. GSM) as well as the capabilities to execute circuit-switched voice calls.

It should also be noted that both solutions can be simultaneously supported in the same network, and it can be assumed that operators initially deploying CSFB may over time migrate towards the MMTel+SRVCC solution.