Lte Detail - S1 Interface

Long Term Evolution - Evolved Packet Core
S1 Interface Conformance Test Plan

Table of Contents
! "#$%& (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !)
* +&,&+&-#&" (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !)
. /00+&12/32$-" (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !!
4 $1&+12&5 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !4
6 3&"3 #$-,278+/32$- ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !9
6(! -&35$+: ; 2-3&+,/#& #$-,278+/32$- <$1&+12&5= (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !9
(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !>
6(* -&35$+: &?&@&-3" "$,35/+& 1&+"2$- ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !A
6(. 3&"3 &B82%@&-3 ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !A
9 C&3/2?&C 3&"3 #/"&" (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( !D
9(! @/-/7&@&-3E 3+/#2-7 /-C ?$#/32$- +&%$+3 3&"3 #/"&" ((((((((((((((((((((((((((((((((((((((((((((((((((( !D
6.1.1 MAnACLMLn1 8CCLuu8LS CvL8 SC1 ................................................................................. 19
6.1.1.1 S1 SeLup beLween MML and enode8 ln a slngle LMn conflguraLlon .......................... 19
6.1.1.1.1 Successful S1 SeLup .................................................................................................... 19
6.1.1.1.2 unsuccessful S1 SeLup ................................................................................................ 21
6.1.1.2 S1 SeLup beLween MML and enode8 ln a mulLlple LMn conflguraLlon (MCCn
conflguraLlon) ................................................................................................................................ 22
6.1.1.2.1 Successful S1 SeLup .................................................................................................... 22
6.1.1.2.2 unsuccessful S1 SeLup ................................................................................................ 23
6.1.1.3 S1 ConflguraLlon updaLe (MML lnlLlaLed) ..................................................................... 24
6.1.1.3.1 Successful S1 MML ConflguraLlon updaLe ................................................................. 24
6.1.1.3.2 unsuccessful S1 MML ConflguraLlon updaLe ............................................................. 23
6.1.1.4 S1 ConflguraLlon updaLe (enode8 lnlLlaLed) ................................................................. 26
6.1.1.4.1 Successful S1 ConflguraLlon updaLe (enode8 lnlLlaLed) ............................................ 26
6.1.1.4.2 unsuccessful S1 ConflguraLlon updaLe (enode8 lnlLlaLed) ........................................ 27
6.1.1.3 S1 8eseL rocedures ...................................................................................................... 27
6.1.1.3.1 S1 8eseL lnlLlaLed by enode8 ..................................................................................... 28
6.1.1.3.2 S1 8eseL lnlLlaLed by MML ......................................................................................... 29
6.1.1.6 S1 8ecovery afLer nodes fallure ..................................................................................... 30
6.1.1.6.1 S1 8ecovery afLer enode8 resLarL .............................................................................. 30
6.1.1.6.2 S1 8ecovery afLer MML resLarL .................................................................................. 32
6.1.1.6.3 S1 8ecovery afLer SCW resLarL ................................................................................... 33
6.1.1.6.4 S1 8ecovery from S1 fallure due Lo physlcal connecLlons losL ................................... 33
6.1.2 18ACL Anu LCCA1lCn 8LC81lnC 8CCLuu8LS ........................................................................ 37
6.1.2.1 1race rocedures ........................................................................................................... 37
6.1.2.1.1 1race SLarL .................................................................................................................. 37
6.1.2.1.1.1 1race SLarL supporLlng S1 lnLerface ......................................................................... 37
6.1.2.1.1.2 1race SLarL supporLlng x2 lnLerface ......................................................................... 39
6.1.2.1.2 ueacLlvaLe 1race ......................................................................................................... 41
6.1.2.2 LocaLlon 8eporLlng rocedures ..................................................................................... 43
6.1.2.2.1 Successful locaLlon reporLlng for a dlrecL reporL of Lhe uL locaLlon .......................... 43
6.1.2.2.2 Successful locaLlon reporLlng for servlng cell change ................................................. 43
6.1.2.2.3 Successful cancellaLlon of locaLlon reporLlng for servlng cell change ........................ 47
9(* ,8-#32$-/? 3&"3 #/"&" (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( 4D
6.2.1 A11ACP/uL1ACP .................................................................................................................. 49
6.2.1.1 Successful LS ALLach wlLh uL unknown ln MML and no Clpherlng ............................. 49
6.2.1.2 Successful LS ALLach wlLh uL unknown ln MML and Clpherlng .................................. 32
6.2.1.3 Successful LS ALLach procedure wlLh uL known ln MML and no Clpherlng ................ 33
6.2.1.4 Successful LS ALLach procedure wlLh uL known ln MML wlLh Clpherlng .................... 37
6.2.1.3 Successful LS ALLach procedure wlLh lMSl .................................................................. 39
6.2.1.6 unsuccessful LS ALLach due Lo lMSl unknown on PSS ................................................ 61
6.2.1.7 Successful LS ueLach lnlLlaLed by uL ........................................................................... 63
6.2.1.8 Successful LS ueLach lnlLlaLed by uL due Lo swlLch off ............................................... 64
6.2.1.9 Successful LS ueLach lnlLlaLed by MML ....................................................................... 66
6.2.2 L-8A8 8C1CCCL 8CCLuu8LS .............................................................................................. 68
6.2.2.1 L-8A8 SeLup ................................................................................................................... 68
6.2.2.1.1 Successful L-8A8 esLabllshmenL for ........................................................................... 68
6.2.2.1.2 Successful L-8A8 esLabllshmenL for- uL AggregaLe Maxlmum 8lL 8aLe lL ls lncluded
69
6.2.2.1.3 Successful L-8A8 esLabllshmenL for mulLlple L-8A8s ................................................. 71
6.2.2.2 L-8A8 Modlfy ................................................................................................................. 72
6.2.2.2.1 Successful L-8A8 modlflcaLlon ................................................................................... 72
6.2.2.2.2 Successful L-8A8 modlflcaLlon for mulLlple L-8A8s ................................................... 74
6.2.2.2.3 Successful and unsuccessful L-8A8 modlflcaLlon for mulLlple L-8A8s ....................... 73
6.2.2.3 L-8A8 8elease ................................................................................................................ 76
6.2.2.3.1 L-8A8 8elease lnlLlaLed by MML ................................................................................ 76
6.2.2.3.2 L-8A8 8elease lnlLlaLed by enode8 ............................................................................ 78
6.2.3 LC 8LA8L8S lunC1lCnAL 8CCLuu8LS .................................................................................. 80
6.2.3.1 uedlcaLed bearer AcLlvaLlon .......................................................................................... 80
6.2.3.1.1 Successful uedlcaLed 8earer AcLlvaLlon lnlLlaLed by Lhe neLwork .............................. 80
6.2.3.1.2 Successful uedlcaLed 8earer AcLlvaLlon lnlLlaLed by Lhe uL ....................................... 82
6.2.3.1.3 Successful uedlcaLed 8earer AcLlvaLlon durlng aLLach ............................................... 84
6.2.3.2 8earer ModlflcaLlon ....................................................................................................... 86
6.2.3.2.1 8earer ModlflcaLlon lnlLlaLed by Lhe LC ................................................................... 86
6.2.3.2.1.1 un CW lnlLlaLed bearer modlflcaLlon wlLh CoS updaLe ....................................... 86
6.2.3.2.1.2 PSS lnlLlaLed Subscrlber CoS ModlflcaLlon .............................................................. 87
6.2.3.2.1.3 neLwork lnlLlaLed 8earer modlflcaLlon wlLhouL 8earer CoS updaLe ...................... 88
6.2.3.2.2 8earer ModlflcaLlon lnlLlaLed by Lhe uL ..................................................................... 90
6.2.3.2.2.1 uL 8equesLed 8earer ModlflcaLlon accepLed by Lhe neLwork ................................ 90
6.2.3.2.2.2 uL 8equesLed 8earer ModlflcaLlon wlLhouL CoS updaLe accepLed by Lhe neLwork92
6.2.3.3 uedlcaLed 8earer deacLlvaLlon ...................................................................................... 94
6.2.3.3.1 un CW lnlLlaLed uedlcaLed 8earer ueacLlvaLlon ..................................................... 94
6.2.3.3.2 MML lnlLlaLed uedlcaLed 8earer ueacLlvaLlon ........................................................... 93
6.2.3.3.3 uL lnlLlaLed uedlcaLed 8earer ueacLlvaLlon ............................................................... 97
6.2.4 luLL MCuL Anu CCn1Lx1 MAnACLMLn1 8CCLuu8LS ............................................................. 98
6.2.4.1 AcLlve Lo ldle mode 1ranslLlon (ConLexL 8elease) ......................................................... 98
6.2.4.1.1 uL/enode8 ConLexL 8elease due Lo user lnacLlvlLy wlLh a slngle bearer esLabllshed 98
6.2.4.1.2 uL/enode8 ConLexL 8elease due Lo user lnacLlvlLy wlLh mulLlple bearers esLabllshed
100
6.2.4.2 uL ConLexL 8elease due Lo radlo connecLlon wlLh uL losL .......................................... 102
6.2.4.3 1racklng Area updaLe procedures ............................................................................... 103
6.2.4.3.1 normal 1racklng area updaLe ................................................................................... 103
6.2.4.3.2 normal 1racklng area updaLe wlLh bearer esLabllshmenL requesLed ...................... 103
6.2.4.3.3 Comblned 1racklng and LocaLlon Area updaLe ........................................................ 107
6.2.4.3.4 Comblned 1racklng and LocaLlon Area updaLe wlLh lMSl aLLach ............................. 109
6.2.4.3.3 Comblned 1racklng and LocaLlon Area updaLe wlLh bearer esLabllshmenL requesLed
111
6.2.4.3.6 erlodlc 1racklng area updaLe .................................................................................. 113
6.2.4.3.7 1racklng Area updaLe re[ecLed due Lo no LS 8earer conLexL acLlvaLed" ............. 113
6.2.4.3.8 1racklng Area updaLe re[ecLed due Lo lmpllclLly deLached" ................................... 117
6.2.4.4 aglng .......................................................................................................................... 119
6.2.4.4.1 aglng wlLh aglng u8x lL ........................................................................................ 119
6.2.4.4.2 aglng wlLhouL aglng u8x lL ................................................................................... 120
6.2.4.3 ldle Lo AcLlve Mode (Servlce 8equesL) ........................................................................ 121
6.2.4.3.1 Successful Servlce 8equesL lnvoked when Lhe uL recelves a paglng requesL wlLh Cn
domaln lndlcaLor seL Lo S" from Lhe neLwork ln LCM-ldle mode (Slngle bearer) ................... 121
6.2.4.3.2 Successful Servlce 8equesL lnvoked when Lhe uL recelves a paglng requesL wlLh Cn
domaln lndlcaLor seL Lo S" from Lhe neLwork ln LCM-ldle mode (MulLlple bearers) .............. 123
6.2.4.3.3 Successful Servlce 8equesL lnvoked when Lhe uL has pendlng user daLa Lo be senL ln
LCM-ldle mode (Slngle 8earer) ................................................................................................... 123
6.2.4.3.4 Successful Servlce 8equesL lnvoked when Lhe uL has pendlng user daLa Lo be senL ln
LCM-ldle mode (MulLlple 8earers) .............................................................................................. 127
6.2.4.3.3 Successful Servlce 8equesL lnvoked when Lhe uL has upllnk slgnallng pendlng ln
LCM-ldle mode ............................................................................................................................ 129
6.2.4.3.6 Successful Servlce 8equesL lnvoked by 1xCS fallback when Lhe uL ls ln ldle mode and
has a moblle orlglnaLlng 1xCS fallback requesL ........................................................................... 131
6.2.4.3.7 Successful Servlce 8equesL lnvoked by 1xCS fallback when Lhe uL ls ln AcLlve mode
and has a moblle orlglnaLlng 1xCS fallback requesL .................................................................... 133
6.2.4.3.8 Successful lnlLlal uL message wlLh Lmergency llag enabled ................................... 133
6.2.3 uSL8 LAnL 8C1CCCL Anu uA1A 18AnSlL8 1LS1 CASLS ......................................................... 136
6.2.3.1.1 user lane ConLrol 1esL Cases .................................................................................. 136
6.2.3.1.1.1 C1-u echo mechanlsm ......................................................................................... 136
6.2.3.1.1.2 C1-u message Lnd of Marker" ........................................................................... 137
6.2.3.1.1.3 Craceful Lrror lndlcaLlon handllng by enode8 ...................................................... 139
6.2.3.1.1.4 Craceful Lrror lndlcaLlon handllng by S-CW .......................................................... 140
6.2.3.1.2 uaLa 1ransfer on uefaulL 8earer ............................................................................... 142
6.2.3.1.3 uaLa 1ransfer on uedlcaLed 8earer 1esL Cases ........................................................ 144
6.2.3.1.3.1 Successful uaLa 1ransfer wlLh non-C88 Servlce and AM Mode ............................ 144
6.2.3.1.3.2 Successful uaLa 1ransfer wlLh non-C88 Servlce and uM Mode ............................ 146
6.2.3.1.3.3 Successful uaLa 1ransfer wlLh C88 Servlce and AM Mode ................................... 148
6.2.3.1.3.4 Successful uaLa 1ransfer wlLh C88 Servlce and uM Mode ................................... 130
6.2.6 MC8lLl1? 1LS1 CASLS .......................................................................................................... 132
6.2.6.1.1 lnLra-SysLem Pandover ............................................................................................. 132
6.2.6.1.1.1 x2 8ased Pandover ................................................................................................ 132
6.2.6.1.1.1.1 Successful PC wlLh slngle L-8A8 vla x2 lnLerface ............................................... 132
6.2.6.1.1.1.2 Successful PC wlLh slngle L-8A8 vla x2 lnLerface wlLh Clpherlng ...................... 133
6.2.6.1.1.1.3 Successful PC wlLh mulLlple L-8A8s vla x2 lnLerface ......................................... 137
6.2.6.1.1.1.4 arLlally Successful PC wlLh mulLlple L-8A8s vla x2 lnLerface ........................... 160
6.2.6.1.1.1.3 unsuccessful PC vla x2 lnLerface due Lo LC lallure ......................................... 162
6.2.6.1.1.2 S1 8ased Pandover ................................................................................................ 164
6.2.6.1.1.2.1 Successful S1 PC wlLh slngle L-8A8 .................................................................... 164
6.2.6.1.1.2.2 Successful S1 PC wlLh mulLlple L-8A8s .............................................................. 166
6.2.6.1.1.2.3 arLlally Successful S1 PC wlLh mulLlple L-8A8s ................................................ 168
6.2.6.1.1.2.4 unsuccessful S1 based PC due Lo fall on MML-LargeL enode8 connecLlvlLy ..... 171
6.2.6.1.1.2.3 unsuccessful S1 based PC due Lo noL common clpherlng algorlLhm ................. 173
6.2.6.1.1.2.6 unsuccessful S1 based PC due Lo no resources avallable aL LargeL enode8 ..... 173
6.2.6.1.2 lnLer-SysLem Pandover ............................................................................................. 177
6.2.6.1.3 L1L Lo u18An lnLer 8A1 Pandover ........................................................................... 177
6.2.6.1.3.1 Successful L1L Lo u18An PC for a slngle L-8A8 .................................................... 177
6.2.6.1.3.2 Successful L1L Lo u18An PC for mulLlple L-8A8s ................................................. 180
6.2.6.1.3.3 L1L Lo u18An PC fallure due Lo connecLlvlLy lssues ............................................. 183
6.2.6.1.3.4 L1L Lo u18An PC fallure due Lo noL resources aL node8 ..................................... 184
6.2.6.1.3.3 L1L Lo u18An CS-lallback: lnLer 8A1 Pandover Lrlggered by Moblle CrlglnaLed Call,
uL ln ldle Mode ........................................................................................................................... 186
6.2.6.1.3.6 L1L Lo u18An CS-lallback: lnLer 8A1 PC Lrlggered by moblle 1ermlnaLed Call, uL ln
ldle mode 189
6.2.6.1.3.7 L1L Lo u18An CS-lallback: lnLer 8A1 PC Lrlggered by moblle CrlglnaLed Call, uL ln
AcLlve Mode 194
6.2.6.1.3.8 L1L Lo u18An CS-lallback: lnLer 8A1 PC Lrlggered by moblle 1ermlnaLed Call, uL ln
AcLlve Mode 197
6.2.6.1.3.9 L1L Lo u18An S8vCC: lnLer 8A1 Pandover for vol Call ....................................... 202
6.2.6.1.3.10 L1L Lo u18An S8vCC: lnLer 8A1 Pandover for uaLa 1ransfer and vol Call ....... 204
6.2.6.1.4 u18An Lo L1L lnLer 8A1 Pandover ........................................................................... 206
6.2.6.1.4.1 Successful u18An Lo L1L lnLer 8A1 Pandover for a slngle 8A8 ............................. 206
6.2.6.1.4.2 Successful u18An Lo L1L lnLer 8A1 Pandover for mulLlple 8A8s .......................... 209
6.2.6.1.4.3 u18An Lo L1L lnLer 8A1 Pandover fallure due Lo no resources aL Lhe enode8 .... 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 26: Deactivate Trace ............................................................................................. 41
Figure 28: Location Reporting Control Procedure - Successful Operation ..................... 43
Figure 29: Location Report Failure Indication Procedure ............................................... 44
Figure 31: Location Report Procedure - Successful Operation ....................................... 46
Figure 32: Location Report Failure Indication ................................................................ 46
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 Technical Specification Group Core Network and Terminals;
General
Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)

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

[4] 3GPP TS 23.401 Technical Specification Group Services and System Aspects;
General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access

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

Handover procedures

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

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

Figure 1: S1 Interface Protocol Stack towards MME

S1-AP
SCTP
IP
L2
L1
S1-AP
SCTP
IP
L2
L1
S1-MME
HeNB MME

Figure 2 shows the S1-U interface protocol stack.

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.

GTP-U
UDP
IP
L2
L1
GTP-U
UDP
IP
L2
L1
S1-U
HeNB S-GW

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.

SGi
S1-MME
PCRF
Gx
S6a
HSS
Operator's IP
Services
(e.g. IMS, PSS etc.)
Rx
S10
TE
E-UTRAN
MME
S11
S5
Serving
Gateway
PDN
Gateway
S1-U
UE

Figure 3: Network Configuration for regular test cases

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

SGi
S1-MME
PCRF
Gx
S6a
HSS
Operator's IP
Services
Rx
S10
TE
E-UTRAN
MME
S11
S5
Serving
Gateway
PDN
Gateway
S1-U
UE
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.

SGi
S12
S3
S1-MME
PCRF
Gx
S6a
HSS
Operator's IP
Services
Rx
S10
SGSN
E-UTRAN
MME
S11
S5
Serving
Gateway
PDN
Gateway
S1-U
S4
UTRAN
IuPS
TE
UE
MSS
Gs D
IuCS

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 Name/Model
Analyzer
Simulator
Mobiles
Others

6 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
S1 SETUP REQUEST
MME
S1 SETUP RESPONSE

Figure 6: Setup Procedure Successful Operation

6.1.1.1.2 Unsuccessful S1 Setup

eNB
S1 SETUP REQUEST
MME
S1 SETUP FAILURE

Figure 7: S1 Setup Procedure - Unsuccessful Operation

Test Name: Unsuccessful establishment of SCTP association between eNodeB and
MME in a single PLMN Id Configuration
Test Objective: Verify the the graceful failure of S1 setup establishment between eNodeB
and MME
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)
Test Procedure:
Expected Results:
Verify that:
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

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

eNB
S1 SETUP REQUEST
MME
S1 SETUP RESPONSE

Figure 8: S1 Setup Procedure: Successful Operation
Test Name: Successful establishment of SCTP association and Path Heartbeat in a
multiple PLMN Configuration
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
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
Test Procedure:
Expected Results:
Verify that:
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.

6.1.1.2.2 Unsuccessful S1 Setup

eNB
S1 SETUP REQUEST
MME
S1 SETUP FAILURE

Figure 9: S1 Setup Procedure: Unsuccessful Operation
Test Name: Unsuccessful establishment of SCTP association between eNodeB and
MME in a multiple PLMN Id Configuration
Test Objective: Verify the the graceful failure of S1 setup establishment between eNodeB
and MME
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)
Test Procedure:
Expected Results:
Verify that:
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

6.1.1.3 S1 Configuration Update (MME Initiated)

6.1.1.3.1 Successful S1 MME Configuration Update

eNB
MME CONFIGURATION UPDATE
MME
MME CONFIGURATION UPDATE ACKNOWLEDGE

Figure 10: MME Configuration Update Procedure: Successful Operation
Test Name: Successful MME Configuration Update
Test Objective: Validate the successful application level configuration data update when
initiated by MME
Initial S1 setup has been successfully established between eNodeB and MME
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

6.1.1.3.2 Unsuccessful S1 MME Configuration Update

eNB
MME CONFIGURATION UPDATE
MME
MME CONFIGURATION UPDATE FAILURE

Figure 11: MME Configuration Update: Unsuccessful Operation

Test Name: Unsuccessful MME Configuration Update
Test Objective: Validate the graceful unsuccessful application level configuration data
update when initiated by MME
Make sure eNodeB is not configured to accept the PLMN-ID that MME will send
during the S1 MME Configuration Update.
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.

6.1.1.4 S1 Configuration Update (eNodeB Initiated)

6.1.1.4.1 Successful S1 Configuration Update (eNodeB Initiated)

eNB
ENB CONFIGURATION UPDATE
MME
ENB CONFIGURATION UPDATE ACKNOWLEDGE

Figure 12: ENB Configuration Update Procedure: Successful Operation
Test Name: Successful eNodeB Configuration Update
Test Objective: Validate the successful application level configuration data update
between eNodeB and MME when is initiated by eNodeB
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.

6.1.1.4.2 Unsuccessful S1 Configuration Update (eNodeB Initiated)

eNB
ENB CONFIGURATION UPDATE
MME
ENB CONFIGURATION UPDATE FAILURE

Figure 13: ENB Configuration Update Procedure: Unsuccessful Operation

Test Name: Unsuccessful eNodeB Configuration Update
Test Objective: Validate the graceful unsuccessful application level configuration data
update between eNodeB and MME when is initiated by eNodeB
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.

6.1.1.5 S1 Reset Procedures
6.1.1.5.1 S1 Reset initiated by eNodeB

MME eNB
RESET
RESET ACKNOWLEDGE

Figure 14: Reset Procedure Initiated From the E-UTRAN Successful
Operation
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
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.

6.1.1.5.2 S1 Reset initiated by MME

MME eNB
RESET
RESET ACKNOWLEDGE

Figure 15: Reset Procedure Initiated From the MME Successful Operation

Test Name: S1 Reset initiated by MME
Test Objective: Validate the successful reset initiated by MME and the consequent
initialization of the eNodeB
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.

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
Test Objective: Validate the S1 recovers successfully from the unexpected restart of the
eNodeB
There is at least one UE attached with active context and data transfer is ongoing
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

MME eNB
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
Test Objective: Validate the S1 recovers successfully from the unexpected restart of the
MME
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
Test Objective: Validate the S1-U recovers successfully from the unexpected restart of
the S-GW
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.

UE CONTEXT is successfully established
UE CONTEXT RELEASE COMMAND
eNB MME
UE CONTEXT RELEASE COMPLETE

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)
Test Objective: Validate the S1 recovers successfully from a physical connection failure
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
S1 SETUP REQUEST
MME
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

MME eNB
TRACE START

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

Figure 20: Trace Start Procedure

eNodeB
CELL TRAFFIC TRACE
MME

Figure 21: Cell Traffic Trace Procedure - Successful Operation

MME eNB
TRACE FAILURE INDICATION

Figure 22: Trace Failure Indication Procedure

6.1.2.1.1.2 Trace Start supporting X2 interface

MME eNB
TRACE START

Figure 23: Trace Start Procedure
Test Name: MME requests the eNodeB to start a trace supporting X2 interface and
minimum depth
Test Objective: Validate that MME is able to request the eNodeB to start a trace session
that supports X2 interface and minimum depth
specs)
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.


eNodeB
CELL TRAFFIC TRACE
MME

Figure 24: Cell Traffic Trace Procedure - Successful Operation

MME eNB


6.1.2.1.2 Deactivate Trace

MME eNB
DEACTIVATE TRACE

Figure 26: 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
specs)
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)
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


MME eNB


6.1.2.2 Location Reporting Procedures
6.1.2.2.1 Successful location reporting for a direct report of the UE location

eNB
LOCATION REPORTING CONTROL
MME

Figure 28: Location Reporting Control Procedure - Successful Operation
Test Name: Location Reporting Control sent to Request a direct report for a UE
location
Test Objective: Validate that MME is able to request the eNodeB to report where the UE
is currently located
specs)
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 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=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)

MME eNB
LOCATION REPORT FAILURE
INDICATION

Figure 29: Location Report Failure Indication Procedure

6.1.2.2.2 Successful location reporting for serving cell change

eNB
MME


Test Name: Successful location reporting for serving cell change
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
specs)
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

ongoing HO)

eNB
LOCATION REPORT
MME

Figure 31: Location Report Procedure - Successful Operation

MME eNB
INDICATION

Figure 32: Location Report Failure Indication

6.1.2.2.3 Successful cancellation of location reporting for serving cell
change

eNB
MME


Test Name: Successful cancellation of location reporting for serving cell change
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
specs)
Currently the location reporting is active for a serving cell change.
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.

ongoing HO)

MME eNB
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
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
ciphering is enabled
Ciphering is enabled
GUTI is unknown in the MME

Test Procedure:
Trigger UE attach

Expected Results:
Verify that:
or EEA2 for Ciphering as per the configuration
complete
Information Request
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
Test Objective: Validate the successful attach when UE is known to the MME and the
ciphering is disabled
Ciphering is disabled
GUTI is known in the MME

Test Procedure:
Trigger UE attach

Figure 37: Successful EPS Attach procedure with UE known in MME and
No Ciphering
Expected Results:
Verify that:
for Ciphering
complete
Information Request
being performed

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
Test Objective: Validate the successful attach when UE is known to the MME and the
ciphering is enabled
GUTI is known in the MME

Test Procedure:
Trigger UE attach

Figure 38: Successful EPS Attach with UE known in MME and Ciphering
Expected Results:
Verify that:
or EEA2 for Ciphering as per the configuration
complete
Information Request
being performed

6.2.1.5 Successful EPS Attach procedure with IMSI

Test Name: Successful EPS Attach with IMSI
UE has no GUTI
UE is not attached
UE has no GUTI

Test Procedure:
Trigger UE attach

Expected Results:
Verify that:
Request, which includes the EPS Mobile Identity IE (set to IMSI) and the ESM
Mode Command, with the Selected NAS Security Algorithms IE including EEA0,
EEA1 or EEA2 for Ciphering as per the configuration
complete
Information Request
Complete. The ESM message container IE will include a NAS Activate Default
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
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
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:
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

Figure 41: 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
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.

6.2.1.8 Successful EPS Detach initiated by UE due to switch off

Test Name: Successful EPS Detach UE initiated
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
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
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
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
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
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

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

Test Name: Successful Establishment of single E-RAB
Test Objective: Validate the possibility to establish an E-RAB for a UE
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.

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
Test Objective: Validate the possibility to establish an E-RAB for a UE when UE
Aggregate Maximum Bit Rate IE is included
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:
to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) and the UE
Aggregate Maximum Bit Rate IE
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

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

Test Name: Successful establishment of Multiple E-RABs
Test Objective: Validate the possibility to establish multiple E-RAB for a UE
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:
to be Setup List IE containing multiple E-RAB to be setup (multiple E-RAB ID IEs)
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 E-
RABs

Remarks 1:
If some of the E-RABs are successfully established but some of them are not, the S1-AP E-
RAB 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

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
Test Objective: Validate the possibility to modify an existing E-RAB
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

Figure 48: Successful E-RAB Modification for multiple E-RABs
Test Name: Successful E-RAB modification of multiple E-RABs
Test Objective: Validate the possibility to modify existing E-RABs
There are multiple E-RABs existing on UE

Test Procedure:
by including new TFT Filters/QoS Parameters) for multiple E-RABs

Expected Results:
Verify that:
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).
both of the sides and that the data is transferred accordingly on all the bearers.

6.2.2.2.3 Successful and Unsuccessful E-RAB modification for multiple E-
RABs

Test Name: Successful and Unsuccessful E-RAB modification of multiple E-RABs
Test Objective: Validate the possibility of a graceful partial modification of all the existing
E-RABs on a UE
There are multiple E-RABs existing on UE

Test Procedure:
by including new TFT Filters/QoS Parameters) for multiple E-RABs

Expected Results:
Verify that:
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.
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 E-
RABs

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
Test Objective: Validate the successful MME initiated release of an E-RAB existing on
UE
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 E-
RAB 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
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
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
UE is attached

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

Figure 55: PGW 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
UE is attached

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 E-
RAB Modify List IE containing the same E-RAB ID acknowledging the modification
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.

6.2.3.2.1.2 HSS initiated Subscriber QoS Modification

Figure 56: HSS initiated Subscriber QoS Modification

Test Name: HSS initiated bearer modification with QoS Update
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
UE is attached

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.
Vadliate that the new QoS is updated on every node accordingly and data traffic is
now following the new rules.

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
UE is attached

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 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
UE is attached

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.

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
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
UE is attached

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.

Remark 1:
If the modification request is not accepted by the network, then the MME will answer the S1-
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 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

Figure 60: PGW Initiated Dedicated Bearer Deactivation
Test Name: PDN GW initiated bearer deactivation
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
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
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).

6.2.3.3.2 MME initiated Dedicated Bearer Deactivation

Test Name: MME initiated bearer deactivation
3GPP TS 24.301, Section 6.4.4.2
3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3
MME
UE is attached

Test Procedure:
Initiate bearer deactivation from the MME
Expected Results:
Verify that:
List IE
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

Figure 62: UE initiated Dedicated Bearer Deactivation
Test Name: UE initiated bearer deactivation
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
UE
UE is attached

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
List IE
the traffic is now being routed through one of the rest of the bearers (e.g default).

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
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
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
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:
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 S1-
AP 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

Figure 65: UE Context Release due to Radio connection with UE lost
Test Name: UE Context Release due to radio connection with UE Lost
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
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:
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

6.2.4.3 Tracking Area Update procedures
6.2.4.3.1 Normal Tracking area Update

Test Name: Normal Tracking Area Update
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
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
Security Mode Complete
Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A
NAS Tracking Area Update Accept
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
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.
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:
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
NAS Tracking Area Update Accept including a EPS bearer context status IE
indicating the correct the EPS contexts as active in the MME
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
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
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:
Tracking Area Update Request, including a EPS Update Type IE set to Combined
TA/LA updating
Complete.
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
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
UE is attached
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:
TA/LA updating with IMSI attach
Complete.
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
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.
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
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

Figure 70: Combined Tracking and Location Area Update with bearer
establishment requested
Expected Results:
Verify that:
TA/LA updating and EPS bearer context status IE indicating the correct EPS
contexts as active on the UE
NAS Tracking Area Update Accept including a EPS bearer context status IE
indicating the correct the EPS contexts as active in the MME
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.

6.2.4.3.6 Periodic Tracking area Update

Test Name: Periodic Tracking Area Update
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
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:
Tracking Area Update Request, including a EPS Update Type IE set to Periodic
Updating
Complete.
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
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.
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

Expected Results:
Verify that:
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
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
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:
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

Figure 74: Paging with Paging DRX IE
Test Name: Paging with Paging DRX IE
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.
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 S1-
AP: 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.

6.2.4.4.2 Paging without Paging DRX IE

Figure 75: Paging without Paging DRX IE
Test Name: Paging without Paging DRX IE
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.
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 S1-
AP: 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.

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 ECM-
Idle Mode
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.

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 E-
RAB 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 ECM-
Idle Mode (Multiple bearers)
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
and establish the radio and S1 bearers when the network has downlink
signaling pending.

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
Service Request
RAB 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
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)
3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2
and establish the radio and S1 bearers when the UE has user data to be
sent in a single bearer environment

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:
Service Request
established.

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)
3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2
and establish the radio and S1 bearers when the UE has user data to be
sent in a multiple bearer environment

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:
Service Request
RAB to be setup list IE containing all the E-RABs which the eNodeB should
establish in order to build the new E-RAB configuration
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
3GPP TS 24.301, 5.6.1
3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2
and establish the radio and S1 bearers when the UE has signaling
pending

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:
Service Request
established.

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
UE is attached
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:
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
UE is attached
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:
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

Figure 83: Successful Initial UE message with Emergency Flag enabled

Test Name: Successful initial UE message when UE originating a call with
Emergency Flag enabled
Test Objective: Validate the successful Initial Context Setup procedure when emergency
mode is enabled
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 E-
RAB 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.

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

Figure 84: 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
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.

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

Handover completion
(A)
UE
Source
eNodeB
Serving
GW
PDN GW
MME
Target
eNodeB
Handover execution
Downlink and uplink data
Handover preparation
Forwarding of data
Downlink data
Uplink data
1 Path Switch Request
2 Modify Bearer Request
4 Modify Bearer Response
6 Path Switch Request Ack
7 Release Resource
Downlink data
5. End marker
5. End marker
8. Tracking Area Update procedure
3a Modify Bearer Request
3b Modify Bearer Response

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

6.2.5.1.1.3 Graceful Error Indication handling by eNodeB

Figure 86: 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
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 E-
RAB 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.

6.2.5.1.1.4 Graceful Error Indication handling by S-GW

Test Name: Graceful Error Indication Handling by S-GW
Test Objective: Validate the appropriate handling of the Error Indication by S-GW from a
enodeB
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
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 a S1-AP Uplink NAS Tansport encapsulating the NAS: Identity
Mode Command, with the Selected NAS Security Algorithms IE including EEA0,
EEAA1 or EEA2 for Ciphering as per the configuration
complete
Information Request
Validate that all kind of Data can be transferred on the default bearer on both of
directions for any traffic type.

3. Identification Request
1. Attach Request
new MME Old
MME/SGSN
Serving GW PCRF HSS
3. Identification Response
PDN GW
2. Attach
Request
eNodeB UE
4. Identity Request

4. Identity Response

5a. Authentication / Security

17. Initial Context Setup Request / Attach Accept
First Uplink Data
19. RRC Connection Reconfiguration Complete
18. RRC Connection Reconfiguration
20. Initial Context Setup Response
24. Modify Bearer Response
23. Modify Bearer Request
First Downlink Data
25. Notify Request
26. Notify Response
(B)
(A)
16. Create Session Response

12. Create Session Request
8. Update Location Request
9. Cancel Location
11. Update Location Ack
9. Cancel Location Ack
10. Delete Session Request

10. Delete Session Response
15. Create Session Response
7. Delete Session Response
7. Delete Sesion Request
First Downlink Data (if not handover)
(C)
EIR
5b. ME Identity Check

5b. Identity Request/Response

10. PCEF Initiated IP-CAN
Session Termination

7. PCEF Initiated IP-CAN
Session Termination

14. PCEF Initiated IP-CAN Session
Establishment/Modification

6. Ciphered Options Request
6. Ciphered Options Response
23a. Modify Bearer Request
23b. Modify Bearer Response
(D)
21. Direct Transfer
22. Attach Complete
(E)
(F)

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
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
Test Objective: Validate the successful data transfer with non-GBR Service and UM
Mode on eNodeB
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:

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
Test Objective: Validate the successful data transfer with GBR Service and AM Mode on
eNodeB
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:

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
Test Objective: Validate the successful data transfer with GBR Service and UM Mode on
eNodeB
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:

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
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 E-
RAB ID IE, the Transport Layer Address IE and the GTP-TEID IE
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
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
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.

Handover completion
(A)
UE
Source
eNodeB
Serving
GW
PDN GW
MME
Target
eNodeB
Handover execution
Forwarding of data
Downlink data
Uplink data
2 User Plane Update Request
4 User Plane Update Response
7 Release Resource
Downlink data
5. End marker
5. End marker
3a Update Bearer Request
3b Update Bearer Response

Figure 93: Successful X2 HO with single bearer

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
UE is in Active Mode in the source eNodeB with at least 1 E-RAB established
Test Procedure:
Initiate an X2-based HO to the target eNodeB.

Expected Results:
Verify that:
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.
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
can be released
changed
Validate that data traffic is continued with minimum disruption while ciphering is
being performed

Handover completion
(A)
UE
Source
eNodeB
Serving
GW
PDN GW
MME
Target
eNodeB
Handover execution
Forwarding of data
Downlink data
Uplink data
7 Release Resource
Downlink data
5. End marker
5. End marker

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

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
UE is in Active Mode in the source eNodeB with multiple E-RABs established
Test Procedure:
Initiate an X2-based HO to the former eNodeB.

Expected Results:
Verify that:
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
Target eNodeB. This message will include all the E-RABs to Be Switched in Uplink
can be released
changed

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
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
Target eNodeB 1. This message will include the E-RAB to Be Switched in Uplink
Target eNodeB 1 will send an X2-AP UE context Release message to the source
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.

Handover completion
(A)
UE
Source
eNodeB
Serving
GW
PDN GW
MME
Target
eNodeB
Handover execution
Forwarding of data
Downlink data
Uplink data
7 Release Resource
Downlink data
5. End marker
5. End marker

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.
UE is in Active Mode in the source eNodeB with multiple E-RABs established
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:

Expected Results:
Verify that:
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.
can be released
changed
source eNodeB) after the completion of X2 HO. Validate that only some of the E-
RABs 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)

Handover completion
(A)
UE
Source
eNodeB
Serving
GW
PDN GW
MME
Target
eNodeB
Handover execution
Forwarding of data
Downlink data
Uplink data
7 Release Resource
Downlink data
5. End marker
5. End marker

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 (E-
RABs 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
Test Objective: Validate the expected call flow for an unsuccessful HO via X2 interface
due to EPC failure
UE attached to the source eNodeB
Make EPC to be unable to with the path switch
Test Procedure:

Expected Results:
Verify that:
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
Test Objective: Validate the successful S1 based HO between two eNodeBs for single E-
RAB
UE is in Active Mode in the source eNodeB with at least 1 E-RAB established

Test Procedure:
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 E-
RABs 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 E-
RABs 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

MME
PDN GW
Serving GW

Target
eNodeB
Detach from old cell and
synchronize to new cell

Downlink User Plane data
2. Handover Required
1. Decision to trigger a
relocation via S1

5. Handover Command
Only for Direct forwarding of data
8. RRC Reconfig Complete
Downlink data

9. Handover Notify

13a. UE Context Release Command
Uplink User Plane data
13b. UE Context Release Complete
6. eNB Status Transfer
7. MME Status Transfer
3. Handover Request
4. Handover Request Ack
Admission Control

Switch DL Data Path

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
Test Objective: Validate the successful S1 based HO between two eNodeBs for multiple
E-RABs
UE is in Active Mode in the source eNodeB with at least two E-RABs established

Test Procedure:
Initiate traffic also for the rest of bearers (e.g ICMP)

Expected Results:
Verify that:
RABs to be setup List IE, containing all the E-RAB Ids
able to be established
sending back a S1-AP UE Context Release cOmplete
Validate that the data session continues with no noticeable disruption for all the
bearers

UE
Source
eNodeB

MME
PDN GW
Serving GW

Target
eNodeB

relocation via S1

5. Handover Command
Downlink data

9. Handover Notify

3. Handover Request
Admission Control

Switch DL Data Path

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
Test Objective: Validate the graceful behavior after a partially successful S1 based HO
between two eNodeBs for multiple E-RABs
Configure target eNodeB to accept only a subset of E-RABs

Test Procedure:
Initiate traffic also for the rest of bearers (e.g ICMP)

Expected Results:
Verify that:
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
sending back a S1-AP UE Context Release complete
Validate that the data session continues with no noticeable disruption for all the
bearers

UE
Source
eNodeB

MME
PDN GW
Serving GW

Target
eNodeB

relocation via S1

5. Handover Command
Downlink data

9. Handover Notify

3. Handover Request
Admission Control

Switch DL Data Path

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 E-
RABs 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
Test Objective: Validate the expected call flow for an unsuccessful S1 HO due to fail on
MME
Configure MME to reject the HO (e.g S1-AP between MME and Target eNodeB is
down)

Test Procedure:

Expected Results:
Verify that:
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
Test Objective: Validate that the PS Call will not drop after the S1 HO for single-RAB fails
because of no common ciphering algorithm
Configure target eNodeB and UE to not have ta common ciphering algorithm

Test Procedure:

Expected Results:
Verify that:
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

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
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
Configure target eNodeB to not accept any E-RAB and generage Handover
Failure message

Test Procedure:

Expected Results:
Verify that:
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

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
Test Objective: Validate the successful LTE to UTRAN HO in a single E-RAB
environment
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 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 Target SGSN
Serving GW
HSS
1. Handover Initiation
3. Forward Relocation Request
5. Relocation Request
5a. Relocation Request Acknowledge
8 . Create Indirect Data Forwarding Tunnel Request
7. Forward Relocation Response
PDN GW
8 a. Create Indirect Data Forwarding Tunnel Response
Uplink and Downlink User Plane PDUs

Target
Serving GW
4a. Create Session Response
6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
Source

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)

UE
Source
eNodeB
Serving GW
HSS PDN GW
1. Handover Command
2. HO from E-UTRAN Command
-
Sending of
uplink data
possible
4. UTRAN Iu Access Procedures
5. Relocation Complete
6. Forward Relocation Complete Notification
6a. Forward Relocation Complete Acknowledge
8a. Modify Bearer Response
Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)
4a. Handover to UTRAN Complete
Downlink User Plane PDUs
If Direct Forwarding applies
If Indirect Forwarding applies.
Target
Serving GW
(A)
Via Target SGSN in case Direct Tunnel is not used
10. Routeing Area Update procedure
(B)
11a. Delete Session Response
11b. Release Resources
For Serving GW relocation Steps 7, 8 and 9,
and the following User Plane path, will be
handled by Target Serving GW
12. Delete Indirect Data Forwarding Tunnel Request
Source
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
Test Objective: Validate the successful LTE to UTRAN HO in a multiple E-RABs
environment
UE is in Active Mode in the source eNodeB with 2 E-RABs established

Test Procedure:

Expected Results:
Verify that:
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)
Successful Handover
Validate that data transfer is continued via UTRAN and no resource is hold at LTE
eNodeB.

UE
Source
eNodeB
Serving GW
HSS
5a. Relocation Request Acknowledge
7. Forward Relocation Response
PDN GW
8 a. Create Indirect Data Forwarding Tunnel Response

Target
Serving GW
6. Create Indirect Data Forwarding Tunnel Request
Source

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)

UE
Source
eNodeB
Serving GW
HSS PDN GW
1. Handover Command
2. HO from E-UTRAN Command
-
Sending of
uplink data
possible
4. UTRAN Iu Access Procedures
5. Relocation Complete
Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)
4a. Handover to UTRAN Complete
Downlink User Plane PDUs
If Indirect Forwarding applies.
Target
Serving GW
(A)
Via Target SGSN in case Direct Tunnel is not used
10. Routeing Area Update procedure
(B)
11b. Release Resources
Source

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

Figure 108: LTE to UTRAN HO Failure due to connectivity issues
Test Name: LTE to UTRAN HO failure due to connectivity issues
Test Objective: Validate the inter RAT Failure for a UE does not release the UE context
in the EPC network
UE is in Active Mode in the source eNodeB
Bring down the link between MME and SGSN or the link between SGSN and RNC
to entail the HO to fail

Test Procedure:

Expected Results:
Verify that:
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.

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
Test Objective: Validate the inter RAT Failure for a UE does not release the UE context
in the EPC network
UE is in Active Mode in the source eNodeB
Configure the target NodeB to not allow any more calls (simulate overload
situation)

Test Procedure:

Expected Results:
Verify that:
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
Serving GW
HSS
6. Relocation Failure
.8. Forward Relocation Response (Reject)
PDN GW
Target
Serving GW
9. Handover Preparation Failure
Source

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

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
Test Objective: Validate the successful CS-Fallback to UTRAN network triggered by the
mobile originated call while the UE is in Idle Mode
UE is in Idle Mode
VoIP Services are not available

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
Successful Handover
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
MME BSS /RNS
MSC eNodeB
2. Optional Measurement Report Solicitation

10b. Location Area Update
10a. Service Reject
10c. CS MO call

6. UE changes RAT then LA Update or Combined RA/LA Update or RA Update or LAU and RAU
3 a . NACC ,
5. S1 UE Context Release
1a. NAS Extended Service Request
SGW/PGW
4. S1 - AP: S1 UE Context Release Request
1b. S1 - AP UE Context Modification Request with CS Fallback indicator
7 a. Suspend (see 23.060)
8 . Update bearer(s)
SGSN
7b. Suspend Request / Response
11. Routing Area Update or Combined RA/LA Update

3b, 3c . RRC connection release
If the MSC
is changed

1c. S1 - AP UE Context Modification Response message
9. CM Service Request 9. A/Iu-cs message (with CM Service Request)

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
terminated call, UE in Idle Mode
mobile terminated call while the UE is in Idle Mode
UE is in Idle Mode
Test Procedure:
Initiate a mobile terminated speech call
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
cell
Successful Handover
performed.

1. IAM
3. IAM
4. Paging Request
5. Paging
6. Paging
2. SRI procedure in TS 23.018
G-MSC
eNodeB RNC/BSC UE MME
HSS
MSC
VLR
7a. Extended Service Request
7b. Initial UE Context Setup
7a. Service Request

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:

4a. Location Area Update or Combined RA/LA
Update
4b. Paging Response
4b. A/Iu-cs message (with Paging Response)
5b. Signalling Connection Release 5b. Connection Reject
If the MSC
is changed
5b. Location Area Update or Combined RA/LA Update
5c. CS call establishment procedure
6. PS HO as specified in 23.401 [2] (continuation of execution phase)
5a. Establish CS
connection
Option 1:
MSC is not
changed
3c. Update Bearer(s)
3b. Suspend
P-GW/
GGSN
3a. PS HO as specified in 23.401 [2] (preparation phase and start of execution phase)
1e. S1-AP UE Context Modification Response message
1d. S1-AP UE Context Modification Request with CS Fallback indicator
UE/MS
MME BSS/RNS
MSC
eNodeB SGSN
Serving
GW
1b. NAS Extended Service Request
1a. Paging Request
1a. CS Paging Notification
1c. CS Paging Reject
1a. Service Request

Figure 112: LTE to UTRAN CS-Fallback (Execution Phase with PS HO
supported)
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:

IF THE
MSC IS
CHANGED
UE/MS
MME
MSC
3a. CCO/NACC, 3b, 3c. Signalling connection release
eNodeB
2. Optional Measurement Report
9. Paging Response
9c. Location Area Update or Combined RA/LA Update
9b. Signalling Connection Release
S-GW/PGW
7a. Suspend (see TS 23.060)
8. Update bearer(s)
9b. CONNECTION REJECT
1A. CS SERVICE NOTIFICATION
1A. PAGING REQUEST
SGSN
6.UE changes RAT then, LAU OR COMBINED RA/LA UPDATE OR RA UPDATE OR LAU AND RAU
5. S1 UE CONTEXT RELEASE
BSS/RNS
4. S1-AP: S1 UE CONTEXT RELEASE REQUEST
1A. SERVICE REQUEST
9a. Establish CS connection

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

Originated Call, UE in Active Mode
originated call, UE in Idle Mode
Reference: TS 23.272 sections 6.2 and 6.3
mobile originated call while the UE is in Idle Mode
UE is in Active mode transmitting data

Test Procedure:
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
cell
Successful Handover
performed.

UE/ MS
MME BSS /RNS
MSC eNodeB

10b. Location Area Update
10a. Service Reject
10c. CS MO call

6. UE changes RAT then LA Update or Combined RA/LA Update or RA Update or LAU and RAU
3 a . NACC ,
5. S1 UE Context Release
1a. NAS Extended Service Request
SGW/PGW
4. S1 - AP: S1 UE Context Release Request
1b. S1 - AP UE Context Modification Request with CS Fallback indicator
7 a. Suspend (see 23.060)
8 . Update bearer(s)
SGSN
11. Routing Area Update or Combined RA/LA Update

3b, 3c . RRC connection release
If the MSC
is changed

1c. S1 - AP UE Context Modification Response message
9. CM Service Request 9. A/Iu-cs message (with CM Service Request)

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

Terminated Call, UE in Active Mode
terminated call, UE in Active Mode
Reference: TS 23.272 sections 7.3 and 7.4
mobile terminated call while the UE is in Active Mode
UE is in Active mode transmitting data

Test Procedure:
release the CS call

If the eNodeB knows that PS HO is supported, then the procedure following this call flow is:

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
cell
Successful Handover
performed.

4a. Location Area Update or Combined RA/LA
Update
4b. Paging Response
4b. A/Iu-cs message (with Paging Response)
5b. Signalling Connection Release 5b. Connection Reject
If the MSC
is changed
5b. Location Area Update or Combined RA/LA Update
5c. CS call establishment procedure
6. PS HO as specified in 23.401 [2] (continuation of execution phase)
5a. Establish CS
connection
Option 1:
MSC is not
changed
3c. Update Bearer(s)
3b. Suspend
P-GW/
GGSN
3a. PS HO as specified in 23.401 [2] (preparation phase and start of execution phase)
UE/MS
MME BSS/RNS
MSC
eNodeB SGSN
Serving
GW
1a. Paging Request
1a. CS Paging Notification
1a. Service Request

Figure 115: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode
(Preparation Phase)
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:

IF THE
MSC IS
CHANGED
UE/MS
MME
MSC
3a. CCO/NACC, 3b, 3c. Signalling connection release
eNodeB
2. Optional Measurement Report
9. Paging Response
9c. Location Area Update or Combined RA/LA Update
9b. Signalling Connection Release
S-GW/PGW
7a. Suspend (see TS 23.060)
8. Update bearer(s)
9b. CONNECTION REJECT
1A. CS SERVICE NOTIFICATION
1A. PAGING REQUEST
SGSN
6.UE changes RAT then, LAU OR COMBINED RA/LA UPDATE OR RA UPDATE OR LAU AND RAU
5. S1 UE CONTEXT RELEASE
BSS/RNS
4. S1-AP: S1 UE CONTEXT RELEASE REQUEST
1A. SERVICE REQUEST
9a. Establish CS connection

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
Test Objective: Validate the successful SRVCC when the UE has a VoIP call ongoing
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:
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
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
Successful Handover
Validate that voice call is ongoing via UTRAN

UE Source
E-UTRAN
Source
MME
MSC Server/
MGW
Target
MSC
14. Handover Command
Target
BSS
1. Measurement reports
SGW
2. Decision for HO
5.PS to CS Req
6.Prep HO Req
7. HO Request/Ack
8.Prep HO Resp
9. Establish circuit
19. HO Complete
20.SES (HO Complete)
21. ANSWER
13.PS to CS Resp
15. HO from EUTRAN command
HSS/
HLR
23.UpdateLoc
10. Initiation of Session Transfer (STN-SR or E-STN-SR)
11. Session transfer
and Update remote end
IMS
(SCC AS)
12. Release of IMS
access leg
22. PS to CS Complete/Ack
Target
SGSN
16. UE tunes to GERAN
17. HO Detection
18. Suspend (see TS 23.060)
18. Suspend
18. Suspend Request / Response
18. Update Bearer
4. Bearer Splitting
GMLC
24. Subscriber Location Report

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
Test Objective: Validate the successful SRVCC when the UE has both data transfer and
VoIP calls ongoing
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:
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 Target RNC send Relocation Request Acknowledge to MSC
o MSC Server sends SRVCC PS to CS Response to MME
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 MSC sends a SRVCC PS to CS Complete Notification to MME
o MME sends SRVCC PS to CS Complete Notification Ack to MSC Server
Successful Handover
Validate that Data Transfer and voice call are ongoing via UTRAN

13. Handover Command
1. Measurement reports
2. Decision for HO
5a. PS to CS Req
17a. Reloc/HO Complete
17b. SES (HO Complete)
17c. ANSWER
12. PS to CS Resp
18a. Reloc/HO Complete
18c. Update bearer
HSS/
HLR
17e. UpdateLoc
5b. Prep HO
Req
8b. Prep HO Resp
8c. Establish circuit
6a. Forward Reloc Req
6b. Reloc /HO Req
5c. Reloc /HO Req
8a. Reloc /HO Req Ack
7b. Forward Reloc Resp
7a. Reloc /HO Req Ack
11. Release of IMS access
leg
10. Session transfer and
update remote leg
9. Initiation of Session Transfer (STN-SR or E-STN-SR)
UE Source
E-UTRAN
Source
MME
MSC Server/
MGW
Target
MSC
Target
RNS/BSS
SGW IMS
(SCC AS)
Target
SGSN
14. HO from EUTRAN command
17d. PS to CS Complete/Ack
18b. Forward Reloc Complete/Ack
16. HO Detection
4. Bearer Splitting
15. UE tunes to
UTRAN/GERAN
GMLC
19. Subscriber Location Report

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
Test Objective: Validate the successful inter RAT Handover for a UE with a single RAB
from UTRAN to LTE
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 E-
RABs 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 HSS
2. Relocation Required
5. Handover Request

5a. Handover Request Acknowledge
7 . Forward Relocation Response
PDN
GW
Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)


6 a . Create Indirect Data Forwarding Tunnel Response

Target
Serving GW

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
PDN
GW
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
6. Handover Notify
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
If Indirect Forwarding applies
Target
Serving GW
(A)
(B)
12b. Iu Release Procedure
Sending of
uplink data
possible
Via Source SGSN in case Direct Tunnel is not used
Source

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
Test Objective: Validate the successful inter RAT Handover for a UE with multiple RABs
from UTRAN to LTE
UE has established at least 2 RABs

Test Procedure:
Initiate data transfer of a big file over each RAB
Verify that the data transfer continue for the two RABs after the inter RAT HO is
completed

Expected Results:
Verify that:
List IE group contains all the RAB-IDs
eNodeB sends a S1-AP Handover Request Acknowledge containing the same E-
RABs 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 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
5. Handover Request

5a. Handover Request Acknowledge
7 . Forward Relocation Response
PDN
GW


6 a . Create Indirect Data Forwarding Tunnel Response

Target
Serving GW

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
PDN
GW
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
6. Handover Notify
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
If Indirect Forwarding applies
Target
Serving GW
(A)
(B)
12b. Iu Release Procedure
Sending of
uplink data
possible
Via Source SGSN in case Direct Tunnel is not used
Source

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
Test Objective: Validate the call flow for an unsuccessful Inter RAT HO for a UE due to
no resources at the eNodeB
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
Verify that the inter RAT HO fails but that the data transfer does not stop due to
this failure.

Expected Results:
Verify that:
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 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
Serving GW
HSS
5. Handover Request
6. Handover Failure
8. Forward Relocation Response (Reject)

PDN
GW

Target
Serving GW

9. Relocation Preparation Failure
Source

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

Lte Detail - S1 Interface

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Lte Detail - S1 Interface

Diunggah oleh

Hak Cipta:

Format Tersedia

Long Term Evolution - Evolved Packet Core

S1 Interface Conformance Test Plan

Anda mungkin juga menyukai