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)