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

Transcription

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
2
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
3
VoLGA Stage 2 V1.7.0 (2010-06-14)
Contents
Foreword ............................................................................................................................................................6
1
Scope ........................................................................................................................................................7
2
References ................................................................................................................................................7
3
Definitions and abbreviations...................................................................................................................8
3.1
3.2
4
4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
5
5.1
5.2
5.2.1
5.2.2
5.3
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
7
7.1
7.1.1
7.1.2
7.2
7.2.1
7.2.2
7.3
7.4
7.5
8
8.1
8.2
8.3
8.3.1
8.3.2
9
9.1
9.1.1
9.1.2
9.1.3
Definitions............................................................................................................................................................. 8
Abbreviations ........................................................................................................................................................ 9
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
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
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
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
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
Procedures for VoLGA A-mode ............................................................................................................22
Rove-in ................................................................................................................................................................ 22
General........................................................................................................................................................... 22
VANC discovery ........................................................................................................................................... 23
VoLGA registration....................................................................................................................................... 25
VoLGA Forum
Phase 1
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
10
11.1
VoLGA Stage 2 V1.7.0 (2010-06-14)
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
Procedures for VoLGA Iu-mode............................................................................................................54
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
4
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
HOSF procedures ...................................................................................................................................74
Create VANC-UE binding in HOSF .................................................................................................................. 74
VoLGA Forum
Phase 1
11.2
12
12.1
12.2
12.2.1
12.2.2
12.2.3
5
VoLGA Stage 2 V1.7.0 (2010-06-14)
Delete VANC-UE binding in HOSF .................................................................................................................. 75
VoLGA configuration mechanisms .......................................................................................................75
General ................................................................................................................................................................ 75
VoLGA configuration properties........................................................................................................................ 75
VANC discovery control............................................................................................................................... 75
Voice mode control ....................................................................................................................................... 75
Security configuration ................................................................................................................................... 75
Annex A (normative): VoLGA coexistence with IMS & CSFB ......................................................................76
A.1
A.2
A.2.1
A.2.2
A.3
A.4
A.5
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
Annex B (normative): VoLGA security mechanisms ......................................................................................89
B.1
B.2
B.3
B.3.1
B.3.2
B.4
B.4.1
B.4.2
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
Annex C (informative): VoLGA PDN connection usage.................................................................................94
C.1
C.2
C.3
PDN connection management for VoLGA ........................................................................................................ 94
VoLGA signaling bearer..................................................................................................................................... 94
VoLGA user plane bearer ................................................................................................................................... 95
Annex D (informative): User location information verification for SMS-only service ...................................95
D.1
D.2
General ................................................................................................................................................................ 95
PLMN-ID verification via GIBA-like mechanism............................................................................................. 95
VoLGA Forum
Phase 1
6
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
1
7
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.
2
References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document. References may be other VoLGA specifications, or specifications from other standards entities, such as
3GPP, IETF, etc.
 References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
 For a specific reference, subsequent revisions do not apply.
 For a non-specific reference, the latest version applies.
[1]
VoLGA Forum: "Voice over LTE via Generic Access; Requirements Specification; Phase 1".
[2]
3GPP TS 43.318: "Generic Access Network (GAN); Stage 2".
[3]
3GPP TS 23.401: "GPRS enhancements for E-UTRAN access".
[4]
3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[5]
3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[6]
3GPP TS 23.203: "Policy and charging control architecture".
[7]
3GPP TS 44.318: "Generic Access Network (GAN); Mobile GAN interface layer 3 specification".
[8]
3GPP TS 23.271: "Functional stage 2 description of Location Services (LCS)".
[9]
3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2".
[10]
3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".
[11]
IETF RFC 4867, April 2007: "RTP Payload Format and File Storage Format for the Adaptive
Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".
[12]
3GPP TS 23.228: "IP Multimedia Subsystem; Stage 2".
[13]
3GPP TS 23.272: "Circuit Switched Fallback in Evolved Packet System; Stage 2".
[14]
3GPP TS 23.292: "IP Multimedia System (IMS) centralized services, Stage 2".
[15]
Void
VoLGA Forum
Phase 1
8
VoLGA Stage 2 V1.7.0 (2010-06-14)
[16]
3GPP TS 24.008: "Mobile radio interface layer 3 specification".
[17]
IETF RFC 4187, January 2006: "Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)".
[18]
IETF RFC 4306, December 2005: "Internet Key Exchange (IKEv2) Protocol)".
[19]
IETF RFC 2406, November 1998: "IP Encapsulating Security Payload (ESP)".
[20]
IETF RFC 4282, December 2005: "The Network Access Identifier".
[21]
IETF RFC 2451: "The ESP CBC-Mode Cipher Algorithms".
[22]
IETF RFC 3602: "The AES-CBC Cipher Algorithm and Its Use with IPsec".
[23]
IETF RFC 2104: "HMAC: Keyed-Hashing for Message Authentication".
[24]
IETF RFC 2315: "PKCS #7: Cryptographic Message Syntax Version 1.5".
[25]
IETF RFC 2404: "The Use of HMAC-SHA-1-96 within ESP and AH".
[26]
IETF RFC 2406: "IP Encapsulating Security Payload (ESP)".
[27]
IETF RFC 3566: "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec".
[28]
IETF RFC 2409: "The Internet Key Exchange (IKE)".
[29]
IETF RFC 4434, February 2006: "The AES-XCBC-PRF-128 Algorithm for the Internet Key
Exchange Protocol (IKE)".
[30]
3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".
[31]
3GPP TS 29.280: "Evolved Packet System (EPS); 3GPP Sv interface (MME to MSC, and SGSN
to MSC) for SRVCC".
[32]
3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security Architecture".
[33]
3GPP TS 23.236: " Intra-domain connection of Radio Access Network (RAN) nodes to multiple
Core Network (CN) nodes ".
[34]
OMA-DDS-DM_ConnMO-V1_0-20081107-A: "Standardized Connectivity Management
Objects", Approved Version 1.0 – 07 Nov 2008.
[35]
3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle
mode".
[36]
3GPP TS 23.221: "Architectural requirements".
[37]
3GPP TS 33.203: "3G security; Access security for IP-based services".
[38]
3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and
Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
3
Definitions and abbreviations
3.1
Definitions
GERAN/UTRAN Mode: UE mode of operation where the CS domain NAS layers communicate through either the
GERAN RR entity or the UTRAN RRC entity.
VoLGA Mode: UE mode of operation where the CS domain NAS layers communicate through the VoLGA RR entity
for CS services. It includes VoLGA A-mode and VoLGA Iu-mode.
VoLGA Forum
Phase 1
9
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
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
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
VoLGA Forum
Phase 1
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
10
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
VoLGA Stage 2 V1.7.0 (2010-06-14)
Phase 1
11
4
High level principles
4.1
Architectural requirements
VoLGA Stage 2 V1.7.0 (2010-06-14)
-
The VoLGA solution shall impact neither the MME interfaces nor the MME behavior, as specified in current
3GPP specs.
-
Coexistence between IMS/SRVCC and VoLGA shall be possible with no modifications to MME.
-
A VoLGA UE that supports handover to GERAN/UTRAN indicates SRVCC capability to the E-UTRAN/EPS.
4.2
High level functions
4.2.1
VANC discovery support functions
DHCP and DNS interfaces are typically not included in architecture diagrams or described as reference points. For
VoLGA VANC discovery, described in sub-clause 9.1.2, DHCP and DNS interactions take place between the UE and
these services. The details of these interactions are a matter for stage 3 specification.
The DNS server shall be accessed in the same PDN as the VANC. The PDN GW shall support the DHCP server
function including VANC discovery specific options. The UE shall interact with DNS and DHCP services for the
purpose of VANC discovery by means of the PDN connection after this has been established by means of the PDN GW.
4.2.2
Security context handling functions
The UE shall use the CS domain security context information (i.e., {KSI, CK, IK} or {CKSN, Kc}) that results from the
authentication and security mode control/cipher mode command procedures performed between the UE and MSC in
VoLGA mode, when (and if) handover to GERAN/UTRAN is necessary.
The UE shall not derive a new CS domain security context based on the EPS security context, per the procedures
specified for SRVCC in TS 33.401 [32].
The VANC shall discard the derived security context received from the MME in the SRVCC CS to PS Handover
Request message.
When handing over to UTRAN, the UE shall reset the CS domain START value to 0.
4.2.3
Handover functions
For intra-E-UTRAN handover, VoLGA uses the Intra-E-UTRAN handover procedure specified in TS 23.401 [3].
For handover from E-UTRAN to GERAN or UTRAN CS, VoLGA uses the SRVCC PS to CS handover functions
defined in TS 23.216 [5] for handover to GERAN/UTRAN CS domain.
The SRVCC PS to CS handover procedures only apply when the VoLGA CS service uses an EPS bearer with QCI 1.
This is the case for VoLGA speech calls. It can also be the case for fax and CS data calls if the VANC requests QCI 1
resources for these services.
VoLGA CS services that operate solely over the VoLGA signalling channel (e.g., SMS and USSD) are not handed over
to GERAN/UTRAN. If the UE is directed to handover to GERAN/UTRAN while one of these services is ongoing, the
UE shall abort the service and depend on retry mechanisms to complete the service.
VoLGA does not support CS to PS handover from GERAN/UTRAN CS domain to E-UTRAN.
4.2.4
HOSF selection function
VoLGA uses the SRVCC MSC Server selection function for the purpose of HOSF selection by the MME during PS to
CS handover to GERAN/UTRAN; i.e., from the MME's perspective, an SRVCC MSC Server is being selected.
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.
5
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
Sv
MSC
Server
A or Iu-CS
MSC/
VLR
HOSF
Z3
S1-c
MME
VANC
“LTE Uu”
UE
E-UTRAN
S1-u
S-GW
P-GW
SGi
Gx
SeGW
Rx
Wm
D
PCRF
AAA
Server
D’
HLR/HSS
Z1
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
MME
S1-u
S-GW
S6a
“LTE Uu”
UE
E-UTRAN
Gxc
S8
V-PCRF
VPLMN
HPLMN
P-GW
S9
SGi
Gx
VANC
Rx
MSC/
VLR
A or Iu-CS
Wm
D
H-PCRF
AAA
Server
D’
HLR/HSS
Z1
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
5.3
14
VoLGA Stage 2 V1.7.0 (2010-06-14)
Reference points
SGi:
SGi is defined in TS 23.401 [3]. It is the reference point between the P-GW and the packet data network.
The "packet data network" is the CS core network connected by VANC in this specification.
Sv:
Sv is defined in TS 23.216 [5], where it is defined as the reference point between the MME/SGSN and
MSC Server. In this specification, Sv applies to two interfaces: (1) between the MME and HOSF, and (2)
between the HOSF and MSC Server.
Z1:
Z1 is the reference point between the UE and VANC, which is based on the Up interface defined in TS
43.318 [2].
Z3:
Z3 is the reference point between the VANC and HOSF. It is based on GTPv2-C as specified in TS
29.274 [30]. The Z3 reference point is used for the creation and deletion of VANC-UE bindings in the
HOSF, and to route the SRVCC PS to CS Handover Request message to the VANC.
6
Functional entities
6.1 E-UTRAN
The functionality for E-UTRAN is specified in TS 36.300[9]. In addition, E-UTRAN needs to provide support for
SRVCC as specified in TS 23.216[5].
NOTE:
E-UTRAN configuration shall ensure that VoLGA CS calls are not handed over to the GERAN/UTRAN
PS domain.
No additional functionality is required of the E-UTRAN to support VoLGA.
6.2 MME
The functionality for MME is specified in TS 23.401[3]. In addition, MME needs to provide support for SRVCC as
specified in TS 23.216 [5].
No additional functionality is required of MME to support VoLGA.
6.3 S-GW and P-GW
The functionality of S-GW and P-GW are specified in TS 23.401[3] for GTP based S5/S8 and TS 23.402[10] for 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.
7
Protocol architecture
7.1 VoLGA A-mode protocol architecture
7.1.1 Control plane
The protocol architecture for the VoLGA A-mode control plane is illustrated in the following figure.
Figure 7.1.1-1: Protocol stack for VoLGA control plane (VoLGA A-mode)
NOTE:
GA-CSR/GA-RC refer to the existing GAN protocols in TS 44.318 [7] plus changes defined for VoLGA.
The GA-RC protocol provides a resource management layer, including the following functions:
-
registration with the VANC, including VoLGA mode selection (VoLGA A-mode or VoLGA Iu-mode);
-
registration update with the VANC; and
-
application level keep-alive with the VANC.
The GA-CSR protocol provides a resource management layer, which is equivalent to the GERAN RR and provides the
following functions:
- setup of bearer for CS voice and CS data traffic between the UE and VANC;
- direct transfer of NAS messages between the UE and the CS core network (i.e., for MM and CM signalling, and
for SMS and USSD data transport); and
- functions such as paging, ciphering configuration, and classmark change.
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
8
VoLGA states
8.1 General
The VoLGA Registration Management (VRM) states describe the registration status of the UE.
The VoLGA Connection Management (VCM) states describe the logical signalling connectivity between the UE and
the VANC, i.e. the VoLGA signalling connection analogous to the GERAN RR connection or the UTRAN RRC
connection.
The VCM states depend on whether VoLGA A-mode or VoLGA Iu-mode is being used.
The VCM states are valid when the registration state is GA-RC-REGISTERED.
NOTE:
The VRM and the VCM states are independent from the EPS states defined in TS 23.401 [3].
8.2 VoLGA Registration Management state model
The VRM state diagram is shown in the following figure.
GA-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).
9
Procedures for VoLGA A-mode
9.1 Rove-in
9.1.1 General
"Rove-in" is the process in which the UE switches the serving RR entity for CS domain services to GA-CSR (VoLGA
A-mode) or GA-RRC (VoLGA Iu-mode). When preparing to rove in, if the UE is not already registered with a VANC,
the UE performs the following procedures:
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
NOTE:
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
6.
If DNS resolution is successful, then the UE is ready to attempt VoLGA registration as described in sub-clause
9.1.3.
9.1.3 VoLGA registration
If the UE has successfully completed the VANC discovery procedure (i.e., has the address of a SeGW and a VANC),
the UE may attempt VoLGA registration. The VANC may accept or reject the registration or redirect the UE to 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).
NOTE:
The UE is assigned its "remote IP address" (see sub-clauses 7.1.1 and 7.2.1) using the IKEv2
configuration payload procedure.
VoLGA Forum
Phase 1
26
VoLGA Stage 2 V1.7.0 (2010-06-14)
2.
If the UE received a VANC domain name during VANC discovery, the UE uses DNS to resolve the VANC
domain name.
3.
The UE establishes a TCP connection to the assigned VANC. The TCP keepalive option shall not be enabled
by the UE. Detection of a TCP connection failure is handled using the GA-RC KEEP ALIVE message
procedure (see sub-clause 9.4).
4.
The UE registers with the VANC, using the GA-RC REGISTER REQUEST message. The message contains:
-
EPS Tracking Area ID (TAI)
-
the current camping E-UTRAN cell ID
-
UE IMSI
-
UE GUTI
-
GAN Classmark: Including indication of support for VoLGA service
-
The "transport IP address" assigned to the UE (see sub-clauses 7.1.1 and 7.2.1); the VANC stores this
address and uses it as the destination IP address for RTP packets sent to the UE (e.g., in the case of a MO or
MT call).
-
Optionally, an indication that SMS-only service is requested by the UE.
NOTE:
The conditions for the UE to include this indicator (e.g., when the UE is roaming on a VPLMN or only
after a registration request without the indicator has failed) are up to UE configuration.
5a. If the VANC accepts the registration attempt it may request specific QoS for the VoLGA signalling flow using
the Rx interface to the PCRF, per the procedures in TS 23.401 [2] and TS 23.203 [6].
NOTE 1: The authorization of the QoS for the signalling flow may incur the activation or modification of an EPS
bearer.
NOTE 2: This step can be used to verify the binding between the received UE IMSI and transport IP address by the
PCRF, since these parameters are provided by the VANC to the PCRF in the AA-Request message per
TS 29.214.
5b. The VANC then responds with a GA-RC REGISTER ACCEPT message. The message contains VoLGA
specific system information, including:
-
GAN Mode Indicator: A/Gb mode or Iu mode (i.e., VoLGA A-mode or Iu-mode, respectively)
-
VoLGA Location Area Identification (LAI) comprising the mobile country code, mobile network code, and
location area code allocated by the VANC. If the VoLGA LAI is not the same as the stored LAI, the UE
performs the CS domain location area update procedure via the VoLGA control plane.
-
Applicable system timer values
-
Optionally, a list (i.e., containing one or more entries) of the EPS TAIs that are served by the VANC. This
is referred to as the "VANC TAI List". The VANC TAI List may be used to control the VoLGA
registration update procedure, as described in sub-clause 9.3.
NOTE:
The VANC TAI List is independent from the TAI List allocated by the MME
-
Optionally, a "registration update suppression" indicator. This indicator shall be included when a roaming
UE connects to a VANC in its HPLMN for SMS-only service.
-
Access network preference for the placement of emergency calls; i.e., GERAN/UTRAN CS domain or
VoLGA in E-UTRAN
-
Optionally, the domain name or IP address of the VANC (see sub-clause 9.4.2)
In this case the secure tunnel and TCP connection are not released and are maintained as long as the UE is
registered to this VANC. If the LAI is not the same as the stored LAI, the UE performs the CS domain location
area update procedure via the VoLGA control plane.
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 UE’s 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
VANC: Accept and
indicate VoLGA A-mode
UE: Proceed per VoLGA
A-mode procedures
Iu-mode only
VANC: Redirect UE to
VoLGA Iu-mode capable
Iu-mode only
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
VoLGA Forum
Both modes
VANC: Handle as normal
VoLGA A-mode
registration. If required,
redirect UE to VoLGA Amode capable VANC.
A-mode procedures
VANC: Accept and
Phase 1
28
VANC or reject registration
Iu-mode procedures
Iu-mode procedures
VANC: Accept and
indicate VoLGA A-mode
VANC: Accept and
A-mode procedures
Iu-mode procedures
VANC: Accept and
or VoLGA A-mode (Note
1). If required, redirect UE
to VoLGA Iu-mode or
VoLGA A-mode capable
VANC.
UE: Handle per registration
redirection or reject
procedures
Both modes
VoLGA Stage 2 V1.7.0 (2010-06-14)
Iu-mode or VoLGA Amode procedures
NOTE 1: The VANC’s 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.
The UE sends the GA-RC DEREGISTER message to the VANC, which removes the UE context in the
VANC.
2.
The VANC deletes the VANC-UE binding previously created for the UE on one or more HOSF(s). The
procedure to delete a VANC-UE binding is described in sub-clause 11.2.
3.
If the VANC had previously authorized the VoLGA signalling flow using the Rx interface to the PCRF (see
step 5 in sub-clause 9.1.3), then the VANC deauthorizes the VoLGA signalling flow (which results in the
release of the VoLGA signalling bearer) via the Rx interface to the PCRF.
Figure 9.2.2-2: VoLGA deregistration initiated by the VANC
1.
The VANC sends the GA-RC DEREGISTER message to the UE.
2-3. Same as steps 2-3 in Figure 9.2.2-1.
9.3 VoLGA registration update
9.3.1 Registration update downlink
The VoLGA registration update downlink procedure allows the VANC to autonomously update the VoLGA system
information in the UE (e.g., VoLGA LAI, VANC TAI List), if needed, by sending a GA-RC REGISTER UPDATE
DOWNLINK message to the UE carrying the updated information.
UE
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.
When the UE detects any of the conditions listed above, it shall send the GA-RC REGISTER UPDATE
UPLINK message to the VANC with the updated information.
2.
The VANC may send the GA-RC REGISTER REDIRECT (VANC address) message when it wants to redirect
the UE based on updated information. The UE performs the registration procedure on the new VANC as
specified in sub-clause 9.1.3.
NOTE:
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.
The VANC may send the GA-RC REGISTER UPDATE DOWNLINK message when it wants to provide new
system information (e.g., VoLGA LAI, VANC TAI List) to the UE. If the VoLGA LAI is included and is not
the same as the stored LAI, the UE performs the CS domain location area update procedure via the VoLGA
control plane.
The VANC may also send the GA-RC REGISTER UPDATE DOWNLINK message to the UE to direct the
UE to rove-out or rove-in (see sub-clause 9.3.1).
4.
The VANC may deregister the UE by sending the GA-RC DEREGISTER message to the UE.
5.
The VANC may update its VANC-UE bindings on the HOSF(s), as described in clause 11; i.e., creating a
VANC-UE binding on one or more HOSFs, deleting a VANC-UE binding on one or more HOSFs, or both.
9.4 Keep-Alive and Re-Synchronization
9.4.1
Keep-Alive
The Keep-Alive procedure is used between the peer GA-RC entities to indicate that the UE is still registered on the
VANC. The periodic transmission of the GA-RC KEEP ALIVE message also allows the UE to determine that the
VANC is still available (i.e., based on TCP level acknowledgement). The frequency of the GA-RC KEEP ALIVE
message transmission is based on a timer sent by the VANC to the UE in the GA-RC REGISTER ACCEPT message 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:
9.4.2
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.
Re-Synchronization
9.4.2.1
UE-initiated Re-Synchronization
The UE-initiated Re-Synchronization procedure is used when the UE receives a TCP Reset after TCP connection
failure. If the UE received a VANC IP address or FQDN in the GA-RC REGISTER ACCEPT message (see sub-clause
9.1.3), then the UE shall make a single attempt to re-establish the TCP connection to that address; otherwise, the UE
shall make a single attempt to re-establish the TCP connection to the VANC address provided during VANC discovery
or redirection. If the TCP connection is successfully re-established, the UE sends the GA-RC 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.
The UE sends a message to the VANC.
2.
The UE receives a TCP reset indicating a TCP connection failure.
3.
The UE successfully attempts to re-establish a TCP connection to the assigned VANC.
4.
The UE sends the GA-RC SYNCHRONIZATION INFORMATION (GA-RC SYNC INFO) message to the
VANC to synchronize the UE state information.
5.
The VANC updates the UE registration status based on the received information.
If the TCP connection could not be re-established, the UE enters the GA-RC DEREGISTERED state locally.
The above procedure shall also be applied if the UE performs any other implementation-specific failure handling
procedure where the UE attempts to re-establish the TCP connection after failure detection.
9.4.2.2
VANC-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.
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).
2.
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.
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.
3.
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.
The MSC indicates to the VANC to release the user plane connection allocated to the UE, via the BSSMAP
Clear Command message.
2.
The VANC commands the UE to release the connection, using the GA-CSR RELEASE message.
3.
The VANC confirms the release to MSC using the BSSMAP Clear Complete message.
4.
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.
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.
2.
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.
3.
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.
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.
2.
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.
3.
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.
4.
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.
NOTE:
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.
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
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.
2.
The VANC extracts the NAS-PDU, encapsulates it within a DTAP message and sends the message to the
MSC.
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.
For network-initiated NAS signalling (including SMS), the MSC sends a DTAP message to the VANC via the
A interface.
2.
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
UE
VoLGA Stage 2 V1.7.0 (2010-06-14)
VANC
MSC
1. GA-CSR Connection Establishment
GA-CSRDEDICATED
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.
The GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1.
2.
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.
3.
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.
4.
The MSC may optionally authenticate the UE using standard GSM authentication procedures.
5.
The MSC may optionally initiate the ciphering configuration procedure described in sub-clause 9.6.
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.
7.
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.
8.
The MSC requests the VANC to assign call resources using the BSSMAP Assignment Request message.
9.
The VANC sends the GA-CSR ACTIVATE CHANNEL message to the UE including bearer path setup
information such as:
VoLGA Forum
Phase 1
38
-
channel mode
-
multi-rate codec configuration
-
UDP port & the IP address for the uplink RTP stream
-
voice sample size
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
2.
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.
3.
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.
4.
an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the
BSSMAP Complete Layer 3 Information message.
5.
6.
The MSC may optionally update the ciphering configuration in the UE, via the VANC, as described in subclause 9.6.
VoLGA Forum
Phase 1
41
VoLGA Stage 2 V1.7.0 (2010-06-14)
7.
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.
8.
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.
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.
2.
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.
3.
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.
VoLGA Forum
Phase 1
42
VoLGA Stage 2 V1.7.0 (2010-06-14)
4.
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.
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.
A call is established as described in sub-clauses 9.9 or 9.10.
2.
The VANC sends the GA-CSR CHANNEL MODE MODIFY message to the UE to modify parameters for the
established call.
3.
The UE responds with the GA-CSR CHANNEL MODE MODIFY 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.
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)
VoIP bearer active
for VoLGA?
PS HO?
DTM HO?
Source eNodeB initiates:
1
No
No
No
NACC
2
No
No
Yes
n/a
3
No
Yes
No
PS Handover
4
No
Yes
Yes
PS Handover
5
Yes
No
No
CS Handover
(VoIP bearer only)
PS bearers suspended
6
Yes
No
Yes
n/a
7
Yes
Yes
No
CS Handover
(VoIP bearer only)
8a
Yes
Yes
Yes
(and UE
supports DTM
& DTM HO)
CS+PS Handover
(All bearers)
8b
Yes
Yes
Yes
(but UE doesn’t
support DTM)
CS Handover
(VoIP bearer only)
8c
Yes
Yes
Yes
(and UE
supports DTM
but not DTM
HO)
CS Handover
(VoIP bearer only)
UE RAU after CS Handover
moves PS bearers to GERAN
NOTE 1: When a voice bearer is active and the target GERAN supports both PS handover and DTM (scenarios 8a,
8b and 8c), the UE’s DTM capabilities determine the behaviour of the handover. In the other scenarios
the handover behaviour is independent of the UE’s 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.
Source
E-UTRAN
UE
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
7. Prepare Handover Request
8. Handover Request/Ack
9. Prepare Handover Response
10. Establish circuit
11. Handover Command
12. PS to CS Response
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 message—without
modifying the message content—to 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)
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:
9.12.1.3
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].
Handover of VoLGA call to GERAN with DTM handover support
supported in the target GERAN.
VoLGA Forum
Phase 1
46
Source
E-UTRAN
UE
Source
MME
VoLGA Stage 2 V1.7.0 (2010-06-14)
Serving
VANC
HOSF
Serving
MSC
Target
MSC
Target
SGSN
Target
BSS
SGW
2. Decision for HO
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
9. UE tunes
to GERAN
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
5.
The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 9.12.1.2, steps
5-12.
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
48
Source
E-UTRAN
UE
Source
MME
HOSF
VoLGA Stage 2 V1.7.0 (2010-06-14)
Serving
VANC
Serving
MSC
Target
SGSN
Target
MSC
Target
RNS
SGW
2. Decision for HO
4. Bearer Splitting
5. SRVCC PS to CS handover preparation
6. PS relocation preparation
7. Handover Command
9. UE tunes
to UTRAN
11. SRVCC PS to CS handover completion
12. PS relocation completion
Figure 9.12.2.1-1: Handover of VoLGA call to UTRAN
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).
UTRAN RRC, the UE starts the "deregister on rove-out" timer (see sub-clause 9.2).
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).
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
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
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.
The CS GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1.
2.
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.
3.
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.
4.
5.
The MSC may optionally initiate the Cipher Mode Control procedure described in sub-clause 9.6.
6.
The MSC signals acceptance of the MO SMS request.
7.
The UE sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the
MSC.
8.
The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
UE.
9.
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.
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.
2.
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.
3.
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.
4.
an SCCP connection to the MSC. The VANC then forwards the paging response to the MSC using the
BSSMAP Complete Layer 3 Information message.
5.
6.
7.
The MSC sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the
UE.
8.
The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
MSC.
9.
The UE sends a response to the VANC in the CP-DATA message. The VANC relays this to the MSC.
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 subscriber’s 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
subscriber’s 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 UE’s location is queried from the MME as specified in TS 23.271 [8] (see below);
-
ATI: the UE’s 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 UE’s location is obtained based on interaction with the PCRF as specified in TS 23.203 [6];
-
The UE’s 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.
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.
The CS GA-CSR connection establishment procedure is performed as described in sub-clause 9.5.1.
2.
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.
3.
an SCCP connection to the MSC and forwards the NAS PDU (i.e., the Location Updating Request message) to
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.
The MSC signals acceptance of the location update request.
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.
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
10.5.2.2
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
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.
2.
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.
3.
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
NOTE:
57
VoLGA Stage 2 V1.7.0 (2010-06-14)
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
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
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.
The CS GA-RRC connection establishment procedure is performed as described in sub-clause 10.5.1.
2.
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.
3.
The VANC maps the received EPS information to a corresponding UTRAN SAI value. The VANC establishes
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.
4.
The MSC may optionally authenticate the UE using standard UTRAN authentication procedures.
5.
The MSC normally initiates the Security Mode Control procedure described in sub-clause 10.6.
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.
7.
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.
VoLGA Forum
Phase 1
8.
60
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
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
UE
VoLGA Stage 2 V1.7.0 (2010-06-14)
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
2.
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).
3.
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.
4.
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.
5.
VoLGA Forum
Phase 1
62
VoLGA Stage 2 V1.7.0 (2010-06-14)
6.
The MSC normally updates the security configuration in the UE, via the VANC, as described in sub-clause
10.6.
7.
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.
8.
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.
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
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
MSC
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.
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)
VoIP bearer active
for VoLGA?
PS HO?
DTM HO?
Source eNodeB initiates:
1
No
No
No
NACC
2
No
No
Yes
n/a
3
No
Yes
No
PS Handover
4
No
Yes
Yes
PS Handover
5
Yes
No
No
CS Handover
(VoIP bearer only)
6
Yes
No
Yes
n/a
7
Yes
Yes
No
CS Handover
(VoIP bearer only)
8a
Yes
Yes
Yes
(and UE
supports DTM
& DTM HO)
CS+PS Handover
(All bearers)
8b
Yes
Yes
Yes
(but UE doesn’t
support DTM)
CS Handover
(VoIP bearer only)
8c
Yes
Yes
Yes
(and UE
supports DTM
but not DTM
HO)
CS Handover
(VoIP bearer only)
UE RAU after CS Handover
moves PS bearers to GERAN
NOTE 1: When a voice bearer is active and the target GERAN supports both PS handover and DTM (scenarios 8a,
8b and 8c), the UE’s DTM capabilities determine the behaviour of the handover. In the other scenarios
the handover behaviour is independent of the UE’s 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
not supported in the target GERAN.
Source
E-UTRAN
UE
Source
MME
HOSF
Serving
VANC
Serving
MSC
Target
MSC
Target
BSS
2. Decision for HO
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
15. UE tunes to
GERAN
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
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 message—without
modifying the message content—to 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)
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.
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
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
5.
The SRVCC PS to CS handover preparation procedure is performed, as described in sub-clause 10.12.1.2,
steps 5-12.
18-24.
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
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
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)
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).
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).
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
Figure 10.12.2.2-1: Handover to UTRAN of VoLGA signalling channel without active voice bearer
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
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 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.
3.
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.
4.
5.
6.
The MSC signals acceptance of the MO SMS request.
7.
The UE sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the
MSC.
8.
The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
UE.
9.
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.
10. The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
MSC.
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
2.
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).
3.
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.
4.
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.
5.
6.
The MSC normally updates the security configuration in the UE, via the VANC, as described in sub-clause
10.6.
7.
The MSC sends the SMS message encapsulated in a CP-DATA message to the VANC, which relays it to the
UE.
8.
The UE sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
MSC.
9.
The UE sends a response to the VANC in the CP-DATA message. The VANC relays this to the MSC.
10. The MSC sends CP-DATA-ACK to acknowledge the message. The VANC relays the acknowledgement to the
UE.
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
10.17 Lawful interception
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.
Figure 10.18-1: Location area update
VoLGA Forum
Phase 1
74
VoLGA Stage 2 V1.7.0 (2010-06-14)
1.
2.
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.
3.
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.
4.
5.
6.
The MSC signals acceptance of the location update request.
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.
2.
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.
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.
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.
2.
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
VoLGA configuration mechanisms
12.1
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
VoLGA configuration properties
12.2.1
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 UE’s 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 UE’s 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
prefer CS Voice
with IMS PS Voice
or VoLGA Voice as
secondary/tertiary
(Section A.4)
(Section A.2)
(Section A.3)
[IMS] (A.4-1)
[IMS, CS] (A.2.1-1)
[CS, IMS] (A.3-1)
[VoLGA] (A.4-2)
[VoLGA, CS] (A.2.12)
[CS, VoLGA] (A.32)
[IMS, VoLGA] (A.43)
[IMS, VoLGA, CS]
(A.2.1-3)
[CS, IMS, VoLGA]
(A.3-3)
[VoLGA, IMS] (A.44)
[VoLGA, IMS, CS]
(A.2.1-4)
[CS, VoLGA, IMS]
(A.3-4)
(Section A.5)
[CS] (A.5-1)
VPV
[IMS, CS, VoLGA]
(A2.1-5)
[VoLGA, CS, IMS]
(A2.1-6)
VoLGA Forum
Phase 1
77
VoLGA Stage 2 V1.7.0 (2010-06-14)
A.2
IMS PS Voice or VoLGA Voice preferred
A.2.1
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
Supported
Not
supported
TAU performed
UE uses IMS
Voice
UE performs
combined TAU for
CSFB as in TS
23.272
Fail
UE checks for
voice centric or
data centric setting
Success
Data centric
UE uses CSFB
UE stays in current
RAT
Voice centric
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
Success
UE uses VoLGA
Fails
UE performs
combined TAU for
CSFB as in TS
23.272
Fail
UE checks for
voice centric or
Success
Data centric
UE uses CSFB
UE stays in current
RAT
Voice centric
UE reselects to
other RAT
Figure A.2.1-2: UE behavior for VPV set to [VoLGA, CS], non-combined EPS/IMSI attach.
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.
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.
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.
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
Success
Success
Data centric
UE uses CSFB
UE uses VoLGA
UE stays in current
RAT
Voice centric
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
Supported TAU performed
UE uses IMS
Voice
UE checks for
voice centric or
Voice centric
Data centric
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
Success
Data centric
UE uses VoLGA
UE stays in current
RAT
Voice centric
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 uses IMS
Voice
UE performs
VoLGA
registration
Fail
UE checks for
voice centric or
Success
Data centric
UE uses VoLGA
UE stays in current
RAT
Voice centric
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
Success
UE uses VoLGA
UE uses IMS
Voice
UE checks for
voice centric or
Voice centric
Data centric
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
UE
EPS
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
The UE connects to EPS and performs the VANC discovery procedure.
2.
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.
3.
The SeGW selects a AAA Server.
4.
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.
5.
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.
6.
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.
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.
8.
The SeGW forwards the EAP Request/AKA-Challenge message to the UE.
9.
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.
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).
2.
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.
3.
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).
4.
The SeGW forwards the EAP Request/AKA-Reauthentication message to the UE.
5.
The UE verifies that the Counter value is fresh and the MAC is correct.
6.
The UE sends the EAP Response/AKA-Reauthentication message with the same Counter value and a
calculated MAC to the SeGW.
7.
The SeGW forwards the response to the AAA Server.
8.
The AAA Server verifies that the Counter value is the same as it sent, and that the MAC is correct.
9.
The AAA Server sends an EAP Success message to the SeGW.
10. The SeGW forwards the EAP Success message to the UE.
VoLGA Forum
Phase 1
B.4
93
VoLGA Stage 2 V1.7.0 (2010-06-14)
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].
-
-
- Third cryptographic suite:
-
-
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].
-
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:
-
-
-
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].
-
- Third cryptographic suite:
-
Confidentiality: AES with 128-bit keys in CBC mode. The key length is set to 128 bits (also known as
-
Integrity: AES-XCBC-MAC-96 (also known as AUTH_AES_PRF_128) per RFC 3566 [27].
-
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 UE’s 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 VoLGA—is 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
C.3
VoLGA Stage 2 V1.7.0 (2010-06-14)
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 user’s 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
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
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
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.
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.
VoLGA Forum
Old
New
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
Phase 1
97
VoLGA Stage 2 V1.7.0 (2010-06-14)
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.
V09-HUA-006, V09-HUA-007, V09-HUA-008, V09-KIN-006.
V10-ALU-004, V10-DTG-009, V10-KIN-003, V10-KIN-004, V10-KIN-006,
V10-KIN-011.
V11-KIN-006, V11-KIN-011, V11-KIN-012, V11-KIN-013.
V12-KIN-004, V12-KIN-011, V12-KIN-012. Added abbreviations to sub-clause 3.2.
V13-KIN-001, V13-KIN-009, V13-KIN-024.
V13-DTG-009, V13-DTG-011, V13-KIN-028.
06-14-10 Removed working draft designation after completion of email approval.
VoLGA Forum
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.5.0
1.6.0
1.6.0
1.7.0WD1
1.7.0WD2
1.7.0
1.7.0WD1
1.7.0WD2

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

Transcription

Similar documents

- Volga Group

Bulletin 2016 (1) - Hillcrest Church of the Nazarene

9.4 Dakotaland Spring Newsletter.indd

Strategic Management of Projects MSc - The Bartlett

MSC Industrial Direct Transforming with Information Technology

Bulletin 2016 (2) - Hillcrest Church of the Nazarene

international conference places on the edge creating a sense of