VoLGA-Stage2 Spec v1.7.0

7/31/2019 VoLGA-Stage2 Spec v1.7.0

1/97

VoLGA Stage 2V1.7.0 (2010-06-14)Technical Specification

Voice over LTE via Generic Access;Stage 2 Specification;

Phase1

The present document has been developed by the VoLGA Forum and may be further elaborated for the purpose of providing CS services over EPS networks


2/97

VoLGA Forum

VoLGA Stage 2 V1.7.0 (2010-06-14)2Phase 1

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

2009, 2010 VoLGA Forum.

All rights reserved.


3/97

VoLGA Forum


Contents

Foreword .................................. ........................................... ........................................ .......................................6

1 Scope........................................................................................................................................................7

2 References ........................................... ............................................... ........................................... ...........7

3 Definitions and abbreviations...................................................................................................................83.1 Definitions................................................................................................ ............................................................. 83.2 Abbreviations ................................................................................................... ..................................................... 9

4 High level principles ......................................... ............................................ .........................................114.1 Architectural requirements......................................................................................................... ......................... 114.2 High level functions............................................................................. ............................................................... 114.2.1 VANC discovery support functions................................................. ............................................................. 114.2.2 Security context handling functions..................................................................................................... ......... 114.2.3 Handover functions .................................................................................... ................................................... 114.2.4 HOSF selection function ..................................................................................................... .......................... 11

5 Architecture model and reference points................................................................................................125.1 Non-roaming architecture .................................................................... ............................................................... 125.2 Roaming architectures................................................................................................................ ......................... 125.2.1 VoLGA service provided in VPLMN................................................. .......................................................... 125.2.2 VoLGA SMS provided from HPLMN .............................................................................................. ........... 135.3 Reference points.................................. ....................................................................................................... ......... 14

6 Functional entities ................................... ....................................... ............................................... .........146.1 E-UTRAN ................................................................................................. .......................................................... 146.2 MME .................................................................................................. ................................................................. 146.3 S-GW and P-GW................................................................................................... .............................................. 146.4 VANC........................................... .............................................................................................................. ......... 146.5 HOSF........................... ............................................................................................................... ......................... 156.6 UE.............. ............................................................................................................ .............................................. 156.7 AAA Server........................................ ........................................................................................................ ......... 15

6.8 MSC Server .............................................................................................. ........................................................... 156.9 PCRF .................................................................................... ............................................................................... 166.10 MSC/VLR ............................................................................................................... ............................................ 16

7 Protocol architecture ...................................... ........................................... ........................................... ..167.1 VoLGA A-mode protocol architecture................................ ............................................................................... 167.1.1 Control plane .............................................................................................. ................................................... 167.1.2 User plane............................................................................................ .......................................................... 177.2 VoLGA Iu-mode protocol architecture ..................................................................................................... ......... 177.2.1 Control plane .............................................................................................. ................................................... 177.2.2 User plane............................................................................................ .......................................................... 187.3 MME-HOSF protocol architecture.................................................................................... ................................. 197.4 HOSF-MSC Server protocol architecture ................................................................................. ......................... 197.5 VANC-HOSF protocol architecture .......................................................................................................... ......... 19

8 VoLGA states.........................................................................................................................................208.1 General ................................................................................................... ............................................................. 208.2 VoLGA Registration Management state model ........................................................................................ ......... 208.3 VoLGA Connection Management state model .................................................................................................. 218.3.1 VCM state model for VoLGA A-mode ...................................................................................... .................. 218.3.2 VCM state model for VoLGA Iu-mode.......................................................................... .............................. 22

9 Procedures for VoLGA A-mode ......................................... ........................................ ...........................229.1 Rove-in ................................................................................................... ............................................................. 229.1.1 General.............................................................................................. ............................................................. 229.1.2 VANC discovery ............................................................................................... ............................................ 239.1.3 VoLGA registration................................................................................. ...................................................... 25


4/97

VoLGA Forum


9.1.4 VoLGA mode selection................................................................................ ................................................. 279.2 Rove-out .................................................................................................... .......................................................... 289.2.1 General.............................................................................................. ............................................................. 289.2.2 VoLGA deregistration........................................ ........................................................................................... 289.3 VoLGA registration update .................................................................................... ............................................ 299.3.1 Registration update downlink ........................................................................................... ............................ 299.3.2 Registration update uplink ................................................................................................... ......................... 30

9.4 Keep-Alive and Re-Synchronization................................... ............................................................................... 319.4.1 Keep-Alive ................................................................................................. ................................................... 319.4.2 Re-Synchronization................................... ........................................................................................... ......... 329.5 GA-CSR connection handling ......................................................................................... ................................... 339.5.1 GA-CSR connection establishment ............................................................................. ................................. 339.5.2 GA-CSR connection release .................................................................................... ..................................... 349.6 Ciphering configuration................................................................................... ................................................... 359.7 NAS signalling ................................................................................... ................................................................. 359.8 Mobile-originated call......................... ....................................................................................... ......................... 369.8.1 EPS bearer establishment for VoLGA user plane...................................................................... .................. 399.9 Mobile-terminated call..... ......................................................................................................... .......................... 399.10 Call clearing .............................................................................................. .......................................................... 419.11 Channel modification......................... ........................................................................................ ......................... 429.12 Handover ............................................................................................ ................................................................. 429.12.1 Handover from E-UTRAN to GERAN ............................................................................... ......................... 429.12.2 Handover from E-UTRAN to UTRAN ............................................................................... ......................... 479.13 Short Message Service ................................................................................................... ..................................... 499.13.1 Mobile-originated SMS.................................................. ............................................................................... 499.13.2 Mobile-terminated SMS................................... ............................................................................................. 509.14 Supplementary services ..................................................................... ................................................................. 529.15 Emergency services................................................................................... .......................................................... 529.16 Location services......................................................................... ........................................................................ 529.17 Lawful interception.......................................................................................... ................................................... 539.18 Location area update ................................................................................. .......................................................... 53

10 Procedures for VoLGA Iu-mode............................................................................................................5410.1 Rove-in ................................................................................................... ............................................................. 5410.2 Rove-out .................................................................................................... .......................................................... 5410.3 VoLGA registration update .................................................................................... ............................................ 54

10.4 Keep-Alive and Re-Synchronization................................... ............................................................................... 5410.5 GA-RRC connection handling.................................................... ........................................................................ 5410.5.1 GA-RRC connection establishment............ ......................................................................................... ......... 5410.5.2 GA-RRC connection release............................................................................. ............................................ 5510.6 Security mode control ............................................................................................. ............................................ 5610.7 NAS signalling ................................................................................... ................................................................. 5710.8 Mobile-originated call......................... ....................................................................................... ......................... 5810.9 Mobile-terminated call..... ......................................................................................................... .......................... 6010.10 Call clearing .............................................................................................. .......................................................... 6210.10.1 Call release ......................................................................................... ........................................................... 6210.10.2 Channel release.................................................................................... .......................................................... 6310.11 Channel modification......................... ........................................................................................ ......................... 6310.12 Handover ............................................................................................ ................................................................. 6410.12.1 Handover from E-UTRAN to GERAN ............................................................................... ......................... 64

10.12.2 Handover from E-UTRAN to UTRAN ............................................................................... ......................... 6910.13 Short Message Service ................................................................................................... ..................................... 7010.13.1 Mobile-originated SMS.................................................. ............................................................................... 7010.13.2 Mobile-terminated SMS................................... ............................................................................................. 7110.14 Supplementary services ..................................................................... ................................................................. 7310.15 Emergency services................................................................................... .......................................................... 7310.16 Location services......................................................................... ........................................................................ 7310.17 Lawful interception.......................................................................................... ................................................... 7310.18 Location area update ................................................................................. .......................................................... 73

11 HOSF procedures ....................................... ........................................... ............................................... ..7411.1 Create VANC-UE binding in HOSF ......................................................................................... ......................... 74


5/97

VoLGA Forum


11.2 Delete VANC-UE binding in HOSF ......................................................................................................... ......... 75

12 VoLGA configuration mechanisms .......................................... ......................................... ....................7512.1 General ................................................................................................... ............................................................. 7512.2 VoLGA configuration properties............................................................. ........................................................... 7512.2.1 VANC discovery control................................................................................... ............................................ 7512.2.2 Voice mode control ........................................................................ ............................................................... 7512.2.3 Security configuration................................................................................................ ................................... 75

Annex A (normative): VoLGA coexistence with IMS & CSFB......................................................................76A.1 General ................................................................................................... ............................................................. 76A.2 IMS PS Voice or VoLGA Voice preferred ............................................................................................... ......... 77A.2.1 EPS attach...................................... ....................................................................................................... ......... 77A.2.2 Combined EPS/IMSI attach ................................................................................... ....................................... 82A.3 CS Voice preferred.................................................................................... .......................................................... 82A.4 IMS PS Voice or PS Voice only.............................. .................................................................................. ......... 84A.5 CS Voice only ........................................................................................... .......................................................... 88

Annex B (normative): VoLGA security mechanisms ..................................... ........................................ .........89B.1 Authentication and key agreement ............................................................................................................ ......... 89B.2 Encryption and integrity protection........................................................................ ............................................ 89B.3 EAP-AKA procedures................................................................................................................................ ......... 89B.3.1 EAP-AKA authentication procedure .......................................................................................... .................. 89B.3.2 EAP-AKA fast re-authentication procedure.................. ............................................................................... 91B.4 VoLGA security profiles.................................................................................. ................................................... 93B.4.1 Profile of IKEv2 ..................................................................................................... ....................................... 93B.4.2 Profile of IPsec ESP .......................................................................................... ............................................ 93

Annex C (informative): VoLGA PDN connection usage.................................................................................94C.1 PDN connection management for VoLGA .......................................................................... .............................. 94C.2 VoLGA signaling bearer.................................. ........................................................................................ ........... 94C.3 VoLGA user plane bearer ....................................................................................... ............................................ 95

Annex D (informative): User location information verification for SMS-only service ................................. ..95D.1 General ................................................................................................... ............................................................. 95D.2 PLMN-ID verification via GIBA-like mechanism.................................................................... ......................... 95


6/97

VoLGA Forum


Foreword

This Technical Specification has been produced by the Voice over LTE via Generic Access (abbreviated herein as

VoLGA) forum.

The contents of the present document are subject to continuing work within the forum and may change following

formal approval by forum members. Should the forum modify the contents of the present document, it will be re-

released by the forum with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

0 draft version of the specification;

1 approved version of the specification.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,

updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.


7/97

VoLGA Forum


1 Scope

The present document defines the stage 2 service description for Voice (and other CS services) over LTE via Generic

Access (VoLGA). It describes the VoLGA system concepts, documents the reference architecture, functional entities,

network interfaces, and high-level procedures.

VoLGA supports two modes of operation:

- VoLGA A-mode

- VoLGA Iu-mode

VoLGA A-mode supports an extension of GSM CS services that is achieved by tunnelling Non Access Stratum (NAS)

protocols between the UE and the Core Network over EPS bearers and the A interface to the MSC.

VoLGA Iu-mode supports an extension of UMTS CS services that is achieved by tunnelling Non Access Stratum

(NAS) protocols between the UE and the Core Network over EPS bearers and the Iu-CS interface to the MSC.

2 References

The following documents contain provisions which, through reference in this text, constitute provisions of the present

document. References may be other VoLGA specifications, or specifications from other standards entities, such as

3GPP, IETF, etc.

References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.

For a specific reference, subsequent revisions do not apply.

For a non-specific reference, the latest version applies.

[1] VoLGA Forum: "Voice over LTE via Generic Access; Requirements Specification; Phase 1".

[2] 3GPP TS 43.318: "Generic Access Network (GAN); Stage 2".

[3] 3GPP TS 23.401: "GPRS enhancements for E-UTRAN access".

[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".

[5] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".

[6] 3GPP TS 23.203: "Policy and charging control architecture".

[7] 3GPP TS 44.318: "Generic Access Network (GAN); Mobile GAN interface layer 3 specification".

[8] 3GPP TS 23.271: "Functional stage 2 description of Location Services (LCS)".

[9] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal

Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2".

[10] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".

[11] IETF RFC 4867, April 2007: "RTP Payload Format and File Storage Format for the Adaptive

Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".

[12] 3GPP TS 23.228: "IP Multimedia Subsystem; Stage 2".

[13] 3GPP TS 23.272: "Circuit Switched Fallback in Evolved Packet System; Stage 2".

[14] 3GPP TS 23.292: "IP Multimedia System (IMS) centralized services, Stage 2".

[15] Void


8/97

VoLGA Forum


[16] 3GPP TS 24.008: "Mobile radio interface layer 3 specification".

[17] IETF RFC 4187, January 2006: "Extensible Authentication Protocol Method for 3rd Generation

Authentication and Key Agreement (EAP-AKA)".

[18] IETF RFC 4306, December 2005: "Internet Key Exchange (IKEv2) Protocol)".

[19] IETF RFC 2406, November 1998: "IP Encapsulating Security Payload (ESP)".

[20] IETF RFC 4282, December 2005: "The Network Access Identifier".

[21] IETF RFC 2451: "The ESP CBC-Mode Cipher Algorithms".

[22] IETF RFC 3602: "The AES-CBC Cipher Algorithm and Its Use with IPsec".

[23] IETF RFC 2104: "HMAC: Keyed-Hashing for Message Authentication".

[24] IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".

[25] IETF RFC 2404: "The Use of HMAC-SHA-1-96 within ESP and AH".

[26] IETF RFC 2406: "IP Encapsulating Security Payload (ESP)".

[27] IETF RFC 3566: "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec".

[28] IETF RFC 2409: "The Internet Key Exchange (IKE)".

[29] IETF RFC 4434, February 2006: "The AES-XCBC-PRF-128 Algorithm for the Internet Key

Exchange Protocol (IKE)".

[30] 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service

(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".

[31] 3GPP TS 29.280: "Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN

to MSC) for SRVCC".

[32] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security Architecture".

[33] 3GPP TS 23.236: " Intra-domain connection of Radio Access Network (RAN) nodes to multiple

Core Network (CN) nodes ".

[34] OMA-DDS-DM_ConnMO-V1_0-20081107-A: "Standardized Connectivity Management

Objects", Approved Version 1.0 07 Nov 2008.

[35] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle

mode".

[36] 3GPP TS 23.221: "Architectural requirements".

[37] 3GPP TS 33.203: "3G security; Access security for IP-based services".

[38] 3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and

Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".

3 Definitions and abbreviations

3.1 Definitions

GERAN/UTRAN Mode: UE mode of operation where the CS domain NAS layers communicate through either the

GERAN RR entity or the UTRAN RRC entity.

VoLGA Mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA RR entity

for CS services. It includes VoLGA A-mode and VoLGA Iu-mode.


9/97

VoLGA Forum


VoLGA A-mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA GA-

CSR entity

VoLGA Iu-mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA GA-

RRC entity

Rove-in: UE switches to VoLGA mode from another voice mode or from a no coverage condition.

Rove-out: UE switches from VoLGA mode to another voice mode or to a no coverage condition.

3.2 Abbreviations

AAA Authentication, Authorization and Accounting

AF Application Function

AKA Authentication and Key Agreement

APN Access Point Name

ATM Asynchronous Transfer Mode

BSSAP Base Station Subsystem Application Part

BSSMAP Base Station Subsystem Management Application Part

CC Call Control

CGI Cell Global Identification

CK Ciphering KeyCKSN Ciphering Key Sequence Number

CM Connection Management

CN Core Network

CS Circuit Switched

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DTAP Direct Transfer Application Part

DTM Dual Transfer Mode

EAP Extensible Authentication Protocol

ECGI E-UTRAN Cell Global Identifier

EPC Evolved Packet Core

EPS Evolved Packet System

ESP Encapsulating Security Payload

E-UTRAN Evolved Universal Terrestrial Radio Access NetworkFQDN Fully Qualified Domain Name

GAN Generic Access Network

GA-CSR Generic Access - Circuit Switched Resources

GA-RC Generic Access - Resource Control

GA-RRC Generic Access - Radio Resource Control

GERAN GSM EDGE Radio Access Network

GPRS General Packet Radio Service

GTP GPRS Tunnelling Protocol

GTP-C GTP Control Plane

GTP-U GTP User Plane

GUTI Globally Unique Temporary Identity

GW Gateway

HLR Home Location Register

HOSF Handover Selection Function

HPLMN Home PLMN

HSS Home Subscriber Server

IETF Internet Engineering Task Force

IK Integrity Key

IKE Internet Key Exchange

IMEISV International Mobile station Equipment Identity and Software Version Number

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

KSI Key Set Identifier

L1 Layer 1


10/97

VoLGA Forum


L2 Layer 2

LA Location Area

LAI Location Area Identity

MAC Medium Access Control

MAC Message Authentication Code

MM Mobility Management

MME Mobility Management Entity

MS Mobile StationMSC Mobile Switching Center

NAS Non-Access Stratum

PCO Protocol Configuration Options

PCRF Policy and Charging Rules Function

PDCP Packet Data Convergence Protocol

PDN Packet Data Network

PDP Packet Data Protocol

PLMN Public Land Mobile Network

PS Packet Switched

PSTN Public Switched Telephone Network

P-GW PDN Gateway

P-TMSI Packet - TMSI

QCI QoS Class Identifier

QoS Quality of Service

RA Routing Area

RAC Routing Area Code

RAI Routing Area Identity

RAT Radio Access Technology

RLC Radio Link Control

RNC Radio Network Controller

RR Radio Resource

RTCP Real Time Control Protocol

RTP Real Time Protocol

SCCP Signalling Connection Control Part

SAP Service Access Point

SEGW SEcurity GateWay

SGSN Serving GPRS Support Node

SIM Subscriber Identity Module

SMS Short Message ServiceSRVCC Single Radio Voice Call Continuity

SS Supplementary Service

S-GW Serving Gateway

TAC Tracking Area Code

TAI Tracking Area Identity

TAU Tracking Area Update

TC Transport Channel

TCP Transmission Control Protocol

TDM Time Division Multiplex

TMSI Temporary Mobile Subscriber Identity

UDP User Datagram Protocol

UE User Equipment

UMTS Universal Mobile Telecommunication System

USSD Unstructured Supplementary Service DataVANC VoLGA Access Network Controller

VCM VoLGA Connection Management

VLR Visited Location Register

VoLGA Voice over LTE via Generic Access

VPLMN Visited Public Land Mobile Network

VRM VoLGA Registration Management


11/97

VoLGA Forum


4 High level principles

4.1 Architectural requirements

- The VoLGA solution shall impact neither the MME interfaces nor the MME behavior, as specified in current

3GPP specs.

- Coexistence between IMS/SRVCC and VoLGA shall be possible with no modifications to MME.

- A VoLGA UE that supports handover to GERAN/UTRAN indicates SRVCC capability to the E-UTRAN/EPS.

4.2 High level functions

4.2.1 VANC discovery support functions

DHCP and DNS interfaces are typically not included in architecture diagrams or described as reference points. For

VoLGA VANC discovery, described in sub-clause 9.1.2, DHCP and DNS interactions take place between the UE and

these services. The details of these interactions are a matter for stage 3 specification.

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.

4.2.2 Security context handling functions

The UE shall use the CS domain security context information (i.e., {KSI, CK, IK} or {CKSN, Kc}) that results from the

authentication and security mode control/cipher mode command procedures performed between the UE and MSC in

VoLGA mode, when (and if) handover to GERAN/UTRAN is necessary.

The UE shall not derive a new CS domain security context based on the EPS security context, per the procedures

specified for SRVCC in TS 33.401 [32].

The VANC shall discard the derived security context received from the MME in the SRVCC CS to PS Handover

Request message.

When handing over to UTRAN, the UE shall reset the CS domain START value to 0.

4.2.3 Handover functions

For intra-E-UTRAN handover, VoLGA uses the Intra-E-UTRAN handover procedure specified in TS 23.401 [3].

For handover from E-UTRAN to GERAN or UTRAN CS, VoLGA uses the SRVCC PS to CS handover functions

defined in TS 23.216 [5] for handover to GERAN/UTRAN CS domain.

The SRVCC PS to CS handover procedures only apply when the VoLGA CS service uses an EPS bearer with QCI 1.

This is the case for VoLGA speech calls. It can also be the case for fax and CS data calls if the VANC requests QCI 1

resources for these services.

VoLGA CS services that operate solely over the VoLGA signalling channel (e.g., SMS and USSD) are not handed over

to GERAN/UTRAN. If the UE is directed to handover to GERAN/UTRAN while one of these services is ongoing, the

UE shall abort the service and depend on retry mechanisms to complete the service.

VoLGA does not support CS to PS handover from GERAN/UTRAN CS domain to E-UTRAN.

4.2.4 HOSF selection function

VoLGA uses the SRVCC MSC Server selection function for the purpose of HOSF selection by the MME during PS to

CS handover to GERAN/UTRAN; i.e., from the MME's perspective, an SRVCC MSC Server is being selected.


12/97

VoLGA Forum


The SRVCC MSC Server selection function is not explicitly specified in TS 23.216 [5] or in TS 23.401 [3]. However,

we assume that the selection may be based on network topology; e.g., selection is based on Target ID received in the

Handover Required message. Also, the selection function may perform a simple load balancing between the possible

target SRVCC MSC Servers.

5 Architecture model and reference points5.1 Non-roaming architecture

The operator reuses the existing CS domain entities (e.g., MSC/VLR) that control establishment of CS services under

E-UTRAN coverage. The VANC enables the UE to access the MSC/VLR using the generic IP connectivity provided by

the EPS. The VANC can be connected to the MSC/VLR using either the A-interface ("VoLGA A-mode") or the Iu-CS

interface ("VoLGA Iu-mode"). From the EPS point of view, the VANC is viewed as an Application Function and the

"Z1" interface between the UE and the VANC is based on the Up interface defined in TS 43.318 [2].

UE E-UTRAN

VANC

Z1

MSC/VLR

A or Iu-CS

MMES1-c

S-GWP-GW

S1-u

Sv

SGi

PCRF

Gx Rx

HLR/HSS

D

LTE Uu

AAAServer

Wm

D

S6a

HOSFMSC

ServerSv

Z3

SeGW

Figure 5.1-1: Non-roaming architecture

5.2 Roaming architectures

5.2.1 VoLGA service provided in VPLMN

If the Visited PLMN supports "VoLGA service", the following architecture shall apply, where the PDN Gateway (P-

GW), the Serving VANC and the MSC/VLR are located in the VPLMN. The VANC in the VPLMN is connected to the

MSC/VLR using either the A-interface ("VoLGA A-mode") or the Iu-CS interface ("VoLGA Iu-mode").


13/97

VoLGA Forum


Figure 5.2.1-1: Roaming architecture

5.2.2 VoLGA SMS provided from HPLMN

If VoLGA SMS is provided from the HPLMN when the UE is roaming, the following architecture shall apply, where

the PDN Gateway (P-GW), the Serving VANC and the MSC/VLR are located in the HPLMN. The VANC in the

HPLMN is connected to the MSC/VLR using either the A-interface ("VoLGA A-mode") or the Iu-CS interface

("VoLGA Iu-mode").

VPLMN

HPLMN

HLR/HSSD

UE E-UTRAN

VANC

Z1

MSC/VLR

A or Iu-CS

MMES1-c

S-GWS1-u

SGi

H-PCRF

GxRx D

LTE Uu

AAA

Server

Wm

S6a

P-GW

S8

V-PCRF

S9

Gxc

Figure 5.2.2-1: Roaming architecture when SMS is provided from HPLMN

NOTE: The V-PCRF, S9 and Gxc interface exist in case S8 is PMIP based. See TS 23.402 [10] and TS 23.203 [6]

for details.


14/97

VoLGA Forum


5.3 Reference points

SGi: SGi is defined in TS 23.401 [3]. 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 [5], 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.

Z1: Z1 is the reference point between the UE and VANC, which is based on the Up interface defined in TS

43.318 [2].

Z3: Z3 is the reference point between the VANC and HOSF. It is based on GTPv2-C as specified in TS

29.274 [30]. 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.

6 Functional entities

6.1 E-UTRAN

The functionality for E-UTRAN is specified in TS 36.300[9]. In addition, E-UTRAN needs to provide support for

SRVCC as specified in TS 23.216[5].

NOTE: E-UTRAN configuration shall ensure that VoLGA CS calls are not handed over to the GERAN/UTRAN

PS domain.

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

6.2 MME

The functionality for MME is specified in TS 23.401[3]. In addition, MME needs to provide support for SRVCC as

specified in TS 23.216 [5].

No additional functionality is required of MME to support VoLGA.

6.3 S-GW and P-GW

The functionality of S-GW and P-GW are specified in TS 23.401[3] for GTP based S5/S8 and TS 23.402[10] for PMIP-

based S5/S8.

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

6.4 VANC

The VANC behaves like a BSC (VoLGA A-mode) or RNC (VoLGA Iu-mode) towards the CS domain. The VANC

also behaves like an Application Function (AF) towards the PCRF. The VANC includes a Security Gateway (SeGW)function that terminates a secure remote access tunnel from each UE, providing mutual authentication, encryption and

integrity protection for signalling traffic.

NOTE: The SeGW implementation may be separate from the VANC implementation; in this case, the

communication between the SeGW and the VANC is not defined in this specification.

The key functions provided by the VANC are stated below:

- Translation between the UE-VANC protocol and BSSAP/RANAP. This includes the mapping of information

between the UE and the MSC communication paths.


15/97

VoLGA Forum


- Handover preparation and execution in cooperation with the HOSF, where SRVCC functions are expected to be

reused. This includes the mapping of information received from the HOSF into formats that are acceptable to the

MSC (e.g. cell IDs / location IDs).

- Supports the UE-VANC protocol; e.g., for encapsulation of NAS CS domain signalling messages, for paging and

for the VoLGA Registration procedure to provide the UE with CN parameters that are normally broadcast in

System Information, such as CN domain specific GSM-MAP NAS system information.

- Ensures UE-VANC control plane communication is secure:

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

the VANC to allow for mutual authentication, data confidentiality and message integrity protection.

- Performs UE security binding verification; i.e. checking that the UE uses the same identity during VoLGA

registration as it used to authenticate and establish the IPSec tunnel to the VANC.

- Supports the VANC-UE binding creation and deletion procedures with the HOSF.

- Supports the detection of emergency call being setup.

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

- Supports "A Flex" or "Iu Flex" functions (i.e. behaves like a BSC or RNC) as specified in TS 23.236 [33].

6.5 HOSF

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).

6.6 UE

The functionalities required by the UE to support VoLGA are:

- 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 [11].

- Ensures UE-VANC control plane communication is secure (see VANC description).

6.7 AAA Server

The AAA Server authenticates the UE using EAP-AKA [17] when the UE initiates the establishment of a secure tunnel

to the SeGW. The procedures are as described in Annex B.

6.8 MSC Server

The functionality of the MSC Server is specified in TS 23.216[5]. The MSC Server is not used for VoLGA and is only

shown in the architecture figure for completeness to illustrate the functionality of the HOSF.


16/97

VoLGA Forum


6.9 PCRF

The functionality of the PCRF is specified in TS 23.203[6]. PCRF is optional and is only deployed if the operator

supports PCC.

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

6.10 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.

7 Protocol architecture

7.1 VoLGA A-mode protocol architecture

7.1.1 Control plane

The protocol architecture for the VoLGA A-mode control plane is illustrated in the following figure.

Figure 7.1.1-1: Protocol stack for VoLGA control plane (VoLGA A-mode)

NOTE: GA-CSR/GA-RC refer to the existing GAN protocols in TS 44.318 [7] plus changes defined for VoLGA.

The GA-RC protocol provides a resource management layer, including the following functions:

- registration with the VANC, including VoLGA mode selection (VoLGA A-mode or VoLGA Iu-mode);

- registration update with the VANC; and

- application level keep-alive with the VANC.

The GA-CSR protocol provides a resource management layer, which is equivalent to the GERAN RR and provides the

following functions:

- setup of bearer for CS voice and CS data traffic between the UE and VANC;

- direct transfer of NAS messages between the UE and the CS core network (i.e., for MM and CM signalling, and

for SMS and USSD data transport); and

- functions such as paging, ciphering configuration, and classmark change.


17/97

VoLGA Forum


The "transport IP address" is the "outer" IP address for IPsec tunnel mode. The transport IP address is assigned to the

UE when EPS connectivity for VoLGA service is established.

The "remote IP address" is the "inner" IP address for IPsec tunnel mode. The remote IP address is assigned to the UE

using the IKEv2 configuration payload procedure.

7.1.2 User plane

The protocol architecture for the VoLGA A-mode user plane (i.e., for CS voice and CS data) is illustrated in the

following figure.

Figure 7.1.2-1: Protocol stack for VoLGA user plane (VoLGA A-mode)

The user plane diagram indicates that the VANC performs transcoding "if required". The need for transcoding is

dependent on the A-interface transport (i.e., TDM-based or IP-based) and on the type of call:

- AoTDM:

- Transcoding is required for voice calls.

- Transcoding is not required for non-voice calls (e.g., CS data).

- AoIP:

- Transcoding is required for voice calls if G.711 is used over the A-interface.

- Transcoding is not required for voice calls if AMR (i.e., per RFC 4867 [11]) is used over the A-interface.

- Transcoding is not required for non-voice calls (e.g., CS data).

NOTE: The SMS and USSD data is transported using the NAS direct transfer functions of the VoLGA control

plane.

7.2 VoLGA Iu-mode protocol architecture

7.2.1 Control plane

The protocol architecture for the VoLGA Iu-mode control plane is illustrated in the following figure.


18/97

VoLGA Forum


Figure 7.2.1-1: Protocol stack for VoLGA control plane (VoLGA Iu-mode)

NOTE: GA-RRC/GA-RC refer to the existing GAN protocols in TS 44.318 [7] plus changes defined for VoLGA.

The GA-RC protocol provides a resource management layer, including the following functions:

- registration with the VANC, including VoLGA mode selection (VoLGA A-mode or VoLGA Iu-mode);

- registration update with the VANC; and

- application level keep-alive with the VANC.

The GA-RRC protocol provides a resource management layer which is equivalent to UTRAN RRC and supports the

following functions:

- setup of bearer for CS voice and CS data traffic between the UE and VANC;

- direct transfer of NAS messages between the UE and the CS core network (i.e., for MM and CM signalling, and

for SMS and USSD data transport); and

- other functions such as CS paging and security configuration.

The "transport IP address" is the "outer" IP address for IPsec tunnel mode. The transport IP address is assigned to the

UE when EPS connectivity for VoLGA service is established.

The "remote IP address" is the "inner" IP address for IPsec tunnel mode. The remote IP address is assigned to the UE

using the IKEv2 configuration payload procedure.

7.2.2 User plane

The protocol architecture for the VoLGA Iu-mode user plane (i.e., for CS voice and CS data) is illustrated in the

following figure.


19/97

VoLGA Forum


Figure 7.2.2-1: Protocol stack for VoLGA user plane (VoLGA Iu-mode)

The user plane diagram indicates that there is a re-framing function in the VANC, which converts between the RTP

framing protocol according to IETF RFC 4867 [11] and the Iu-CS user plane framing protocol, Iu UP.

Transcoding is not required in the VANC in this scenario.

NOTE: The SMS and USSD data is transported using the NAS direct transfer functions of the VoLGA control

plane.

7.3 MME-HOSF protocol architecture

The protocol architecture for the MME-HOSF interface (Sv) is illustrated in the following figure. The Sv interface is

based on GTPv2-C and is specified in TS 29.280 [31].

Figure 7.3-1: Protocol stack for MME-HOSF interface

7.4 HOSF-MSC Server protocol architecture

The protocol architecture for the HOSF-MSC Server interface (Sv) is illustrated in the following figure. The Sv

interface is based on GTPv2-C and is specified in TS 29.280 [31].

Figure 7.4-1: Protocol stack for HOSF-MSC Server interface

7.5 VANC-HOSF protocol architecture

The protocol architecture for the VANC-HOSF interface (Z3) is illustrated in the following figure. The Z3 interface is

based on GTPv2-C as specified in TS 29.274 [30].


20/97

VoLGA Forum


Figure 7.5-1: Protocol stack for VANC-HOSF interface

8 VoLGA states

8.1 General

The VoLGA Registration Management (VRM) states describe the registration status of the UE.

The VoLGA Connection Management (VCM) states describe the logical signalling connectivity between the UE and

the VANC, i.e. the VoLGA signalling connection analogous to the GERAN RR connection or the UTRAN RRC

connection.

The VCM states depend on whether VoLGA A-mode or VoLGA Iu-mode is being used.

The VCM states are valid when the registration state is GA-RC-REGISTERED.

NOTE: The VRM and the VCM states are independent from the EPS states defined in TS 23.401 [3].

8.2 VoLGA Registration Management state model

The VRM state diagram is shown in the following figure.

GA-RCDEREGISTERED

GA-RCREGISTERED

(A-mode or Iu-mode)

Deregistrationevent

Successfulregistration

Figure 8.2-1: VRM state diagram

The VRM entity in the UE and VANC can be in one of two states: GA-RC DEREGISTERED or GA-RC

REGISTERED.


21/97

VoLGA Forum


In the GA-RC DEREGISTERED state, the UE may be camped on an E-UTRAN cell; however, the UE has not

registered successfully with the VANC and cannot exchange GA-CSR messages (VoLGA A-mode) or GA-RRC

messages (VoLGA Iu-mode) with the VANC.

The UE may initiate the VoLGA Registration procedure when it is camped on an E-UTRAN cell and in the GA-RC

DEREGISTERED state.

NOTE 1: The ability for the UE to initiate the VoLGA Registration procedure when it is camped on aGERAN/UTRAN cell and in the GA-RC DEREGISTERED state (e.g., for handover from

GERAN/UTRAN purposes) is out of scope.

Upon successful VoLGA registration, the VRM state in the UE enters the GA-RC REGISTERED state with either

VoLGA A-mode or VoLGA Iu-mode selected.

The VRM entity in the UE returns to GA-RC DEREGISTERED state when a deregistration event takes place; e.g., the

UE receives a deregistration message from the VANC.

The VRM entity in the UE is normally in the GA-RC DEREGISTERED state when the UE is operating in

GERAN/UTRAN mode. The exception is when the UE moves to a GERAN/UTRAN cell and "roves out" (i.e., as

described in sub-clause 9.2) while in the GA-RC REGISTERED state; e.g., due to cell reselection, handover or NACC.

In this case, the UE may only send the periodic GA-RC KEEP ALIVE messages or a GA-RC DEREGISTER message

to the VANC and shall disregard all messages from the VANC except for the GA-RC DEREGISTER message.

NOTE 2: If the UE performs a handover into GERAN then the ability for the UE to communicate with the VANC

is conditional on the UE being able to simultaneously do both CS and PS.

8.3 VoLGA Connection Management state model

8.3.1 VCM state model for VoLGA A-mode

The VCM state diagram is shown in the following figure.

GA-CSR-IDLE

GA-CSR

GA-RC REGISTERED

(A-mode)

GA-CSR-

DEDICATED

GA-CSR

connectionestablishment

GA-CSR

connectionrelease

Figure 8.3.1-1: VCM state diagram for VoLGA A-mode.

The VCM entity in the UE enters the GA-CSR-IDLE state when the UE switches the serving RR entity to GA-CSR and

the SAP between the NAS and the GA-CSR is activated. This switch may occur only when the VRM entity is in the

GA-RC REGISTERED state.


22/97

VoLGA Forum


The VCM entity in the UE moves from the GA-CSR-IDLE state to the GA-CSR-DEDICATED state when the GA-CSR

connection is established and returns to the GA-CSR-IDLE state when the GA-CSR connection is released. Upon GA-

CSR connection release, an indication that no dedicated resources exist for the CS domain is passed to the upper layers.

The VCM state machine in the UE terminates when the UE switches the serving RR entity from VoLGA A-mode to

GERAN/UTRAN (i.e., when the UE performs a cell reselection into GERAN/UTRAN, after handover to

GERAN/UTRAN is completed, or when the VRM enters the GA-RC DEREGISTERED state).

8.3.2 VCM state model for VoLGA Iu-mode

The VCM state diagram is shown in the following figure.

GA-RRC-IDLE

GA-RRC

GA-RC REGISTERED(Iu-mode)

GA-RRC-CONNECTED

GA-RRCconnection

establishment

GA-RRCconnection

release

Figure 8.3.2-1: VCM state diagram for VoLGA Iu-mode.

The VCM in the UE enters the GA-RRC-IDLE state when the UE switches the serving RR entity to GA-RRC and the

SAP between the NAS and the GA-RRC is activated. This switch may occur only when the VCM entity is in the GA-

RC REGISTERED state.

The VCM entity in the UE moves from the GA-RRC-IDLE state to the GA-RRC-CONNECTED state when the GA-

RRC connection is established and returns to the GA-RRC-IDLE state when the GA-RRC connection is released. Upon

GA-RRC connection release, an indication that no dedicated resources exist for the CS domain is passed to the upper

layers.

The VCM state machine in the UE terminates when the UE switches the serving RR entity from VoLGA Iu-mode to

GERAN/UTRAN (i.e., when the UE performs a cell reselection into GERAN/UTRAN, after handover to

GERAN/UTRAN is completed, or when the VRM enters the GA-RC DEREGISTERED state).

9 Procedures for VoLGA A-mode

9.1 Rove-in

9.1.1 General

"Rove-in" is the process in which the UE switches the serving RR entity for CS domain services to GA-CSR (VoLGA

A-mode) or GA-RRC (VoLGA Iu-mode). When preparing to rove in, if the UE is not already registered with a VANC,

the UE performs the following procedures:


23/97

VoLGA Forum


1. VANC discovery

2. VoLGA registration

9.1.2 VANC discovery

9.1.2.1 GeneralThe VANC discovery process consists of two parts:

1. Selection of the PDN that the UE uses for VoLGA service (i.e., default PDN or VoLGA-specific PDN)

2. VANC discovery within the selected PDN

The selection of the PDN that the UE uses for VoLGA service shall be based on operator policy per sub-clause 12.2.

VANC discovery shall be performed using one or more of the following mechanisms (i.e., dependent on operator

policy):

- As part of the establishment of connectivity towards the selected PDN, using Protocol Configuration Options

(PCO)

- After IP connectivity in the selected PDN has been established, using DHCP or preconfigured addressinformation

The DHCP- and PCO-based mechanisms are described in sub-clause 9.1.2.2.

When using preconfigured address information, the UE shall behave as follows:

1. If the UE is preconfigured with the IP address of a SeGW and the IP address of a VANC, then the UE shall use

this address information in the VANC discovery procedure described in sub-clause 9.1.2.2.

2. If the UE is preconfigured with the IP address of a SeGW and the domain name of a VANC, then the UE shall

perform the pre-processing of the VANC domain name described in sub-clause 9.1.2.1.1, and then use the

resulting address information in the VANC discovery procedure described in sub-clause 9.1.2.2.

3. If the UE is preconfigured with the domain name of a SeGW and the IP address of a VANC, then the UE shall

perform the pre-processing of the SeGW domain name described in sub-clause 9.1.2.1.1, and then use theresulting address information in the VANC discovery procedure described in sub-clause 9.1.2.2.

4. If the UE is preconfigured with the domain name of a SeGW and the domain name of a VANC, then the UE shall

perform the pre-processing of the SeGW and VANC domain names described in sub-clause 9.1.2.1.1, and then

use the resulting address information in the VANC discovery procedure described in sub-clause 9.1.2.2.

5. If the UE is not preconfigured as described above, or if the UE fails to register using the preconfigured address

information, the UE may use the DHCP- or PCO-based mechanisms, as described in sub-clause 9.1.2.2.

9.1.2.1.1 Pre-processing of domain names

If domain names are provided to the UE for the SeGW or VANC or both, either via DHCP or via preconfiguration, the

UE shall inspect each domain name to determine if it includes an EPS Tracking Area Code (TAC) component. To do

this, the UE shall check if the left-most component of the domain name has the following format:

tac-lb.tac-hb.tac.

The TAC is a 16 bit integer. is the hexadecimal string of the most significant byte in the TAC and

is the hexadecimal string of the least significant byte.

If the domain name already includes the TAC in the format shown above, then the UE shall use the domain name as is;

otherwise, the UE shall add the TAC of the current EPS cell to the domain name string using the format shown above.

The following exception applies to the TAC-related processing of the domain name described above: The UE shall not

apply this processing if the UE is in a VPLMN and has selected a PDN from the HPLMN for VoLGA service.


24/97

VoLGA Forum


9.1.2.2 VANC discovery

Figure 9.1.2.2-1: VANC discovery

1. The UE performs the EPS attach procedure as defined in TS 23.401 [3] with the following SRVCC additions

as described in TS 23.216 [5]:

- The UE includes the SRVCC capability indication as part of the UE Network Capability in the Attach

Request message. The MME stores this information for SRVCC operation (if authorized, see below).

NOTE: If the operator policy on the UE is changed, the UE can change its SRVCC capability indication as part of

the UE network capability in a Tracking Area Update procedure.

- The UE includes the GERAN Classmark information (if the UE supports GERAN access) in the Attach

Request message (and maintained during the Tracking Area Update procedure).

- If the subscriber is authorized to use the SRVCC capabilities then the HSS includes the SRVCC STN-SR

and MSISDN in the Insert Subscriber Data message to the MME.

- The MME includes a "SRVCC operation possible" indication in the S1 AP Initial Context Setup Request,

meaning that both UE and MME are SRVCC-capable and SRVCC service is authorized.

The UE may include a request for the VANC address information using Protocol Configuration Options (PCO)

during the EPS attach procedure. In response, the network may provide the UE with the VANC address

information via PCO.

2. If the APN of the PDN connection established in step 1 matches the APN configured for VoLGA in the PLMN

per sub-clause 12.2, and the UE does not have VANC address information (i.e., provided by preconfiguration

or via PCO), then the UE shall proceed to step 3.

If the APN of the PDN connection established in step 1 matches the APN configured for VoLGA in the PLMN

per sub-clause 12.2, and the UE has VANC address information (i.e., provided by preconfiguration or via

PCO), then the UE shall proceed to step 5.

Otherwise, the UE shall establish another PDN connection using the VoLGA APN configured for the PLMN

per procedures described in TS 23.401 [3]. During this additional PDN connectivity procedure, the UE may

include a request for the VANC address information using Protocol Configuration Options (PCO). In response,

the network may provide the UE with the VANC address information via PCO.

After completing the additional PDN connectivity procedure, if the UE has VANC address information (i.e.,

provided by preconfiguration or via PCO), then the UE shall proceed to step 5; otherwise, the UE shall proceed

to step 3.


25/97

VoLGA Forum


NOTE: The UE is assigned its "transport IP address" (see sub-clauses 7.1.1 and 7.2.1) when EPS connectivity for

VoLGA service is established. This may be during the EPS attach procedure (step 1) or the additional

PDN connectivity procedure (step 2).

3-4. The UE uses DHCP to obtain the domain name (or IP address) of a SeGW and a VANC and the address of a

Domain Name Server (DNS) that is capable of resolving the SeGW domain name. The UE may not receive a

DNS address if the SeGW IP address is provided via DHCP. If a SeGW IP address is returned then the UE is

ready to attempt VoLGA registration.

If domain names are provided to the UE for the SeGW or VANC or both, the UE shall perform the pre-

processing of the domain name(s) as described in sub-clause 9.1.2.1.1.

5. If the VANC address information that the UE has obtained includes a SeGW domain name, the UE uses DNS

to resolve the SeGW domain name; otherwise, the UE is ready to attempt VoLGA registration as described in

sub-clause 9.1.3.

6. If DNS resolution is successful, then the UE is ready to attempt VoLGA registration as described in sub-clause

9.1.3.

9.1.3 VoLGA registration

If the UE has successfully completed the VANC discovery procedure (i.e., has the address of a SeGW and a VANC),

the UE may attempt VoLGA registration. The VANC may accept or reject the registration or redirect the UE to anotherVANC (e.g., depending on the UE's location, load balancing or roaming condition), as illustrated in the following

figure.

UE EPS

4. GA-RC REGISTER REQUEST (EPS cell info, IMSI, GUTI, GAN Classmark, )

5b. GA-RC REGISTER ACCEPT (VoLGA System Information)

6. GA-RC REGISTER REJECT (Reject Cause)

1. Establish secure tunnel to SeGW

7. GA-RC REGISTER REDIRECT (VANC address)

5a. Activate dedicated EPS bearer for signalling (e.g., QCI=5)

HOSF(s)SeGW

5c. Create VANC-UEbinding on HOSF(s)

DNS VANC

2a. DNS query (VANC domain name)

2b. DNS response

3. Establish TCP connection to VANC

Figure 9.1.3-1: VoLGA registration

1. The UE establishes a secure tunnel to the SeGW (i.e., using IKEv2 and IPSec ESP as specified in Annex B).

NOTE: The UE is assigned its "remote IP address" (see sub-clauses 7.1.1 and 7.2.1) using the IKEv2

configuration payload procedure.


26/97

VoLGA Forum


2. If the UE received a VANC domain name during VANC discovery, the UE uses DNS to resolve the VANC

domain name.

3. The UE establishes a TCP connection to the assigned VANC. The TCP keepalive option shall not be enabled

by the UE. Detection of a TCP connection failure is handled using the GA-RC KEEP ALIVE message

procedure (see sub-clause 9.4).

4. The UE registers with the VANC, using the GA-RC REGISTER REQUEST message. The message contains:

- EPS Tracking Area ID (TAI)

- the current camping E-UTRAN cell ID

- UE IMSI

- UE GUTI

- GAN Classmark: Including indication of support for VoLGA service

- The "transport IP address" assigned to the UE (see sub-clauses 7.1.1 and 7.2.1); the VANC stores this

address and uses it as the destination IP address for RTP packets sent to the UE (e.g., in the case of a MO or

MT call).

- Optionally, an indication that SMS-only service is requested by the UE.

NOTE: The conditions for the UE to include this indicator (e.g., when the UE is roaming on a VPLMN or only

after a registration request without the indicator has failed) are up to UE configuration.

5a. If the VANC accepts the registration attempt it may request specific QoS for the VoLGA signalling flow using

the Rx interface to the PCRF, per the procedures in TS 23.401 [2] and TS 23.203 [6].

NOTE 1: The authorization of the QoS for the signalling flow may incur the activation or modification of an EPS

bearer.

NOTE 2: This step can be used to verify the binding between the received UE IMSI and transport IP address by the

PCRF, since these parameters are provided by the VANC to the PCRF in the AA-Request message per

TS 29.214.

5b. The VANC then responds with a GA-RC REGISTER ACCEPT message. The message contains VoLGA

specific system information, including:

- GAN Mode Indicator: A/Gb mode or Iu mode (i.e., VoLGA A-mode or Iu-mode, respectively)

- VoLGA Location Area Identification (LAI) comprising the mobile country code, mobile network code, and

location area code allocated by the VANC. If the VoLGA LAI is not the same as the stored LAI, the UE

performs the CS domain location area update procedure via the VoLGA control plane.

- Applicable system timer values

- Optionally, a list (i.e., containing one or more entries) of the EPS TAIs that are served by the VANC. This

is referred to as the "VANC TAI List". The VANC TAI List may be used to control the VoLGA

registration update procedure, as described in sub-clause 9.3.

NOTE: The VANC TAI List is independent from the TAI List allocated by the MME

- Optionally, a "registration update suppression" indicator. This indicator shall be included when a roaming

UE connects to a VANC in its HPLMN for SMS-only service.

- Access network preference for the placement of emergency calls; i.e., GERAN/UTRAN CS domain or

VoLGA in E-UTRAN

- Optionally, the domain name or IP address of the VANC (see sub-clause 9.4.2)

In this case the secure tunnel and TCP connection are not released and are maintained as long as the UE is

registered to this VANC. If the LAI is not the same as the stored LAI, the UE performs the CS domain location

area update procedure via the VoLGA control plane.


27/97

VoLGA Forum


5c. The VANC also creates a VANC-UE binding on one or more HOSFs. The VANC shall ensure that a VANC-

UE binding is created on each HOSF that may be subsequently selected by the serving MME for SRVCC PS to

CS handover (see sub-clause 4.2.4); e.g., taking account of the UE's EPS location information and EPS

network topology information configured in the VANC. The procedure to create a VANC-UE binding is

described in sub-clause 11.1. The creation of the VANC-UE binding(s) is not required if the UE is registered

for SMS-only service from the HPLMN.

6. Alternatively, the VANC may reject the request in certain cases including the following:

- VoLGA is not supported on the UEs current PLMN. In this case, the VANC may indicate other PLMNs

which support VoLGA.

- The current TA is not VoLGA enabled. In this case, the VANC optionally includes a list of TAIs which are

also not VoLGA enabled. This is referred to as the "VoLGA-disabled TAI List". If no list is provided by

the VANC, the UE shall assume that VoLGA is not enabled in the TAI list indicated by the MME. While

operating in a TA that is not VoLGA enabled, the UE shall not attempt VoLGA registration.

- The UE is attempting to register on a VANC in the HPLMN while roaming.

The VANC responds with a GA-RC REGISTER REJECT message indicating an appropriate reject cause. The

UE may release the secure tunnel and TCP connection and may attempt re-discovery and re-registration under

certain circumstances (i.e., depending on the reject cause).

7. Alternatively, if the VANC wishes to redirect the UE to another VANC (e.g., to distribute load betweenVANCs in a pool), it shall respond with a GA-RC REGISTER REDIRECT message providing the domain

name or IP address of the target VANC and, optionally, the domain name or IP address of the target SeGW.

The UE releases the TCP connection to the VANC. If the address of the target SeGW (a) is not included or (b)

is included and matches the address associated with the current SeGW that is stored in the UE, then the UE

reuses the existing secure tunnel. Otherwise (i.e., the address of the target SeGW is included but does not

match the address associated with the current SeGW), the UE releases the existing secure tunnel and

establishes a new secure tunnel to the target SeGW. The UE then attempts registration on the new VANC.

9.1.4 VoLGA mode selection

The UE transfers its VoLGA mode support to the VANC during registration procedure; i.e., in the GAN Classmark IE.

VoLGA mode support options are VoLGA A-mode supported, VoLGA Iu-mode supported, or both modes supported.

The VANC may use the received VoLGA mode support information to redirect the UE to a different VANC or adifferent TCP port on the current VANC. The VANC shall also indicate the VoLGA mode to use for the current

session.

The following table enumerates the VoLGA mode selection procedures for the various combinations of UE and VANC

VoLGA mode capabilities.

Table 9.1.4-1: VoLGA mode selection procedures associated with VoLGA registration

VANC VoLGA mode capabilities

UE VoLGA

mode

capabilities

A-mode only Iu-mode only Both modes

A-mode only VANC: Accept and

indicate VoLGA A-mode

UE: Proceed per VoLGA

A-mode procedures

VANC: Redirect UE to

VoLGA A-mode capable

VANC or reject registration

UE: Handle per registration

redirection or reject

procedures

VANC: Handle as normal

VoLGA A-mode

registration. If required,

redirect UE to VoLGA A-

mode capable VANC.


A-mode procedures

Iu-mode only VANC: Redirect UE to

VoLGA Iu-mode capable

VANC: Accept and

indicate VoLGA Iu-mode

VANC: Accept and



28/97

VoLGA Forum


VANC or reject registration

UE: Handle per registration

redirection or reject

procedures


Iu-mode procedures


Iu-mode procedures

Both modes VANC: Accept and

indicate VoLGA A-mode


A-mode procedures

VANC: Accept and



Iu-mode procedures

VANC: Accept and


or VoLGA A-mode (Note1). If required, redirect UE

to VoLGA Iu-mode or

VoLGA A-mode capable

VANC.


Iu-mode or VoLGA A-

mode procedures

NOTE 1: The VANCs choice of VoLGA Iu-mode versus VoLGA A-mode may be based on other information

received in the VoLGA registration message from the UE, information stored in the VANC, and on

operator policy.

9.2 Rove-out

9.2.1 General

"Rove-out" is the process in which the UE switches from VoLGA mode, where the serving RR entity for CS domain

services is GA-CSR (VoLGA A-mode) or GA-RRC (VoLGA Iu-mode), to another mode (i.e., using the voice mode

selection procedures in Annex A) or to a no coverage condition.

When the UE roves out, it starts the "deregister on rove-out" timer. The value of the timer is provided by the VANC

during VoLGA registration or registration update. If the UE roves back into VoLGA mode while registered with the

VANC, it stops the timer. If the timer expires while the UE is in a non-VoLGA mode, the UE initiates the VoLGA

deregistration procedure (see sub-clause 9.2.2). If the timer expires while the UE is in a no coverage condition, the UE

implicitly deregisters from the VoLGA service; i.e., locally releases all resources related to VoLGA service. Thisinvolves no signalling between the UE and VANC.

When the UE roves out to a no coverage condition, the VoLGA RR entity shall inform the CS MM entity that coverage

has been lost. Likewise, if rove-in is due to the recovery from a lack of coverage while registered for VoLGA service

(i.e., recovery to E-UTRAN coverage), the VoLGA RR entity shall inform the CS MM entity (see also sub-clauses 9.18

and 10.18).

9.2.2 VoLGA deregistration

The VoLGA deregistration procedure allows the UE to explicitly inform the VANC that it is leaving VoLGA mode by

sending a GA-RC DEREGISTER message to the VANC. The UE also initiates the VoLGA deregistration procedure if

the "deregister on rove-out" timer expires while the UE is in a non-VoLGA mode.

The VANC supports "implicit VoLGA deregistration"; e.g., when the TCP connection that is used for VoLGAsignalling transport is lost.

The VANC can also autonomously release the UE registration context, and send a GA-RC DEREGISTER message to

the UE. Alternatively, the VANC can implicitly deregister the UE by closing the TCP connection with the UE.

In all these deregistration cases, the VANC deletes the stored UE context information.


29/97

VoLGA Forum


Figure 9.2.2-1: VoLGA deregistration initiated by the UE

1. The UE sends the GA-RC DEREGISTER message to the VANC, which removes the UE context in the

VANC.

2. The VANC deletes the VANC-UE binding previously created for the UE on one or more HOSF(s). The

procedure to delete a VANC-UE binding is described in sub-clause 11.2.

3. If the VANC had previously authorized the VoLGA signalling flow using the Rx interface to the PCRF (see

step 5 in sub-clause 9.1.3), then the VANC deauthorizes the VoLGA signalling flow (which results in the

release of the VoLGA signalling bearer) via the Rx interface to the PCRF.

Figure 9.2.2-2: VoLGA deregistration initiated by the VANC

1. The VANC sends the GA-RC DEREGISTER message to the UE.

2-3. Same as steps 2-3 in Figure 9.2.2-1.

9.3 VoLGA registration update

9.3.1 Registration update downlink

The VoLGA registration update downlink procedure allows the VANC to autonomously update the VoLGA system

information in the UE (e.g., VoLGA LAI, VANC TAI List), if needed, by sending a GA-RC REGISTER UPDATE

DOWNLINK message to the UE carrying the updated information.

UE

1. GA-RC REGISTER UPDATE DOWNLINK

VANC

Figure 9.3.1-1: VoLGA registration update downlink

1. The VANC sends the GA-RC REGISTER UPDATE DOWNLINK message with the updated system

information (e.g., VoLGA LAI, VANC TAI List). If the VoLGA LAI is included and is not the same as the

stored LAI, the UE performs the CS domain location area update procedure via the VoLGA control plane.


30/97

VoLGA Forum


The VoLGA registration update downlink procedure also allows the VANC to direct the UE to rove-out; e.g., after the

UE moves to a TA that is not VoLGA capable. In this case, the VANC includes a rove-out indicator and optionally

includes a list of TAIs which are also not VoLGA enabled (i.e., the VoLGA-disabled TAI List, described in sub-clause

9.1.3) in the GA-RC REGISTER UPDATE DOWNLINK message. The rove-out procedures are described in sub-clause

9.2.1.

Finally, the VoLGA registration update downlink procedure allows the VANC to direct the UE to rove back in; e.g.,

after the UE moves from a TA that is not VoLGA capable to a TA that is VoLGA capable. In this case, the VANC

includes a rove-in indicator and any updated VoLGA system information (e.g., VoLGA LAI, VANC TAI List or

VANC RAI List) in the GA-RC REGISTER UPDATE DOWNLINK message.

9.3.2 Registration update uplink

The VoLGA registration update uplink procedure allows the UE to update information in the VANC by sending a GA-

RC REGISTER UPDATE UPLINK message to the VANC carrying the updated information.

The following triggers for the VoLGA registration update uplink procedure apply if the registration update suppression

indicator is not received in the GA-RC REGISTER ACCEPT or GA-RC REGISTER UPDATE DOWNLINK message:

- If no VANC TAI List has been received from the VANC, then the UE shall perform the VoLGA registration

update procedure after each EPS tracking area update that is due to a TA change.

- If a VANC TAI List has been received from the VANC, then the UE shall perform the VoLGA registrationupdate procedure when the tracking area identity of the selected E-UTRAN cell is not in the VANC TAI List.

Since the UE does not perform the registration update while in the geographic area associated with the VANC

TAI List, it will maintain the same VoLGA LAI while in this geographic area; i.e., the geographic area

associated with the VANC TAI List is contained within the geographic area associated with the VoLGA LAI.

- If the UE is assigned a new GUTI and the MME ID portion (i.e., MME Group ID + MME Code) is not the same

as the MME ID portion of the old GUTI then the UE shall perform the VoLGA registration update procedure.

- If the UE is in an active call, then the UE shall perform the VoLGA registration update procedure when the

tracking area identity of the serving EPS cell changes.

For registered UEs in non-VoLGA mode, the following triggers for the VoLGA registration update uplink procedure

apply:

- If no VoLGA-disabled TAI List has been received from the VANC, then the UE shall perform the VoLGAregistration update procedure after each EPS tracking area update that is due to a TA change.

- If a VoLGA-disabled TAI List has been received from the VANC, then the UE shall perform the VoLGA

registration update procedure when the tracking area identity of the selected E-UTRAN cell is not in the VoLGA

Disabled TAI List.

NOTE: A combination of two or more of the above triggers (e.g., a TAU with a new GUTI assignment) shall

result in only a single GA-RC REGISTER UPDATE UPLINK message from the UE to the VANC.

If the UE received the registration update suppression indicator in the most recent GA-RC REGISTER ACCEPT or

GA-RC REGISTER UPDATE DOWNLINK message then it shall not perform the VoLGA registration update

procedure.

The receipt of a GA-RC REGISTER UPDATE UPLINK message by the VANC may result in (a) no action by the

VANC, (b) the VANC redirecting the UE to another VANC, (c) the VANC providing new VoLGA system information(e.g., VoLGA LAI, VANC TAI List) to the UE, or (d) the VANC deregistering the UE (e.g., based on operator policy).

This may also result in the VANC updating its VANC-UE bindings with the HOSF(s); i.e., creating a VANC-UE

binding on one or more HOSFs, deleting a VANC-UE binding on one or more HOSFs, or both.


31/97

VoLGA Forum


Figure 9.3.2-1: VoLGA registration update uplink

1. When the UE detects any of the conditions listed above, it shall send the GA-RC REGISTER UPDATE

UPLINK message to the VANC with the updated information.

2. The VANC may send the GA-RC REGISTER REDIRECT (VANC address) message when it wants to redirect

the UE based on updated information. The UE performs the registration procedure on the new VANC asspecified in sub-clause 9.1.3.

NOTE: The VANC may send the GA-RC REGISTER REDIRECT message to the UE at any time while the UE

is registered; i.e., the GA-RC REGISTER REDIRECT message does not have to be in response to a

received GA-RC REGISTER UPDATE UPLINK message. The VANC may use this procedure to off-

load UEs to other VANCs.

3. The VANC may send the GA-RC REGISTER UPDATE DOWNLINK message when it wants to provide new

system information (e.g., VoLGA LAI, VANC TAI List) to the UE. If the VoLGA LAI is included and is not

the same as the stored LAI, the UE performs the CS domain location area update procedure via the VoLGA

control plane.

The VANC may also send the GA-RC REGISTER UPDATE DOWNLINK message to the UE to direct the

UE to rove-out or rove-in (see sub-clause 9.3.1).

4. The VANC may deregister the UE by sending the GA-RC DEREGISTER message to the UE.

5. The VANC may update its VANC-UE bindings on the HOSF(s), as described in clause 11; i.e., creating a

VANC-UE binding on one or more HOSFs, deleting a VANC-UE binding on one or more HOSFs, or both.

9.4 Keep-Alive and Re-Synchronization

9.4.1 Keep-Alive

The Keep-Alive procedure is used between the peer GA-RC entities to indicate that the UE is still registered on the

VANC. The periodic transmission of the GA-RC KEEP ALIVE message also allows the UE to determine that the

VANC is still available (i.e., based on TCP level acknowledgement). The frequency of the GA-RC KEEP ALIVE

message transmission is based on a timer sent by the VANC to the UE in the GA-RC REGISTER ACCEPT message orthe GA-RC REGISTER UPDATE DOWNLINK message.

Note: The value of this timer should be set to avoid unnecessary battery drain in the UE (e.g., no more frequent

than one message every 60 minutes).


32/97

VoLGA Forum


Figure 9.4.1-1: Keep-Alive procedure

1. The UE sends GA-RC KEEP ALIVE message to the VANC.

NOTE: The VANC behaviour if the GA-RC KEEP ALIVE message is not received from the UE for an extended

period of time is implementation-specific.

9.4.2 Re-Synchronization

9.4.2.1 UE-initiated Re-Synchronization

The UE-initiated Re-Synchronization procedure is used when the UE receives a TCP Reset after TCP connection

failure. If the UE received a VANC IP address or FQDN in the GA-RC REGISTER ACCEPT message (see sub-clause

9.1.3), then the UE shall make a single attempt to re-establish the TCP connection to that address; otherwise, the UE

shall make a single attempt to re-establish the TCP connection to the VANC address provided during VANC discovery

or redirection. If the TCP connection is successfully re-established, the UE sends the GA-RC SYNCHRONIZATIONINFORMATION (GA-RC SYNC INFO) message to the VANC to synchronize the UE state information, allowing the

VANC to update the UE registration.

Figure 9.4.2.1-1: UE-initiated Re-Synchronization

1. The UE sends a message to the VANC.

2. The UE receives a TCP reset indicating a TCP connection failure.

3. The UE successfully attempts to re-establish a TCP connection to the assigned VANC.

4. The UE sends the GA-RC SYNCHRONIZATION INFORMATION (GA-RC SYNC INFO) message to the

VANC to synchronize the UE state information.

5. The VANC updates the UE registration status based on the received information.

If the TCP connection could not be re-established, the UE enters the GA-RC DEREGISTERED state locally.

The above procedure shall also be applied if the UE performs any other implementation-specific failure handling

procedure where the UE attempts to re-establish the TCP connection after failure detection.

9.4.2.2 VANC-initi

Documents

VoLGA-Stage2 Spec v1.7.0