VoLGA Stage 2 V1.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

Phase 1

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

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.

VoLGA Forum

Phase 1

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

Contents
Foreword ............................................................................................................................................................6 1 2 3
3.1 3.2

Scope ........................................................................................................................................................7 References ................................................................................................................................................7 Definitions and abbreviations...................................................................................................................8

Definitions............................................................................................................................................................. 8 Abbreviations ........................................................................................................................................................ 9

4
4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4

High level principles ..............................................................................................................................11

Architectural requirements.................................................................................................................................. 11 High level functions ............................................................................................................................................ 11 VANC discovery support functions.............................................................................................................. 11 Security context handling functions.............................................................................................................. 11 Handover functions ....................................................................................................................................... 11 HOSF selection function ............................................................................................................................... 11

5
5.1 5.2 5.2.1 5.2.2 5.3

Architecture model and reference points................................................................................................12

Non-roaming architecture ................................................................................................................................... 12 Roaming architectures......................................................................................................................................... 12 VoLGA service provided in VPLMN........................................................................................................... 12 VoLGA SMS provided from HPLMN ......................................................................................................... 13 Reference points.................................................................................................................................................. 14

6
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10

Functional entities ..................................................................................................................................14

E-UTRAN ........................................................................................................................................................... 14 MME ................................................................................................................................................................... 14 S-GW and P-GW................................................................................................................................................. 14 VANC.................................................................................................................................................................. 14 HOSF................................................................................................................................................................... 15 UE........................................................................................................................................................................ 15 AAA Server......................................................................................................................................................... 15 MSC Server ......................................................................................................................................................... 15 PCRF ................................................................................................................................................................... 16 MSC/VLR ........................................................................................................................................................... 16

7
7.1 7.1.1 7.1.2 7.2 7.2.1 7.2.2 7.3 7.4 7.5

Protocol architecture ..............................................................................................................................16

VoLGA A-mode protocol architecture............................................................................................................... 16 Control plane ................................................................................................................................................. 16 User plane ...................................................................................................................................................... 17 VoLGA Iu-mode protocol architecture .............................................................................................................. 17 Control plane ................................................................................................................................................. 17 User plane ...................................................................................................................................................... 18 MME-HOSF protocol architecture ..................................................................................................................... 19 HOSF-MSC Server protocol architecture .......................................................................................................... 19 VANC-HOSF protocol architecture ................................................................................................................... 19

8
8.1 8.2 8.3 8.3.1 8.3.2

VoLGA states.........................................................................................................................................20
General ................................................................................................................................................................ 20 VoLGA Registration Management state model ................................................................................................. 20 VoLGA Connection Management state model .................................................................................................. 21 VCM state model for VoLGA A-mode ........................................................................................................ 21 VCM state model for VoLGA Iu-mode........................................................................................................ 22

9
9.1 9.1.1 9.1.2 9.1.3

Procedures for VoLGA A-mode ............................................................................................................22

Rove-in ................................................................................................................................................................ 22 General........................................................................................................................................................... 22 VANC discovery ........................................................................................................................................... 23 VoLGA registration....................................................................................................................................... 25

VoLGA Forum

Phase 1

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

9.1.4 9.2 9.2.1 9.2.2 9.3 9.3.1 9.3.2 9.4 9.4.1 9.4.2 9.5 9.5.1 9.5.2 9.6 9.7 9.8 9.8.1 9.9 9.10 9.11 9.12 9.12.1 9.12.2 9.13 9.13.1 9.13.2 9.14 9.15 9.16 9.17 9.18

VoLGA mode selection................................................................................................................................. 27 Rove-out .............................................................................................................................................................. 28 General........................................................................................................................................................... 28 VoLGA deregistration................................................................................................................................... 28 VoLGA registration update ................................................................................................................................ 29 Registration update downlink ....................................................................................................................... 29 Registration update uplink ............................................................................................................................ 30 Keep-Alive and Re-Synchronization.................................................................................................................. 31 Keep-Alive .................................................................................................................................................... 31 Re-Synchronization....................................................................................................................................... 32 GA-CSR connection handling ............................................................................................................................ 33 GA-CSR connection establishment .............................................................................................................. 33 GA-CSR connection release ......................................................................................................................... 34 Ciphering configuration ...................................................................................................................................... 35 NAS signalling .................................................................................................................................................... 35 Mobile-originated call......................................................................................................................................... 36 EPS bearer establishment for VoLGA user plane ........................................................................................ 39 Mobile-terminated call........................................................................................................................................ 39 Call clearing ........................................................................................................................................................ 41 Channel modification.......................................................................................................................................... 42 Handover ............................................................................................................................................................. 42 Handover from E-UTRAN to GERAN ........................................................................................................ 42 Handover from E-UTRAN to UTRAN ........................................................................................................ 47 Short Message Service ........................................................................................................................................ 49 Mobile-originated SMS................................................................................................................................. 49 Mobile-terminated SMS................................................................................................................................ 50 Supplementary services ...................................................................................................................................... 52 Emergency services............................................................................................................................................. 52 Location services................................................................................................................................................. 52 Lawful interception ............................................................................................................................................. 53 Location area update ........................................................................................................................................... 53

10

Procedures for VoLGA Iu-mode............................................................................................................54

Rove-in ................................................................................................................................................................ 54 Rove-out .............................................................................................................................................................. 54 VoLGA registration update ................................................................................................................................ 54 Keep-Alive and Re-Synchronization.................................................................................................................. 54 GA-RRC connection handling............................................................................................................................ 54 GA-RRC connection establishment.............................................................................................................. 54 GA-RRC connection release......................................................................................................................... 55 Security mode control ......................................................................................................................................... 56 NAS signalling .................................................................................................................................................... 57 Mobile-originated call......................................................................................................................................... 58 Mobile-terminated call........................................................................................................................................ 60 Call clearing ........................................................................................................................................................ 62 Call release .................................................................................................................................................... 62 Channel release.............................................................................................................................................. 63 Channel modification.......................................................................................................................................... 63 Handover ............................................................................................................................................................. 64 Handover from E-UTRAN to GERAN ........................................................................................................ 64 Handover from E-UTRAN to UTRAN ........................................................................................................ 69 Short Message Service ........................................................................................................................................ 70 Mobile-originated SMS................................................................................................................................. 70 Mobile-terminated SMS................................................................................................................................ 71 Supplementary services ...................................................................................................................................... 73 Emergency services............................................................................................................................................. 73 Location services................................................................................................................................................. 73 Lawful interception ............................................................................................................................................. 73 Location area update ........................................................................................................................................... 73 Create VANC-UE binding in HOSF .................................................................................................................. 74

10.1 10.2 10.3 10.4 10.5 10.5.1 10.5.2 10.6 10.7 10.8 10.9 10.10 10.10.1 10.10.2 10.11 10.12 10.12.1 10.12.2 10.13 10.13.1 10.13.2 10.14 10.15 10.16 10.17 10.18

11
11.1

HOSF procedures ...................................................................................................................................74

VoLGA Forum

Phase 1

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

11.2

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

12
12.1 12.2 12.2.1 12.2.2 12.2.3 A.1 A.2 A.2.1 A.2.2 A.3 A.4 A.5 B.1 B.2 B.3 B.3.1 B.3.2 B.4 B.4.1 B.4.2 C.1 C.2 C.3 D.1 D.2

VoLGA configuration mechanisms .......................................................................................................75

General ................................................................................................................................................................ 75 VoLGA configuration properties........................................................................................................................ 75 VANC discovery control............................................................................................................................... 75 Voice mode control ....................................................................................................................................... 75 Security configuration ................................................................................................................................... 75 General ................................................................................................................................................................ 76 IMS PS Voice or VoLGA Voice preferred ........................................................................................................ 77 EPS attach...................................................................................................................................................... 77 Combined EPS/IMSI attach .......................................................................................................................... 82 CS Voice preferred.............................................................................................................................................. 82 IMS PS Voice or PS Voice only......................................................................................................................... 84 CS Voice only ..................................................................................................................................................... 88 Authentication and key agreement ..................................................................................................................... 89 Encryption and integrity protection .................................................................................................................... 89 EAP-AKA procedures......................................................................................................................................... 89 EAP-AKA authentication procedure ............................................................................................................ 89 EAP-AKA fast re-authentication procedure................................................................................................. 91 VoLGA security profiles..................................................................................................................................... 93 Profile of IKEv2 ............................................................................................................................................ 93 Profile of IPsec ESP ...................................................................................................................................... 93 PDN connection management for VoLGA ........................................................................................................ 94 VoLGA signaling bearer..................................................................................................................................... 94 VoLGA user plane bearer ................................................................................................................................... 95 General ................................................................................................................................................................ 95 PLMN-ID verification via GIBA-like mechanism............................................................................................. 95

Annex A (normative): VoLGA coexistence with IMS & CSFB ......................................................................76

Annex B (normative): VoLGA security mechanisms ......................................................................................89

Annex C (informative): VoLGA PDN connection usage.................................................................................94

Annex D (informative): User location information verification for SMS-only service ...................................95

VoLGA Forum

Phase 1

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

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

VoLGA Forum

Phase 1

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

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.

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.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] VoLGA Forum: "Voice over LTE via Generic Access; Requirements Specification; Phase 1". 3GPP TS 43.318: "Generic Access Network (GAN); Stage 2". 3GPP TS 23.401: "GPRS enhancements for E-UTRAN access". 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2". 3GPP TS 23.203: "Policy and charging control architecture". 3GPP TS 44.318: "Generic Access Network (GAN); Mobile GAN interface layer 3 specification". 3GPP TS 23.271: "Functional stage 2 description of Location Services (LCS)". 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2". 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses". 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". 3GPP TS 23.228: "IP Multimedia Subsystem; Stage 2". 3GPP TS 23.272: "Circuit Switched Fallback in Evolved Packet System; Stage 2". 3GPP TS 23.292: "IP Multimedia System (IMS) centralized services, Stage 2". Void

VoLGA Forum

Phase 1

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

[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38]

3GPP TS 24.008: "Mobile radio interface layer 3 specification". IETF RFC 4187, January 2006: "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)". IETF RFC 4306, December 2005: "Internet Key Exchange (IKEv2) Protocol)". IETF RFC 2406, November 1998: "IP Encapsulating Security Payload (ESP)". IETF RFC 4282, December 2005: "The Network Access Identifier". IETF RFC 2451: "The ESP CBC-Mode Cipher Algorithms". IETF RFC 3602: "The AES-CBC Cipher Algorithm and Its Use with IPsec". IETF RFC 2104: "HMAC: Keyed-Hashing for Message Authentication". IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5". IETF RFC 2404: "The Use of HMAC-SHA-1-96 within ESP and AH". IETF RFC 2406: "IP Encapsulating Security Payload (ESP)". IETF RFC 3566: "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec". IETF RFC 2409: "The Internet Key Exchange (IKE)". IETF RFC 4434, February 2006: "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)". 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3". 3GPP TS 29.280: "Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN to MSC) for SRVCC". 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security Architecture". 3GPP TS 23.236: " Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes ". OMA-DDS-DM_ConnMO-V1_0-20081107-A: "Standardized Connectivity Management Objects", Approved Version 1.0 07 Nov 2008. 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode". 3GPP TS 23.221: "Architectural requirements". 3GPP TS 33.203: "3G security; Access security for IP-based services". 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
3.1

Definitions and abbreviations

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.

VoLGA Forum

Phase 1

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

VoLGA A-mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA GACSR entity VoLGA Iu-mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA GARRC 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
Authentication, Authorization and Accounting Application Function Authentication and Key Agreement Access Point Name Asynchronous Transfer Mode Base Station Subsystem Application Part Base Station Subsystem Management Application Part Call Control Cell Global Identification Ciphering Key Ciphering Key Sequence Number Connection Management Core Network Circuit Switched Dynamic Host Configuration Protocol Domain Name System Direct Transfer Application Part Dual Transfer Mode Extensible Authentication Protocol E-UTRAN Cell Global Identifier Evolved Packet Core Evolved Packet System Encapsulating Security Payload Evolved Universal Terrestrial Radio Access Network Fully Qualified Domain Name Generic Access Network Generic Access - Circuit Switched Resources Generic Access - Resource Control Generic Access - Radio Resource Control GSM EDGE Radio Access Network General Packet Radio Service GPRS Tunnelling Protocol GTP Control Plane GTP User Plane Globally Unique Temporary Identity Gateway Home Location Register Handover Selection Function Home PLMN Home Subscriber Server Internet Engineering Task Force Integrity Key Internet Key Exchange International Mobile station Equipment Identity and Software Version Number IP Multimedia Subsystem International Mobile Subscriber Identity Internet Protocol Key Set Identifier Layer 1

AAA AF AKA APN ATM BSSAP BSSMAP CC CGI CK CKSN CM CN CS DHCP DNS DTAP DTM EAP ECGI EPC EPS ESP E-UTRAN FQDN GAN GA-CSR GA-RC GA-RRC GERAN GPRS GTP GTP-C GTP-U GUTI GW HLR HOSF HPLMN HSS IETF IK IKE IMEISV IMS IMSI IP KSI L1

VoLGA Forum

Phase 1

10

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

L2 LA LAI MAC MAC MM MME MS MSC NAS PCO PCRF PDCP PDN PDP PLMN PS PSTN P-GW P-TMSI QCI QoS RA RAC RAI RAT RLC RNC RR RTCP RTP SCCP SAP SEGW SGSN SIM SMS SRVCC SS S-GW TAC TAI TAU TC TCP TDM TMSI UDP UE UMTS USSD VANC VCM VLR VoLGA VPLMN VRM

Layer 2 Location Area Location Area Identity Medium Access Control Message Authentication Code Mobility Management Mobility Management Entity Mobile Station Mobile Switching Center Non-Access Stratum Protocol Configuration Options Policy and Charging Rules Function Packet Data Convergence Protocol Packet Data Network Packet Data Protocol Public Land Mobile Network Packet Switched Public Switched Telephone Network PDN Gateway Packet - TMSI QoS Class Identifier Quality of Service Routing Area Routing Area Code Routing Area Identity Radio Access Technology Radio Link Control Radio Network Controller Radio Resource Real Time Control Protocol Real Time Protocol Signalling Connection Control Part Service Access Point SEcurity GateWay Serving GPRS Support Node Subscriber Identity Module Short Message Service Single Radio Voice Call Continuity Supplementary Service Serving Gateway Tracking Area Code Tracking Area Identity Tracking Area Update Transport Channel Transmission Control Protocol Time Division Multiplex Temporary Mobile Subscriber Identity User Datagram Protocol User Equipment Universal Mobile Telecommunication System Unstructured Supplementary Service Data VoLGA Access Network Controller VoLGA Connection Management Visited Location Register Voice over LTE via Generic Access Visited Public Land Mobile Network VoLGA Registration Management

VoLGA Forum

Phase 1

11

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

4
4.1
-

High level principles

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
4.2.1

High level functions

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.

VoLGA Forum

Phase 1

12

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

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.

Architecture model and reference points

5.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].
S6a Sv

HOSF

Sv

MSC Server

Z3

S1-c LTE Uu

MME S-GW P-GW

VANC
A or Iu-CS

UE

E-UTRAN
S1-u SGi

SeGW

MSC/ VLR

Gx

Rx

Wm

PCRF AAA Server

Z1 D

HLR/HSS

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 (PGW), 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").

VoLGA Forum

Phase 1

13

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

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").
S1-c LTE Uu

MME

S6a

UE

E-UTRAN
S1-u

S-GW

Gxc

S8

V-PCRF

VPLMN HPLMN
P-GW
SGi

VANC

A or Iu-CS

MSC/ VLR

S9

Gx

Rx

Wm

H-PCRF AAA Server

Z1 D

HLR/HSS

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.

VoLGA Forum

Phase 1

14

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

5.3
SGi: Sv:

Reference points
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 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 is the reference point between the UE and VANC, which is based on the Up interface defined in TS 43.318 [2]. 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.

Z1: Z3:

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

VoLGA Forum

Phase 1

15

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

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.

VoLGA Forum

Phase 1

16

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

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.

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.

VoLGA Forum

Phase 1

17

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

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.

VoLGA Forum

Phase 1

18

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

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.

VoLGA Forum

Phase 1

19

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

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

VoLGA Forum

Phase 1

20

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

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

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-RC DEREGISTERED

Successful registration

Deregistration event

GA-RC REGISTERED
(A-mode or Iu-mode)

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.

VoLGA Forum

Phase 1

21

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

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 a GERAN/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-RC REGISTERED (A-mode) GA-CSR
GA-CSR-IDLE

GA-CSR connection establishment

GA-CSR connection release

GA-CSRDEDICATED

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.

VoLGA Forum

Phase 1

22

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

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 GACSR 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-RC REGISTERED (Iu-mode) GA-RRC
GA-RRC-IDLE

GA-RRC connection establishment

GA-RRC connection release

GA-RRCCONNECTED

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 GARC REGISTERED state. The VCM entity in the UE moves from the GA-RRC-IDLE state to the GA-RRC-CONNECTED state when the GARRC 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).

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:

VoLGA Forum

Phase 1

23

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

1. VANC discovery 2. VoLGA registration

9.1.2 VANC discovery

9.1.2.1 General
The 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 address information

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 the resulting 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-low-byte>.tac-hb<TAC-high-byte>.tac.<rest of the domain name> The TAC is a 16 bit integer. <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and <TAC-low-byte > 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.

VoLGA Forum

Phase 1

24

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

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]: NOTE: 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). 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.

VoLGA Forum

Phase 1

25

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

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 preprocessing 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. If DNS resolution is successful, then the UE is ready to attempt VoLGA registration as described in sub-clause 9.1.3.

6.

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 another VANC (e.g., depending on the UE's location, load balancing or roaming condition), as illustrated in the following figure.

UE

EPS

SeGW

DNS

VANC

HOSF(s)

1. Establish secure tunnel to SeGW

2a. DNS query (VANC domain name)

2b. DNS response

3. Establish TCP connection to VANC

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

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

5b. GA-RC REGISTER ACCEPT (VoLGA System Information) 5c. Create VANC-UE binding on HOSF(s) 6. GA-RC REGISTER REJECT (Reject Cause)

7. GA-RC REGISTER REDIRECT (VANC address)

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). The UE is assigned its "remote IP address" (see sub-clauses 7.1.1 and 7.2.1) using the IKEv2 configuration payload procedure.

NOTE:

VoLGA Forum

Phase 1

26

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

2. 3.

If the UE received a VANC domain name during VANC discovery, the UE uses DNS to resolve the VANC domain name. 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). 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. 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.

4.

NOTE:

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

NOTE: -

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.

VoLGA Forum

Phase 1

27

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

5c. The VANC also creates a VANC-UE binding on one or more HOSFs. The VANC shall ensure that a VANCUE 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 between VANCs 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 a different 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 A-mode only Iu-mode only Both modes

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: Accept and indicate VoLGA Iu-mode

VANC: Handle as normal VoLGA A-mode registration. If required, redirect UE to VoLGA Amode capable VANC. UE: Proceed per VoLGA A-mode procedures VANC: Accept and indicate VoLGA Iu-mode

Iu-mode only

VANC: Redirect UE to VoLGA Iu-mode capable

VoLGA Forum

Phase 1

28

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

VANC or reject registration UE: Handle per registration redirection or reject procedures Both modes VANC: Accept and indicate VoLGA A-mode UE: Proceed per VoLGA A-mode procedures

UE: Proceed per VoLGA Iu-mode procedures

UE: Proceed per VoLGA Iu-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 (Note 1). If required, redirect UE to VoLGA Iu-mode or VoLGA A-mode capable VANC. UE: Proceed per VoLGA Iu-mode or VoLGA Amode 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. This involves 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 VoLGA signalling 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.

VoLGA Forum

Phase 1

29

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

Figure 9.2.2-1: VoLGA deregistration initiated by the UE 1. 2. 3. The UE sends the GA-RC DEREGISTER message to the VANC, which removes the UE context in the VANC. 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. 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 VANC

1. GA-RC REGISTER UPDATE DOWNLINK

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.

VoLGA Forum

Phase 1

30

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

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 GARC 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 registration update 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 VoLGA registration 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.

VoLGA Forum

Phase 1

31

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

Figure 9.3.2-1: VoLGA registration update uplink 1. 2. 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. 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 as specified in sub-clause 9.1.3. 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 offload UEs to other VANCs.

NOTE:

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

The VANC may deregister the UE by sending the GA-RC DEREGISTER message to the UE. 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 or the 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).

VoLGA Forum

Phase 1

32

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

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
9.4.2.1

Re-Synchronization
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 SYNCHRONIZATION INFORMATION (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. 2. 3. 4. 5. The UE sends a message to the VANC. The UE receives a TCP reset indicating a TCP connection failure. The UE successfully attempts to re-establish a TCP connection to the assigned VANC. The UE sends the GA-RC SYNCHRONIZATION INFORMATION (GA-RC SYNC INFO) message to the VANC to synchronize the UE state information. 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-initiated Re-Synchronization

The VANC-initiated Re-Synchronization procedure is used when the VANC detects a TCP connection failure.

VoLGA Forum

Phase 1

33

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

Figure 9.4.2.2-1: VANC-initiated Re-Synchronization 1. 2. The VANC detects a TCP connection failure (e.g., the VANC receives a TCP reset when it attempts to send a message to the UE). The VANC sends the GA-RC SYNCHRONIZATION COMMAND (GA-RC SYNC COMMAND) message to the UE using the stored UE IP address, UDP transport, and the pre-defined UDP port number for VANCinitiated Re-Synchronization.

3-5. Same as steps 3-5 in sub-clause 9.4.2.1. If the TCP connection could not be re-established, the VANC deregisters the UE locally.

9.5 GA-CSR connection handling

The GA-CSR connection is a logical connection between the UE and the VANC for the CS domain. It is established when the upper layers in the UE request GA-CSR to enter dedicated mode. When a successful response is received from the network, GA-CSR replies to the upper layer that it has entered dedicated mode. The upper layers then have the possibility to request transmission of NAS messages to the network. In the case of a network-initiated CS session, the GA-CSR connection is implicitly established and the UE enters dedicated mode when the UE responds to the GA-CSR PAGING REQUEST message from the VANC. This is illustrated in the sub-clauses describing mobile-terminated procedures (e.g., 9.9 and 9.13.2).

9.5.1 GA-CSR connection establishment

Figure 9.5.1-1 shows successful and unsuccessful establishment of the GA-CSR connection. This procedure is initiated by the UE in GA-CSR-IDLE state. After the successful completion of the procedure with the establishment of GA-CSR connection, the VCM state of the UE is GA-CSR-DEDICATED.

Figure 9.5.1-1: GA-CSR connection establishment 1. The UE initiates GA-CSR connection establishment by sending the GA-CSR REQUEST message to the VANC. This message contains the Establishment Cause indicating the reason for GA-CSR connection establishment.

VoLGA Forum

Phase 1

34

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

2. 3.

VANC signals the successful response to the UE by sending the GA-CSR REQUEST ACCEPT and the UE enters dedicated mode and the GA-CSR state changes to GA-CSR-DEDICATED. Alternatively, the VANC may return a GA-CSR REQUEST REJECT indicating the reject cause.

9.5.2 GA-CSR connection release

9.5.2.1 MSC-initiated connection release
Figure 9.5.2.1-1 shows release of the logical GA-CSR connection between the UE and the VANC when initiated from the MSC. After the successful completion of this procedure the VCM state of the UE is GA-CSR-IDLE.

Figure 9.5.2.1-1: GA-CSR connection release (MSC-initiated) 1. 2. 3. 4. The MSC indicates to the VANC to release the user plane connection allocated to the UE, via the BSSMAP Clear Command message. The VANC commands the UE to release the connection, using the GA-CSR RELEASE message. The VANC confirms the release to MSC using the BSSMAP Clear Complete message. The UE confirms connection release to the VANC using the GA-CSR RELEASE COMPLETE message and the GA-CSR state in the UE changes to GA-CSR-IDLE.

9.5.2.2 UE/VANC-requested connection release

The following figure shows release of the logical GA-CSR connection between the UE and the VANC when requested by the UE or by the VANC (i.e., due to abnormal conditions). This procedure is initiated when the UE is in the GACSR DEDICATED state. After the successful completion of the procedure the VCM state of the UE is GA-CSR-IDLE.

Figure 9.5.2.2-1: GA-CSR connection release (UE/VANC-requested) 1. 2. 3. The UE may initiate GA-CSR connection release by sending the GA-CSR CLEAR REQUEST message to the VANC. The message includes the cause indicating the reason for GA-CSR connection release. On receipt of the GA-CSR CLEAR REQUEST message from the UE or based on local conditions in the VANC, the VANC initiates the release by sending the BSSMAP Clear Request message to the MSC. The MSC triggers the release of connection as described in sub-clause 9.5.2.1.

VoLGA Forum

Phase 1

35

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

9.6 Ciphering configuration

The message flow for ciphering configuration is shown in Figure 9.6-1.

Figure 9.6-1: Ciphering configuration 1. 2. The MSC sends the BSSMAP Cipher Mode Command message to VANC. This message contains the cipher key Kc, and the encryption algorithms that the VANC may use. The VANC sends GA-CSR CIPHERING MODE COMMAND to the UE. This message indicates whether stream ciphering shall be started or not (i.e., after a subsequent handover to GERAN) and if so, which algorithm to use, and a random number. The UE stores the information for possible future use after a handover to GERAN. The message also indicates whether the UE shall include IMEISV in the GA-CSR CIPHERING MODE COMPLETE message. The UE computes a MAC based on the random number, the UE IMSI and the key Kc. The UE then sends the GA-CSR CIPHERING MODE COMPLETE message to the VANC which includes the selected algorithm, the computed MAC, and the IMEISV, if requested in the GA-CSR CIPHERING MODE COMMAND message. This VANC verifies the MAC. If the VANC verifies the MAC to be correct it sends a BSSMAP Cipher Mode Complete message to the MSC. The MAC proves that the identity that is authenticated to the VANC is the same as the identity authenticated to the MSC. The MSC configuration option of not enabling ciphering (i.e., not sending the Cipher Mode Command message) will therefore open up the network to more security threats than in GERAN.

3.

4.

NOTE:

9.7 NAS signalling

After GA-CSR connection establishment, NAS PDUs may be transferred from UE-to-MSC and from MSC-to-UE. The initial NAS PDU from the UE to the MSC is transferred in the GA-CSR UPLINK (UL) DIRECT TRANSFER message as illustrated in the following figure.

Figure 9.7-1: Initial UE-to-MSC NAS signalling 1. The UE GA-CSR entity receives a request from the NAS layer to transfer an initial uplink NAS-PDU. The UE GA-CSR entity encapsulates the NAS-PDU within a GA-CSR UL DIRECT TRANSFER message and sends the message to the VANC. The message includes the EPS TAI and the identity of the current camping EUTRAN cell. It also includes the Intra Domain NAS Node Selector (IDNNS) to be used by the VANC to route the establishment of a signalling connection to a MSC; i.e., using the "A Flex" functions specified in TS 23.236 [33]. Note that the use of IDNNS to convey the "A Flex" routing parameter (e.g., TMSI) differs from the

VoLGA Forum

Phase 1

36

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

mechanism in GERAN where the BSC is required to extract the routing parameter from the NAS-PDU. The use of IDNNS in VoLGA is consistent between VoLGA A-mode and VoLGA Iu-mode (see also sub-clause 10.7). 2. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC extracts the NAS-PDU, establishes an SCCP connection to the indicated MSC and forwards the initial NAS-PDU to the MSC using the BSSMAP Complete Layer 3 Information message.

Subsequent NAS PDUs from the UE to the MSC are transferred in the GA-CSR UPLINK (UL) DIRECT TRANSFER message as illustrated in the following figure.

Figure 9.7-2: UE-to-MSC NAS signalling 1. For UE-initiated NAS signalling (including SMS), the UE GA-CSR entity receives a request from the NAS layer to transfer an uplink NAS-PDU. The UE GA-CSR entity encapsulates the NAS-PDU within a GA-CSR UL DIRECT TRANSFER message and sends the message to the VANC. The VANC extracts the NAS-PDU, encapsulates it within a DTAP message and sends the message to the MSC.

2.

NAS PDUs from the MSC to the UE are transferred in the GA-CSR DOWNLINK (DL) DIRECT TRANSFER message as illustrated in the following figure.

Figure 9.7-3: MSC-to-UE NAS signalling 1. 2. For network-initiated NAS signalling (including SMS), the MSC sends a DTAP message to the VANC via the A interface. The VANC extracts the NAS-PDU and encapsulates it within a GA-CSR DL DIRECT TRANSFER message that is forwarded to the UE via the existing TCP connection.

9.8 Mobile-originated call

The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-CSR is the serving RR entity for CS services in the UE. It also assumes that no GA-CSR signalling connection exists between the UE and VANC; i.e., the GA-CSR entity in the UE is in the GA-CSR-IDLE state. If the GA-CSR entity in the UE is already in the GA-CSR-DEDICATED state, step 1 is skipped. A UE that is VoLGA registered for SMS-only shall not originate voice calls.

VoLGA Forum

Phase 1

37

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

UE 1. GA-CSR Connection Establishment

GA-CSRDEDICATED

VANC

MSC

2. GA-CSR UPLINK DIRECT TRANSFER (CM Service Request) 3. Complete L3 Info (CM Service Request) 4. Authentication 5. Ciphering configuration 6. GA-CSR UL DIRECT TRANSFER (Setup) 7. GA-CSR DL DIRECT TRANSFER (Call Proceeding) 8. Assignment Request 9. GA-CSR ACTIVATE CHANNEL 10. GA-CSR ACTIVATE CHANNEL ACK

11. Activate second EPS bearer for user data 12. GA-CSR ACTIVATE CHANNEL COMPLETE 13. Assignment Response 14. GA-CSR DL DIRECT TRANSFER (Alerting) 15. GA-CSR DL DIRECT TRANSFER (Connect) 16. GA-CSR UL DIRECT TRANSFER (Connect Ack) 17. Voice traffic (via second EPS bearer )

Figure 9.8-1: Mobile-originated call 1. 2. The GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1. Upon request from the upper layers, the UE sends the CM Service Request to the VANC in the GA-CSR UL DIRECT TRANSFER message. The message also includes the EPS TAI and the identity of the current camping E-UTRAN cell. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC establishes an SCCP connection to the MSC and forwards the CM Service Request to the MSC using the BSSMAP Complete Layer 3 Information message. Subsequent layer 3 messages between UE and the MSC are sent between VANC and MSC via DTAP. The MSC may optionally authenticate the UE using standard GSM authentication procedures. The MSC may optionally initiate the ciphering configuration procedure described in sub-clause 9.6. The UE sends the Setup message providing details on the call to the MSC and its bearer capability and supported codecs. This message is contained within the GA-CSR UL DIRECT TRANSFER message between the UE and the VANC. The VANC forwards the Setup message to the MSC. The MSC indicates it has received the call setup and it will accept no additional call-establishment information using the Call Proceeding message to the VANC. VANC forwards this message to the UE in the GA-CSR DL DIRECT TRANSFER message. The MSC requests the VANC to assign call resources using the BSSMAP Assignment Request message. The VANC sends the GA-CSR ACTIVATE CHANNEL message to the UE including bearer path setup information such as:

3.

4. 5. 6.

7.

8. 9.

VoLGA Forum

Phase 1

38

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

channel mode multi-rate codec configuration UDP port & the IP address for the uplink RTP stream voice sample size

10. The UE establishes the RTP path to the VANC. The UE sends the GA-CSR ACTIVATE CHANNEL ACK to the VANC indicating the UDP port for the downlink RTP stream. 11. The VANC initiates the activation of a second EPS bearer for the CS voice call using the Rx interface to the PCRF (see sub-clause 9.8.1). 12. The VANC establishes the downlink RTP path between the VANC and the UE. The VANC starts sending RTP packets to the UE (see Note 1 below). The VANC signals the completion of the bearer path to the UE with the GA-CSR ACTIVATE CHANNEL COMPLETE message. On receipt of the GA-CSR ACTIVATE CHANNEL COMPLETE message, the UE starts sending RTP packets to the VANC (see Note 2 below). 13. The VANC signals to the MSC that the call resources have been allocated by sending a BSSMAP Assignment Complete message. 14. The MSC signals to the UE, with the Alerting message, that the called party is ringing. The message is transferred to the VANC and the VANC forwards the message to the UE in the GA-CSR DL DIRECT TRANSFER message. If the UE has not connected the audio path to the user, it shall generate ring back to the calling party. Otherwise, the network-generated ring back will be returned to the calling party. 15. The MSC signals that the called party has answered, via the Connect message. The message is transferred to the VANC and VANC forwards the message to the UE in the GA-CSR DL DIRECT TRANSFER. The UE connects the user to the audio path. If the UE is generating ring back, it stops and connects the user to the audio path. 16. The UE sends the Connect Ack message in response, and the two parties are connected for the voice call. This message is contained within the GA-CSR UL DIRECT TRANSFER between the UE and the VANC. The VANC forwards the Connect Ack message to the MSC. 17. Bi-directional voice traffic flows between the UE and MSC through the VANC. NOTE 1: The RTP packet format is specified in TS 44.318 [7], sub-clause 7.4.3. NOTE 2: The RTP packet format is specified in TS 44.318 [7], sub-clause 7.4.4.

VoLGA Forum

Phase 1

39

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

9.8.1 EPS bearer establishment for VoLGA user plane

UE E-UTRAN MME S-GW P-GW PCRF VANC

1a. IP-CAN session modification request 1b. Ack 2. PCRF-initiated IP-CAN session modification (begin) 3. Create Dedicated Bearer Request 4. Create Dedicated Bearer Request 5. Bearer Setup Request 6. RRC Connection Reconfiguration 7. RRC Connection Reconfiguration Complete 8. Bearer Setup Response 9. Create Dedicated Bearer Response 10. Create Dedicated Bearer Response 11. PCRF-initiated IP-CAN session modification (end) 12a. Notification of bearer level event 12b. Ack

Figure 9.8.1-1: EPS bearer establishment for VoLGA user plane The following description is per TS 23.401 [3], sub-clause 5.4.1. 1. The VANC, acting as an Application Function (AF), requests IP-CAN session modification by the PCRF; i.e., to add a dedicated VoIP-capable bearer to the UE session. If the bearer is for an emergency call, the VANC includes an indication in the bearer request. The VANC also requests subscription to notification of bearer level events related to the service information. The PCRF sends an acknowledgement to the VANC.

2-11. These steps are the same as steps 1-10 in TS 23.401 [3], sub-clause 5.4.1 "Dedicated bearer activation". 12. The PCRF notifies the VANC of the related bearer level events (e.g. transmission resources have been successfully established). The VANC acknowledges the notification from the PCRF.

9.9 Mobile-terminated call

The description of the procedure in this clause assumes that the UE has successfully registered with the VANC and GACSR is the serving RR entity for CS services in the UE.

VoLGA Forum

Phase 1

40

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

Figure 9.9-1: Mobile-terminated call 1. A mobile-terminated call arrives at the MSC. The MSC sends a BSSMAP Paging message to the VANC identified through the last Location Update received by the MSC and includes the TMSI if available. The IMSI of the UE being paged is always included in the request. The VANC identifies the UE registration context using the IMSI provided by the MSC. It then pages the UE using the GA-CSR PAGING REQUEST message. The message includes the TMSI, if available in the request from the MSC; otherwise, the MSC includes only the IMSI of the UE. The UE responds with a GA-CSR PAGING RESPONSE message including the MS Classmark and Ciphering Key Sequence Number. The message also includes the EPS TAI, the identity of the current camping EUTRAN cell, and the Intra Domain NAS Node Selector (IDNNS) to be used by the VANC to route the establishment of a signalling connection to a MSC; i.e., using the "A Flex" functions specified in TS 23.236 [33] (see comment in sub-clause 9.7). The UE enters dedicated mode and the GA-CSR state changes to GACSR-DEDICATED. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC establishes an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the BSSMAP Complete Layer 3 Information message. The MSC may optionally authenticate the UE using standard GSM authentication procedures. The MSC may optionally update the ciphering configuration in the UE, via the VANC, as described in subclause 9.6.

2.

3.

4.

5. 6.

VoLGA Forum

Phase 1

41

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

7. 8.

The MSC initiates call setup using the Setup message sent to the UE via the VANC. The VANC forwards this message to the UE in the GA-CSR DL DIRECT TRANSFER message. In case the UE is not registered for SMS-only service, the UE responds with Call Confirmed message in the GA-CSR UL DIRECT TRANSFER message after checking it's compatibility with the bearer service requested in the Setup message and modifying the bearer service as needed. If the Setup message included the signal information element, the UE alerts the user using the indicated signal; otherwise, the UE alerts the user after the successful configuration of the user plane. The VANC forwards the Call Confirmed message to the MSC. In case the UE is registered for SMS-only service and the UE determines from the Setup message that the setup is for MT call, the UE shall send a DISCONNECT message with the cause #79 "service or option not implemented, unspecified". Step 9 onwards are not performed in this case.

9-14. The MSC initiates the assignment procedure with the VANC, which triggers the setup of the RTP stream (voice bearer channel) between the VANC and UE, same as steps 8-13 in the MO call scenario in sub-clause 9.8. 15. The UE signals that it is alerting the user, via the Alerting message contained in the GA-CSR UL DIRECT TRANSFER message. The VANC forwards the Alerting message to the MSC. The MSC sends a corresponding alerting message to the calling party. 16. The UE signals that the called party has answered, via the Connect message contained in the GA-CSR UL DIRECT TRANSFER message. The VANC forwards the Connect message to the MSC. The MSC sends a corresponding Connect message to the calling party and through connects the audio. The UE connects the user to the audio path. 17. The MSC acknowledges via the Connect Ack message to the VANC. VANC forwards this message to the UE in the GA-CSR DL DIRECT TRANSFER message. The two parties on the call are connected on the audio path. 18. Bi-directional voice traffic flows between the UE and MSC through the VANC.

9.10 Call clearing

Figure 9.10-1 shows call clearing initiated by the UE.

Figure 9.10-1: UE-initiated call clearing 1. The UE sends the Disconnect message to the MSC to release the call. This message is contained in the GACSR UL DIRECT TRANSFER message between UE and VANC. The VANC forwards the Disconnect message to the MSC. The MSC responds with a Release message to the VANC. The VANC forwards this message to the UE using the GA-CSR DL DIRECT TRANSFER message. The UE responds with the Release Complete message. This message is contained within the GA-CSR UL DIRECT TRANSFER message between UE and VANC. The VANC forwards the Release Complete message to the MSC.

2. 3.

VoLGA Forum

Phase 1

42

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

4. 5.

The MSC triggers the release of connection as described in sub-clause 9.5.2.1. In parallel with step 4, the VANC initiates the deactivation of the second EPS bearer for the CS voice call using the Rx interface to the PCRF.

9.11 Channel modification

The VANC may use the channel modification procedure to modify parameters used for an ongoing call. This procedure may be used if the voice coding scheme should be changed, or in fault or congestion situations; e.g., if the VANC detects "packet loss" and handover to GERAN/UTRAN is not possible or desired. The VANC may modify the following parameters: - Channel Mode - Sample Size - VANC IP Address for the uplink RTP stream - RTP UDP Port - RTCP UDP Port

Figure 9.11-1: Channel modification 1. 2. 3. 4. A call is established as described in sub-clauses 9.9 or 9.10. The VANC sends the GA-CSR CHANNEL MODE MODIFY message to the UE to modify parameters for the established call. The UE responds with the GA-CSR CHANNEL MODE MODIFY ACKNOWLEDGE message to the VANC. Optionally, the VANC initiates the modification of the second EPS bearer using the Rx interface to the PCRF, using the procedure described in sub-clause 9.8.1.

9.12 Handover
9.12.1 Handover from E-UTRAN to GERAN
9.12.1.1 General

The following table summarizes the eNodeB behaviour related to handover and cell change to GERAN.

VoLGA Forum

Phase 1

43

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

Table 9.12.1.1-1: Scenarios for handover and cell change to GERAN Target GERAN supports: Scenario (Note 1) 1 2 3 4 5 VoIP bearer active for VoLGA? No No No No Yes PS HO? DTM HO? Source eNodeB initiates:

No No Yes Yes No

No Yes No Yes No

NACC n/a PS Handover PS Handover CS Handover (VoIP bearer only) PS bearers suspended n/a CS Handover (VoIP bearer only) PS bearers suspended CS+PS Handover (All bearers)

6 7

Yes Yes

No Yes

Yes No

8a

Yes

Yes

Yes (and UE supports DTM & DTM HO) Yes (but UE doesnt support DTM) Yes (and UE supports DTM but not DTM HO)

8b

Yes

Yes

CS Handover (VoIP bearer only) PS bearers suspended CS Handover (VoIP bearer only) UE RAU after CS Handover moves PS bearers to GERAN

8c

Yes

Yes

NOTE 1: When a voice bearer is active and the target GERAN supports both PS handover and DTM (scenarios 8a, 8b and 8c), the UEs DTM capabilities determine the behaviour of the handover. In the other scenarios the handover behaviour is independent of the UEs DTM capabilities. NOTE 2: DTM handover support is an optional additional functionality for UEs that support DTM. - Scenario 1 is illustrated in sub-clause 9.12.1.6. - Scenarios 2 and 6 are not possible since we assume that the target GERAN must support PS handover if it supports DTM handover. - Scenarios 3 and 4 are described in sub-clause 9.12.1.4. - Scenarios 5, 7 and 8b are illustrated in sub-clause 9.12.1.2. - Scenario 8a is illustrated in sub-clause 9.12.1.3. - Scenario 8c is illustrated in sub-clause 9.12.1.5.

VoLGA Forum

Phase 1

44

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

9.12.1.2 Handover of VoLGA call to GERAN without DTM handover support or for UE without DTM support
The following figure illustrates the VoLGA call handover from E-UTRAN to GERAN, assuming that DTM handover is not supported in the target GERAN.
UE Source E-UTRAN Source MME HOSF Serving VANC Serving MSC Target MSC Target BSS

1. Measurement Reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting 5a. PS to CS Request 5b. PS to CS Request 6. Handover Required 7. Prepare Handover Request 8. Handover Request/Ack 9. Prepare Handover Response 10. Establish circuit 11. Handover Command 12. PS to CS Response 13. Handover Command 14. Handover from E-UTRAN Command

15. UE tunes to GERAN 16. Handover Detection 17. Suspend procedure as described for SRVCC in 3GPP TS 23.216, sub-clause 6.2.2.1 18. Handover Complete 19. Send End Signal (Handover Complete) 20. Answer 21. Clear Command 22. PS to CS Complete/Ack 23. Release Resources 24. Clear Complete

Figure 9.12.1.2-1: Handover of VoLGA call to GERAN without DTM handover support or for UE without DTM support A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. 5. The MME sends a SRVCC PS to CS Request message to the HOSF. The content of the SRVCC PS to CS Request message is the same as described in TS 23.216 [5], sub-clause 6.2.2.1. The HOSF forwards the SRVCC PS to CS Request message to the current serving VANC, without modifying the message content. The HOSF identifies the UE using the IMSI received in the message. The HOSF identifies the current serving VANC based on the stored VANC-UE binding information. If the HOSF does not have a record of the serving VANC for the UE, then the HOSF assumes that this is a request for SRVCC handover. Therefore, the HOSF forwards the SRVCC PS to CS Request messagewithout modifying the message contentto the MSC Server enhanced for SRVCC, selected based on the target cell information in the Source to Target Transparent Container, and the rest of this procedure is not applicable. 6. The VANC converts the SRVCC PS to CS Request into a CS handover request by sending a BSSMAP Handover Required message to the MSC that is currently serving the VoLGA call.

VoLGA Forum

Phase 1

45

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

7-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. 11. The serving MSC sends a BSSMAP Handover Command message to the VANC, containing the GERAN RR Handover Command message encapsulated in the "Layer 3 Information" IE. 12. The VANC sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the source MME. The VANC gets the source MME address from the IE 'MME/SGSN Sv Address for Control Plane' received in the SRVCC PS to CS Request. The VANC includes its Z3 interface IP address in the IE 'MSC Server Sv Address for Control Plane'; this allows subsequent SRVCC messaging for the handover to bypass the HOSF. The source MME knows that at the end of the PS-CS handover the non-GBR bearers should be preserved. 13-20. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 21. The serving MSC sends a Clear Command message to the VANC to request release of the resources that had been allocated for the call. 22. The VANC sends a SRVCC PS to CS Complete Notification message to the source MME, informing it that the UE has arrived on the target side. The source MME acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the VANC. 23. The source MME releases the E-UTRAN resources allocated to the UE. 24. The VANC sends the Clear Complete message to the serving MSC indicating that the VANC has released the resources that had been allocated for the call. After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060 [4]) the UE shall resume PS services by sending a Routeing Area Update Request message to the SGSN. The Update Type depends on the mode of operation of the GERAN network; e.g., in mode I a Combined RA/LA Update is used and in mode II or III Routeing Area Update is used. NOTE: From the perspective of the UE, the E-UTRAN and the MME, this flow is identical to the SRVCC handover flow as specified in TS 23.216 [5].

9.12.1.3

Handover of VoLGA call to GERAN with DTM handover support

The following figure illustrates the VoLGA call handover from E-UTRAN to GERAN, assuming that DTM handover is supported in the target GERAN.

VoLGA Forum

Phase 1
Source E-UTRAN Source MME

46
Serving VANC Target SGSN

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

Serving MSC SGW Target MSC Target BSS

UE

HOSF

1. Measurement Reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting

5. SRVCC PS to CS handover preparation 6a. Forward Relocation Request 6b. PS Handover Request 6c. PS Handover Request Ack 6d. Forward Relocation Response 7. Handover Command 8. Handover from E-UTRAN Command

9. UE tunes to GERAN 10. Handover Detection

11. SRVCC PS to CS handover completion 12a. PS Handover Complete 12b. Forward Relocation Complete/Ack 12c. Update bearer

Figure 9.12.1.3-1: Handover of VoLGA call to GERAN with DTM handover support A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. 5. The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 9.12.1.2, steps 5-12.

6-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 11. The SRVCC PS to CS handover completion procedure is performed, as described in sub-clause 9.12.1.2, steps 18-24. 12. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2.

9.12.1.4

Handover to GERAN of VoLGA signalling channel without active voice bearer

The following figure illustrates the handover of the VoLGA signalling channel from E-UTRAN to GERAN when no voice bearer is active prior to the handover; for example, during an SMS transfer, supplementary service transaction, or a call where the voice bearer has not yet been established.

VoLGA Forum

Phase 1

47

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

Figure 9.12.1.4-1: Handover to GERAN of VoLGA signalling channel without active voice bearer 1-9. The active PS bearers are handed over to GERAN per the procedures described in TS 23.401 [3]. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see subclause 9.2). If the UE is in an active CS signalling session (e.g., an SMS, SS, or call that has not yet established the QCI=1 bearer) and EPS has decided a handover to GERAN is necessary, the UE disregards the presence of the CS transaction and ceases to send or respond to GA- and higher layer communications associated with the CS transaction. The UE performs a routing area update following the EPS to GERAN handover procedure as described in TS 23.401 [3]. A location area update may be combined with the routing area (RA) update as specified in TS 23.401 [3] and TS 23.060 [4] or may follow the completion of the RA update.

9.12.1.5 Handover of VoLGA call to GERAN with DTM handover support (UE supports DTM but does not support DTM handover)
The call flow for this scenario is similar to the call flow depicted in figure 9.12.1.2-1, with the exception that the Suspend procedure (step 17 in figure 9.12.1.2-1) is not performed. Instead, at the end of the procedure described in figure 9.12.1.2-1, the UE transfers the PS bearer contexts to GERAN by performing the RAU as described in TS 23.060 [4].

9.12.1.6

Network Assisted Cell Change (NACC) from E-UTRAN to GERAN

The following figure illustrates NACC from E-UTRAN to GERAN.

Figure 9.12.1.6-1: NACC from E-UTRAN to GERAN 1. The NACC procedure is executed per 3GPP standards. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2).

9.12.2 Handover from E-UTRAN to UTRAN

9.12.2.1 Handover of VoLGA call to UTRAN

The following figure illustrates the VoLGA call handover from E-UTRAN to UTRAN.

VoLGA Forum

Phase 1
Source E-UTRAN Source MME

48
Serving VANC Target SGSN

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

Serving MSC SGW Target MSC Target RNS

UE

HOSF

1. Measurement Reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting

5. SRVCC PS to CS handover preparation 6. PS relocation preparation 7. Handover Command 8. Handover from E-UTRAN Command

9. UE tunes to UTRAN 10. Handover Detection 11. SRVCC PS to CS handover completion 12. PS relocation completion

Figure 9.12.2.1-1: Handover of VoLGA call to UTRAN A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. 5. The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 9.12.1.2, steps 5-12, with the exception that the target MSC exchanges the Relocation Request/Request Ack messages with the target RNS in step 8 (versus Handover Request/Request Ack with the target BSS in sub-clause 9.12.1.2).

6-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. After switching the serving RR entity to UTRAN RRC, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 11. The SRVCC PS to CS handover completion procedure is performed, as described in sub-clause 9.12.1.2, steps 18-24, with the exception that the target RNS sends the Relocation Complete message to the target SGSN in step 18 (versus Handover Complete in sub-clause 9.12.1.2). 12. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2.

9.12.2.2

Handover to UTRAN of VoLGA signalling channel without active voice bearer

The following figure illustrates the handover of the VoLGA signalling channel from E-UTRAN to UTRAN when no voice bearer is active prior to the handover; for example, during an SMS transfer, supplementary service transaction, or a call where the voice bearer has not yet been established.

VoLGA Forum

Phase 1

49

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

Figure 9.12.2.2-1: Handover to UTRAN of VoLGA signalling channel without active voice bearer 1-9. The active PS bearers are relocated to UTRAN per the procedures described in TS 23.401 [3]. After switching the serving RR entity to UTRAN RRC, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). If the UE is in an active CS signalling session (e.g., an SMS, SS, or call that has not yet established the QCI=1 bearer) and EPS has decided a handover to UTRAN is necessary, the UE disregards the presence of the CS transaction and ceases to send or respond to GA- and higher layer communications associated with the CS transaction. The UE performs a routing area update following the EPS to UTRAN handover procedure as described in TS 23.401 [3]. A location area update may be combined with the routing area (RA) update as specified in TS 23.401 [3] and TS 23.060 [4] or may follow the completion of the RA update.

9.13 Short Message Service

SMS support is based on the same mechanism that is utilized for GSM mobility management and call control. On the UE side, the SMS layers (including the supporting CM sub layer functions) utilize the services of the MM layer to transfer SMS messages per standard circuit switched GSM implementation. The SM-CP protocol is effectively tunnelled between the UE and the MSC, using GA-CSR messages from the UE to the VANC, where the VANC relays the SM-CP to BSSAP DTAP messages for transport over the A interface. As with GSM mobility management and call control procedures, the secure IPsec tunnel and TCP session are used to provide secure and reliable SMS delivery over the IP network.

9.13.1 Mobile-originated SMS

The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-CSR is the serving RR entity for CS services in the UE. It also assumes that no GA-CSR signalling connection exists between the UE and VANC; i.e., the CS domain GA-CSR entity in the UE is in the GA-CSR-IDLE state. If the CS domain GA-CSR entity in the UE is already in the GA-RRC-DEDICATED state, step 1 is skipped.

VoLGA Forum

Phase 1

50

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

Figure 9.13.1-1: Mobile-originated SMS 1. 2. The CS GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1. The UE sends the CM Service Request message to the VANC within the GA-CSR UPLINK DIRECT TRANSFER message. The message includes the EPS TAI and the identity of the current camping E-UTRAN cell. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC establishes an SCCP connection to the MSC and forwards the NAS PDU (i.e., the CM Service Request message) to the MSC using the BSSMAP Complete Layer 3 Information message. The MSC may optionally authenticate the UE using standard GSM authentication procedures. The MSC may optionally initiate the Cipher Mode Control procedure described in sub-clause 9.6. The MSC signals acceptance of the MO SMS request. The UE sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the MSC. The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the UE. The MSC relays the response received from the IWMSC (not shown) to the VANC in the CP-DATA message. The VANC relays this to the UE.

3.

4. 5. 6. 7. 8. 9.

10. The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the MSC. 11. The MSC triggers the release of connection as described in sub-clause 9.5.2.1.

9.13.2 Mobile-terminated SMS

The description of the procedure in this clause assumes that the UE has successfully registered with the GANC and GACSR is the serving RR entity for CS services in the UE.

VoLGA Forum

Phase 1

51

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

Figure 9.13.2-1: Mobile-terminated SMS 1. A mobile-terminated SMS arrives at the MSC. The MSC sends a BSSMAP Paging message to the VANC identified through the last Location Update received by it and includes the TMSI if available. The IMSI of the mobile being paged is always included in the request. The VANC identifies the UE registration context using the IMSI provided by the MSC. It then pages the UE using the GA-CSR PAGING REQUEST message. The message includes the TMSI, if available in the request from the MSC; else it includes only the IMSI of the UE. The UE responds with a GA-CSR PAGING RESPONSE message. The message includes the EPS TAI and the identity of the current camping E-UTRAN cell. The CS domain GA-CSR entity in the UE transitions to the GA-CSR-DEDICATED state. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC establishes an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the BSSMAP Complete Layer 3 Information message. The MSC may optionally authenticate the UE using standard GSM authentication procedures. The MSC may optionally initiate the Cipher Mode Control procedure described in sub-clause 9.6. The MSC sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the UE. The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the MSC. The UE sends a response to the VANC in the CP-DATA message. The VANC relays this to the MSC.

2.

3.

4.

5. 6. 7. 8. 9.

10. The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the UE. 11. The MSC triggers the release of connection as described in clause 9.5.2.1.

VoLGA Forum

Phase 1

52

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

9.14 Supplementary services

GSM has a large number of standardized supplementary services. These supplementary services involve procedures that operate end-to-end between the UE and the MSC. The NAS messages used for the supplementary service are relayed between the UE and MSC in the same manner as in the other call control and mobility management scenarios described in this specification.

9.15 Emergency services

For a UE with a valid USIM and obtaining normal service in a PLMN as defined in TS 23.122 [35], emergency services can, based on operator preference, be supported either by VoLGA in E-UTRAN or via the CS domain in GERAN/UTRAN. The VANC can indicate, in the VoLGA Registration procedures, an access network preference for the placement of emergency calls. If the access network preference is GERAN/UTRAN, and if GERAN/UTRAN coverage is available (either from the VoLGA subscribers home PLMN or from any roamed to PLMN), the UE shall autonomously switch from VoLGA mode to GERAN/UTRAN mode and place the emergency call over GERAN/UTRAN. NOTE: After completion of the emergency call the UE may stay in GERAN/UTRAN for a specific amount of time to leverage the location determination infrastructure in GERAN/UTRAN for call-back. However, this behavior is covered in relevant 3GPP specifications and is not VoLGA specific.

If the access network preference is E-UTRAN, and if E-UTRAN coverage is available (either from the VoLGA subscribers home PLMN or from any roamed to PLMN), the UE places the emergency call over VoLGA via the MSC. The VANC detects that an emergency call is being set up based on: - the Establishment Cause IE in the GA-CSR/RRC Request message, and/or; - the priority value included in the Assignment Request or RAB Assignment Request message. The use of the priority value to detect an emergency call is based on operator configuration. The VANC must ensure that the MSC gets a proper Cell Global ID (CGI) for routing of the emergency call to an appropriate PSAP. The VANC provides an Emergency Indicator to the PCRF via the Rx interface as specified in TS 23.203 [6] in order to establish the EPS bearer for emergency voice. A VoLGA UE which is CS voice capable, in limited service state, should always camp on a RAT which is likely to support the CS domain, e.g. GERAN or UTRAN as specified in TS 23.221 [36] and place an emergency call in the GERAN/UTRAN CS domain.

9.16 Location services

The VANC shall be able to retrieve network-based location information using 3GPP standardized mechanisms, such as Location Services (LCS), Any Time Interrogation (ATI), Policy and Charging Control (PCC) as follows: LCS: the UEs location is queried from the MME as specified in TS 23.271 [8] (see below); ATI: the UEs location is queried from the MME using the same interface as used by the HLR/HSS in the ATI procedure (i.e., the Insert Subscriber Data procedure specified in TS 29.272 [38]); The UEs location is obtained based on interaction with the PCRF as specified in TS 23.203 [6]; The UEs location is queried from an AAA server located on the Gi / SGi interface (see Annex D);

Note: the selection of any of the above mechanisms is based on operator preference. If using LCS, the VANC uses the control-plane LCS architecture defined in TS 23.271 [8]. The VANC will behave like a GMLC requesting the MME to perform standard LCS procedure in order to get the location information. The MME is selected based on the GUTI provided by the UE. CS-NI-LR and CS-MT-LR services are supported in VoLGA, and the VoLGA UE performs MO-LR in EPS.

VoLGA Forum

Phase 1

53

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

The VANC may initiate such LCS procedure to get the location information in order to verify the EPS location information (i.e. ECGI, TAI) provided by UE. Details on the conditions for the VANC to trigger the LCS procedure are implementation specific. If the verification fails, the VANC acts according to operator policy; e.g., the VANC may ignore the EPS location information provided by the UE and map the EPS location information provided by the MME to the CS location information (i.e., VoLGA LAI, GERAN CGI or UTRAN SAI) transferred to the MSC, or the VANC may terminate the ongoing procedure, or the VANC may immediately deregister the UE.

9.17 Lawful interception

For the non-roaming and roaming architecture with local break-out the lawful interception architecture and mechanisms specified for the CS domain are used.

9.18 Location area update

The UE performs a location area update when the current VoLGA LAI is not the same as the stored LAI. The CS domain MM layer is responsible for the comparison when it obtains the VoLGA LAI from the VoLGA GA-RC layer. The following triggers for the VoLGA GA-RC layer providing VoLGA LAI apply: - When the VoLGA GA-RC entity receives the VoLGA LAI from the VANC during the Registration or Registration Update procedure, it stores the new VoLGA LAI and then offers it to the upper CS domain MM layer. - When the UE in GA-RC REGISTERED state reselects to E-UTRAN and the VoLGA registration update uplink procedure is not triggered (refer to sub-clause 9.3.2), the VoLGA GA-RC entity offers the stored VoLGA LAI to the upper CS domain MM layer. The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-CSR is the serving RR entity for CS services in the UE. It also assumes that no GA-CSR signalling connection exists between the UE and VANC; i.e., the GA-CSR entity in the UE is in the GA-CSR-IDLE state. If the GA-CSR entity in the UE is already in the GA-CSR-DEDICATED state, step 1 is skipped.

Figure 9.18-1: Location area update 1. 2. The CS GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1. The UE sends the Location Updating Request message to the VANC within the GA-CSR UPLINK DIRECT TRANSFER message. The GA-CSR UPLINK DIRECT TRANSFER message includes the EPS TAI and the identity of the current camping E-UTRAN cell. The Location Updating Request message includes the LAI associated with the last successful location area update procedure. The VANC maps the received EPS information to a corresponding GERAN CGI value. The VANC establishes an SCCP connection to the MSC and forwards the NAS PDU (i.e., the Location Updating Request message) to

3.

VoLGA Forum

Phase 1

54

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

the MSC using the BSSMAP Complete Layer 3 Information message, including the VoLGA LAI value currently assigned to the UE and the mapped GERAN CGI value. 4. 5. 6. 7. The MSC may optionally authenticate the UE using standard GSM authentication procedures. The MSC may optionally initiate the Cipher Mode Control procedure described in sub-clause 9.6. The MSC signals acceptance of the location update request. The MSC triggers the release of connection as described in sub-clause 9.5.2.1.

Note: The timing of the MSC release of the connection is per TS 24.008 [16]; e.g., additional "follow-on" NAS signalling may occur after step 6. Note: Location update is only initiated by the UE. Per 3GPP standards, the UE does not perform a location update during an active call.

10

Procedures for VoLGA Iu-mode

10.1 Rove-in
See sub-clause 9.1.

10.2 Rove-out
See sub-clause 9.2.

10.3 VoLGA registration update

See sub-clause 9.3.

10.4 Keep-Alive and Re-Synchronization

See sub-clause 9.4.

10.5 GA-RRC connection handling

The GA-RRC connection is a logical connection between the UE and the VANC. A GA-RRC connection is established when the upper layers in the UE request the establishment of a signalling connection for the CS domain and the UE is in the GA-RRC-IDLE state; i.e., no GA-RRC connection exists. When a successful response is received from the network, GA-RRC replies to the upper layer that the UE has entered the RRC connected mode (i.e., the GA-RRC-CONNECTED state). The upper layers then have the possibility to request transmission of NAS messages to the network. In the case of a network-initiated CS session, the GA-RRC connection is implicitly established and the UE enters the RRC connected mode when the UE responds to the GA-RRC PAGING REQUEST message from the VANC with the GA-RRC INITIAL DIRECT TRANSFER containing the paging response. This is illustrated in the sub-clauses describing the mobile-terminated procedures (e.g., 10.9 and 10.13.2).

10.5.1 GA-RRC connection establishment

The following figure shows successful and unsuccessful establishment of the GA-RRC connection for the CS domain.

VoLGA Forum

Phase 1

55

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

Figure 10.5.1-1: GA-RRC connection establishment 1. The UE initiates GA-RRC connection establishment by sending the GA-RRC REQUEST message to the VANC. The message includes the CN Domain identity (CS) and the Establishment Cause indicating the reason for GARRC connection establishment. 2. The VANC signals the acceptance of the connection request to the UE by sending the GA-RRC REQUEST ACCEPT and the UE enters the GA-RRC-CONNECTED state. 3. If the VANC determines that the GA-RRC connection request shall be rejected, it sends a GA-RRC REQUEST REJECT to the UE indicating the reject cause, completing the procedure.

10.5.2 GA-RRC connection release

10.5.2.1 MSC-initiated connection release

Figure 10.5.2.1-1 shows release of the logical GA-RRC connection between the UE and the VANC when initiated from the MSC.

Figure 10.5.2.1-1: GA-RRC connection release (MSC-initiated) 1. The MSC directs the VANC to release the resources allocated to the UE, via the RANAP Iu Release Command message. 2. The VANC commands the UE to release resources, using the GA-RRC RELEASE message. The message includes the CN Domain Identity (CS). 3. The VANC confirms resource release to the MSC using the Iu Release Complete message. The VANC may optionally wait for receipt of the GA-RRC RELEASE COMPLETE message from the UE before sending the Iu Release Complete message to the MSC. 4. The UE confirms resource release to the VANC using the GA-RRC RELEASE COMPLETE message and the GA-RRC state of the CS domain GA-RRC entity in the UE changes to GA-RRC-IDLE.

VoLGA Forum

Phase 1

56

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

10.5.2.2

UE/VANC-requested connection release

The following figure shows release of the logical GA-RRC connection between the UE and the VANC when requested by the UE or by the VANC (i.e., due to abnormal conditions).

Figure 10.5.2.2-1: GA-RRC connection release (UE/VANC-requested) 1. 2. 3. The UE initiates GA-RRC connection release by sending the GA-RRC RELEASE REQUEST message to the VANC. The message includes the cause indicating the reason for GA-RRC connection release. On receipt of the GA-RRC RELEASE REQUEST from the UE or based on local conditions in the VANC, the VANC initiates the release by sending the RANAP Iu Release Request message to the MSC. The MSC triggers the release of connection as described in sub-clause 10.5.2.1.

10.6 Security mode control

The message flow for security mode control is shown in the following figure.

Figure 10.6-1: Security mode control 1. The MSC sends the RANAP Security Mode Command message to the VANC. This message contains the integrity key (IK) and allowed algorithms, and optionally the cipher key (CK) and allowed algorithms. 2. The VANC selects the integrity algorithm and (optionally) the ciphering algorithm based on the permitted algorithms received from the MSC and the UE security capabilities indicated in the IE "3G Security Capability" received from the UE in the GA-RC REGISTER REQUEST message. The VANC sends the GA-RRC SECURITY MODE COMMAND message to the UE. This message indicates the selected integrity protection algorithm and ciphering algorithm (i.e., that are applicable after handover to UTRAN), and a random number. The UE stores the information for possible future use after a handover to UTRAN. 3. The UE computes a MAC based on the random number, the UE IMSI and the integrity key. The UE then sends the GA-RRC SECURITY MODE COMPLETE message including the computed MAC. 4. The VANC verifies the MAC. If the VANC verifies the MAC to be correct, it sends the Security Mode Complete message to the MSC.

VoLGA Forum

Phase 1

57

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

NOTE:

The MAC proves that the identity that is authenticated to the VANC is the same as the identity authenticated to the core network.

10.7 NAS signalling

After GA-RRC connection establishment, NAS PDUs may be transferred from MSC-to-UE and from UE-to-MSC. The initial NAS PDU from the UE to the MSC is transferred in the GA-RRC INITIAL DIRECT TRANSFER message as illustrated in the following figure. This scenario assumes that a GA-RRC connection already exists between the UE and VANC; if not, the procedure described in sub-clause 10.5.1 is performed before step 1.

Figure 10.7-1: Initial UE-to-MSC NAS signalling 1. The UE receives a request from the NAS layer to establish a signalling connection to a core network domain. The request also includes a request to transfer an uplink NAS PDU. The UE encapsulates the NAS PDU within a GA-RRC INITIAL DIRECT TRANSFER message and sends the message to the VANC. The message includes the CN Domain identity (CS), the EPS TAI and the identity of the current camping E-UTRAN cell. It also includes the Intra Domain NAS Node Selector (IDNNS) to be used by the VANC to route the establishment of a signalling connection to a MSC within the indicated CN domain; i.e., using the Iu Flex functions as specified in TS 23.236 [33]. 2. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes a signalling connection to the indicated MSC and relays the received NAS-PDU to the MSC via the RANAP Initial UE Message message. Subsequent NAS PDUs from the UE to the MSC are transferred in the GA-RRC UPLINK DIRECT TRANSFER message as illustrated in the following figure.

Figure 10.7-2: UE-to-MSC NAS signalling 1. The UE receives a request from the NAS layer to transfer an uplink NAS PDU. Assuming the required signalling connection already exists, the UE encapsulates the NAS PDU within a GA-RRC UL DIRECT TRANSFER message and sends the message to the VANC. The message includes the CN Domain identity (CS). 2. The VANC relays the received NAS-PDU to the MSC via the RANAP Direct Transfer message. NAS PDUs from the MSC to the UE are transferred in the GA-RRC DOWNLINK DIRECT TRANSFER message as illustrated in the following figure.

VoLGA Forum

Phase 1

58

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

Figure 10.7-3: MSC-to-UE NAS signalling 1. For MSC-to-UE NAS signalling, the MSC sends a NAS PDU to the VANC via the RANAP Direct Transfer message. 2. The VANC encapsulates the NAS PDU within a GA-RRC DL DIRECT TRANSFER message and forwards the message to the UE via the existing TCP connection. The message includes the CN Domain identity (CS).

10.8 Mobile-originated call

The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-RRC is the serving RR entity for CS services in the UE. It also assumes that no GA-RRC signalling connection exists between the UE and VANC; i.e., the CS domain GA-RRC entity in the UE is in the GA-RRC-IDLE state. If the CS domain GA-RRC entity in the UE is already in the GA-RRC-CONNECTED state, step 1 is skipped. A UE that is VoLGA registered for SMS-only shall not originate voice calls.

VoLGA Forum

Phase 1

59

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

Figure 10.8-1: Mobile-originated call 1. 2. The CS GA-RRC connection establishment procedure is performed as described in sub-clause 10.5.1. The UE sends the CM Service Request message to the VANC within the GA-RRC INITIAL DIRECT TRANSFER message. The message includes the CN Domain identity (CS), the EPS TAI and the identity of the current camping E-UTRAN cell. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes an SCCP connection to the MSC and forwards the NAS PDU (i.e., the CM Service Request message) to the MSC using the RANAP Initial UE Message. The message includes the Domain Indicator set to value CS domain. Subsequent NAS messages between the UE and MSC will be sent between VANC and MSC using the RANAP Direct Transfer message. The MSC may optionally authenticate the UE using standard UTRAN authentication procedures. The MSC normally initiates the Security Mode Control procedure described in sub-clause 10.6. The UE sends the Setup message providing details on the call to the MSC and its bearer capability and supported codecs. This message is contained within the GA-RRC UL DIRECT TRANSFER between the UE and the VANC. The VANC forwards the Setup message to the MSC. The MSC indicates it has received the call setup and it will accept no additional call-establishment information using the Call Proceeding message to the VANC. The VANC forwards this message to the UE in the GA-RRC DL DIRECT TRANSFER message.

3.

4. 5. 6.

7.

VoLGA Forum

Phase 1

60

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

8.

a) The MSC requests the VANC to assign call resources using the RANAP RAB Assignment Request message. The MSC includes the RAB ID, the CN Transport Layer Address and the CN Iu Transport Association for user data. b) The Iu bearer is established per standard Iu procedures. In the case of the ATM-based Iu-CS interface, this may include the exchange of ALCAP signalling between the VANC and the MSC to setup the ATM virtual circuit. For both ATM and IP-based Iu-CS interface types, Iu bearer establishment may also include the Iu UP initialization exchange, if Iu UP support mode is required as indicated by the MSC in the RANAP RAB Assignment Request message.

9.

The VANC sends the GA-RRC ACTIVATE CHANNEL message to the UE including bearer path setup information such as: CN Domain ID (i.e., indicating CS domain). RAB ID (provided by the MSC in step 8). RAB Configuration (based on RAB parameters provided by the MSC in step 8). Multi-rate codec configuration. UDP port & the IP address for the uplink RTP stream. Voice sample size.

10. The UE sends the GA-RRC ACTIVATE CHANNEL ACK to the VANC indicating that the UE has successfully established a CS bearer channel for the call and including the UDP port for the downlink RTP stream. 11. The VANC initiates the activation of a second EPS bearer for the CS voice call using the Rx interface to the PCRF (see sub-clause 9.8.1). 12. The VANC signals the completion of the RAB establishment to the UE with the GA-RRC ACTIVATE CHANNEL COMPLETE message. 13. The VANC signals to the MSC that the RAB has been established by sending a RANAP RAB Assignment Response message. 14. The MSC signals to the UE, with the Alerting message, that the called party is ringing. The message is transferred to the VANC and VANC forwards the message to the UE in the GA-RRC DL DIRECT TRANSFER message. If the UE has not connected the audio path to the user, it shall generate ring back to the calling party. Otherwise, the network-generated ring back will be returned to the calling party. 15. The MSC signals that the called party has answered, via the Connect message. The message is transferred to the VANC and VANC forwards the message to the UE in the GA-RRC DL DIRECT TRANSFER message. The UE connects the user to the audio path. If the UE is generating ring back, it stops and connects the user to the audio path. 16. The UE sends the Connect Ack message in response, and the two parties are connected for the voice call. This message is contained within the GA-RRC UL DIRECT TRANSFER message between the UE and the VANC. The VANC forwards the Connect Ack message to the MSC. 17. Bi-directional voice traffic flows between the UE and MSC through the VANC.

10.9 Mobile-terminated call

The description of the procedure in this clause assumes that the UE has successfully registered with the VANC and GARRC is the serving RR entity for CS services in the UE.

VoLGA Forum

Phase 1

61

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

UE

VANC

MSC

1. Paging 2. GA-RRC PAGING REQUEST 3. GA-RRC INITIAL DIRECT TRANSFER (Paging Response)
GA-RRCCONNECTED

4. Initial UE Message (Paging Response)

5. Authentication 6. Security Mode Control 7. GA-RRC DL DIRECT TRANSFER (Setup) 8. GA-RRC UL DIRECT TRANSFER (Call Confirmed) 9a. RAB Assignment Request

9b. Iu Bearer Establishment and Iu UP Initialization 10. GA-RRC ACTIVATE CHANNEL 11. GA-RRC ACTIVATE CHANNEL ACK

12. Activate second EPS bearer for user data 13. GA-RRC ACTIVATE CHANNEL COMPLETE 14. RAB Assignment Response 15. GA-RRC UL DIRECT TRANSFER (Alerting) 16. GA-RRC UL DIRECT TRANSFER (Connect) 17. GA-RRC DL DIRECT TRANSFER (Connect Ack) 18. Voice traffic (via second EPS bearer )

Figure 10.9-1: Mobile-terminated call 1. A mobile-terminated call arrives at the MSC. The MSC sends a RANAP Paging message to the VANC identified through the last Location Update received by it and includes the TMSI if available. The IMSI of the mobile being paged is always included in the request. The VANC identifies the UE registration context using the IMSI provided by the MSC. It then pages the UE using the GA-RRC PAGING REQUEST message. The message includes the TMSI, if available in the request from the MSC; else it includes only the IMSI of the UE. The message includes the CN Domain identity (CS). The UE responds with a GA-RRC INITIAL DIRECT TRANSFER message containing the Paging Response message. The message includes the CN Domain identity (CS), the EPS TAI and the identity of the current camping E-UTRAN cell. The CS domain GA-RRC entity in the UE changes to the GA-RRC-CONNECTED state. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the RANAP Initial UE Message. Subsequent NAS messages between the UE and MSC will be sent between VANC and MSC using the RANAP Direct Transfer message. The MSC may optionally authenticate the UE using standard UTRAN authentication procedures.

2.

3.

4.

5.

VoLGA Forum

Phase 1

62

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

6. 7. 8.

The MSC normally updates the security configuration in the UE, via the VANC, as described in sub-clause 10.6. The MSC initiates call setup using the Setup message sent to the UE via VANC. VANC forwards this message to the UE in the GA-RRC DL DIRECT TRANSFER message. In case the UE is not registered for SMS-only service, the UE responds with Call Confirmed using the GARRC UL DIRECT TRANSFER message after checking it's compatibility with the bearer service requested in the Setup message and modifying the bearer service as needed. If the Setup message included the signal information element, the UE alerts the user using the indicated signal, else the UE alerts the user after the successful configuration of the user plane. The VANC forwards the Call Confirmed message to the MSC. In case the UE is registered for SMS-only service and the UE determines from the Setup message that the setup is for MT call, the UE shall send a DISCONNECT message with the cause #79 "service or option not implemented, unspecified". Step 9 onwards are not performed in this case.

9-14. The MSC initiates the assignment procedure with the VANC, which triggers the establishment of the second EPS bearer for the CS voice call and the setup of the RTP stream (voice bearer channel) between the VANC and UE, same as steps 8-13 in the MO call scenario described in sub-clause 10.8. 15. The UE signals that it is alerting the user, via the Alerting message contained in the GA-RRC UL DIRECT TRANSFER message. The VANC forwards the Alerting message to the MSC. The MSC sends a corresponding alerting message to the calling party. 16. The UE signals that the called party has answered, via the Connect message contained in the GA-RRC UL DIRECT TRANSFER message. The VANC forwards the Connect message to the MSC. The MSC sends a corresponding Connect message to the calling party and through connects the audio. The UE connects the user to the audio path. 17. The MSC acknowledges via the Connect Ack message to the VANC. VANC forwards this message to the UE in the GA-RRC DL DIRECT TRANSFER message. The two parties on the call are connected on the audio path. 18. Bi-directional voice traffic flows between the UE and MSC through the VANC.

10.10 Call clearing

10.10.1 Call release
The following figure shows CS call clearing initiated by the UE. This scenario assumes that the MSC uses Iu Release to release the call (i.e., versus a separate RAB Release then Iu Release).
UE VANC MSC

1. GA-RRC UL DIRECT TRANSFER (Disconnect)

2. GA-RRC DL DIRECT TRANSFER (Release)

3. GA-RRC UL DIRECT TRANSFER (Release Complete)

4. GA-RRC Connection Release

5. Deactivate second EPS bearer

Figure 10.10.1-1: UE-initiated call release

VoLGA Forum

Phase 1

63

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

1. The UE sends the Disconnect message to the MSC to release the call. This message is contained in the GA-RRC UL DIRECT TRANSFER message between UE and VANC. The VANC forwards the Disconnect message to the MSC (i.e., using the RANAP Direct Transfer message). 2. The MSC responds with a Release message to the VANC. The VANC forwards this message to the UE using the GA-RRC DL DIRECT TRANSFER message. 3. The UE responds with the Release Complete message. This message is contained within the GA-RRC UL DIRECT TRANSFER message between UE and VANC. The VANC forwards the Disconnect message to the MSC. 4. The MSC triggers the release of connection as described in clause 10.5.2.1. 5. In parallel with step 4, the VANC initiates the deactivation of the second EPS bearer for the CS voice call using the Rx interface to the PCRF.

10.10.2 Channel release

The following figure shows CS channel release (i.e., user plane only) corresponding to the Iu RAB Release procedure.
UE VANC MSC

1. RAB Assignment Request

2. GA-RRC DEACTIVATE CHANNEL

3. GA-RRC DEACTIVATE CHANNEL COMPLETE

4. RAB Assignment Response

5. Deactivate second EPS bearer

Figure 10.10.2-1: Channel release 1. The MSC indicates to the VANC to release the RAB allocated to the UE (identified by the RAB ID), via the RANAP RAB Assignment Request message. 2. The VANC commands the UE to release the CS user plane channel (but maintain the CS signalling connection), using the GA-RRC DEACTIVATE CHANNEL message. The message includes the CN Domain ID (indicating CS) and the RAB ID. 3. The UE confirms CS channel release to the VANC using the GA-RRC DEACTIVATE CHANNEL COMPLETE message. The UE remains in the GA-RRC-CONNECTED state. 4. The VANC confirms resource release to MSC using the RAB Assignment Response message. 5. In parallel with step 4, the VANC initiates the deactivation of the second EPS bearer for the CS voice call using the Rx interface to the PCRF.

10.11 Channel modification

The VANC may initiate the CS channel modification procedure when it determines that one or more active CS channels require modification; e.g., based on information received from the MSC in the RAB Assignment Request message or based on local VANC logic. For example, the VANC may initiate this procedure if it detects "packet loss" and handover to GERAN/UTRAN is not possible or desired. The VANC may modify the following parameters:

VoLGA Forum

Phase 1

64

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

- RAB Configuration - Sample Size - RTP UDP Port - VANC IP Address for the uplink RTP stream - Multi-rate Configuration 2 - RTP Redundancy Configuration - NAS Synchronisation Indicator - RTCP UDP Port

UE

VANC

MSC

1. CS call is established 2. GA-RRC MODIFY CHANNEL

3. GA-RRC MODIFY CHANNEL ACKNOWLEDGE

4. Modify second EPS bearer for user data (optional)

Figure 10.11-1: Channel modification 1. A call is established as described in sub-clauses 10.8 or 10.9. 2. The VANC sends the GA-RRC MODIFY CHANNEL message to the UE to modify parameters for the established call. 3. The UE responds with the GA-RRC MODIFY CHANNEL ACKNOWLEDGE message to the VANC. 4. Optionally, the VANC initiates the modification of the second EPS bearer using the Rx interface to the PCRF, using the procedure described in sub-clause 9.8.1.

10.12 Handover
10.12.1 Handover from E-UTRAN to GERAN
10.12.1.1 General
The following table summarizes the eNodeB behaviour related to handover and cell change to GERAN.

VoLGA Forum

Phase 1

65

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

Table 10.12.1.1-1: Scenarios for handover and cell change to GERAN Target GERAN supports: Scenario (Note 1) 1 2 3 4 5 VoIP bearer active for VoLGA? No No No No Yes PS HO? DTM HO? Source eNodeB initiates:

No No Yes Yes No

No Yes No Yes No

NACC n/a PS Handover PS Handover CS Handover (VoIP bearer only) PS bearers suspended n/a CS Handover (VoIP bearer only) PS bearers suspended CS+PS Handover (All bearers)

6 7

Yes Yes

No Yes

Yes No

8a

Yes

Yes

Yes (and UE supports DTM & DTM HO) Yes (but UE doesnt support DTM) Yes (and UE supports DTM but not DTM HO)

8b

Yes

Yes

CS Handover (VoIP bearer only) PS bearers suspended CS Handover (VoIP bearer only) UE RAU after CS Handover moves PS bearers to GERAN

8c

Yes

Yes

NOTE 1: When a voice bearer is active and the target GERAN supports both PS handover and DTM (scenarios 8a, 8b and 8c), the UEs DTM capabilities determine the behaviour of the handover. In the other scenarios the handover behaviour is independent of the UEs DTM capabilities. NOTE 2: DTM handover support is an optional additional functionality for UEs that support DTM. - Scenario 1 is illustrated in sub-clause 10.12.1.6. - Scenarios 2 and 6 are not possible since we assume that the target GERAN must support PS handover if it supports DTM handover. - Scenarios 3 and 4 are described in sub-clause 10.12.1.4. - Scenarios 5, 7 and 8b are illustrated in sub-clause 10.12.1.2. - Scenario 8a is illustrated in sub-clause 10.12.1.3. - Scenario 8c is illustrated in sub-clause 10.12.1.5.

VoLGA Forum

Phase 1

66

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

10.12.1.2 Handover of VoLGA call to GERAN without DTM handover support or for UE without DTM support
The following figure illustrates the VoLGA call handover from E-UTRAN to GERAN, assuming that DTM handover is not supported in the target GERAN.
UE Source E-UTRAN Source MME HOSF Serving VANC Serving MSC Target MSC Target BSS

1. Measurement Reports 2. Decision for HO 3. Handover Required 4. Bearer Splitting 5. PS to CS Request 6. Relocation Required 7. Prepare Handover Request 8. Handover Request/Ack 9. Prepare Handover Response 10. Establish circuit 11. Relocation Command 12. PS to CS Response 13. Handover Command 14. Handover from E-UTRAN Command

15. UE tunes to GERAN 16. Handover Detection 17. Suspend procedure as described for SRVCC in 3GPP TS 23.216, sub-clause 6.2.2.1 18. Handover Complete 19. Send End Signal (Handover Complete) 20. Answer 21. Iu Release Command 22. PS to CS Complete/Ack 23. Release Resources 24. Iu Release Complete

Figure 10.12.1.2-1: Handover of VoLGA call to GERAN without DTM handover support or for UE without DTM support A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. 5. The MME sends a SRVCC PS to CS Request message to the HOSF. The content of the SRVCC PS to CS Request message is the same as described in TS 23.216 [5], sub-clause 6.2.2.1. The HOSF forwards the SRVCC PS to CS Request message to the current serving VANC, without modifying the message content. The HOSF identifies the UE using the IMSI received in the message. The HOSF identifies the current serving VANC based on the stored VANC-UE binding information. If the HOSF does not have a record of the serving VANC for the UE, then the HOSF assumes that this is a request for SRVCC handover. Therefore, the HOSF forwards the SRVCC PS to CS Request messagewithout modifying the message contentto the MSC Server enhanced for SRVCC, selected based on the target cell information in the Source to Target Transparent Container, and the rest of this procedure is not applicable. 6. The VANC converts the SRVCC PS to CS Request into a CS handover request by sending a RANAP Relocation Required message to the MSC that is currently serving the VoLGA call.

VoLGA Forum

Phase 1

67

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

7-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. 11. The serving MSC sends a RANAP Relocation Command message to the VANC, containing the GERAN RR Handover Command message encapsulated in the "Layer 3 Information" IE. 12. The VANC sends a SRVCC PS to CS Response (Target to Source Transparent Container) message to the source MME. The VANC gets the source MME address from the IE 'MME/SGSN Sv Address for Control Plane' received in the SRVCC PS to CS Request. The VANC includes its Z3 interface IP address in the IE 'MSC Server Sv Address for Control Plane'; this allows subsequent SRVCC messaging for the handover to bypass the HOSF. The source MME knows that at the end of the PS-CS handover the non-GBR bearers should be preserved. 13-20. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.1. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 21. The serving MSC sends a Iu Release Command message to the VANC to request release of the resources that had been allocated for the call. 22. The VANC sends a SRVCC PS to CS Complete Notification message to the source MME, informing it that the UE has arrived on the target side. The source MME acknowledges the information by sending a SRVCC PS to CS Complete Acknowledge message to the VANC. 23. The source MME releases the E-UTRAN resources allocated to the UE. 24. The VANC sends the Iu Release Complete message to the serving MSC indicating that the VANC has released the resources that had been allocated for the call. After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060 [4]) the UE shall resume PS services by sending a Routeing Area Update Request message to the SGSN. The Update Type depends on the mode of operation of the GERAN network; e.g., in mode I a Combined RA/LA Update is used and in mode II or III Routeing Area Update is used. NOTE: From the perspective of the UE, the E-UTRAN and the MME, this flow is identical to the SRVCC handover flow as specified in TS 23.216 [5].

10.12.1.3 Handover of VoLGA call to GERAN with DTM handover support

The following figure illustrates the VoLGA call handover from E-UTRAN to GERAN, assuming that DTM handover is supported in the target GERAN.

VoLGA Forum

Phase 1

68

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

Figure 10.12.1.3-1: Handover of VoLGA call to GERAN with DTM handover support A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. 5. The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 10.12.1.2, steps 5-12.

6-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 11. The SRVCC PS to CS handover completion procedure is performed, as described in sub-clause 10.12.1.2, steps 18-24. 12. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2.

10.12.1.4 Handover to GERAN of VoLGA signalling channel without active voice bearer
The following figure illustrates the handover of the VoLGA signalling channel from E-UTRAN to GERAN when no voice bearer is active prior to the handover; for example, during an SMS transfer, supplementary service transaction, or a call where the voice bearer has not yet been established.

VoLGA Forum

Phase 1

69

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

Figure 10.12.1.4-1: Handover to GERAN of VoLGA signalling channel without active voice bearer See sub-clause 9.12.1.4.

10.12.1.5 Handover of VoLGA call to GERAN with DTM handover support (UE supports DTM but does not support DTM handover)
The call flow for this scenario is similar to the call flow depicted in figure 10.12.1.2-1, with the exception that the Suspend procedure (step 17 in figure 10.12.1.2-1) is not performed. Instead, at the end of the procedure described in figure 10.12.1.2-1, the UE transfers the PS bearer contexts to GERAN by performing the RAU as described in TS 23.060 [4].

10.12.1.6 Network Assisted Cell Change (NACC) from E-UTRAN to GERAN

See sub-clause 9.12.1.6.

10.12.2 Handover from E-UTRAN to UTRAN

10.12.2.1 Handover of VoLGA call to UTRAN
The following figure illustrates the VoLGA call handover from E-UTRAN to UTRAN.

Figure 10.12.2.1-1: Handover of VoLGA call to UTRAN

VoLGA Forum

Phase 1

70

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

A VoLGA call is established. 1-4. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. 5. The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 10.12.1.2, steps 5-12, with the exception that the target MSC exchanges the Relocation Request/Request Ack messages with the target RNS in step 8 (versus Handover Request/Request Ack with the target BSS in sub-clause 10.12.1.2).

6-10. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2. After switching the serving RR entity to GERAN RR, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2). 11. The SRVCC PS to CS handover completion procedure is performed, as described in sub-clause 10.12.1.2, steps 18-24, with the exception that the target RNS sends the Relocation Complete message to the target SGSN in step 18 (versus Handover Complete in sub-clause 10.12.1.2). 12. Same as corresponding steps in TS 23.216 [5], sub-clause 6.2.2.2.

10.12.2.2 Handover to UTRAN of VoLGA signalling channel without active voice bearer
The following figure illustrates the handover of the VoLGA signalling channel from E-UTRAN to UTRAN when no voice bearer is active prior to the handover; for example, during an SMS transfer, supplementary service transaction, or a call where the voice bearer has not yet been established.

Figure 10.12.2.2-1: Handover to UTRAN of VoLGA signalling channel without active voice bearer See sub-clause 9.12.2.2.

10.13 Short Message Service

SMS support is based on the same mechanism that is utilized for UMTS mobility management and call control. On the UE side, the SMS layers (including the supporting CM sub layer functions) utilize the services of the MM layer to transfer SMS messages per standard circuit switched UMTS implementation. The SM-CP protocol is effectively tunnelled between the UE and the MSC, using GA-RRC messages from the UE to the VANC, where the VANC relays the SM-CP to RANAP Direct Transfer messages for transport over the Iu-CS interface. As with UMTS mobility management and call control procedures, the secure IPsec tunnel and TCP session are used to provide secure and reliable SMS delivery over the IP network.

10.13.1 Mobile-originated SMS

The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-RRC is the serving RR entity for CS services in the UE. It also assumes that no GA-RRC signalling connection exists between the UE and VANC; i.e., the CS domain GA-RRC entity in the UE is in the GA-RRC-IDLE state. If the CS domain GA-RRC entity in the UE is already in the GA-RRC-CONNECTED state, step 1 is skipped.

VoLGA Forum

Phase 1

71

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

Figure 10.13.1-1: Mobile-originated SMS 1. 2. The CS GA-RRC connection establishment procedure is performed as described in sub-clause 10.5.1. The UE sends the CM Service Request message to the VANC within the GA-RRC INITIAL DIRECT TRANSFER message. The message includes the CN Domain identity (CS). The message also includes the EPS TAI and the identity of the current camping E-UTRAN cell. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes an SCCP connection to the MSC and forwards the NAS PDU (i.e., the CM Service Request message) to the MSC using the RANAP Initial UE Message. The message includes the Domain Indicator set to value CS domain. Subsequent NAS messages between the UE and MSC will be sent between VANC and MSC using the RANAP Direct Transfer message. The MSC may optionally authenticate the UE using standard UTRAN authentication procedures. The MSC normally initiates the Security Mode Control procedure described in sub-clause 10.6. The MSC signals acceptance of the MO SMS request. The UE sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the MSC. The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the UE. The MSC relays the response received from the IWMSC (not shown) to the VANC in the CP-DATA message. The VANC relays this to the UE.

3.

4. 5. 6. 7. 8. 9.

10. The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the MSC. 11. The MSC triggers the release of connection as described in clause 10.5.2.1.

10.13.2 Mobile-terminated SMS

The description of the procedure in this clause assumes that the UE has successfully registered with the GANC and GARRC is the serving RR entity for CS services in the UE.

VoLGA Forum

Phase 1

72

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

Figure 10.13.2-1: Mobile-terminated SMS 1. A mobile-terminated SMS arrives at the MSC. The MSC sends a RANAP Paging message to the VANC identified through the last Location Update received by it and includes the TMSI if available. The IMSI of the mobile being paged is always included in the request. The VANC identifies the UE registration context using the IMSI provided by the MSC. It then pages the UE using the GA-RRC PAGING REQUEST message. The message includes the TMSI, if available in the request from the MSC; else it includes only the IMSI of the UE. The message includes the CN Domain identity (CS). The UE responds with a GA-RRC INITIAL DIRECT TRANSFER message containing the Paging Response message. The message includes the CN Domain identity (CS). The message also includes the EPS TAI and the identity of the current camping E-UTRAN cell. The CS domain GA-RRC entity in the UE transitions to the GA-RRC-CONNECTED state. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the RANAP Initial UE Message. Subsequent NAS messages between the UE and core network will be sent between VANC and MSC using the RANAP Direct Transfer message. The MSC may optionally authenticate the UE using standard UTRAN authentication procedures. The MSC normally updates the security configuration in the UE, via the VANC, as described in sub-clause 10.6. The MSC sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the UE. The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the MSC. The UE sends a response to the VANC in the CP-DATA message. The VANC relays this to the MSC.

2.

3.

4.

5. 6. 7. 8. 9.

10. The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the UE. 11. The MSC triggers the release of connection as described in clause 10.5.2.1.

VoLGA Forum

Phase 1

73

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

10.14 Supplementary services

UMTS has a large number of standardized supplementary services. These supplementary services involve procedures that operate end-to-end between the UE and the MSC. The NAS messages used for the supplementary service are relayed between the UE and MSC in the same manner as in the other call control and mobility management scenarios described in this specification.

10.15 Emergency services

See sub-clause 9.15.

10.16 Location services

See sub-clause 9.16.

10.17 Lawful interception

See sub-clause 9.17.

10.18 Location area update

The UE performs a location area update when the current VoLGA LAI is not the same as the stored LAI. The CS domain MM layer is responsible for the comparison when it obtains the VoLGA LAI from the VoLGA GA-RC layer. The following triggers for the VoLGA GA-RC layer providing VoLGA LAI apply: - When the VoLGA GA-RC entity receives the VoLGA LAI from the VANC during the Registration or Registration Update procedure, it stores the new VoLGA LAI and then offers it to the upper CS domain MM layer. - When the UE in GA-RC REGISTERED state reselects to E-UTRAN and the VoLGA registration update uplink procedure is not triggered (refer to sub-clause 9.3.2), the VoLGA GA-RC entity offers the stored VoLGA LAI to the upper CS domain MM layer. The description of the procedure in this sub-clause assumes that the UE has successfully registered with the VANC and GA-RRC is the serving RR entity for CS services in the UE. It also assumes that no GA-RRC signalling connection exists between the UE and VANC; i.e., the CS domain GA-RRC entity in the UE is in the GA-RRC-IDLE state. If the CS domain GA-RRC entity in the UE is already in the GA-RRC-CONNECTED state, step 1 is skipped.

Figure 10.18-1: Location area update

VoLGA Forum

Phase 1

74

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

1. 2.

The CS GA-RRC connection establishment procedure is performed as described in sub-clause 10.5.1. The UE sends the Location Updating Request message to the VANC within the GA-RRC INITIAL DIRECT TRANSFER message. The GA-RRC INITIAL DIRECT TRANSFER message includes the CN Domain identity (CS), the EPS TAI and the identity of the current camping E-UTRAN cell. The Location Updating Request message includes the LAI associated with the last successful location area update procedure. The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes an SCCP connection to the MSC and forwards the NAS PDU (i.e., the Location Updating Request message) to the MSC using the RANAP Initial UE Message, including the VoLGA LAI value currently assigned to the UE and the mapped SAI value. Subsequent NAS messages between the UE and MSC will be sent between VANC and MSC using the RANAP Direct Transfer message. The MSC may optionally authenticate the UE using standard UTRAN authentication procedures. The MSC normally initiates the Security Mode Control procedure described in sub-clause 10.6. The MSC signals acceptance of the location update request. The MSC triggers the release of connection as described in sub-clause 10.5.2.1.

3.

4. 5. 6. 7.

Note: The timing of the MSC release of the connection is per TS 24.008 [16]; e.g., additional "follow-on" NAS signalling may occur after step 6. Note: Location update is only initiated by the UE. Per 3GPP standards, the UE does not perform a location update during an active call.

11

HOSF procedures

11.1 Create VANC-UE binding in HOSF

VANC HOSF

1. VANC-UE Binding Request

2. VANC-UE Binding Response

Figure 11.1-1: Create VANC-UE binding in HOSF 1. The VANC sends a VANC-UE Binding Request message to the HOSF, with an indication that a VANC-UE binding be created. The message also includes the UE's IMSI and the VANC IP address. The binding enables the HOSF to forward subsequent SRVCC PS to CS Request messages from a MME to the VANC, as described in sub-clauses 9.12 and 10.12. The VANC selects the HOSF based on GUTI and EPS location information (e.g. TAI) provided by the UE and on local configuration information in the VANC. The HOSF creates the binding or updates the binding if the binding already exists, and sends the VANC-UE Binding Response message to the VANC, indicating that the HOSF accepts the request; i.e., that the HOSF has created the binding.

2.

VoLGA Forum

Phase 1

75

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

11.2 Delete VANC-UE binding in HOSF

VANC HOSF

1. VANC-UE Binding Request

2. VANC-UE Binding Response

Figure 11.2-1: Delete VANC-UE binding in HOSF 1. 2. The VANC sends a VANC-UE Binding Request message to the HOSF, with an indication that a VANC-UE binding be deleted. The message also includes the UE's IMSI and the VANC IP address. The HOSF deletes the binding and sends the VANC-UE Binding Response message to the VANC, indicating that the HOSF accepts the request; i.e., that the HOSF has deleted the binding.

12
12.1

VoLGA configuration mechanisms

General

VoLGA terminals will require configuration in order to properly carry out VANC discovery, voice service mode selection and secure access to VoLGA services. This configuration will either be done through pre-configuration of UEs by the operator or by means of OMA DM [34].

12.2
12.2.1

VoLGA configuration properties

VANC discovery control

It shall be possible to configure the UE with: a) the APN that the UE shall use for VoLGA in the HPLMN; b) a list of VPLMNs, each with a VoLGA APN to be used in that VPLMN; c) the APN that the UE shall use for VoLGA in all other VPLMNs, i.e. those not identified in b); d) the PCO-related container identifiers that the UE shall use in each PLMN (i.e., if the default values are not used).

12.2.2

Voice mode control

It shall be possible to configure the UE with a list of modes to support voice service. For each mode it shall be possible to configure: priority; the operator policy that determines whether or not each mode that the UE supports is included or excluded.

These modes and their interpretation are discussed further in Annex A.

12.2.3

Security configuration

The UE shall be configurable with parameters necessary to enable the proper use of IPsec between the UE and the VANC to secure the Z1 interface. Example: Certificates, traffic policy templates for the Security Policy Database (SPD), etc. IPsec considerations for VoLGA are discussed further in Annex B.

VoLGA Forum

Phase 1

76

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

Annex A (normative): VoLGA coexistence with IMS & CSFB

A.1 General

This annex specifies the UEs behaviour when it supports different voice service mechanisms such as VoLGA voice, IMS Voice and CS voice. This behaviour is built on specification in TS 23.221 [36] section 7.2a Domain Selection for UE originating Sessions/call and Annex A Guidance for CSFB and IMS enabled UE implementations. The figures in this section are based on figures in Annex A of TS 23.221 [36]. New elements introduced to figures in are shown in yellow-fill and new text introduced inside an existing box in a figure is in red color. As stated in Annex A of TS 23.221 [36], the following indications/settings are provided for a UE: CS Voice only, IMS PS Voice only, prefer CS Voice with IMS PS Voice as secondary, or prefer IMS PS Voice with CS Voice as secondary, referred to as 3gpp voice mechanism Preference Vector (3PV) in this annex and
Voice centric or Data centric.

In addition, for a VoLGA UE the following setting are provided regarding preference of CS Voice, IMS PS Voice or VoLGA voice, as part of VoLGA voice mechanism Preference Vector (VPV) The VPV is provided as a maximum of three-tuple, [first_preference, second_preference, third_preference], where CS Voice, IMS PS Voice or VoLGA voice can be placed in any of the above elements. If only one voice mechanism is to be allowed, then only the first_preference is populated, i.e the second_preference and third_preference are not specified. If preference between only two voice mechanisms is to be provided then the third_preference is not specified. Otherwise, all three preferences are provided. The voice mechanisms are included in decreasing order of preference in the VPV.

The value of the VPV alone drives the behaviour of the UE, i.e it over-rides the setting of the 3PV. The VPV is set by HPLMN in the same way as the 3PV. There are a total of 15 values for the VPV. The table provides an organization of how the figures in the following subsections are organized for different values of VPV. The column headings correspond to section headings in this annex.. The parenthesis in the table are the index of the figure which describes UEs behaviour when a particular setting of VPV. Table A.1 Organization of the figures corresponding to VPV values in the Annex. CS Voice Only IMS PS Voice or VoLGA Voice Only prefer IMS PS Voice or VoLGA Voice with CS Voice as secondary/tertiary (Section A.2) [IMS, CS] (A.2.1-1) [VoLGA, CS] (A.2.12) [IMS, VoLGA, CS] (A.2.1-3) [VoLGA, IMS, CS] (A.2.1-4) [IMS, CS, VoLGA] (A2.1-5) [VoLGA, CS, IMS] (A2.1-6) prefer CS Voice with IMS PS Voice or VoLGA Voice as secondary/tertiary (Section A.3) [CS, IMS] (A.3-1) [CS, VoLGA] (A.32) [CS, IMS, VoLGA] (A.3-3) [CS, VoLGA, IMS] (A.3-4)

(Section A.5) (Section A.4) [CS] (A.5-1) [IMS] (A.4-1) [VoLGA] (A.4-2) [IMS, VoLGA] (A.43) [VoLGA, IMS] (A.44)

VPV

VoLGA Forum

Phase 1

77

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

A.2
A.2.1

IMS PS Voice or VoLGA Voice preferred

EPS attach

The following figure A.2.1-1illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [IMS, CS].

VPV = [IMS, CS] or 3PV = UE is set to IMS voice preferred, CS voice secondary

UE initiates EPS attach procedure (non combined)

UE checks for IMS voice supported Indication from Network

Not supported

UE performs combined TAU for CSFB as in TS 23.272

Fail

UE checks for voice centric or data centric setting

Voice centric

Supported

TAU performed

Success

Data centric

UE uses IMS Voice

UE uses CSFB

UE stays in current RAT

UE reselects to other RAT

Figure A.2.1-1: UE behavior for VPV set to [IMS, CS], non-combined EPS/IMSI attach. This also corresponds to 3PV setting of IMS PS Voice preferred with CS Voice as secondary. The following figure A.2.1-2 illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [VoLGA, CS].

VoLGA Forum

Phase 1

78

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

VPV = [VoLGA, CS]

UE initiates EPS attach procedure (non combined)

UE performs VoLGA registration

Fails

UE performs combined TAU for CSFB as in TS 23.272

Fail

UE checks for voice centric or data centric setting

Voice centric

Success

Success

Data centric

UE uses VoLGA

UE uses CSFB

UE stays in current RAT

UE reselects to other RAT

Figure A.2.1-2: UE behavior for VPV set to [VoLGA, CS], non-combined EPS/IMSI attach. The following figure A.2.1-3 illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [IMS, VoLGA, CS].

VoLGA Forum

Phase 1

79

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

Figure A.2.1-3: UE behavior for VPV set to [IMS, VoLGA, CS], non-combined EPS/IMSI attach. The following figure A.2.1-4 illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [VoLGA, IMS, CS].

VoLGA Forum

Phase 1

80

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

Figure A.2.1-4: UE behavior for VPV set to [VoLGA, IMS, CS], non combined EPS/IMSI attach. The following figure A.2.1-5 illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [IMS, CS, VoLGA].

VoLGA Forum

Phase 1

81

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

Figure A.2.1-5: UE behavior for VPV set to [IMS, CS, VoLGA], non combined EPS/IMSI attach. The following figure A.2.1-6 illustrates the UE behaviour when performing non-combined EPS/IMSI attach, with the VPV setting of [VoLGA, CS, IMS].

VoLGA Forum

Phase 1

82

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

Figure A.2.1-6: UE behavior for VPV set to [VoLGA, CS , IMS], non combined EPS/IMSI attach.

A.2.2

Combined EPS/IMSI attach

A VoLGA capable UE with any setting where Volga Voice is preferred over CS shall not initiate combined attach prior to attempting to use the VoLGA voice option.

A.3

CS Voice preferred

The following figure A.3-1 illustrates the UE behaviour with the VPV setting of [CS, IMS].

VoLGA Forum

Phase 1

83

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

Figure A.3-1: UE behavior for VPV set to [CS, IMS]. This also corresponds to 3PV setting of CS Voice preferred with IMS PS Voice as secondary. The following figure A.3-2 illustrates the UE behaviour with the VPV setting of [CS, VoLGA].

VPV = [CS, VoLGA]

UE initiates a combined EPS/ IMSI attach procedure

Fail

UE performs VoLGA registration

Fail

UE checks for voice centric or data centric setting

Voice centric

Success

Success

Data centric

UE uses CSFB

UE uses VoLGA

UE stays in current RAT

UE reselects to other RAT

Figure A.3-2: UE behavior for VPV set to [CS, VoLGA]. The following figure A.3-3 illustrates the UE behaviour with the VPV setting of [CS, VoLGA, IMS].

VoLGA Forum

Phase 1

84

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

Figure A.3-3: UE behavior for VPV set to [CS, VoLGA, IMS]. The following figure A.3-4 illustrates the UE behaviour with the VPV setting of [CS, IMS, VoLGA].

Figure A.3-4: UE behavior for VPV set to [CS, IMS, VoLGA].

A.4

IMS PS Voice or PS Voice only

The following figure A.4-1 illustrates the UE behaviour with the VPV setting of [IMS].

VoLGA Forum

Phase 1

85

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

VPV = [IMS] or 3PV = UE is set to IMS voice only

UE initiates EPS attach procedure (non combined)

UE checks for IMS voice supported Indication from Network

Not supported

UE checks for voice centric or data centric setting

Voice centric

Supported TAU performed

Data centric

UE uses IMS Voice

UE stays in current RAT

UE reselects to other RAT

Figure A.4-1: UE behavior for VPV set to [IMS]. This also corresponds to 3PV setting of IMS PS Voice only. The following figure A.4-2 illustrates the UE behaviour with the VPV setting of [VoLGA].

VoLGA Forum

Phase 1

86

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

VPV = [VoLGA]

UE initiates EPS attach procedure (non combined)

UE performs VoLGA registration

Fails

UE checks for voice centric or data centric setting

Voice centric

Success

Data centric

UE uses VoLGA

UE stays in current RAT

UE reselects to other RAT

Figure A.4-2: UE behavior for VPV set to [VoLGA] The following figure A.4-3 illustrates the UE behaviour with the VPV setting of [IMS, VoLGA].

VoLGA Forum

Phase 1

87

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

VPV = [IMS, VoLGA]

UE initiates EPS attach procedure (non combined)

UE checks for IMS voice supported Indication from Network

Not supported

UE performs VoLGA registration

Fail

UE checks for voice centric or data centric setting

Voice centric

Supported TAU performed

Success

Data centric

UE uses IMS Voice

UE uses VoLGA

UE stays in current RAT

UE reselects to other RAT

Figure A.4-3: UE behavior for VPV set to [IMS, VoLGA]. The following figure A.4-4 illustrates the UE behaviour with the VPV setting of [VoLGA, IMS].

VoLGA Forum

Phase 1

88

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

VPV = [VoLGA, IMS]

UE initiates EPS attach procedure (non combined)

UE performs VoLGA registration

Fail

UE checks for IMS voice supported Indication from Network

Not supported

UE checks for voice centric or data centric setting

Voice centric

Success

Supported TAU performed

Data centric

UE uses VoLGA

UE uses IMS Voice

UE stays in current RAT

UE reselects to other RAT

Figure A.4-4: UE behavior for VPV set to [VoLGA, IMS].

A.5

CS Voice only

The following figure A.5-1illustrates the UE behaviour with the VPV setting of [CS].

Figure A.5-1: UE behavior for VPV set to [CS]. This also corresponds to 3PV setting of CS Voice only.

VoLGA Forum

Phase 1

89

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

Annex B (normative): VoLGA security mechanisms

B.1 Authentication and key agreement

The scheme for authentication and key agreement in VoLGA is IKEv2 [18]. Authentication of the UE by the VANC shall be performed using EAP-AKA [17] within IKEv2. Authentication of the VANC by the UE shall be performed using the VANC's public key signature, per IKEv2 requirements. The basic elements of the IKEv2 procedure are as follows: - The UE initiates the connection with the SeGW by starting the IKEv2 initial exchanges (i.e., IKE_SA_INIT, IKE_AUTH). The EAP-AKA procedure is started as a result of these exchanges. - The EAP-AKA procedure is performed between UE and the AAA Server. The SeGW acts as relay for the EAPAKA messages. - When the EAP-AKA procedure has successfully completed, the IKEv2 procedure is continued to complete the VANC authentication and key agreement and the signalling channel between UE and SeGW is secured. The UE and VANC can then continue with the VoLGA registration procedure. Signalling flows for EAP-AKA authentication and fast re-authentication are shown in sub-clause B.3. The IKEv2 profiles that are applicable in VoLGA are listed in sub-clause B.4.1.

B.2

Encryption and integrity protection

All control plane traffic between the UE and the VANC shall be sent through the IPsec tunnel that is established as a result of the IKEv2 procedure. User plane traffic shall not be sent through the IPSec tunnel. The confidentiality and integrity protection of the IP packets sent through the tunnel between the UE and the SeGW shall be protected by IPSec ESP [19] using the negotiated cryptographic algorithms, which are based on operator policy and enforced by the SeGW. The profile for IPSec ESP in VoLGA is defined in sub-clause B.4.2.

B.3

EAP-AKA procedures

B.3.1 EAP-AKA authentication procedure

The EAP-AKA authentication mechanism is specified in [17]. This sub-clause describes how this mechanism is used in VoLGA.

VoLGA Forum

Phase 1

90

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

UE

EPS

SeGW

AAA

HSS/HLR

1. VANC discovery 2a. IKE_SA_INIT 2b. IKE_SA_INIT 2c. IKE_AUTH (NAI in Idi, no AUTH included) 3. Select AAA Server 4. EAP Response/Identity (NAI based on IMSI) 5. Send Auth Info (IMSI) 6. Response (Authentication vectors) 7. EAP Request/AKA Challenge (RAND, AUTN, MAC, Next re-auth ID) 8. EAP Request/AKA Challenge (RAND, AUTN, MAC, Next re-auth ID) 9. Run UMTS algorithms and verify AUTN 10. EAP Response/AKA Challenge (RES, MAC) 11. EAP Response/AKA Challenge (RES, MAC) 12. Check MAC and verify RES 13. EAP Success + keying material 14. EAP Success 15. Complete IKEv2 signalling 16. VoLGA registration

Figure B.3.1-1: EAP-AKA authentication procedure 1. 2. The UE connects to EPS and performs the VANC discovery procedure. The UE obtains the IP address of the SeGW, and initializes the IKEv2 authentication procedure by starting the IKE_SA_INIT exchange. It indicates the desire to use EAP by leaving out the AUTH payload from message 3, the first message of the IKE_AUTH exchange, and the initiator identity is composed compliant with the Network Access Identifier (NAI) format specified in RFC 4282 [20], which contains the IMSI and an indication that EAP-AKA should be used. The SeGW selects a AAA Server. The SeGW sends an EAP Response/Identity message to the AAA Server, containing the initiator identity included in the third IKE message. The leading digit of the NAI indicates that the UE wishes to use EAP-AKA. The AAA Server identifies the subscriber as a candidate for authentication with EAP-AKA, based on the received identity, and verifies that EAP-AKA shall be used based on subscription information, The AAA server requests the UMTS authentication vector(s) from the HSS/HLR, if these are not available in the AAA server. Optionally, the AAA receives UMTS authentication vector(s) from the HSS/HLR. The UMTS authentication vector consists of a random part (RAND), an authentication part (AUTH), an expected result part (XRES) and sessions keys for integrity check (IK) and encryption (CK). The AAA Server determines that EAP-AKA will be used.

3. 4. 5.

6.

VoLGA Forum

Phase 1

91

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

7.

The AAA Server formulates an EAP-Request/AKA Challenge with RAND, AUTN and includes a message authentication code (MAC) whose master key is computed based on the associated IK and CK. A new re-authentication identity may be chosen and protected (i.e., encrypted and integrity protected) using EAPAKA generated keying material. The AAA Server sends the RAND, AUTN, MAC and re-authentication identity to the SeGW in the EAP Request/AKA-Challenge message. The SeGW forwards the EAP Request/AKA-Challenge message to the UE. The UE runs the UMTS algorithm on the USIM. The USIM verifies that the AUTN is correct and thereby authenticates the network. If AUTN is incorrect, the UE rejects the authentication (not shown in the figure). If AUTN is correct, the USIM computes RES, IK and CK. The UE calculates a new MAC with the new keying material (IK and CK) covering the EAP message. If a re-authentication ID was received, then the UE stores this ID for future authentications.

8. 9.

10. The UE sends EAP Response/AKA-Challenge containing the calculated RES and MAC to the SeGW. 11. The SeGW forwards the EAP Response/AKA-Challenge message to the AAA Server. 12. The AAA Server verifies the received MAC and compares XRES to the received RES. 13. If the checks in step 12 are successful, then the AAA Server sends the EAP Success message to the SeGW. The AAA Server includes derived keying material for confidentiality and/or integrity protection between the UE and the SeGW, in the underlying AAA protocol message (i.e., not at the EAP level). 14. The SeGW informs the UE of the successful authentication with the EAP Success message. 15. Now the EAP-AKA exchange has been successfully completed, the IKEv2 signaling can be completed. 16. The Secure Association between the UE and SeGW is complete and the UE can continue with the VoLGA registration procedure.

B.3.2 EAP-AKA fast re-authentication procedure

When the authentication process is performed frequently, especially with a large number of connected UEs, performing fast re-authentication can reduce the network load resulting from this authentication. The fast re-authentication process allows the AAA Server to authenticate a UE based on keys derived from the last full authentication process. Fast re-authentication is supported by EAP-AKA, and does not make use of the UMTS security algorithms. The UE may include the re-authentication ID in the IKE_SA_INIT. The decision to make use of the fast re-authentication procedure is taken by the AAA Server, based on operator policy. The basic elements of the EAP-AKA fast re-authentication procedure are the following: - The UE initiates a new SA with a SeGW that it was previously connected to and uses the re-authentication ID (re-authentication ID received during the previous full authentication procedure) in the IKE_SA_INIT exchange. The EAP-AKA procedure is started as a result of these exchanges. - The AAA Server and UE re-authenticate each other based on the keys derived on the preceding full authentication.

VoLGA Forum

Phase 1

92

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

Figure B.3.2-1: EAP-AKA fast re-authentication procedure 1. The UE initializes the IKEv2 authentication procedure by starting the IKE_SA_INIT exchange. It indicates the desire to use EAP by leaving out the AUTH payload from message 3, the first message of the IKE_AUTH exchange, and the initiator identity contains the re-authentication identity (this identity was previously delivered by the AAA Server in a EAP-AKA full authentication procedure). The SeGW sends an EAP Response/Identity message to the AAA Server, containing the re-authentication ID that was included in the third IKE message. This triggers the start of EAP-AKA. The AAA Server initiates the Counter (which was initialized to one in the full authentication process) and sends it in the EAP Request/AKA-Reauthentication message, together with the NONCE, the MAC (calculated over the NONCE) and a re-authentication id for a next fast re-authentication. If the AAA Server is not able to deliver a re-authentication identity, then the UE shall force a full-authentication next time (to avoid the use of the re-authentication identity more than once). The SeGW forwards the EAP Request/AKA-Reauthentication message to the UE. The UE verifies that the Counter value is fresh and the MAC is correct. The UE sends the EAP Response/AKA-Reauthentication message with the same Counter value and a calculated MAC to the SeGW. The SeGW forwards the response to the AAA Server. The AAA Server verifies that the Counter value is the same as it sent, and that the MAC is correct. The AAA Server sends an EAP Success message to the SeGW.

2. 3.

4. 5. 6. 7. 8. 9.

10. The SeGW forwards the EAP Success message to the UE.

VoLGA Forum

Phase 1

93

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

B.4

VoLGA security profiles

B.4.1 Profile of IKEv2

IKEv2, as specified in [18], contains a number of options, where some are not needed for the purposes of this specification and others are required. IKEv2 is therefore profiled in this sub-clause. When IKEv2 is used in the context of this specification the profile specified in this sub-clause shall be supported. The following three profiles shall be supported by the UE and SeGW. The SeGW shall support all three profiles, while the UE shall support at least one of the three profiles in order of preference stated below: - First cryptographic suite: Confidentiality: AES with fixed key length in CBC mode. The key length is set to 128 bits (also known as ENCR_AES_CBC) per RFC 3602 [22]. Pseudo-random function: HMAC-SHA1 (also known as PRF_HMAC_SHA1) per RFC 2104 [23]. Integrity: HMAC-SHA1-96 (also known as AUTH_HMAC_SHA1_96) per RFC 2404 [25]. Diffie-Hellman group 2 (1024-bit MODP) per RFC 2409 [28].

- Second cryptographic suite: Confidentiality: 3DES in CBC mode (also known as ENCR_3DES) per RFC 2451 [21]. Pseudo-random function: HMAC-SHA1 (also known as PRF_HMAC_SHA1) per RFC 2104 [23]. Integrity: HMAC-SHA1-96 (also known as AUTH_HMAC_SHA1_96) per RFC 2404 [25]. Diffie-Hellman group 2 (1024-bit MODP) per RFC 2409 [28].

- Third cryptographic suite: Confidentiality: AES with fixed key length in CBC mode. The key length is set to 128 bits (also known as ENCR_AES_CBC) per RFC 3602 [22]. Pseudo-random function: AES-XCBC-PRF-128 (also known as PRF_AES128_XCBC) per RFC 4434 [29]. Integrity: AES-XCBC-MAC-96 (also known as AUTH_AES_PRF_128) per RFC 3566 [27]. Diffie-Hellman group 2 (1024-bit MODP) per RFC 2409 [28].

B.4.2 Profile of IPsec ESP

IPSec ESP, as specified in [19], contains a number of options, where some are not needed for the purposes of this specification and others are required. IPSec ESP is therefore profiled in this sub-clause. When IPSec ESP is used in the context of this specification the profile specified in this sub-clause shall be supported. The following three profiles shall be supported by the UE and SeGW. The SeGW shall support all three profiles, while the UE shall support at least one of the three profiles in order of preference stated below: - First cryptographic suite: Confidentiality: AES with fixed key length in CBC mode. The key length is set to 128 bits (also known as ENCR_AES_CBC) per RFC 3602 [22]. Integrity: HMAC-SHA1-96 (also known as AUTH_HMAC_SHA1_96) per RFC 2404 [25]. Tunnel mode must be used.

- Second cryptographic suite: Confidentiality: 3DES in CBC mode (also known as ENCR_3DES) per RFC 2451 [21].

VoLGA Forum

Phase 1

94

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

Integrity: HMAC-SHA1-96 (also known as PRF_HMAC_SHA1). The key length is 160 bits, according to RFC 2104 [23] and RFC 2404 [25]. Tunnel mode must be used.

- Third cryptographic suite: Confidentiality: AES with 128-bit keys in CBC mode. The key length is set to 128 bits (also known as ENCR_AES_CBC) per RFC 3602 [22]. Integrity: AES-XCBC-MAC-96 (also known as AUTH_AES_PRF_128) per RFC 3566 [27]. Tunnel mode must be used.

Annex C (informative): VoLGA PDN connection usage

This annex describes how the requirements for PDN connection / EPS bearer context usage, laid down in the VoLGA stage1 specification, have been accounted for in the present document. More specifically, it provides a detailed description of the ways that bearer resources and PDN connections are used by VoLGA, that have been the foundation of the procedures specified in the present document.

C.1

PDN connection management for VoLGA

When the UE chooses to activate VoLGA service (see annex A), it first needs to acquire the appropriate PDN connection. The APN to use for VoLGA service can be configured on the UE per VPLMN. As part of VoLGA activation, the UE first checks if it already has a PDN connection on the APN that is configured for VoLGA in the serving PLMN. If so, the UE uses this PDN connection for VoLGA, regardless of whether the PDN connection is also used for other (i.e., non-VoLGA) services. If the UE does not already have a PDN connection to the VoLGA APN, then it activates this PDN connection employing the EPS procedures specified in TS 23.401 [3]. Note: the UE binds the VoLGA application to the selected PDN connection and thereby to the IP address that was assigned to that PDN connection. This (source) IP address may be used as a parameter to populate TFTs, as mentioned in this annex. If the VoLGA PDN connection is also used for other services, the UE may request dedicated bearer resources for these other services. However, the UE does not request dedicated bearer resources on the VoLGA PDN connection for use with VoLGA. In contrast, upon the UEs activation of VoLGA or at any other point in time, the network may assign dedicated bearer resources to the UE for VoLGA, if so configured by the Operator. The use of PDN connections and default / dedicated bearer resources on those PDN connections in relation to VoLGA and the potential other services including the exclusive use of a PDN connection or dedicated bearer for VoLGAis determined by the network setting appropriate packet filters, as specified in TS 23.203 [6] and TS 23.401 [3]. In scenarios where the UE activates a dedicated VoLGA PDN connection after EPS attach and default connectivity establishment, the UE should subsequently release the default connectivity if it is not used / needed by the UE for other purposes.

C.2

VoLGA signaling bearer

By default, the UE uses the default bearer on the VoLGA PDN connection for VoLGA signalling. It does not request dedicated bearer resources for use with VoLGA signalling on that PDN connection. However, the network may establish dedicated bearer resources for VoLGA signalling at any time, depending on Operator configuration, using the related procedures specified in TS 23.203 [6] and TS 23.401 [3]. The UE uses the same PDN connection for all VoLGA signalling. This implies, e.g.: when the UE uses the EPS default connectivity for VoLGA service discovery, it also uses the EPS default connectivity for other VoLGA signalling; when the UE uses a dedicated PDN connection for VoLGA service discovery, it also uses that PDN connection for other VoLGA signalling.

VoLGA Forum

Phase 1

95

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

C.3

VoLGA user plane bearer

VoLGA user plane bearers are dedicated EPS bearers on the same PDN connection that is used for VoLGA signalling. They are under full control of the network, i.e. it is always the network that establishes and releases these bearers. The UE does not request any bearer resources for the VoLGA user plane. It is under the sole responsibility of the network to assign the proper packet filters so that the VoLGA service actually runs on the intended VoLGA user plane bearer.

Annex D (informative): User location information verification for SMS-only service

D.1 General

When VoLGA SMS-only service is provided from the HPLMN for a UE that is roaming in a VPLMN, it is not necessary to verify the cell ID provided by the UE on each SMS transfer; i.e., since the HPLMN will have limited visibility into the internal structure of the VPLMN E-UTRAN. However, operators may require verification of the PLMN-ID provided in the TAI when the UE registers for VoLGA SMS-only service from a VPLMN, since the HPLMN may wish to restrict this service to a subset of potential roaming partners (e.g., those partners that do not offer VoLGA service). Extending the current VoLGA approach to cell ID verification (see sub-clause 9.16) requires that the VANC support the "Lr" interface defined in TS 23.271. This annex describes a simpler alternative means of verification of the PLMN-ID provided when the UE registers for VoLGA SMS-only service.

D.2

PLMN-ID verification via GIBA-like mechanism

TS 33.203 [37] Annex T describes the "GPRS-IMS-Bundled Authentication" (GIBA) mechanism, which is "an interim security solution for early IMS implementations that are not fully compliant with the IMS security architecture specified in the main body of this specification." The GGSN terminates each user's PDP context and has assurance that the IMSI used within this PDP context is authenticated. The GGSN shall provide the user's IP address (or the prefix in the case of IPv6 stateless autoconfiguration), IMSI and MSISDN to a RADIUS server in the HSS over the Gi interface when a PDP context is activated towards the IMS system. The HSS has a binding between the IMSI and/or MSISDN and the IMPI and IMPU(s), and is therefore able to store the currently assigned IP address (or the prefix in the case of IPv6 stateless autoconfiguration) from the GGSN against the user's IMPI and/or IMPU(s). The precise way of the handling of these identities in the HSS is outside the scope of standardization. The GGSN informs the HSS when the PDP context is deactivated/modified so that the stored IP address (or the prefix in the case of IPv6 stateless autoconfiguration) can be updated in the HSS. When the S-CSCF receives a SIP registration request or any subsequent requests for a given IMPU, it checks that the IP address (or the prefix in the case of IPv6 stateless autoconfiguration) in the SIP header (verified by the network) matches the IP address (or the prefix in the case of IPv6 stateless autoconfiguration) that was stored against that subscriber's IMPU in the HSS. The mechanism assumes that the GGSN does not allow a UE to successfully transmit an IP packet with a source IP address (or the prefix in the case of IPv6 stateless autoconfiguration) that is different to the one assigned during PDP context activation. In other words, the GGSN must prevent "source IP spoofing". The mechanism also assumes that the P-CSCF checks that the source IP address in the SIP header is the same as the source IP address in the IP header received from the UE (the assumption here, as well as for the full security solution, is that no NAT is present between the GGSN and the P-CSCF). We note that TS 29.274 [30] specifies the following: The Create Session Request message shall be sent on the S11 interface by the MME to the SGW, and on the S5/S8 interface by the SGW to the PGW as part of the procedures: E-UTRAN Initial Attach

VoLGA Forum

Phase 1

96

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

UE requested PDN connectivity

The Create Session Request message received by the P-GW includes the following parameter (among others):
User Location Information (ULI) C This IE shall be included for E-UTRAN Initial Attach and UE-requested PDN Connectivity procedures. It shall include ECGI&TAI. The MME/SGSN shall also include it for TAU/RAU/Handover procedures if the PGW has requested location information change reporting and MME/SGSN support location information change reporting. The SGW shall include this IE on S5/S8 if it receives the ULI from MME/SGSN. ULI 0

Therefore, the P-GW obtains the ULI (i.e., ECGI and TAI) from the S-GW. With this as background, the simplified user location verification mechanism works as follows: 1. The P-GW terminates each UE PDN connection and has assurance that the IMSI used within this PDN connection is authenticated. The P-GW also receives the User Location Information (ULI), including the TAI and ECGI, from the S-GW during E-UTRAN Initial Attach and UE requested PDN connectivity procedures. 2. The P-GW shall provide the user's IMSI and ULI to a AAA server over the SGi interface when a PDN connection is activated towards the APN configured for accessing the VoLGA service. 3. The AAA server stores this information. 4. The P-GW informs the AAA server when the PDN connection is deactivated so that the stored information can be updated. 5. When the VANC receives a VoLGA registration request, it retrieves the ULI associated with the users IMSI from the AAA server to verify that the PLMN ID in the Tracking Area Identity IE (i.e., received in the registration request) matches the information that was stored against that subscriber's IMSI in the AAA server. The AAA server may be a standalone system or may be integrated into the HSS. Examples of possible interface protocols between the VANC and the AAA server are RADIUS, Diameter, and LDAP. Further details regarding this solution are vendor dependent and based on operator requirements.

Annex Z (informative): Change history

Change history
Date Subject/Comment Old New

03-13-09 Contribution V04-KIN-001 03-20-09 Implemented accepted text from the following VoLGA Meeting #4 contributions: V04-ALU-005, V04-ALU-007, V04-HUA-004, V04-HUA-005, V04-HUA-006, V04-KIN-002, V04-KIN-007, V04-KIN-008, V04-MOT-004, V04-MOT-006, V04-MOT-007, V04-RIM-005 04-28-09 Implemented accepted text from the following VoLGA Meeting #5 contributions: V05-HUA-001, V05-HUA-002, V05-HUA-005, V05-HUA-008, V05-HUA-009, V05-KIN-003, V05-KIN-005, V05-KIN-006, V05-KIN-007, V05-KIN-008, V05-KIN-009, V05-SAM-010, V05-MOT-001, V05-RIM-001, V05-RIM-005 06-17-09 Implemented accepted text from the following VoLGA Meeting #6 contributions: V06-HUA-005, V06-KIN-010, V06-KIN-011, V06-KIN-012, V06-KIN-016, V06-MOT-002, V06-MOT-004, V06-MOT-007, V06-RIM-007. Removed editorial notes related to items not included in VoLGA Phase 1. 06-24-09 Editorial corrections. 07-17-09 Implemented accepted text from the following VoLGA Meeting #7 contributions: V07-ALU-001, V07-ALU-002, V07-HUA-002, V07-HUA-003, V07-KIN-001, V07-KIN-009, V07-KIN-011, V07-NOR-005, V07-ZTE-003, V07-ZTE-004, V07-ZTE-006.

0.0.1

0.0.1 0.1.0

0.1.0

0.2.0

0.2.0

1.0.0

1.0.0 1.0.1

1.0.1 1.1.0

VoLGA Forum

Phase 1

97

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

08-24-09 Implemented accepted text from the following VoLGA Meeting #8 contributions: V08-ALU-007, V08-HUA-007, V08-KIN-003, V08-KIN-008, V08-KIN-014, V08-KIN-017, V08-MOT-001, V08-MOT-007. Editorial changes to use NOTE style consistently throughout specification. 10-20-09 Implemented accepted text from the following VoLGA Meeting #9 contributions: V09-HUA-006, V09-HUA-007, V09-HUA-008, V09-KIN-006. 11-20-09 Implemented accepted text from the following VoLGA Meeting #10 contributions: V10-ALU-004, V10-DTG-009, V10-KIN-003, V10-KIN-004, V10-KIN-006, V10-KIN-011. 02-01-10 Implemented accepted text from the following VoLGA Meeting #11 contributions: V11-KIN-006, V11-KIN-011, V11-KIN-012, V11-KIN-013. 03-05-10 Implemented accepted text from the following VoLGA Meeting #12 contributions: V12-KIN-004, V12-KIN-011, V12-KIN-012. Added abbreviations to sub-clause 3.2. 05-11-10 Implemented accepted text from the following VoLGA Meeting #13 contributions: V13-KIN-001, V13-KIN-009, V13-KIN-024. 06-01-10 Implemented accepted text from the following VoLGA Meeting #13 contributions: V13-DTG-009, V13-DTG-011, V13-KIN-028. 06-14-10 Removed working draft designation after completion of email approval.

1.1.0

1.2.0

1.2.0 1.3.0

1.3.0 1.4.0

1.4.0 1.5.0 1.6.0 1.7.0WD1 1.7.0WD2

1.5.0 1.6.0 1.7.0WD1 1.7.0WD2 1.7.0

VoLGA Forum