Professional Documents
Culture Documents
Tracking Area Update Procedure LTE
Tracking Area Update Procedure LTE
Table of Contents
1
SCOPE
..............................................................................................................................
10
2
REFERENCES
....................................................................................................................
10
3
ABBREVIATIONS
..............................................................................................................
11
4
OVERVIEW
.......................................................................................................................
14
5
TEST
CONFIGURATION
.....................................................................................................
16
5.1
NETWORK
&
INTERFACE
CONFIGURATION
(OVERVIEW)
............................................................
16
..............................................................................................................................................
17
5.2
NETWORK
ELEMENTS
SOFTWARE
VERSION
.............................................................................
18
5.3
TEST
EQUIPMENT
.............................................................................................................
18
6
DETAILED
TEST
CASES
......................................................................................................
19
6.1
MANAGEMENT,
TRACING
AND
LOCATION
REPORT
TEST
CASES
...................................................
19
6.1.1
MANAGEMENT
PROCEDURES
OVER
SCTP
.................................................................................
19
6.1.1.1
S1
Setup
between
MME
and
eNodeB
in
a
single
PLMN
configuration
..........................
19
6.1.1.1.1
Successful
S1
Setup
....................................................................................................
19
6.1.1.1.2
Unsuccessful
S1
Setup
................................................................................................
21
6.1.1.2
S1
Setup
between
MME
and
eNodeB
in
a
multiple
PLMN
configuration
(MOCN
configuration)
................................................................................................................................
22
6.1.1.2.1
Successful
S1
Setup
....................................................................................................
22
6.1.1.2.2
Unsuccessful
S1
Setup
................................................................................................
23
6.1.1.3
S1
Configuration
Update
(MME
Initiated)
.....................................................................
24
6.1.1.3.1
Successful
S1
MME
Configuration
Update
.................................................................
24
6.1.1.3.2
Unsuccessful
S1
MME
Configuration
Update
.............................................................
25
6.1.1.4
S1
Configuration
Update
(eNodeB
Initiated)
.................................................................
26
6.1.1.4.1
Successful
S1
Configuration
Update
(eNodeB
Initiated)
............................................
26
6.1.1.4.2
Unsuccessful
S1
Configuration
Update
(eNodeB
Initiated)
........................................
27
6.1.1.5
S1
Reset
Procedures
......................................................................................................
27
6.1.1.5.1
S1
Reset
initiated
by
eNodeB
.....................................................................................
28
6.1.1.5.2
S1
Reset
initiated
by
MME
.........................................................................................
29
6.1.1.6
S1
Recovery
after
nodes
failure
.....................................................................................
30
6.1.1.6.1
S1
Recovery
after
eNodeB
restart
..............................................................................
30
6.1.1.6.2
S1
Recovery
after
MME
restart
..................................................................................
32
6.1.1.6.3
S1
Recovery
after
SGW
restart
...................................................................................
33
6.1.1.6.4
S1
Recovery
from
S1
failure
due
to
physical
connections
lost
...................................
35
6.1.2
TRACE
AND
LOCATION
REPORTING
PROCEDURES
........................................................................
37
6.1.2.1
Trace
Procedures
...........................................................................................................
37
6.1.2.1.1
Trace
Start
..................................................................................................................
37
6.1.2.1.1.1
Trace
Start
supporting
S1
interface
.........................................................................
37
6.1.2.1.1.2
Trace
Start
supporting
X2
interface
.........................................................................
39
6.1.2.1.2
Deactivate
Trace
.........................................................................................................
41
6.1.2.2
Location
Reporting
Procedures
.....................................................................................
43
6.1.2.2.1
Successful
location
reporting
for
a
direct
report
of
the
UE
location
..........................
43
6.1.2.2.2
Successful
location
reporting
for
serving
cell
change
.................................................
45
6.1.2.2.3
Successful
cancellation
of
location
reporting
for
serving
cell
change
........................
47
6.2
FUNCTIONAL
TEST
CASES
....................................................................................................
49
6.2.1
ATTACH/DETACH
..................................................................................................................
49
6.2.1.1
Successful
EPS
Attach
with
UE
unknown
in
MME
and
no
Ciphering
.............................
49
6.2.1.2
Successful
EPS
Attach
with
UE
unknown
in
MME
and
Ciphering
..................................
52
6.2.1.3
Successful
EPS
Attach
procedure
with
UE
known
in
MME
and
no
Ciphering
................
55
6.2.1.4
Successful
EPS
Attach
procedure
with
UE
known
in
MME
with
Ciphering
....................
57
6.2.1.5
Successful
EPS
Attach
procedure
with
IMSI
..................................................................
59
6.2.1.6
Unsuccessful
EPS
Attach
due
to
IMSI
unknown
on
HSS
................................................
61
6.2.1.7
Successful
EPS
Detach
initiated
by
UE
...........................................................................
63
6.2.1.8
Successful
EPS
Detach
initiated
by
UE
due
to
switch
off
...............................................
64
6.2.1.9
Successful
EPS
Detach
initiated
by
MME
.......................................................................
66
6.2.2
E-RAB
PROTOCOL
PROCEDURES
..............................................................................................
68
6.2.2.1
E-RAB
Setup
...................................................................................................................
68
6.2.2.1.1
Successful
E-RAB
establishment
for
...........................................................................
68
6.2.2.1.2
Successful
E-RAB
establishment
for
UE
Aggregate
Maximum
Bit
Rate
IE
is
included
69
6.2.2.1.3
Successful
E-RAB
establishment
for
multiple
E-RABs
.................................................
71
6.2.2.2
E-RAB
Modify
.................................................................................................................
72
6.2.2.2.1
Successful
E-RAB
modification
...................................................................................
72
6.2.2.2.2
Successful
E-RAB
modification
for
multiple
E-RABs
...................................................
74
6.2.2.2.3
Successful
and
Unsuccessful
E-RAB
modification
for
multiple
E-RABs
.......................
75
6.2.2.3
E-RAB
Release
................................................................................................................
76
6.2.2.3.1
E-RAB
Release
initiated
by
MME
................................................................................
76
6.2.2.3.2
E-RAB
Release
initiated
by
eNodeB
............................................................................
78
6.2.3
EPC
BEARERS
FUNCTIONAL
PROCEDURES
..................................................................................
80
6.2.3.1
Dedicated
bearer
Activation
..........................................................................................
80
6.2.3.1.1
Successful
Dedicated
Bearer
Activation
initiated
by
the
network
..............................
80
6.2.3.1.2
Successful
Dedicated
Bearer
Activation
initiated
by
the
UE
.......................................
82
6.2.3.1.3
Successful
Dedicated
Bearer
Activation
during
attach
...............................................
84
6.2.3.2
Bearer
Modification
.......................................................................................................
86
6.2.3.2.1
Bearer
Modification
initiated
by
the
EPC
...................................................................
86
6.2.3.2.1.1
PDN
GW
initiated
bearer
modification
with
QoS
Update
.......................................
86
6.2.3.2.1.2
HSS
initiated
Subscriber
QoS
Modification
..............................................................
87
6.2.3.2.1.3
Network
Initiated
Bearer
modification
without
Bearer
QoS
Update
......................
88
6.2.3.2.2
Bearer
Modification
initiated
by
the
UE
.....................................................................
90
6.2.3.2.2.1
UE
Requested
Bearer
Modification
accepted
by
the
network
................................
90
6.2.3.2.2.2
UE
Requested
Bearer
Modification
without
QoS
update
accepted
by
the
network92
6.2.3.3
Dedicated
Bearer
deactivation
......................................................................................
94
6.2.3.3.1
PDN
GW
initiated
Dedicated
Bearer
Deactivation
.....................................................
94
6.2.3.3.2
MME
initiated
Dedicated
Bearer
Deactivation
...........................................................
95
6.2.3.3.3
UE
initiated
Dedicated
Bearer
Deactivation
...............................................................
97
6.2.4
IDLE
MODE
AND
CONTEXT
MANAGEMENT
PROCEDURES
.............................................................
98
6.2.4.1
Active
to
Idle
mode
Transition
(Context
Release)
.........................................................
98
6.2.4.1.1
UE/eNodeB
Context
Release
due
to
User
Inactivity
with
a
single
bearer
established
98
6.2.4.1.2
UE/eNodeB
Context
Release
due
to
User
Inactivity
with
multiple
bearers
established
100
6.2.4.2
UE
Context
Release
due
to
radio
connection
with
UE
lost
..........................................
102
6.2.4.3
Tracking
Area
Update
procedures
...............................................................................
103
Index of Figures
Figure 1: S1 Interface Protocol Stack towards MME ....................................................... 14
Figure 2: S1 Interface Protocol Stack towards S-GW ...................................................... 15
Figure 3: Network Configuration for regular test cases.................................................... 16
Figure 4: Network Configuration for intra-RAT HO Test Cases ..................................... 17
Figure 5: Network Configuration for Inter-RAT HO Test Cases ..................................... 17
Figure 6: Setup Procedure Successful Operation.......................................................... 20
Figure 7: S1 Setup Procedure - Unsuccessful Operation ................................................. 21
Figure 8: S1 Setup Procedure: Successful Operation ..................................................... 22
Figure 9: S1 Setup Procedure: Unsuccessful Operation ................................................. 23
Figure 10: MME Configuration Update Procedure: Successful Operation .................... 24
Figure 11: MME Configuration Update: Unsuccessful Operation .................................. 25
Figure 12: ENB Configuration Update Procedure: Successful Operation...................... 26
Figure 13: ENB Configuration Update Procedure: Unsuccessful Operation ................. 27
Figure 14: Reset Procedure Initiated From the E-UTRAN Successful Operation ....... 28
Figure 15: Reset Procedure Initiated From the MME Successful Operation ............... 29
Figure 16: Reset Procedure Initiated From the E-UTRAN Successful Operation ....... 31
Figure 17: Reset Procedure Initiated From the MME Successful Operation ............... 33
Figure 18: UE Context Release Procedure Successful Operation ................................ 34
Figure 19: Setup Procedure Successful Operation........................................................ 36
Figure 20: Trace Start Procedure ..................................................................................... 38
Figure 21: Cell Traffic Trace Procedure - Successful Operation .................................... 38
Figure 22: Trace Failure Indication Procedure ................................................................ 38
Figure 23: Trace Start Procedure ..................................................................................... 39
Figure 24: Cell Traffic Trace Procedure - Successful Operation .................................... 40
Figure 25: Trace Failure Indication Procedure ................................................................ 40
Figure 26: Deactivate Trace ............................................................................................. 41
Figure 27: Trace Failure Indication Procedure ................................................................ 42
Figure 28: Location Reporting Control Procedure - Successful Operation ..................... 43
Figure 29: Location Report Failure Indication Procedure ............................................... 44
Figure 30: Location Reporting Control Procedure - Successful Operation ..................... 45
Figure 31: Location Report Procedure - Successful Operation ....................................... 46
Figure 32: Location Report Failure Indication ................................................................ 46
Figure 33: Location Reporting Control Procedure - Successful Operation ..................... 47
Figure 34: Location Report Failure Indication Procedure ............................................... 48
Figure 35: Successful EPS Attach with UE unknown in MME and No Ciphering ......... 51
Figure 36: Successful EPS Attach with MME unknown in MME and Ciphering ........... 54
Figure 37: Successful EPS Attach procedure with UE known in MME and No Ciphering
................................................................................................................................... 56
Figure 38: Successful EPS Attach with UE known in MME and Ciphering.................... 58
Figure 39: Successful EPS Attach with IMSI ................................................................... 60
Figure 40: Unsuccessful EPS Attach due to IMSI unknown on HSS............................... 62
Figure 41: Successful EPS detach initiated by UE ........................................................... 63
Figure 42: Successful EPS Detach initiated by UE due to switch off .............................. 65
Figure 43: Successful EPS Detach initiated by MME ...................................................... 67
Figure 81: Successful Service Request when UE is in Idle mode and has a mobile
originating 1xCS fallback request ........................................................................... 132
Figure 82: Successful Service Request when UE is in Active Mode and has a mobile
originating 1xCS fallback request ........................................................................... 134
Figure 83: Successful Initial UE message with Emergency Flag enabled...................... 135
Figure 84: GTP-U Echo mechanism ............................................................................... 136
Figure 85: GTP-U message "End of Marker" ................................................................. 138
Figure 86: Graceful Error Indication handling by eNodeB ............................................ 139
Figure 87: Graceful Error Indication handling by SGW ................................................ 141
Figure 88: Data Transfer on Default Bearer ................................................................... 143
Figure 89: Data Transfer on Dedicated Bearer with non-GBR Service and AM Mode . 145
Figure 90: Data Transfer on Dedicated Bearer with non-GBR service and UM Mode . 147
Figure 91: Data Transfer on Dedicated Bearer with GBR Service and AM Mode ........ 149
Figure 92: Data Transfer on Dedicated Bearer with GBR Service and UM Mode ........ 151
Figure 93: Successful X2 HO with single bearer............................................................ 154
Figure 94: Successful HO with single E-RAB via X2 with Ciphering........................... 156
Figure 95: Successful X2 HO with Multiple E-RABs .................................................... 159
Figure 96: Partially Successful HO via X2 interface with Multiple E-RABs ................ 161
Figure 97: Unsuccessful X2 HO Due to EPC Failure..................................................... 163
Figure 98: Successful S1 HO with Single E-RAB.......................................................... 165
Figure 99: Successful S1 HO with Multiple E-RABs .................................................... 167
Figure 100: Partially Successful S1 HO with Multiple E-RABs .................................... 170
Figure 101: Unsuccessful S1 HO due to fail on MME-Target eNodeB connectivity .... 172
Figure 102: Unsuccessful S1 HO due to non common Ciphering algorithm ................. 174
Figure 103: Unsuccessful S1 based HO due to no resources available at target eNodeB
................................................................................................................................. 176
Figure 104: Successful LTE to UTRAN HO for single E-RAB (Preparation Phase) ... 178
Figure 105: Successful LTE to UTRAN HO for single E-RAB (Execution Phase) ...... 179
Figure 106: Successful LTE to UTRAN HO for Multiple E-RABs (Preparation Phase)
................................................................................................................................. 181
Figure 107: Successful LTE to UTRAN HO with Multiple E-RABs (Execution Phase)
................................................................................................................................. 182
Figure 108: LTE to UTRAN HO Failure due to connectivity issues ............................. 183
Figure 109: LTE to UTRAN HO failure due to not resources at NodeB ....................... 185
Figure 110: LTE to UTRAN CS-Fallback: MO call, UE in Idle Mode ......................... 188
Figure 111: LTE to UTRAN CS-Fallback: MT Call, UE in Idle Mode (Preparation Phase)
................................................................................................................................. 191
Figure 112: LTE to UTRAN CS-Fallback (Execution Phase with PS HO supported) .. 192
Figure 113: LTE to UTRAN CS-Fallback (Execution Phase without PS HO Supported)
................................................................................................................................. 193
Figure 114: LTE to UTRAN CS-Fallback, MO Call, UE in Active Mode .................... 196
Figure 115: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Preparation
Phase) ...................................................................................................................... 199
Figure 116: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Execution
Phase) without PS HO Support ............................................................................... 200
Figure 117: LTE to UTRAN SRVCC, Inter RAT HO for VoIP Call............................. 203
Figure 118: LTE to UTRAN SRVCC, Inter RAT HO for Data Transfer with VoIP Call
................................................................................................................................. 205
Figure 119: Successful UTRAN to LTE Inter RAT HO for a single RAB (Preparation
Phase) ...................................................................................................................... 207
Figure 120: Successful UTRAN to LTE Inter RAT HO for a single RAB (Execution
Phase) ...................................................................................................................... 208
Figure 121: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Preparation
Phase) ...................................................................................................................... 210
Figure 122: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Execution
Phase) ...................................................................................................................... 211
Figure 123: UTRAN to LTE Inter RAT HO failure due to no resources at eNodeB ..... 213
1 Scope
This document defines a proposal for the test suite to be used for S1 Interface
Conformance testing. The goal is ensuring a graceful integration and interoperability
between eNodeB-MME and eNodeB-SGW from different vendors.
2
References
[1]
3GPP TS 36.413
[2]
3GPP TS 29.281
General
[3]
3GPP TS 36.300
[4]
3GPP TS 23.401
General
[5]
3GPP TS 36.331
[6]
3GPP TS 23.009
[7]
3GPP TS 24.301
[8]
3GPP TS 24.008
Mobile
3 Abbreviations
AS
Access Stratum
BC
Broadcast
BSC
BM-SC
BSS
BTS
CC
Call Control
CDMA
CSG
CN
Core Network
CS
Circuit Switched
CSFB
CS Fallback
DL
Downlink
DRX
Discontinuous Reception
ECGI
E-DCH
E-RAB
eNB
E-UTRAN NodeB
EP
Elementary Procedure
EPC
EPS
E-UTRAN
Evolved UTRAN
GBR
GERAN
GGSN
GPRS
GSM
GTP
GTP-U
GUMMEI
GUTI
GW
Gateway
HeNB
HFN
HRPD
HLR
HSDPA
HSS
HSUPA
HO
Handover
ID
Identifier
IE
Information Element
IETF
IMSI
IOT
Interoperability Test
IP
Internet Protocol
LAI
LTE
MBMS
MM
Mobility Management
MME
MMI
MO
Mobile Originated
MOC
MOCN
MS
Mobile Station
MSC
MT
Mobile Terminated
MTC
NAS
NNSF
NRT
Non-Real Time
O&M
PDN
PDCP
PDP
PDU
P-GW
PDN Gateway
PLMN
PS
Packet Switched
PSTN
PTM
Point To multipoint
P-TMSI
Packet TMSI
PTP
Point To Point
QoS
Quality of Service
RAB
RAC
RAI
RFCI
RIM
RLC
RNC
RRC
RT
Real Time
SAP
SAPI
SCTP
SGSN
S-GW
Serving Gateway
SMS
SN
Sequence Number
SRVCC
S-TMSI
TAI
TCP
TE
Terminal Equipment
TEID
TFT
TI
Transaction Identifier
TMSI
UDP
UE
User Equipment
UE-AMBR
UL
Uplink
UMTS
UP
User Plane
USIM
UTRAN
VLR
4 Overview
The purpose of this document is defining a test suite to guarantee the successful interoperability
of the S1 interface between the EPC and the eNB/E-UTRAN. The E-UTRAN is connected to the
MME (Mobility Management Entity) by means of the S1-MME for control-plane functionality and
to the Serving Gateway (S-GW) by means of the S1-U for bearer-plane functionality
The following main areas are covered in testing S1 interface:
Protocol
Transport Network Layer
o SCTP
o Multi-Homing
Context Management Procedures
Handover Signalling
Paging
NAS Transport
Management Procedures
UE Capability Info Indication
Trace Procedures
User Plane
GTP-U
Functional Oriented Test
Mobility Management
Session Management
General Failure and Recovery Tests
Data Transfer
Paging
Downlink Scheduling
S1-AP
S1-AP
SCTP
SCTP
IP
IP
L2
L2
L1
L1
HeNB
S1-MME
MME
GTP-U
GTP-U
UDP
UDP
IP
IP
L2
L2
L1
L1
HeNB
S1-U
S-GW
For all the diagrams and call flows included into this test plan, dotted lines imply that the
procedure is optional as per the applicable 3GPP specifications.
5 Test Configuration
This section lists the test equipment necessary to perform the test cases detailed in this
document, together with the network configurations that will be required to execute all the
test cases included in this document.
HSS
S1-MME
S6a
MME
PCRF
S11
Rx
Gx
S10
UE
Serving
Gateway
E-UTRAN
S1-U
S5
PDN
Gateway
SGi
Operator's IP
Services
(e.g. IMS, PSS etc.)
TE
HSS
S1-MME
S6a
MME
PCRF
S11
Rx
Gx
S10
Serving
Gateway
E-UTRAN
S5
PDN
Gateway
SGi
S1-U
UE
TE
Operator's IP
Services
(e.g. IMS, PSS etc.)
S1-MME
E-UTRAN
S1-U
IuCS
MSS
Gs
IuPS
UTRAN
SGSN
HSS
UE
S3
S1-MME
S6a
MME
TE
PCRF
S11
S10
S12
S4
Serving
Gateway
E-UTRAN
S1-U
S5
Rx
Gx
PDN
Gateway
SGi
Operator's IP
Services
(e.g. IMS, PSS etc.)
Software Version
eNodeB
MME
SGW
PGW
HSS
PCRF
HLR (3G)
SGSN (3G)
Item/Tool
Analyzer
Simulator
Mobiles
Others
Name/Model
References:
Test Objective:
Pre-Test Conditions:
MME is configured with the SCTP and S1 parameters (1 PLMN Id)
eNodeB is configured with the SCTP and S1 parameters (1 same PLMN Id)
Both of the nodes shall be configured with the SCTP path heartbeat timer
Verify IP connectivity between the two nodes
Test Procedure:
Power on the MME and eNodeB
Trigger eNodeB to initiate the S1 Setup
Expected Results:
Verify that:
SCTP connection is initiated by eNodeB by sending a S1 setup Request message,
including the TAC and the configured PLMN Identity included into the Broadcast
PLMNs IE,
MME responds with the S1 setup response message acknowledging the
connectivity and including the same PLMN Identity
S1 connectivity is successfully established between eNodeB and MME.
SCTP heartbeats messages are exchanged successfully between both of the
nodes according to the timers configured.
eNB
MME
S1 SETUP REQUEST
S1 SETUP RESPONSE
References:
Test Objective:
Pre-Test Conditions:
MME is configured with S1 parameters different than the one configures on
eNodeB (different TAC or different PLMN Id)
eNodeB is configured with S1 parameters different than the one configured on
MME (different TAC or different PLMN Id)
Verify IP connectivity between the two nodes
Test Procedure:
Power on the MME and eNodeB
Trigger eNodeB to initiate the S1 Setup
Expected Results:
Verify that:
SCTP connection is initiated by eNodeB by sending a S1 setup Request message,
including the TAC and the configured PLMN Identity included into the Broadcast
PLMNs IE,
MME responds with the S1 setup failure including the reason of the unsuccessful
establishment (e.g unknown TAC, unknown PLMN Id, etc)
No resource is hold by any network element after the unsuccessful S1
establishment
eNB
MME
S1 SETUP REQUEST
S1 SETUP FAILURE
Test Name:
References:
Test Objective:
Pre-Test Conditions:
MME is configured with the SCTP and S1 parameters
eNodeB is configured with the SCTP and S1 parameters
Both of the nodes shall be configured with the SCTP path heartbeat timer
Verify IP connectivity between the two nodes
Test Procedure:
Power on the MME and eNodeB
Trigger eNodeB to initiate the S1 Setup
Expected Results:
Verify that:
SCTP connection is initiated by eNodeB by sending a S1 setup Request message,
including the TAC and the configured PLMN Identitier included into the Broadcast
PLMNs IE,
MME responds with the S1 setup response message acknowledging the
connectivity and including the same PLMN Identitier
S1 connectivity is successfully established between eNodeB and MME.
SCTP heartbeats messages are exchanged successfully between both of the
nodes according to the timers configured.
eNB
MME
S1 SETUP REQUEST
S1 SETUP RESPONSE
References:
Test Objective:
Pre-Test Conditions:
MME is configured with S1 parameters different than the one configures on
eNodeB (different TAC Ids)
eNodeB is configured with S1 parameters different than the one configured on
MME (different TAC Ids)
Verify IP connectivity between the two nodes
Test Procedure:
Power on the MME and eNodeB
Trigger eNodeB to initiate the S1 Setup
Expected Results:
Verify that:
SCTP connection is initiated by eNodeB by sending a S1 setup Request message,
including the TAC and the configured PLMN Identitier included into the Broadcast
PLMNs IE,
MME responds with the S1 setup failure including the reason of the unsuccessful
establishment (e.g unknown TAC, unknown PLMN Id, etc)
No resource is hold by any network element after the unsuccessful S1
establishment
eNB
MME
S1 SETUP REQUEST
S1 SETUP FAILURE
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Verify IP connectivity between the two nodes
Test Procedure:
Trigger MME to initiate the S1 Setup Update by changing the configuration (eg
change the name of MME or changing the MME relative capacity)
Expected Results:
Verify that:
Validate that MME sends a S1-AP:MME Configuration Update including the new
parameters (e.g new MME name, or new MME relative capacity)
Validate that eNodeB is acknowledging the update by sending back a S1-AP MME
Configuration Update Acknowledge to MME
eNB
MME
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Make sure eNodeB is not configured to accept the PLMN-ID that MME will send
during the S1 MME Configuration Update.
Verify IP connectivity between the two nodes
Test Procedure:
Trigger MME to initiate the S1 Setup Update by changing the configuration
including a parameter not acceptable by eNodeB (eg unknown PLMN in enodeB)
Expected Results:
Verify that:
Validate that MME sends a S1-AP:MME Configuration Update including the new
parameters (e.g new PLMN-ID)
Validate that eNodeB is sending back a S1-APL MME configuration Update Failure
including the reason of the unsuccessful S1 update.
eNB
MME
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Verify IP connectivity between the two nodes
Test Procedure:
Trigger eNodeB to initiate the S1 Setup Update by changing the configuration (eg
supported TAC change in eNodeB)
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP:EnodeB Configuration Update including the
new parameters (e.g new TAC supported)
Validate that MME is acknowledging the update by sending back a S1-AP eNodeB
Configuration Update Acknowledge to eNodeB
Validate that new S1 parameters have been successfully negotiated at both of the
nodes.
eNB
MME
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Verify IP connectivity between the two nodes
Test Procedure:
Trigger eNodeB to initiate the S1 Setup Update by changing the configuration to
one which MME can not accept (e.g TAC change to unknown TAC in MME)
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP:EnodeB Configuration Update including the
new parameters (e.g new TAC supported)
Validate that MME is sending back a S1-SP enodeB configuration update failure
including the reason of the unsuccessful S1 update.
eNB
MME
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Verify IP connectivity between the two nodes
Test Procedure:
Trigger eNodeB to send a S1 Reset to MME
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Reset to MME
Validate that MME sends back a S1-AP Reset Acknowledge message
Validate that MME is releasing all allocated resources on S1 related to the UE and
removing the S1AP ID for all the UE associations.
eNB
MME
RESET
RESET ACKNOWLEDGE
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
Verify IP connectivity between the two nodes
Test Procedure:
Trigger MME to send a S1 Reset to eNodeB
Expected Results:
Verify that:
Validate that MME sends a S1-AP Reset to eNodeB
Validate that eNodeB sends back a S1-AP Reset Acknowledge message
Validate that eNodeB is releasing all allocated resources on S1 related to the UE
and removing the S1AP ID for all the UE associations.
MME
eNB
RESET
RESET ACKNOWLEDGE
Figure 15: Reset Procedure Initiated From the MME Successful Operation
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Trigger the eNodeB to restart as in case of a failure (e.g power cycling)
If no failure can be triggered, the pre-condition can be to execute a normal restart
as in test case 6.1.1.5.1).
Test Procedure:
Initiated the system restart from eNodeB (preferably by emulating is unexpected,
failure e.g power cycle-).
Expected Results:
Verify that:
If the failure does allow the eNodeB to send the S1 Reset:
o Verify that eNodeB sends S1-AP: S1 RESET to MME
o Verify that MME acknowledges by sending back a S1-AP: S1 RESET
acknowledgement to eNodeB
o Validate that all the resources have been released after the restart
Validate that the S1 recovers from the restart, eNodeB is sending a S1-AP S1
SETUP REQUEST
Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP
RESPONSE
Validate that UE can reestablish the context and resume the data transfer
successfully
eNB
MME
RESET
RESET ACKNOWLEDGE
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Trigger the MME to restart as in case of a failure (e.g power cycling)
If no failure can be triggered, the pre-condition can be to execute a normal restart
as in test case 6.1.1.5.2).
Test Procedure:
Initiated the system restart from MME (preferably by emulating is unexpected,
failure e.g power cycle-).
Expected Results:
Verify that:
If the failure does allow the MME to send the S1 Reset
o Verify that MME sends S1-AP: S1 RESET to eNodeB
o Verify that eNodeB acknowledges by sending back a S1-AP: S1 RESET
acknowledgement to MME
o Validate that all the resources have been released after the restart
Validate that the S1 recovers from the restart, eNodeB is sending a S1-AP S1
SETUP REQUEST
Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP
RESPONSE
Validate that UE can reestablish the context and resume the data transfer
successfully
MME
eNB
RESET
RESET ACKNOWLEDGE
Figure 17: Reset Procedure Initiated From the MME Successful Operation
6.1.1.6.3 S1 Recovery after SGW restart
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Initiated the system restart from S-GW (emulate is unexpected, failure)
Expected Results:
Verify that:
Verify that, when S-GW restarts, GTP-U may send a notification to the higher layer
and O&M entities
Verify that, upon S-GW reinitialization, the data can be resumed successfully. If no
same Tunnel Endpoints are honored at both of directions, GTP-U error indication
will be sent to the other end to indicate about the Tunnel ID mismatch.
This procedure may involve a UE Context release from MME (S-GW can notify
MME via S11) and UE context setup to re-activate the UE context successfully.
In Figure 18, UE context successfully established is not an actual procedure within
the 3GPP S1-AP specs. The message UE Context is successfully established is
meant to indicate that there are a collection of procedures executed in order to
resume UE operation.
eNB
MME
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Cause a failure on all the physical links carrying S1, for example by disconnecting
the cable or shutting down the interface
Reconnect the cable before eNodeB and MME triggers RESET failure (if
disconnection of the cable, eNodeB and MME will not trigger RESET)
Expected Results:
Verify that:
Message flow may depend on the vendor implementation
Expected behavior is eNodeB to start a S1 SETUP REQUEST to MME, MME to
acknowledge and UE context activation is being successfully re-established after
the physical link recovery
UE can resume the data transmission and no resource from previous call is hold
by any network element
eNB
MME
S1 SETUP REQUEST
S1 SETUP RESPONSE
References:
Test Objective:
Validate that MME is able to request the eNodeB to start a trace session
that supports S1 interface and minimum depth
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Send the trace control and configuration parameters from the MME. A trigger may
be manually initiated or received from HSS by using a ISDR message including
the trace control parameters
Validate that eNodeB is subsequently tracing the UE accordingly
Expected Results:
Verify that:
MME sends S1-AP Trace Start including a Trace Activation IE containing the
Interfaces To Trace IE with the S1-MME bit set and the Trace depth IE set to
minimum
Validate that eNodeB starts tracing the UE accordingly. The eNodeB will send to
MME a S1-AP Cell Traffic Trace including the requested tracing information
Validate that MME can manage the Cell Traffic message according to the protocol
and is capable of interpreting the tracing information reported by eNodeB.
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure
indication by including the reason of why the tracing control procedure was failed. In that
case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace
Start message originally sent by MME
MME
eNB
TRACE START
eNodeB
MME
MME
References:
Test Objective:
Validate that MME is able to request the eNodeB to start a trace session
that supports X2 interface and minimum depth
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Send the trace control and configuration parameters from the MME. A trigger may
be manually initiated or received from HSS by using a ISDR message including
the trace control parameters
Validate that eNodeB is subsequently tracing the UE accordingly
Expected Results:
Verify that:
MME sends S1-AP Trace Start including a Trace Activation IE containing the
Interfaces To Trace IE with the X2 bit set and the Trace depth IE set to minimum
Validate that eNodeB starts tracing the UE accordingly. The eNodeB will send to
MME a S1-AP Cell Traffic Trace including the requested tracing information
Validate that MME can manage the Cell Traffic message according to the protocol
and is capable of interpreting the tracing information reported by eNodeB.
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure
indication by including the reason of why the tracing control procedure was failed. In that
case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace
Start message originally sent by MME
MME
eNB
TRACE START
eNodeB
MME
MME
Test Name:
References:
Test Objective:
Validate that MME is able to request the eNodeB to stop the trace
session
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
eNodeB is currently tracing the S1 and/or X2 interfaces (MME previously sent a
S1-AP Trace Start message by enabling the interfaces to be monitored)
Verify IP connectivity between the two nodes
Test Procedure:
Send the deactivate trace control and configuration parameters from the MME. A
trigger may be manually initiated or received from HSS by using a ISDR message
including the trace control parameters
Validate that eNodeB is subsequently stopping the tracing for the UE accordingly
Expected Results:
Verify that:
MME sends S1-AP Deactivate Trace by including the same E-UTRAN Trace ID IE
that was notified by MME when the trace control was started (same value than the
one included into the S1-AP Start Trace message)
Validate that eNodeB stops tracing the UE accordingly
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure
indication by including the reason of why the tracing control procedure was failed. In that
case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace
Start message originally sent by MME
MME
eNB
DEACTIVATE TRACE
eNB
MME
References:
Test Objective:
Validate that MME is able to request the eNodeB to report where the UE
is currently located
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Initiate the location reporting for a direct location report for the UE
Validate that eNodeB is subsequently reporting the current location of the UE
Expected Results:
Verify that:
MME sends a S1-AP: Location Reporting Control by including a Request Type IE
with Event IE=Direct and Report Area IE=ECGI
eNodeB is subsequently sending a S1:AP Location Report message with a EUTRAN CGI IE indicating the cell where the UE is located. The Location Report
message also includes a TAI IE indicating the tracing area where the UE is located
and a Request Type IE including Event IE=Direct And Report Area IE=ECGI
Remark: If the location report control failed, the eNodeB shall send to MME a S1-AP Location
Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a
ongoing HO)
eNB
MME
eNB
MME
References:
Test Objective:
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Verify IP connectivity between the two nodes
Test Procedure:
Initiate the location reporting for a serving cell change for the UE
Move the UE to another cell
Expected Results:
Verify that:
MME sends a S1-AP: Location Reporting Control by including a Request Type IE
with Event IE=Change of Service Cell and Report Area IE=ECGI
Verify that when the UE moves to a new cell the eNodeB is sending a S1:AP
Location Report message with a E-UTRAN CGI IE indicating the cell where the UE
is located. The Location Report message also includes a TAI IE indicating the
tracing area where the UE is located and a Request Type IE including Event
IE=Change of Service cell And Report Area IE=ECGI
Remark: If the location report control failed, the eNodeB shall send to MME a S1-AP Location
Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a
ongoing HO)
eNB
MME
eNB
MME
LOCATION REPORT
eNB
MME
References:
Test Objective:
Note:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is at least one UE attached with active context and data transfer is ongoing
Currently the location reporting is active for a serving cell change.
Verify IP connectivity between the two nodes
Test Procedure:
Initiate the cancel of the location reporting for serving cell change for the UE
Move the UE to another cell
Expected Results:
Verify that:
During the cancellation of the location reporting, the MME sends a S1-AP:
Location Reporting Control by including a Request Type IE with Event IE=Stop
Change of Service Cell and Report Area IE=ECGI
Verify that when the UE moves to a new cell the eNodeB not sending any S1-AP
Location Report message.
Remark: If the location report control failed, the eNodeB shall send to MME a S1-AP Location
Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a
ongoing HO)
eNB
MME
eNB
MME
References:
Test Objective:
Validate the successful attach when UE is unknown to the MME and the
ciphering is disabled
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached and no context exists for the UE
Ciphering is disabled
GUTI is unknown in the MME
Test Procedure:
Trigger UE attach
Send Data in both of directions
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity
Request message, with Identity type IE=IMSI
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity
Response message with the IMSI IE included.
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA0
for Ciphering
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Deftault
EPS Bearer Context Accept message.
Validate that the Data can be transferred on both of directions with no Ciphering
being performed
References:
Test Objective:
Validate the successful attach when UE is unknown to the MME and the
ciphering is enabled
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached and no context exists for the UE
Ciphering is enabled
GUTI is unknown in the MME
Test Procedure:
Trigger UE attach
Send Data in both of directions
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity
Request message, with Identity type IE=IMSI
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity
Response message with the IMSI IE included.
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA1
or EEA2 for Ciphering as per the configuration
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Deftault
EPS Bearer Context Accept message.
Validate that the Data can be transferred on both of directions with Ciphering being
performed
Figure 36: Successful EPS Attach with MME unknown in MME and
Ciphering
References:
Test Objective:
Validate the successful attach when UE is known to the MME and the
ciphering is disabled
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached and no context exists for the UE
Ciphering is disabled
GUTI is known in the MME
Test Procedure:
Trigger UE attach
Send Data in both of directions
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA0
for Ciphering
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Deftault
EPS Bearer Context Accept message.
Validate that the Data can be transferred on both of directions with no Ciphering
being performed
Figure 37: Successful EPS Attach procedure with UE known in MME and
No Ciphering
References:
Test Objective:
Validate the successful attach when UE is known to the MME and the
ciphering is enabled
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached and no context exists for the UE
Ciphering is enabled
GUTI is known in the MME
Test Procedure:
Trigger UE attach
Send Data in both of directions
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA1
or EEA2 for Ciphering as per the configuration
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Deftault
EPS Bearer Context Accept message.
Validate that the Data can be transferred on both of directions with no Ciphering
being performed
Figure 38: Successful EPS Attach with UE known in MME and Ciphering
References:
Test Objective:
Validate the successful attach when UE is unknown to the MME and the
UE has no GUTI
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached
UE has no GUTI
Test Procedure:
Trigger UE attach
Send Data in both of directions
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to IMSI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA0,
EEA1 or EEA2 for Ciphering as per the configuration
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Default
EPS Bearer Context Accept message.
Validate that the Data can be transferred on both of directions with no Ciphering
being performed
References:
Test Objective:
Validate the graceful failed EPS Attach when IMSI is unknown on HSS
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is not attached and no GUTI is known on MME
IMSI is unknown on HSS
Test Procedure:
Trigger UE attach
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity
Request message, with Identity type IE=IMSI
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity
Response message with the IMSI IE included.
MME sends a S1-AP: Downlink NAS Transport encapsulating an Attach Reject
with the corresponding Cause IE included.
No resource is hold by any network element
References:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is attached
Test Procedure:
Trigger UE detach
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Uplink NAS Transport encapsulating a Detach
Request including the GUTI inside the EPS mobile Identity IE
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Detach
Accept
MME sends a S1-AP Downlink NAS Transport encapsulating a S1 UE Context
Release Command
eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport
encapsulating a S1 UE Context Release complete.
There is no resource hold by any network element after the detach is completed.
References:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is attached
Test Procedure:
Trigger UE detach by switching off the UE
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Uplink NAS Transport encapsulating a Detach
Request including a Detach Type IE with the switch off bit set
MME sends a S1-AP Downlink NAS Transport encapsulating a S1 UE Context
Release Command
eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport
encapsulating a S1 UE Context Release complete.
There is no resource hold by any network element after the detach is completed.
References:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
UE is attached and in active state
Test Procedure:
Trigger UE detach from the MME
Expected Results:
Verify that:
MME sends to eNodeB a S1-AP: Uplink NAS Transport encapsulating a Detach
Request
eNodeB sends to MME a S1-AP Downlink NAS Transport encapsulating a NAS
Detach Accept
MME sends to eNodeB a S1-AP Downlink NAS Transport encapsulating a S1 UE
Context Release Command
eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport
encapsulating a S1 UE Context Release complete.
There is no resource held by any network element after the detach is completed.
Remark 1:
If MME includes a Detach Type requesting UE to make a new attach inside the initial Detach
Request, the UE should start a new attach as soon as the current context is completed
released.
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is no existing E-RAB on UE
Test Procedure:
Initiate a procedure that requires E-RAB establishment (e.g service request)
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB
to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE)
Validate that eNodeB is acknowledging the successful establishment by sending a
S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the
successfully established E-RAB, including the same E-RAB ID IE originally
included into the request.
Validate that the UE can send data by using the established E-RAB
Remarks 1:
If the E-RAB is not successfully established (e.g due to no resources available on eNodeB)
the eNodeB will answer with a S1-AP: E-RAB SETUP Response including a E-RAB Failed to
Setup List IE containing the ID for the E-RAB that was unable to be established.
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is an existing E-RAB using all of the Aggregate Maximum Bit Rate for the
UE as per UE Context (default bearer)
Test Procedure:
Configure MME to include the UE Aggregate Maixmum Bit Rate IE during the
establishment of the new E-RAB
Initiate a procedure that requires an additional E-RAB establishment (e.g creation
of a dedicated bearer).
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB
to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) and the UE
Aggregate Maximum Bit Rate IE
Validate that eNodeB is acknowledging the successful establishment by sending a
S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the
successfully established E-RAB, including the same E-RAB ID IE originally
included into the request.
Validate that the Aggregate Maximum Bit Rate is successfully changed at both of
the sides to support the new E-RAB. Validate that the Data Radio Bearer is
established for the requested E-RAB with the appropriated resources based on the
E-RAB Level QoS Parameter IE
Validate that the UE can send data over all of the established E-RABs.
Remarks 1:
If the E-RAB is desired to be pre-empted, the Priority Level shall be set to be low priority and
the Pre-emption Vulnerability has to be Pre-emptable. The no pre-empting E-RAB will then
present the Priority Level set to high and the Pre-emption Capability has to be may trigger
pre-emption. In this case, if no enough resources are available the high priority E-RAB will be
established and the pre-emptable E-RAB will be released out.
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is no existing E-RAB on UE
Test Procedure:
Initiate a procedure that requires multiple E-RAB establishment (e.g service
request)
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB
to be Setup List IE containing multiple E-RAB to be setup (multiple E-RAB ID IEs)
Validate that eNodeB is acknowledging the successful establishment by sending a
S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the
successfully established E-RABs, including the same E-RAB ID IEs originally
included into the request for each successfully established E-RAB
Validate that the UE can send data by using ALL the successfully established ERABs
Remarks 1:
If some of the E-RABs are successfully established but some of them are not, the S1-AP ERAB Setup Response message sent by eNodeB to MME will include E-RAB Setup List IE
containing all the successfully established E-RABs and will include a E-RAB Failed to Setup
List IE containing all the IDs of each of the E-RAB which was unable to be established
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There is an existing E-RAB on UE
Test Procedure:
Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to
MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ
by including new TFT Filters/QoS Parameters)
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB
to be Modified List IE containing one E-RAB to Be Modified Item (with the
corresponding E-RAB ID IE)
Validate that eNodeB is acknowledging the modification by sending back a S1-AP
E-RAB Modify Response message with the same E-RAB Modify List IE containing
the same E-RAB Modify Item IEs (with same E-RAB ID IE).
Validate that the new parameters (QoS and/or TFT Filters) are properly updated at
both of the sides and that the data is transferred accordingly.
Remarks 1:
The MME can include the UE Aggregate Maximum Bit Rate IE into the S1-AP: E-RAB Modify
Request. In that case, the data radio bearer shall be modified for the requested E-RAB with
the appropriate resources based on the E-RAB level QoS Parameter IE, reflecting the change
in the aggregate maximum bit rate
Remarks 2:
The MME can attempt to modify the existing E-RAB while pre-empting another E-RAB on the
UE. For this purpose, the MME will include into the S1-AP: E-RAB Modify Request message
the E-RAB to be Modified List IE containing one E-RAB to Be Modified Item IE with the
corresponding E-RAB ID, the E-RAB Priority Level set to 1 and the Pre-emption Capability
set to may trigger pre-emption. In this case, if no enough resources are available on enodeB
the others E-RAB will be released by using a S1-AP E-RAB Release procedure for the low
priority E-RABs.
Remarks 3:
If the E-RAB is not successfully modified the eNodeB will send a S1-AP E-RAB Modify
Response including a E-RAB Failed to Modify List IE with the same ID of the E-RAB included
into the request. In this case, the former QoS/TFT parameters of the bearer will be honored
by all the nodes.
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There are multiple E-RABs existing on UE
Test Procedure:
Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to
MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ
by including new TFT Filters/QoS Parameters) for multiple E-RABs
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB
to be Modified List IE containing all E-RAB to Be Modified Item (with the
corresponding E-RAB ID IEs)
Validate that eNodeB is acknowledging the modification by sending back a S1-AP
E-RAB Modify Response message with the same E-RAB Modify List IE containing
the same E-RAB Modify Item IEs (with same E-RAB ID IEs).
Validate that the new parameters (QoS and/or TFT Filters) are properly updated at
both of the sides and that the data is transferred accordingly on all the bearers.
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There are multiple E-RABs existing on UE
Test Procedure:
Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to
MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ
by including new TFT Filters/QoS Parameters) for multiple E-RABs
Expected Results:
Verify that:
Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB
to be Modified List IE containing all E-RAB to Be Modified Item (with the
corresponding E-RAB ID IEs)
Validate that eNodeB is sending back a S1-AP E-RAB Modify Response message
with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs
(with same E-RAB ID IEs) for all the successfully modified E-RABs.
Validate that eNodeB is also including into the S1-AP E-RAB Modify Response a
E-RAB Failed to Modify List IE containing the IDs for each of the E-RABs which
was unable to be modified.
Validate that the new parameters (QoS and/or TFT Filters) are properly updated at
both of the sides only on the successfully modified E-RABs, whereas the former
values are kept for the unsuccessfully modified E-RABs. Validate that the data is
transferred accordingly on all the bearers.
Figure 49: Successful and Unsuccessful E-RAB Modification for Multiple ERABs
6.2.2.3 E-RAB Release
6.2.2.3.1 E-RAB Release initiated by MME
Test Name:
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There are at least two E-RABs existing on UE
Test Procedure:
Initiate a procedure that requires an existing E-RAB to be released (e.g eliminate
all the TFT Filters from a dedicated bearer)
Expected Results:
Verify that:
Validate that MME is sending S1-AP: E-RAB Release command including the ERAB to be Released List IE containing the ID of the E-RABs to be released
Validate that eNodeB sends back a S1-AP: E-RAB Release Response including
the E-RAB Release List IE containing the same ID of the released E-RAB
Validate that all the resources have been modified on all the network elements as
expected.
Remark 1:
The Optional IE UE Aggregate Maximum Bit Rate may be present.
References:
Test Objective:
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
There are at least two E-RABs existing on UE
Test Procedure:
Initiate a procedure that requires an existing E-RAB to be released (e.g eliminate
all the TFT Filters from a dedicated bearer)
Expected Results:
Verify that:
Validate that eNodeB is sending a S1-AP: E-RAB Release Indication including the
E-RAB Released List IE containing the ID of the E-RAB to be released
Validate that MME is successfully acknowledging and that the bearer is also
eliminated over S11 interface
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Trigger PGW to perform a dedicated bearer activation
Expected Results:
Verify that:
Validate that MME is receiving the EGTP_CREATE_BEARER_REQ from SGW
over S11 interface, and is subsequently sending a S1-AP: E-RAB Setup Request
encapsulating a NAS Activate Dedicated EPS Bearer Context Request message.
This message shall include the EPS Bearer identity IE, the EPS QoS and Traffic
Flow Template IE as originally included into the EGTP message coming from
SGW
Validate that eNodeB sends back a S1-AP: E-RAB SETUP Response.
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS
Bearer identity and the Procedure transaction identity IE.
Vadliate that the a new dedicated bearer has been established on every node and
that the data transmission in DL/UL honors the QoS/TFT Filter rules on that
bearer.
Remark 1:
If the dedicated bearer establishment is rejected by the UE/enodeB, the enodeB will send a
S1-AP: Uplink NAS Transport including a NAS Activate dedicated EPS bearer Context Reject,
including the EPS Bearer ID as well as the ESM Cause IE with the corresponding cause (E.g
insufficient resources)
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Trigger UE to perform a dedicated bearer activation (e.g making a MO call with
different QCI)
Expected Results:
Verify that:
Validate that eNodeB is initially sending a S1-AP: Uplink NAS Transport
encapsulating a NAS Bearer Resource Allocation Request message with the
TFT/QoS information sent by the UE and including a EPS Bearer Identity IE with
no EPS bearer identity assigned
Validate that MME is subsequently sending a S1-AP: E-RAB Setup Request
encapsulating a NAS Activate Dedicated EPS Bearer Context Request message.
This message shall include the EPS Bearer identity IE, the EPS QoS and Traffic
Flow Template IE as originally included into the EGTP message coming from
SGW
Validate that eNodeB sends back a S1-AP: E-RAB SETUP Response.
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS
Bearer identity and the Procedure transaction identity IE.
Validate that a new dedicated bearer has been established on every node and that
the data transmission in DL/UL honors the QoS/TFT Filter rules on that bearer.
Remark 1:
If the dedicated bearer establishment is rejected by the network, the MME will send a S1-AP:
Uplink NAS Transport including a NAS Bearer Resource Modification Reject with ESM Cause
IE with the corresponding cause (E.g insufficient resources)
References:
Test Objective:
Pre-Test Conditions:
UE is not attached
Network is configured to trigger a dedicated bearer activation during the UE attach
Test Procedure:
Trigger UE to attach
Expected Results:
Verify that:
enodeB sends a S1-AP Initial UE message encapsulating a NAS Attach Request
to MME
MME sends back a S1-AP Initial Context Setup Request including both NAS
Attach Accept and NAS Activate Default EPS Bearer Context Request
MME sends a S1-AP: E-RAB set request encapsulating a NAS Activate Dedicated
EPS Bearer Context Request to eNodeB. The NAS message will include the EPS
Bearer identity IE of the new dedicated bearer, the EPS QoS IE and the
corresponding Traffic Flow Template IE
Validate that eNodeB sends back a S1-AP: Initial Context Setup Response.
Validate that eNodeB sends to MME a S1-AP: Uplink NAS Transport
encapsulating a NAS Attach Complete and NAS Activate Default EPS Bearer
Context Accept message.
Validate that eNodeB sends to MME a S1-aP: E-RAB Setup Response
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS
Bearer identity and the Procedure transaction identity IE.
Validate that both default and dedicated bearers have been established on every
node and that the data transmission in DL/UL honors the QoS/TFT Filter rules on
that bearer.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Trigger PGW to modify the QoS Parameters for a E-RAB (e.g MBR GBR or
AMBR)
Expected Results:
Verify that:
Validate that MME is receiving the EGTP_UPDATE_BEARER_REQ from SGW
over S11 interface, and is subsequently sending a S1-AP: E-RAB Modify Request
including the NAS session management request with the E-RAB to be Modified
List IE included.
Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the ERAB Modify List IE containing the same E-RAB ID acknowledging the modification
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Session Management Response message.
Vadliate that the new QoS/TFT Filter is updated on every node accordingly and
data traffic is now following the new rules.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Trigger HSS to modify the subscribed QoS parameters in the middle of the session
(e.g QCI, ARP, QoS)
Expected Results:
Verify that:
Validate that MME is receiving the Insert Subscriber Data Request from HSS with
the new QoS information, and is successfully acknowledging it back
Validate that MME is subsequently sending a S1-AP: E-RAB Modify Request
including the NAS session management request with the E-RAB to be Modified
List IE included.
Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the ERAB Modify List IE containing the same E-RAB ID acknowledging the modification
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Session Management Response message.
Vadliate that the new QoS is updated on every node accordingly and data traffic is
now following the new rules.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Trigger network to modify the bearer without QoS Update (e.g adding new TFT
filters on PGW to the bearer, or making HSS to modify the APN-AMBR)
Expected Results:
Verify that:
Validate that MME is sending a S1-AP: E-RAB ModifyRequest including the NAS
session management request with the E-RAB to be Modified List IE included. The
Modification could include the Traffic Flow Template IE (if new TFT filter is added),
the APN-AMBR IE (if new AMBR is included).
Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the ERAB Modify List IE containing the same E-RAB ID acknowledging the modification
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Session Management Response message.
Validate that the new TFT/AMBR is updated on every node accordingly and data
traffic is now following the new rules.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Initiate QoS parameter modification from the UE (e.g MBR, GBR, etc)
Expected Results:
Verify that:
Validate that eNodeB is mapping the EPS Bearer QoS to the Radio Bearer QoS
and signals a RRC Connection Reconfiguration to the UE
Validate that eNodeB is sending S1-AP: Uplink NAS Transport encapsulating a
NAS Bearer Resource Modification Request to the MME
Validate that MME is sending back a E-RAB Modify Request encapsulating a NAS
Session Management Request containing the E-RAB to be Modified List IE set to
the corresponding E-RAB ID
Validate that eNodeB sends to MME S1-APL E-RAB Modify Response message
acknowledging it back.
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Session Management Response message.
Validate that the new TFT/AMBR is updated on every node accordingly and data
traffic is now following the new rules.
Remark 1:
If the modification request is not accepted by the network, then the MME will answer the S!AP NAS Bearer Resource modification Request with a S1-AP Downlink NAS Transport
encapsulating a NAS Bearer Resource Modification Reject message including the
corresponding Cause ID
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least one E-RAB on UE
Test Procedure:
Initiate TFT parameter modification from the UE
Expected Results:
Verify that:
Validate that eNodeB is mapping the EPS Bearer QoS to the Radio Bearer QoS
and signals a RRC Connection Reconfiguration to the UE
Validate that eNodeB is sending S1-AP: Uplink NAS Transport encapsulating a
NAS Bearer Resource Modification Request to the MME. This message should
include the Traffic Flow Template IE with the new information
Validate that MME is sending back a E-RAB Modify Request encapsulating a NAS
Session Management Request containing the E-RAB to be Modified List IE set to
the corresponding E-RAB ID and same Traffic Flow Template IE
Validate that eNodeB sends to MME S1-APL E-RAB Modify Response message
acknowledging it back.
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Session Management Response message.
Validate that the new TFT/AMBR is updated on every node accordingly and data
traffic is now following the new rules.
Remark 1:
If the modification request is not accepted by the network, then the MME will answer the S1AP NAS Bearer Resource modification Request with a S1-AP Downlink NAS Transport
encapsulating a NAS Bearer Resource Modification Reject message including the
corresponding Cause ID
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least two E-RABs on UE
Test Procedure:
Initiate bearer deactivation from the PDN GW
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a
NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released
List IE
Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the
same E-RAB Release List IE
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Deactivate EPS Bearer Context Accept.
Validate that the dedicated bearer has been released on every node and that all
the traffic is now being routed through one of the rest of the bearers (e.g default).
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least two E-RABs on UE
Test Procedure:
Initiate bearer deactivation from the MME
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a
NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released
List IE
Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the
same E-RAB Release List IE
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Deactivate EPS Bearer Context Accept.
Validate that the dedicated bearer has been released on every node and that all
the traffic is now being routed through one of the remaining bearers (e.g default).
References:
Test Objective:
Pre-Test Conditions:
UE is attached
There are at least two E-RABs on UE
Test Procedure:
Initiate bearer deactivation from the UE
Expected Results:
Verify that:
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Bearer Resource Modification Request including a ESM Cause IE set to
Regular deactivation
Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a
NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released
List IE
Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the
same E-RAB Release List IE
Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating
the NAS Deactivate EPS Bearer Context Accept.
Validate that the dedicated bearer has been released on every node and that all
the traffic is now being routed through one of the rest of the bearers (e.g default).
References:
Test Objective:
Validate the successful transition from Active to Idle mode when the UE
has only 1 bearer established
Pre-Test Conditions:
UE is attached
UE is in active mode
UE has only 1 E-RAB established
Test Procedure:
Stop data transmission and wait until Idle mode timer gets expired
Expected Results:
Verify that:
Validate that eNodeB is sending a S1-AP UE context Release Request including a
Cause IE set to User Inactivity
The MME will then send a S11 EGTP_Release_Access_Bearer_Request
message including the information of the S1 bearer to be released between
eNodeB and SGW.
SGW
will
acknowledge
it
back
by
sending
a
S11
EGTP_Release_Access_Bearer_Response message
Since there is only one bearer, validate that MME is sending a S1 AP UE Context
Release message. This message is acknowledged by the eNodeB.
Validate that all the bearers have been released but the UE context is still alive on
MME
References:
Test Objective:
Validate the successful transition from Active to Idle mode when the UE
has multiple bearers established
Pre-Test Conditions:
UE is attached
UE is in active mode
UE has at least two E-RABs established
Test Procedure:
Stop data transmission through all the bearers and wait until Idle mode timer gets
expired
Expected Results:
Verify that:
Validate that eNodeB is sending a S1-AP UE context Release Request including a
Cause IE set to User Inactivity
The MME will then send a S11 EGTP_Release_Access_Bearer_Request
message including the information of all the S1 bearers to be released between
eNodeB and SGW.
SGW
will
acknowledge
it
back
by
sending
a
S11
EGTP_Release_Access_Bearer_Response message
Validate that MME sends a S1-AP: UE Context Release Command to the eNodeB
Validate that eNodeB is sending back a S1-AP UE Context Release Complete
Validate that all the bearers have been released but the UE context is still alive on
MME
Note: It may happen that multiple bearers are established but only a subset of these bearers
become Idle. In this case, the MME would send a S1-AP UE Context Release Command by
including only the subset of bearers that are inactive and the eNodeB would respond with S1AP UE Context Release Complete. When required at UE or network side, a S1-AP Service
Request will be sent to re-activate the subset of bearers when a packet matching that packet
filter/classifier needs to be transmitted.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is in active mode and a context exists for the UE on every node
Test Procedure:
Make the UE to go out of radio coverage (e.g moving the UE or using attenuators)
Expected Results:
Verify that:
Validate that eNodeB is sending a S1-AP UE context Release Request including a
Cause IE set to Radio Connection with UE lost
Validate that MME sends a S1-AP: UE Context Release Command encapsulating
a NAS Deactivate EPS Bearer Context Request including the E-RAB to be
Released List IE
Validate that eNodeB is sending S1-AP: UE Context Release Complete
Validate that the UE context is successfully released and there is no longer any
resource hold by any network element for that UE
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is in Idle Mode
A neighbor cell is configured with a TA which is not in UEs TA list
Test Procedure:
Make the UE to move to the neighboring cell
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Normal
Tracking Area Update
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete,
Finally, validate that MME is sending a S1-AP UE Context Release Command is
eNodeB is acknowledging it back by sending back a S1-AP UE Context Release
Complete.
Validate that the UE context is successfully kept on both MME and eNodeB and
UE remains in Idle
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is attached for EPS services only and one or several services are established
with data transfer ongoing
A neighbor cell is configured with a TA which is not in the UEs TA list
Test Procedure:
Move the UE to the neighboring cell and resume traffic
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Normal
Tracking Area Update and EPS bearer context status IE indicating the correct
EPS contexts as active on the UE
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept including a EPS bearer context status IE
indicating the correct the EPS contexts as active in the MME
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete.
Validate that, MME is subsequently performing a Initial Context Setup and E-RAB
Setup (if any dedicated bearers)
Validate that the default and dedicated bearers (if any) are successfully
established. Validate that services are re-established and data transfer can be
resumed.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE supports CS fallback
UE is attached for both EPS and non-EPS services
A neighbor cell is configured with a TA which is not in UEs TA list
Test Procedure:
Make the UE to move to the neighboring cell
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Combined
TA/LA updating
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete,
Finally, validate that MME is sending a S1-AP UE Context Release Command is
eNodeB is acknowledging it back by sending back a S1-AP UE Context Release
Complete.
Validate that the UE context is successfully kept on both MME and eNodeB and
UE remains in Idle
6.2.4.3.4 Combined Tracking and Location Area Update with IMSI attach
Test Name:
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE supports CS fallback
UE is attached for EPS services only
Test Procedure:
Enable CS/PS mode 1 or CS/PS mode 2 on the UE
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Combined
TA/LA updating with IMSI attach
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete,
Finally, validate that MME is sending a S1-AP UE Context Release Command is
eNodeB is acknowledging it back by sending back a S1-AP UE Context Release
Complete.
Validate that the UE context is successfully kept on both MME and eNodeB and
UE remains in Idle
Figure 69: Combined Tracking and Location Area Update with IMSI attach
References:
Test Objective:
Validate the successful combined tracking and locating area update with
bearer establishment requested. This may happen when the UE moves
to a neighbor cell and data traffic is resumed through one of the bearers.
Pre-Test Conditions:
UE is attached
UE is attached for both EPS and non-EPS services only and one or several
services are established with data transfer ongoing
UE supports CS fallback
A neighbor cell is configured with a TA which is not in the UEs TA list
Test Procedure:
Stop traffic to put the UE in Idle state
Move the UE to the neighboring cell and resume traffic
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Combined
TA/LA updating and EPS bearer context status IE indicating the correct EPS
contexts as active on the UE
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept including a EPS bearer context status IE
indicating the correct the EPS contexts as active in the MME
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete.
Validate that, MME is subsequently performing a Initial Context Setup and E-RAB
Setup (if any dedicated bearers)
Validate that the default and dedicated bearers (if any) are successfully
established. Validate that services are re-established and data transfer can be
resumed.
Figure 70: Combined Tracking and Location Area Update with bearer
establishment requested
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is in Idle Mode
Test Procedure:
The periodic tracking area updating procedure is triggered on the UE when the
timer T3412 expires
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Periodic
Updating
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS
Authentication Request to eNodeB
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Authentication Response to MME
Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Security Mode Command
Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept
Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a
NAS Tracking Area Update Complete,
Finally, validate that MME is sending a S1-AP UE Context Release Command is
eNodeB is acknowledging it back by sending back a S1-AP UE Context Release
Complete.
Validate that the UE context is successfully kept on both MME and eNodeB and
UE remains in Idle
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is attached and one or several services are established with data transfer
ongoing
A neighboring cell is configured with a TA which is not in UEs TA list
Test Procedure:
Stop traffic to put the UE in Idle state
Delete the EPS bearer context on the MME
Move the UE to the neighboring cell and resume traffic
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request, including a EPS Update Type IE set to Bearer
Establishment Requested. The message will have also a EPS Update type IE with
the active flag set.
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating NAS
Tracking Area Update Reject. The EMM Cause IE including a No EPS bearer
context activated
Validate that MME sends a S1-AP UE Context Release Command
Validate that eNodeB sends a S1-AP UE Context Release Complete
Figure 72: Tracking Area Update rejected due to "No EPS Bearer context
activated"
References:
Test Objective:
Validate the tracking area update procedure rejected when the network
has been implicitly detached the UE
Pre-Test Conditions:
UE is attached
UE is in idle state
A neighboring cell is configured with a TA which is not in UEs TA list
Test Procedure:
Remove the UE from the cell radio coverage in order to have the periodic tracking
area update timer (T3412) expires and also the mobile reachable timer expired.
The network will then implicitly detach the UE. Validate the procedure on MME
Move the UE back under the radio coverage
Expected Results:
Verify that:
Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS
Tracking Area Update Request,
Validate that MME sends S1-AP: Downlink NAS Transport encapsulating NAS
Tracking Area Update Reject. The EMM Cause IE including a implicitly detached
Validate that MME sends a S1-AP UE Context Release Command
Validate that eNodeB sends a S1-AP UE Context Release Complete
Validate that the UE performs a new attach procedure and is successfully
completed
6.2.4.4 Paging
6.2.4.4.1 Paging with Paging DRX IE
Test Name:
References:
Test Objective:
Validate the MME can sends the Paging message including the Paging
DRX IE in case the UE supports Paging DRX.
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
The UE has included the UE specific parameter in the DRX Parameter IE in the
Attach Request message to indicate it supports Paging DRX
The UE is in Idle Mode
Test Procedure:
Send DL Data to the UE while UE is in Idle Mode
Expected Results:
Verify that:
Validate that MME is sending S1-AP: Paging including the Paging DRX IE
Validate that UE is subsequently re-entering Active Mode. eNodeB is sending S1AP: Initial UE Message encapsulating a Service Request from the UE
Validate that the UE context is established successfully and that the UE is able to
receive the DL data, as well as send UL data.
References:
Test Objective:
Validate the MME can sends the Paging message without Paging DRX
IE in case the UE does not support Paging DRX.
Pre-Test Conditions:
Initial S1 setup has been successfully established between eNodeB and MME
The UE did not include the UE specific parameter in the DRX Parameter IE in the
Attach Request message to indicate it does NOT support Paging DRX
The UE is in Idle Mode
Test Procedure:
Send DL Data to the UE while UE is in Idle Mode
Expected Results:
Verify that:
Validate that MME is sending S1-AP: Paging NOT including any Paging DRX IE
Validate that UE is subsequently re-entering Active Mode. eNodeB is sending S1AP: Initial UE Message encapsulating a Service Request from the UE
Validate that the UE context is established successfully and that the UE is able to
receive the DL data, as well as send UL data.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is in idle state
UE context on the network contains only 1 bearer.
Test Procedure:
Send data in DL direction so that paging is started.
Expected Results:
Verify that:
Validate that MME sends a S1-AP Paging including a CN Domain IE set to PS
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Service Request
Validate that MME sends S1-AP: Initial Context setup Request including the ERAB to be setup list IE containing the E-RAB which the eNodeB should establish
in order to build the new E-RAB configuration
Validate that eNodeB sends a S1-AP Initial Context Setup Response including the
same list of E-RAB setup list IE containing the E-RAB that has been successfully
established.
Validate that the EPS bearer has been re-established and that data can be
transmitted on the bearer.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE is in idle state
UE context on the ntetwork contains at least two bearers. This entails that at least
two E-RABs will be established for the UE during the Idle Mode exit
Test Procedure:
Send data in DL direction so that paging is started.
Expected Results:
Verify that:
Validate that MME sends a S1-AP Paging including a CN Domain IE set to PS
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Service Request
Validate that MME sends S1-AP: Initial Context setup Request including the ERAB to be setup list IE containing the list of E-RABs which the eNodeB should
establish in order to build the new E-RAB configuration
Validate that eNodeB sends a S1-AP Initial Context Setup Response including the
same list of E-RAB setup list IE containing the list of E-RABs that have been
successfully established.
Validate that all bearers have been re-established and that data can be transmitted
on all of the bearers.
References:
Test Objective:
Pre-Test Conditions:
UE is attached
Only 1 EPS bearer needs to be re-established
UE is in idle state
Test Procedure:
Send data in UL data from the UE.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Service Request
Validate that MME sends S1-AP: Initial Context setup Request including the ERAB to be setup list IE containing the E-RAB which the eNodeB should establish
in order to build the new E-RAB configuration
Validate that eNodeB sends a S1-AP Initial Context Setup Response including the
same list of E-RAB setup list IE containing the E-RAB that has been successfully
established.
Validate that the EPS bearer has been re-established and that data can be
transmitted on the bearer.
Figure 78: Successful Service Request when UE has pending user data to
be sent (Single Bearer)
References:
Test Objective:
Pre-Test Conditions:
UE is attached
Multiple EPS bearers need to be re-established
UE is in idle state
Test Procedure:
Send data in UL data from the UE.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Service Request
Validate that MME sends S1-AP: Initial Context setup Request including the ERAB to be setup list IE containing all the E-RABs which the eNodeB should
establish in order to build the new E-RAB configuration
Validate that eNodeB sends a S1-AP Initial Context Setup Response including the
same list of E-RAB setup list IE containing all the E-RABs that have been
successfully established.
Validate that all the EPS bearers have been re-established and that data can be
transmitted on each bearer.
Figure 79: Successful Service Request when the UE has pending user to be
sent (Multiple Bearers)
References:
Test Objective:
Pre-Test Conditions:
UE is attached
Only 1 EPS bearer needs to be re-established
UE is in idle state
Test Procedure:
Initialize a procedure that requires service request to be started.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Service Request
Validate that MME sends S1-AP: Initial Context setup Request including the ERAB to be setup list IE containing the E-RAB which the eNodeB should establish
in order to build the new E-RAB configuration
Validate that eNodeB sends a S1-AP Initial Context Setup Response including the
same list of E-RAB setup list IE containing the E-RAB that has been successfully
established.
Validate that the EPS bearer has been re-established and that data can be
transmitted on the bearer.
Successful Service Request invoked when the is in Idle mode and has a
mobile originating 1xCS fallback request from the upper layer
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE supports CS fallback
UE is attached for both EPS and non EPS services
UE is in idle state
Test Procedure:
Initialize a CS call from the UE.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Extended Service Request with Service Type IE set to mobile originating CS
fallback or 1xCS fallback
Validate that MME sends S1-AP: Initial Context setup Request a CS Fallback
Indicator IE.
Validate that the CS callback is successfully established and that the UE can
establish the CS Call
Remark1:
If no CS domain is available the MME will reject by answering the Initial UE message from
eNodeB with a S1-AP: Initial Context Setup Request encapsulating a NAS Service Reject
with EMM Cause IE set to CS domain not available
Figure 81: Successful Service Request when UE is in Idle mode and has a
mobile originating 1xCS fallback request
Successful Service Request invoked when the is in Active mode and has
a mobile originating 1xCS fallback request from the upper layer
References:
Test Objective:
Pre-Test Conditions:
UE is attached
UE supports CS fallback
UE is attached for both EPS and non EPS services
UE is in Connected state
Test Procedure:
Initialize a CS call from the UE.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS
Extended Service Request with Service Type IE set to mobile originating CS
fallback or 1xCS fallback
Validate that MME sends S1-AP: UE Context Modification Request a CS Fallback
Indicator IE.
Validate that eNodeB sends to MME a S1-AP UE Context Modification Response
Validate that the CS callback is successfully established and that the UE can
establish the CS Call
Remark1:
If no CS domain is available the MME will reject by answering the Initial UE message from
eNodeB with a S1-AP: Initial Context Setup Request encapsulating a NAS Service Reject
with EMM Cause IE set to CS domain not available
Figure 82: Successful Service Request when UE is in Active Mode and has
a mobile originating 1xCS fallback request
References:
Test Objective:
Pre-Test Conditions:
UE is not attached
UE is LTE capable
Test Procedure:
Initialize an emergency call from the UE.
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Initial UE message including a RRC
Establishment Cause IE set to Emergency
Validate that MME sends S1-AP: Initial Context Setup Request including the ERAB to be Setup List IE
Validate that eNodeB sends to MME a S1-AP Initial Context Setup Response with
the same E-RAB Setup List IE
Validate that attach or service request procedure is successfully completed and
that the emergency call can be performed.
Reference:
Test Objective:
Pre-Test Conditions:
Configure both eNodeB and SGW to present a echo request timer for testing
purposes.
Test Procedure:
Initiate a UE attach
Expected Results:
Verify that:
Validate that once a GTP-U tunnel is established by the network, eNodeB is able
to send a GTP-U: Echo Request to SGW. SGW is capable of acknowledging it by
sending back a GTP-U: Echo Response.
Validate that SGW is also capable of sending a GTP-U: Echo Request as per the
configuration and that is successfully acknowledged by eNodeB with a GTP-U:
Echo Response.
Reference:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME
X2 interface is properly set up.
UE is attached and a single E-RAB exists for the UE.
Test Procedure:
Start an application to start a download of a large file while HO happens (e.g video
streaming session, FTP, etc)
Change the radio condition in the eNodeBs to trigger a HO
Expected Results:
Verify that:
Validate that, prior to the HO, there is a User data transmission ongoing from
between Source eNodeB and SGW
When X2 HO happens and the UE has moved to target eNodeB, the UL Data
transmission starts automatically from Target eNodeB to SGW as soon as the UE
context is established through the target eNodeB.
Validate that Target eNodeB sends a S1:AP Path Switch Request to MME to
indicate that X2 HO is in process
Validate that SGW sends a GTP-U End of Marker to the Source eNodeB to
indicate that the DL path has been moved
Validate that Source eNodeB sends a GTP-U End Of Marker to Target eNodeB
Validate that DL data is resumed between SGW and Target eNodeB
Validate that Target eNodeB is sending a S1-AP: Path Switch Request
Acknowledgement to MME in order to indicate the successful end of HO.
Remark 1:
During this process the Target eNodeB can perform a Tracking Area Update procedure with
MME if required per the TA configuration on the network.
UE
Target
eNodeB
Source
eNodeB
MME
Serving
GW
PDN GW
Downlink data
Handover completion
Uplink data
1 Path Switch Request
Downlink data
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
(A)
Reference:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
One or more E-RAB established for the UE
Test Procedure:
Force S-GW to send a GTP-U: Error Indication (e.g manual command on SGW,
making eNodeB to send a UL data for an unexisting EPS Bearer in UL due to HO
or manually using an unknown TEID)
Expected Results:
Verify that:
Validate that, SGW is sending a GTP-U: Error Indication including as information
element the TEID for which that Error Indication was triggered
Validate that eNodeB is subsequently initiating the UE Context Release for the
EPS bearer by sending a S1-AP UE Context Release req to MME, initiating the ERAB Release procedure and immediately locally releasing the E-RAB (i.e without
waiting for a response from the MME). The RRC Connection Release is
performed.
Reference:
Test Objective:
Pre-Test Conditions:
S1 interface is properly set up between eNodeB and MME/SGW
One or more E-RAB established for the UE
Test Procedure:
Force eNodeB to send a GTP-U: Error Indication (e.g manual command on
eNodeB, making S-GW to send a DL data for an unexisting EPS Bearer in DL
due to HO or manually using an unknown TEID)
Expected Results:
Verify that:
Validate that, eNodeB is sending a GTP-U: Error Indication including as
information element the TEID for which that Error Indication was triggered
Validate that upon the reception of the Error Indication with the GTP-U Identifier
from the enodeB to the S-GW, the S-GW does not delete the associated bearer
Context but just all the eNodeB GTP-U TEIDs for this UE. The S-GW then starts
buffering DL packets received from this UE and sends Downlink Data Notification
message to the MME which triggers the re-establishment of the corresponding
bearers.
The call flow would be as follows:
Upon the reception of the GTP-U Error Indication from eNodeB, S-GW sends a
S11 Downlink Data Notification to MME
MME is sending a S1-AP: Paging to all eNodeBs belonging to the same TA in
which the UE is currently registered
The eNodeB is sending S1-AP: Initial UE message containing a Service Request
to the MME
MME is sending a S1-AP: Initial Context setup Request to eNOdeB
enodeB sends a S1-AP: Initial Context Setup Complete to MME
Data is re-established on both of directions.
Reference
Test Objective:
Pre-Test Conditions:
UE is not attached
Test Procedure:
Perform UE attach with not any dedicated bearer being initiated by the network
Initiate traffic from/to the UE with different traffic types: HTTP, FTP, etc
Expected Results:
Verify that:
eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach
Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM
message container IE with the NAS PDN Connectivity Request message
MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity
Request message, with Identity type IE=IMSI
eNodeB sends a S1-AP Uplink NAS Tansport encapsulating the NAS: Identity
Response message with the IMSI IE included.
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS
Authentication Request message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS
Authentication Response message
The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security
Mode Command, with the Selected NAS Security Algorithms IE including EEA0,
EEAA1 or EEA2 for Ciphering as per the configuration
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode
complete
MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM
Information Request
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM
Information Response
MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach
Accept message. The message will include the NAS Activate Default EPS bearer
context Request message, with the new GUTI IE included.
eNodeB sends a S1-AP: Initial Context Setup Response message
eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach
Complete. The ESM message container IE will include a NAS Activate Deftault
EPS Bearer Context Accept message.
Validate that all kind of Data can be transferred on the default bearer on both of
directions for any traffic type.
UE
eNodeB
new MME
Serving GW
Old
MME/SGSN
1. Attach Request
HSS
PCRF
PDN GW
EIR
2. Attach
Request
3. Identification Request
3. Identification Response
4. Identity Request
4. Identity Response
5a. Authentication / Security
5b. Identity Request/Response
(A)
(F)
(B)
(C)
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode
eNodeB will use the RLC AM Mode
Test Procedure:
Perform UE attach
Initiate traffic to the UE with non-GBR, using RLC AM Mode at the eNodeB that
will entail the creation of a dedicated bearer
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS
Activate Dedicated EPS Bearer Context Request. The NAS message shall include
the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE
Validate that eNodeB is sending a S1-AP E-RAB Setup Response
Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a
ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall
include the EPS bearer identity and the Procedure transaction Identity IE
Validate that the dedicated bearer is established successfully and both eNodeB
and SGW/PGW have the same TFT/QoS features for the bearer
Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 89: Data Transfer on Dedicated Bearer with non-GBR Service and
AM Mode
Test Name:
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode
eNodeB will use the RLC UM Mode
Test Procedure:
Perform UE attach
Initiate traffic to the UE with non-GBR, using RLC UM Mode at the eNodeB that
will entail the creation of a dedicated bearer
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS
Activate Dedicated EPS Bearer Context Request. The NAS message shall include
the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE
Validate that eNodeB is sending a S1-AP E-RAB Setup Response
Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a
ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall
include the EPS bearer identity and the Procedure transaction Identity IE
Validate that the dedicated bearer is established successfully and both eNodeB
and SGW/PGW have the same TFT/QoS features for the bearer
Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 90: Data Transfer on Dedicated Bearer with non-GBR service and
UM Mode
Reference:
Test Objective:
Validate the successful data transfer with GBR Service and AM Mode on
eNodeB
Pre-Test Conditions:
UE is in Active Mode
eNodeB will use the RLC AM Mode
Test Procedure:
Perform UE attach
Initiate traffic to the UE with GBR (QCI<4), using RLC AM Mode at the eNodeB
that will entail the creation of a dedicated bearer
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS
Activate Dedicated EPS Bearer Context Request. The NAS message shall include
the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE
Validate that eNodeB is sending a S1-AP E-RAB Setup Response
Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a
ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall
include the EPS bearer identity and the Procedure transaction Identity IE
Validate that the dedicated bearer is established successfully and both eNodeB
and SGW/PGW have the same TFT/QoS features for the bearer
Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 91: Data Transfer on Dedicated Bearer with GBR Service and AM
Mode
Reference:
Test Objective:
Validate the successful data transfer with GBR Service and UM Mode on
eNodeB
Pre-Test Conditions:
UE is in Active Mode
eNodeB will use the RLC UM Mode
Test Procedure:
Perform UE attach
Initiate traffic to the UE with GBR (QCI<4), using RLC UM Mode at the eNodeB
that will entail the creation of a dedicated bearer
Expected Results:
Verify that:
Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS
Activate Dedicated EPS Bearer Context Request. The NAS message shall include
the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE
Validate that eNodeB is sending a S1-AP E-RAB Setup Response
Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a
ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall
include the EPS bearer identity and the Procedure transaction Identity IE
Validate that the dedicated bearer is established successfully and both eNodeB
and SGW/PGW have the same TFT/QoS features for the bearer
Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 92: Data Transfer on Dedicated Bearer with GBR Service and UM
Mode
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with a single E-RAB established
Two eNodeBs will be required for this test case.
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate an X2-based HO to the target eNodeB. Validate the first call flow below
Initiate an X2-based HO to the former eNodeB. Validate the second call flow below
Expected Results:
Verify that:
Source e-NodeB initiates the X2-based HO with target eNodeB (message
sequence out of the scope of this test plan)
Target eNodeB will send a S1-AP: Path Switch Request to MME. The message
will include E-RAB to be Switched in Downlink List IE including a single E-RAB,
and also a Switched in Downlink Item IE which will contain the E-RAB ID IE, the
Transport Layer Address IE and the GTP-TEID IE
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB a GTP-U End Of Marker message in order
to indicates source eNodeB that shall start forwarding the GTP-U packets to
Target eNodeB. Validate that Source eNodeB is honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB. This message will include the E-RAB to Be Switched in Uplink IE,
the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint
Target eNodeB will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB (not
source eNodeB) after the completion of X2 HO.
Validate that data traffic is continued with minimum disruption
Perform now a subsequent X2 HO. Validate that:
e-NodeB 1 (original eNodeB) is sending a S1-AP Path Switch Request to MME.
The message will include E-RAB to be Switched in Downlink List IE including a
single E-RAB, and also a Switched in Downlink Item IE which will contain the ERAB ID IE, the Transport Layer Address IE and the GTP-TEID IE
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB (eNodeB 2) a GTP-U End Of Marker
message in order to indicates source eNodeB (eNodeB 2) that shall start
forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is
honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB 1. This message will include the E-RAB to Be Switched in Uplink
IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint
Target eNodeB 1 will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB 1 performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB 1 (not
source eNodeB 2) after the completion of X2 HO.
Validate that data traffic is continued with minimum disruption
UE
Target
eNodeB
Source
eNodeB
MME
Serving
GW
PDN GW
Downlink data
Handover completion
Uplink data
1 Path Switch Request
Downlink data
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
(A)
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least 1 E-RAB established
Two eNodeBs will be required for this test case.
Ciphering is enabled
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate an X2-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the X2-based HO with target eNodeB (message
sequence out of the scope of this test plan)
Target eNodeB will send a S1-AP: Path Switch Request to MME. The message
will include E-RAB to be Switched in Downlink List IE including a single E-RAB,
and also a Switched in Downlink Item IE which will contain the E-RAB ID IE, the
Transport Layer Address IE and the GTP-TEID IE. This message will include also
UE Security Capabilities IE indicating the support of EEA1 and/or EEA2 as per
configuration.
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB a GTP-U End Of Marker message in order
to indicates source eNodeB that shall start forwarding the GTP-U packets to
Target eNodeB. Validate that Source eNodeB is honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB. This message will include the E-RAB to Be Switched in Uplink IE,
the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint
Target eNodeB will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB (not
source eNodeB) after the completion of X2 HO.
Validate that data traffic is continued with minimum disruption while ciphering is
being performed
UE
Target
eNodeB
Source
eNodeB
MME
Serving
GW
PDN GW
Downlink data
Handover completion
Uplink data
1 Path Switch Request
Downlink data
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
(A)
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with multiple E-RABs established
Two eNodeBs will be required for this test case.
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate an X2-based HO to the target eNodeB.
Initiate an X2-based HO to the former eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the X2-based HO with target eNodeB (message
sequence out of the scope of this test plan)
Target eNodeB will send a S1-AP: Path Switch Request to MME. The message
will include all the E-RABs to be Switched in Downlink List IE including all E-RABs,
and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE,
the Transport Layer Address IE and the GTP-TEID IEs
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB a GTP-U End Of Marker message in order
to indicates source eNodeB that shall start forwarding the GTP-U packets to
Target eNodeB. Validate that Source eNodeB is honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB. This message will include all the E-RABs to Be Switched in Uplink
IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint
Target eNodeB will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB (not
source eNodeB) after the completion of X2 HO.
Validate that data traffic is continued with minimum disruption
Perform now a subsequent X2 HO. Validate that:
e-NodeB 1 (original eNodeB) is sending a S1-AP Path Switch Request to MME.
The message will include all the E-RABs to be Switched in Downlink List IE
including all E-RABs, and also a Switched in Downlink Item IE which will contain
the E-RAB ID IEs, the Transport Layer Address IE and the GTP-TEID IEs
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB (eNodeB 2) a GTP-U End Of Marker
message in order to indicates source eNodeB (eNodeB 2) that shall start
forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is
honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB 1. This message will include the E-RAB to Be Switched in Uplink
IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint
Target eNodeB 1 will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB 1 performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB 1 (not
source eNodeB 2) after the completion of X2 HO.
Validate that data traffic is continued with minimum disruption
UE
Target
eNodeB
Source
eNodeB
MME
Serving
GW
PDN GW
Downlink data
Handover completion
Uplink data
1 Path Switch Request
Downlink data
(A)
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with multiple E-RABs established
Two eNodeBs will be required for this test case.
Make EPC to be unable to fully comply with the path witch (For example to allow
only few E-RABs establishment through the target eNodeB)
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate an X2-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the X2-based HO with target eNodeB (message
sequence out of the scope of this test plan)
Target eNodeB will send a S1-AP: Path Switch Request to MME. The message
will include all the E-RABs to be Switched in Downlink List IE including all E-RABs,
and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE,
the Transport Layer Address IE and the GTP-TEID IEs
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB a GTP-U End Of Marker message in order
to indicates source eNodeB that shall start forwarding the GTP-U packets to
Target eNodeB. Validate that Source eNodeB is honoring this request
Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to
Target eNodeB. This message will include all the E-RABs to Be Switched in Uplink
IE, the list of E-RABs which are able to be switched to the new GTP Tunnel
Endpoint. On the other hand, this message will include also a E-RAB to Be
Released List IE containing the list of all E-RABS which were unable to be
switched to the new GTP tunnel endpoint.
Target eNodeB will send an X2-AP UE context Release message to the source
eNodeB to indicate that the HO is completed and resources at the source eNodeB
can be released
Target enodeB performs a Tracking Area Update with MME in case TA has
changed
Validate that the resources remain alive only on MME and target eNodeB (not
source eNodeB) after the completion of X2 HO. Validate that only some of the ERABs have been re-established through the target eNodeB upon the completion of
the HandOver.
Validate that data traffic is continued with minimum disruption (being re-routed
over the rest of the bearers)
UE
Target
eNodeB
Source
eNodeB
MME
Serving
GW
PDN GW
Downlink data
Handover completion
Uplink data
1 Path Switch Request
Downlink data
(A)
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
Reference:
Test Objective:
Pre-Test Conditions:
UE attached to the source eNodeB
Make EPC to be unable to with the path switch
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate an X2-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the X2-based HO with target eNodeB (message
sequence out of the scope of this test plan)
Target eNodeB will send a S1-AP: Path Switch Request to MME. The message
will include all the E-RABs to be Switched in Downlink List IE including all E-RABs,
and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE,
the Transport Layer Address IE and the GTP-TEID IEs
A Modify Bearer Procedure will be successfully completed between MME and
SGW to update the TEIDs
The SGW will send to Source eNodeB a GTP-U End Of Marker message in order
to indicates source eNodeB that shall start forwarding the GTP-U packets to
Target eNodeB. Validate that Source eNodeB is honoring this request
Validate that MME is sending a S1-AP Patch Switch Failure including a Cause IE
indicating the reason for the path switch failure.
Validate that MME is explicitly detaching the UE and there is not any resource hold
by the network
Reference:
Test Objective:
Validate the successful S1 based HO between two eNodeBs for single ERAB
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least 1 E-RAB established
Two eNodeBs will be required for this test case.
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Request to Target eNodeB including the ERABs to be setup List IE, containing 1 E-RAB Id
Target eNodeB sends a S1-AP Handover Request Acknowledge to MME including
the E-RABs Admitted List IE containing all the successful E-RABs id that were
able to be established
The MME sends a S1-AP Handover Command to the source eNodeB including the
Target to Source Transparent Container IE
The source e-NodeB sends a S1-AP: eNodeB Status Transfer to MME including
the eNodeB Status Transfer Transparent Container IE with the list of all the ERABs which are subject to status transfer
The MME sends a S1-AP: MME Status Transfer to target enodeB including the
same information than above
The Target eNodeB sends a S1-AP Handover Notify to MME
The MME sends a S1-AP UE Context Release Command to Source eNodeB with
Cause IE set to Successful HO
The Source eNodeB acknowledges the successful release of the resources by
sending back a S1-AP UE Context Release cOmplete
Validate that the data session continues with no noticeable disruption
MME and Target eNodeB will perform Tracking Area Update if is required (target
eNodeB TAC is not into the current UE TAC list)
UE
Source
eNodeB
Target
MME
eNodeB
Downlink User Plane data
Serving GW
PDN GW
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Handover Request
Admission Control
4. Handover Request Ack
5. Handover Command
9. Handover Notify
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least two E-RABs established
Two eNodeBs will be required for this test case.
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate traffic also for the rest of bearers (e.g ICMP)
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Request to Target eNodeB including the ERABs to be setup List IE, containing all the E-RAB Ids
Target eNodeB sends a S1-AP Handover Request Acknowledge to MME including
the E-RABs Admitted List IE containing all the successful E-RABs id that were
able to be established
The MME sends a S1-AP Handover Command to the source eNodeB including the
Target to Source Transparent Container IE
The source e-NodeB sends a S1-AP: eNodeB Status Transfer to MME including
the eNodeB Status Transfer Transparent Container IE with the list of all the ERABs which are subject to status transfer
The MME sends a S1-AP: MME Status Transfer to target enodeB including the
same information than above
The Target eNodeB sends a S1-AP Handover Notify to MME
The MME sends a S1-AP UE Context Release Command to Source eNodeB with
Cause IE set to Successful HO
The Source eNodeB acknowledges the successful release of the resources by
sending back a S1-AP UE Context Release cOmplete
Validate that the data session continues with no noticeable disruption for all the
bearers
MME and Target eNodeB will perform Tracking Area Update if is required (target
eNodeB TAC is not into the current UE TAC list)
UE
Source
eNodeB
Target
MME
eNodeB
Downlink User Plane data
Serving GW
PDN GW
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Handover Request
Admission Control
4. Handover Request Ack
5. Handover Command
9. Handover Notify
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least two E-RABs established
Two eNodeBs will be required for this test case.
Configure target eNodeB to accept only a subset of E-RABs
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate traffic also for the rest of bearers (e.g ICMP)
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Request to Target eNodeB including the ERABs to be setup List IE, containing all the E-RAB Ids
Target eNodeB sends a S1-AP Handover Request Acknowledge to MME including
the E-RABs Admitted List IE containing all the successful E-RABs id that were
able to be established. It also contains the E-RABs Failed to Setup List IE
containing the list of all the E-RAB IDs for each E-RAB not accepted by the target
eNodeB
The MME sends a S1-AP Handover Command to the source eNodeB including the
Target to Source Transparent Container IE
The source e-NodeB sends a S1-AP: eNodeB Status Transfer to MME including
the eNodeB Status Transfer Transparent Container IE with the list of all the ERABs which are subject to status transfer
The MME sends a S1-AP: MME Status Transfer to target enodeB including the
same information than above
The Target eNodeB sends a S1-AP Handover Notify to MME
The MME sends a S1-AP UE Context Release Command to Source eNodeB with
Cause IE set to Successful HO
The Source eNodeB acknowledges the successful release of the resources by
sending back a S1-AP UE Context Release complete
Validate that the data session continues with no noticeable disruption for all the
bearers
MME and Target eNodeB will perform Tracking Area Update if is required (target
eNodeB TAC is not into the current UE TAC list)
UE
Source
eNodeB
Target
MME
eNodeB
Downlink User Plane data
Serving GW
PDN GW
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Handover Request
Admission Control
4. Handover Request Ack
5. Handover Command
9. Handover Notify
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least two E-RABs established
Two eNodeBs will be required for this test case.
Configure MME to reject the HO (e.g S1-AP between MME and Target eNodeB is
down)
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Preparation Failure including a Cause IE
indicating the reason for the HO failure
Validate that UE context is still alive through source eNodeB and there is ongoing
data transfer between S-GW and source eNodeB while RF is still acceptable.
Reference:
Test Objective:
Validate that the PS Call will not drop after the S1 HO for single-RAB fails
because of no common ciphering algorithm
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least two E-RABs established
Two eNodeBs will be required for this test case.
Configure target eNodeB and UE to not have ta common ciphering algorithm
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Request to Target eNodeB including the ERABs to be setup List IE, containing all the E-RAB Ids
Target eNodeB is sending a S1-AP Handover Failure to MME including a Cause
IE set to Encryption and/or integrity protection algorithm not supported
MME is sending a S1-AP Handover Failure to enodeB including the same Cause
IE
Validate that UE context is still alive through source eNodeB and there is ongoing
data transfer between S-GW and source eNodeB while RF is still acceptable.
Reference:
Test Objective:
Validate that the PS Call will not drop after the S1 HO for single-RAB fails
because of no resources available at target eNodeB
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with at least two E-RABs established
Two eNodeBs will be required for this test case.
Configure target eNodeB to not accept any E-RAB and generage Handover
Failure message
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate a S1-based HO to the target eNodeB.
Expected Results:
Verify that:
Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to
MME. The HandOver Required message includes Handover Type IE= Intra LTE,
the Direct Forwarding Path Availability IE, the Source to Target Transparent
Container IE, the Target ID IE (including the target eNodeB identity and selected
TAI) and the Cause IE indicating the reason for the HO
MME is sending a S1-AP Handover Request to Target eNodeB including the ERABs to be setup List IE, containing all the E-RAB Ids
Target eNodeB is sending a S1-AP Handover Failure to MME including the
corresponding Cause IE
MME is sending a S1-AP Handover Failure to enodeB including the same Cause
IE
Validate that UE context is still alive through source eNodeB and there is ongoing
data transfer between S-GW and source eNodeB while RF is still acceptable.
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with 1 E-RAB established
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate the LTE to UTRAN HO
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Handover Required to MME with Handover
Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of
the target cell, as well as a source to target transparent container IE.
Validate that MME is sending a Forward Relocation Request to 3G-SGSN.
o 3G-SgSN forwards the relocation request to the target RNC
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Forward Relocation Response is sent by 3G-SGSN to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC sends a Reloction Detect to 3G-SGSN
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
Validate that data transfer is continued via UTRAN and no resource is hold at LTE
eNodeB.
UE
Source
eNodeB
Source
Target
Target SGSN Serving GW Serving GW
PDN GW
HSS
5. RelocationRequest
5a. Relocation Request Acknowledge
6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
8. Create Indirect Data Forwarding Tunnel Request
8a. Create Indirect Data Forwarding Tunnel Response
Source
eNodeB
UE
Target RNC
Source MME
Target SGSN
Source
Serving GW
Target
Serving GW PDN GW
HSS
(A)
(B)
Reference:
Test Objective:
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB with 2 E-RABs established
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate the LTE to UTRAN HO
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Handover Required to MME with Handover
Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of
the target cell, as well as a source to target transparent container IE.
Validate that MME is sending a Forward Relocation Request to 3G-SGSN (The
relocation request includes two RAB IDs)
o 3G-SGSN forwards the relocation request to the target RNC (The
relocation request includes two RAB IDs)
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Forward Relocation Response is sent by 3G-SGSN to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC sends a Reloction Detect to 3G-SGSN
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
Validate that data transfer is continued via UTRAN and no resource is hold at LTE
eNodeB.
UE
Source
eNodeB
Source
Target
Target SGSN Serving GW Serving GW
PDN GW
HSS
5. RelocationRequest
5a. Relocation Request Acknowledge
6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
8. Create Indirect Data Forwarding Tunnel Request
8a. Create Indirect Data Forwarding Tunnel Response
Source
eNodeB
UE
Target RNC
Source MME
Target SGSN
Source
Serving GW
Target
Serving GW PDN GW
HSS
(A)
(B)
Reference:
Test Objective:
Validate the inter RAT Failure for a UE does not release the UE context
in the EPC network
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB
1 eNodeB and 1 nodeB will be required for this test
Bring down the link between MME and SGSN or the link between SGSN and RNC
to entail the HO to fail
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate the LTE to UTRAN HO
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Handover Required to MME with Handover
Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of
the target cell, as well as a source to target transparent container IE.
Validate that MME is sending back a S1-AP Handover Preparation Failure. The
Cause IE shall be set to the reason of the handover failure
Validate that the UE context is not released and data transfer is continued via
EUTRAN between eNodeB and SGW.
Reference:
Test Objective:
Validate the inter RAT Failure for a UE does not release the UE context
in the EPC network
Pre-Test Conditions:
UE is in Active Mode in the source eNodeB
1 eNodeB and 1 nodeB will be required for this test
Configure the target NodeB to not allow any more calls (simulate overload
situation)
Test Procedure:
Initiate a FTP session (will transfer data in both of directions) of a large file that can
span the handover time
Initiate the LTE to UTRAN HO
Expected Results:
Verify that:
Validate that eNodeB sends a S1-AP Handover Required to MME with Handover
Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of
the target cell, as well as a source to target transparent container IE.
Validate that MME is sending back a S1-AP Handover Preparation Failure. The
Cause IE shall be set to No Radio Resources Available in Target Cell. Please
remember this cause code is originated in the target radio access side
Validate that the UE context is not released and data transfer is continued via
EUTRAN between eNodeB and SGW.
UE
Source
eNodeB
Source
Target
Target SGSN Serving GW Serving GW
PDN GW
5. Relocation Request
6. Relocation Failure
7. Delete Session Request
7a. Delete Session Response
.8. Forward Relocation Response (Reject)
9. Handover Preparation Failure
HSS
Reference:
Test Objective:
Pre-Test Conditions:
UE supports CS fallback
UE is in Idle Mode
UE is attached for both EPS and non-EPS services
VoIP Services are not available
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a mobile originated speech call
After the UE is handed over to UTRAN network and CS call has been established,
release the CS call
Expected Results:
Verify that:
UE/MS
eNodeB
BSS/RNS
MME
MSC
SGW/PGW
SGSN
5. S1 UE Context Release
6. UE changes RAT then LA Update or Combined RA/LA Update or RA Update or LAU and RAU
7a. Suspend (see 23.060)
7b. Suspend Request / Response
8. Update bearer(s)
9. CM Service Request
If the MSC
is changed
10c. CS MO call
Reference:
Test Objective:
Pre-Test Conditions:
UE supports CS fallback
UE is in Idle Mode
UE is attached for both EPS and non-EPS services
VoIP Services are not available
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a mobile terminated speech call
After the UE is handed over to UTRAN network and CS call has been established,
release the CS call
Expected Results:
Verify that:
MME sends a S1-AP Paging to eNodeB with CN Domain IE set to CS
eNodeB sends back a S1-AP Initial UE message encapsulating a NAS Extended
Service Request. The service Type IE inside that message shall be set to mobile
terminating CS fallback or 1xCS Fallback. It will also contain a CSFB response IE
set to CS fallback accepted by the UE
MME sends a S1-AP Initial Context Setup Request to eNodeB, including a CS
Fallback Inidicator IE. eNodeB optionally may initiate a measurement control
procedure to find out the target UTRANcell.
eNodeB sends a S1-AP Initial Context Setup Response to MME
eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall
be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target
cell
o 3G-SGSN forwards the relocation request to the target RNC
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Forward Relocation Response is sent by 3G-SGSN to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC sends a Reloction Detect to 3G-SGSN
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
CS call is established via UTRAN. Validate that the CS call can be successfully
performed.
Validate that once the call is ended the UE returns to LTE network
UE
MME
eNodeB
RNC/BSC
MSC
VLR
HSS
G-MSC
1. IAM
5. Paging
Note: This call flow will appear always at the beginning of the Inter-RAT HO due to Mobile Terminating Call
when UE in Idle Mode.
If the eNodeB knows that PS HO is supported, then the procedure following this call flow is:
UE/MS
eNodeB
BSS/RNS
MSC
MME
Serving
GW
SGSN
5a. Establish CS
connection
5b. Connection Reject
Option 1:
MSC is not
changed
If the MSC
is changed
P-GW/
GGSN
eNodeB
BSS/RNS
MSC
MME
S-GW/PGW
SGSN
IF THE
MSC IS
CHANGED
Reference:
Test Objective:
Pre-Test Conditions:
UE supports CS fallback
UE is in Active mode transmitting data
UE is attached for both EPS and non-EPS services
VoIP Services are not available
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a mobile originated speech call
After the UE is handed over to UTRAN network and CS call has been established,
release the CS call
Expected Results:
Verify that:
eNodeB sends a S1-AP Uplink NSA Transport encapsulating a NAS Extended
Service Request including a Service Type IE set to mobile originating CS fallback
or 1xCS Fallback
MME sends a S1-AP UE Context Modification Request with CS Fallback Indicator
IE set to CS Fallback Required.eNodeB optionally may initiate a measurement
control procedure to find out the target UTRANcell.
eNodeB sends a S1-AP UE Context Modification Response
eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall
be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target
cell
o 3G-SGSN forwards the relocation request to the target RNC
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Forward Relocation Response is sent by 3G-SGSN to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC sends a Reloction Detect to 3G-SGSN
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
CS call is established via UTRAN. Validate that the CS call can be successfully
performed.
Validate that once the call is ended the UE returns to LTE network
UE/MS
eNodeB
BSS/RNS
MME
MSC
SGW/PGW
SGSN
5. S1 UE Context Release
6. UE changes RAT then LA Update or Combined RA/LA Update or RA Update or LAU and RAU
7a. Suspend (see 23.060)
7b. Suspend Request / Response
8. Update bearer(s)
9. CM Service Request
If the MSC
is changed
10c. CS MO call
Reference:
Test Objective:
Pre-Test Conditions:
UE supports CS fallback
UE is in Active mode transmitting data
UE is attached for both EPS and non-EPS services
VoIP Services are not available
1 eNodeB and 1 nodeB will be required for this test
Test Procedure:
Initiate a mobile originated speech call
After the UE is handed over to UTRAN network and CS call has been established,
release the CS call
Expected Results:
Verify that:
MME sends a S1-AP Paging with CN Domain IE set to CS even when there is
traffic going on between eNodeB and SGW
eNodeB sends a S1-AP Uplink NSA Transport encapsulating a NAS Extended
Service Request including a Service Type IE set to mobile originating CS fallback
or 1xCS Fallback
MME sends a S1-AP UE Context Modification Request with CS Fallback Indicator
IE set to CS Fallback Required.eNodeB optionally may initiate a measurement
control procedure to find out the target UTRANcell.
eNodeB sends a S1-AP UE Context Modification Response
eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall
be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target
cell
o 3G-SGSN forwards the relocation request to the target RNC
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Forward Relocation Response is sent by 3G-SGSN to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC sends a Reloction Detect to 3G-SGSN
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
CS call is established via UTRAN. Validate that the CS call can be successfully
performed.
Validate that once the call is ended the UE returns to LTE network
If the eNodeB knows that PS HO is supported, then the procedure following this call flow is:
UE/MS
eNodeB
BSS/RNS
MSC
MME
Serving
GW
SGSN
5a. Establish CS
connection
5b. Connection Reject
Option 1:
MSC is not
changed
If the MSC
is changed
P-GW/
GGSN
eNodeB
BSS/RNS
MSC
MME
S-GW/PGW
SGSN
IF THE
MSC IS
CHANGED
6.2.6.1.3.9 LTE to UTRAN SRVCC: Inter RAT Handover for VoIP Call
Test Name:
Reference:
Test Objective:
Validate the successful SRVCC when the UE has a VoIP call ongoing
Pre-Test Conditions:
UE is registered on both MME and HSS
Test Procedure:
Initiate speech through the IMS/LTE network
Trigger SRVCC Inter RAT HO to UTRAN
Validate that VoIP Call continues after the HO
Expected Results:
Verify that:
eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall
be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target
cell. It shall also contain SRVCC HO Indication IE set to CS Only
o 3SRVCC PS to CS Request sent from MME to MSC Server
o MSC sends a Relocation Request from MME to 3G-SGSN
o Relocation Request sent from MSC Server to RNC
o Target RNC send Relocation Request Acknowledge to MSC
o MSC Server sends SRVCC PS to CS Response to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC Relocation Detect to MSC Server
o RNC sends a Relocation Complete to MSC Server
o MSC sends a SRVCC PS to CS Complete Notification to MME
o MME sends SRVCC PS to CS Complete Notification Ack to MSC Server
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
Validate that voice call is ongoing via UTRAN
UE
Target
MSC
MSC Server/
MGW
Source
MME
Source
E-UTRAN
Target
SGSN
Target
BSS
SGW
IMS
(SCC AS)
1. Measurement reports
2. Decision for HO
3. Handover Required
4. Bearer Splitting
5.PS to CS Req
6.Prep HO Req
7. HO Request/Ack
8.Prep HO Resp
9. Establish circuit
10. Initiation of Session Transfer (STN-SR or E-STN-SR)
11. Session transfer
and Update remote end
13.PS to CS Resp
14. Handover Command
18. Suspend
18. Update Bearer
19. HO Complete
20.SES (HO Complete)
21. ANSWER
22. PS to CS Complete/Ack
23.UpdateLoc
24. Subscriber Location Report
HSS/
HLR
GMLC
Figure 117: LTE to UTRAN SRVCC, Inter RAT HO for VoIP Call
Note: The Handover Required will contain a SRVCC HO Indication IE to indicate to the MME that target is
only CS capable, hence this is a SRVCC HO operation only towards the CS Domain
6.2.6.1.3.10 LTE to UTRAN SRVCC: Inter RAT Handover for Data Transfer
and VoIP Call
Test Name:
LTE to UTRAN SRVCC: Inter RAT Handover for Data Transfer and VoIP
call
Reference:
Test Objective:
Validate the successful SRVCC when the UE has both data transfer and
VoIP calls ongoing
Pre-Test Conditions:
UE is registered on both MME and HSS
Test Procedure:
Initiate speech through the IMS/LTE network
Initiate data transfer of a big file
Trigger SRVCC Inter RAT HO to UTRAN
Validate that both data transfer and VoIP Call continues after the HO
Expected Results:
Verify that:
eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall
be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target
cell. It shall also contain SRVCC HO Indication IE set to PS and CS
o 3SRVCC PS to CS Request sent from MME to MSC Server
o MSC sends a Relocation Request from MME to 3G-SGSN
o Relocation Request sent from MSC Server to RNC
o 3G-SGSN forwards the relocation request to the target RNC
o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN
o Target RNC send Relocation Request Acknowledge to MSC
o Forward Relocation Response is sent by 3G-SGSN to MME
o MSC Server sends SRVCC PS to CS Response to MME
MME sends a S1-AP Handover Command to eNodeB
o RNC Relocation Detect to MSC Server
o RNC sends a Relocation Detect to 3G-SGSN
o RNC sends a Relocation Complete to MSC Server
o RNC sends a Relocation Complete to 3G-SGSN
o 3G-SGSN sends a forward Relocation Complete Notification to MME
o MSC sends a SRVCC PS to CS Complete Notification to MME
o MME sends SRVCC PS to CS Complete Notification Ack to MSC Server
o MME sends a Forward Relocation Complete ACK to 3G-SGSN
o There is a Routing Area Update between UE and 3G-SGSN
MME sends a S1-AP UE Context Release Command with Cause IE set to
Successful Handover
eNodeB sends a S1-AP UE Context Release Complete to MME.
Validate that Data Transfer and voice call are ongoing via UTRAN
Target
MSC
MSC Server/
MGW
Source
MME
Source
E-UTRAN
UE
Target
SGSN
Target
RNS/BSS
SGW
IMS
(SCC AS)
1. Measurement reports
2. Decision for HO
3. Handover Required
4. Bearer Splitting
5a. PS to CS Req
5b. Prep HO
Req
6a. Forward Reloc Req
15. UE tunes to
UTRAN/GERAN
16. HO Detection
17a. Reloc/HO Complete
17b. SES (HO Complete)
17c. ANSWER
17d. PS to CS Complete/Ack
17e. UpdateLoc
HSS/
HLR
Figure 118: LTE to UTRAN SRVCC, Inter RAT HO for Data Transfer with
VoIP Call
Note: The Handover Required will contain a SRVCC HO Indication IE to indicate to the MME that target is
both CS+PS HO request, hence this is a SRVCC HO operation towards the target CS and PS Domains
Reference:
Test Objective:
Validate the successful inter RAT Handover for a UE with a single RAB
from UTRAN to LTE
Pre-Test Conditions:
UE is operating in the UTRAN network
UE has established a single RAB
Test Procedure:
Initiate data transfer of a big file
Trigger an inter RAT Handover for LTE
Expected Results:
Verify that:
Validate that during the preparation phase in the 3G part:
o RNC sends a Relocation Request to 3G-SGSN
o 3G-SGSN forwards the relocation request to MME
MME sends a S1-AP Handover Request to eNodeB; The Handover Request will
present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup
List IE group contains only 1 E-RABid
eNodeB sends a S1-AP Handover Request Acknowledge containing the same ERABs to Be Setup List IE
o After that a Forward Relocation Response is sent by MME to 3G-SGSN
o Relocation Command is sent from 3G-SGSN to source RNC
eNodeB sends a S1-AP Handover Notify to MME
o MME sends a Forward Relocation Complete Notification to 3G-SGSN
o 3G-SGSN acknowledges by sending back a Forward Relocation Ack to
MME
There is a Tracking Area Update procedure from UE->eNodeB->MME
After that, a Iu Release procedure between source RNC and 3G-SGSN shall be
successfully performed
Validate that the data is still ongoing via E-UTRAN and no resource is hold by the
UTRAN network
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Serving GW
Target
Serving GW
PDN
GW
HSS
1. Handover Initiation
2. Relocation Required
5. Handover Request
5a. Handover Request Acknowledge
6 . Create Indirect Data Forwarding Tunnel Request
6a . Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
8. Create Indirect Data Forwarding Tunnel Request
8a. Create Indirect Data Forwarding Tunnel Response
Figure 119: Successful UTRAN to LTE Inter RAT HO for a single RAB
(Preparation Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by MME to
SGSN). Forward Relocation Request include the list of all the E-RABs to be established. Preparation phase
is followed by the Execution Phase (call flow below)
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Source
Target
Serving GW Serving GW
PDN
GW
HSS
Uplink and Downlink User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
1. Relocation Command
2. HO from UTRAN Command
4. E-UTRAN Access Procedures
5. HO to E-UTRAN Complete
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
Sending of
uplink data
possible
6. Handover Notify
7. Forward Relocation Complete Notification
7a. Forward Relocation Complete Acknowledge
8. Modify Bearer Request
For Serving GW relocation Steps 8, 9 and 10,
and the following User Plane path, will be
handled by Target Serving GW
(A)
(B)
12a. Delete Session Response
13. Delete Indirect Data Forwarding Tunnel Request
13a. Delete Indirect Data Forwarding Tunnel Response
14. Delete Indirect Data Forwarding Tunnel Request
14a. Delete Indirect Data Forwarding Tunnel Response
Figure 120: Successful UTRAN to LTE Inter RAT HO for a single RAB
(Execution Phase)
Note: This call flow covers the Execution Phase (Until UTRAN to LTE Inter RAT HO is successfully
completed)
6.2.6.1.4.2 Successful UTRAN to LTE Inter RAT Handover for multiple RABs
Test Name:
Reference:
Test Objective:
Validate the successful inter RAT Handover for a UE with multiple RABs
from UTRAN to LTE
Pre-Test Conditions:
UE is operating in the UTRAN network
UE has established at least 2 RABs
Test Procedure:
Initiate data transfer of a big file over each RAB
Trigger an inter RAT Handover for LTE
Verify that the data transfer continue for the two RABs after the inter RAT HO is
completed
Expected Results:
Verify that:
Validate that during the preparation phase in the 3G part:
o RNC sends a Relocation Request to 3G-SGSN
o 3G-SGSN forwards the relocation request to MME
MME sends a S1-AP Handover Request to eNodeB; The Handover Request will
present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup
List IE group contains all the RAB-IDs
eNodeB sends a S1-AP Handover Request Acknowledge containing the same ERABs Id inside the E-RABs Admitted List IE
o After that a Forward Relocation Response is sent by MME to 3G-SGSN
o Relocation Command is sent from 3G-SGSN to source RNC
eNodeB sends a S1-AP Handover Notify to MME
o MME sends a Forward Relocation Complete Notification to 3G-SGSN
o 3G-SGSN acknowledges by sending back a Forward Relocation Ack to
MME
There is a Tracking Area Update procedure from UE->eNodeB->MME
After that, a Iu Release procedure between source RNC and 3G-SGSN shall be
successfully performed
Validate that the data is still ongoing via E-UTRAN for each E-RAB and no
resource is hold by the UTRAN network
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Serving GW
Target
Serving GW
PDN
GW
HSS
1. Handover Initiation
2. Relocation Required
5. Handover Request
5a. Handover Request Acknowledge
6 . Create Indirect Data Forwarding Tunnel Request
6a . Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
8. Create Indirect Data Forwarding Tunnel Request
8a. Create Indirect Data Forwarding Tunnel Response
Figure 121: Successful UTRAN to LTE Inter RAT HO for Multiple RABs
(Preparation Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by MME to
SGSN). Handover Request will include the list of all the E-RABs to be established, and Handover Request
Ack will include the list of all the E-RABs successfully established and, if occurs, the list of E-RABs failed to
be set up. Preparation phase is followed by the Execution Phase (call flow below)
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Source
Target
Serving GW Serving GW
PDN
GW
HSS
Uplink and Downlink User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
1. Relocation Command
2. HO from UTRAN Command
4. E-UTRAN Access Procedures
5. HO to E-UTRAN Complete
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
Sending of
uplink data
possible
6. Handover Notify
7. Forward Relocation Complete Notification
7a. Forward Relocation Complete Acknowledge
8. Modify Bearer Request
For Serving GW relocation Steps 8, 9 and 10,
and the following User Plane path, will be
handled by Target Serving GW
(A)
(B)
12a. Delete Session Response
13. Delete Indirect Data Forwarding Tunnel Request
13a. Delete Indirect Data Forwarding Tunnel Response
14. Delete Indirect Data Forwarding Tunnel Request
14a. Delete Indirect Data Forwarding Tunnel Response
Figure 122: Successful UTRAN to LTE Inter RAT HO for Multiple RABs
(Execution Phase)
Note: This call flow covers the Execution Phase (Until UTRAN to LTE Inter RAT HO is successfully
completed)
Reference:
Test Objective:
Validate the call flow for an unsuccessful Inter RAT HO for a UE due to
no resources at the eNodeB
Pre-Test Conditions:
UE is operating in the UTRAN network
UE has established at least 1 RAB
Configure eNodeB to present an overload situation
Test Procedure:
Initiate data transfer of a big file over each RAB
Trigger an inter RAT Handover for LTE
Verify that the inter RAT HO fails but that the data transfer does not stop due to
this failure.
Expected Results:
Verify that:
Validate that during the preparation phase in the 3G part:
o RNC sends a Relocation Request to 3G-SGSN
o 3G-SGSN forwards the relocation request to MME
MME sends a S1-AP Handover Request to eNodeB; The Handover Request will
present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup
List IE group contains all the RAB-IDs
eNodeB sends a S1-AP Handover Failure with a Cause IE Set to No Radio
Resources Available at Target Cell
After this failure reception, validate:
o MME sends a Forward Relocation Complete Notification to 3G-SGSN
o 3G-SGSN sends a Relocation Preparation Failure to source RNC
Validate that, despite of the Inter RAT HO failure, the data is still ongoing via
UTRAN as far as RF signal quality allows it.
UE
Source
RNC
Target
eNodeB
Source SGSN
Target MME
Source
Serving GW
Target
Serving GW
PDN
GW
HSS
Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)
1. Handover Initiation
2. Relocation Required
5. Handover Request
6. Handover Failure
7. Delete Session Request
7a. Delete Session Response
8. Forward Relocation Response (Reject)
9. Relocation Preparation Failure