This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy

Top 10 E2E VoLTE deployment considerations

2014.12.10
Top ten E2E VoLTE deployment considerations

TextStart

By Wang Yachen,

Director of Multimedia Network Lab, China Mobile Research Institute, and Reporter of SG13 Q10 Work Team, ITU

VoLTE deployment is unprecedented in its complexity and a great challenge to carrier networks and telco business transformation. This article details the ten most important deployment considerations.

VoLTE is the mainstream solution for voice and voice-roaming services in the LTE era. VoLTE provides high-quality voice and video services and supports single-radio voice-call continuity (SRVCC) and enhanced SRVCC (eSRVCC). Through its provision of rich service experiences to end users, VoLTE is crucial to next-generation convergent communications. With the coordinated development of frequency division duplexing (FDD) and time division duplexing (TDD), more and more carriers are investing in VoLTE. They are also jointly promoting the construction of VoLTE roaming networks that will offer seamless roaming on a global scale.

IMS core network deployment

IP multimedia subsystem (IMS) supports a variety of access types and multimedia services. It has been acknowledged by the 3GPP and GSMA as the standard architecture for all-IP mobile voice services. Deployment of an IMS core network is a key to VoLTE deployment. It contains many network elements (NEs), such as the interrogating-call session control function (I-CSCF), serving-call session control function (S-CSCF), domain name server (DNS), E.164 number to URI mapping (ENUM) server, multimedia resource function controller (MRFC), multimedia resource function processor (MRFP), interconnection border control function (I-BCF), breakout gateway control function (BGCF), media gateway control function (MGCF), IP multimedia media gateway (IM-MGW), and session border controller (SBC). The IMS core network is responsible for access control, call routing, and service triggering.

The SBC is a key NE on a VoLTE network, usually co-located with the proxy-call session control function (P-CSCF), which acts as the first contact point for mobile users within IMS networks. Generally, the SBC transmits both VoLTE signals and media streams. Its location on the VoLTE network has a great impact on user experience, so deployment efficiency and engineering efficiency must be considered during centralized SBC deployment, with the traffic switching efficiency warranting consideration during distributed SBC deployment. As the proxy node and access point for VoLTE media streams, the SBC also acts as both the access transfer control function (ATCF) and access transfer gateway (ATGW), with these functionalities reducing the media channel reestablishment time for handover from LTE to 2G/3G, allowing for smooth inter-system call roaming.

EPC core network deployment

The evolved packet core (EPC) core network includes the mobility management entity (MME), serving gateway (S-GW), and PDN gateway (P-GW). It supports the following VoLTE-related functions; assignment of IPv4 or IPv6 addresses to IMS access point names (APNs); P-CSCF discovery deployment; service request routing to the IMS core network; enforcement of policy and charging rules function (PCRF) policies over the Gx interface to establish EPC and air interface bearers that meet QoS requirements; and handover request initiation for CS networks over the Sv interface between the MME and single-radio voice call continuity interworking function (SRVCC IWF).

APN configuration, which must be performed on the user equipment (UE), MME, and P-GW, is a key element of EPC core network deployment. Call and data services can share an APN or use independent APNs, and different IP addresses are required for different APNs. If they share an APN, deployment is easy, but voice could be impacted by data services. When the sharing APN solution is used, voice call-related traffic must be separated from data traffic by the IMS charging identifier (ICID) as voice calls are charged by call duration while data services are charged by traffic volume, and this separation involves complex adaptation of the billing system. This problem will not occur, however, when an independent APN solution is in use.

CS core network reconstruction

The circuit-switched (CS) and VoLTE networks will coexist for a long time to come, and coordination between the two is crucial to seamless user experience. This requires CS network support of the Sv interface for SRVCC/eSRVCC handover, which ensures voice call continuity when users roam from LTE to 2G/3G. A CS network must also support enhanced SRVCC/eSRVCC for common supplementary services after handover, such as call waiting (CW), call hold (CH), and multiparty (MPTY). An international standard solution is prescribed for evolution from CS to IMS networking – CS network upgrade to support IMS centralized services (ICS). This solution calls for the mobile switching center (MSC) server to be transformed into an enhanced MSC (eMSC) in order to support the I2 interface, migrating the service switching and call switching functions to the IMS network. A unified core network can then be built to improve user experience and operational efficiency.

However, CS network reconstruction must be minimal during the initial phase of VoLTE deployment. To implement eSRVCC, carriers need only deploy one or two eMSCs to function as the SRVCC IWF to bridge the CS and EPC/IMS networks, as inter-system handovers are relatively few and eSRVCC deployment is an interim solution for evolution to LTE.

LTE PCC deployment

Policy and charging control (PCC) architecture, proposed in 3GPP R7, provides end-to-end (E2E) policy control on packet-switched (PS) networks. In PCC architecture, the SBC/P-CSCF applies for VoLTE voice and video bearer resources from the PCRF over the Rx interface. The PCRF generates dynamic rules for the voice and video services, based on the configured policies; then, over the Gx interface, the PCRF instructs the EPC and wireless network to reserve dedicated service resources in order to ensure QoS.

E2E QoS depends on QoS parameter configuration and mapping on each NE. The configuration and mapping include provisioning of key parameters, such as QCI, ARP, APN-AMBR, and UE-AMBR, in the system architecture evolution home subscriber server (SAE-HSS) based on subscribed services; the QoS mechanism and parameter mapping of service-layer NEs (e.g. base station, MME, S-GW, P-GW, and PCRF), and differentiated control mapping between the QCI and differentiated services code point (DSCP) for IP bearer-layer NEs (e.g. router). E2E QoS deployment involves multiple fields and numerous NEs, posing a great challenge to carrier and vendor integration capabilities.

Service platform and intelligent network reconstruction

In terms of service deployment, there are two challenges. The first is service experience consistency for voice and supplementary services on 2G/3G and LTE networks. The second is intelligent network (IN) service migration from 2G/3G to LTE so that VoLTE users can use value-added services such as virtual private mobile network (VPMN) and 400.

There are three ways to resolve the first challenge.

Solution 1: Deploy an ICS architecture-based target network so that users can use IMS services even when roaming in CS networks. This solution is not mature and requires tremendous CS network reconstruction.

Solution 2: Users subscribe to originating CAMEL subscription information (O-CSI) and terminating CAMEL subscription information (T-CSI). When they make or receive calls on a CS network, it triggers the O-CSI or T-CSI to route the call requests to the anchor application server (AS), which then provides an IMS routing number (IMRN). Based on the IMRN, the CS network anchors the calls in the IMS network for service processing. This process is known as anchoring. It is easy to deploy but reduces service processing efficiency, so most carriers currently use mobile terminated (MT) anchoring only.

Solution 3: Parallel CS/IMS service processing: neither mobile originated (MO) calls nor MT calls are anchored in IMS networks. This solution requires service data synchronization between the home location register (HLR)/SAE-HSS and IMS-HSS.

Considering the availability of solutions and time to market, carriers should select solution 2 or 3, based on their network conditions.

There are several ways to help carriers migrate IN services. Carriers can deploy the IP multimedia service switching function (IM-SSF) which, similar to the service switching point (SSP) on the CS network, implements IN service control by routing CAMEL or INAP signaling to the service control point (SCP) and online charging system (OCS). In this case, it is recommended that the IM-SSF be co-located with the multimedia telephony application server (MMTel AS). Carriers could also opt to transform an IN service platform that already supports or can be upgraded to support SIP as a SIP AS. This would allow the S-CSCF to contact the SIP AS through initial filter criteria (iFC) to implement service control. Another solution would be to configure the MGCF to route interactive voice services to the MSC/SSP, on a CS network, to complete intelligent interaction. Carriers can choose a suitable solution based on their network conditions and specific services.

Convergent HLR/HSS deployment

Convergent HLR/HSS (co-located HLR, SAE-HSS, and IMS-HSS) avoids large-scale synchronization of authentication or eSRVCC data between the HLR/SAE-HSS and IMS-HSS. It also simplifies BSS/OSS reconstruction because it doesn't require VoLTE subscription data provisioning to two sets of equipment. The unified service subscription data ensures supplementary service consistency on CS and VoLTE networks, enabling the same service experience whether users are on CS or VoLTE networks.

The optimal solution for convergent HLR/HSS deployment is HLR upgrade on the live network so that it functions as both the SAE-HSS and IMS-HSS. If the HLR on a live network does not support such an upgrade, a convergent HLR/HSS must be deployed, with the legacy HLR either coexisting with the convergent HLR/HSS indefinitely or being replaced directly. Coexistence allows for smooth deployment, but it requires flexible number routing (FNR), as most users are migrated to LTE without a change to their phone numbers. FNR distinguishes routes to the existing HLR and the newly deployed convergent HLR/HSS. HLR replacement does not require FNR deployment, but it is still risky and requires comprehensive verification of every service scenario. Carriers can determine a database deployment solution and process based on their network conditions.

Diameter signaling network deployment

Diameter is the basic protocol for EPC, PCC, and IMS network communication and is used by interfaces connecting to the PCRF, OCS, and HSS. As stipulated in 3GPP, the Diameter routing agent (DRA) is used for Diameter signal routing aggregation and applies to core network routing scenarios. As defined by the GSMA, the DRA is used for security isolation in 3G/LTE inter-network roaming and interworking with legacy SS7 signaling networks; it applies to inter-network roaming interwork scenarios. The DRA is deployed between the EPC, PCC, and IMS networks and binds sessions from the same user over different NE interfaces to the same PCRF. DRA deployment helps simplify deployment and maintenance of Diameter signaling networks and accelerates service rollout.

As users migrate to LTE, the required capacity of Diameter signaling networks will increase while the capacity of SS7 signaling networks will decrease. If the STP on a live network can be directly upgraded to support Diameter, it can be reused, with convergent Diameter/SS7 relay equipment deployed otherwise. With user migration and IP-based reconstruction of SS7, convergent Diameter/SS7 networks will gradually replace legacy SS7.

BSS/OSS and NMS deployment

VoLTE service provisioning involves many NEs, including the convergent HLR/HSS, MMTel AS, IM-SSF, DNS, ENUM server, SCP, and other AS. The BSS/OSS must be rebuilt to support various service provisioning interfaces, with the call detail record (CDR) processing and online charging interfaces of the MMTel AS and P-GW rebuilt to support VoLTE service provisioning and billing.

VoLTE's all-IP architecture and complex service processes pose great challenges to network management. Less than five NEs exist on the CS core network, while VoLTE will have more than twelve core NEs. With VoLTE, far more NEs and interfaces are involved in basic service processes, increasing their complexity. Carriers must consider improving E2E troubleshooting and service provisioning efficiencies, building a service quality KPI system for LTE, and managing E2E voice quality in the all-IP architecture.

Wireless network reconstruction

The LTE network must be upgraded to support VoLTE. Real-time telecom services, such as voice and video, are sensitive to delay, imposing strict requirements on E2E QoS, including QoS on the wireless side. According to test results, wireless-related features, such as robust header compression (ROHC), transmission time interval (TTI) bundling, and semi-persistent scheduling (SPS), can improve the VoLTE coverage and system capacity. The E-UTRAN NodeB (eNodeB) must be correctly configured with neighboring GSM or UMTS location areas and eSRVCC measurement control parameters. The configurations must be adjusted correspondingly as the network changes. In addition, the base station controller (BSC) or radio network controller (RNC) must be configured to support reselection from a 2G/3G network back to a 4G network when the 4G network is available.

IP bearer network reconstruction

Generally, virtual private networks (VPNs) are used to distinguish signaling, media, and maintenance management data from telco networks to improve service security. IMS signaling VPNs and IMS media VPNs are used to distinguish IMS signaling from media, for example. Unlike 2G/3G PS users, whose IP addresses are automatically recycled when they do not consume data traffic for a period of time, VoLTE users are always online. Therefore, IPv6 address deployment is an important task for large carriers; the UE, IP bearer network, EPC core network, IMS core network, and SBC are all involved.

QoS improvement is important to the reconstruction of bearer networks, as they must be enabled with DiffServ queue scheduling in order to differentiate QoS. Priority parameter mapping between the QCI and DSCP must be configured to prioritize VoLTE services over other packet services so that QoS for VoLTE signaling, voice, and video services is assured.

VoLTE deployment involves many issues related to operation and network optimization; all require persistent effort and rich experience to overcome. We hope that carriers, network equipment vendors, and device and chip manufacturers all cooperate to promote the development of the VoLTE industry.

TextEnd