volga-stage2 spec v1.7.0
TRANSCRIPT
-
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
3/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)3Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
4/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)4Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
5/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)5Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
6/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)6Phase 1
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/31/2019 VoLGA-Stage2 Spec v1.7.0
7/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)7Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
8/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)8Phase 1
[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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
9/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)9Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
10/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)10Phase 1
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
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
11/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)11Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
12/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)12Phase 1
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").
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
13/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)13Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
14/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)14Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
15/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)15Phase 1
- 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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
16/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)16Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
17/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)17Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
18/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)18Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
19/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)19Phase 1
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].
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
20/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)20Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
21/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)21Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
22/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)22Phase 1
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:
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
23/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)23Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
24/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)24Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
25/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)25Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
26/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)26Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
27/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)27Phase 1
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.
UE: Proceed per VoLGA
A-mode procedures
Iu-mode only VANC: Redirect UE to
VoLGA Iu-mode capable
VANC: Accept and
indicate VoLGA Iu-mode
VANC: Accept and
indicate VoLGA Iu-mode
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
28/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)28Phase 1
VANC or reject registration
UE: Handle per registration
redirection or reject
procedures
UE: Proceed per VoLGA
Iu-mode procedures
UE: Proceed per VoLGA
Iu-mode procedures
Both modes VANC: Accept and
indicate VoLGA A-mode
UE: Proceed per VoLGA
A-mode procedures
VANC: Accept and
indicate VoLGA Iu-mode
UE: Proceed per VoLGA
Iu-mode procedures
VANC: Accept and
indicate VoLGA Iu-mode
or VoLGA A-mode (Note1). If required, redirect UE
to VoLGA Iu-mode or
VoLGA A-mode capable
VANC.
UE: Proceed per VoLGA
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
29/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)29Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
30/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)30Phase 1
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.
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
31/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)31Phase 1
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).
-
7/31/2019 VoLGA-Stage2 Spec v1.7.0
32/97
VoLGA Forum
VoLGA Stage 2 V1.7.0 (2010-06-14)32Phase 1
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