3

The Full IP Core Network

3.1. Fixed mobile convergence

Fixed mobile convergence (FMC) is set of a technology bringing seamless connectivity between fixed and wireless communication networks.

FMC is the answer to the desire of consumers to be connected anytime anywhere and from any device.

This requires:

FMC, to be seamless to the end user, involves personalization for the user services.

FMC includes:

3.2. IP multimedia subsystem

3.2.1. General description of IMS

3GPP has taken IMS (Internet Multimedia Subsystem) as the core of its telecommunication standards. This trend has been followed by ETSI and other standardization bodies such as ANSI.

Figure 3.1. IMS

IMS was introduced by 3GPP with release 5 and developed to date. It is also developed by ETSI TISPAN (for fixed telecommunication). IMS is based on IETF protocols. OMA specify the service layer application.

Although originally specified by 3GPP, a number of other organizations around the world support IMS. In addition to the IETF, which specifies key protocols such as SIP, and the OMA, which specifies end-to-end service-layer applications, other organizations supporting IMS include the GSM Association (GSMA), the ETSI, CableLabs, 3GPP2, the Parlay Group, the International Telecommunication Union (ITU), the American National Standards Institute (ANSI), the TISPAN and the Java Community Process (JCP).

According to an ABI Research analyst, an advantage of IMS is that it enables rapid development and deployment of new services and is essential to the success of mobile and fixed operators who are losing revenue from traditional sources. It is forecast by ABI that mobile operators will reap $300 billion revenues over five years ending in 2013 due to new services delivered with IMS.

The benefits of using IMS include handling all communication in the packet domain, tighter integration with the Internet and a lower cost infrastructure that is based on IP building blocks used for both voice and data services. This allows operators to potentially deliver data and voice services at lower cost, in turn providing these services at lower prices and further driving demand and usage.

IMS applications can reside either in the operator’s network or in third-party networks.

IMS separates the access network from the service layer. The horizontal control layer isolates the access from the service. It is a common horizontal control layer. Logically, services do not need to have their own control functions.

IMS uses IETF protocols wherever possible, especially SIP. But other technologies apply, in particular soft switches or Generic Access Network.

However in implementation this does not necessarily map into greater reduced cost and complexity. IMS is unable to master the OTT mechanisms, which provide access to contents and contacts outside the control of wireless/fixed operators.

3.2.2. Session Initiation Protocol

SIP is the core networking protocol used within the IMS and is one of the more widely known examples of a session control protocol. Session control refers to the process used to create, modify and terminate IP-based communication sessions, and a session can include two-way voice communication, multimedia (text, audio or video) conference collaboration, instant messaging, application sharing and other contemplated but not yet fully specified services. Session control is accomplished through signaling between various network elements and endpoints using a session control protocol.

Although SIP is the most widely known session control protocol, SIP has a major limitation that is of great importance to any GSMUMTS operator. It does not provide any method of directly inter-working with the Public Switched Telephone Network (PSTN) because it was not created with the intention of it being fully backwards-compatible with legacy PSTN signaling mechanisms.

In addition to SIP, other examples of session control protocols include BICC, SIP-I and SIP-T.

BICC, or Bearer Independent Call Control, is the protocol standardized in the 3GPP Release 4 architecture and deployed in some networks today. BICC, however, is not an optimal choice for ongoing evolution because it has been limited to, and is predicted to remain limited to, operation within a GSM-UMTS context. BICC does not address domains beyond GSM-UMTS such as LTE; as a result, it does not automatically offer the future level of flexibility of continued development and evolution that would accompany the SIP with ISUP encapsulation variants (i.e. either SIP-T, SIP for Telephones or SIP-I, SIP with ISUP encapsulation).

With a technical analysis of capabilities existing within the two SIP technologies with ISUP encapsulation variants, 4G Americas recommends SIP-I as the direction for evolution. There are four areas where SIP-I is better suited for a GSM-UMTS environment than SIP-T:

3.2.3. IMS components and interfaces

The IMS is an architectural framework for delivering IP multimedia services. It was originally designed by 3GPP as a part of the vision for evolving mobile networks beyond GSM. Its original formulation appears in Release 5. This vision was later updated by 3GPP and TISPAN. In particular, IMS applies to fixed lines standards (3GPP Release 7 and TISPAN R1.1), and further updates.

Since it is becoming increasingly easier to access content and contacts using mechanisms outside the control of traditional wireless/fixed operators, the interest of IMS is being challenged.

Figure 3.2. IMS wide scope

Figure 3.3. IMS functions

The IP multimedia CN subsystem is a collection of different functions, linked by standardized interfaces, which grouped form one IMS administrative network. A function is not a node (hardware box). An implementer is free to combine two functions in one node, or to split a single function into two or more nodes. Each node can also be present multiple times in a single network, for dimensioning, load balancing or organizational issues.

3.2.3.1. Access network

The user can connect to IMS in various ways, most of which use the standard IP. IMS terminals (such as mobile phones, personal digital assistants (PDAs) and computers) can register directly on IMS, even when they are roaming in another network or country (the visited network). The only requirement is that they can use IP and run SIP user agents (SIP UAs). Fixed access (e.g., Digital Subscriber Line (DSL), cable modems, Ethernet), mobile access and wireless access (e.g. WiMAX) are all supported. Other phone systems like plain old telephone service (POTS—the old analog telephones), H.323 and non IMS-compatible VoIP systems, are supported through gateways.

3.2.3.2. Core network

The Home Subscriber Server (HSS), or User Profile Server Function (UPSF), is a master user database that supports the IMS network entities that actually handle calls. It contains the subscription-related information (subscriber profiles), performs authentication and authorization of the user, and can provide information about the subscribers location and IP information. It is similar to the GSM Home Location Register (HLR) and Authentication Centre (AuC).

A Subscriber Location Function (SLF) is needed to map user addresses when multiple HSSs are used.

Various User identities may be associated with IMS: IP Multimedia Private Identity (IMPI), IP Multimedia Public Identity (IMPU), Globally Routable User Agent URI (GRUU), Wildcarded Public User Identity. Both IMPI and IMPU are not phone numbers or other series of digits, but Uniform Resource Identifiers (URIs), that can be digits (a Tel. URI, such as Tel.: +1-555-123-4567) or alphanumeric identifiers (a SIP URI, such as sip:[email protected]).

The IMPI is a unique permanently allocated global identity assigned by the home network operator, and is used, for example, for Registration, Authorization, Administration and Accounting purposes. Every IMS user will have one IMPI.

The IMPU is used by any user for requesting communications to other users (e.g. this might be included on a business card). There can be multiple IMPU per IMPI. The IMPU can also be shared with another phone, so that both can be reached with the same identity (for example, a single phone-number for an entire family).

GRUU is an identity that identifies a unique combination of IMPU and UE instance. There are two types of GRUU: Public-GRUU (P-GRUU) and Temporary GRUU (T-GRUU):

A wildcarded Public User Identity expresses a set of IMPU grouped together.

The HSS subscriber database contains the IMPU, IMPI, IMSI, MSISDN, subscriber service profiles, service triggers and other information.

CSCF – Call Session Control Function

The Call Session Control Function (CSCF) is a collection of functional capabilities that play an essential role in the IMS CN. The CSCF is responsible for the signaling controlling the communication of IMS User Equipment (UE) with IMS enhanced services across different network accesses and domains. The CSCF controls the session establishment and teardown, as well as user authentication, network security and Quality of Service (QoS).

Several roles of SIP servers or proxies, collectively called CSCF, are used to process SIP signaling packets in the IMS.

To summarize, the P-CSCF is the first point of contact between the UEs and the IMS network. Acting as a SIP proxy, all the SIP requests and responses from/to UEs traverse the P-CSCF. The P-CSCF may be located in either the user’s home network or in the visited network for handling roaming.

The P-CSCF supports several important functions:

The P-CSCF may support Policy Enforcement capabilities for authorizing media plane resources, bandwidth and QoS management.

In addition, the P-CSCF can also generate charging information to be collected by charging network nodes.

A Serving-CSCF (S-CSCF) is the central node of the signaling plane. It is a SIP server, but performs session control too. It is always located in the home network. It uses Diameter Cx and Dx interfaces to the HSS to download user profiles and upload user-to-S-CSCF associations (the user profile is only cached locally for processing reasons only and is not changed). All necessary subscriber profile information is loaded from the HSS.

To summarize, the S-CSCF is a central function of the signaling plane in the IMS CN. A S-CSCF node acts as a SIP registrar, and in some cases as a SIP redirect server. It is responsible for processing the location registration of each UE, user authentication and call routing and processing. Similar to the I-CSCF, the S-CSCF supports Diameter Cx and Dx interfaces to the HSS to download the authentication information and user profile of the registering UEs from the HSS for authentication purpose. All of the SIP signaling from/to the IMS UEs traverses their serving S-CSCF allocated during the registration process. The S-CSCF also provides SIP message routing and services triggering. It also enforces the policy of the network operator and keep users from performing unauthorized operations.

The S-CSCF is always located in the home network. A number of S-CSCFs may be deployed for the sake of scalability and redundancy.

An Interrogating-CSCF (I-CSCF) is another SIP function located at the edge of an administrative domain. Its IP address is published in the Domain Name System (DNS) of the domain (using NAPTR and SRV type of DNS records), so that remote servers can find it, and use it as a forwarding point (e.g. registering) for SIP packets to this domain.

To summarize, The I-CSCF is a SIP proxy located in the edge of an administrative IMS domain. Its IP address is published in the DNS of the domain (using NAPTR and SRV type of DNS records), so that remote servers can find and use it as a forwarding point (e.g., registering) for SIP packets to this IMS domain. The I-CSCF implements a Diameter (RFC 3588) interface to the HSS, and queries the HSS to retrieve the address of the S-CSCF for an UE to perform SIP registration. Being a SIP proxy, the I-CSCF forwards SIP message requests and responses to the S-CSCF. Additionally, the I-CSCF may encrypt parts of the SIP messages securing any sensitive information.

Typically the IMS network includes a number of I-CSCF nodes for the purpose of scalability and redundancy. The I-CSCF is usually located in the IMS home network.

An Emergency-CSCF, the E-CSCF is a newly defined entity in the IMS network. As its name indicates, the E-CSCF is responsible for handling of emergency call service. Once the P-CSCF detects that the received SIP message request is for an emergency call it forwards that SIP message to the E-CSCF. Then, the E-CSCF contacts the Locating Retrieval Function (LRF) to get the location of the UE for routing the emergency call appropriately. The E-CSCF can be located either in a home network or in a visited network.

SIP ASs host and execute services (Next Generation Network Services), and interface with the S-CSCF using SIP. An example of an AS that is being developed in 3GPP is the Voice call continuity Function (VCC Server). Depending on the actual service, the AS can operate in SIP proxy mode, SIP UA mode or SIP B2BUA mode. An AS can be located in the home network or in an external third-party network. If located in the home network, it can query the HSS with the Diameter Sh or Si interfaces (for a SIP-AS).

Functional model: the AS-ILCM and AS-OLCM store the transaction state, and may optionally store the session state depending on the specific service being executed. The AS-ILCM interfaces to the S-CSCF (ILCM) for an incoming leg and the AS-OLCM interfaces to the S-CSCF (OLCM) for an outgoing leg. Application Logic provides the service(s) and interacts between the AS-ILCM and AS-OLCM.

Public Service Identities (PSI) are identities that identify services, which are hosted by ASs. As user identities, PSIs will take the form of either a SIP or Tel URI. PSIs are stored in the HSS either as a distinct PSI or as a wildcarded PSI:

Media servers

The Media Resource Function (MRF) provides media-related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements.

Each MRF is further divided into a Media Resource Function Controller (MRFC) and a Media Resource Function Processor (MRFP).

The Media Resource Broker (MRB) is a functional entity that is responsible for both collection of appropriate published MRF information and supplying of appropriate MRF information to consuming entities such as the AS. MRB can be used in two modes:

A Breakout Gateway Control Function (BGCF) is a SIP proxy which processes requests for routing from an S-CSCF when the S-CSCF has determined that the session cannot be routed using DNS or ENUM/DNS. It includes routing functionality based on telephone numbers.

A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signaling, CS networks use ISDN User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses SIP over IP. For media, CS networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP).

Media Resources are those components that operate on the media plane and are under the control of IMS Core functions. Specifically, Media Server (MS) and MGW.

IMS has two types of Next Generation Networking interconnection :

An NGN interconnection mode can be direct or indirect. Direct interconnection refers to the interconnection between two network domains without any intermediate network domain. Indirect interconnection at one layer refers to the interconnection between two network domains with one or more intermediate network domain(s) acting as transit networks. The intermediate network domain(s) provide(s) transit functionality to the two other network domains. Different interconnection modes may be used for carrying service layer signaling and media traffic.

Offline charging is applied to users who pay for their services periodically (e.g. at the end of the month). Online charging, also known as credit-based charging, is used for prepaid services, or realtime credit control of postpaid services. Both may be applied to the same session.

Charging function addresses are addresses distributed to each IMS entitly and provide a common location for each entity to send charging information. Charging Data Function (CDF) addresses are used for offline billing and Online Charging Function (OCF) for online billing.

IMS-based PSTN Emulation System (PES) provides IP network services to analog devices. IMS-based PES allows non-IMS devices to appear to IMS as normal SIP users. Analog terminal using standard analog interfaces can connect to IMS-based PES in two ways:

Both A-MGW and VGW are unaware of the services. They only relay call control signaling to and from the PSTN terminal. Session control and handling is done by IMS components.

Session handling

One of the most important features of IMS, that of allowing for a SIP application to be dynamically and differentially (based on the user’s profile) triggered, is implemented as a filter-and-redirect signaling mechanism in the S-CSCF.

The S-CSCF might apply filter criteria to determine the need to forward SIP requests to AS. It is important to note that services for the originating party will be applied in the originating network, while the services for the terminating party will be applied in the terminating network, all in the respective S-CSCFs.

An initial filter criteria (iFC) is an XML-based format used for describing control logic. iFCs represent a provisioned subscription of a user to an application. They are stored in the HSS as part of the IMS Subscription Profile and are downloaded to the S-CSCF upon user registration (for registered users) or on processing demand (for services, acting as unregistered users). iFCs are valid throughout the registration lifetime or until the User Profile is changed.

The iFC is composed of:

There are two types of iFCs:

Table 3.1. The chart describes the interfaces involved in IMS and figure 3.4 shows their place in the overall processing system

It is envisaged that security defined in TS 33.203 may not be available for a while especially because of the lack of USIM/ISIM interfaces and prevalence of devices that support IPv4. For this situation, to provide some protection against the most significant threats, 3GPP defines some security mechanisms, which are informally known as “early IMS security”, in TR33.978. This mechanism relies on the authentication performed during the network attachment procedures, which binds between the user’s profile and its IP address. This mechanism is also weak because the signaling is not protected on the User–network interface.

Figure 3.4. Security aspects of early IMS and non-3GPP systems

CableLabs in PacketCable 2.0, which also adopted the IMS architecture but has no USIM/ISIM capabilities in their terminals, published deltas to the 3GPP specifications where the Digest-MD5 is a valid authentication option. Later on, TISPAN also made a similar effort given their Fixed Networks scopes, although the procedures are different. To compensate for the lack of IPsec capabilities, TLS has been added as an option for securing the Gm interface. Later 3GPP Releases have included the Digest-MD5 method, toward a Common-IMS platform, yet in its own and again different approach. Although all 3 variants of Digest-MD5 authentication have the same functionality and are the same from the IMS terminal’s perspective, the implementations on the Cx interface between the S-CSCF and the HSS are different.

For a more detailed description see:

3.3. Evolved packet system in 3GPP standards

The new blocks specific to Evolved UMTS evolution, also known as the evolved packet system (EPS), are the evolved packet core (EPC) and the Evolved UTRAN (or E-UTRAN). Other blocks from the classical UMTS architecture are also displayed, such as the UTRAN (the UMTS Access Network), the PS and the CS CNs, respectively, connected to the public (or any private) IP and Telephone Networks. The IMS (IP Multimedia Subsystem) is located on top of the Packet Core blocks and provide access to both public or private IP networks, and the public telephone network via Media Gateway network entities. The HSS, managing user subscription information is shown as a central node, providing services to all CN blocks of 3G and evolved 3G architecture.

3.3.1. Policy and charging rules function

EPS introduces the Policy and Charging Rules Function (PCRF) as a software node designed to determine in real-time the policy rules in an IMS network. Earlier policy engines were added onto an existing network, which was sometimes cumbersome to manage and update.

Figure 3.5. Full scope of EPS

Being a policy tool, PCRF plays a central role in the NGN. It accesses subscribers’ databases and charging system. In real-time, PCRF aggregates information to and from the network, from operational support systems and other sources such as portals. It supports the creation of rules and automatically makes policy decisions for each active subscriber on the network, e.g. authorization to access one or more among the multiple services and QoSs levels offered by the network with application of the charging rules.

Figure 3.6. PCRF connections in LTE’s EPC

PCRF is available both on wired and wireless networks. It can be integrated in different platforms (billing, rating, charging, subscribers’ database) or operate on a stand alone device.

3.3.2. Release 8 system architecture evolution and evolved packet system

System Architecture Evolution (SAE) is synonymous with Evolved Packet Core (EPC). SAE/EPC is defined by 3GPP in Release 8 (Rel-8) as an entirely new CN with a flatter all-IP architecture enabling a higher data rate, lower latency packet-optimized system that supports multiple radio-access technologies, focusing on the packet-switched domain, with the assumption that the system will support all services – including voice – in this domain.

3GPP has made significant progress in Rel-8 toward the standards development and definition of a new flatter-IP CN to support the Evolved UMTS Terrestrial Radio Access Network (EUTRAN) through the SAE work item, which was later renamed the EPC Architecture. In parallel, 3GPP has made significant progress toward the standards development and definition of a new OFDMA-based technology through the Long Term Evolution (LTE) work item. This new OFDMA based air interface (LTE) is also often referred to as the EUTRAN. Note that the complete packet system consisting of the EUTRAN/LTE and the SAE/EPC is called the EPS.

The combination of LTE and SAE/EPC provides the long-term vision for 3GPP to an all-IP, packet only wideband OFDMA system expected to further improve performance by providing higher data rates, improved spectral efficiency and reduced latency. LTE’s ability to support bandwidths wider than 5 MHz is of particular importance as the demands for higher wireless data speeds and spectral efficiencies continue to grow.

As mobile operators add LTE to their radio access networks, they will simultaneously evolve the rest of their networks and subscriber devices. They will update their core and backhaul networks to handle the exponential increases in IP traffic enabled by LTE. To keep their networks performing optimally, mobile operators will flatten their CN architectures considerably by using EPC technology. EPC reduces the number of nodes in the core, which reduces latency even as the amount of data traffic increases. It simplifies deployment of IP-based networks and reduces the cost of their deployments.

Figure 3.7. Evolved packet core

EPC uses IMS as a component. It also manages QoS across the whole system, which will be essential for enabling a rich set of multimedia-based services. The EPS will be optimized for all services to be delivered via IP in a manner that is as efficient as possible – through minimization of latency within the system, for example.

Although it will most likely be deployed in conjunction with LTE, EPC may also be deployed for use with HSPA+, where it would provide a stepping-stone to LTE. It will support service continuity across heterogeneous networks, important for LTE operators that must simultaneously support GSM/GPRS/EDGE/UMTS/HSPA customers.

The key features and capabilities of SAE/EPC include:

The EPC is a flat all-IP-based CN that can be accessed through 3GPP radio access (LTE, 3G and 2G) and non-3GPP radio access (e.g. WiMAX and WLAN), allowing handover procedures within and between both radio access types. The access flexibility to the EPC is attractive for operators since it enables them to have a single CN through which different services are supported. The main components of the EPC are: (1) Mobility Management Entity; (2) Serving Gateway; and (3) Packet Data Network.

Figure 3.8. EPC components

3.3.2.1. Mobility Management Entity (MME)

Mobility Management Entity (MME) is a key control element. It is in charge of managing security functions (authentication, authorization and Network Access Server (NAS) signaling security), idle state mobility handling, roaming and handovers among other functions. The S1-MME interface connects the EPC with the evolved Node Bs (eNBs, base stations in LTE).

MME is responsible for tracking and paging procedure including retransmissions, and also for idle mode of UE. MME is also involved in bearer activation and deactivation procedures. Its task also belongs to choosing the SGW for a UE in the initial attach process and when the intra-handover takes place which involves CN node relocation.

MME is responsible for authenticating the user to the HSS, if the user is roaming MME terminates S6a interface to the user’s home HSS. All Non Access Stratum (NAS) signaling terminates at the MME point, which is also responsible for generation and allocation of temporary UE identities (GUTI). Among its duties is also authorization UE to Public Land Mobile Network (PLMN) and enforcing UE roaming restrictions if there are any. MME is also the termination point of ciphering and integrity protection for NAS signaling. Lawful interception (LI) of signaling could also be supported by MME entity. It also provides the control plane function for mobility between LTE and 2G/3G networks by the S3 interface (from SGSN to MME).

MME functions, according to 23.401 3GPP documentation, include:

The MME will signal a change is UE time zone only in case of mobility and in case of UE triggered service request, PDN disconnection and UE detach. If the MME cannot determine whether the UE time zone has changed (e.g. the UE time zone is not sent by the old MME during MME relocation), the MME should not signal a change in UE time zone. A change in UE time zone caused by a regulatory mandated time change (e.g. daylight saving time or summer time change) will not trigger the MME to initiate signaling procedures due to the actual change. Instead the MME will wait for the UE’s next mobility event or service request procedure and then use these procedures to update the UE time zone information in PDN GW.

3.3.2.2. Serving Gateway (S-GW or SGW)

SGW is the gateway that terminates the EPC interface toward the E-UTRAN via an interface called the S1-U. For each UE that is associated with the EPS there will be a unique S-GW hosting several functions, including mobility anchor point for both local inter-eNB handover and inter-3GPP mobility, inter-operator charging and packet routing and forwarding.

SGW is responsible for handovers with neighboring eNodeBs, also for data transfer in terms of all packets across the user plane. To its duties belongs taking care of mobility interface to other networks such as 2G/3G. SGW is monitoring and maintaining context information related to UE during its idle state and generates paging requests when data arrives for the UE in downlink direction (e.g. somebody’s calling). SGW is also responsible for replication of user traffic in case of LI.

SGW functions, according to 23.401 3GPP documentation include:

3.3.2.3. Packet Data Network Gateway (PDN-GW or PGW)

Packet Data Network Gateway (PGW) provides the UE with access to a packet data network (PDN) by assigning an IP address from the PDN to the UE among other functions. Additionally, the Evolved Packet Data Gateway (ePDG) provides a security connection between an UE connected from an untrusted non-3GPP access network with the EPC by using IPSec tunnels.

The PGW is the gateway which terminates the SGi interface toward PDN. If UE is accessing multiple PDNs, there may be more than one PGW for that UE, however a mix of S5/S8 connectivity and Gn/Gp connectivity is not supported for that UE simultaneously.

PGW is responsible for acting as an “anchor” of mobility between 3GPP and non-3GPP technologies. PGW provides connectivity from the UE to external PDN by being the point of entry or exit of traffic for the UE. The PGW manages policy enforcement, packet filtration for users, charging support and LI.

Possible non-3GPP technologies are: WiMAX, CDMA 1X and EvDO.

PGW functions, as a list, according to 23.401 3GPP documentation, include:

Additionally the PDN GW includes the following functions for the GTP-based S5/S8:

The PGW provides PDN connectivity to both GERAN/UTRAN only UEs and E-UTRAN capable UEs using any of E-UTRAN, GERAN or UTRAN. The PGW provides PDN connectivity to E-UTRAN capable UEs using E-UTRAN only over the S5/S8 interface.

However, from a user-plane perspective, there are only the base station (eNodeB) and the gateways. The system is considered “flat”. This results in a reduced complexity compared to previous architectures.

For further details regarding these elements and other elements of the EPC, the official specifications can be found in:

3.4. Telephony processing

3.4.1. Enhanced voice quality

To ensure compatibility, 3GPP demands at least AMR-NB codec (narrow band), but the recommended speech codec for VoLTE is Adaptive Multi-Rate Wideband, also known as HD Voice. This codec is mandated in 3GPP networks that support 16 kHz sampling.

Fraunhofer IIS has proposed and demonstrated Full-HD Voice, an implementation of the AAC-ELD (Advanced Audio Coding – Enhanced Low Delay) codec for LTE handsets. Where previous cellphone voice codecs only supported frequencies up to 3.5 kHz and upcoming wideband audio services branded as HD Voice up to 7 kHz, Full-HD Voice supports the entire bandwidth range from 20 Hz to 20 kHz. For end-to-end Full-HD Voice calls to succeed however, both the caller and recipient’s handsets as well as networks have to support the feature.

3.4.2. Circuit-switched fallback (CSFB)

In this approach, LTE just provides data services, and when a voice call is to be initiated or received, 192 twill fall back to the circuit switched domain. When using this solution, operators, which have both LTE and 3G systems, just need to upgrade the MSC (in the GSM case) instead of deploying the IMS, and therefore, can provide services quickly. However, the disadvantage is that the subscriber suffers longer call setup delay.

3.4.3. Simultaneous voice and LTE (SVLTE)

The handset works simultaneously in the LTE and circuit switched modes, with the LTE mode providing data services and the circuit switched mode providing the voice service. This is a solution solely based on the handset, which does not have special requirements on the network and does not require the deployment of IMS either. The disadvantage of this solution is that the phone can become expensive with high power consumption.

While the industry has seemingly standardized on VoLTE for the future, the demand for voice calls today has led LTE carriers to introduce Circuit-switched fallback (CSFB) as a stopgap measure. When placing or receiving a voice call, LTE handsets will fall back to old 2G or 3G networks for the duration of the call.

3.4.4. Over-The-Top (OTT) applications

There are multiple options available today for mobile applications. This includes Over-The-Top (OTT) applications, services that are generally offered by third party (non-operator) developers (e.g. Skype) that can be downloaded from popular app stores, often for free. Second, we have Web-based applications. These applications run directly from a Web browser, or are included as part of Cloud-based services that run thin client applications on a device platform. Third are pre-loaded applications which are bundled with a platform and cannot be deleted or disabled. This includes applications such as camera, maps, mail and calendar. Finally, there are embedded applications, which are deeply integrated applications that are part of the native dialer; VoLTE falls in this category.

Today we are seeing explosive growth in OTT applications for VoIP/Video/Messaging apps. By quickly browsing through Google Play and Apple Store, we see a couple of hundred (or more) VoIP/Video/Messaging apps available for free. Most of these apps use their own proprietary protocols/infrastructure/network and use the operator’s best-effort data network. Most consumers today have one or more of these apps installed on their mobile device.

OTT VoIP over LTE:

3.4.4.1. OTT Mobile VoIP

Mobile VoIP or simply mVoIP is an extension of mobility to a VoIP network. There are several methodologies that allow a mobile handset to be integrated into a VoIP network. One implementation turns the mobile device into a standard SIP client, which then uses a data network to send and receive SIP messaging, and to send and receive RTP for the voice path. This methodology of turning a mobile handset into a standard SIP client requires that the mobile handset support, at minimum, high speed IP communications. In this application, standard VoIP protocols (typically SIP) are used over any broadband IP-capable wireless network connection.

High speed services from mobile operators using LTE may have better audio quality and capabilities for metropolitan-wide coverage including fast handoffs among mobile base stations, yet it will cost more than the typical Wi-Fi-based VoIP service.

As device manufacturers exploited more powerful processors and less costly memory, smartphones became capable of sending and receiving email, browsing the Web (albeit at low rates) and allowing a user to watch TV. Mobile VoIP users were predicted to exceed 100 million by 2012 and InStat projects 288 million subscribers by 2013.

The mobile operator industry business model conflicts with the expectations of Internet users that access is free and fast without extra charges for visiting specific sites.

Mobile VoIP, like all VoIP, relies on SIP — the standard used by most VoIP services, and now being implemented on mobile handsets and smartphones.

When moving between IP-based networks, as is typically the case for outdoor applications, two other protocols are required:

For indoor or campus (cordless phone equivalent) use, the IEEE P1905 protocol establishes QoS guarantees for home area networks: Wi-Fi, Bluetooth, 3G, 4G and wired backbones using AC powerline networking/HomePlug/IEEE P1901, Ethernet and Power over Ethernet/IEEE 802.3af/IEEE 802.3at, MoCA and G.hn. In combination with IEEE 802.21, P1905 permits a call to be initiated on a wired phone and transferred to a wireless one and then resumed on a wired one, perhaps with additional capabilities such as videoconferencing in another room. In this case the use of mobile VoIP enables a continuous conversation that originates, and ends with, a wired terminal device.

A more popular approach has been full-spectrum handsets that can communicate with any wireless network including mobile VoIP, DECT and satellite phone networks, but which have limited handoff capabilities between networks. The intent of IEEE 802.21 and IEEE 802.11u is that they can be added to such phones running iPhone, QNX, Android or other smartphone operating systems, yielding a phone that is capable of communicating with literally any digital network and maintaining a continuous call at high reliability at a low access cost.

3.5. The requirements of VoLTE and V.VoIP applications

VoLTE requirements:

VoLTE is based on the IMS network, with specific profiles for control and media planes of voice service on LTE defined by GSMA in PRD IR.92. This approach results in the voice service (control and media planes) being delivered as data flows within the LTE data bearer. This means that there is no dependency on (or ultimately, requirement for) the legacy Circuit Switch voice network to be maintained.

One of the most important requirements for VoIP applications is that they must have guaranteed QoS. Since all OTT apps use VoIP over LTE (on the operators’ data networks) do not offer QoS because the same pipe is used for real-time voice/video communication as is used for web browsing and audio/video streaming. This leads to competition for bandwidth – meaning there can be no guaranteed QoS. Conversely, carrier-grade VoLTE utilizes dedicated bearer/bandwidth thus guaranteeing superior voice and video quality.

Low latency is also a key requirement for V.VoIP. With OTT apps, latency suffers as tasks queue up in the pipeline as they compete for bandwidth. OTT apps are integrated at high-level user space interfaces, whereas the embedded VoLTE integrates with low-level audio drivers for audio capture/rendering and network interfaces, thus reducing the TX/RX processing delays considerably. OTT end-to-end latency is approximately 3x higher than with embedded VoLTE.

Interoperability must also be considered. Almost all OTT apps use proprietary methods, and hence do not interoperate with each other. To overcome this, and make calling a hassle-free experience for consumers, embedded VoLTE has the opportunity to thrive through ecosystem collaboration between chipset, OEM and infrastructure vendors and mobile operators.

3.6. Voice and video over LTE are achieved using voice on IP channels (VoLTE)

The advantages of LTE are high throughput, low latency, plug and play capabilities, a superior end user experience and a simplified network architecture resulting in a 10X improvement cost-per-megabyte to carry data traffic.

Given its ability to effectively carry VoIP, LTE provides mobile carriers with a single network infrastructure for all services, including voice, short message service (SMS), and broadband data for both mobile and fixed end users. Finally, mobile operators can migrate voice and SMS from their congested and costly circuit switched core networks to a more efficient IP-based core.

Key technical requirements for Voice and Video over LTE include:

Inside the smartphone (or mobile), standards can obviously help in the collaboration between the different applications. Embedded carrier grade VoLTE/Video over LTE and Rich Communication Suite (RCS) applications are compliant to GSMA PRD IR.92 (IMS Profile for Voice, and SMS), GSMA PRD IR.94 (IMS Profile for Conversational Video Service) and RCS 5.1 (Advanced Communications Services and Client Specification) respectively.

As these apps are running on mobile devices, it is clear that optimizing for low-power consumption and optimal bandwidth is key. Some of the techniques that embedded VoLTE/Video over LTE/RCS uses to reduce power consumption and increase bandwidth include:

Network integration is also critical. All OTT apps drop the realtime voice/video calls when migrating from one network to the other, which is an obvious problem. Embedded VoLTE supports SRVCC which enables a seamless handover to legacy 2G/3G cellular networks when there is no LTE coverage, as well as handover to Wi-Fi with IP2IP and Access Network Discovery and Selection Function (ANDSF).

For a smooth user experience, it is also important to have a single user interface for both circuit switched and packet switched calls. As an integrated native application, embedded VoLTE uses one interface for both circuit switched and packet switched VoLTE calls. However, OTT applications have their own dialer/user interface for VoIP over LTE/Wi-Fi calling, but a native dialer must be used for circuit-switched calls.

The RCS is the operators’ response to real-time VoIP/Video/Messaging OTT apps. It not only supports VoIP/Video/Messaging, but also integrates an enhanced phonebook which includes capability discovery exchange and social presence information. It also supports enhanced messaging (1-1 chat, group chat, emoticons, location share and file sharing and enriched calls) and enables multimedia content sharing during a voice call, video call and video sharing. It also addresses a much larger subscriber base (more than 5 billion) compared to a fragmented OTT user base.

More and more operators across the world are following this track. Trials are ongoing for Video over LTE, with the ultimate goal of providing an integrated super-app that provides a unified VoLTE, Video over LTE and RCS functionality. The community developing Rich Communication Services is called Joyn, it is working under the umbrella of the GSMA with the leadership of prominent operators (Vodafone, Orange, Telefonica, Deutsche Telekom and Telecom Italia) and major manufacturers (Sony, Samsung, HTC, Huawei, Nokia, LG, BlackBerry, ZTE, Apple with the I-Phone).

To further increase customer satisfaction, operators’ embedded VoLTE provides the same user experience across the platforms. It supports all circuit-switched features (voice calling, and supplementary call features – call waiting, transfer, forwarding, emergency calling and SMS). It also supports some of the enhanced features such as HD Voice (AMR-WB) and HD Video, with reduced call setup times and improved voice quality that is 40% better than 3G due to using a wider bandwidth (50–7000 Hz instead of 300–2400 Hz).

Operators have adopted different approaches to migrate from the full circuit-switched voice + data to full LTE voice and data. From a high-level perspective, there are three categories:

As realization in the field, embedded VoLTE was launched in August 2012 by MetroPCS, LGU+, SK Telecom. The world’s first country-wide interoperable RCS network was launched in Spain by Movistar, Orange and Vodafone. This was followed by deployments in Korea – KT, LGU+, SK Telecom, Germany – Vodafone, T-Mobile and US – MetroPCS.

The largest LTE operator, Verizon is already testing VoLTE in trials and plans to launch the service commercially in 2014, at first using traditional CDMA-LTE combo phones, unlike other carriers, Verizon’s LTE-CDMA combo does not support a feature called SRVCC, which would hand over a VoLTE call to the 2G network if a customer walked out of 4G network range. For Verizon, launching VoLTE is dependent on matching its LTE coverage to its 2G coverage, so customers would rarely, if ever, be forced off the 4G network. Most of Verizon’s data traffic (57%) has already migrated to its LTE network. Verizon 4G now covers 95% of the US population (298 million POP).

CDMA traffic has hit its peak and has started declining. Eventually Verizon will shut down a portion of its 3G CDMA data networks, and as voice traffic moves to VoLTE it can do the same with its 2G networks. That PCS spectrum can then be re-farmed for LTE or other purposes.

VoLTE would not just support voice calls. Verizon’s service would include video-casting and other real-time multimedia communications features. As an IP service, VoLTE could be integrated into other applications and could reproduce many of the enhanced messaging and video features in over-the-top applications.

3.7. Cut down version of IMS

In order that IMS was implemented in a fashion that would be acceptable to operators, a cut down version was defined. This not only reduced the number of entities required in the IMS network, but it also simplified the interconnectivity – focusing on the elements required for VoLTE.

Figure 3.9. Cut down version of IMS Reduced IMS network for VoLTE

As can be seen there are several entities within the reduced IMS network used for VoLTE:

The IMS calls for VoLTE are processed by the subscriber’s S-CSCF in the home network. The connection to the S-CSCF is via the P-CSCF. Dependent upon the network in use and overall location within a network, the P-CSCF will vary, and a key element in the enablement of voice calling capability is the discovery of the P-CSCF.

3.8. Latency management

While much attention has been focused on LTE data rates, another important parameter, latency, is critical to enable a number of applications particularly voice services (VoLTE) or real time television

Latency depends on a number of parameter. It is a statistical measure. Some of the parameters impacting latency include traffic and subscriber load, the type of traffic and the channel radio frequency condition.

LTE includes QoS management with up to 9 classes of service. Conversational voice is very susceptible to delay and packet error loss, particularly for low bit-rate vocoders. Real-time gaming is another highly demanding application both in terms of delay budget and packet error rate.

LTE is supposed to provide a round trip time of less than 10 ms. According to LTE system specification and requirements, user plane latency is defined to be sub-10 ms for two way radio delay. Although this value excludes the latency to the core, the bulk of latency typically occurs on the air interface. Hence, there is much more room for improvements and optimization when it comes to LTE latency. This is a key issue and even failure of the LTE standard if latency is not improved. After all, LTE was designed with a 1 ms subframe to meet the low latency requirement. So far, this goal has not been achieved.

Table 3.2. Priority

The measured values exceed this limit.

Table 3.3. Latency

Figure 3.10. Latency (50 ms)

Table 3.4. Measurement

3.9. Appendix 1: VoIP tests in UK

For more details about the methodology and results, please visit David Martland’s website: www.sipcentric.com/2013/04/how–well–does–Uoip–work–ove–4g/.