VoLTE (4) - IMS "One Voice" Profile - One Voice Initiative

VoLTE (4) - IMS "One Voice" Profile - One Voice Initiative

1). One Voice Initiative - IMS “One Voice” Profile

§ As LTE is a pure IP technology, traditional voice and SMS services must be implemented over the packet network.

§ The One Voice Initiative aims to achieve an industry agreement on a harmonized way to implement voice and SMS over LTE based on existing standards.

§ One Voice Initiative uses current open standards to define the minimum mandatory set of functionality for interoperable IMS-based voice & SMS in LTE.

§ A technical profile document was created, covering the device (UE), the LTE Access Network, the Evolved Packet Core Network, and the IP Multimedia Subsystem

§ This “Voice over IMS Profile” specification has been produced by AT&T, Orange, Telefonica, TeliaSonera, Verizon, Vodafone, Alcatel-Lucent, Ericsson, Nokia Siemens Networks, Nokia, Samsung and Sony Ericsson.

§ The One Voice Initiative aims to achieve an industry agreement on a harmonized way to implement voice and SMS over LTE based on existing standards -“Voice over IMS Profile” specification

§ This solution envisaged for the mid and long term is to introduce network operator based voice services in LTE with the IMS.

Note: For facilitating session transfer (SRVCC) of the voice component from LTE to the CS domain, the IMS multimedia telephony sessions needs to be anchored in the IMS

2). IMS “One Voice” Profile

Pros:

§ Most feature rich

§ Enables Real time Rich Media - fully IP based platform for rich media communication

§ Doesn’t require MSC support

§ Handing-over ongoing IMS based voice calls to circuit switched networks via SRVCC (between IMS over PS access and CS access for calls is anchored in IMS)

§ Convergence via ICS – IMS based on the popular SIP is widely used in fixed line IP based networks for Voice over IP

Cons:

§ Complexity - significant complexity of the system, and it will still take several years before large scale commercial IMS deployments, and features to handle wireless specific issues such as unreliable radio connections, application servers for external application development, international roaming, scalability, security, etc.

§ IMS Market timing

§ SRVCC provides the ability to transition a voice call from the VoIP/IMS packet domain to the legacy circuit domain, but the ability to transition from the circuit domain to the packet domain is not addressed in the current generation (R8) of LTE standards

§ Limited LTE Coverage if only hotspots at the initial phase

§ SRVCC-capable mobile initiated in a voice call determines that it is moving away from LTE coverage

§ ICS-capable UE if ICS is utilized

3). The scope of the profile includes the following aspects:

§ IMS basic capabilities and voice including supplementary services

§ Real-time media negotiation, transport and codecs

§ LTE radio and evolved packet core capabilities

§ Functionality that is relevant across the protocol stack and subsystems

4). Voice over IMS Profile – Network Architecture:

§ Network Architecture http://docs.google.com/View?id=ddh56dhg_299c2gzj5gv

5). Supplementary Services (SS) overview

§ Supplementary services shall be supported as defined as part of 3GPP MMTel

§ It is up to the operator to enable these services.

§ UE and TAS shall support the supplementary services listed below.

§ Originating Identification Presentation

§ Terminating Identification Presentation

§ Originating Identification Restriction

§ Terminating Identification Restriction

§ Communication Diversion Unconditional

§ Communication Diversion on not Logged

§ Communication Diversion on Busy

§ Communication Diversion on not Reachable

§ Communication Diversion on No Reply

§ Barring of All Incoming Calls

§ Barring of All Outgoing Calls

§ Barring of Outgoing International Calls

§ Barring of Incoming Calls - When Roaming

§ Communication Hold

§ Message Waiting Indication

§ Communication Waiting

§ Ad-Hoc Multi Party Conference

§ For supplementary service configuration, the UE and IMS core network shall support XCAP at the Ut

6). Minimum Feature Set for IMS VoIP over LTE

The minimum feature set for the UEs and networks to support the IMS VoIP over LTE.

§ Domain Selection

§ SR-VCC

§ Service Setting Management

§ Emergency Service - support emergency services via E-CSCF in the IMS domain

§ Roaming Service - support IMS roaming with both P-CSCF and PGW in the visited network

§ SMS Support

Note:

§ session based charging via Rf interface is supported in home and visited network;

§ signalling encryption is terminated in the P-CSCF in the visited network, which may be required to fulfil regulatory requirements;

7). IMS Function Supported for IMS VoIP over LTE

§ SIP Registration: support for service route discovery, network-initiated de-registration, subscribe to the registration event package

§ Authentication: support the procedures for ISIM based authentication, for USIM based authentication, for authentication at the Ut

§ Addressing: support SIP URIs (alphanumeric) and MSISDN based IMPU, local numbers and may support geo-local numbers

§ Call establishment and termination: follow the SIP procedures for establishment and termination of a call, support reliable provisional responses, use an ICSI value to indicate the IMS Multimedia Telephony service (MMTel)

§ Forking: UE shall be ready to receive responses generated due to a forked request and behave

§ Support for Signalling Compression shall be mandatory in the UE and the P-CSCF

§ Support of the debug event package is optional

§ IMS Media: The needed SDP support in UEs and in the IMS core network and it describes the necessary media capabilities both for UEs and for entities in the IMS core network (MRFP and the MGW) that terminate the user plane.

§ IMS Codecs for Voice Media: The UE and the entities in the IMS core network that terminate the user plane shall support the AMR speech codec including all eight (8) modes and source rate controlled operations.

8). Protocol Supported for IMS VoIP over LTE

§ The UE and the network shall support both IPv4 and IPv6 for all protocols

§ Protocol Stack Support for VoIP application: SIP, SDP, RTP, RTCP and XCAP/HTTP

§ The IMS profile part lists the mandatory capabilities, which are required over the Gm and Ut reference points.

§ TCP/IP includes UDP, and HTTP includes XCAP in the protocol suite

§ The UE and the entities in the IMS core network that terminate the user plane shall use RTP over UDP to transport voice.

§ The UE shall use the same port number for sending and receiving RTP packets.

§ The UE and the IMS core network shall be able to receive and answer to an SDP offer using SDPCapNeg.

§ The answer shall indicate the use of the RTP AVP profile.

§ Support for RTP profile AVP

§ The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level,

§ Protocol Stack http://docs.google.com/View?id=ddh56dhg_3013hdmqddf

9). Function Supported for IMS VoIP over LTE

§ TAS from MMTel or IMS Centralized Services (ICS) - Service anchor in IMS to improve service consistency

§ Single Radio Voice Call Continuity (SR-VCC) - Swap between IMS and CS without preserving services

§ IP Multimedia Subsystem (IMS) Emergency Sessions is supported via E-CSCF.

§ The Emergency solution should be able to provide continuity of location support the SR VCC of emergency calls.

VoLTE (3) - (VoLGA) Voice over LTE Generic Access OV

VoLTE (3) - (VoLGA) Voice over LTE Generic Access OV

§ VoLGA = Voice over LTE Generic Access

§ Both CS Fallback (CSFB) and VoLGA rely on the existing circuit voice network, but VoLGA is not approved by 3GPP yet.

1). VoLGA OV

§ VoLGA is architecture independent and uses the UMA/GAN (Unlicensed Mobile Access/ Generic Access Network) protocol.

§ This was originally adopted for Wi-Fi/3G fixed-mobile convergence and as such did find its way into the 3GPP.

§ VoLGA does not require modifications in the LTE RAN or Core, or the MSC, but uses a separate gateway controller.

§ A technological approach for delivering voice and SMS services over LTE access networks

§ Leverages a mobile operator’s existing core voice network

§ Derived from the existing 3GPP GAN standard

§ A technological approach for delivering voice and SMS services over LTE access networks

§ Leverages a mobile operator’s existing core voice network

§ VoLGA is architecture independent and uses the UMA/GAN (Unlicensed Mobile Access/Generic Access Network) protocol - Derived from the existing 3GPP GAN standard (originally adopted for Wi-Fi/3G fixed-mobile convergence)

§ VoLGA re-uses this principle by replacing the Wi-Fi (GAN-based) access with LTE access on an LTE/UE new dual mode mobile device (both GSM/UMTS and LTE).

§ VoLGA does not require modifications in the LTE RAN or Core, or the MSC, but uses a new separate gateway controller (VANC).

§ The VoLGA Access Network Controller (VANC) , as a GAN gateway between LTE and CS domain, securely connects a subscriber to the infrastructure of a network operator and voice calls and other circuit switched services such as SMS are then securely transported between the mobile device and the Gateway.

§ VoLGA is a stronger contender than CSFB. From technical view, VoLGA seems to be a much better starting point. VoLGA would further delay IMS deployment

2). UMA/GAN OV

§ 3GPP Generic Access Network (GAN) specifications add Wi-Fi as an access technology to 3GPP based networks such as GSM and UMTS.

§ GAN requires a new dual mode mobile devices which have both a GSM/UMTS radio interface and a Wi-Fi radio interface.

§ The concept is to connect the already existing Mobile Switching Centers to the LTE network via a gateway.

§ As no fallback to a legacy network is required, call setup times are not increased and the user's quality of experience is consistent with that of the 2G or 3G voice environment.

§ The GAN specification was extended in Release 8 in 2008 to also include support for 3G/UMTS core network interfaces (Iu), in addition to 2G (A/Gb) interfaces.

3). Full service transparency

§ Supports all circuit services over LTE

§ Supports IMS RCS and combinational services (CS+IMS) over LTE

§ Supports handover of active calls between LTE and GSM/UMTS

§ Supports expected LTE femtocell deployments

4). VoLGA Pros and Cons:

Pros:

§ Voice and Data over LTE

§ Call setup times as good as 3G

§ Preserves CS core investments

§ External controller (VANC) minimizes impact to core network - No MSC upgrades

§ Supports simultaneous voice/ data over LTE

§ VoLGA will support all existing circuit services as well as IMS RCS - Supports combinational IMS/ RCS + Voice over LTE

§ Delivering voice over LTE validates LTE QoS capabilities

§ Voice services delivered natively through LTE femtocell

§ The VoLGA forum decided to use the SRVCC as the means to handover VoLGA calls from LTE to GSM or UMTS.

§ No VoLGA specific features required in the MSC or SGSN for VoLGA is a great plus for deployment in a running network.

Cons:

§ Not 3GPP standardized yet - VoLGA is currently not a work item in 3GPP

§ Not fully standardized yet as the stage 3 specification has not yet been finalized

§ Limited operator support

§ GAN-based dual-mode mobile phones is required

§ SRVCC-capable mobile is required

§ Only T-Mobile strongly enthusiastic right now

§ Scaling and Roaming

§ Limited LTE Coverage if only hotspots at the initial phase

§ It also requires changes to handsets, as well as a mechanism for allowing the network to trigger LTE-to-3G/2G handovers for VoLGA calls, originally defined as part of SR-VCC (single radio voice call continuity).

5). VoLGA Architecture:

§ http://docs.google.com/View?id=ddh56dhg_295htd3pzcn

§ VoLGA - Non-roaming architecture (N/A Here)

§ VoLGA - Roaming architecture (N/A Here)

§ VoLGA - Roaming architecture when SMS is provided from HPLMN (N/A Here)

§ On the network side, VoLGA only requires software enhancements to the circuit to packet gateways which already exist for GAN. No modifications are required on the Mobile Switching Centers or the LTE core and access network nodes.

§ On the mobile device side, the protocol stack initially developed for GAN can also be re-used in large parts. The two main software additions required are to include the LTE access technology as a radio bearer together with a modified handover procedure

6). VoLGA Interface:

§ All other network elements and the interfaces between them already exist and are reused without any modifications.

§ A-interface is used to connect the VANC to a GSM MSC (Mobile Switching Center).

§ The Iu-interface is used to connect the VANC to the UMTS MSC.

§ No changes are required on these network nodes to support voice, SMS and other services over the LTE network.

§ SGi: SGi is defined in TS 23.401. It is the reference point between the P-GW and the packet data network. The "packet data network" is the CS core network connected by VANC in this specification.

§ Sv: Sv is defined in TS 23.216, where it is defined as the reference point between the MME/SGSN and MSC Server. In this specification, Sv applies to two interfaces:

(1) between the MME and HOSF, and

(2) between the HOSF and MSC Server.

HOSF = Handover Selection Function

§ Z1 (UE – VANC): Z1 is the reference point between the UE and VANC, which is based on the Up interface defined in TS 43.318.

§ Z3 (VANC – HOSF): Z3 is the reference point between the VANC and HOSF. It is based on GTPv2-C as specified in TS 29.274. The Z3 reference point is used for the creation and deletion of VANC-UE bindings in the HOSF, and to route the SRVCC PS to CS Handover Request message to the VANC.

7). VoLGA Function & Service:

§ VoLGA is designed to deliver voice and SMS services over LTE networks.

§ The user gets the exact same set of services and user experience when on all three networks (GSM, 3G, LTE). Providing a common and consistent user experience across networks is a key requirement for mobile operators.

§ Given that the CS system cannot handle LTE ECGI, VoLGA shall support a mapping / translation function between GERAN Cell ID or UTRAN Service Area ID and LTE ECGI (E-UTRAN Cell Global Identifier).

7-1). VANC discovery support functions

§ For VoLGA VANC discovery, DHCP and DNS interactions take place between the UEs and these services.

§ The DNS server shall be accessed in the same PDN as the VANC.

§ The PDN GW shall support the DHCP server function including VANC discovery specific options.

§ The UE shall interact with DNS and DHCP services for the purpose of VANC discovery by means of the PDN connection after this has been established by means of the PDN GW.

7-2). Support CS Services:

The VoLGA shall be possible to access CS domain services over evolved PS access (EPS).

§ The following set of CS domain voice, supplementary and value-adding services and business principles (e.g. for roaming and interconnect) shall be made available over the evolved PS access.

§ MO/MT voice calls

§ Emergency calls

§ Video telephony

§ Supplementary Services

§ CAMEL services

§ SMS

§ USSD

§ TTY

§ Customised Alerting Tones

§ Circuit Switched Data

§ G3 Fax

7-3). Handover for VoLGA

§ The VoLGA forum decided to use the SRVCC as the means to handover VoLGA calls from LTE to GSM or UMTS.

§ A very important functionality of VoLGA is its ability to handover ongoing calls from the LTE network to a GSM or UMTS network when the user leaves the LTE coverage area.

§ For VoLGA, handover mechanisms are used which have been initially specified for IMS Single Radio Voice Call Continuity (SR-VCC) in 3GPP TS 23.2168.

7-4). VoLGA Function – Roaming:

§ VoLGA also enables a smooth introduction of global LTE roaming.

§ International Roaming: Local Breakout - preferred for VoLGA supported in the roaming network.

§ International Roaming: Home Network Routing - It is possible to use an APN that establishes a connection to the P-GW in the home network of the subscriber.

7-5). VoLGA Function – Emergency Service:

§ VoLGA shall support Emergency Service with USIM.

§ VoLGA shall support SIM-less Emergency Call per CS Emergency Call

§ VoLGA shall be able to detect whether a UE is attempting to establish an emergency call.

§ Location information shall be provided for emergency calls.

§ If the VANC has detected that the UE is attempting to establish an emergency call, it shall – as part of the PCC interaction – indicate to the PCRF that the bearer is needed for an emergency call.

8). VoLGA Functional Entity:

8-1). VoLGA Function Entity – VANC:

§ The only new network element introduced is the VoLGA Access Network Controller (VANC) , as a gateway between LTE and CS domain.

§ In a VoLGA solution, there is a newly introduced controller (VAN-C) which connects to the operator’s existing mobile voice switch.

§ The VoLGA controller takes all the standard circuit voice and SMS messages, puts them into IP packets, and routes them over LTE to the phone.

§ VANC manages the UE’s connection to the VoLGA service. It shall be able to interfaces with the MSC using the standard A and/or Iu interfaces.

§ The VANC behaves like a BSC (VoLGA A-mode) or RNC (VoLGA Iu-mode) towards the CS domain - supports "A Flex" or "Iu Flex" functions (i.e. behaves like a BSC or RNC)

§ The VANC shall support CS handover functions towards the MSC in the same way as a BSC/RNC.

§ The VANC shall be able to interact with a 3GPP PCRF for the control of the VoLGA signalling and user plane bearers.

§ Translation between the UE-VANC protocol and BSSAP/RANAP.

§ Handover preparation and execution in cooperation with the HOSF,

§ Supports the UE-VANC protocol

§ The AAA Server authenticates the UE using EAP-AKA when the UE initiates the establishment of a secure tunnel to the SeGW in VANC.

§ GAN-style IKEv2 authentication and tunnel mode IPSec is used between the UE and the SeGW function of the VANC

§ Performs UE security binding verification

§ Supports the detection of emergency call being setup.

§ Supports location function (i.e. behaves like a GMLC) to acquire location information from the MME.

§ The load distribution between VANCs within the same VANC pool is required

§ This controller scales up as traffic increases.

8-2). VoLGA Function Entity – HOSF:

§ HOSF = Handover Selection Function

§ In case of handover, the HOSF decides if the HO request from the MME is for VoLGA or for IMS/SRVCC and routes the request accordingly (i.e. either to the serving VANC or to the MSC Server enhanced for SRVCC).

§ HOSF shall support the VANC-UE binding creation and deletion procedures so that it can make these decisions based on the stored record of the serving VANC for the UE.

§ HOSF is a logical functional entity, which can be deployed according to operator's requirements (e.g. separate entity, embedded in MME or VANC).

8-3). VoLGA Function Entity – UE:

§ On the (LTE) phone, the ‘dialer’ sends and receives the exact same messages it would over GSM or 3G.

§ VoLGA re-uses this principle by replacing the Wi-Fi (GAN-based) access with LTE access on an LTE/UE new dual mode mobile device (both GSM/UMTS and LTE).

§ The mobile devices side it is also likely that VoLGA can be developed very quickly, as the already existing GAN protocol stack can be mostly re-used.

§ The major change in the UE software is handover handling, as the network based Single Radio Voice Call Continuity (SRVCC) feature will be used.

§ Discovery of and registration with VANC.

§ CS related NAS procedures for MM and CM through VANC.

§ VoIP on the user plane per IETF RFC 4867.

§ Ensures UE-VANC control plane communication is secure

8-4). VoLGA Function Entity – SRVCC:

§ The VoLGA forum decided to use the SRVCC as the means to handover VoLGA calls from LTE to GSM or UMTS.

§ No VoLGA specific features are required in the MSC or SGSN for VoLGA

§ SRVCC from E‑UTRAN access to 3GPP UTRAN/GERAN CS accesses for voice calls that are anchored in the IMS, and handling of SRVCC from 3GPP UTRAN/GERAN CS accesses to E‑UTRAN/UTRAN (HSPA) direction is not specified in the release (R8)

8-5). VoLGA Function Entity – EPS (E-UTRAN and MME):

§ The impact from VoLGA on the EPS shall be minimized

§ EPS needs to support Policy Control and Charging (PCC)

§ Support of appropriate QoS for the VoLGA signalling and user plane bearers

§ EPS must support handover with the CS network, e.g. similar to SRVCC

§ LTE must offer support for Header Compression on the user plane (RoHC)

EPS: E-UTRAN

§ The functionality for E-UTRAN is specified in TS 36.300.

§ No additional functionality is required of the E-UTRAN to support VoLGA.

§ In addition, E-UTRAN needs to provide support for SRVCC as specified in TS 23.216.

EPS: MME

§ The functionality for MME is specified in TS 23.40.

§ In addition, MME needs to provide support for SRVCC as specified in TS 23.216.

§ No additional functionality is required of MME to support VoLGA.

EPS: S-GW and P-GW

§ The functionality of S-GW and P-GW are specified in TS 23.401 for GTP based S5/S8 and TS 23.402 for PMIP based S5/S8.

§ No additional functionality is required of the S-GW and P-GW to support VoLGA.

8-6). VoLGA Function Entity on CS:

CS entities

§ VoLGA does not require any enhancement in existing CS elements like MSC but for VoLGA another set of additional nodes are needed.

§ There shall be no impact of VoLGA on the CS system.

§ VoLGA service delivery is transparent to the CS system.

CS: MSC Server

§ The functionality of the MSC Server is specified in TS 23.216.

§ The MSC Server is not used for VoLGA and is only shown in the architecture for completeness to illustrate the functionality of the HOSF.

CS: MSC/VLR

§ The functionality of the MSC/VLR is specified in existing 3GPP specifications.

§ No additional functionality is required of the MSC/VLR to support VoLGA.

CS: PCRF

§ The functionality of the PCRF is specified in TS 23.203.

§ PCRF is optional and is only deployed if the operator supports PCC.

§ No additional functionality is required of the PCRF to support VoLGA.

9-1). VoLGA supports two modes of operation:

§ VoLGA A-mode

§ VoLGA Iu-mode

9-2). VoLGA configuration properties

§ VANC discovery control - It shall be possible to configure the UE with: APN (in HPLMN or VPLMN), List of VPLMN

§ Voice mode control - It shall be possible to configure the UE with a list of modes to support voice service. For each mode it shall be possible to configure: priority or operator policy

§ Security configuration - The UE shall be configurable with parameters necessary to enable the proper use of IPsec between the UE and the VANC to secure the Z1 interface.

10). VoLGA Message Flow – (N/A Here)