VoLTE End to End Soln Guide

Ericsson Confidential SOLUTION GUIDELINE

1 (47)

Prepared (Subject resp) No.

EAB/FKK/T Henrik Johansson W 1/221 12-FGD 101 073 Uen Approved (Document resp) Checked Date Rev Reference

EAB/FKK Stefan Svensson 2014-03-06 E

VoLTE End-to-end Solution Guideline

Abstract

Ericsson VoLTE end-to-end solution offers the most advantages for operators and satisfies user expectations. 13B focused on the first release of handling commercial traffic for Ericsson VoLTE end to end. 14A has added Diameter Signaling Controller (DSC) integration and network provided location in IMS as the main highlights compared to earlier releases. This document covers both earlier released generic Ericsson VoLTE functionalities and the functionalities newly added in 14A to provide complete end to end guideline.


2 (47)




Contents 1 Introduction ............................................................................................ 3

1.1 Purpose ...................................................................................... 3 1.2 Revision History ......................................................................... 4

2 VoLTE end-to-end solution overview ................................................... 5 2.1 General ...................................................................................... 5 2.2 Standardization for Voice over LTE (VoLTE) services ............... 5 2.3 VoLTE basics ............................................................................. 6 2.4 Conversational voice over LTE .................................................. 7 2.5 CS coexistence .......................................................................... 7 2.5.1 Circuit Switch Fall Back (CSFB) ................................................. 8 2.5.2 IMS Centralized Services (ICS) ................................................. 8 2.5.3 Single Radio Voice call continuity (SR-VCC) ............................. 8 2.6 SMS over LTE ............................................................................ 8 2.7 Emergency Call .......................................................................... 9 2.8 Network provided Location (NetLoc) .......................................... 9

3 Ericsson VoLTE end-to-end solution outline .................................... 10 3.1 Ericsson VoLTE end-to-end solution architecture .................... 10 3.2 Long Term Evolution Radio Access Network (LTE RAN) ........ 11 3.3 Evolved Packet Core (EPC) ..................................................... 11 3.4 IP Multimedia Subsystem (IMS) ............................................... 12 3.5 Diameter Signaling Controller (DSC) ....................................... 16 3.6 Mobile CS Core ........................................................................ 17 3.7 User and Data Management (UDM) ........................................ 17 3.8 Other Ericsson product ............................................................ 19 3.9 Device ...................................................................................... 19

4 VoLTE end to end aspects .................................................................. 20 4.1 Functional aspects ................................................................... 20 4.1.1 Conversational voice over LTE ................................................ 20 4.1.2 Conversational video over LTE ................................................ 29 4.1.3 CSFB ........................................................................................ 31 4.1.4 ICS ........................................................................................... 32 4.1.5 SR-VCC ................................................................................... 33 4.1.6 SMS over LTE .......................................................................... 35 4.1.7 Emergency call ......................................................................... 37 4.1.8 NetLoc ...................................................................................... 40 4.1.9 Roaming in VoLTE ................................................................... 41 4.2 Non-Functional aspect ............................................................. 42 4.2.1 Operation and Maintenance ..................................................... 42 4.2.2 QoS and Performance ............................................................. 43

5 Terms and abbreviations ..................................................................... 45 5.1 Terminology ............................................................................. 45 5.2 Abbreviations ........................................................................... 46

6 References ............................................................................................ 46 6.1 Other documents ...................................................................... 46 6.2 Features ................................................................................... 47


3 (47)




1 Introduction

Terminal industry is driven by new high end type of devices such as smartphones and tablets. This type of devices drives the demand for high performance mobile broadband network, both regarding capacity and coverage. In order to meet these demands, operators are investing in more efficient radio technologies such as LTE. However voice is still major source of revenue and high quality voice service must be preserved also when moving into a mobile broadband centric future. The industry has aligned around GSMA Voice over LTE (VoLTE) as the standard for the telephony in LTE.

With the industry alignment around GSMA VoLTE, the 3GPP MMTel standard track has become the industry’s preferred solution for voice and SMS services over LTE. With a recent work item in GSMA, the existing VoLTE work is also becoming the base for delivering conversational video services. VoLTE leverages traditional telecom characteristics, such as high quality and global reach, and at the same time offers an optimal evolution path towards full multimedia services.

VoLTE ecosystem is building up fast due to the traction in the market. With a strong end-to-end VoLTE solution portfolio including the LTE Radio, Evolved Packet Core, Mobile Softswitch Solution, User Data Management, IMS portfolio, and its extensive delivery capabilities of complex end-to-end projects; Ericsson has a great position to support operators around the world to deploy and launch full commercial voice, SMS and conversational video services in their LTE networks.

1.1 Purpose

The purpose with this document is to give a technical overview of the Ericsson VoLTE end-to-end solution for telephony in LTE/EPC networks, building on the GSMA VoLTE profile specified in IR.92 and related suite of GSMA documents (see Figure 1). Additionally mechanisms for CS co-existence, as well as end-to-end conversational video service, are also covered.

Throughout this document, the terminology “VoLTE” will be used as a service bundle including the IMS/MMTel based SMS, voice and conversational video service over the LTE/EPC access.

The term “Ericsson VoLTE end-to-end solution” defines the Ericsson offering for VoLTE as described in this document and includes the following Ericsson products areas; IMS, UDM, MSS, EPC, LTE RAN and BSS. Unless explicitly stated differently, the document baseline is release 14A of all involved products, which constitute the Ericsson VoLTE end-to-end solution.


4 (47)




The targeted audience for the document is mainly technical managers, solution managers and solution architects in the regional organizations as well as individuals in the Business Units working with mobile telephony evolution and related fields.

This document is for internal use and cannot be submitted to external parties as is. Extracts of the document may however be suitable for external use, and can be used in customer workshops, presentations and solution descriptions as part of Ericsson proposals in this area.

The content of the document is subject to change without prior notice and does not represent a commitment on the part of Ericsson. Ericsson assumes no legal responsibility for errors or damage resulting from the use of this document.

1.2 Revision History

Revision Comments

A The first Revision was written before GSMA VoLTE work was created. It was called “Solution Guideline, MMTel over LTE”

B Aligned with GSMA VoLTE (including the voice and SMS over IP) specifications. SR-VCC/ICS are updated and moved to the main body of the document and IMS Roaming, Conversational Video over LTE chapters is added. QoS and Performance Targets, VoLTE Emergency Calls, Terminal and roaming aspects are updated.

C Solution guideline describing Ericsson VoLTE end to end offering based on 13A release base

D Official release for Solution guideline with 13B base

E Official release for Solution guideline with 14A base. Main changes are: - Re-structure of the document - Add Emergency call and NetLoc as newly introduced functionality in 14A - Modify the existing descriptions aligning with the latest implementations


5 (47)




2 VoLTE end-to-end solution overview

2.1 General

Please see Mobile Telephony Evolution Commercial presentation ref.[2] and Business Guide documents ref.[3] in Mobile Telephony Evolution with VoLTE product catalogue for a thorough analysis of market drivers, operators and end user needs in mobile broadband era and how these trends shape the evolution of multimedia communications in all-IP networks, such as LTE/EPC.

This document covers the technical aspects of an Ericsson provided end-to-end solution for SMS, voice and conversational video over LTE.

2.2 Standardization for Voice over LTE (VoLTE) services

The GSMA VoLTE initiative has defined a minimum mandatory set of functions/features specified in 3GPP that an LTE device and the network are required to implement to guarantee an interoperable IMS based telephony/SMS service over an LTE/EPC radio access network. The document describing this minimum mandatory set, or profile, is called the “IMS profile for voice and SMS” and published as GSMA PRD IR.92.

IR.92 specifies the User-to-Network interface for VoLTE including:

• MMTel telephony and supplementary services

• IMS control and media handling

• EPC IP flow and bearer management

• LTE radio capabilities to be used

There are also other VoLTE related PRDs produced by GSMA as following figure.

PRD IR.92

PRD IR.65

IMS voice onLTE - UNI

IMS Roaming & interconnect

PRD IR.94PRD IR.58

Video call UNI additions

IMS voice on HSPA – UNI

additions

PRD IR.64

Nw. recomm.for SR-VCC

& ICS

PRD IR.39

HDVC

Figure 1. VoLTE Related GSMA Documentation overview

http://prodcat.ericsson.se/frontend/category.action?code=FGD%20101%20073&path=\Navigation%20Root\MarketCategory001\FGB%20101%20844



6 (47)




2.3 VoLTE basics

A high level functional overview of the Voice and video over LTE architecture is provided in Figure 2, including the functional entities affected.

MMTelTelephonyService

VoLTEPhone

CS Core

(MSS)GSM / WCDMA /CDMA RAN

LTERAN

EvolvedPacket Core

SV, SGs MMTelIMS Core

SGi, Rx

Mg/Mw

OSS BSS Provisioning LI

MPBN

Figure 2. Functional Voice and video over LTE logical architecture overview

The figure above lists different functions in the different subsystems used in a VoLTE solution and the main interfaces between them. The different subsystems used in the solution are LTE RAN, EPC, IMS and UDM.

• LTE RAN

Handles the air interface towards the UE and involves functions such as Robust Header Compression (RoHC) and Discontinuous Reception (DRX).

• EPC

Handles the IP transport and control including; Policy control, Bearer management for QoS and P-CSCF discovery

• IMS

Handles service control and media; such as authentication, codec and jitter buffers handling, as well as supplementary service execution and provisioning.

• UDM

Handles subscriber for all the processes related with the Privacy, Authentication, Authorization and Mobility management of end users in mobile and converge Operators networks.


7 (47)




The detail of Ericsson nodes for each functions are described in chapter 3.

In order to evolve circuit switched system toward full VoLTE, there are many scenarios that could be taken by different operators. Figure 3 shows four frames which represent a framework for evolution steps and coexistence technologies used for different steps.

CircuitSwitched

CSLTE

LTE

LTELTE

CSFB

LTE

LTELTELTE

LTE LTELTELTE

LTELTELTE

LTE

LTELTE

LTELTELTE

LTELTE

LTELTELTE

LTE LTELTELTE

LTELTELTE

LTE

LTELTELTE

LTE

LTELTE

LTELTE

LTE

PS

CSLTE LTELTE

LTELTE

LTELTE

LTELTE

LTELTE

LTE

SRVCC

LTE

LTELTE

LTELTE

Spotty LTE coverage

Areas with continuous LTE coverage

Continuous IMS voice over PS coverage

Figure 3. VoLTE evolution steps and CS coexistence

2.4 Conversational voice over LTE

Voice over LTE end-to-end solution consists of three functional area, LTE RAN, EPC and IMS.

LTE RAN handles the air interface towards the UE and involves functions such as Robust Header Compression (RoHC) and Discontinuous Reception (DRX).

EPC handles the IP transport and control including; Policy control, Bearer management for QoS and P-CSCF discovery.

IMS handles service control and media; such as authentication, codec and jitter buffers handling, as well as supplementary service execution and provisioning. Legacy IN service interworking with standard MMTel services is also important to expand telephony services.

Further details on conversational voice over LTE can be found in section 4.1.1.

2.5 CS coexistence

There are number of reasons why CS coexistence may be needed for an operator including for example:


8 (47)




• Reuse of existing CS roaming agreements

• CS Emergency call handling already in place

• Lack of LTE radio coverage in some areas

Complementing VoLTE with CS is described in IR.92 Annex A and IR.64.

2.5.1 Circuit Switch Fall Back (CSFB)

For early deployments of LTE with handheld devices, operators may consider complementing LTE data services with CS voice, using Circuit Switch Fallback (CSFB). CSFB is a standardized solution utilizing existing MSC-network to provide services to LTE-capable devices before homogenous LTE-coverage is built.

CSFB can also be used to handle roaming as well as early emergence call solution. Further details on CSFB can be found in section 4.1.3 and ref.[4].

2.5.2 IMS Centralized Services (ICS)

ICS handles the situation where a VoLTE user makes or receives a call when outside LTE coverage. In a single service engine scenario, the user is still being served by IMS but cannot make use of LTE/EPC, but rather need to rely on legacy 2G/3G access and transport. Further details on ICS can be found in section 4.1.4.

2.5.3 Single Radio Voice call continuity (SR-VCC)

For the situation where a VoLTE user leaves LTE coverage during an established session, mechanisms for voice call continuity will be needed to avoid dropped calls. According to 3GPP release 10, SR-VCC means that UE is connected to either CS or LTE at one point in time. Terminal then needs to flag to network when running into poor LTE coverage and tune over to CS while network reestablish connection to the CS side of UE. SR-VCC is promoted for 3GPP markets. Further details on SR-VCC can be found in section 4.1.5.

2.6 SMS over LTE

There are two options to deliver SMS service over LTE by existing SMS-C.

• SMS over SGs

UE can send and retrieve SMS using NAS signalling over LTE. It requires SGs interface between CS Core and EPC to transport SMS to/from UE.

• SMS over IP


9 (47)




The solution is to transport SMS over any PS access using IMS and mandated to be supported by VoLTE terminals.

VoLTEPhone

CS Core

(MSS)GSM / WCDMARAN

LTERAN

EvolvedPacket Core

SGs MMTelIMS Core

SMSoSGs SMS

IP

SMSoSGs

SMSoSGs

SMSoSGs

SMSIP

SMSIP

SMSIP

Existing SMS

Figure 4. SMS options over LTE

Further details on SMS over LTE options can be found in section 4.1.6.

2.7 Emergency Call

According to IR.92, the UEs and network deployments must support emergency service in the IMS domain. In VoLTE introduction due to early deployment or regulatory requirements, fallback to CS network might be applicable in a CS co-existence scenario. This is described in IR.92 as well as 3GPP 23.167. The UE at attach to LTE NW will provide information if the attach type (in normal/limited mode) is for Emergency. The NW will also indicate if Emergency Service is supported.

IR.92 and 3GPP TS specifies that the network can reject an emergency call with an indication with a proposed UE action. This is an 380 (Alternative Service) response with an XML body indicating that the UE should perform either a CS emergency call. This is returned if IMS emergency calls are not supported or not allowed according to an operator policy.

Unauthenticated emergency call is currently not supported end-to-end due to limitations in EPG (PGW). It is therefore recommended to use fallback to CS for networks using EPG and requiring unauthenticated emergency calls.

Further details on VoLTE emergency call can be found in section 4.1.7. SR-VCC emergency call will be supported in the future release.

2.8 Network provided Location (NetLoc)

Network provided location to IMS is to provide a trusted network determined location and time zone information to IMS from packet or CS core. Main use cases for the location and time zone include Charging, LI, Data retention, and basic location services.


10 (47)




Ericsson end to end solution in this release can provide the functionality to fetch and use location information by querying the HSS. The HSS retrieves the location either from MME when the user is on LTE access or from the MSC in case the user is on 2G/3G access.

Further details on NetLoc can be found in section 4.1.8.

3 Ericsson VoLTE end-to-end solution outline

This chapter describes complete Ericsson end-to-end solution architecture with the different Ericsson products.

3.1 Ericsson VoLTE end-to-end solution architecture

Figure 5 shows different Ericsson products and the network functions performed by the products. Some of the functions can be collocated in the same physical node and/or can be implemented by the same product. Ericsson has a responsibility to validate and test this reference architecture. The next sections offer a description of the different functions.

S1-U S5 Gm/SGi

Mw

Dx/Cx

Rx

Gx

S6a

S1-MME

S4/S11

LTE-Uu

ISUP

Mg

Mn

Mb CS

SGSN-MME

UE RBS 6000(eNB)

HSS(SLF)

EPG (SGW)

EPG (PGW)

SAPC(PCRF)

SBG(P-CSCF)

CSCF (S-I-E-CSCF/

BGCF)

MGCF

MRS (BGF/TrGW/MRFP/ATGW/MGW)

Iq

AFG(AP)

Ut/SGi

MTAS(MMTel ASSCC AS)

Dh/Sh

ISC/Ma

Ut

Mp

SBG(IBCF)

Ix

Izi

IciMx

IPworks(ENUM)

ENUM

HLR

Gr

MAP

D

Mg

Gs/SGs/Sv

RBS 6000(NB)

RNC/BSC

Uu/Um

Iub/Abis

IuCS/A

IuPS/Gb/A

EMeIP SM GW

D MAP

ISC

Mb

Zh/Zx

Gn

MSSMb/CS

CUDB

LDAP

LDAP

Camel

Figure 5. Ericsson VoLTE deployment architecture overview


11 (47)




3.2 Long Term Evolution Radio Access Network (LTE RAN)

The E-UTRAN consists of one or many eNBs. The eNB is an enhanced NodeB that provides the LTE air interface to the UEs. The eNB includes most of the 3GPP Release 6 RNC functionalities. This means that the eNB terminates the user plane (PDCP/RLC/MAC/L1) and control plane (RRC) protocols and that the eNB amongst other things performs radio resource management and intra-LTE mobility for the evolved access system. At the S1 interface towards the EPC the eNB terminates the control plane (S1AP) and the user plane (GTP-U).

Ericsson Product: LTE RAN

3.3 Evolved Packet Core (EPC)

• MME

The MME is a control plane node. It is responsible for idle mode UE tracking and paging procedures. The MME is involved in the EPS bearer activation/modification/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving CN node relocation, as well as PGW selection. It is responsible for authenticating the user by interacting with the HSS. During attach and tracking area update, the MME provide the UE with information whether voice over IMS (LTE) can be used in the tracking area list.

The NAS signaling terminates at the MME and it is responsible for generation and allocation of temporary identities to UEs. It checks the authorization of the UE to camp on the service provider’s PLMN and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks. MME handles interfaces towards the MSC such as SGs for CSFB and SMS over SGs, and the Sv interface for SRVCC.

Ericsson Product: SGSN-MME

• SGW

The SGW routes and forwards the IP packets, while also acting as the mobility anchor for the user plane flow during inter-eNB handovers. It also acts as the anchor for mobility between LTE and other 3GPP technologies (2G/3G systems using S4). For idle state UEs, the SGW terminates the DL data path and triggers paging when DL data arrives for the UE.

Ericsson Product: Evolved Packet Gateway (EPG)

• PGW

http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20469&path=%5cNavigation%20Root%5cProductRoot999%5cProductCatagory006&catalogs=Global,&language=English

http://prodcat.ericsson.se/frontend/category.action?code=1/FGB%20101%20049&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory004%5cFGB%20101%20256&catalogs=Global,&language=English



12 (47)




The PGW is the gateway which terminates the SGi interface. The PGW provides connectivity to the UE to external packet data networks by being the point of exit and entry of traffic for the UEs. The PGW provides IP addresses to the UEs as well as optional IP addresses to P-CSCFs and DNS servers. It also performs policy and QoS enforcement, bearer binding and packet filtering for each user in conjunction with the PCRF through the Gx interface. Charging support and CDR generation are also tasks of the PGW, although mainly useful for statistics in a VoLTE scenario where charging is performed on the IMS level. Another key role of the PGW is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as CDMA EVDO. A UE may have simultaneous connectivity with more than one PGW for accessing multiple PDNs.

Ericsson Product: Evolved Packet Gateway (EPG)

The Ericsson PGW/SGW product exists on two platforms:

- EPG-M, based on GGSN on the Juniper platform

- EPG-S, based on the SSR platform

• PCRF

The PCRF supports policy control decisions and flow based charging control functionalities. Policy Control is the process whereby the PCRF indicates to the PCEF (in PDN GW) how to control the EPS bearer. A policy in this context is the information that is going to be installed in the PCEF to allow the enforcement of the required services.

Ericsson Product: Service Aware Policy Controller (SAPC)

3.4 IP Multimedia Subsystem (IMS)

• MTAS

- MMTel AS

MMTel AS is the application server for IMS based multimedia telephony (MMTel).

The main use case of that type of communication service is Multi-Media Telephony (MMTel), where the MMTel AS provides the basic communication services as well as MMTel specific supplementary services (3GPP 22.173).

MMTel AS supports both basic calls and various telephony supplementary services in a multimedia context. MMTel AS supports the MMTel Supplementary Services as defined in IR.92.


http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20428&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory004%5cFGB%20101%20256&catalogs=Global,&language=English


13 (47)




MMtel AS has an integrated MRFC but does also support an external MRFC. MMtel AS controls MRFP via MRFC (internal or external) for announcements and voice/video conferencing.

MMTel AS is also the prime source of charging information in MMTel.

- SCC AS

The IMS Service Centralization and Continuity Application Server (SCC-AS) is an application server involved in SRVCC and IMS Service Centralization (ICS) procedures. ICS procedure enables the use of IMS as the single telephony service engine for UEs regardless of access technology used, PS access or 2G/3G CS access.

SRVCC procedure enables for the transfer of ongoing sessions for single radio UEs when the UE moves from LTE PS to 2G/3G CS coverage.

One important function of the SCC-AS is terminating access domain selection (T-ADS). This function makes it possible for the IMS system to route the call to the UE when the UE is in 2G/3G CS coverage.

SCC AS supports offline charging and it follows the same principles as in MMTel AS.

ICS do exist in different variants but the only variant that is discussed in this document is the so-called ICS Mg variant. This variant does require the deployment of an SCC-AS but do not require any enhancements in the MSC-S and the UE.

NOTE: The SCC-AS is also a key component in the SR-VCC solution, see section 4.1.5.

Ericsson Product: Multimedia Telephony Application Server (MTAS)

• CSCF

CSCF plays a central role for SIP originating and terminating call session control for communication services in IMS networks. It enforces the service authorization based on user profile settings, allowing multi-activation of applications. CSCF consists of:

- I-CSCF

The I-CSCF is the contact point within an operator's network for all connections destined to a user of that network operator.

- S-CSCF



14 (47)




The S-CSCF conforms to 3GPP TS 24.229 and performs the session control services for the UE. It maintains a session state for support of the services.

- E-CSCF

The E-CSCF handles emergency calls in a standardized way.

- BGCF

The BGCF is used to select an Outgoing Gateway for a SIP request addressed to a telephone. It manages the establishment of IMS-session across domains with e.g. breakout to PLMN/POTS when necessary.

- BCF

The BCF gives the possibility for users connected to other networks to execute originating IMS services.

In addition, the P-CSCF is used to access IMS from the UE, and is implemented in the Session Border Gateway (see Section 3.4, SBG).

Ericsson Product: Call Session Control Function (CSCF)

• SBG

SBG is an IP-IP Gateway. The SBG manages sessions (signalling and media) to ensure Security, Quality of Service, Service Level Agreements, NAT/FW traversal and other critical functions for real time IP sessions like VoIP and IP Multimedia Applications.

The SBG acts in the following roles:

- IBCF

The IBCF is located at the border of an operator's IMS core network and foreign networks. The IBCF provides network security, connectivity, and quality-of-service assurance for the operator’s core network.

- P-CSCF

The P-CSCF is the UE SIP point of access towards IMS, supporting the SIP Access Network Interface, sometimes referred to as the User-to-Network Interface (UNI), placed between the user and the IMS network. The P CSCF hides the internal IMS topology from the UE; P CSCF manages sessions (signaling and media) to ensure Security, Quality of Service, Service Level Agreements, NAT/FW traversal and other critical functions for real time IP sessions like VoIP and IP Multimedia Applications.



15 (47)




The P CSCF forwards the SIP messages received from the UE to an I-CSCF, E-CSCF or S-CSCF (and vice versa).

The P-CSCF supports the ATCF which controls the ATGW. The ATCF receives the SRVCC-related information bound to the registration with information in the SIP MESSAGE request. The SRVCC-related information is stored in ATCF and is used later during the SRVCC access transfer procedures.

Ericsson Product: Session Border Gateway (SBG)

• MRS

- TrGW

TrGW is a packet-to-packet gateway for user plane media traffic. It provides the interface between two IP-transport domains. The TrGW performs both policy enforcement functions and NA(P)T functions under the control of the IBCF.

The TrGW implements the IMS Mb media interface between the IMS Core and other Voice over IP networks.

BGF can act as a TrGW (a.k.a. I-BGF) and provides media anchoring when instructed by the IBCF. The BGF provides security control for the IP based media streams passing through the network borders. The Border Gateway Function feature ensures network security for media streams on the user plane.

- MRFP

The MRFP is a media plane node used to mix and process media streams. The MRFP is controlled via H.248 by an MRFC.

The Content Sharing feature in MRFP provides a service that allows sharing content between participants in a video conference.

The MRFP supports NRBT which provides a service that allows the Calling Party to play different Ring Back Tones depending whether terminating subscriber is located in terminating subscriber's home network or is roaming. When the call is terminating to the subscriber in the home network, a special tone (TLEC tone) is played before the actual RBT. This provides the caller an ability to distinguish call price. The service is for the originating caller and the mechanism to play the tones is triggered from the terminating side.

- ATGW

ATGW feature provides media anchoring for a VoLTE call to lower the voice interruption delay during the SRVCC handover between LTE and circuit switched 2G/3G mobile networks.



16 (47)




The ATGW implements the IMS Mb media interfaces between the UE and the IMS core. The ATGW is controlled by the P CSCF.

BGF acts as an ATGW and provides media anchoring when instructed by the P CSCF which performs the ATCF. It saves signaling time, since no interaction with the remote end is needed, and accelerates the handover process.

- MGW

The MGW implements the gateway function between the Voice over IP and the PSTN/PLMN networks. The MGw supports the IP and TDM transport bearer types for payload transport and for signaling. The MGW is controlled by the MGCF.

Towards IMS the MGW supports the Mb interface including transport of voice on RTP and support of RTCP. The supported RTP profiles enable connections using a range of different codec e.g. AMR-NB, EFR, G.729 and G.711. Also there is support for a RTP profile to carry DTMF.

The MGW also includes the inter-working functionality for video calls.

Ericsson Product: Media Resource System (MRS)

• IP-SM-GW

The IP-SM-GW acts as an IMS application server for the SMS over IP service. The IP-SM-GW is interfaced over the ISC interface towards the IMS core. The role of the IP-SM-GW is to provide the protocol inter-working (SIP MAP) for delivery of SMS between the IMS UE and the SMS-C.

• AFG

The AFG provides the Aggregation Proxy (or Authentication Proxy) (AP) provides a point of access to the IMS network for self-management of the subscriber’s services and for management of subscriber information.

Ericsson Product: Authentication Federation Gateway (AFG)

3.5 Diameter Signaling Controller (DSC)

The Diameter Signaling Controller (DSC) is the key network component to secure and centralize Diameter communication and to increase the operation efficiency and reliability of the internal Diameter signaling network. The DSC removes the need to have a full mesh of connectivity between all Diameter peers.


http://prodcat.ericsson.se/frontend/product.action?code=FGC%20101%202154&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory001%5cFGB%20101%20148%5cFGB%20101%20623&catalogs=Global,&language=English


17 (47)




For VoLTE, the DSC provides in particular the Diameter Routing Agent (DRA) functionality for the Gx and Rx interfaces. This is in practice providing the possibility to scale the PGW, PCRF, and P-CSCF nodes independently of each other. The DRA ensures that the different policy control sessions for a particular user connection (either from PGW or P-CSCF) are routed to the same PCRF instance, assuming there are several PCRFs deployed.

Ericsson Product: Diameter Signaling Controller (DSC)

3.6 Mobile CS Core

The Mobile Softswitch (MSS) consists of the control plane layer implemented in the MSC and the user plane layer implemented in the M-MGw.

The MSC main functions are:

• Serve 2G or 3G mobile subscribers or both at the same time.

• Connect to the MME by the SGs-interface and/or Sv-Interface in the PS domain.

• Call routing inside PLMN through the BICC and ISUP signaling.

• Gateway between PLMN and external networks using BICC, ISUP and SIP-I signaling.

• Control M-MGWs (Mc-Interface) using the Gateway Control Protocol H.248.

Ericsson products:

• GSM/WCDMA: Mobile Switching

• CDMA: CDMA voice core

3.7 User and Data Management (UDM)

• HSSSLF

The HSS provides the subscription management functionality for multi-access and multi-domains of an all-IP network environment. HSS is:

- The network subscription server for the IMS system, managing IMS subscription, IMS user identification handling, authentication, and access authorization to the IMS network.

- The network subscription server for the EPC network and handles the user across 2G/3G and LTE accesses as well as LTE and non-3GPP accesses.

http://prodcat.ericsson.se/frontend/category.action?language=English&catalogs=Global,&code=FGB%20101%200123&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory002%5cFGB%20101%200191

http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20189&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory002&catalogs=Global,&language=English

http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20719&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory002&catalogs=Global,&language=English


18 (47)




Important is that having separate HSSes for IMS and EPC is not recommended because of the following reasons.

- There is not standard interface between different domains, hence authentication can not be handled in one common place which might cause authentication failure.

- IMS domain is using IMPUs and IMPIs, CS/PS domain are using IMSIs and MSISDNs. There is nothing prevents from using different numbers/identities in the different domains.

The SLF provides an operator with the capability of scaling the HSS. The SLF is used when more than one HSS is used in the home network.

• HLR

The HLR provides the subscription and mobility management functionality for GSM/WCDMA CS access networks. Additionally HLR supports inter-working with SMS-C and SMS Home route functionality as defined in 3GPP TS 23.040.

Ericsson products:

- Monolithic:

- Home Subscriber Stage / Server Locator Function (HSS/SLF)

- Home Location Register (HLR)

- Data Layered:

- Home Location Register Front End (HLR-FE)

- Home Subscriber Stage Front End (HSS-FE)

- Customer User Database (CUDB)

• ENUM/DNS

The DNS/ENUM server and plays a central role for the DNS addressing resolution of IMS related domain names as well as users public addresses in the IMS network. It also supports the resolution of number portability legislative rules for telephony numbering identity through inter-working with existing portability databases residing in mobile and wire-line domains.

Ericsson Products: IPworks








19 (47)




3.8 Other Ericsson product

• MPS

The MPS provides the RDF/LDR function to route the emergency call towards the PSAP (Emergency Center) and supports the location push and pull.

Ericsson Products: Mobile Positioning System (MPS)

• OSS-RC

The OSS-RC provides configuration management, fault management and performance management generally handled on node level.

Ericsson Products: OSS-RC

• ENIQ

ENIQ event and ENIQ statistics provides VoLTE related end-to-end KPI based on node provided performance counters.

Ericsson Products: Ericsson Network IQ Events (ENIQ Events)

Ericsson Products: Ericsson Network IQ Statistics (ENIQ Statistics)

• EMA

The EMA provides subscriber provisioning functionality towards VoLTE nodes and integrated with Customer Activation System (CAS).

Ericsson Products: Multi Activation (EMA)

• MM

The MM provides Charging Gateway Function (CGF) and Charging Data Function (CDF) functionalities to generate the CDR records toward the customer’s Business Support System. The CGF functionality is provided by component called MM-DCF (MM Data Collecting Function) and the CDF functionality is provided by MM-FE (MM File and Event).

Ericsson Products: Multi Mediation (MM)

3.9 Device

IR.92 was specifically developed in order to specify a clear UNI between device and network. This is important to secure that any VoLTE device/implementation can be used in any network in order to support global device eco-system and roaming support.


http://prodcat.ericsson.se/frontend/category.action?language=English&catalogs=Global,&code=FGB%20101%200150&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory005%5cFGB%20101%200382%5cFGB%20101%200164%5cFGB%20101%200148



http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20622&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory005%5cFGB%20101%200162%5cFGB%20101%200138&catalogs=Global,&language=English

http://prodcat.ericsson.se/frontend/category.action?code=FGB%20101%20630&path=%5cNavigation%20Root%5cProductRoot999%5cProductCategory005%5cFGB%20101%20146%5cFGB%20101%200146&catalogs=Global,&language=English


20 (47)




Ericsson VoLTE end-to-end only considers devices with tightly integrated client in order to guarantee the QoS required in public telephony service.

The device implementation will therefore mirror all the network layers in the device. LTE radio, IP packet handling, IMS stack and MMTel service needs to be represented in the device in order to be IR.92 compliant and provide necessary QoS, as depicted in Figure 6 below.

UNI

UNI

UNI

UNI

EPC

IMS

LTE

MMTel

UNI

UNI

UNI

UNI

EPCEPCEPC

IMSIMSIMS

LTELTELTE

MMTelMMTelMMTel

Figure 6. VoLTE device implementation

4 VoLTE end to end aspects

4.1 Functional aspects

4.1.1 Conversational voice over LTE

To be able to provide a full conversational voice service over LTE, a number of functions are required to be supported by the different domains.

Figure 7 shows Ericsson end-to-end architecture and features required to guarantee a high quality conversational voice service through underlying layers.


21 (47)




S1-Ue-Uu

S1-MME S11 ISC

Mb

eNB

MMTelAS

A

Mw

P-CSCF /IMS AGw

PCRF

RxGx

HSS

Sh

Cx

S6a

S&PGW

Signaling Bearer (Default) , QCI=5

Dedicated Voice Bearer , QCI=1

I-/S-CSCF

SGI

Gm

Ut

SIP (SDP)XCAP

Voice(RTP)RTCP

MME

Bearer and APN ManagementQoS HandlingP-CSCF Discovery

QoS and Bearer Handling in LTE– Intra LTE HO– DRX in order to maximize battery liftime– RoHC– Scheduling– Admission Control– Bearer Continuity

Supplementary service management using Ut with XCAP procedures

Media Handling– AMR-NB and WB– RTCP– Jitter Buffer management

MobilityCS Interworking

Policy Control

IMS feature– Registration and Authentication– MMTel Supplementary Services

Figure 7. Ericsson end-to-end conversational voice over LTE architecture

IMS level provides the basic communication functionality, including supplementary service support. For VoLTE, the authentication mechanism has also been mandated to secure the possibility for roaming in the future. The so called IMS AKA with IPsec is used. For VoLTE service, it is also mandated to support both AMR-WB (HD voice) as well as AMR (for backward compatibility with existing CS only phones).

For VoLTE, the use of so called pre-condition support is highly recommended to use. Pre-condition usage secure that resources for the voice and video calls are available before the call can be connected through. This avoids things such as media clipping and more important ghost ringing, i.e., that the called party picks up the call but as there are no resources available, no media can be sent end-to-end, and as a result the parties cannot communicate. Ghost ringing can be very frequent during high load, which can I addition cause additional load on an already loaded network. By using pre-conditions, the ghost ringing is avoided, and there is no risk to increase the load on an already overloaded network.

The Policy Control and Charging (PCC) architecture is mandated to be used to dynamically setup resources in evolved packet core and radio for any voice and video session. The dynamic PCC is mandated to secure that the high quality voice / video bearers are setup when required, and freed up when not required.

The Evolved Packet Core system also provides additional functionality for IMS APN management, Voice indication to UE, QoS handling, and P-CSCF discovery. Note that a separate APN is required for IMS, and it is highly recommended to use a special APN also for self management traffic (XCAP). EPC also provide additional functionality for e.g., SRVCC, Access Domain Selection, and CSFB.


22 (47)




The LTE radio network provides a number of features to secure the quality of the voice and video sessions. QoS aware Scheduling and admission control are key functions to provide quality for the media using the Guaranteed Bit Rate (GBR) bearers. The Robust header compression (RoHC) reduces the size of the voice packets, which is also important to improve the performance at cell edge. The RLC UM feature is additionally used to reduce need for retransmissions of voice traffic and reduce delay. To improve battery saving, the service specific DRX functionality is can also be provided.

In addition to the IR.92 mandated features, LTE provides further functionality to guarantee the quality of the voice and video traffic. In particular, Dynamic QoS modification is required to ensure that the session can be modified during the call setup as well as during the call. The Delay-Based Scheduling and Grant Estimation can provide a better utilization of resources, and by doing so increase the mobile broadband throughput at high VoLTE load and increased VoLTE cell-edge performance at high VoLTE load. TTI Bundling is a feature that can be activated to provide better performance at cell-edge. Finally, SRVCC capabilities provide the possibility to handover users to 2G/3G.

4.1.1.1 LTE RAN

This section describes the LTE RAN aspects for realizing voice over LTE services. Figure 8 shows LTE RAN and the interfaces between the eNBs and EPC and UEs as well as interface between eNBs.

MME

e-Uu

A

LTE

eNodeB

S11

S1-U

S1-MME

S&PGW

UE

e-Uu

eNodeB

S1-U

X2

MME

e-Uu

A

LTE

eNodeB

S11

S1-U

S1-MME

S&PGW

UE

e-Uu

eNodeB

S1-U

X2

Figure 8. LTE RAN architecture

• Intra LTE HO

The intra LTE HO is carried out over the X2 interface, if this is present, or if there is no connection between the eNBs, over the S1 interface, shown in Figure 8.


23 (47)




X2 handover uses partly different concepts than previous systems. The involved eNBs starts by agreeing about the handover then the UE is moved to the new cell. When the UE is safely locked to the new cell, the MME is notified that a new S1-UP connection should be established. During the time the UE moves to the new cell until the new S1-UP is established the remaining data from source eNB and new data coming on old S1-UP are forwarded over X2-UP.If not X2 HO is possible a S1 handover can be done instead. The S1 HO uses the MME to transfer HO messages.

At S1-based handover, packet forwarding can take place either directly from the source eNodeB to the target eNodeB.

• DRX

Discontinuous reception (DRX) feature is essential to provide longer battery time with LTE handsets for VoLTE services. Due to the low TTI (transmission time interval) for voice packets over LTE, the receivers in the VoLTE UEs will not need to be on during the whole VoLTE voice session

TTI Bundling is supported as a way to improve cell edge performance in the UL. Four TTIs will be used to fit the VoIP packet, which gives 14% header overhead while over 40% for normal RLC segmentation making it possible to transmit more payload data bits. It also means more power is available per data bit. A cell edge gain of 2-3 dB is expected according to simulations.

Figure 9. DRX functionality for battery savings

DRX is a licensed feature in the eNB and the operator will be able to turn this feature on or off.

An optimal DRX configuration setting must be considered to achieve good battery savings in the UE, during a VoLTE voice service.


24 (47)




• RoHC

The RTP/UDP/IP header is a large part of the MMTel voice packet. When using IPv4, the size of the RTP/UDP/IP headers is 40 bytes (60 bytes with IPv6) while the voice frame for AMR 12.2 is only 32 bytes (including the AMR payload format overhead). Therefore there are large gains in compressing the RTP/UDP/IP headers, especially if the voice part of the total traffic mix is significant.

With Robust Header Compression, RoHC, the RTP/UDP/IP headers may be compressed down to 1-3 bytes, where IPv6 always needs a minimum of 3 bytes. If the VoIP traffic becomes an important part of the uplink traffic mix, RoHC will be required to free resources for other less prioritized traffic types.

RoHC will improve uplink VoIP coverage as there is only half the number of bits to transmit for a VoIP package. VoIP quality has to be as good CS voice quality and thus the requirement on coverage for VoIP in LTE is to be comparable to CS voice coverage in WCDMA and GSM networks.

• Scheduling

The main task of the flow prioritization module is to select the radio bearers, for downlink, or radio bearer groups, for uplink, to be scheduled in the next sub frame so that the QoS requirements of all users are fulfilled. By considering different input in this prioritization process different types of scheduling strategies are supported:

- Strict priority

- Resource fair schedule

- Equal rate

- Proportional fair schedule

- Proportional fair schedule with minimum rate

- Delay based scheduling

Delay based scheduling (DBS) is suited and recommended for GBR services for which GBR = MBR and assuming that MBR is not exceeded by the sender, i.e. QCI 1-4. The DBS scheduler is tailored for voice, i.e. it’s mode of operation and parameters are optimized for voice. A backside of DBS is poor UE battery economy since DBS delays grants to the UE to transmit a packets in the UL. This time corresponds to active time in the UE, which means that no saving opportunities occur.

• Admission Control


25 (47)




Even with prioritization in the scheduler it could be tricky to fulfill the GBR requirements of the MMTel bearers in a high loaded network. Admission Control of GBR bearers will therefore be needed in order to guarantee the bit rate and thereby the quality of voice and video services, once accepted into the network.

Admission control keeps track of the GBR load on various system resources of eNB, and strives for that an admission threshold for the GBR traffic shall not be exceeded. By configuring the GBR admission threshold the operator can decide on the balance between service dropping and service blocking.

ARP, Allocation Retention Priority, is a bearer-level priority used by Admission Control when resources are limited. Based on ARP, high-priority UEs/bearers may get admitted at the expense of low-priority UEs/bearers either by access to reserved resources or by pre-emption of low-priority UEs/bearers. In addition to ARP, the establishment cause received at RRC Connection Establishment determines whether a UE shall get access to reserved resources.

• Radio Bearer Continuity

RRC Connection Re-establishment is supported, which re-establish the radio bearers for a UE the lost connection with eNB. The re-establishment procedure will benefit VoLTE service, since the call will be reconnected i.e. the user doesn’t need to re-dial. The system benefit will be reduced signaling compared with the UE needing to start over from idle state.

First re-establishment in the serving cell, when no other RRC procedure is ongoing, will be supported. Support for re-establishment in source, target and even unprepared cell is introduced.

4.1.1.2 EPC

This section describes the EPC aspects for realizing voice over LTE services. Ericsson product SAPC for PCRF functionality is part of Ericsson VoLTE end-to-end solution due to the need for QoS requirements.

The Figure 10below is showing the non-roaming EPC system architecture for LTE/VoLTE.


26 (47)




Figure 10. EPC Architecture, non-VoLTE roaming case

• Bearer and APN handling

GSMA have decided that the APN to be used for VoLTE is “IMS”, which is a well-known APN that in the future will be used also for roaming as local breakout on a PGW in the visited network. This APN can either be the default APN which is activated at Attach, or be activated in a separate PDN connection procedure which is the primary choice. (Ericsson recommendation is not to provision the IMS APN as the Default APN in HSS for the IMS subscriber. The reason is that if the UE roams to a network where the IMS APN is not allowed then the initial Attach will fail and the UE will not be able to get any connectivity, for any services, at all to the network.). When the PDN connection to the IMS APN has been established, also a default bearer is established, and this is to be used for the SIP signaling towards the P-CSCF. The UE is expected to request P-CSCF IP-addresses in the PCO field when connecting to the IMS APN,

When a voice call is to be setup, a dedicated bearer for voice with QCI1 will be setup, initiated from the P-CSCF over Rx to PCRF, and then from PCRF over Gx to PGW, and all the way through the network to the UE.

If supplementary services are to be used, these are configured using XCAP over a home-routed APN as decided by GSMA. This can either be a dedicated APN for XCAP, or another APN typically one used for internet browsing.

• QoS handling


27 (47)




The parameter ARP (containing priority levels and pre-emption flags) will be set by PCRF to appropriate values, and forwarded to PGW over Gx for dedicated bearers. The ARP parameter will just be transported through the network to eNB and it will be used in MME for admission control. When the GBR is supported, the Guaranteed Bit Rate will be equal to Maximum Bit Rate, GBR = MBR.

There is also certain support for handling of QoS in transport networks so that QoS is provided in transport networks by setting “per-hop behavior” by the Differentiated Services Code Point (DSCP) in the IP header. It is supported in the nodes to set DSCP based on QCI.

For VoLTE services, the network-initiated bearer procedure is used to provide QoS for the media components of a VoLTE session. The NW-initiated bearer procedures are triggered by the so-called dynamic PCC Rule. Dynamic PCC Rules are generated in PCRF based on the media description used for the VoLTE session and then provisioned over the Gx interface.

There are a number of VoLTE media components that are mapped into GBR or non-GBR QCIs. The operator defines the type of QCI (either GBR or non-GBR).

- MMTel service information QoS parameters mapping

The P-CSCF maps the SDP information into the format that is understood by the PCRF according to the Rx interface ((media component and media subcomponent information). The mapping is done according to the rules described in 3GPP TS 29.213.

- Mapping service information to GBR and MBR

The SDP is mapped into Rx parameters that are sent to the PCRF including the information about audio and video, each media component, as requested maximum bandwidth Uplink and Downlink, etc.

• Mobility

The mobility aspects of VoLTE services are quite important to ensure a seamless service usage experience by the end users. These aspects require introduction of a number of features and functionalities in the network and securing an end-to-end interworking for all the important use cases. The support includes mobility such as intra/inter-eNB mobility both for X2 and S1-mobility but also SGW and MME relocations.

4.1.1.3 IMS

IMS is a standardized multimedia communication infrastructure. IMS is all packet switched (IP) and uses SIP as signaling protocol.


28 (47)




• Registration and authentication

To be able to use the IMS network, a device needs to register with the IMS network. This is done using a well defined registration process, where the IMS client in the device sends registration requests to the P-CSCF. The P-CSCF address is according IR.92 provided to the device during radio attach (PCO). Authentication will normally also take place during the registration process. IR.92 specifies the use of IMS AKA for authentication.

The registration and authentication process is not new or unique for VoLTE.

• Supplementary services

GSMA IR.92 defines a subset of total MMTel supplementary services set as mandatory. Please see Table 1 below.

BAIC24.611 ACR/CB – ICBBarring of All Incoming Calls

(SMS)24.606 MWIMessage Waiting Indication

MPTY24.605 CONF Ad-Hoc Multi Party Conference

HOLD24.610 HOLD Communication HOLD

CW24.615 Comm. Waiting Communication Waiting – Terminal mode

CFB24.604 CDIV - CFBCommunication Diversion on Busy

CLIR24.607 OIR Originating Identification Restriction

24.623 XCAP over the Ut for MMTelManipulating and Configuration of MMTel over Ut

BIC-Roam24.611 ACR/CB – ICBBarring of Incoming Calls - When RoamingBOIC24.611 ACR/CB – OCBBarring of Outgoing International Calls **BAOC24.611 ACR/CB - OCBBarring of All Outgoing Calls

CFNRy24.604 CDIV - CFNRCommunication Diversion on No ReplyCFNRc24.604 CDIV - CFNRcCommunication Diversion on not Reachable

CFNRc24.604 CDIV - CFNLCommunication Diversion on not Logged inCFU24.604 CDIV - CFUCommunication Diversion* UnconditionalCoLR24.608 TIR Terminating Identification Restriction

CoLP24.608 TIP Terminating Identification PresentationCLIP24.607 OIP Originating Identification PresentationGSM equivalent3GPP MM Tel specificationSupplementary Service name

* Media (audio) or (audio AND video) is also a supported condition in CDIV ** Barring Condition International is a 3GPP R9 feature

Table 1. IR.92 (VoLTE) Supplementary services

These above services are all supported by Ericsson VoLTE end-to-end solution Please note that 3GPP MMTel standard provides more service capabilities, actual end user services as well as more supplementary services than mentioned in this chapter.

• Media plane

Ericsson VoLTE end-to-end solution supports AMR-NB and AMR-WB as stipulated by IR.92. Other codecs and transcoding is also supported in MRS

• Legacy IN service interaction


29 (47)




IN services will be replaced by service logic on modern service platforms like NGIN where the platform can avail of the rich, powerful multimedia control capabilities of IMS. However many operators still require access to their CS non-standardized Value Added Services (VAS) regardless of access, and as a result of large investments by operators in IN, VoLTE network can be extended enabling the operator to reuse legacy IN services for VoLTE subscribers.

In such situation, Ericsson recommends to introduce MTAS integrated SSF model because of the following reasons.

- CAPEX/OPEX saving: MTAS can be re-used for interworking purposes.

- Ease of supplementary service interworking: MTAS simplifies ISC chaining for service orchestration/interaction

- Less capacity/latency impact: Each time an AS (SSF) is invoked, there is a capacity and a call setup latency impact. This model can reduce the impact.

Figure 11 shows the deployment example of the introduction model.

BRoutingLogic

ISC

S-CSCF

MMTelAS

iFC

S3S2S1

SSF

SCP

CAPv4

SCP

S4

SCP

CAPv2 CAPv4

Legacy IN

MTAS SSF SSF

INVITE INVITE

A

Figure 11. MTAS integrated SSF model deployment example

4.1.2 Conversational video over LTE

A conversational video service session is an additional complement to a conversational voice session in IMS. Conversational video can be added or removed by the end user during ongoing session or it can be established together with voice at initial call establishment.


30 (47)




The 3GPP standards offer a variety of terminal, radio and core network configuration options when launching IMS voice and video services over an LTE/EPC network. Therefore, GSMA has defined IR.94 profile for conversational video. IR.94 is done as an add-on to IR.92 to define a minimum set of features to be implemented in the terminal and network for the support of conversational video calling over LTE.

4.1.2.1 GSMA IR.94 video profile

IR.94 is based on IR.92 but add the capability to use video media together with the voice media. Voice-only calls remain as profiled in IR.92.

• The same supplementary service set as in IR.92 is used

• Video media shall be possible in all call cases defined in IR.92 e.g. also in ad-hoc multi party conference and in early media

• Video media in emergency call is not part of the first version of IR.94

IR.94, as IR.92, is a profile with a minimum mandatory subset of 3GPP specifications. It is important to note that IR.94 requires that IR.92 is in place in both network and terminals, since it relies on the functionalities and services like supplementary services, supported use cases, etc.

Figure 12. GSMA IR.94 Video Profile


31 (47)




4.1.2.2 Video Telephony Client

The video client in the UE uses RTP to transport the encapsulated video frames to the receiving client. In case of impairment on the E-RAB or IP transport network the client is responsible to identify the degradation of service to take the appropriate actions by changing the codec rate. This detection can be based on measured delay, loss and jitter or early congestion notification.

To adapt to changing bearer characteristics requires E2E signaling between the clients, which could be done on the SIP interface or on the user plane level. To allow faster adaptation RTCP on the user plane interface is used. If the clients indicate for example packet or frame loss to the peer the two clients can modify the video codec to a more robust mode, trying to optimize the video quality for given conditions. RTCP is also used for synchronization of the audio and video stream, in contrast to a pure voice session where RTCP is only used at call hold.

4.1.3 CSFB

Circuit Switched Fallback (CSFB) for a UE in LTE coverage towards legacy GSM or WCDMA is specified in 3GPP 23.272.

EvolvedPacket

Core

CSFBPhone

2G/3GCS Core

LTE

SGs

CSFBPhone CALL

PAGING

WCDMA/GSMCS VoiceCS Voice

CS Voice

EvolvedPacket

Core

EvolvedPacket

Core

CSFBPhone

2G/3GCS Core

LTE

SGs

CSFBPhone CALL

PAGING

WCDMA/GSMWCDMA/GSMCS VoiceCS Voice

CS Voice

Figure 13. Circuit Switch Fallback (CSFB) principles

In CSFB, upon a voice call origination attempt or when receiving a page for CS voice (via SGs interface), the UE is moved to WCDMA/GSM and the voice is sent over one of these access networks. The page response is sent over the new RAT on the Iu or A interface. The UE will return to LTE after call completion if LTE is preferred and coverage exists.

The CSFB function is only possible to realize in areas where E-UTRAN coverage is overlapped with GSM and WCDMA coverage.

CSFB will allow retaining current roaming relationships between operators, since CS voice is still used. CSFB can also be used to handle early emergence call solution. Further details can be found in ref.[4].


32 (47)




4.1.4 ICS

Considering that most of IMS subscribers will be existing MSS subscribers that will be migrated to IMS, Ericsson VoLTE end-to-end solution promotes the use of ICS and single service engine. ICS and single service enginge secures following benefits.

• Single service experience for the end user irrespectively of access

• A user on CS access can have the same evolved service experience as on LTE

• There is no need for complex service synchronization between LTE and 2G/3G

• Simple call routing to CS avoiding the need to handle service interaction between CS and IMS

Adaptations for dual service engine needs to be handled as local adaptation.

ICS consist of the following features and affected nodes:

• Terminating Access Domain Selection (TADS): Implemented in SCC-AS on MTAS

• Terminating Service Domain Selection (T-SDS): Implemented in SCC-AS on MTAS

Figure 14 below depicts ICS architecture with the main interfaces and nodes highlighted in red.

Ericsson VoLTE end-to-end solution fully supports CAMEL based ICS (Mg interface).

BTS/NodeB MSS

MME

eNodeB

e-Uu

S1-MME

S&PGW

P-CSCF

BGF

MMTel /SCC AS

I-/S-CSCF

IBCF

TrGW

Sv/SGs

DS6a

S11

S1-U

Gm

Rx

Mb

Gx

SG

i

Iq Ix

HLR/HSS

PCRF

A

VoLTESRVCCCSFBSMSoSGs/S102

BSC/RNC

AMg/Mw/Mx

MwISC

ShCx

Mb

I2/Mg

Um/UuAbis/Iub

A/IuCS

GSM/WCDMA

LTE

BTS/NodeB MSS

MME

eNodeB

e-Uu

S1-MME

S&PGW

P-CSCF

BGF

MMTel /SCC AS

I-/S-CSCF

IBCF

TrGW

Sv/SGs

DS6a

S11

S1-U

Gm

Rx

Mb

Gx

SG

i

Iq Ix

HLR/HSS

PCRF

A

VoLTESRVCCCSFBSMSoSGs/S102

BSC/RNC

AMg/Mw/Mx

MwISC

ShCx

Mb

I2/Mg

Um/UuAbis/Iub

A/IuCS

GSM/WCDMA

LTE

Figure 14. IMS Centralized Services architecture


33 (47)




4.1.5 SR-VCC

Ericsson VoLTE end to end solution supports SR-VCC as defined in GSMA IR.64.

Ericsson VoLTE end to end supports SRVCC according to TS 23.216 [5] and provides IMS voice call continuity for the conversational QCI1 VoIP bearer from LTE to CS in WCDMA and GSM.

Figure 15 below depicts SR-VCC architecture with the main interfaces and nodes highlighted in red.

This revision of Ericsson VoLTE end-to-end solution is based on 3GPP R10 architecture, which minimizes the voice interrupt at hand over.

Moreover this revision supports one-way SR-VCC handover from LTE to WCDMA with SIP interface between MSC-S and IMS. Ongoing data sessions are reestablished after handover.

SR-VCC

SR-VCC

SR-VCC

SR-VCC

SR-VCC

SR-VCC

SR-VCC

SRVCChandover

SR-VCC

Figure 15. SRVCC architecture and impacted nodes, interfaces

SRVCC introduces the Sv interfaces between MME and anchor MSC. The new SCC AS in IMS is linked into every IMS voice call (based on triggers in HSS) as shown in Figure 15. In case of SRVCC HO the MME coordinates the HO for voice using the Sv towards the anchor MSC and for other PS bearers over S3 or Gn towards SGSN.

The anchor MSC/MGCF serves as SIP user agent for the UE when the UE is in the CS domain. It coordinated the session transfer in IMS over the Mg interface and the CS HO towards the UTRAN.

Figure 16 shows the principle steps of a session transfer (SRVCC with PSHO) of an ongoing IMS voice call to UTRAN (or DTM GERAN). The UE might have additional ongoing PS sessions.


34 (47)




4.1.5.1 SR-VCC functions and interfaces

Figure 15 above depicts also all impacted nodes and interfaces for SR-VCC

New logical functions for SRVCC (red in picture):

• SCC-AS (MTAS): SRVCC support in SCC-AS (MTAS product)

• ATGW: Access transfer Gateway functionality in MRS product

• ATCF: Access Transfer Control Functionality in SBG product

SR-VCC also requires support in the following network entities:

• MSSMME: The Sv interface for SRVCC is supported as well as needed functionality to transfer the bearers used for the IMS call towards the CS domain.

• eNodeB

• Terminal

This release of the business solution is supporting the following additional interfaces for SR-VCC compared to vanilla VoLTE:

• Sv interface between anchor MSC and MME

• SIP interface between anchor MSC and IMS

• S6a additions between MME and HSS

• Sh and Cx between HSS and IMS

4.1.5.2 SR-VCC principles

The high level principle of SR-VCC is described in Figure 16below.


35 (47)




eNodeB S&PGW

BTSNodeB

BSCRNC MSS

MME

ATGw

P-CSCFATCF

I-/S-CSCF

SCC AS MTAS

LTE

GSM / WCDMA

SRVCChandover

Home NetworkServing Network

HO request

Signaling

Voice media

1. The eNodeB decides to do SRVCC HO

2. The MME handles the SRVCC HO via the Sv interface

3a. The MSS and RAN prepares to receive a handover

3b. The MSS set up a call leg to the ATCF using the STN-SR number. And performs HO towards Access network

5. The ATGW is updated with new media destination for transferred party

6. Media is established towards UE

4. The ATCF finds the anchored call and executes session transfer

MTAS

B

A

A

Figure 16. SRVCC principles

4.1.6 SMS over LTE

4.1.6.1 SMS over SGs

SMS over SGs is specified in 3GPP TS 23.272, CSFB.

SMS

LTERAN

A

GSM/WCDMA RAN

EPC

MSC

HLR/HSS

SGs

Figure 17. SMS over SGs topology

The high level procedure for a mobile terminating SMS is summarized below.

• The UE registers with combined EPS/IMSI attach for “SMS-only”, and updates MSC and MME using combined TA/LA update procedure

• When an incoming SMS arrives to the MSC, the MSC will send a paging via SGs interface to the MME. The MME will page the UE only if the UE is in idle mode. Otherwise it will directly send a service request message to the MSC.


36 (47)




• Once the MSC receives the service request message from MME, it will send the SMS via SGs interface to the MME, which will tunnel the short message to the UE.

So the SMS is transferred via SGs to MME and tunneled to the device whilst the terminal is in LTE, avoiding the need to execute fallback to WCDMA/GSM.

A mobile originated SMS is following the same mechanisms. The UE sends the SMS to the MME, which forwards it via SGs to the MSC.

Existing roaming agreements are re-used.

4.1.6.2 SMS over IP

SMS over IP is an interworking solution that enables the delivery of SMS via the IMS.

The solution requires

SMS client that uses the IMS stack in the UE

• IP-SM-GW

• IMS Core

• HLR/HSS supporting SMS over IP with home routing support

The SMS over IP service works in the following way:

• When the SMS recipient is being registered as a SMS over IP receiver, the HLR/HSS will respond with the address to an IPSMGW. The terminating SMS-C will now route all SMS messages for that subscriber to the IP-SM-GW. (This method of handling MT-SMS is also known as SMS home routing)

• The IP-SM-GW will perform a domain selection procedure towards the HSS/HLR to figure out if the SMS shall be delivered as a SIP message or an ordinary SMS. If it is decided that the SMS is to be encapsulated in a SIP message, the encapsulation is done in IP-SM-GW.

• The SIP message containing the SMS is then routed to the end-user via the IMS. If the IMS user is in e.g. GSM coverage, the IP-SM-GW may decide to route the SMS directly to the MSC for further transport to the IMS UE.


37 (47)




Figure 18. SMS over IP topology

• When sending an SMS over IP, the SMS is formatted as a traditional SMS in the terminal and is encapsulated in a SIP message.

• The SIP message is sent to the IP-SM-GW via IMS.

The IP-SM-GW transfers the SMS between the SIP/IP stack to the MAP stack and routes the SMS to the SMS-C.

4.1.7 Emergency call

Voice over LTE emergency call is a local network service and not a subscribed service. This means that the emergency call is routed locally in the serving (visited if roaming) network towards the PSAP (emergency center). To be able to handle this, the Emergency CSCF (E-CSCF) is used to handle the local routing towards the PSAP from the serving network.

Note that for authentication and IMS registration purposes, the HSS/HLR in the home network and the I/S-CSCF in the home network are used during the emergency registration procedures. However, emergency calls do not require additional subscription information to handle the service as such.

The LRF and GMLC are used to both assist the routing of the call towards the closest PSAP as well as to allow the PSAP to request updated information of the user’s location during the emergency call.

A high level deployment overview of the Voice over LTE emergency architecture is provided inFigure 19.


38 (47)




Figure 19. VoLTE emergency deployment architecture overview

Ericsson VoLTE emergency call supports the following use cases.

• Basic VoLTE emergency call

This is an emergency call over LTE when the user is attached to the system during normal operation.

• Emergency call in limited service mode

This is an emergency call over LTE when the user is not attached to the system, such as being in an area where limited service is only provided.

• UE undetectable emergency call

This is the procedures to handle an emergency call request over LTE, but where the UE has not detected that the number it is dialing is an emergency number and therefore has not applied the emergency procedures of basic emergency call.

• Emergency Call back

To facilitate call back to the subscriber from the emergency center, the UE needs to be provisioned with a telephone number. Furthermore, the UE must be registered in IMS for normal calls (alternatively registered for CSFB).

• User Identity Requirements


39 (47)




To be able to perform an authenticated IMS emergency call, the user has to be provisioned with at least one E.164 number (TelURI) as part of the user's IMS subscription in HSS. In case of unauthenticated emergency call, the IMEI is used as the UE identifier (both by EPC and IMS).

• Access Domain Selection

Access Domain selection for emergency call is a UE capability to decide whether to perform a detectable emergency call over the LTE access or fall back to a 2G/3G CS emergency call.

• Emergency Number distribution to UE

This is to make sure the UE can detect when a specific call is an emergency call and not.

• Interactions with other services during emergency call

This is to make sure that the emergency call should not be interrupted during an ongoing emergency session.

• Mobility considerations

The use of the emergency PDN and the dedicated emergency bearers secures not only priority and quality of service of the emergency call, but also that mobility into restricted areas can take place.

In VoLTE introduction due to early deployment or regulatory requirements, fallback to CS network might be applicable in a CS co-existence scenario. Further detail functionalities, supported use cases and signaling flow can be found in [7].

Unauthenticated emergency call is currently not supported end-to-end due to limitations in EPG (PGW). It is therefore recommended to use fallback to CS for networks using EPG and requiring unauthenticated emergency calls.


40 (47)




4.1.8 NetLoc

Authorities can in today’s CS network request operators to provide lists of Calls, SMSs and other events including the cell ID of the cell where the session or SMS was sent or received as part of the data retention functionality. The authorities will not accept a degradation of information when moving to IMS. In IMS, the Cell ID can today be provided from the UE (in the PANI header). The UE retrieves its location (Cell ID) from the radio network and provides this as UPLI (UE Provided Location Information). Manipulation of the UPLI is considered complicated and therefore the UPLI can be used for example as input to services. The UPLI is however not considered as trusted by regulations. As a result, operators have started to request a network provided Cell ID that can be considered as trusted and with same service characteristic as used today in CS based networks.

Network Provided Location Information (NPLI) consists of user location and time zone of the user as described in annex E.7 of 3GPP TS 23.228 Release 11.The main applications considered for the NPLI are:

• Charging

• Data Retention

• Lawful Intercept

• Basic service usage (where latest known cell id is enough, and latest positioning is not required).

3GPP standardized two mechanisms to be able to cover these scenarios, one based on IMS requesting the location via HSS, and one based on PCC. In this revision, HSS based solution is supported.

The reference architecture of the HSS based solution is shown in Figure 19 with the impacted nodes high-lighted. The MME is used when the user camps on LTE access, while the SGSN may be used when the user camps on 2G/3G access.

As the main use case for NetLoc is for VoLTE, it will be possible to query the location either from MME (when UE is using LTE) or from MSC/CS domain (when UE is on 2G/3G). As a result, there is no strong need short term to require query from SGSN (as MSC can always be queried instead). Query of SGSN is mainly required long term for full standard compliance with 3party products (such as IP messaging products not using CS domain queries).


41 (47)




Figure 20. Reference architecture for HSS based NetLoc solution

4.1.9 Roaming in VoLTE

GSMA IR.65 proposed a model mimicking the CS Roaming, and requested 3GPP to work out the detailed architecture. Roaming Architecture for Voice over IMS with Local Breakout (RAVEL) is the 3GPP name for the work and GSMA agreed that visited network call routing is the stable architecture for VoLTE roaming.

Ericsson proposes phasing approach for the stable architecture based on the VoLTE introduction status. Figure 21shows the first step of possible VoLTE roaming phasing. In this revision, the introduced VoLTE network supports CS roaming and CSFB use cases.

In the CS roaming case, VoLTE user is roaming and attaches to VPMN in “CS-Mode”. In case that the roaming agreement exists however no Camel agreement exists, all originating services will be executed in the VPMN MSC which means that an originating dual service engine deployment exists. Users terminating service engine is in IMS (HPMN). As the user is not registered in IMS, T-ADS (SCC-AS) will direct the call to the CS domain using the MSRN (Mobile Station Roaming Number). In case that Camel agreement exists. User A’s (ICS user) call routed to the H-PLMN IMS for execution of originating IMS services using ICS Mg/Camel.

In case that the 2G/3G and LTE data only radio coverage is available when VoLTE user is roaming, the user does a combined EPS/IMSI attach (TS.23.221) to VPMN. Profile is downloaded from HSS (UDA) to MME with default APN (internet). As no PS voice available, CSFB procedures are initiated in the VPMN


42 (47)




CS Core

Fallbackfor voice

2G/3G RAN

LTE RANEvolved

Packet Core

CSFB

VPMNCS voice/ICS

HPMN

IMS(HPMN)

CS Core(GMSC/MGCF)

CS Core2G/3G RAN

VPMNCS voice/ICS

HPMN

IMS(HPMN)

CS Core(GMSC/MGCF)

Pre-VoLTE roaming - CS roaming

Pre-VoLTE roaming – Data roaming with CSFB

Figure 21. Phasing approach for VoLTE roaming introduction

4.2 Non-Functional aspect

4.2.1 Operation and Maintenance

All Ericsson products constituting the VoLTE end-to-end solution support Performance management (PM), Fault management (PM) and Configuration management (CM) based on IMS 14A release together with OSS-RC 14A. The end-to-end CM guideline and the end-to-end trouble shooting guideline are provided in a part of VoLTE end-to-end CAL Store.

Figure 22 depicts recommended PM solution in Ericsson VoLTE end-to end solution.

ENIQ Events

Data sources (events)3G GPEH4G CELL TRACECS CDRSGSN-MME EBM

SGSNSGSNSGSN- MME

EPGEPGEPG

RNCRNCRAN

SGSNSGSNMSS

4G

ENIQ Statistics

RNCRNCRAN

2G

SGSNSGSNIMS

CS Core PS Core

LTE Events Stats (Counters)

Data sources (Stats)Counter files

PS Core IMS

OSS-RC

RNCRNCRAN

3G

Counter files

Counter filesCounter and event files

Counter filesevent files

Counter files

Counter and event files

Counter files

Event StreamEvent files Event files Counter files

EMM Topology

EMM: Filtering and mediation of charging data

OSS-RC: Initiation and mediation of PM data

Topology

Figure 22. Recommended PM solution in VoLTE


43 (47)




4.2.2 QoS and Performance

The high level goal for VoLTE over LTE/EPC is that the speech quality should be equal or better than speech quality of the legacy 2G/3G CS telephony service.

From the VoLTE services QoS perspective, the system KPIs listed in the section 4.2.1 must be considered. These KPIs have effects on the solution from all areas; LTE RAN, EPC, IMS domain as well as the transport network and the VoLTE UE itself. Following descriptions show specific area where have specific target values and recommendations in the system.

• Session setup time

The target for call setup time is dependent on the state the UE is in.

For LTE<->LTE calls, having both UEs in connected state, the target call setup time to be below under normal network operating conditions is <2.5 sec. Having both UEs is idle state, the target is < 4 sec. Real measurements in lab and field test shows better figures.

For LTE<->PSTN calls, the target setup time is in between the targets provided for LTE<->LTE calls above.

• Speech quality

The only new challenge, which is a significant challenge, with VoIP services is to manage the large amount of delay jitter introduced in the LTE radio network. The target for the speech path delay perceived by the end-user is the same as for CS voice, but the new component Jitter Buffer Manager in the decoding node (the UE and the media Gw in the network) has to cope with this in order to deliver a fixed end-to-end speech path delay. All other speech quality component are the same for VoLTE compared to CS voice.

When assuming the same speech quality functions in VoLTE over LTE/EPC as in CS, then securing that the speech quality is on par with the CS service in particular focus is that the speech path delay, frame erasure rate and handover performance must meet certain performance metrics.

- Speech codec recommendations

The VoLTE IR.92 document stipulates the support of AMR Narrowband and AMR Wideband. The Ericsson recommendation is that calls between two LTE terminals should encode the speech using the AMR Wideband 12.65 kbps mode.

- Speech path delay (SPD)


44 (47)




The targeted speech path delay end-to-end (mouth to ear) between two VoLTE terminals is calculated in the VoLTE (VoLTE) is to be <220 ms (20 ms DRX-cycle), provided that the UE meets its delay budget in ITU-T.

- Frame erasure ratio (FER)

The target is that the frame erasure ratio should be less than 1% per call type. Low FER and low SPD are tightly correlated with good experienced voice quality.

- Speech interruption time at intra LTE HO

The radio transport interruption time (at L2) in a LTE intra HO (X2 handover) will be around 45 ms in normal network operating radio conditions. With Contention Free HO, a random access preamble is reserved in target cell; the interruption time could be even shorter (down to 30 ms). Contention Free HO is included in L12A. It’s a licensed feature and may not be a part of every LTE RAN.

The VoLTE characteristics requirement specifications requires a HO performance of <50 ms speech interruption time in 90 percent of the cases.

Hence if the speech interruption time is equal to the 45 ms radio transport interruption time at HO (or 30 ms if Contention Free HO is supported), the solution will meet the requirements (at least for X2 handovers).

In reality the speech interruption time is most probable less than the interruption of the radio transport, making it even more probable that the solution meets the requirements. This is due to buffering of voice frames in the terminal. This means that there will typically be a few speech codec frames buffered in the terminal when the radio transport interrupts due to the HO. These frames are played out covering some or all of the radio transport interruption time until new packets with speech codec frames is received from the new eNB.

• Video quality

The high level goal for VoLTE is that the video quality should be significantly better than the video quality in the legacy 3G CS video telephony service.

- Video codec recommendations

The recommended video codec for Conversational Video service in VoLTE is H.264. It is recommended to use a low complexity profile (baseline profile level) of that video codec. The frame rate should be ≥25 Hz.


45 (47)




Given a video format of 480p, the widescreen format of VGA, a video bitrate of ≥500 kbps is the target for high quality video calling over LTE for smartphones. If a higher video format is used, significantly higher video bitrates are required.

- Video path delay

The target for video path delay end-to-end between two VoLTE terminals with both voice and conversational video support is calculated in the VoLTE (VoLTE) is estimated to be <400 ms. Of this delay roughly half of it is dedicated to handle the delay jitter originated from scheduling and retransmissions in LTE RAN.

In order to have lip-sync, the audio shall not be more than 25 ms ahead of the video, and the video shall not be more 40 ms ahead of the audio. Adjustments of the lip-sync is made in the decoding node (the UE).

- Frame erasure ratio

The measured time between visible degradations for the end user should be once per 20 seconds for video telephony (maybe longer for “premium” video conferencing services”. Given one packet per frame and a frame rate of 25 Hz, that would correspond to a frame erasure ratio of 0.2% end-to-end.

Unlike for speech, most common is to split a video frame over two RTP packets. Hence when looking at the Packet Loss Ratio (PLR), the target is to be <0.1%

• SR-VCC Performance

For the CS Co-existence scenarios with VoLTE, there are expected performance targets to fulfill to secure a seamless VoLTE service for VoLTE users in the commercial LTE/EPC networks.

SR-VCC Hand-over Speech Interruption Time < 300 ms and the Speech quality before and after HO is the same for the same codec.

5 Terms and abbreviations

5.1 Terminology Allocation Retention Priority (ARP) ARP defines the importance of an IP-

CAN bearer compared to other IP-CAN bearers. It is used in case of congestion, to determine which Radio Access Bearer (RAB) should be ”killed” first.

Maximum Bit Rate (MBR) The MBR defines the limit in the delivered bit rate (kbps) that the bearer


46 (47)




guarantees to the subscriber for the services running on it.

Guaranteed Bit Rate (GBR) The GBR defines the bit rate (kbps) that the bearer guarantees to the subscriber for the services running on it.

PCC rules A policy sent from PCRF to PDN Gw for an EPS bearer including : QCI/ARP(/MBR/GBR)

QoS Class Identifier (QCI) A scalar pointing to a certain node pre-configuration and packet forwarding treatment

Anchor MSC The MSC supporting the Sv interface to an MME. The MSC can be in a pool configuration. It requires all configurations to reach the target RNC/BSC. This target RAN can be directly connected or can be reached through a target MSC using inter MSC HO procedures.

Singe Radio The UE can only transmit or receive either in LTE or GERAN/UTRAN

Target MSC The target MSC is the node serving the target RAN. It does not require supporting the Sv interface. Only new neighbour MSC relations might be needed for inter MSC HO from the anchor MSC

5.2 Abbreviations

For VoLTE end-to-end related abbreviations, please refer to the VoLTE abbreviation Lists [8].

6 References

Please refer Mobile Telephony Evolution with VoLTE product catalogue and VoLTE E2E Solution CAL Store as a generic reference of this document.

6.1 Other documents

[1] Ericsson Mobile Telephony Evolution with VoLTE, release plan; 1/224 01-FGD 101 073 Uen

[2] Ericsson VoLTE commercial presentation; 20/221 09-FGD 101 073 Uen

[3] Ericsson VoLTE Business Guide; 3/224 10-FGD 101 073


http://calstore.internal.ericsson.com/alexserv?li=EN/LZN7060047R2A

http://gask2web.ericsson.se/pub/get?docno=1/22401-fgd101073&lang=en&format=*source*&highestfree=y

http://gask2web.ericsson.se/pub/get?docno=20/22109-fgd101073&lang=en&format=*source*&highestfree=y

http://gask2web.ericsson.se/pub/get?docno=3/22410-fgd101073&lang=en&format=pdfv1r5&highestfree=y


47 (47)




[4] CSFB and SMS over SG Solution Guideline. Doc: 1/221 12-FGD 101 073 Uen

[5] TS 23.216

[6] System Feature Description VoLTE 2/22104-HSC12034 Uen

[7] System Feature Description Emergency 1/22104-HSC12034 Uen

[8] VoLTE abbreviation Lists 1/0033-HSC12034 Uen

6.2 Features

Please refer to the following VoLTE related feature collections in feature store

[9] VoLTE Communication Enrichment feature collection

[10] VoLTE CS Co-Existence feature collection

[11] VoLTE Regulatory

[12] VoLTE Barebone

http://gask2web.ericsson.se/pub/picov/get?DocNo=22112-FGD101073&Lang=EN&Format=*Source*&HighestFree=Y

http://erilink.ericsson.se/eridoc/erl/objectId/09004cff878a9cb1?docno=1/0033-HSC12034Uen&action=current&format=msw8

http://featurestore.lmera.ericsson.se/fs/feature_collections/view/83




Documents

VoLTE End to End Soln Guide