Download as pdf or txt
Download as pdf or txt
You are on page 1of 213

Long Term Evolution - Evolved Packet Core

S1 Interface Conformance Test Plan

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

6.2.4.3.1 Normal Tracking area Update ................................................................................... 103


6.2.4.3.2 Normal Tracking area Update with bearer establishment requested ...................... 105
6.2.4.3.3 Combined Tracking and Location Area Update ........................................................ 107
6.2.4.3.4 Combined Tracking and Location Area Update with IMSI attach ............................. 109
6.2.4.3.5 Combined Tracking and Location Area Update with bearer establishment requested

111
6.2.4.3.6 Periodic Tracking area Update .................................................................................. 113
6.2.4.3.7 Tracking Area Update rejected due to No EPS Bearer context activated ............. 115
6.2.4.3.8 Tracking Area Update rejected due to implicitly detached ................................... 117
6.2.4.4 Paging .......................................................................................................................... 119
6.2.4.4.1 Paging with Paging DRX IE ........................................................................................ 119
6.2.4.4.2 Paging without Paging DRX IE ................................................................................... 120
6.2.4.5 Idle to Active Mode (Service Request) ........................................................................ 121
6.2.4.5.1 Successful Service Request invoked when the UE receives a paging request with CN
domain indicator set to PS from the network in ECM-Idle mode (Single bearer) ................... 121
6.2.4.5.2 Successful Service Request invoked when the UE receives a paging request with CN
domain indicator set to PS from the network in ECM-Idle mode (Multiple bearers) .............. 123
6.2.4.5.3 Successful Service Request invoked when the UE has pending user data to be sent in
ECM-Idle mode (Single Bearer) ................................................................................................... 125
6.2.4.5.4 Successful Service Request invoked when the UE has pending user data to be sent in
ECM-Idle mode (Multiple Bearers) .............................................................................................. 127
6.2.4.5.5 Successful Service Request invoked when the UE has uplink signaling pending in
ECM-Idle mode ............................................................................................................................ 129
6.2.4.5.6 Successful Service Request invoked by 1xCS fallback when the UE is in Idle mode and
has a mobile originating 1xCS fallback request ........................................................................... 131
6.2.4.5.7 Successful Service Request invoked by 1xCS fallback when the UE is in Active mode
and has a mobile originating 1xCS fallback request .................................................................... 133
6.2.4.5.8 Successful Initial UE message with Emergency Flag enabled ................................... 135
6.2.5 USER PLANE PROTOCOL AND DATA TRANSFER TEST CASES ......................................................... 136
6.2.5.1.1 User Plane Control Test Cases .................................................................................. 136
6.2.5.1.1.1 GTP-U echo mechanism ......................................................................................... 136
6.2.5.1.1.2 GTP-U message End of Marker ........................................................................... 137
6.2.5.1.1.3 Graceful Error Indication handling by eNodeB ...................................................... 139
6.2.5.1.1.4 Graceful Error Indication handling by S-GW .......................................................... 140
6.2.5.1.2 Data Transfer on Default Bearer ............................................................................... 142
6.2.5.1.3 Data Transfer on Dedicated Bearer Test Cases ........................................................ 144
6.2.5.1.3.1 Successful Data Transfer with non-GBR Service and AM Mode ............................ 144
6.2.5.1.3.2 Successful Data Transfer with non-GBR Service and UM Mode ............................ 146
6.2.5.1.3.3 Successful Data Transfer with GBR Service and AM Mode ................................... 148
6.2.5.1.3.4 Successful Data Transfer with GBR Service and UM Mode ................................... 150
6.2.6 MOBILITY TEST CASES .......................................................................................................... 152
6.2.6.1.1 Intra-System Handover ............................................................................................. 152
6.2.6.1.1.1 X2 Based Handover ................................................................................................ 152
6.2.6.1.1.1.1 Successful HO with single E-RAB via X2 interface ............................................... 152
6.2.6.1.1.1.2 Successful HO with single E-RAB via X2 interface with Ciphering ...................... 155
6.2.6.1.1.1.3 Successful HO with multiple E-RABs via X2 interface ......................................... 157
6.2.6.1.1.1.4 Partially Successful HO with multiple E-RABs via X2 interface ........................... 160
6.2.6.1.1.1.5 Unsuccessful HO via X2 interface due to EPC Failure ......................................... 162
6.2.6.1.1.2 S1 Based Handover ................................................................................................ 164

6.2.6.1.1.2.1 Successful S1 HO with single E-RAB .................................................................... 164


6.2.6.1.1.2.2 Successful S1 HO with multiple E-RABs .............................................................. 166
6.2.6.1.1.2.3 Partially Successful S1 HO with multiple E-RABs ................................................ 168
6.2.6.1.1.2.4 Unsuccessful S1 based HO due to fail on MME-target eNodeB connectivity ..... 171
6.2.6.1.1.2.5 Unsuccessful S1 based HO due to not common ciphering algorithm ................. 173
6.2.6.1.1.2.6 Unsuccessful S1 based HO due to no resources available at target eNodeB ..... 175
6.2.6.1.2 Inter-System Handover ............................................................................................. 177
6.2.6.1.3 LTE to UTRAN Inter RAT Handover ........................................................................... 177
6.2.6.1.3.1 Successful LTE to UTRAN HO for a single E-RAB .................................................... 177
6.2.6.1.3.2 Successful LTE to UTRAN HO for multiple E-RABs ................................................. 180
6.2.6.1.3.3 LTE to UTRAN HO failure due to connectivity issues ............................................. 183
6.2.6.1.3.4 LTE to UTRAN HO failure due to not resources at NodeB ..................................... 184
6.2.6.1.3.5 LTE to UTRAN CS-Fallback: Inter RAT Handover triggered by Mobile Originated Call,
UE in Idle Mode ........................................................................................................................... 186
6.2.6.1.3.6 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile Terminated Call, UE in
Idle mode 189
6.2.6.1.3.7 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile Originated Call, UE in
Active Mode 194
6.2.6.1.3.8 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile Terminated Call, UE in
Active Mode 197
6.2.6.1.3.9 LTE to UTRAN SRVCC: Inter RAT Handover for VoIP Call ....................................... 202
6.2.6.1.3.10 LTE to UTRAN SRVCC: Inter RAT Handover for Data Transfer and VoIP Call ....... 204
6.2.6.1.4 UTRAN to LTE Inter RAT Handover ........................................................................... 206
6.2.6.1.4.1 Successful UTRAN to LTE Inter RAT Handover for a single RAB ............................. 206
6.2.6.1.4.2 Successful UTRAN to LTE Inter RAT Handover for multiple RABs .......................... 209
6.2.6.1.4.3 UTRAN to LTE Inter RAT Handover failure due to no resources at the eNodeB .... 212

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 44: Successful E-RAB establishment for single E-RAB....................................... 68


Figure 45: Successful E-RAB establishment for single E-RAB with UE Maximum
Aggregate IE included .............................................................................................. 70
Figure 46: Successful E-RAB establishment for Multiple E-RABs ................................. 71
Figure 47: Successful E-RAB modification for single E-RAB ........................................ 73
Figure 48: Successful E-RAB Modification for multiple E-RABs .................................. 74
Figure 49: Successful and Unsuccessful E-RAB Modification for Multiple E-RABs ..... 76
Figure 50: E-RAB Release Initiated by MME .................................................................. 77
Figure 51: E-RAB Release initiated by eNodeB .............................................................. 79
Figure 52: Successful Dedicated Bearer Activation initiated by the network .................. 81
Figure 53: Successful Bearer Activation initiated by the UE ........................................... 83
Figure 54: Successful Bearer Activation during Attach ................................................... 85
Figure 55: PGW Initiated Bearer Modification with QoS Update ................................... 86
Figure 56: HSS initiated Subscriber QoS Modification ................................................... 87
Figure 57: Network Initiated Bearer Modification without QoS ...................................... 89
Figure 58: UE Requested Bearer Modification Accepted by the Network ...................... 91
Figure 59: UE Requested Bearer Modification without QoS Update accepted by the
Network..................................................................................................................... 93
Figure 60: PGW Initiated Dedicated Bearer Deactivation ............................................... 94
Figure 61: MME initiated Dedicated Bearer Deactivation ............................................... 96
Figure 62: UE initiated Dedicated Bearer Deactivation ................................................... 97
Figure 63: UE/eNodeB Context Release initiated due to UE inactivity with single bearer
established ................................................................................................................. 99
Figure 64: UE/enodeB Context Release initiated due to UE inactivity with multiple
bearers established .................................................................................................. 101
Figure 65: UE Context Release due to Radio connection with UE lost ......................... 102
Figure 66: Normal Tracking Area Update ...................................................................... 104
Figure 67: Normal Tracking area Update with bearer establishment requested ............. 106
Figure 68: Combined Tracking and Location Area Update............................................ 108
Figure 69: Combined Tracking and Location Area Update with IMSI attach ............... 110
Figure 70: Combined Tracking and Location Area Update with bearer establishment
requested ................................................................................................................. 112
Figure 71: Periodic Tracking area Update ...................................................................... 114
Figure 72: Tracking Area Update rejected due to "No EPS Bearer context activated" .. 116
Figure 73: Tracking Area Update rejected due to "implicitly detached"........................ 118
Figure 74: Paging with Paging DRX IE ......................................................................... 119
Figure 75: Paging without Paging DRX IE .................................................................... 120
Figure 76: Successful Service Requested when UE receives a pacging request with CN
Domain set to "PS" (Singel bearer) ........................................................................ 122
Figure 77: Successful Service Requested when UE receives a paging request with CN
Domain indicator set to "PS" (Multiple bearers) .................................................... 124
Figure 78: Successful Service Request when UE has pending user data to be sent (Single
Bearer)..................................................................................................................... 126
Figure 79: Successful Service Request when the UE has pending user to be sent (Multiple
Bearers) ................................................................................................................... 128
Figure 80: Successful Service Request when UE has uplink signaling pending in Idle
Mode ....................................................................................................................... 130

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

Technical Specification Group Radio Access Network; Evolved


Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)

[2]

3GPP TS 29.281
General

Technical Specification Group Core Network and Terminals;


Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)

[3]

3GPP TS 36.300

Technical Specification Group Radio Access Network; Evolved


Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall
description; Stage 2

[4]

3GPP TS 23.401
General

Technical Specification Group Services and System Aspects;


Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access

[5]

3GPP TS 36.331

Technical Specification Group Radio Access Network; Evolved


Universal Terrestrial Radio Access (E-UTRAN); Radio Resource
Control (RRC) Protocol Specification

[6]

3GPP TS 23.009

Technical Specification Group Core Network and Terminals;


Handover procedures

[7]

3GPP TS 24.301

Technical Specification Group Core Network and Terminals;


Non-Access-Stratum (NAS) protocol for Evolved Packet System
(EPS); Stage 3

[8]

3GPP TS 24.008
Mobile

Technical Specification Group Core Network and Terminals;


radio interface Layer 3 specification; Core network protocols;
Stage 3

3 Abbreviations
AS

Access Stratum

BC

Broadcast

BSC

Base Station Controller

BM-SC

Broadcast-Multicast Service Centre

BSS

Base Station Sub-system

BTS

Base Transceiver Station

CC

Call Control

CDMA

Code Division Multiple Access

CSG

Closed Subscriber Group

CN

Core Network

CS

Circuit Switched

CSFB

CS Fallback

DL

Downlink

DRX

Discontinuous Reception

ECGI

E-UTRAN Cell Global Identifier

E-DCH

Enhanced Dedicated Channels

E-RAB

E-UTRAN Radio Access Bearer

eNB

E-UTRAN NodeB

EP

Elementary Procedure

EPC

Evolved Packet Core

EPS

Evolved Packet System

E-UTRAN

Evolved UTRAN

GBR

Guaranteed Bit Rate

GERAN

GSM/EDGE Radio Access Network

GGSN

Gateway GPRS Support Node

GPRS

General Packet Radio Service

GSM

Global System for Mobile communications

GTP

GPRS Tunnelling Protocol

GTP-U

GPRS Tunnelling Protocol-User plane

GUMMEI

Globally Unique MME Identifier

GUTI

Globally Unique Temporary UE Identity

GW

Gateway

HeNB

Home E-UTRAN NodeB

HFN

Hyper Frame Number

HRPD

High Rate Packet Data

HLR

Home Location Register

HSDPA

High Speed Downlink Packet Access

HSS

Home Subscriber Server

HSUPA

High Speed Uplink Packet Access

HO

Handover

ID

Identifier

IE

Information Element

IETF

Internet Engineering Task Force

IMSI

International Mobile Subscriber Identity

IOT

Interoperability Test

IP

Internet Protocol

LAI

Location Area Identifier

LTE

Long Term Evolution

MBMS

Multimedia Broadcast Multicast Service

MM

Mobility Management

MME

Mobility Management Entity

MMI

Man Machine Interface

MO

Mobile Originated

MOC

Mobile Originated Call

MOCN

Multi Operator Core Network

MS

Mobile Station

MSC

Mobile services Switching Center

MT

Mobile Terminated

MTC

Mobile Terminated Call

NAS

Non Access Stratum

NNSF

NAS Node Selection Function

NRT

Non-Real Time

O&M

Operation and Maintenance

PDN

Packet Data Network

PDCP

Packet Data Convergence Protocol

PDP

Packet Data Protocol

PDU

Protocol Data Unit

P-GW

PDN Gateway

PLMN

Public Land Mobile Network

PS

Packet Switched

PSTN

Public Switched Telephone Network

PTM

Point To multipoint

P-TMSI

Packet TMSI

PTP

Point To Point

QoS

Quality of Service

RAB

Radio Access Bearer

RAC

Routing Area Code

RAI

Routing Area Identifier

RFCI

RAB subFlow Combination Indicator

RIM

RAN Information Management

RLC

Radio Link Control

RNC

Radio Network Controller

RRC

Radio Resource Control

RT

Real Time

SAP

Service Access Point

SAPI

Service Access Point Identifier

SCTP

Stream Control Transmission Protocol

SGSN

Serving GPRS Support Node

S-GW

Serving Gateway

SMS

Short Message Service

SN

Sequence Number

SRVCC

Single Radio Voice Call Continuity

S-TMSI

S-Temporary Mobile Subscriber Identity

TAI

Tracking Area Identity

TCP

Transmission Control Protocol

TE

Terminal Equipment

TEID

Tunnel Endpoint Identifier

TFT

Traffic Flow Template

TI

Transaction Identifier

TMSI

Temporary Mobile Subscriber Identity

UDP

User Datagram Protocol

UE

User Equipment

UE-AMBR

UE-Aggregate Maximum Bit Rate

UL

Uplink

UMTS

Universal Mobile telecommunication System

UP

User Plane

USIM

Universal Subscriber Identity Module

UTRAN

UMTS Terrestrial Radio Access Network

VLR

Visitor Location Register

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

Figure 1 shows the S1-MME interface protocol stack.

S1-AP

S1-AP

SCTP

SCTP

IP

IP

L2

L2

L1

L1

HeNB

S1-MME

Figure 1: S1 Interface Protocol Stack towards MME

MME

Figure 2 shows the S1-U interface protocol stack.

GTP-U

GTP-U

UDP

UDP

IP

IP

L2

L2

L1

L1

HeNB

S1-U

S-GW

Figure 2: S1 Interface Protocol Stack towards 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.

5.1 Network & Interface Configuration (Overview)


Figure 3 depicts the Network Configuration for regular test cases.

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

Figure 3: Network Configuration for regular test cases

Figure 4 depicts the Network Configuration for Intra-RAT HO test cases.

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

Figure 4: Network Configuration for intra-RAT HO Test Cases


Figure 5 depicts the Network Configuration for Inter-RAT HO test cases.

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

Figure 5: Network Configuration for Inter-RAT HO Test Cases

5.2 Network Elements Software Version


Network
Element

Software Version

eNodeB
MME
SGW
PGW
HSS
PCRF
HLR (3G)
SGSN (3G)

5.3 Test Equipment


The following test equipment will be required in order to carry out the tests defined in this
document and verify the results:

Item/Tool
Analyzer
Simulator
Mobiles
Others

Name/Model

Detailed Test Cases

6.1 Management, Tracing and Location Report Test Cases


6.1.1 Management Procedures over SCTP
6.1.1.1 S1 Setup between MME and eNodeB in a single PLMN configuration
6.1.1.1.1 Successful S1 Setup
Test Name:

Successful establishment of SCTP association and Path Heartbeat in a


single PLMN Configuration

References:

TS 36.413, Section 8.7.3.2

Test Objective:

Verify the successful establishment of the SCTP and S1 connection


between eNodeB and MME as well as the periodic path heartbeat to
monitor the link

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

Figure 6: Setup Procedure Successful Operation

6.1.1.1.2 Unsuccessful S1 Setup


Test Name:

Unsuccessful establishment of SCTP association between eNodeB and


MME in a single PLMN Id Configuration

References:

TS 36.413, Section 8.7.3.3

Test Objective:

Verify the the graceful failure of S1 setup establishment between eNodeB


and MME

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

Figure 7: S1 Setup Procedure - Unsuccessful Operation

6.1.1.2 S1 Setup between MME and eNodeB in a multiple PLMN


configuration (MOCN configuration)
6.1.1.2.1 Successful S1 Setup

Test Name:

Successful establishment of SCTP association and Path Heartbeat in a


multiple PLMN Configuration

References:

TS 36.413, Section 8.7.3.2

Test Objective:

Verify the successful establishment of the SCTP and S1 connection


between eNodeB and MME as well as the periodic path heartbeat to
monitor the link in a MOCN configuration

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

Figure 8: S1 Setup Procedure: Successful Operation

6.1.1.2.2 Unsuccessful S1 Setup


Test Name:

Unsuccessful establishment of SCTP association between eNodeB and


MME in a multiple PLMN Id Configuration

References:

TS 36.413, Section 8.7.3.3

Test Objective:

Verify the the graceful failure of S1 setup establishment between eNodeB


and MME

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

Figure 9: S1 Setup Procedure: Unsuccessful Operation

6.1.1.3 S1 Configuration Update (MME Initiated)


6.1.1.3.1 Successful S1 MME Configuration Update
Test Name:

Successful MME Configuration Update

References:

TS 36.413, Section 8.7.5.2

Test Objective:

Validate the successful application level configuration data update when


initiated by MME

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

MME CONFIGURATION UPDATE


MME CONFIGURATION UPDATE ACKNOWLEDGE

Figure 10: MME Configuration Update Procedure: Successful Operation

6.1.1.3.2 Unsuccessful S1 MME Configuration Update


Test Name:

Unsuccessful MME Configuration Update

References:

TS 36.413, Section 8.7.5.3

Test Objective:

Validate the graceful unsuccessful application level configuration data


update when initiated by MME

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

MME CONFIGURATION UPDATE


MME CONFIGURATION UPDATE FAILURE

Figure 11: MME Configuration Update: Unsuccessful Operation

6.1.1.4 S1 Configuration Update (eNodeB Initiated)


6.1.1.4.1 Successful S1 Configuration Update (eNodeB Initiated)
Test Name:

Successful eNodeB Configuration Update

References:

TS 36.413, Section 8.7.4.2

Test Objective:

Validate the successful application level configuration data update


between eNodeB and MME when is initiated by eNodeB

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

ENB CONFIGURATION UPDATE


ENB CONFIGURATION UPDATE ACKNOWLEDGE

Figure 12: ENB Configuration Update Procedure: Successful Operation

6.1.1.4.2 Unsuccessful S1 Configuration Update (eNodeB Initiated)


Test Name:

Unsuccessful eNodeB Configuration Update

References:

TS 36.413, Section 8.7.4.3

Test Objective:

Validate the graceful unsuccessful application level configuration data


update between eNodeB and MME when is initiated by eNodeB

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

ENB CONFIGURATION UPDATE


ENB CONFIGURATION UPDATE FAILURE

Figure 13: ENB Configuration Update Procedure: Unsuccessful Operation

6.1.1.5 S1 Reset Procedures


6.1.1.5.1 S1 Reset initiated by eNodeB

Test Name:

S1 Reset initiated by eNodeB

References:

TS 36.413, Section 8.7.1.2.2

Test Objective:

Validate the successful reset initiated by eNodeB and the consequent


initialization of the MME

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

Figure 14: Reset Procedure Initiated From the E-UTRAN Successful


Operation

6.1.1.5.2 S1 Reset initiated by MME

Test Name:

S1 Reset initiated by MME

References:

TS 36.413, Section 8.7.1.2.1

Test Objective:

Validate the successful reset initiated by MME and the consequent


initialization of the eNodeB

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

6.1.1.6 S1 Recovery after nodes failure


6.1.1.6.1 S1 Recovery after eNodeB restart
Test Name:

S1 recovery after eNodeB restart

References:

TS 36.413, Section 8.7.1.2.2

Test Objective:

Validate the S1 recovers successfully from the unexpected restart of the


eNodeB

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

Figure 16: Reset Procedure Initiated From the E-UTRAN Successful


Operation

6.1.1.6.2 S1 Recovery after MME restart


Test Name:

S1 recovery after MME restart

References:

TS 36.413, Section 8.7.1.2.1

Test Objective:

Validate the S1 recovers successfully from the unexpected restart of the


MME

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:

S1 recovery after S-GW restart while data transfer is ongoing

References:

TS 36.413, Section 8.3.3.2

Test Objective:

Validate the S1-U recovers successfully from the unexpected restart of


the S-GW

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

UE CONTEXT RELEASE COMMAND


UE CONTEXT RELEASE COMPLETE
UE CONTEXT is successfully established

Figure 18: UE Context Release Procedure Successful Operation

6.1.1.6.4 S1 Recovery from S1 failure due to physical connections lost

Test Name:

S1 recovery from S1 failure due to transmission network failure (physical


connections lost)

References:

TS 36.413, Section 8.7.3.2

Test Objective:

Validate the S1 recovers successfully from a physical connection failure

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

Figure 19: Setup Procedure Successful Operation

6.1.2 Trace and Location Reporting Procedures


6.1.2.1 Trace Procedures
6.1.2.1.1 Trace Start
6.1.2.1.1.1 Trace Start supporting S1 interface
Test Name:

MME requests the eNodeB to start a trace supporting S1 interface and


minimum depth

References:

TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2

Test Objective:

Validate that MME is able to request the eNodeB to start a trace session
that supports S1 interface and minimum depth

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

Figure 20: Trace Start Procedure

eNodeB

MME

CELL TRAFFIC TRACE

Figure 21: Cell Traffic Trace Procedure - Successful Operation


eNB

MME

TRACE FAILURE INDICATION

Figure 22: Trace Failure Indication Procedure

6.1.2.1.1.2 Trace Start supporting X2 interface


Test Name:

MME requests the eNodeB to start a trace supporting X2 interface and


minimum depth

References:

TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2

Test Objective:

Validate that MME is able to request the eNodeB to start a trace session
that supports X2 interface and minimum depth

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

Figure 23: Trace Start Procedure

eNodeB

MME

CELL TRAFFIC TRACE

Figure 24: Cell Traffic Trace Procedure - Successful Operation


eNB

MME

TRACE FAILURE INDICATION

Figure 25: Trace Failure Indication Procedure

6.1.2.1.2 Deactivate Trace

Test Name:

MME requests the eNodeB to stop the trace session

References:

TS 36.413, Sections 8.10.3.2 & 8.10.2.2

Test Objective:

Validate that MME is able to request the eNodeB to stop the trace
session

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

Figure 26: Deactivate Trace

eNB

MME

TRACE FAILURE INDICATION

Figure 27: Trace Failure Indication Procedure

6.1.2.2 Location Reporting Procedures


6.1.2.2.1 Successful location reporting for a direct report of the UE location
Test Name:

Location Reporting Control sent to Request a direct report for a UE


location

References:

TS 36.413, Sections 8.11.1.2 & 8.11.2.2

Test Objective:

Validate that MME is able to request the eNodeB to report where the UE
is currently located

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

LOCATION REPORTING CONTROL

Figure 28: Location Reporting Control Procedure - Successful Operation

eNB

MME

LOCATION REPORT FAILURE


INDICATION

Figure 29: Location Report Failure Indication Procedure

6.1.2.2.2 Successful location reporting for serving cell change


Test Name:

Successful location reporting for serving cell change

References:

TS 36.413, Sections 8.11.3.2, 8.11.1.2, & 8.11.2.2

Test Objective:

Validate that MME is able to request the eNodeB to report whenever a


UE changes cells, and the eNodeB sends a location report with the
correct service area identifier when that event happens

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

LOCATION REPORTING CONTROL

Figure 30: Location Reporting Control Procedure - Successful Operation

eNB

MME

LOCATION REPORT

Figure 31: Location Report Procedure - Successful Operation

eNB

MME

LOCATION REPORT FAILURE


INDICATION

Figure 32: Location Report Failure Indication

6.1.2.2.3 Successful cancellation of location reporting for serving cell


change
Test Name:

Successful cancellation of location reporting for serving cell change

References:

TS 36.413, Sections 8.11.1.2 & 8.11.2.2

Test Objective:

Validate that MME is able to request the eNodeB to stop reporting


whenever a UE changes cells, and the eNodeB sends a location report
with the correct service area identifier when that event happens

Note:

This is an optional requirement (not mandatory feature as per applicable


specs)

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

LOCATION REPORTING CONTROL

Figure 33: Location Reporting Control Procedure - Successful Operation

eNB

MME

LOCATION REPORT FAILURE


INDICATION

Figure 34: Location Report Failure Indication Procedure

6.2 Functional Test Cases


6.2.1 Attach/Detach
6.2.1.1 Successful EPS Attach with UE unknown in MME and no Ciphering
Test Name:

Successful EPS Attach with the UE unknown in MME and no Ciphering

References:

3GPP TS 23.401, Section 5.3.2.1

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

Figure 35: Successful EPS Attach with UE unknown in MME and No


Ciphering

6.2.1.2 Successful EPS Attach with UE unknown in MME and Ciphering


Test Name:

Successful EPS Attach with the UE unknown in MME and Ciphering

References:

3GPP TS 23.401, Section 5.3.2.1

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

6.2.1.3 Successful EPS Attach procedure with UE known in MME and no


Ciphering
Test Name:

Successful EPS Attach with the UE known in MME and no Ciphering

References:

3GPP TS 23.401, Section 5.3.2.1

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

6.2.1.4 Successful EPS Attach procedure with UE known in MME with


Ciphering
Test Name:

Successful EPS Attach with the UE known in MME and Ciphering

References:

3GPP TS 23.401, Section 5.3.2.1

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

6.2.1.5 Successful EPS Attach procedure with IMSI


Test Name:

Successful EPS Attach with IMSI

References:

3GPP TS 23.401, Section 5.3.2.1

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

Figure 39: Successful EPS Attach with IMSI

6.2.1.6 Unsuccessful EPS Attach due to IMSI unknown on HSS


Test Name:

Unsuccessful EPS Attach due to IMSI unknown on HSS

References:

3GPP TS 23.401, Section 5.3.2.1


3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3
3GPP TS 24.301, Section 5.5.1.2.2, 5.4.4.2

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

Figure 40: Unsuccessful EPS Attach due to IMSI unknown on HSS

6.2.1.7 Successful EPS Detach initiated by UE


Test Name:

Successful EPS Detach UE initiated

References:

3GPP TS 23.401, Section 5.3.8.2.1


3GPP TS 36.413, Section 8.6.2.3, 8.6.2.2, 8.3.3.2
3GPP TS 24.301, Section 5.5.2.2.1

Test Objective:

Validate the successful detach procedure when is initiated by the UE

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.

Figure 41: Successful EPS detach initiated by UE

6.2.1.8 Successful EPS Detach initiated by UE due to switch off


Test Name:

Successful EPS Detach UE initiated

References:

3GPP TS 23.401, Section 5.3.8.2.1


3GPP TS 36.413, Section 8.6.2.3, 8.3.3.2

Test Objective:

Validate the successful detach procedure when is initiated by the UE

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.

Figure 42: Successful EPS Detach initiated by UE due to switch off

6.2.1.9 Successful EPS Detach initiated by MME


Test Name:

Successful EPS Detach MME initiated

References:

3GPP TS 23.401, Section 5.3.8.3


3GPP TS 24.301, 5.5.2.3.1
3GPP TS 36.413, Section 8.3.3.2

Test Objective:

Validate the successful detach procedure when is initiated by the MME

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.

Figure 43: Successful EPS Detach initiated by MME

6.2.2 E-RAB Protocol Procedures


6.2.2.1 E-RAB Setup
6.2.2.1.1 Successful E-RAB establishment
Test Name:

Successful Establishment of single E-RAB

References:

3GPP TS 36.413, Section 8.2.1.2

Test Objective:

Validate the possibility to establish an E-RAB for a UE

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.

Figure 44: Successful E-RAB establishment for single E-RAB

6.2.2.1.2 Successful E-RAB establishment UE Aggregate Maximum Bit


Rate IE is included
Test Name:

Successful Establishment of single E-RAB when UE Aggregate


Maximum Bit Rate IE is contained

References:

3GPP TS 36.413, Section 8.2.1.2

Test Objective:

Validate the possibility to establish an E-RAB for a UE when UE


Aggregate Maximum Bit Rate IE is included

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.

Figure 45: Successful E-RAB establishment for single E-RAB with UE


Maximum Aggregate IE included

6.2.2.1.3 Successful E-RAB establishment for multiple E-RABs


Test Name:

Successful establishment of Multiple E-RABs

References:

3GPP TS 36.413, Section 8.2.1.2

Test Objective:

Validate the possibility to establish multiple E-RAB for a UE

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

Figure 46: Successful E-RAB establishment for Multiple E-RABs

6.2.2.2 E-RAB Modify


6.2.2.2.1 Successful E-RAB modification of single E-RAB
Test Name:

Successful E-RAB modification of single E-RAB

References:

3GPP TS 36.413, Section 8.2.2.2

Test Objective:

Validate the possibility to modify an existing E-RAB

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.

Figure 47: Successful E-RAB modification for single E-RAB

6.2.2.2.2 Successful E-RAB modification for multiple E-RABs


Test Name:

Successful E-RAB modification of multiple E-RABs

References:

3GPP TS 36.413, Section 8.2.2.2

Test Objective:

Validate the possibility to modify existing E-RABs

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.

Figure 48: Successful E-RAB Modification for multiple E-RABs

6.2.2.2.3 Successful and Unsuccessful E-RAB modification for multiple ERABs

Test Name:

Successful and Unsuccessful E-RAB modification of multiple E-RABs

References:

3GPP TS 36.413, Section 8.2.2.2

Test Objective:

Validate the possibility of a graceful partial modification of all the existing


E-RABs on a UE

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:

E-RAB Release initiated by MME

References:

3GPP TS 36.413, Section 8.2.3.2.1

Test Objective:

Validate the successful MME initiated release of an E-RAB existing on


UE

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.

Figure 50: E-RAB Release Initiated by MME

6.2.2.3.2 E-RAB Release initiated by eNodeB


Test Name:

E-RAB Release initiated by eNodeB

References:

3GPP TS 36.413, Section 8.2.3.2.2, 8.2.3.2.1

Test Objective:

Validate the successful eNodeB initiated release of an E-RAB existing on


UE

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

Figure 51: E-RAB Release initiated by eNodeB

6.2.3 EPC Bearers Functional Procedures


6.2.3.1 Dedicated bearer Activation
6.2.3.1.1 Successful Dedicated Bearer Activation initiated by the network
Test Name:

Successful Dedicated Bearer Activation initiated by the network

References:

3GPP TS 23.401, Section 5.4.1


3GPP TS 24.301, Section 6.4.2.2
3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3

Test Objective:

Validate the successful dedicated bearer activation when initiated by the


network

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)

Figure 52: Successful Dedicated Bearer Activation initiated by the network

6.2.3.1.2 Successful Dedicated Bearer Activation initiated by the UE


Test Name:

Successful Dedicated Bearer Activation initiated by the UE

References:

3GPP TS 23.401, Section 5.4.1, 5.4.5


3GPP TS 24.301, Section 6.4.2.2
3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3

Test Objective:

Validate the successful dedicated bearer activation when initiated by the


UE

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)

Figure 53: Successful Bearer Activation initiated by the UE

6.2.3.1.3 Successful Dedicated Bearer Activation during attach


Test Name:

Successful Dedicated Bearer Activation during attach

References:

3GPP TS 23.401, Annex F


3GPP TS 24.301, Section 6.4.2.2
3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3

Test Objective:

Validate the successful dedicated bearer activation during UE attach

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.

Figure 54: Successful Bearer Activation during Attach

6.2.3.2 Bearer Modification


6.2.3.2.1 Bearer Modification initiated by the EPC
6.2.3.2.1.1 PDN GW initiated bearer modification with QoS Update
Test Name:

PDN GW initiated bearer modification with QoS Update

References:

3GPP TS 23.401, 5.4.2.1


3GPP TS 24.301, Section 6.4.3.1
3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3

Test Objective:

Validate the successful bearer modification when initiated by PDN GW

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.

Figure 55: PGW Initiated Bearer Modification with QoS Update

6.2.3.2.1.2 HSS initiated Subscriber QoS Modification


Test Name:

HSS initiated bearer modification with QoS Update

References:

3GPP TS 23.401, 5.4.2.2


3GPP TS 24.301, Section 6.4.3.1
3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3

Test Objective:

Validate the successful bearer modification when initiated by HSS

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.

Figure 56: HSS initiated Subscriber QoS Modification

6.2.3.2.1.3 Network Initiated Bearer modification without Bearer QoS Update


Test Name:

Network initiated bearer modification without QoS Update

References:

3GPP TS 23.401, 5.4.2.2, 5.4.3


3GPP TS 24.301, Section 6.4.3.1
3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3

Test Objective:

Validate the successful bearer modification without bearer QoS update


by the network

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.

Figure 57: Network Initiated Bearer Modification without QoS

6.2.3.2.2 Bearer Modification initiated by the UE


6.2.3.2.2.1 UE Requested Bearer Modification accepted by the network
Test Name:

UE Requested Bearer Modification accepted by the network

References:

3GPP TS 23.401, 5.4.5, 5.4.2.1


3GPP TS 24.301, Section 6.5.4.2, 6.4.3.1
3GPP TS 36.413, Section 8.6.2.3, 8.2.2.2, 8.6.2.2

Test Objective:

Validate the successful bearer modification when initiated by the UE

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

Figure 58: UE Requested Bearer Modification Accepted by the Network

6.2.3.2.2.2 UE Requested Bearer Modification without QoS update accepted


by the network
Test Name:

UE Requested Bearer Modification without QoS update accepted by the


network

References:

3GPP TS 23.401, 5.4.5, 5.4.2.1


3GPP TS 24.301, Section 6.5.4.2, 6.4.3.1
3GPP TS 36.413, Section 8.6.2.3, 8.2.2.2, 8.6.2.2

Test Objective:

Validate the successful bearer modification without QoS update when


initiated by the UE

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

Figure 59: UE Requested Bearer Modification without QoS Update accepted


by the Network

6.2.3.3 Dedicated Bearer deactivation


6.2.3.3.1 PDN GW initiated Dedicated Bearer Deactivation
Test Name:

PDN GW initiated bearer deactivation

References:

3GPP TS 23.401, 5.4.4.1


3GPP TS 24.301, Section 6.4.4.2
3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3

Test Objective:

Validate the successful dedicated bearer deactivation when initiated by


PDN GW

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

Figure 60: PGW Initiated Dedicated Bearer Deactivation

6.2.3.3.2 MME initiated Dedicated Bearer Deactivation


Test Name:

MME initiated bearer deactivation

References:

3GPP TS 23.401, 5.4.4.2


3GPP TS 24.301, Section 6.4.4.2
3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3

Test Objective:

Validate the successful dedicated bearer deactivation when initiated by


MME

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

Figure 61: MME initiated Dedicated Bearer Deactivation

6.2.3.3.3 UE initiated Dedicated Bearer Deactivation


Test Name:

UE initiated bearer deactivation

References:

3GPP TS 23.401, 5.4.5, 5.4.4.2


3GPP TS 24.301, Section 6.5.4.2, 6.4.4.2
3GPP TS 36.413, Section 8.6.2.3, 8.2.3.2.1

Test Objective:

Validate the successful dedicated bearer deactivation when initiated by


UE

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

Figure 62: UE initiated Dedicated Bearer Deactivation

6.2.4 Idle Mode and Context Management Procedures


6.2.4.1 Active to Idle mode Transition (Context Release)
6.2.4.1.1 UE/eNodeB Context Release due to User Inactivity with a single
bearer established
Test Name:

UE/eNodeB Context Release due to User Inactivity with single bearer


established

References:

3GPP TS 23.401, 5.3.5


3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2

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

Figure 63: UE/eNodeB Context Release initiated due to UE inactivity with


single bearer established

6.2.4.1.2 UE/eNodeB Context Release due to User Inactivity with multiple


bearers established
Test Name:

UE/eNodeB Context Release due to User Inactivity with multiple bearers


established

References:

3GPP TS 23.401, 5.3.5


3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2

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.

Figure 64: UE/enodeB Context Release initiated due to UE inactivity with


multiple bearers established

6.2.4.2 UE Context Release due to radio connection with UE lost


Test Name:

UE Context Release due to radio connection with UE Lost

References:

3GPP TS 23.401, 5.3.5


3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2

Test Objective:

Validate the successful UE Context release due to radio connection with


UE lost

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

Figure 65: UE Context Release due to Radio connection with UE lost

6.2.4.3 Tracking Area Update procedures


6.2.4.3.1 Normal Tracking area Update
Test Name:

Normal Tracking Area Update

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2

Test Objective:

Validate the normal tracking update

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

Figure 66: Normal Tracking Area Update

6.2.4.3.2 Normal Tracking area Update with bearer establishment requested


Test Name:

Normal Tracking Area Update with bearer establishment requested

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.1.2

Test Objective:

Validate the successful tracking 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 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.

Figure 67: Normal Tracking area Update with bearer establishment


requested

6.2.4.3.3 Combined Tracking and Location Area Update


Test Name:

Combined Tracking and Location Area Update

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 23.272, 5.4.1
3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2

Test Objective:

Validate the successful combined tracking and location normal tracking


area update

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

Figure 68: Combined Tracking and Location Area Update

6.2.4.3.4 Combined Tracking and Location Area Update with IMSI attach
Test Name:

Combined Tracking and Location Area Update with IMSI attach

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 23.272, 5.4.1
3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2

Test Objective:

Validate the successful combined tracking and location normal tracking


area update with IMSI attach

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

6.2.4.3.5 Combined Tracking and Location Area Update with bearer


establishment requested
Test Name:

Combined Tracking and Location Area Update with bearer establishment


requested

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 23.272, 5.4.1
3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2

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

6.2.4.3.6 Periodic Tracking area Update


Test Name:

Periodic Tracking Area Update

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2

Test Objective:

Validate the successful Periodic Tracking area update

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

Figure 71: Periodic Tracking area Update

6.2.4.3.7 Tracking Area Update rejected due to No EPS Bearer context


activated
Test Name:

Tracking Area Update rejected due to No EPS Bearer context activated

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2

Test Objective:

Validate the tracking area update procedure rejected when the UE


requests an establishment of the radio access bearer for all active EPS
bearer contexts but the MME does not have the corresponding active
EPS bearer context.

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"

6.2.4.3.8 Tracking Area Update rejected due to implicitly detached


Test Name:

Tracking Area Update rejected due to implicitly detached

References:

3GPP TS 23.401, 5.3.3.2


3GPP TS 24.301, 5.5.3
3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2

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

Figure 73: Tracking Area Update rejected due to "implicitly detached"

6.2.4.4 Paging
6.2.4.4.1 Paging with Paging DRX IE
Test Name:

Paging with Paging DRX IE

References:

3GPP TS 23.401, 5.3.4.3


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.5.2, 8.6.2.1

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.

Figure 74: Paging with Paging DRX IE

6.2.4.4.2 Paging without Paging DRX IE


Test Name:

Paging without Paging DRX IE

References:

3GPP TS 23.401, 5.3.4.3


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.5.2, 8.6.2.1

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.

Figure 75: Paging without Paging DRX IE

6.2.4.5 Idle to Active Mode (Service Request)


6.2.4.5.1 Successful Service Request invoked when the UE receives a
paging request with CN domain indicator set to PS from the
network in ECM-Idle mode (Single bearer)
Test Name:

Successful Service Request invoked when the UE receives a paging


request with CN domain indicator set to PS from the network in ECMIdle Mode

References:

3GPP TS 23.401, 5.3.4.3


3GPP TS 24.301, 5.6.1, 5.6.2
3GPP TS 36.413, Section 8.5.2, 8.6.2.1, 8.3.1.2

Test Objective:

Validate the successful transfer from ECM-Idle mode to ECM-Connected


and establish the radio and S1 bearers when the network has downlink
signaling pending.

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.

Figure 76: Successful Service Requested when UE receives a pacging


request with CN Domain set to "PS" (Singel bearer)

6.2.4.5.2 Successful Service Request invoked when the UE receives a


paging request with CN domain indicator set to PS from the
network in ECM-Idle mode (Multiple bearers)
Test Name:

Successful Service Request invoked when the UE receives a paging


request with CN domain indicator set to PS from the network in ECMIdle Mode (Multiple bearers)

References:

3GPP TS 23.401, 5.3.4.3


3GPP TS 24.301, 5.6.1, 5.6.2
3GPP TS 36.413, Section 8.5.2, 8.6.2.1, 8.3.1.2

Test Objective:

Validate the successful transfer from ECM-Idle mode to ECM-Connected


and establish the radio and S1 bearers when the network has downlink
signaling pending.

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.

Figure 77: Successful Service Requested when UE receives a paging


request with CN Domain indicator set to "PS" (Multiple bearers)

6.2.4.5.3 Successful Service Request invoked when the UE has pending


user data to be sent in ECM-Idle mode (Single Bearer)
Test Name:

Successful Service Request invoked when the UE has user data to be


sent (Single Bearer)

References:

3GPP TS 23.401, 5.3.4.1


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2

Test Objective:

Validate the successful transfer from ECM-Idle mode to ECM-Connected


and establish the radio and S1 bearers when the UE has user data to be
sent in a single bearer environment

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)

6.2.4.5.4 Successful Service Request invoked when the UE has pending


user data to be sent in ECM-Idle mode (Multiple Bearers)
Test Name:

Successful Service Request invoked when the UE has user data to be


sent (Multiple Bearers)

References:

3GPP TS 23.401, 5.3.4.1


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2

Test Objective:

Validate the successful transfer from ECM-Idle mode to ECM-Connected


and establish the radio and S1 bearers when the UE has user data to be
sent in a multiple bearer environment

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)

6.2.4.5.5 Successful Service Request invoked when the UE has uplink


signaling pending in ECM-Idle mode
Test Name:

Successful Service Request invoked when the UE has signaling pending

References:

3GPP TS 23.401, 5.3.4.1


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2

Test Objective:

Validate the successful transfer from ECM-Idle mode to ECM-Connected


and establish the radio and S1 bearers when the UE has signaling
pending

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.

Figure 80: Successful Service Request when UE has uplink signaling


pending in Idle Mode

6.2.4.5.6 Successful Service Request invoked by 1xCS fallback when the


UE is in Idle mode and has a mobile originating 1xCS fallback
request
Test Name:

Successful Service Request invoked when the is in Idle mode and has a
mobile originating 1xCS fallback request from the upper layer

References:

3GPP TS 23.272, B.2.2a


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2, 8.3.2.2, 8.3.3.2

Test Objective:

Validate the successful Service Request invoked when the is in Idle


mode and has a mobile originating 1xCS fallback request from the upper
layer

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

6.2.4.5.7 Successful Service Request invoked by 1xCS fallback when the


UE is in Active mode and has a mobile originating 1xCS fallback
request
Test Name:

Successful Service Request invoked when the is in Active mode and has
a mobile originating 1xCS fallback request from the upper layer

References:

3GPP TS 23.272, B.2.2


3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.3, 8.3.4.2, 8.3.2.2, 8.3.3.2

Test Objective:

Validate the successful Service Request invoked when the is in Active


mode and has a mobile originating 1xCS fallback request from the upper
layer

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

6.2.4.5.8 Successful Initial UE message with Emergency Flag enabled


Test Name:

Successful initial UE message when UE originating a call with


Emergency Flag enabled

References:

3GPP TS 23.401, 5.3.2.1

Test Objective:

Validate the successful Initial Context Setup procedure when emergency


mode is enabled

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.

Figure 83: Successful Initial UE message with Emergency Flag enabled

6.2.5 User Plane Protocol and Data Transfer Test Cases


6.2.5.1.1 User Plane Control Test Cases
6.2.5.1.1.1 GTP-U echo mechanism
Test Name:

GTP-U echo mechanism

Reference:

TS 29.281 Section 7.2

Test Objective:

Validate the echo mechanism in both UL and DL directions

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.

Figure 84: GTP-U Echo mechanism

6.2.5.1.1.2 GTP-U message End of Marker


Test Name:

GTP-U message End of Marker

Reference:

TS 29.281 Section 7.3.2

Test Objective:

Validate that the message End of Marker is properly used during a HO

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 and uplink data


Handover preparation
Handover execution
Forwarding of data

Downlink data

Handover completion

Uplink data
1 Path Switch Request

Downlink data

2 Modify Bearer Request


3a Modify Bearer Request
3b Modify Bearer Response
4 Modify Bearer Response

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource

8. Tracking Area Update procedure

Figure 85: GTP-U message "End of Marker"

(A)

6.2.5.1.1.3 Graceful Error Indication handling by eNodeB


Test Name:

Graceful Error Indication Handling by eNodeB

Reference:

TS 23.007 section 21.6

Test Objective:

Validate the appropriate handling of the Error Indication by eNodeB from


a S-GW

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.

Figure 86: Graceful Error Indication handling by eNodeB

6.2.5.1.1.4 Graceful Error Indication handling by S-GW


Test Name:

Graceful Error Indication Handling by S-GW

Reference:

TS 23.007 section 21.7

Test Objective:

Validate the appropriate handling of the Error Indication by S-GW from a


enodeB

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.

Figure 87: Graceful Error Indication handling by SGW

6.2.5.1.2 Data Transfer on Default Bearer


Test Name:

Successful Data Transfer on Default Bearer

Reference

TS 23.401 Section 5.3.2.1

Test Objective:

Validate the successful data transfer on both of directions on default


bearer

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

5b. ME Identity Check

6. Ciphered Options Request


6. Ciphered Options Response
7. Delete Sesion Request
(E)

7. PCEF Initiated IP-CAN


Session Termination

7. Delete Session Response

(A)

8. Update Location Request


9. Cancel Location
9. Cancel Location Ack
10. Delete Session Request
10. Delete Session Response

(F)

10. PCEF Initiated IP-CAN


Session Termination

(B)

11. Update Location Ack


12. Create Session Request
13. Create Session Request
14. PCEF Initiated IP-CAN Session
Establishment/Modification

(C)

15. Create Session Response


First Downlink Data (if not handover)
16. Create Session Response
17. Initial Context Setup Request / Attach Accept
18. RRC Connection Reconfiguration
19. RRC Connection Reconfiguration Complete
20. Initial Context Setup Response
21. Direct Transfer
22. Attach Complete
First Uplink Data
23. Modify Bearer Request
23a. Modify Bearer Request
23b. Modify Bearer Response
(D)
24. Modify Bearer Response
First Downlink Data
25. Notify Request
26. Notify Response

Figure 88: Data Transfer on Default Bearer

6.2.5.1.3 Data Transfer on Dedicated Bearer Test Cases


6.2.5.1.3.1 Successful Data Transfer with non-GBR Service and AM Mode
Test Name:

Sucessful Data Transfer with non-GBR Service and AM Mode

Reference:

TS 23.401 and 36.413 and 29.281

Test Objective:

Validate the successful data transfer with non-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 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

6.2.5.1.3.2 Successful Data Transfer with non-GBR Service and UM Mode

Test Name:

Sucessful Data Transfer with non-GBR Service and UM Mode

Reference:

TS 23.401 and 36.413 and 29.281

Test Objective:

Validate the successful data transfer with non-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 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

6.2.5.1.3.3 Successful Data Transfer with GBR Service and AM Mode


Test Name:

Sucessful Data Transfer with GBR Service and AM Mode

Reference:

TS 23.401 and 36.413 and 29.281

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

6.2.5.1.3.4 Successful Data Transfer with GBR Service and UM Mode


Test Name:

Sucessful Data Transfer with GBR Service and UM Mode

Reference:

TS 23.401 and 36.413 and 29.281

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

6.2.6 Mobility Test Cases


6.2.6.1.1 Intra-System Handover
6.2.6.1.1.1 X2 Based Handover
6.2.6.1.1.1.1 Successful HO with single E-RAB via X2 interface
Test Name:

Successful HO with single E-RAB via X2 interface

Reference:

TS 23.401, section 5.5.1.1.2

Test Objective:

Validate the successful HO with single E-RAB via X2 interface. Validate


also the subsequent HO

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 and uplink data


Handover preparation
Handover execution
Forwarding of data

Downlink data

Handover completion

Uplink data
1 Path Switch Request

Downlink data

2 User Plane Update Request


3a Update Bearer Request
3b Update Bearer Response
4 User Plane Update Response

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource

8. Tracking Area Update procedure

Figure 93: Successful X2 HO with single bearer

(A)

6.2.6.1.1.1.2 Successful HO with single E-RAB via X2 interface with


Ciphering
Test Name:

Successful HO with single E-RAB via X2 interface when Ciphering is


enabled

Reference:

TS 23.401 section 5.5.1.2

Test Objective:

Validate the successful HO with single E-RAB via X2 interface when


Ciphering is enabled

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 and uplink data


Handover preparation
Handover execution
Forwarding of data

Downlink data

Handover completion

Uplink data
1 Path Switch Request

Downlink data

2 User Plane Update Request


3a Update Bearer Request
3b Update Bearer Response
4 User Plane Update Response

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource

8. Tracking Area Update procedure

Figure 94: Successful HO with single E-RAB via X2 with Ciphering

(A)

6.2.6.1.1.1.3 Successful HO with multiple E-RABs via X2 interface


Test Name:

Successful HO with multiple E-RAB via X2 interface

Reference:

TS 23.401 Section 5.5.1.1.2

Test Objective:

Validate the successful HO with multiple E-RAB via X2 interface. Validate


also the subsequent HO

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 and uplink data


Handover preparation
Handover execution
Forwarding of data

Downlink data

Handover completion

Uplink data
1 Path Switch Request

Downlink data

2 User Plane Update Request


3a Update Bearer Request
3b Update Bearer Response

(A)

4 User Plane Update Response

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource

8. Tracking Area Update procedure

Figure 95: Successful X2 HO with Multiple E-RABs


Note: Path Switch Request messages will include a list with all the E-RABs established towards the target
eNodeB

6.2.6.1.1.1.4 Partially Successful HO with multiple E-RABs via X2 interface


Test Name:

Successful HO with multiple E-RAB via X2 interface

Reference:

TS 23.401 section 5.5.1.1.2

Test Objective:

Validate the successful HO with multiple E-RAB via X2 interface.

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 and uplink data


Handover preparation
Handover execution
Forwarding of data

Downlink data

Handover completion

Uplink data
1 Path Switch Request

Downlink data

2 User Plane Update Request


3a Update Bearer Request
3b Update Bearer Response

(A)

4 User Plane Update Response

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource

8. Tracking Area Update procedure

Figure 96: Partially Successful HO via X2 interface with Multiple E-RABs


Note: Path Switch Request messages will include a list with all the E-RABs successfully established (ERABs to be switched) and the E-RABs that could not be established (E-RABs to be released) towards the
target eNodeB

6.2.6.1.1.1.5 Unsuccessful HO via X2 interface due to EPC Failure


Test Name:

Unsuccessful HO via X2 interface due to EPC failure

Reference:

TS 23.401 section 5.5.1.1.2

Test Objective:

Validate the expected call flow for an unsuccessful HO via X2 interface


due to EPC failure

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

Figure 97: Unsuccessful X2 HO Due to EPC Failure

6.2.6.1.1.2 S1 Based Handover


6.2.6.1.1.2.1 Successful S1 HO with single E-RAB
Test Name:

Successful S1 HO with Single E-RAB

Reference:

TS 23.401 section 5.5.1.2.2

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

6. eNB Status Transfer

7. MME Status Transfer


Only for Direct forwarding of data

Detach from old c ell and


synchronize to new cell
8. RRC Reconfig Complete
Downlink data

Uplink User Plane data

9. Handover Notify

10. Modify Bearer Request


Switch DL Data Path

11. Modify Bearer Response


Downlink User Plane data
12. Tracking Area Update procedure

13a. UE Context Release Command


13b. UE Context Release Complete

Figure 98: Successful S1 HO with Single E-RAB


Note: Handover Request only includes 1 E-RAB

6.2.6.1.1.2.2 Successful S1 HO with multiple E-RABs


Test Name:

Successful S1 HO with multiple E-RABs

Reference:

TS 23.401 section 5.5.1.2.2

Test Objective:

Validate the successful S1 based HO between two eNodeBs for multiple


E-RABs

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

6. eNB Status Transfer

7. MME Status Transfer


Only for Direct forwarding of data

Detach from old c ell and


synchronize to new cell
8. RRC Reconfig Complete
Downlink data

Uplink User Plane data

9. Handover Notify

10. Modify Bearer Request


Switch DL Data Path

11. Modify Bearer Response


Downlink User Plane data
12. Tracking Area Update procedure

13a. UE Context Release Command


13b. UE Context Release Complete

Figure 99: Successful S1 HO with Multiple E-RABs


Note: Handover Request includes multiple E-RABs. The Handover Request ACK will include all the E-RABs
into the admitted list (all of them were successfully established)

6.2.6.1.1.2.3 Partially Successful S1 HO with multiple E-RABs


Test Name:

Successful S1 HO with multiple E-RABs

Reference:

TS 23.401 section 5.5.1.2.2

Test Objective:

Validate the graceful behavior after a partially successful S1 based HO


between two eNodeBs for multiple E-RABs

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

6. eNB Status Transfer

7. MME Status Transfer


Only for Direct forwarding of data

Detach from old c ell and


synchronize to new cell
8. RRC Reconfig Complete
Downlink data

Uplink User Plane data

9. Handover Notify

10. Modify Bearer Request


Switch DL Data Path

11. Modify Bearer Response


Downlink User Plane data
12. Tracking Area Update procedure

13a. UE Context Release Command


13b. UE Context Release Complete

Figure 100: Partially Successful S1 HO with Multiple E-RABs


Note: Handover Request includes multiple E-RABs. The Handover Request ACK will include all the E-RABs
that were successfully established towards the target eNodeB into the admitted list, and all the failed ERABs into the Failed to Setup IE .

6.2.6.1.1.2.4 Unsuccessful S1 based HO due to fail on MME-target eNodeB


connectivity
Test Name:

Successful S1 HO due to fail on MME

Reference:

TS 23.401 section 5.5.1.2.2

Test Objective:

Validate the expected call flow for an unsuccessful S1 HO due to fail on


MME

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.

Figure 101: Unsuccessful S1 HO due to fail on MME-Target eNodeB


connectivity

6.2.6.1.1.2.5 Unsuccessful S1 based HO due to not common ciphering


algorithm
Test Name:

Unsuccessful S1 HO due to not common ciphering algorithm

Reference:

TS 23.401 section 5.5.1.2.2

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.

Figure 102: Unsuccessful S1 HO due to non common Ciphering algorithm

6.2.6.1.1.2.6 Unsuccessful S1 based HO due to no resources available at


target eNodeB
Test Name:

Unsuccessful S1 HO due to not resources available at target eNodeB

Reference:

TS 23.401 section 5.5.1.2.2

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.

Figure 103: Unsuccessful S1 based HO due to no resources available at


target eNodeB

6.2.6.1.2 Inter-System Handover


6.2.6.1.3 LTE to UTRAN Inter RAT Handover
6.2.6.1.3.1 Successful LTE to UTRAN HO for a single E-RAB
Test Name:

Successful LTE to UTRAN HO for a single E-RAB

Reference:

TS 23.401 section 5.5.2.1.2

Test Objective:

Validate the successful LTE to UTRAN HO in a single E-RAB


environment

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

Target RNC Source MME

Source
Target
Target SGSN Serving GW Serving GW

PDN GW

HSS

Uplink and DownlinkUser Plane PDUs


1. Handover Initiation
2. Handover Required

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

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

Figure 104: Successful LTE to UTRAN HO for single E-RAB (Preparation


Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by SGSN to
MME). This phase is followed by the Execution Phase (call flow below)

Source
eNodeB

UE

Target RNC

Source MME

Target SGSN

Source
Serving GW

Target
Serving GW PDN GW

HSS

Uplink and Downlink User Plane PDUs


1. Handover Command
2. HO from- E-UTRAN Command

4. UTRAN Iu Access Procedures


4a. Handover to UTRAN Complete
Sending of
uplink data
possible

Downlink User Plane PDUs


If Direct Forwarding applies
If Indirect Forwarding applies.

Via Target SGSN in case Direct Tunnel is not used


5. Relocation Complete
6. Forward Relocation Complete Notification
6a. Forward Relocation Complete Acknowledge
7. Modify Bearer Request
For Serving GW relocation Steps 7, 8 and 9,
and the following User Plane path, will be
handled by Target Serving GW

(A)

8. Modify Bearer Request


8a. Modify Bearer Response

9. Modify Bearer Response


Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)

10. Routeing Area Update procedure


11. Delete Session Request
11b. Release Resources

(B)

11a. Delete Session Response

12. Delete Indirect Data Forwarding Tunnel Request


12a. Delete Indirect Data Forwarding Tunnel Response
13. Delete Indirect Data Forwarding Tunnel Request
13a. Delete Indirect Data Forwarding Tunnel Response

Figure 105: Successful LTE to UTRAN HO for single E-RAB (Execution


Phase)
Note: This call flow covers the Execution Phase Until the HO is successfully completed

6.2.6.1.3.2 Successful LTE to UTRAN HO for multiple E-RABs


Test Name:

Successful LTE to UTRAN HO for multiple E-RABs

Reference:

TS 23.401 section 5.5.2.1.2

Test Objective:

Validate the successful LTE to UTRAN HO in a multiple E-RABs


environment

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

Target RNC Source MME

Source
Target
Target SGSN Serving GW Serving GW

PDN GW

HSS

Uplink and DownlinkUser Plane PDUs


1. Handover Initiation
2. Handover Required

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

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

Figure 106: Successful LTE to UTRAN HO for Multiple E-RABs (Preparation


Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by SGSN to
MME). Forward Relocation Request include the list of all the RABs to be established. Preparation phase is
followed by the Execution Phase (call flow below)

Source
eNodeB

UE

Target RNC

Source MME

Target SGSN

Source
Serving GW

Target
Serving GW PDN GW

HSS

Uplink and Downlink User Plane PDUs


1. Handover Command
2. HO from- E-UTRAN Command

4. UTRAN Iu Access Procedures


4a. Handover to UTRAN Complete
Sending of
uplink data
possible

Downlink User Plane PDUs


If Direct Forwarding applies
If Indirect Forwarding applies.

Via Target SGSN in case Direct Tunnel is not used


5. Relocation Complete
6. Forward Relocation Complete Notification
6a. Forward Relocation Complete Acknowledge
7. Modify Bearer Request
For Serving GW relocation Steps 7, 8 and 9,
and the following User Plane path, will be
handled by Target Serving GW

(A)

8. Modify Bearer Request


8a. Modify Bearer Response

9. Modify Bearer Response


Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)

10. Routeing Area Update procedure


11. Delete Session Request
11b. Release Resources

(B)

11a. Delete Session Response

12. Delete Indirect Data Forwarding Tunnel Request


12a. Delete Indirect Data Forwarding Tunnel Response
13. Delete Indirect Data Forwarding Tunnel Request
13a. Delete Indirect Data Forwarding Tunnel Response

Figure 107: Successful LTE to UTRAN HO with Multiple E-RABs (Execution


Phase)
Note: This call flow covers the Execution Phase Until the HO is successfully completed

6.2.6.1.3.3 LTE to UTRAN HO failure due to connectivity issues


Test Name:

LTE to UTRAN HO failure due to connectivity issues

Reference:

TS 23.401 section 5.5.2.1.2

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.

Figure 108: LTE to UTRAN HO Failure due to connectivity issues

6.2.6.1.3.4 LTE to UTRAN HO failure due to not resources at NodeB


Test Name:

LTE to UTRAN HO failure due to not resources at NodeB

Reference:

TS 23.401 section 5.5.2.1.4

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

Target RNC Source MME

Source
Target
Target SGSN Serving GW Serving GW

PDN GW

Uplink and DownlinkUser Plane PDUs


1. Handover Initiation
2. Handover Required

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

5. Relocation Request
6. Relocation Failure
7. Delete Session Request
7a. Delete Session Response
.8. Forward Relocation Response (Reject)
9. Handover Preparation Failure

Figure 109: LTE to UTRAN HO failure due to not resources at NodeB

HSS

6.2.6.1.3.5 LTE to UTRAN CS-Fallback: Inter RAT Handover triggered by


Mobile Originated Call, UE in Idle Mode
Test Name:

LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile


originated call, UE in Idle Mode

Reference:

TS 23.272 section 6.4

Test Objective:

Validate the successful CS-Fallback to UTRAN network triggered by the


mobile originated call while the UE is in Idle Mode

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:

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/MS

eNodeB

BSS/RNS

MME

MSC

SGW/PGW

SGSN

1a. NAS Extended Service Request


1b. S1-AP UE Context Modification Request with CS Fallback indicator
1c. S1-AP UE Context Modification Response message
2. Optional Measurement Report Solicitation
3a. NACC,

. 3b, 3c RRC connection release


4. S1-AP: S1 UE Context Release Request

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

9. A/Iu-cs message (with CM Service Request)

10a. Service Reject


10b. Location Area Update

If the MSC
is changed

10c. CS MO call

11. Routing Area Update or Combined RA/LA Update

Figure 110: LTE to UTRAN CS-Fallback: MO call, UE in Idle Mode


Note: Call flow above corresponds to Mobile Originating call in Active Mode. The Mobile Originating call in
Idle Mode procedure would be exactly the same but instead of S1 AP UE Context Modification
Request/Response they would be S1 AP Initial UE Context Request/Response.

6.2.6.1.3.6 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile


Terminated Call, UE in Idle mode
Test Name:

LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile


terminated call, UE in Idle Mode

Reference:

TS 23.272 section 7.2

Test Objective:

Validate the successful CS-Fallback to UTRAN network triggered by the


mobile terminated call while the UE is in Idle Mode

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

2. SRI procedure in TS 23.018


3. IAM
4. Paging Request
6. Paging

5. Paging

7a. Extended Service Request

7a. Service Request

7b. Initial UE Context Setup

Figure 111: LTE to UTRAN CS-Fallback: MT Call, UE in Idle Mode


(Preparation Phase)

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

1a. CS Paging Notification


1b. NAS Extended Service Request

MSC

MME

Serving
GW

SGSN

1a. Paging Request


1a. Service Request
1c. CS Paging Reject

1d. S1-AP UE Context Modification Request with CS Fallback indicator


1e. S1-AP UE Context Modification Response message
2. Optional Measurement Report Solicitation
3a. PS HO as specified in 23.401 [2] (preparation phase and start of execution phase)
3b. Suspend

3c. Update Bearer(s)

4a. Location Area Update or Combined RA/LA


Update
4b. Paging Response
4b. A/Iu-cs message (with Paging Response)

5b. Signalling Connection Release

5a. Establish CS
connection
5b. Connection Reject

5b. Location Area Update or Combined RA/LA Update

Option 1:
MSC is not
changed

If the MSC
is changed

5c. CS call establishment procedure

6. PS HO as specified in 23.401 [2] (continuation of execution phase)

Figure 112: LTE to UTRAN CS-Fallback (Execution Phase with PS HO


supported)

P-GW/
GGSN

Reference figure: TS 23.272. Section 7.3


But If the eNodeB knows that PS HO is NOT supported, then the procedure following this call flow is:
UE/MS

eNodeB

BSS/RNS

1A. CS SERVICE NOTIFICATION


1b. NAS Extended Service Request

MSC

MME

S-GW/PGW

SGSN

1A. PAGING REQUEST


1A. SERVICE REQUEST
1c. CS Paging Reject

1d. S1-AP UE Context Modification Request with CS Fallback indicator


1e. S1-AP UE Context Modification Response message
2. Optional Measurement Report
3a. CCO/NACC,
3b, 3c. Signalling connection release
4. S1-AP: S1 UE CONTEXT RELEASE REQUEST
5. S1 UE CONTEXT RELEASE
6.UE changes RAT then, LAU OR COMBINED RA/LA UPDATE OR RA UPDATE OR LAU AND RAU

7a. Suspend (see TS 23.060)


7b. Suspend Request / Response
8. Update bearer(s)
9. Paging Response
9a. Establish CS connection
9b. Signalling Connection Release

9b. CONNECTION REJECT

9c. Location Area Update or Combined RA/LA Update

IF THE
MSC IS
CHANGED

Figure 113: LTE to UTRAN CS-Fallback (Execution Phase without PS HO


Supported)

6.2.6.1.3.7 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile


Originated Call, UE in Active Mode
Test Name:

LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile


originated call, UE in Idle Mode

Reference:

TS 23.272 sections 6.2 and 6.3

Test Objective:

Validate the successful CS-Fallback to UTRAN network triggered by the


mobile originated call while the UE is in Idle Mode

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

1a. NAS Extended Service Request


1b. S1-AP UE Context Modification Request with CS Fallback indicator
1c. S1-AP UE Context Modification Response message
2. Optional Measurement Report Solicitation
3a. NACC,

. 3b, 3c RRC connection release


4. S1-AP: S1 UE Context Release Request

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

9. A/Iu-cs message (with CM Service Request)

10a. Service Reject


10b. Location Area Update

If the MSC
is changed

10c. CS MO call

11. Routing Area Update or Combined RA/LA Update

Figure 114: LTE to UTRAN CS-Fallback, MO Call, UE in Active Mode

6.2.6.1.3.8 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile


Terminated Call, UE in Active Mode
Test Name:

LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile


terminated call, UE in Active Mode

Reference:

TS 23.272 sections 7.3 and 7.4

Test Objective:

Validate the successful CS-Fallback to UTRAN network triggered by the


mobile terminated call while the UE is in Active Mode

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

1a. CS Paging Notification


1b. NAS Extended Service Request

MSC

MME

Serving
GW

SGSN

1a. Paging Request


1a. Service Request
1c. CS Paging Reject

1d. S1-AP UE Context Modification Request with CS Fallback indicator


1e. S1-AP UE Context Modification Response message
2. Optional Measurement Report Solicitation
3a. PS HO as specified in 23.401 [2] (preparation phase and start of execution phase)
3b. Suspend

3c. Update Bearer(s)

4a. Location Area Update or Combined RA/LA


Update
4b. Paging Response
4b. A/Iu-cs message (with Paging Response)

5b. Signalling Connection Release

5a. Establish CS
connection
5b. Connection Reject

5b. Location Area Update or Combined RA/LA Update

Option 1:
MSC is not
changed

If the MSC
is changed

5c. CS call establishment procedure

6. PS HO as specified in 23.401 [2] (continuation of execution phase)

Figure 115: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode


(Preparation Phase)

P-GW/
GGSN

Reference figure: TS 23.272. Section 7.3


But If the eNodeB knows that PS HO is NOT supported, then the procedure following this call flow is:
UE/MS

eNodeB

BSS/RNS

1A. CS SERVICE NOTIFICATION


1b. NAS Extended Service Request

MSC

MME

S-GW/PGW

SGSN

1A. PAGING REQUEST


1A. SERVICE REQUEST
1c. CS Paging Reject

1d. S1-AP UE Context Modification Request with CS Fallback indicator


1e. S1-AP UE Context Modification Response message
2. Optional Measurement Report
3a. CCO/NACC,
3b, 3c. Signalling connection release
4. S1-AP: S1 UE CONTEXT RELEASE REQUEST
5. S1 UE CONTEXT RELEASE
6.UE changes RAT then, LAU OR COMBINED RA/LA UPDATE OR RA UPDATE OR LAU AND RAU

7a. Suspend (see TS 23.060)


7b. Suspend Request / Response
8. Update bearer(s)
9. Paging Response
9a. Establish CS connection
9b. Signalling Connection Release

9b. CONNECTION REJECT

9c. Location Area Update or Combined RA/LA Update

IF THE
MSC IS
CHANGED

Figure 116: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode


(Execution Phase) without PS HO Support

6.2.6.1.3.9 LTE to UTRAN SRVCC: Inter RAT Handover for VoIP Call
Test Name:

LTE to UTRAN SRVCC: Inter RAT Handover for VoIP call

Reference:

TS 23.216 section 6.2.2.1

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

12. Release of IMS


access leg

15. HO from EUTRAN command


16. UE tunes to GERAN
17. HO Detection
18. Suspend (see TS 23.060)
18. Suspend Request / Response

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:

TS 23.216 section 6.2.2.2

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

5c. Reloc /HO Req


6b. Reloc /HO Req
7a. Reloc /HO Req Ack

7b. Forward Reloc Resp


8b. Prep HO Resp

8a. Reloc /HO Req Ack

8c. Establish circuit


9. Initiation of Session Transfer (STN-SR or E-STN-SR)
12. PS to CS Resp

10. Session transfer and


update remote leg

13. Handover Command


14. HO from EUTRAN command

11. Release of IMS access


leg

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

18b. Forward Reloc Complete/Ack

18a. Reloc/HO Complete


18c. Update bearer

19. Subscriber Location Report


GMLC

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

6.2.6.1.4 UTRAN to LTE Inter RAT Handover


6.2.6.1.4.1 Successful UTRAN to LTE Inter RAT Handover for a single RAB
Test Name:

Successful UTRAN to LTE Inter RAT Handover for a single RAB

Reference:

TS 23.401 section 5.5.2.2

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

Uplink and Downlink User Plane PDUs (via Source SGSN

Target
Serving GW

PDN
GW

HSS

in case Direct Tunnel is not used)

1. Handover Initiation
2. Relocation Required

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

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

If Direct Forwarding applies


Via Source SGSN in case Direct Tunnel is not used

If Indirect Forwarding applies

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)

9. Modify Bearer Request


9a. Modify Bearer Response

10. Modify Bearer Response


Uplink and Downlink User Plane PDUs
11. Tracking Area Update procedure
12. Delete Session Request
12b. Iu Release Procedure

(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:

Successful UTRAN to LTE Inter RAT Handover for multiple RABs

Reference:

TS 23.401 section 5.5.2.2

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

Uplink and Downlink User Plane PDUs (via Source SGSN

Target
Serving GW

PDN
GW

HSS

in case Direct Tunnel is not used)

1. Handover Initiation
2. Relocation Required

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

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

If Direct Forwarding applies


Via Source SGSN in case Direct Tunnel is not used

If Indirect Forwarding applies

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)

9. Modify Bearer Request


9a. Modify Bearer Response

10. Modify Bearer Response


Uplink and Downlink User Plane PDUs
11. Tracking Area Update procedure
12. Delete Session Request
12b. Iu Release Procedure

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

6.2.6.1.4.3 UTRAN to LTE Inter RAT Handover failure due to no resources at


the eNodeB
Test Name:

Unsuccessful UTRAN to LTE Inter RAT Handover due to no resources at


the eNodeB

Reference:

TS 23.401 section 5.5.2.2

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

3. Forward Relocation Request


4. Create Session Request
4a. Create Session Response

5. Handover Request
6. Handover Failure
7. Delete Session Request
7a. Delete Session Response
8. Forward Relocation Response (Reject)
9. Relocation Preparation Failure

Figure 123: UTRAN to LTE Inter RAT HO failure due to no resources at


eNodeB
Note: The Handover Failure message shall include a Cause IE indicating No resources available at target
Cell

You might also like