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 25: Trace Failure Indication Procedure ................................................................ 40 Figure 26: Deactivate Trace ............................................................................................. 41 Figure 27: Trace Failure Indication Procedure ................................................................ 42 Figure 28: Location Reporting Control Procedure - Successful Operation ..................... 43 Figure 29: Location Report Failure Indication Procedure ............................................... 44 Figure 30: Location Reporting Control Procedure - Successful Operation ..................... 45 Figure 31: Location Report Procedure - Successful Operation ....................................... 46 Figure 32: Location Report Failure Indication ................................................................ 46 Figure 33: Location Reporting Control Procedure - Successful Operation ..................... 47 Figure 34: Location Report Failure Indication Procedure ............................................... 48 Figure 35: Successful EPS Attach with UE unknown in MME and No Ciphering ......... 51 Figure 36: Successful EPS Attach with MME unknown in MME and Ciphering ........... 54 Figure 37: Successful EPS Attach procedure with UE known in MME and No Ciphering ................................................................................................................................... 56 Figure 38: Successful EPS Attach with UE known in MME and Ciphering .................... 58 Figure 39: Successful EPS Attach with IMSI ................................................................... 60 Figure 40: Unsuccessful EPS Attach due to IMSI unknown on HSS ............................... 62 Figure 41: Successful EPS detach initiated by UE ........................................................... 63 Figure 42: Successful EPS Detach initiated by UE due to switch off .............................. 65 Figure 43: Successful EPS Detach initiated by MME ...................................................... 67 Figure 44: Successful E-RAB establishment for single E-RAB ....................................... 68 Figure 45: Successful E-RAB establishment for single E-RAB with UE Maximum Aggregate IE included .............................................................................................. 70 Figure 46: Successful E-RAB establishment for Multiple E-RABs ................................. 71 Figure 47: Successful E-RAB modification for single E-RAB ........................................ 73 Figure 48: Successful E-RAB Modification for multiple E-RABs .................................. 74 Figure 49: Successful and Unsuccessful E-RAB Modification for Multiple E-RABs ..... 76 Figure 50: E-RAB Release Initiated by MME .................................................................. 77 Figure 51: E-RAB Release initiated by eNodeB .............................................................. 79 Figure 52: Successful Dedicated Bearer Activation initiated by the network .................. 81 Figure 53: Successful Bearer Activation initiated by the UE ........................................... 83 Figure 54: Successful Bearer Activation during Attach ................................................... 85 Figure 55: PGW Initiated Bearer Modification with QoS Update ................................... 86 Figure 56: HSS initiated Subscriber QoS Modification ................................................... 87 Figure 57: Network Initiated Bearer Modification without QoS ...................................... 89 Figure 58: UE Requested Bearer Modification Accepted by the Network ...................... 91 Figure 59: UE Requested Bearer Modification without QoS Update accepted by the Network ..................................................................................................................... 93 Figure 60: PGW Initiated Dedicated Bearer Deactivation ............................................... 94 Figure 61: MME initiated Dedicated Bearer Deactivation ............................................... 96 Figure 62: UE initiated Dedicated Bearer Deactivation ................................................... 97 Figure 63: UE/eNodeB Context Release initiated due to UE inactivity with single bearer established ................................................................................................................. 99 Figure 64: UE/enodeB Context Release initiated due to UE inactivity with multiple bearers established .................................................................................................. 101 Figure 65: UE Context Release due to Radio connection with UE lost ......................... 102 Figure 66: Normal Tracking Area Update ...................................................................... 104 Figure 67: Normal Tracking area Update with bearer establishment requested ............. 106 Figure 68: Combined Tracking and Location Area Update ............................................ 108 Figure 69: Combined Tracking and Location Area Update with IMSI attach ............... 110 Figure 70: Combined Tracking and Location Area Update with bearer establishment requested ................................................................................................................. 112 Figure 71: Periodic Tracking area Update ...................................................................... 114 Figure 72: Tracking Area Update rejected due to "No EPS Bearer context activated" .. 116 Figure 73: Tracking Area Update rejected due to "implicitly detached" ........................ 118 Figure 74: Paging with Paging DRX IE ......................................................................... 119 Figure 75: Paging without Paging DRX IE .................................................................... 120 Figure 76: Successful Service Requested when UE receives a pacging request with CN Domain set to "PS" (Singel bearer) ........................................................................ 122 Figure 77: Successful Service Requested when UE receives a paging request with CN Domain indicator set to "PS" (Multiple bearers) .................................................... 124 Figure 78: Successful Service Request when UE has pending user data to be sent (Single Bearer) ..................................................................................................................... 126 Figure 79: Successful Service Request when the UE has pending user to be sent (Multiple Bearers) ................................................................................................................... 128 Figure 80: Successful Service Request when UE has uplink signaling pending in Idle Mode ....................................................................................................................... 130 Figure 81: Successful Service Request when UE is in Idle mode and has a mobile originating 1xCS fallback request ........................................................................... 132 Figure 82: Successful Service Request when UE is in Active Mode and has a mobile originating 1xCS fallback request ........................................................................... 134 Figure 83: Successful Initial UE message with Emergency Flag enabled ...................... 135 Figure 84: GTP-U Echo mechanism ............................................................................... 136 Figure 85: GTP-U message "End of Marker" ................................................................. 138 Figure 86: Graceful Error Indication handling by eNodeB ............................................ 139 Figure 87: Graceful Error Indication handling by SGW ................................................ 141 Figure 88: Data Transfer on Default Bearer ................................................................... 143 Figure 89: Data Transfer on Dedicated Bearer with non-GBR Service and AM Mode . 145 Figure 90: Data Transfer on Dedicated Bearer with non-GBR service and UM Mode . 147 Figure 91: Data Transfer on Dedicated Bearer with GBR Service and AM Mode ........ 149 Figure 92: Data Transfer on Dedicated Bearer with GBR Service and UM Mode ........ 151 Figure 93: Successful X2 HO with single bearer ............................................................ 154 Figure 94: Successful HO with single E-RAB via X2 with Ciphering ........................... 156 Figure 95: Successful X2 HO with Multiple E-RABs .................................................... 159 Figure 96: Partially Successful HO via X2 interface with Multiple E-RABs ................ 161 Figure 97: Unsuccessful X2 HO Due to EPC Failure ..................................................... 163 Figure 98: Successful S1 HO with Single E-RAB.......................................................... 165 Figure 99: Successful S1 HO with Multiple E-RABs .................................................... 167 Figure 100: Partially Successful S1 HO with Multiple E-RABs .................................... 170 Figure 101: Unsuccessful S1 HO due to fail on MME-Target eNodeB connectivity .... 172 Figure 102: Unsuccessful S1 HO due to non common Ciphering algorithm ................. 174 Figure 103: Unsuccessful S1 based HO due to no resources available at target eNodeB ................................................................................................................................. 176 Figure 104: Successful LTE to UTRAN HO for single E-RAB (Preparation Phase) ... 178 Figure 105: Successful LTE to UTRAN HO for single E-RAB (Execution Phase) ...... 179 Figure 106: Successful LTE to UTRAN HO for Multiple E-RABs (Preparation Phase) ................................................................................................................................. 181 Figure 107: Successful LTE to UTRAN HO with Multiple E-RABs (Execution Phase) ................................................................................................................................. 182 Figure 108: LTE to UTRAN HO Failure due to connectivity issues ............................. 183 Figure 109: LTE to UTRAN HO failure due to not resources at NodeB ....................... 185 Figure 110: LTE to UTRAN CS-Fallback: MO call, UE in Idle Mode ......................... 188 Figure 111: LTE to UTRAN CS-Fallback: MT Call, UE in Idle Mode (Preparation Phase) ................................................................................................................................. 191 Figure 112: LTE to UTRAN CS-Fallback (Execution Phase with PS HO supported) .. 192 Figure 113: LTE to UTRAN CS-Fallback (Execution Phase without PS HO Supported) ................................................................................................................................. 193 Figure 114: LTE to UTRAN CS-Fallback, MO Call, UE in Active Mode .................... 196 Figure 115: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Preparation Phase) ...................................................................................................................... 199 Figure 116: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Execution Phase) without PS HO Support ............................................................................... 200 Figure 117: LTE to UTRAN SRVCC, Inter RAT HO for VoIP Call ............................. 203 Figure 118: LTE to UTRAN SRVCC, Inter RAT HO for Data Transfer with VoIP Call ................................................................................................................................. 205 Figure 119: Successful UTRAN to LTE Inter RAT HO for a single RAB (Preparation Phase) ...................................................................................................................... 207 Figure 120: Successful UTRAN to LTE Inter RAT HO for a single RAB (Execution Phase) ...................................................................................................................... 208 Figure 121: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Preparation Phase) ...................................................................................................................... 210 Figure 122: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Execution Phase) ...................................................................................................................... 211 Figure 123: UTRAN to LTE Inter RAT HO failure due to no resources at eNodeB ..... 213
1 Scope This document defines a proposal for the test suite to be used for S1 Interface Conformance testing. The goal is ensuring a graceful integration and interoperability between eNodeB-MME and eNodeB-SGW from different vendors. 2 References [1] 3GPP TS 36.413 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)
[2] 3GPP TS 29.281 Technical Specification Group Core Network and Terminals; General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)
[3] 3GPP TS 36.300 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
[4] 3GPP TS 23.401 Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
[5] 3GPP TS 36.331 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRAN); Radio Resource Control (RRC) Protocol Specification
[6] 3GPP TS 23.009 Technical Specification Group Core Network and Terminals; Handover procedures
[7] 3GPP TS 24.301 Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
[8] 3GPP TS 24.008 Technical Specification Group Core Network and Terminals; 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.
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.
Test Name: Unsuccessful establishment of SCTP association between eNodeB and MME in a single PLMN Id Configuration References: TS 36.413, Section 8.7.3.3 Test Objective: Verify the the graceful failure of S1 setup establishment between eNodeB and MME Pre-Test Conditions: MME is configured with S1 parameters different than the one configures on eNodeB (different TAC or different PLMN Id) eNodeB is configured with S1 parameters different than the one configured on MME (different TAC or different PLMN Id) Verify IP connectivity between the two nodes Test Procedure: Power on the MME and eNodeB Trigger eNodeB to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by eNodeB by sending a S1 setup Request message, including the TAC and the configured PLMN Identity included into the Broadcast PLMNs IE, MME responds with the S1 setup failure including the reason of the unsuccessful establishment (e.g unknown TAC, unknown PLMN Id, etc) No resource is hold by any network element after the unsuccessful S1 establishment
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 References: TS 36.413, Section 8.7.3.2 Test Objective: Verify the successful establishment of the SCTP and S1 connection between eNodeB and MME as well as the periodic path heartbeat to monitor the link in a MOCN configuration Pre-Test Conditions: MME is configured with the SCTP and S1 parameters eNodeB is configured with the SCTP and S1 parameters Both of the nodes shall be configured with the SCTP path heartbeat timer Verify IP connectivity between the two nodes Test Procedure: Power on the MME and eNodeB Trigger eNodeB to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by eNodeB by sending a S1 setup Request message, including the TAC and the configured PLMN Identitier included into the Broadcast PLMNs IE, MME responds with the S1 setup response message acknowledging the connectivity and including the same PLMN Identitier S1 connectivity is successfully established between eNodeB and MME. SCTP heartbeats messages are exchanged successfully between both of the nodes according to the timers configured.
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 References: TS 36.413, Section 8.7.3.3 Test Objective: Verify the the graceful failure of S1 setup establishment between eNodeB and MME Pre-Test Conditions: MME is configured with S1 parameters different than the one configures on eNodeB (different TAC Ids) eNodeB is configured with S1 parameters different than the one configured on MME (different TAC Ids) Verify IP connectivity between the two nodes Test Procedure: Power on the MME and eNodeB Trigger eNodeB to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by eNodeB by sending a S1 setup Request message, including the TAC and the configured PLMN Identitier included into the Broadcast PLMNs IE, MME responds with the S1 setup failure including the reason of the unsuccessful establishment (e.g unknown TAC, unknown PLMN Id, etc) No resource is hold by any network element after the unsuccessful S1 establishment
Figure 10: MME Configuration Update Procedure: Successful Operation Test Name: Successful MME Configuration Update References: TS 36.413, Section 8.7.5.2 Test Objective: Validate the successful application level configuration data update when initiated by MME Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Verify IP connectivity between the two nodes Test Procedure: Trigger MME to initiate the S1 Setup Update by changing the configuration (eg change the name of MME or changing the MME relative capacity) Expected Results: Verify that: Validate that MME sends a S1-AP:MME Configuration Update including the new parameters (e.g new MME name, or new MME relative capacity) Validate that eNodeB is acknowledging the update by sending back a S1-AP MME Configuration Update Acknowledge to MME
Test Name: Unsuccessful MME Configuration Update References: TS 36.413, Section 8.7.5.3 Test Objective: Validate the graceful unsuccessful application level configuration data update when initiated by MME Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Make sure eNodeB is not configured to accept the PLMN-ID that MME will send during the S1 MME Configuration Update. Verify IP connectivity between the two nodes Test Procedure: Trigger MME to initiate the S1 Setup Update by changing the configuration including a parameter not acceptable by eNodeB (eg unknown PLMN in enodeB) Expected Results: Verify that: Validate that MME sends a S1-AP:MME Configuration Update including the new parameters (e.g new PLMN-ID) Validate that eNodeB is sending back a S1-APL MME configuration Update Failure including the reason of the unsuccessful S1 update.
Figure 12: ENB Configuration Update Procedure: Successful Operation Test Name: Successful eNodeB Configuration Update References: TS 36.413, Section 8.7.4.2 Test Objective: Validate the successful application level configuration data update between eNodeB and MME when is initiated by eNodeB Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Verify IP connectivity between the two nodes Test Procedure: Trigger eNodeB to initiate the S1 Setup Update by changing the configuration (eg supported TAC change in eNodeB) Expected Results: Verify that: Validate that eNodeB sends a S1-AP:EnodeB Configuration Update including the new parameters (e.g new TAC supported) Validate that MME is acknowledging the update by sending back a S1-AP eNodeB Configuration Update Acknowledge to eNodeB Validate that new S1 parameters have been successfully negotiated at both of the nodes.
Test Name: Unsuccessful eNodeB Configuration Update References: TS 36.413, Section 8.7.4.3 Test Objective: Validate the graceful unsuccessful application level configuration data update between eNodeB and MME when is initiated by eNodeB Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Verify IP connectivity between the two nodes Test Procedure: Trigger eNodeB to initiate the S1 Setup Update by changing the configuration to one which MME can not accept (e.g TAC change to unknown TAC in MME) Expected Results: Verify that: Validate that eNodeB sends a S1-AP:EnodeB Configuration Update including the new parameters (e.g new TAC supported) Validate that MME is sending back a S1-SP enodeB configuration update failure including the reason of the unsuccessful S1 update.
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 Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Verify IP connectivity between the two nodes Test Procedure: Trigger eNodeB to send a S1 Reset to MME
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Reset to MME Validate that MME sends back a S1-AP Reset Acknowledge message Validate that MME is releasing all allocated resources on S1 related to the UE and removing the S1AP ID for all the UE associations.
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 References: TS 36.413, Section 8.7.1.2.1 Test Objective: Validate the successful reset initiated by MME and the consequent initialization of the eNodeB Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME Verify IP connectivity between the two nodes Test Procedure: Trigger MME to send a S1 Reset to eNodeB
Expected Results: Verify that: Validate that MME sends a S1-AP Reset to eNodeB Validate that eNodeB sends back a S1-AP Reset Acknowledge message Validate that eNodeB is releasing all allocated resources on S1 related to the UE and removing the S1AP ID for all the UE associations.
6.1.1.6 S1 Recovery after nodes failure
6.1.1.6.1 S1 Recovery after eNodeB restart
Test Name: S1 recovery after eNodeB restart References: TS 36.413, Section 8.7.1.2.2 Test Objective: Validate the S1 recovers successfully from the unexpected restart of the eNodeB Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Trigger the eNodeB to restart as in case of a failure (e.g power cycling) If no failure can be triggered, the pre-condition can be to execute a normal restart as in test case 6.1.1.5.1). Test Procedure: Initiated the system restart from eNodeB (preferably by emulating is unexpected, failure e.g power cycle-).
Expected Results: Verify that: If the failure does allow the eNodeB to send the S1 Reset: o Verify that eNodeB sends S1-AP: S1 RESET to MME o Verify that MME acknowledges by sending back a S1-AP: S1 RESET acknowledgement to eNodeB o Validate that all the resources have been released after the restart Validate that the S1 recovers from the restart, eNodeB is sending a S1-AP S1 SETUP REQUEST Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP RESPONSE Validate that UE can reestablish the context and resume the data transfer successfully
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 References: TS 36.413, Section 8.7.1.2.1 Test Objective: Validate the S1 recovers successfully from the unexpected restart of the MME Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Trigger the MME to restart as in case of a failure (e.g power cycling) If no failure can be triggered, the pre-condition can be to execute a normal restart as in test case 6.1.1.5.2). Test Procedure: Initiated the system restart from MME (preferably by emulating is unexpected, failure e.g power cycle-). Expected Results: Verify that: If the failure does allow the MME to send the S1 Reset o Verify that MME sends S1-AP: S1 RESET to eNodeB o Verify that eNodeB acknowledges by sending back a S1-AP: S1 RESET acknowledgement to MME o Validate that all the resources have been released after the restart Validate that the S1 recovers from the restart, eNodeB is sending a S1-AP S1 SETUP REQUEST Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP RESPONSE Validate that UE can reestablish the context and resume the data transfer successfully
MME eNB RESET RESET ACKNOWLEDGE
Figure 17: Reset Procedure Initiated From the MME Successful Operation
6.1.1.6.3 S1 Recovery after SGW restart
Test Name: S1 recovery after S-GW restart while data transfer is ongoing References: TS 36.413, Section 8.3.3.2 Test Objective: Validate the S1-U recovers successfully from the unexpected restart of the S-GW Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Initiated the system restart from S-GW (emulate is unexpected, failure)
Expected Results: Verify that: Verify that, when S-GW restarts, GTP-U may send a notification to the higher layer and O&M entities Verify that, upon S-GW reinitialization, the data can be resumed successfully. If no same Tunnel Endpoints are honored at both of directions, GTP-U error indication will be sent to the other end to indicate about the Tunnel ID mismatch. This procedure may involve a UE Context release from MME (S-GW can notify MME via S11) and UE context setup to re-activate the UE context successfully. In Figure 18, UE context successfully established is not an actual procedure within the 3GPP S1-AP specs. The message UE Context is successfully established is meant to indicate that there are a collection of procedures executed in order to resume UE operation.
UE CONTEXT is successfully established UE CONTEXT RELEASE COMMAND eNB MME UE CONTEXT RELEASE COMPLETE
6.1.1.6.4 S1 Recovery from S1 failure due to physical connections lost
Test Name: S1 recovery from S1 failure due to transmission network failure (physical connections lost) References: TS 36.413, Section 8.7.3.2 Test Objective: Validate the S1 recovers successfully from a physical connection failure Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Cause a failure on all the physical links carrying S1, for example by disconnecting the cable or shutting down the interface Reconnect the cable before eNodeB and MME triggers RESET failure (if disconnection of the cable, eNodeB and MME will not trigger RESET)
Expected Results: Verify that: Message flow may depend on the vendor implementation Expected behavior is eNodeB to start a S1 SETUP REQUEST to MME, MME to acknowledge and UE context activation is being successfully re-established after the physical link recovery UE can resume the data transmission and no resource from previous call is hold by any network element
Test Name: MME requests the eNodeB to start a trace supporting S1 interface and minimum depth References: TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2 Test Objective: Validate that MME is able to request the eNodeB to start a trace session that supports S1 interface and minimum depth Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Send the trace control and configuration parameters from the MME. A trigger may be manually initiated or received from HSS by using a ISDR message including the trace control parameters Validate that eNodeB is subsequently tracing the UE accordingly
Expected Results: Verify that: MME sends S1-AP Trace Start including a Trace Activation IE containing the Interfaces To Trace IE with the S1-MME bit set and the Trace depth IE set to minimum Validate that eNodeB starts tracing the UE accordingly. The eNodeB will send to MME a S1-AP Cell Traffic Trace including the requested tracing information Validate that MME can manage the Cell Traffic message according to the protocol and is capable of interpreting the tracing information reported by eNodeB.
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure indication by including the reason of why the tracing control procedure was failed. In that case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace Start message originally sent by MME
Figure 23: Trace Start Procedure Test Name: MME requests the eNodeB to start a trace supporting X2 interface and minimum depth References: TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2 Test Objective: Validate that MME is able to request the eNodeB to start a trace session that supports X2 interface and minimum depth Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Send the trace control and configuration parameters from the MME. A trigger may be manually initiated or received from HSS by using a ISDR message including the trace control parameters Validate that eNodeB is subsequently tracing the UE accordingly
Expected Results: Verify that: MME sends S1-AP Trace Start including a Trace Activation IE containing the Interfaces To Trace IE with the X2 bit set and the Trace depth IE set to minimum Validate that eNodeB starts tracing the UE accordingly. The eNodeB will send to MME a S1-AP Cell Traffic Trace including the requested tracing information Validate that MME can manage the Cell Traffic message according to the protocol and is capable of interpreting the tracing information reported by eNodeB.
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure indication by including the reason of why the tracing control procedure was failed. In that case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace Start message originally sent by MME
Test Name: MME requests the eNodeB to stop the trace session References: TS 36.413, Sections 8.10.3.2 & 8.10.2.2 Test Objective: Validate that MME is able to request the eNodeB to stop the trace session Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing eNodeB is currently tracing the S1 and/or X2 interfaces (MME previously sent a S1-AP Trace Start message by enabling the interfaces to be monitored) Verify IP connectivity between the two nodes Test Procedure: Send the deactivate trace control and configuration parameters from the MME. A trigger may be manually initiated or received from HSS by using a ISDR message including the trace control parameters Validate that eNodeB is subsequently stopping the tracing for the UE accordingly
Expected Results: Verify that: MME sends S1-AP Deactivate Trace by including the same E-UTRAN Trace ID IE that was notified by MME when the trace control was started (same value than the one included into the S1-AP Start Trace message) Validate that eNodeB stops tracing the UE accordingly
Remark: If the tracing control failed, the eNodeB shall send to MME a S1-AP Trace Failure indication by including the reason of why the tracing control procedure was failed. In that case, the E-UTRAN Trace ID value shall be the same as the TraceID included into the Trace Start message originally sent by MME
MME eNB TRACE FAILURE INDICATION
Figure 27: Trace Failure Indication Procedure
6.1.2.2 Location Reporting Procedures 6.1.2.2.1 Successful location reporting for a direct report of the UE location
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 References: TS 36.413, Sections 8.11.1.2 & 8.11.2.2 Test Objective: Validate that MME is able to request the eNodeB to report where the UE is currently located Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Initiate the location reporting for a direct location report for the UE Validate that eNodeB is subsequently reporting the current location of the UE
Expected Results: Verify that: MME sends a S1-AP: Location Reporting Control by including a Request Type IE with Event IE=Direct and Report Area IE=ECGI eNodeB is subsequently sending a S1:AP Location Report message with a 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)
6.1.2.2.2 Successful location reporting for serving cell change
eNB LOCATION REPORTING CONTROL MME
Figure 30: Location Reporting Control Procedure - Successful Operation
Test Name: Successful location reporting for serving cell change References: TS 36.413, Sections 8.11.3.2, 8.11.1.2, & 8.11.2.2 Test Objective: Validate that MME is able to request the eNodeB to report whenever a UE changes cells, and the eNodeB sends a location report with the correct service area identifier when that event happens Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Initiate the location reporting for a serving cell change for the UE Move the UE to another cell
Expected Results: Verify that: MME sends a S1-AP: Location Reporting Control by including a Request Type IE with Event IE=Change of Service Cell and Report Area IE=ECGI Verify that when the UE moves to a new cell the eNodeB is sending a S1:AP Location Report message with a E-UTRAN CGI IE indicating the cell where the UE is located. The Location Report message also includes a TAI IE indicating the tracing area where the UE is located and a Request Type IE including Event IE=Change of Service cell And Report Area IE=ECGI
Remark: If the location report control failed, the eNodeB shall send to MME a S1-AP Location Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a ongoing HO)
6.1.2.2.3 Successful cancellation of location reporting for serving cell change
eNB LOCATION REPORTING CONTROL MME
Figure 33: Location Reporting Control Procedure - Successful Operation
Test Name: Successful cancellation of location reporting for serving cell change References: TS 36.413, Sections 8.11.1.2 & 8.11.2.2 Test Objective: Validate that MME is able to request the eNodeB to stop reporting whenever a UE changes cells, and the eNodeB sends a location report with the correct service area identifier when that event happens Note: This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is at least one UE attached with active context and data transfer is ongoing Currently the location reporting is active for a serving cell change. Verify IP connectivity between the two nodes Test Procedure: Initiate the cancel of the location reporting for serving cell change for the UE Move the UE to another cell
Expected Results: Verify that: During the cancellation of the location reporting, the MME sends a S1-AP: Location Reporting Control by including a Request Type IE with Event IE=Stop Change of Service Cell and Report Area IE=ECGI Verify that when the UE moves to a new cell the eNodeB not sending any S1-AP Location Report message.
Remark: If the location report control failed, the eNodeB shall send to MME a S1-AP Location Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a ongoing HO)
6.2.1.1 Successful EPS Attach with UE unknown in MME and no Ciphering
Test Name: Successful EPS Attach with the UE unknown in MME and no Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the ciphering is disabled Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached and no context exists for the UE Ciphering is disabled GUTI is unknown in the MME
Test Procedure: Trigger UE attach Send Data in both of directions
Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE=IMSI eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0 for Ciphering eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed
Figure 35: Successful EPS Attach with UE unknown in MME and No Ciphering
6.2.1.2 Successful EPS Attach with UE unknown in MME and Ciphering
Test Name: Successful EPS Attach with the UE unknown in MME and Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the ciphering is enabled Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached and no context exists for the UE Ciphering is enabled GUTI is unknown in the MME
Test Procedure: Trigger UE attach Send Data in both of directions
Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE=IMSI eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA1 or EEA2 for Ciphering as per the configuration eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with Ciphering being performed
Figure 36: Successful EPS Attach with MME unknown in MME and Ciphering
6.2.1.3 Successful EPS Attach procedure with UE known in MME and no Ciphering
Test Name: Successful EPS Attach with the UE known in MME and no Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is known to the MME and the ciphering is disabled Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached and no context exists for the UE Ciphering is disabled GUTI is known in the MME
Test Procedure: Trigger UE attach Send Data in both of directions
Figure 37: Successful EPS Attach procedure with UE known in MME and No Ciphering Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0 for Ciphering eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed
6.2.1.4 Successful EPS Attach procedure with UE known in MME with Ciphering
Test Name: Successful EPS Attach with the UE known in MME and Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is known to the MME and the ciphering is enabled Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached and no context exists for the UE Ciphering is enabled GUTI is known in the MME
Test Procedure: Trigger UE attach Send Data in both of directions
Figure 38: Successful EPS Attach with UE known in MME and Ciphering Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA1 or EEA2 for Ciphering as per the configuration eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed
6.2.1.5 Successful EPS Attach procedure with IMSI
Test Name: Successful EPS Attach with IMSI References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the UE has no GUTI Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached UE has no GUTI
Test Procedure: Trigger UE attach Send Data in both of directions
Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to IMSI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0, EEA1 or EEA2 for Ciphering as per the configuration eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Default EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed
Figure 39: Successful EPS Attach with IMSI
6.2.1.6 Unsuccessful EPS Attach due to IMSI unknown on HSS
Test Name: Unsuccessful EPS Attach due to IMSI unknown on HSS References: 3GPP TS 23.401, Section 5.3.2.1 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3 3GPP TS 24.301, Section 5.5.1.2.2, 5.4.4.2 Test Objective: Validate the graceful failed EPS Attach when IMSI is unknown on HSS Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is not attached and no GUTI is known on MME IMSI is unknown on HSS
Test Procedure: Trigger UE attach
Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE=IMSI eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP: Downlink NAS Transport encapsulating an Attach Reject with the corresponding Cause IE included. No resource is hold by any network element
Figure 40: Unsuccessful EPS Attach due to IMSI unknown on HSS
6.2.1.7 Successful EPS Detach initiated by UE
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 Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is attached
Test Procedure: Trigger UE detach
Expected Results: Verify that: eNodeB sends MME a S1-AP: Uplink NAS Transport encapsulating a Detach Request including the GUTI inside the EPS mobile Identity IE MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Detach Accept MME sends a S1-AP Downlink NAS Transport encapsulating a S1 UE Context Release Command eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport encapsulating a S1 UE Context Release complete. There is no resource hold by any network element after the detach is completed.
6.2.1.8 Successful EPS Detach initiated by UE due to switch off
Test Name: Successful EPS Detach UE initiated References: 3GPP TS 23.401, Section 5.3.8.2.1 3GPP TS 36.413, Section 8.6.2.3, 8.3.3.2 Test Objective: Validate the successful detach procedure when is initiated by the UE Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is attached
Test Procedure: Trigger UE detach by switching off the UE
Expected Results: Verify that: eNodeB sends MME a S1-AP: Uplink NAS Transport encapsulating a Detach Request including a Detach Type IE with the switch off bit set MME sends a S1-AP Downlink NAS Transport encapsulating a S1 UE Context Release Command eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport encapsulating a S1 UE Context Release complete. There is no resource hold by any network element after the detach is completed.
Figure 42: Successful EPS Detach initiated by UE due to switch off
6.2.1.9 Successful EPS Detach initiated by MME
Test Name: Successful EPS Detach MME initiated References: 3GPP TS 23.401, Section 5.3.8.3 3GPP TS 24.301, 5.5.2.3.1 3GPP TS 36.413, Section 8.3.3.2 Test Objective: Validate the successful detach procedure when is initiated by the MME Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW UE is attached and in active state
Test Procedure: Trigger UE detach from the MME
Expected Results: Verify that: MME sends to eNodeB a S1-AP: Uplink NAS Transport encapsulating a Detach Request eNodeB sends to MME a S1-AP Downlink NAS Transport encapsulating a NAS Detach Accept MME sends to eNodeB a S1-AP Downlink NAS Transport encapsulating a S1 UE Context Release Command eNodeB acknowledges it back by sending a S1-AP Uplink NAS Transport encapsulating a S1 UE Context Release complete. There is no resource held by any network element after the detach is completed.
Remark 1: If MME includes a Detach Type requesting UE to make a new attach inside the initial Detach Request, the UE should start a new attach as soon as the current context is completed released.
Figure 44: Successful E-RAB establishment for single E-RAB
Test Name: Successful Establishment of single E-RAB References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish an E-RAB for a UE Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is no existing E-RAB on UE
Test Procedure: Initiate a procedure that requires E-RAB establishment (e.g service request)
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) Validate that eNodeB is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RAB, including the same E-RAB ID IE originally included into the request. Validate that the UE can send data by using the established E-RAB
Remarks 1: If the E-RAB is not successfully established (e.g due to no resources available on eNodeB) the eNodeB will answer with a S1-AP: E-RAB SETUP Response including a E-RAB Failed to Setup List IE containing the ID for the E-RAB that was unable to be established.
6.2.2.1.2 Successful E-RAB establishment UE Aggregate Maximum Bit Rate IE is included
Test Name: Successful Establishment of single E-RAB when UE Aggregate Maximum Bit Rate IE is contained References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish an E-RAB for a UE when UE Aggregate Maximum Bit Rate IE is included Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is an existing E-RAB using all of the Aggregate Maximum Bit Rate for the UE as per UE Context (default bearer)
Test Procedure: Configure MME to include the UE Aggregate Maixmum Bit Rate IE during the establishment of the new E-RAB Initiate a procedure that requires an additional E-RAB establishment (e.g creation of a dedicated bearer).
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) and the UE Aggregate Maximum Bit Rate IE Validate that eNodeB is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RAB, including the same E-RAB ID IE originally included into the request. Validate that the Aggregate Maximum Bit Rate is successfully changed at both of the sides to support the new E-RAB. Validate that the Data Radio Bearer is established for the requested E-RAB with the appropriated resources based on the E-RAB Level QoS Parameter IE Validate that the UE can send data over all of the established E-RABs.
Remarks 1: If the E-RAB is desired to be pre-empted, the Priority Level shall be set to be low priority and the Pre-emption Vulnerability has to be Pre-emptable. The no pre-empting E-RAB will then present the Priority Level set to high and the Pre-emption Capability has to be may trigger pre-emption. In this case, if no enough resources are available the high priority E-RAB will be established and the pre-emptable E-RAB will be released out.
Figure 45: Successful E-RAB establishment for single E-RAB with UE Maximum Aggregate IE included
6.2.2.1.3 Successful E-RAB establishment for multiple E-RABs
Figure 46: Successful E-RAB establishment for Multiple E-RABs
Test Name: Successful establishment of Multiple E-RABs References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish multiple E-RAB for a UE Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is no existing E-RAB on UE
Test Procedure: Initiate a procedure that requires multiple E-RAB establishment (e.g service request)
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing multiple E-RAB to be setup (multiple E-RAB ID IEs) Validate that eNodeB is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RABs, including the same E-RAB ID IEs originally included into the request for each successfully established E-RAB Validate that the UE can send data by using ALL the successfully established 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 References: 3GPP TS 36.413, Section 8.2.2.2 Test Objective: Validate the possibility to modify an existing E-RAB Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There is an existing E-RAB on UE
Test Procedure: Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ by including new TFT Filters/QoS Parameters)
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB to be Modified List IE containing one E-RAB to Be Modified Item (with the corresponding E-RAB ID IE) Validate that eNodeB is acknowledging the modification by sending back a S1-AP E-RAB Modify Response message with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs (with same E-RAB ID IE). Validate that the new parameters (QoS and/or TFT Filters) are properly updated at both of the sides and that the data is transferred accordingly.
Remarks 1: The MME can include the UE Aggregate Maximum Bit Rate IE into the S1-AP: E-RAB Modify Request. In that case, the data radio bearer shall be modified for the requested E-RAB with the appropriate resources based on the E-RAB level QoS Parameter IE, reflecting the change in the aggregate maximum bit rate
Remarks 2: The MME can attempt to modify the existing E-RAB while pre-empting another E-RAB on the UE. For this purpose, the MME will include into the S1-AP: E-RAB Modify Request message the E-RAB to be Modified List IE containing one E-RAB to Be Modified Item IE with the corresponding E-RAB ID, the E-RAB Priority Level set to 1 and the Pre-emption Capability set to may trigger pre-emption. In this case, if no enough resources are available on enodeB the others E-RAB will be released by using a S1-AP E-RAB Release procedure for the low priority E-RABs.
Remarks 3: If the E-RAB is not successfully modified the eNodeB will send a S1-AP E-RAB Modify Response including a E-RAB Failed to Modify List IE with the same ID of the E-RAB included into the request. In this case, the former QoS/TFT parameters of the bearer will be honored by all the nodes.
Figure 47: Successful E-RAB modification for single E-RAB
6.2.2.2.2 Successful E-RAB modification for multiple E-RABs
Figure 48: Successful E-RAB Modification for multiple E-RABs Test Name: Successful E-RAB modification of multiple E-RABs References: 3GPP TS 36.413, Section 8.2.2.2 Test Objective: Validate the possibility to modify existing E-RABs Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There are multiple E-RABs existing on UE
Test Procedure: Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ by including new TFT Filters/QoS Parameters) for multiple E-RABs
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB to be Modified List IE containing all E-RAB to Be Modified Item (with the corresponding E-RAB ID IEs) Validate that eNodeB is acknowledging the modification by sending back a S1-AP E-RAB Modify Response message with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs (with same E-RAB ID IEs). Validate that the new parameters (QoS and/or TFT Filters) are properly updated at both of the sides and that the data is transferred accordingly on all the bearers.
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 References: 3GPP TS 36.413, Section 8.2.2.2 Test Objective: Validate the possibility of a graceful partial modification of all the existing E-RABs on a UE Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There are multiple E-RABs existing on UE
Test Procedure: Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ by including new TFT Filters/QoS Parameters) for multiple E-RABs
Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB to be Modified List IE containing all E-RAB to Be Modified Item (with the corresponding E-RAB ID IEs) Validate that eNodeB is sending back a S1-AP E-RAB Modify Response message with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs (with same E-RAB ID IEs) for all the successfully modified E-RABs. Validate that eNodeB is also including into the S1-AP E-RAB Modify Response a E-RAB Failed to Modify List IE containing the IDs for each of the E-RABs which was unable to be modified. Validate that the new parameters (QoS and/or TFT Filters) are properly updated at both of the sides only on the successfully modified E-RABs, whereas the former values are kept for the unsuccessfully modified E-RABs. Validate that the data is transferred accordingly on all the bearers.
Figure 49: Successful and Unsuccessful E-RAB Modification for Multiple 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 References: 3GPP TS 36.413, Section 8.2.3.2.1 Test Objective: Validate the successful MME initiated release of an E-RAB existing on UE Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There are at least two E-RABs existing on UE
Test Procedure: Initiate a procedure that requires an existing E-RAB to be released (e.g eliminate all the TFT Filters from a dedicated bearer)
Expected Results: Verify that: Validate that MME is sending S1-AP: E-RAB Release command including the 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 Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME There are at least two E-RABs existing on UE
Test Procedure: Initiate a procedure that requires an existing E-RAB to be released (e.g eliminate all the TFT Filters from a dedicated bearer)
Expected Results: Verify that: Validate that eNodeB is sending a S1-AP: E-RAB Release Indication including the E-RAB Released List IE containing the ID of the E-RAB to be released Validate that MME is successfully acknowledging and that the bearer is also eliminated over S11 interface
Figure 51: E-RAB Release initiated by eNodeB
6.2.3 EPC Bearers Functional Procedures 6.2.3.1 Dedicated bearer Activation 6.2.3.1.1 Successful Dedicated Bearer Activation initiated by the network Test Name: Successful Dedicated Bearer Activation initiated by the network References: 3GPP TS 23.401, Section 5.4.1 3GPP TS 24.301, Section 6.4.2.2 3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3 Test Objective: Validate the successful dedicated bearer activation when initiated by the network Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Trigger PGW to perform a dedicated bearer activation
Expected Results: Verify that: Validate that MME is receiving the EGTP_CREATE_BEARER_REQ from SGW over S11 interface, and is subsequently sending a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request message. This message shall include the EPS Bearer identity IE, the EPS QoS and Traffic Flow Template IE as originally included into the EGTP message coming from SGW Validate that eNodeB sends back a S1-AP: E-RAB SETUP Response. Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS Bearer identity and the Procedure transaction identity IE. Vadliate that the a new dedicated bearer has been established on every node and that the data transmission in DL/UL honors the QoS/TFT Filter rules on that bearer.
Remark 1: If the dedicated bearer establishment is rejected by the UE/enodeB, the enodeB will send a S1-AP: Uplink NAS Transport including a NAS Activate dedicated EPS bearer Context Reject, including the EPS Bearer ID as well as the ESM Cause IE with the corresponding cause (E.g insufficient resources)
Figure 52: Successful Dedicated Bearer Activation initiated by the network
6.2.3.1.2 Successful Dedicated Bearer Activation initiated by the UE
Test Name: Successful Dedicated Bearer Activation initiated by the UE References: 3GPP TS 23.401, Section 5.4.1, 5.4.5 3GPP TS 24.301, Section 6.4.2.2 3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3 Test Objective: Validate the successful dedicated bearer activation when initiated by the UE Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Trigger UE to perform a dedicated bearer activation (e.g making a MO call with different QCI)
Expected Results: Verify that: Validate that eNodeB is initially sending a S1-AP: Uplink NAS Transport encapsulating a NAS Bearer Resource Allocation Request message with the TFT/QoS information sent by the UE and including a EPS Bearer Identity IE with no EPS bearer identity assigned Validate that MME is subsequently sending a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request message. This message shall include the EPS Bearer identity IE, the EPS QoS and Traffic Flow Template IE as originally included into the EGTP message coming from SGW Validate that eNodeB sends back a S1-AP: E-RAB SETUP Response. Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS Bearer identity and the Procedure transaction identity IE. Validate that a new dedicated bearer has been established on every node and that the data transmission in DL/UL honors the QoS/TFT Filter rules on that bearer.
Remark 1: If the dedicated bearer establishment is rejected by the network, the MME will send a S1-AP: Uplink NAS Transport including a NAS Bearer Resource Modification Reject with ESM Cause IE with the corresponding cause (E.g insufficient resources)
Figure 53: Successful Bearer Activation initiated by the UE
6.2.3.1.3 Successful Dedicated Bearer Activation during attach
Test Name: Successful Dedicated Bearer Activation during attach References: 3GPP TS 23.401, Annex F 3GPP TS 24.301, Section 6.4.2.2 3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3 Test Objective: Validate the successful dedicated bearer activation during UE attach Pre-Test Conditions: UE is not attached Network is configured to trigger a dedicated bearer activation during the UE attach
Test Procedure: Trigger UE to attach
Expected Results: Verify that: enodeB sends a S1-AP Initial UE message encapsulating a NAS Attach Request to MME MME sends back a S1-AP Initial Context Setup Request including both NAS Attach Accept and NAS Activate Default EPS Bearer Context Request MME sends a S1-AP: E-RAB set request encapsulating a NAS Activate Dedicated EPS Bearer Context Request to eNodeB. The NAS message will include the EPS Bearer identity IE of the new dedicated bearer, the EPS QoS IE and the corresponding Traffic Flow Template IE Validate that eNodeB sends back a S1-AP: Initial Context Setup Response. Validate that eNodeB sends to MME a S1-AP: Uplink NAS Transport encapsulating a NAS Attach Complete and NAS Activate Default EPS Bearer Context Accept message. Validate that eNodeB sends to MME a S1-aP: E-RAB Setup Response Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS Bearer identity and the Procedure transaction identity IE. Validate that both default and dedicated bearers have been established on every node and that the data transmission in DL/UL honors the QoS/TFT Filter rules on that bearer.
Figure 54: Successful Bearer Activation during Attach
6.2.3.2 Bearer Modification 6.2.3.2.1 Bearer Modification initiated by the EPC
6.2.3.2.1.1 PDN GW initiated bearer modification with QoS Update
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 Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Trigger PGW to modify the QoS Parameters for a E-RAB (e.g MBR GBR or AMBR)
Expected Results: Verify that: Validate that MME is receiving the EGTP_UPDATE_BEARER_REQ from SGW over S11 interface, and is subsequently sending a S1-AP: E-RAB Modify Request including the NAS session management request with the E-RAB to be Modified List IE included. Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the E- RAB Modify List IE containing the same E-RAB ID acknowledging the modification Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Session Management Response message. Vadliate that the new QoS/TFT Filter is updated on every node accordingly and data traffic is now following the new rules.
Test Name: HSS initiated bearer modification with QoS Update References: 3GPP TS 23.401, 5.4.2.2 3GPP TS 24.301, Section 6.4.3.1 3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3 Test Objective: Validate the successful bearer modification when initiated by HSS Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Trigger HSS to modify the subscribed QoS parameters in the middle of the session (e.g QCI, ARP, QoS)
Expected Results: Verify that: Validate that MME is receiving the Insert Subscriber Data Request from HSS with the new QoS information, and is successfully acknowledging it back Validate that MME is subsequently sending a S1-AP: E-RAB Modify Request including the NAS session management request with the E-RAB to be Modified List IE included. Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the E- RAB Modify List IE containing the same E-RAB ID acknowledging the modification Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Session Management Response message. Vadliate that the new QoS is updated on every node accordingly and data traffic is now following the new rules.
6.2.3.2.1.3 Network Initiated Bearer modification without Bearer QoS Update
Test Name: Network initiated bearer modification without QoS Update References: 3GPP TS 23.401, 5.4.2.2, 5.4.3 3GPP TS 24.301, Section 6.4.3.1 3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3 Test Objective: Validate the successful bearer modification without bearer QoS update by the network Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Trigger network to modify the bearer without QoS Update (e.g adding new TFT filters on PGW to the bearer, or making HSS to modify the APN-AMBR)
Expected Results: Verify that: Validate that MME is sending a S1-AP: E-RAB ModifyRequest including the NAS session management request with the E-RAB to be Modified List IE included. The Modification could include the Traffic Flow Template IE (if new TFT filter is added), the APN-AMBR IE (if new AMBR is included). Validate that eNodeB sends back a S1-AP: E-RAB Modify Response with the E- RAB Modify List IE containing the same E-RAB ID acknowledging the modification Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Session Management Response message. Validate that the new TFT/AMBR is updated on every node accordingly and data traffic is now following the new rules.
Figure 57: Network Initiated Bearer Modification without QoS
6.2.3.2.2 Bearer Modification initiated by the UE
6.2.3.2.2.1 UE Requested Bearer Modification accepted by the network
Test Name: UE Requested Bearer Modification accepted by the network References: 3GPP TS 23.401, 5.4.5, 5.4.2.1 3GPP TS 24.301, Section 6.5.4.2, 6.4.3.1 3GPP TS 36.413, Section 8.6.2.3, 8.2.2.2, 8.6.2.2 Test Objective: Validate the successful bearer modification when initiated by the UE Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Initiate QoS parameter modification from the UE (e.g MBR, GBR, etc)
Expected Results: Verify that: Validate that eNodeB is mapping the EPS Bearer QoS to the Radio Bearer QoS and signals a RRC Connection Reconfiguration to the UE Validate that eNodeB is sending S1-AP: Uplink NAS Transport encapsulating a NAS Bearer Resource Modification Request to the MME Validate that MME is sending back a E-RAB Modify Request encapsulating a NAS Session Management Request containing the E-RAB to be Modified List IE set to the corresponding E-RAB ID Validate that eNodeB sends to MME S1-APL E-RAB Modify Response message acknowledging it back. Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Session Management Response message. Validate that the new TFT/AMBR is updated on every node accordingly and data traffic is now following the new rules.
Remark 1: If the modification request is not accepted by the network, then the MME will answer the S- !AP NAS Bearer Resource modification Request with a S1-AP Downlink NAS Transport encapsulating a NAS Bearer Resource Modification Reject message including the corresponding Cause ID
Figure 58: UE Requested Bearer Modification Accepted by the Network
6.2.3.2.2.2 UE Requested Bearer Modification without QoS update accepted by the network
Test Name: UE Requested Bearer Modification without QoS update accepted by the network References: 3GPP TS 23.401, 5.4.5, 5.4.2.1 3GPP TS 24.301, Section 6.5.4.2, 6.4.3.1 3GPP TS 36.413, Section 8.6.2.3, 8.2.2.2, 8.6.2.2 Test Objective: Validate the successful bearer modification without QoS update when initiated by the UE Pre-Test Conditions: UE is attached There are at least one E-RAB on UE
Test Procedure: Initiate TFT parameter modification from the UE Expected Results: Verify that: Validate that eNodeB is mapping the EPS Bearer QoS to the Radio Bearer QoS and signals a RRC Connection Reconfiguration to the UE Validate that eNodeB is sending S1-AP: Uplink NAS Transport encapsulating a NAS Bearer Resource Modification Request to the MME. This message should include the Traffic Flow Template IE with the new information Validate that MME is sending back a E-RAB Modify Request encapsulating a NAS Session Management Request containing the E-RAB to be Modified List IE set to the corresponding E-RAB ID and same Traffic Flow Template IE Validate that eNodeB sends to MME S1-APL E-RAB Modify Response message acknowledging it back. Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Session Management Response message. Validate that the new TFT/AMBR is updated on every node accordingly and data traffic is now following the new rules.
Remark 1: If the modification request is not accepted by the network, then the MME will answer the 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
Figure 60: PGW Initiated Dedicated Bearer Deactivation Test Name: PDN GW initiated bearer deactivation References: 3GPP TS 23.401, 5.4.4.1 3GPP TS 24.301, Section 6.4.4.2 3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3 Test Objective: Validate the successful dedicated bearer deactivation when initiated by PDN GW Pre-Test Conditions: UE is attached There are at least two E-RABs on UE
Test Procedure: Initiate bearer deactivation from the PDN GW Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the rest of the bearers (e.g default).
Test Name: MME initiated bearer deactivation References: 3GPP TS 23.401, 5.4.4.2 3GPP TS 24.301, Section 6.4.4.2 3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3 Test Objective: Validate the successful dedicated bearer deactivation when initiated by MME Pre-Test Conditions: UE is attached There are at least two E-RABs on UE
Test Procedure: Initiate bearer deactivation from the MME Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the remaining bearers (e.g default).
Figure 62: UE initiated Dedicated Bearer Deactivation Test Name: UE initiated bearer deactivation References: 3GPP TS 23.401, 5.4.5, 5.4.4.2 3GPP TS 24.301, Section 6.5.4.2, 6.4.4.2 3GPP TS 36.413, Section 8.6.2.3, 8.2.3.2.1 Test Objective: Validate the successful dedicated bearer deactivation when initiated by UE Pre-Test Conditions: UE is attached There are at least two E-RABs on UE
Test Procedure: Initiate bearer deactivation from the UE Expected Results: Verify that: Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Bearer Resource Modification Request including a ESM Cause IE set to Regular deactivation Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that eNodeB is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that eNodeB sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the rest of the bearers (e.g default).
6.2.4 Idle Mode and Context Management Procedures 6.2.4.1 Active to Idle mode Transition (Context Release) 6.2.4.1.1 UE/eNodeB Context Release due to User Inactivity with a single bearer established
Test Name: UE/eNodeB Context Release due to User Inactivity with single bearer established References: 3GPP TS 23.401, 5.3.5 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2 Test Objective: Validate the successful transition from Active to Idle mode when the UE has only 1 bearer established Pre-Test Conditions: UE is attached UE is in active mode UE has only 1 E-RAB established
Test Procedure: Stop data transmission and wait until Idle mode timer gets expired Expected Results: Verify that: Validate that eNodeB is sending a S1-AP UE context Release Request including a Cause IE set to User Inactivity The MME will then send a S11 EGTP_Release_Access_Bearer_Request message including the information of the S1 bearer to be released between eNodeB and SGW. SGW will acknowledge it back by sending a S11 EGTP_Release_Access_Bearer_Response message Since there is only one bearer, validate that MME is sending a S1 AP UE Context Release message. This message is acknowledged by the eNodeB. Validate that all the bearers have been released but the UE context is still alive on MME
Figure 63: UE/eNodeB Context Release initiated due to UE inactivity with single bearer established
6.2.4.1.2 UE/eNodeB Context Release due to User Inactivity with multiple bearers established
Test Name: UE/eNodeB Context Release due to User Inactivity with multiple bearers established References: 3GPP TS 23.401, 5.3.5 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2 Test Objective: Validate the successful transition from Active to Idle mode when the UE has multiple bearers established Pre-Test Conditions: UE is attached UE is in active mode UE has at least two E-RABs established
Test Procedure: Stop data transmission through all the bearers and wait until Idle mode timer gets expired Expected Results: Verify that: Validate that eNodeB is sending a S1-AP UE context Release Request including a Cause IE set to User Inactivity The MME will then send a S11 EGTP_Release_Access_Bearer_Request message including the information of all the S1 bearers to be released between eNodeB and SGW. SGW will acknowledge it back by sending a S11 EGTP_Release_Access_Bearer_Response message Validate that MME sends a S1-AP: UE Context Release Command to the eNodeB Validate that eNodeB is sending back a S1-AP UE Context Release Complete Validate that all the bearers have been released but the UE context is still alive on MME
Note: It may happen that multiple bearers are established but only a subset of these bearers become Idle. In this case, the MME would send a S1-AP UE Context Release Command by including only the subset of bearers that are inactive and the eNodeB would respond with 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 References: 3GPP TS 23.401, 5.3.5 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2
Test Objective: Validate the successful UE Context release due to radio connection with UE lost Pre-Test Conditions: UE is attached UE is in active mode and a context exists for the UE on every node
Test Procedure: Make the UE to go out of radio coverage (e.g moving the UE or using attenuators) Expected Results: Verify that: Validate that eNodeB is sending a S1-AP UE context Release Request including a Cause IE set to Radio Connection with UE lost Validate that MME sends a S1-AP: UE Context Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that eNodeB is sending S1-AP: UE Context Release Complete Validate that the UE context is successfully released and there is no longer any resource hold by any network element for that UE
6.2.4.3 Tracking Area Update procedures 6.2.4.3.1 Normal Tracking area Update
Test Name: Normal Tracking Area Update References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2
Test Objective: Validate the normal tracking update Pre-Test Conditions: UE is attached UE is in Idle Mode A neighbor cell is configured with a TA which is not in UEs TA list
Test Procedure: Make the UE to move to the neighboring cell Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Normal Tracking Area Update Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete, Finally, validate that MME is sending a S1-AP UE Context Release Command is eNodeB is acknowledging it back by sending back a S1-AP UE Context Release Complete. Validate that the UE context is successfully kept on both MME and eNodeB and UE remains in Idle
Figure 66: Normal Tracking Area Update
6.2.4.3.2 Normal Tracking area Update with bearer establishment requested Test Name: Normal Tracking Area Update with bearer establishment requested References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.1.2 Test Objective: Validate the successful tracking area update with bearer establishment requested. This may happen when the UE moves to a neighbor cell and data traffic is resumed through one of the bearers. Pre-Test Conditions: UE is attached UE is attached for EPS services only and one or several services are established with data transfer ongoing A neighbor cell is configured with a TA which is not in the UEs TA list
Test Procedure: Move the UE to the neighboring cell and resume traffic
Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Normal Tracking Area Update and EPS bearer context status IE indicating the correct EPS contexts as active on the UE Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept including a EPS bearer context status IE indicating the correct the EPS contexts as active in the MME Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete. Validate that, MME is subsequently performing a Initial Context Setup and E-RAB Setup (if any dedicated bearers) Validate that the default and dedicated bearers (if any) are successfully established. Validate that services are re-established and data transfer can be resumed.
Figure 67: Normal Tracking area Update with bearer establishment requested
6.2.4.3.3 Combined Tracking and Location Area Update Test Name: Combined Tracking and Location Area Update References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 23.272, 5.4.1 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2 Test Objective: Validate the successful combined tracking and location normal tracking area update Pre-Test Conditions: UE is attached UE supports CS fallback UE is attached for both EPS and non-EPS services A neighbor cell is configured with a TA which is not in UEs TA list
Test Procedure: Make the UE to move to the neighboring cell Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Combined TA/LA updating Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete, Finally, validate that MME is sending a S1-AP UE Context Release Command is eNodeB is acknowledging it back by sending back a S1-AP UE Context Release Complete. Validate that the UE context is successfully kept on both MME and eNodeB and UE remains in Idle
Figure 68: Combined Tracking and Location Area Update
6.2.4.3.4 Combined Tracking and Location Area Update with IMSI attach
Test Name: Combined Tracking and Location Area Update with IMSI attach References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 23.272, 5.4.1 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2 Test Objective: Validate the successful combined tracking and location normal tracking area update with IMSI attach Pre-Test Conditions: UE is attached UE supports CS fallback UE is attached for EPS services only
Test Procedure: Enable CS/PS mode 1 or CS/PS mode 2 on the UE Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Combined TA/LA updating with IMSI attach Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete, Finally, validate that MME is sending a S1-AP UE Context Release Command is eNodeB is acknowledging it back by sending back a S1-AP UE Context Release Complete. Validate that the UE context is successfully kept on both MME and eNodeB and UE remains in Idle
Figure 69: Combined Tracking and Location Area Update with IMSI attach
6.2.4.3.5 Combined Tracking and Location Area Update with bearer establishment requested
Test Name: Combined Tracking and Location Area Update with bearer establishment requested References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 23.272, 5.4.1 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2 Test Objective: Validate the successful combined tracking and locating area update with bearer establishment requested. This may happen when the UE moves to a neighbor cell and data traffic is resumed through one of the bearers. Pre-Test Conditions: UE is attached UE is attached for both EPS and non-EPS services only and one or several services are established with data transfer ongoing UE supports CS fallback A neighbor cell is configured with a TA which is not in the UEs TA list
Test Procedure: Stop traffic to put the UE in Idle state Move the UE to the neighboring cell and resume traffic
Figure 70: Combined Tracking and Location Area Update with bearer establishment requested Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Combined TA/LA updating and EPS bearer context status IE indicating the correct EPS contexts as active on the UE Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept including a EPS bearer context status IE indicating the correct the EPS contexts as active in the MME Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete. Validate that, MME is subsequently performing a Initial Context Setup and E-RAB Setup (if any dedicated bearers) Validate that the default and dedicated bearers (if any) are successfully established. Validate that services are re-established and data transfer can be resumed.
6.2.4.3.6 Periodic Tracking area Update
Test Name: Periodic Tracking Area Update References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2 Test Objective: Validate the successful Periodic Tracking area update Pre-Test Conditions: UE is attached UE is in Idle Mode
Test Procedure: The periodic tracking area updating procedure is triggered on the UE when the timer T3412 expires
Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Periodic Updating Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to eNodeB Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept Validate that eNodeB is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete, Finally, validate that MME is sending a S1-AP UE Context Release Command is eNodeB is acknowledging it back by sending back a S1-AP UE Context Release Complete. Validate that the UE context is successfully kept on both MME and eNodeB and UE remains in Idle
Figure 71: Periodic Tracking area Update
6.2.4.3.7 Tracking Area Update rejected due to No EPS Bearer context activated
Test Name: Tracking Area Update rejected due to No EPS Bearer context activated References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2 Test Objective: Validate the tracking area update procedure rejected when the UE requests an establishment of the radio access bearer for all active EPS bearer contexts but the MME does not have the corresponding active EPS bearer context. Pre-Test Conditions: UE is attached UE is attached and one or several services are established with data transfer ongoing A neighboring cell is configured with a TA which is not in UEs TA list
Test Procedure: Stop traffic to put the UE in Idle state Delete the EPS bearer context on the MME Move the UE to the neighboring cell and resume traffic
Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Bearer Establishment Requested. The message will have also a EPS Update type IE with the active flag set. Validate that MME sends S1-AP: Downlink NAS Transport encapsulating NAS Tracking Area Update Reject. The EMM Cause IE including a No EPS bearer context activated Validate that MME sends a S1-AP UE Context Release Command Validate that eNodeB sends a S1-AP UE Context Release Complete
Figure 72: Tracking Area Update rejected due to "No EPS Bearer context activated"
6.2.4.3.8 Tracking Area Update rejected due to implicitly detached
Test Name: Tracking Area Update rejected due to implicitly detached References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2 Test Objective: Validate the tracking area update procedure rejected when the network has been implicitly detached the UE Pre-Test Conditions: UE is attached UE is in idle state A neighboring cell is configured with a TA which is not in UEs TA list
Test Procedure: Remove the UE from the cell radio coverage in order to have the periodic tracking area update timer (T3412) expires and also the mobile reachable timer expired. The network will then implicitly detach the UE. Validate the procedure on MME Move the UE back under the radio coverage
Expected Results: Verify that: Validate that eNodeB sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, Validate that MME sends S1-AP: Downlink NAS Transport encapsulating NAS Tracking Area Update Reject. The EMM Cause IE including a implicitly detached Validate that MME sends a S1-AP UE Context Release Command Validate that eNodeB sends a S1-AP UE Context Release Complete Validate that the UE performs a new attach procedure and is successfully completed
Figure 73: Tracking Area Update rejected due to "implicitly detached"
6.2.4.4 Paging 6.2.4.4.1 Paging with Paging DRX IE
Figure 74: Paging with Paging DRX IE Test Name: Paging with Paging DRX IE References: 3GPP TS 23.401, 5.3.4.3 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.5.2, 8.6.2.1 Test Objective: Validate the MME can sends the Paging message including the Paging DRX IE in case the UE supports Paging DRX. Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME The UE has included the UE specific parameter in the DRX Parameter IE in the Attach Request message to indicate it supports Paging DRX The UE is in Idle Mode
Test Procedure: Send DL Data to the UE while UE is in Idle Mode
Expected Results: Verify that: Validate that MME is sending S1-AP: Paging including the Paging DRX IE Validate that UE is subsequently re-entering Active Mode. eNodeB is sending 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 References: 3GPP TS 23.401, 5.3.4.3 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.5.2, 8.6.2.1 Test Objective: Validate the MME can sends the Paging message without Paging DRX IE in case the UE does not support Paging DRX. Pre-Test Conditions: Initial S1 setup has been successfully established between eNodeB and MME The UE did not include the UE specific parameter in the DRX Parameter IE in the Attach Request message to indicate it does NOT support Paging DRX The UE is in Idle Mode
Test Procedure: Send DL Data to the UE while UE is in Idle Mode
Expected Results: Verify that: Validate that MME is sending S1-AP: Paging NOT including any Paging DRX IE Validate that UE is subsequently re-entering Active Mode. eNodeB is sending 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 References: 3GPP TS 23.401, 5.3.4.3 3GPP TS 24.301, 5.6.1, 5.6.2 3GPP TS 36.413, Section 8.5.2, 8.6.2.1, 8.3.1.2 Test Objective: Validate the successful transfer from ECM-Idle mode to ECM-Connected and establish the radio and S1 bearers when the network has downlink signaling pending.
Pre-Test Conditions: UE is attached UE is in idle state UE context on the network contains only 1 bearer.
Test Procedure: Send data in DL direction so that paging is started.
Expected Results: Verify that: Validate that MME sends a S1-AP Paging including a CN Domain IE set to PS Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Service Request Validate that MME sends S1-AP: Initial Context setup Request including the 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) References: 3GPP TS 23.401, 5.3.4.3 3GPP TS 24.301, 5.6.1, 5.6.2 3GPP TS 36.413, Section 8.5.2, 8.6.2.1, 8.3.1.2 Test Objective: Validate the successful transfer from ECM-Idle mode to ECM-Connected and establish the radio and S1 bearers when the network has downlink signaling pending.
Pre-Test Conditions: UE is attached UE is in idle state UE context on the ntetwork contains at least two bearers. This entails that at least two E-RABs will be established for the UE during the Idle Mode exit
Test Procedure: Send data in DL direction so that paging is started.
Expected Results: Verify that: Validate that MME sends a S1-AP Paging including a CN Domain IE set to PS Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Service Request Validate that MME sends S1-AP: Initial Context setup Request including the E- 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 Validate that eNodeB sends a S1-AP Initial Context Setup Response including the same list of E-RAB setup list IE containing the list of E-RABs that have been successfully established. Validate that all bearers have been re-established and that data can be transmitted on all of the bearers.
Figure 77: Successful Service Requested when UE receives a paging request with CN Domain indicator set to "PS" (Multiple bearers)
6.2.4.5.3 Successful Service Request invoked when the UE has pending user data to be sent in ECM-Idle mode (Single Bearer)
Test Name: Successful Service Request invoked when the UE has user data to be sent (Single Bearer) References: 3GPP TS 23.401, 5.3.4.1 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 Test Objective: Validate the successful transfer from ECM-Idle mode to ECM-Connected and establish the radio and S1 bearers when the UE has user data to be sent in a single bearer environment
Pre-Test Conditions: UE is attached Only 1 EPS bearer needs to be re-established UE is in idle state
Test Procedure: Send data in UL data from the UE.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Service Request Validate that MME sends S1-AP: Initial Context setup Request including the 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 78: Successful Service Request when UE has pending user data to be sent (Single Bearer)
6.2.4.5.4 Successful Service Request invoked when the UE has pending user data to be sent in ECM-Idle mode (Multiple Bearers)
Test Name: Successful Service Request invoked when the UE has user data to be sent (Multiple Bearers) References: 3GPP TS 23.401, 5.3.4.1 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 Test Objective: Validate the successful transfer from ECM-Idle mode to ECM-Connected and establish the radio and S1 bearers when the UE has user data to be sent in a multiple bearer environment
Pre-Test Conditions: UE is attached Multiple EPS bearers need to be re-established UE is in idle state
Test Procedure: Send data in UL data from the UE.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Service Request Validate that MME sends S1-AP: Initial Context setup Request including the E- 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 Validate that eNodeB sends a S1-AP Initial Context Setup Response including the same list of E-RAB setup list IE containing all the E-RABs that have been successfully established. Validate that all the EPS bearers have been re-established and that data can be transmitted on each bearer.
Figure 79: Successful Service Request when the UE has pending user to be sent (Multiple Bearers)
6.2.4.5.5 Successful Service Request invoked when the UE has uplink signaling pending in ECM-Idle mode
Test Name: Successful Service Request invoked when the UE has signaling pending References: 3GPP TS 23.401, 5.3.4.1 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 Test Objective: Validate the successful transfer from ECM-Idle mode to ECM-Connected and establish the radio and S1 bearers when the UE has signaling pending
Pre-Test Conditions: UE is attached Only 1 EPS bearer needs to be re-established UE is in idle state
Test Procedure: Initialize a procedure that requires service request to be started.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Service Request Validate that MME sends S1-AP: Initial Context setup Request including the 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 80: Successful Service Request when UE has uplink signaling pending in Idle Mode
6.2.4.5.6 Successful Service Request invoked by 1xCS fallback when the UE is in Idle mode and has a mobile originating 1xCS fallback request
Test Name: Successful Service Request invoked when the is in Idle mode and has a mobile originating 1xCS fallback request from the upper layer References: 3GPP TS 23.272, B.2.2a 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2, 8.3.2.2, 8.3.3.2 Test Objective: Validate the successful Service Request invoked when the is in Idle mode and has a mobile originating 1xCS fallback request from the upper layer Pre-Test Conditions: UE is attached UE supports CS fallback UE is attached for both EPS and non EPS services UE is in idle state
Test Procedure: Initialize a CS call from the UE.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Extended Service Request with Service Type IE set to mobile originating CS fallback or 1xCS fallback Validate that MME sends S1-AP: Initial Context setup Request a CS Fallback Indicator IE. Validate that the CS callback is successfully established and that the UE can establish the CS Call
Remark1: If no CS domain is available the MME will reject by answering the Initial UE message from eNodeB with a S1-AP: Initial Context Setup Request encapsulating a NAS Service Reject with EMM Cause IE set to CS domain not available
Figure 81: Successful Service Request when UE is in Idle mode and has a mobile originating 1xCS fallback request
6.2.4.5.7 Successful Service Request invoked by 1xCS fallback when the UE is in Active mode and has a mobile originating 1xCS fallback request
Test Name: Successful Service Request invoked when the is in Active mode and has a mobile originating 1xCS fallback request from the upper layer References: 3GPP TS 23.272, B.2.2 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.3, 8.3.4.2, 8.3.2.2, 8.3.3.2 Test Objective: Validate the successful Service Request invoked when the is in Active mode and has a mobile originating 1xCS fallback request from the upper layer Pre-Test Conditions: UE is attached UE supports CS fallback UE is attached for both EPS and non EPS services UE is in Connected state
Test Procedure: Initialize a CS call from the UE.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message encapsulating a NAS Extended Service Request with Service Type IE set to mobile originating CS fallback or 1xCS fallback Validate that MME sends S1-AP: UE Context Modification Request a CS Fallback Indicator IE. Validate that eNodeB sends to MME a S1-AP UE Context Modification Response Validate that the CS callback is successfully established and that the UE can establish the CS Call
Remark1: If no CS domain is available the MME will reject by answering the Initial UE message from eNodeB with a S1-AP: Initial Context Setup Request encapsulating a NAS Service Reject with EMM Cause IE set to CS domain not available
Figure 82: Successful Service Request when UE is in Active Mode and has a mobile originating 1xCS fallback request
6.2.4.5.8 Successful Initial UE message with Emergency Flag enabled
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 References: 3GPP TS 23.401, 5.3.2.1 Test Objective: Validate the successful Initial Context Setup procedure when emergency mode is enabled Pre-Test Conditions: UE is not attached UE is LTE capable
Test Procedure: Initialize an emergency call from the UE.
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Initial UE message including a RRC Establishment Cause IE set to Emergency Validate that MME sends S1-AP: Initial Context Setup Request including the 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 Pre-Test Conditions: Configure both eNodeB and SGW to present a echo request timer for testing purposes.
Test Procedure: Initiate a UE attach
Expected Results: Verify that: Validate that once a GTP-U tunnel is established by the network, eNodeB is able to send a GTP-U: Echo Request to SGW. SGW is capable of acknowledging it by sending back a GTP-U: Echo Response. Validate that SGW is also capable of sending a GTP-U: Echo Request as per the configuration and that is successfully acknowledged by eNodeB with a GTP-U: Echo Response.
6.2.5.1.1.2 GTP-U message End of Marker
Test Name: GTP-U message End of Marker Reference: TS 29.281 Section 7.3.2 Test Objective: Validate that the message End of Marker is properly used during a HO Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME X2 interface is properly set up. UE is attached and a single E-RAB exists for the UE.
Test Procedure: Start an application to start a download of a large file while HO happens (e.g video streaming session, FTP, etc) Change the radio condition in the eNodeBs to trigger a HO
Expected Results: Verify that: Validate that, prior to the HO, there is a User data transmission ongoing from between Source eNodeB and SGW When X2 HO happens and the UE has moved to target eNodeB, the UL Data transmission starts automatically from Target eNodeB to SGW as soon as the UE context is established through the target eNodeB. Validate that Target eNodeB sends a S1:AP Path Switch Request to MME to indicate that X2 HO is in process Validate that SGW sends a GTP-U End of Marker to the Source eNodeB to indicate that the DL path has been moved Validate that Source eNodeB sends a GTP-U End Of Marker to Target eNodeB Validate that DL data is resumed between SGW and Target eNodeB Validate that Target eNodeB is sending a S1-AP: Path Switch Request Acknowledgement to MME in order to indicate the successful end of HO.
Remark 1: During this process the Target eNodeB can perform a Tracking Area Update procedure with MME if required per the TA configuration on the network.
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 Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW One or more E-RAB established for the UE
Test Procedure: Force S-GW to send a GTP-U: Error Indication (e.g manual command on SGW, making eNodeB to send a UL data for an unexisting EPS Bearer in UL due to HO or manually using an unknown TEID)
Expected Results: Verify that: Validate that, SGW is sending a GTP-U: Error Indication including as information element the TEID for which that Error Indication was triggered Validate that eNodeB is subsequently initiating the UE Context Release for the EPS bearer by sending a S1-AP UE Context Release req to MME, initiating the 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 Reference: TS 23.007 section 21.7 Test Objective: Validate the appropriate handling of the Error Indication by S-GW from a enodeB Pre-Test Conditions: S1 interface is properly set up between eNodeB and MME/SGW One or more E-RAB established for the UE
Test Procedure: Force eNodeB to send a GTP-U: Error Indication (e.g manual command on eNodeB, making S-GW to send a DL data for an unexisting EPS Bearer in DL due to HO or manually using an unknown TEID)
Expected Results: Verify that: Validate that, eNodeB is sending a GTP-U: Error Indication including as information element the TEID for which that Error Indication was triggered Validate that upon the reception of the Error Indication with the GTP-U Identifier from the enodeB to the S-GW, the S-GW does not delete the associated bearer Context but just all the eNodeB GTP-U TEIDs for this UE. The S-GW then starts buffering DL packets received from this UE and sends Downlink Data Notification message to the MME which triggers the re-establishment of the corresponding bearers. The call flow would be as follows: Upon the reception of the GTP-U Error Indication from eNodeB, S-GW sends a S11 Downlink Data Notification to MME MME is sending a S1-AP: Paging to all eNodeBs belonging to the same TA in which the UE is currently registered The eNodeB is sending S1-AP: Initial UE message containing a Service Request to the MME MME is sending a S1-AP: Initial Context setup Request to eNOdeB enodeB sends a S1-AP: Initial Context Setup Complete to MME Data is re-established on both of directions.
Figure 87: Graceful Error Indication handling by SGW
6.2.5.1.2 Data Transfer on Default Bearer
Test Name: Successful Data Transfer on Default Bearer Reference TS 23.401 Section 5.3.2.1 Test Objective: Validate the successful data transfer on both of directions on default bearer Pre-Test Conditions: UE is not attached
Test Procedure: Perform UE attach with not any dedicated bearer being initiated by the network Initiate traffic from/to the UE with different traffic types: HTTP, FTP, etc
Expected Results: Verify that: eNodeB sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE=IMSI eNodeB sends a S1-AP Uplink NAS Tansport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message eNodeB sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0, EEAA1 or EEA2 for Ciphering as per the configuration eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. eNodeB sends a S1-AP: Initial Context Setup Response message eNodeB sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that all kind of Data can be transferred on the default bearer on both of directions for any traffic type.
6.2.5.1.3 Data Transfer on Dedicated Bearer Test Cases 6.2.5.1.3.1 Successful Data Transfer with non-GBR Service and AM Mode
Test Name: Sucessful Data Transfer with non-GBR Service and AM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with non-GBR Service and AM Mode on eNodeB Pre-Test Conditions: UE is in Active Mode eNodeB will use the RLC AM Mode
Test Procedure: Perform UE attach Initiate traffic to the UE with non-GBR, using RLC AM Mode at the eNodeB that will entail the creation of a dedicated bearer
Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that eNodeB is sending a S1-AP E-RAB Setup Response Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both eNodeB and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 89: Data Transfer on Dedicated Bearer with non-GBR Service and AM Mode
6.2.5.1.3.2 Successful Data Transfer with non-GBR Service and UM Mode
Test Name: Sucessful Data Transfer with non-GBR Service and UM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with non-GBR Service and UM Mode on eNodeB Pre-Test Conditions: UE is in Active Mode eNodeB will use the RLC UM Mode
Test Procedure: Perform UE attach Initiate traffic to the UE with non-GBR, using RLC UM Mode at the eNodeB that will entail the creation of a dedicated bearer
Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that eNodeB is sending a S1-AP E-RAB Setup Response Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both eNodeB and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 90: Data Transfer on Dedicated Bearer with non-GBR service and UM Mode
6.2.5.1.3.3 Successful Data Transfer with GBR Service and AM Mode
Test Name: Sucessful Data Transfer with GBR Service and AM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with GBR Service and AM Mode on eNodeB Pre-Test Conditions: UE is in Active Mode eNodeB will use the RLC AM Mode
Test Procedure: Perform UE attach Initiate traffic to the UE with GBR (QCI<4), using RLC AM Mode at the eNodeB that will entail the creation of a dedicated bearer
Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that eNodeB is sending a S1-AP E-RAB Setup Response Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both eNodeB and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 91: Data Transfer on Dedicated Bearer with GBR Service and AM Mode
6.2.5.1.3.4 Successful Data Transfer with GBR Service and UM Mode
Test Name: Sucessful Data Transfer with GBR Service and UM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with GBR Service and UM Mode on eNodeB Pre-Test Conditions: UE is in Active Mode eNodeB will use the RLC UM Mode
Test Procedure: Perform UE attach Initiate traffic to the UE with GBR (QCI<4), using RLC UM Mode at the eNodeB that will entail the creation of a dedicated bearer
Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that eNodeB is sending a S1-AP E-RAB Setup Response Validate that eNodeB is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both eNodeB and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.
Figure 92: Data Transfer on Dedicated Bearer with GBR Service and UM Mode
6.2.6 Mobility Test Cases 6.2.6.1.1 Intra-System Handover 6.2.6.1.1.1 X2 Based Handover 6.2.6.1.1.1.1 Successful HO with single E-RAB via X2 interface Test Name: Successful HO with single E-RAB via X2 interface Reference: TS 23.401, section 5.5.1.1.2 Test Objective: Validate the successful HO with single E-RAB via X2 interface. Validate also the subsequent HO Pre-Test Conditions: UE is in Active Mode in the source eNodeB with a single E-RAB established Two eNodeBs will be required for this test case. Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate an X2-based HO to the target eNodeB. Validate the first call flow below Initiate an X2-based HO to the former eNodeB. Validate the second call flow below
Expected Results: Verify that: Source e-NodeB initiates the X2-based HO with target eNodeB (message sequence out of the scope of this test plan) Target eNodeB will send a S1-AP: Path Switch Request to MME. The message will include E-RAB to be Switched in Downlink List IE including a single E-RAB, and also a Switched in Downlink Item IE which will contain the E-RAB ID IE, the Transport Layer Address IE and the GTP-TEID IE A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB a GTP-U End Of Marker message in order to indicates source eNodeB that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB. This message will include the E-RAB to Be Switched in Uplink IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint Target eNodeB will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB (not source eNodeB) after the completion of X2 HO. Validate that data traffic is continued with minimum disruption
Perform now a subsequent X2 HO. Validate that: e-NodeB 1 (original eNodeB) is sending a S1-AP Path Switch Request to MME. The message will include E-RAB to be Switched in Downlink List IE including a single E-RAB, and also a Switched in Downlink Item IE which will contain the 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 (eNodeB 2) a GTP-U End Of Marker message in order to indicates source eNodeB (eNodeB 2) that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB 1. This message will include the E-RAB to Be Switched in Uplink IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint Target eNodeB 1 will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB 1 performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB 1 (not source eNodeB 2) after the completion of X2 HO. Validate that data traffic is continued with minimum disruption
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 User Plane Update Request 4 User Plane Update Response 6 Path Switch Request Ack 7 Release Resource Downlink data 5. End marker 5. End marker 8. Tracking Area Update procedure 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 Ciphering is enabled Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least 1 E-RAB established Two eNodeBs will be required for this test case. Ciphering is enabled Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate an X2-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the X2-based HO with target eNodeB (message sequence out of the scope of this test plan) Target eNodeB will send a S1-AP: Path Switch Request to MME. The message will include E-RAB to be Switched in Downlink List IE including a single E-RAB, and also a Switched in Downlink Item IE which will contain the E-RAB ID IE, the Transport Layer Address IE and the GTP-TEID IE. This message will include also UE Security Capabilities IE indicating the support of EEA1 and/or EEA2 as per configuration. A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB a GTP-U End Of Marker message in order to indicates source eNodeB that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB. This message will include the E-RAB to Be Switched in Uplink IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint Target eNodeB will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB (not source eNodeB) after the completion of X2 HO. Validate that data traffic is continued with minimum disruption while ciphering is being performed
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 User Plane Update Request 4 User Plane Update Response 6 Path Switch Request Ack 7 Release Resource Downlink data 5. End marker 5. End marker 8. Tracking Area Update procedure 3a Update Bearer Request 3b Update Bearer Response
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 Pre-Test Conditions: UE is in Active Mode in the source eNodeB with multiple E-RABs established Two eNodeBs will be required for this test case. Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate an X2-based HO to the target eNodeB. Initiate an X2-based HO to the former eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the X2-based HO with target eNodeB (message sequence out of the scope of this test plan) Target eNodeB will send a S1-AP: Path Switch Request to MME. The message will include all the E-RABs to be Switched in Downlink List IE including all E-RABs, and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE, the Transport Layer Address IE and the GTP-TEID IEs A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB a GTP-U End Of Marker message in order to indicates source eNodeB that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB. This message will include all the E-RABs to Be Switched in Uplink IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint Target eNodeB will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB (not source eNodeB) after the completion of X2 HO. Validate that data traffic is continued with minimum disruption
Perform now a subsequent X2 HO. Validate that: e-NodeB 1 (original eNodeB) is sending a S1-AP Path Switch Request to MME. The message will include all the E-RABs to be Switched in Downlink List IE including all E-RABs, and also a Switched in Downlink Item IE which will contain the E-RAB ID IEs, the Transport Layer Address IE and the GTP-TEID IEs A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB (eNodeB 2) a GTP-U End Of Marker message in order to indicates source eNodeB (eNodeB 2) that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB 1. This message will include the E-RAB to Be Switched in Uplink IE, the list of E-RABs which are to be switched to the new GTP Tunnel Endpoint Target eNodeB 1 will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB 1 performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB 1 (not source eNodeB 2) after the completion of X2 HO. Validate that data traffic is continued with minimum disruption
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 User Plane Update Request 4 User Plane Update Response 6 Path Switch Request Ack 7 Release Resource Downlink data 5. End marker 5. End marker 8. Tracking Area Update procedure 3a Update Bearer Request 3b Update Bearer Response
Figure 95: Successful X2 HO with Multiple E-RABs
Note: Path Switch Request messages will include a list with all the E-RABs established towards the target eNodeB
6.2.6.1.1.1.4 Partially Successful HO with multiple E-RABs via X2 interface Test Name: Successful HO with multiple E-RAB via X2 interface Reference: TS 23.401 section 5.5.1.1.2 Test Objective: Validate the successful HO with multiple E-RAB via X2 interface. Pre-Test Conditions: UE is in Active Mode in the source eNodeB with multiple E-RABs established Two eNodeBs will be required for this test case. Make EPC to be unable to fully comply with the path witch (For example to allow only few E-RABs establishment through the target eNodeB) Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate an X2-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the X2-based HO with target eNodeB (message sequence out of the scope of this test plan) Target eNodeB will send a S1-AP: Path Switch Request to MME. The message will include all the E-RABs to be Switched in Downlink List IE including all E-RABs, and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE, the Transport Layer Address IE and the GTP-TEID IEs A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB a GTP-U End Of Marker message in order to indicates source eNodeB that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Request Acknowledge to Target eNodeB. This message will include all the E-RABs to Be Switched in Uplink IE, the list of E-RABs which are able to be switched to the new GTP Tunnel Endpoint. On the other hand, this message will include also a E-RAB to Be Released List IE containing the list of all E-RABS which were unable to be switched to the new GTP tunnel endpoint. Target eNodeB will send an X2-AP UE context Release message to the source eNodeB to indicate that the HO is completed and resources at the source eNodeB can be released Target enodeB performs a Tracking Area Update with MME in case TA has changed Validate that the resources remain alive only on MME and target eNodeB (not source eNodeB) after the completion of X2 HO. Validate that only some of the 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 Downlink and uplink data Handover preparation Forwarding of data Downlink data Uplink data 1 Path Switch Request 2 User Plane Update Request 4 User Plane Update Response 6 Path Switch Request Ack 7 Release Resource Downlink data 5. End marker 5. End marker 8. Tracking Area Update procedure 3a Update Bearer Request 3b Update Bearer Response
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 Reference: TS 23.401 section 5.5.1.1.2 Test Objective: Validate the expected call flow for an unsuccessful HO via X2 interface due to EPC failure Pre-Test Conditions: UE attached to the source eNodeB Make EPC to be unable to with the path switch Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate an X2-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the X2-based HO with target eNodeB (message sequence out of the scope of this test plan) Target eNodeB will send a S1-AP: Path Switch Request to MME. The message will include all the E-RABs to be Switched in Downlink List IE including all E-RABs, and also a Switched in Downlink Item IE which will contain all the E-RAB IDs IE, the Transport Layer Address IE and the GTP-TEID IEs A Modify Bearer Procedure will be successfully completed between MME and SGW to update the TEIDs The SGW will send to Source eNodeB a GTP-U End Of Marker message in order to indicates source eNodeB that shall start forwarding the GTP-U packets to Target eNodeB. Validate that Source eNodeB is honoring this request Validate that MME is sending a S1-AP Patch Switch Failure including a Cause IE indicating the reason for the path switch failure. Validate that MME is explicitly detaching the UE and there is not any resource hold by the network
Figure 97: Unsuccessful X2 HO Due to EPC Failure
6.2.6.1.1.2 S1 Based Handover 6.2.6.1.1.2.1 Successful S1 HO with single E-RAB Test Name: Successful S1 HO with Single E-RAB Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate the successful S1 based HO between two eNodeBs for single E- RAB Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least 1 E-RAB established Two eNodeBs will be required for this test case.
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Request to Target eNodeB including the 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 11. Modify Bearer Response 10. Modify Bearer Request
Downlink User Plane data 2. Handover Required Downlink User Plane data 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
12. Tracking Area Update procedure 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 Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate the successful S1 based HO between two eNodeBs for multiple E-RABs Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least two E-RABs established Two eNodeBs will be required for this test case.
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate traffic also for the rest of bearers (e.g ICMP) Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Request to Target eNodeB including the E- RABs to be setup List IE, containing all the E-RAB Ids Target eNodeB sends a S1-AP Handover Request Acknowledge to MME including the E-RABs Admitted List IE containing all the successful E-RABs id that were able to be established The MME sends a S1-AP Handover Command to the source eNodeB including the Target to Source Transparent Container IE The source e-NodeB sends a S1-AP: eNodeB Status Transfer to MME including the eNodeB Status Transfer Transparent Container IE with the list of all the 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 for all the bearers MME and Target eNodeB will perform Tracking Area Update if is required (target eNodeB TAC is not into the current UE TAC list)
UE Source eNodeB
MME PDN GW Serving GW
Target eNodeB Detach from old cell and synchronize to new cell 11. Modify Bearer Response 10. Modify Bearer Request
Downlink User Plane data 2. Handover Required Downlink User Plane data 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
12. Tracking Area Update procedure 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 99: Successful S1 HO with Multiple E-RABs Note: Handover Request includes multiple E-RABs. The Handover Request ACK will include all the E-RABs into the admitted list (all of them were successfully established)
6.2.6.1.1.2.3 Partially Successful S1 HO with multiple E-RABs Test Name: Successful S1 HO with multiple E-RABs Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate the graceful behavior after a partially successful S1 based HO between two eNodeBs for multiple E-RABs Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least two E-RABs established Two eNodeBs will be required for this test case. Configure target eNodeB to accept only a subset of E-RABs
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate traffic also for the rest of bearers (e.g ICMP) Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Request to Target eNodeB including the E- RABs to be setup List IE, containing all the E-RAB Ids Target eNodeB sends a S1-AP Handover Request Acknowledge to MME including the E-RABs Admitted List IE containing all the successful E-RABs id that were able to be established. It also contains the E-RABs Failed to Setup List IE containing the list of all the E-RAB IDs for each E-RAB not accepted by the target eNodeB The MME sends a S1-AP Handover Command to the source eNodeB including the Target to Source Transparent Container IE The source e-NodeB sends a S1-AP: eNodeB Status Transfer to MME including the eNodeB Status Transfer Transparent Container IE with the list of all the 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 for all the bearers MME and Target eNodeB will perform Tracking Area Update if is required (target eNodeB TAC is not into the current UE TAC list)
UE Source eNodeB
MME PDN GW Serving GW
Target eNodeB Detach from old cell and synchronize to new cell 11. Modify Bearer Response 10. Modify Bearer Request
Downlink User Plane data 2. Handover Required Downlink User Plane data 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
12. Tracking Area Update procedure 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 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 Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate the expected call flow for an unsuccessful S1 HO due to fail on MME Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least two E-RABs established Two eNodeBs will be required for this test case. Configure MME to reject the HO (e.g S1-AP between MME and Target eNodeB is down)
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Preparation Failure including a Cause IE indicating the reason for the HO failure Validate that UE context is still alive through source eNodeB and there is ongoing data transfer between S-GW and source eNodeB while RF is still acceptable.
Figure 101: Unsuccessful S1 HO due to fail on MME-Target eNodeB connectivity
6.2.6.1.1.2.5 Unsuccessful S1 based HO due to not common ciphering algorithm Test Name: Unsuccessful S1 HO due to not common ciphering algorithm Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate that the PS Call will not drop after the S1 HO for single-RAB fails because of no common ciphering algorithm Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least two E-RABs established Two eNodeBs will be required for this test case. Configure target eNodeB and UE to not have ta common ciphering algorithm
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Request to Target eNodeB including the E- RABs to be setup List IE, containing all the E-RAB Ids Target eNodeB is sending a S1-AP Handover Failure to MME including a Cause IE set to Encryption and/or integrity protection algorithm not supported MME is sending a S1-AP Handover Failure to enodeB including the same Cause IE Validate that UE context is still alive through source eNodeB and there is ongoing data transfer between S-GW and source eNodeB while RF is still acceptable.
Figure 102: Unsuccessful S1 HO due to non common Ciphering algorithm
6.2.6.1.1.2.6 Unsuccessful S1 based HO due to no resources available at target eNodeB Test Name: Unsuccessful S1 HO due to not resources available at target eNodeB Reference: TS 23.401 section 5.5.1.2.2 Test Objective: Validate that the PS Call will not drop after the S1 HO for single-RAB fails because of no resources available at target eNodeB Pre-Test Conditions: UE is in Active Mode in the source eNodeB with at least two E-RABs established Two eNodeBs will be required for this test case. Configure target eNodeB to not accept any E-RAB and generage Handover Failure message
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate a S1-based HO to the target eNodeB.
Expected Results: Verify that: Source e-NodeB initiates the S1 HO by sending a S1-AP Handover Required to MME. The HandOver Required message includes Handover Type IE= Intra LTE, the Direct Forwarding Path Availability IE, the Source to Target Transparent Container IE, the Target ID IE (including the target eNodeB identity and selected TAI) and the Cause IE indicating the reason for the HO MME is sending a S1-AP Handover Request to Target eNodeB including the E- RABs to be setup List IE, containing all the E-RAB Ids Target eNodeB is sending a S1-AP Handover Failure to MME including the corresponding Cause IE MME is sending a S1-AP Handover Failure to enodeB including the same Cause IE Validate that UE context is still alive through source eNodeB and there is ongoing data transfer between S-GW and source eNodeB while RF is still acceptable.
Figure 103: Unsuccessful S1 based HO due to no resources available at target eNodeB
6.2.6.1.2 Inter-System Handover 6.2.6.1.3 LTE to UTRAN Inter RAT Handover 6.2.6.1.3.1 Successful LTE to UTRAN HO for a single E-RAB Test Name: Successful LTE to UTRAN HO for a single E-RAB Reference: TS 23.401 section 5.5.2.1.2 Test Objective: Validate the successful LTE to UTRAN HO in a single E-RAB environment Pre-Test Conditions: UE is in Active Mode in the source eNodeB with 1 E-RAB established 1 eNodeB and 1 nodeB will be required for this test
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate the LTE to UTRAN HO
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Handover Required to MME with Handover Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of the target cell, as well as a source to target transparent container IE. Validate that MME is sending a Forward Relocation Request to 3G-SGSN. o 3G-SgSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. Validate that data transfer is continued via UTRAN and no resource is hold at LTE eNodeB.
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 Target RNC Source MME Target SGSN Serving GW HSS PDN GW Uplink and Downlink User Plane PDUs 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 7. Modify Bearer Request 8a. Modify Bearer Response 9. Modify Bearer Response Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used) 4a. Handover to UTRAN Complete Downlink User Plane PDUs If Direct Forwarding applies If Indirect Forwarding applies. Target Serving GW (A) 8. Modify Bearer Request Via Target SGSN in case Direct Tunnel is not used 10. Routeing Area Update procedure 11. Delete Session Request (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 13. Delete Indirect Data Forwarding Tunnel Request 13a. Delete Indirect Data Forwarding Tunnel Response 12a. Delete Indirect Data Forwarding Tunnel Response
Figure 105: Successful LTE to UTRAN HO for single E-RAB (Execution Phase) Note: This call flow covers the Execution Phase Until the HO is successfully completed
6.2.6.1.3.2 Successful LTE to UTRAN HO for multiple E-RABs Test Name: Successful LTE to UTRAN HO for multiple E-RABs Reference: TS 23.401 section 5.5.2.1.2 Test Objective: Validate the successful LTE to UTRAN HO in a multiple E-RABs environment Pre-Test Conditions: UE is in Active Mode in the source eNodeB with 2 E-RABs established 1 eNodeB and 1 nodeB will be required for this test
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate the LTE to UTRAN HO
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Handover Required to MME with Handover Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of the target cell, as well as a source to target transparent container IE. Validate that MME is sending a Forward Relocation Request to 3G-SGSN (The relocation request includes two RAB IDs) o 3G-SGSN forwards the relocation request to the target RNC (The relocation request includes two RAB IDs) o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. Validate that data transfer is continued via UTRAN and no resource is hold at LTE eNodeB.
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 Target RNC Source MME Target SGSN Serving GW HSS PDN GW Uplink and Downlink User Plane PDUs 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 7. Modify Bearer Request 8a. Modify Bearer Response 9. Modify Bearer Response Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used) 4a. Handover to UTRAN Complete Downlink User Plane PDUs If Direct Forwarding applies If Indirect Forwarding applies. Target Serving GW (A) 8. Modify Bearer Request Via Target SGSN in case Direct Tunnel is not used 10. Routeing Area Update procedure 11. Delete Session Request (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 13. Delete Indirect Data Forwarding Tunnel Request 13a. Delete Indirect Data Forwarding Tunnel Response 12a. Delete Indirect Data Forwarding Tunnel Response
Figure 107: Successful LTE to UTRAN HO with Multiple E-RABs (Execution Phase) Note: This call flow covers the Execution Phase Until the HO is successfully completed
6.2.6.1.3.3 LTE to UTRAN HO failure due to connectivity issues
Figure 108: LTE to UTRAN HO Failure due to connectivity issues Test Name: LTE to UTRAN HO failure due to connectivity issues Reference: TS 23.401 section 5.5.2.1.2 Test Objective: Validate the inter RAT Failure for a UE does not release the UE context in the EPC network Pre-Test Conditions: UE is in Active Mode in the source eNodeB 1 eNodeB and 1 nodeB will be required for this test Bring down the link between MME and SGSN or the link between SGSN and RNC to entail the HO to fail
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate the LTE to UTRAN HO
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Handover Required to MME with Handover Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of the target cell, as well as a source to target transparent container IE. Validate that MME is sending back a S1-AP Handover Preparation Failure. The Cause IE shall be set to the reason of the handover failure Validate that the UE context is not released and data transfer is continued via EUTRAN between eNodeB and SGW.
6.2.6.1.3.4 LTE to UTRAN HO failure due to not resources at NodeB Test Name: LTE to UTRAN HO failure due to not resources at NodeB Reference: TS 23.401 section 5.5.2.1.4 Test Objective: Validate the inter RAT Failure for a UE does not release the UE context in the EPC network Pre-Test Conditions: UE is in Active Mode in the source eNodeB 1 eNodeB and 1 nodeB will be required for this test Configure the target NodeB to not allow any more calls (simulate overload situation)
Test Procedure: Initiate a FTP session (will transfer data in both of directions) of a large file that can span the handover time Initiate the LTE to UTRAN HO
Expected Results: Verify that: Validate that eNodeB sends a S1-AP Handover Required to MME with Handover Type IE set ot LTEtoUTRAN. It also contains a Target ID IE with the RNC-ID of the target cell, as well as a source to target transparent container IE. Validate that MME is sending back a S1-AP Handover Preparation Failure. The Cause IE shall be set to No Radio Resources Available in Target Cell. Please remember this cause code is originated in the target radio access side Validate that the UE context is not released and data transfer is continued via EUTRAN between eNodeB and SGW.
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 Reference: TS 23.272 section 6.4 Test Objective: Validate the successful CS-Fallback to UTRAN network triggered by the mobile originated call while the UE is in Idle Mode Pre-Test Conditions: UE supports CS fallback UE is in Idle Mode UE is attached for both EPS and non-EPS services VoIP Services are not available 1 eNodeB and 1 nodeB will be required for this test
Test Procedure: Initiate a mobile originated speech call After the UE is handed over to UTRAN network and CS call has been established, release the CS call
Expected Results: Verify that:
eNodeB sends back a S1-AP Initial UE message encapsulating a NAS Extended Service Request. The service Type IE inside that message shall be set to mobile terminating CS fallback or 1xCS Fallback. It will also contain a CSFB response IE set to CS fallback accepted by the UE MME sends a S1-AP Initial Context Setup Request to eNodeB, including a CS Fallback Inidicator IE. eNodeB optionally may initiate a measurement control procedure to find out the target UTRANcell. eNodeB sends a S1-AP Initial Context Setup Response to MME eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell o 3G-SGSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. CS call is established via UTRAN. Validate that the CS call can be successfully performed. Validate that once the call is ended the UE returns to LTE network
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 Test Name: LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile terminated call, UE in Idle Mode Reference: TS 23.272 section 7.2 Test Objective: Validate the successful CS-Fallback to UTRAN network triggered by the mobile terminated call while the UE is in Idle Mode Pre-Test Conditions: UE supports CS fallback UE is in Idle Mode UE is attached for both EPS and non-EPS services VoIP Services are not available 1 eNodeB and 1 nodeB will be required for this test Test Procedure: Initiate a mobile terminated speech call After the UE is handed over to UTRAN network and CS call has been established, release the CS call
Expected Results: Verify that: MME sends a S1-AP Paging to eNodeB with CN Domain IE set to CS eNodeB sends back a S1-AP Initial UE message encapsulating a NAS Extended Service Request. The service Type IE inside that message shall be set to mobile terminating CS fallback or 1xCS Fallback. It will also contain a CSFB response IE set to CS fallback accepted by the UE MME sends a S1-AP Initial Context Setup Request to eNodeB, including a CS Fallback Inidicator IE. eNodeB optionally may initiate a measurement control procedure to find out the target UTRANcell. eNodeB sends a S1-AP Initial Context Setup Response to MME eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell o 3G-SGSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. CS call is established via UTRAN. Validate that the CS call can be successfully performed. Validate that once the call is ended the UE returns to LTE network
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 2. Optional Measurement Report Solicitation 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 1b. NAS Extended Service Request 1d. S1-AP UE Context Modification Request with CS Fallback indicator 1c. CS Paging Reject 7a. Suspend (see TS 23.060) 8. Update bearer(s) 7b. Suspend Request / Response 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 1e. S1-AP UE Context Modification Response message 9a. Establish CS connection
Figure 113: LTE to UTRAN CS-Fallback (Execution Phase without PS HO Supported)
6.2.6.1.3.7 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile Originated Call, UE in Active Mode Test Name: LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile originated call, UE in Idle Mode Reference: TS 23.272 sections 6.2 and 6.3 Test Objective: Validate the successful CS-Fallback to UTRAN network triggered by the mobile originated call while the UE is in Idle Mode Pre-Test Conditions: UE supports CS fallback UE is in Active mode transmitting data UE is attached for both EPS and non-EPS services VoIP Services are not available 1 eNodeB and 1 nodeB will be required for this test
Test Procedure: Initiate a mobile originated speech call After the UE is handed over to UTRAN network and CS call has been established, release the CS call
Expected Results: Verify that: eNodeB sends a S1-AP Uplink NSA Transport encapsulating a NAS Extended Service Request including a Service Type IE set to mobile originating CS fallback or 1xCS Fallback MME sends a S1-AP UE Context Modification Request with CS Fallback Indicator IE set to CS Fallback Required.eNodeB optionally may initiate a measurement control procedure to find out the target UTRANcell. eNodeB sends a S1-AP UE Context Modification Response eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell o 3G-SGSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. CS call is established via UTRAN. Validate that the CS call can be successfully performed. Validate that once the call is ended the UE returns to LTE network
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 114: LTE to UTRAN CS-Fallback, MO Call, UE in Active Mode
6.2.6.1.3.8 LTE to UTRAN CS-Fallback: Inter RAT HO triggered by mobile Terminated Call, UE in Active Mode Test Name: LTE to UTRAN CS-Fallback: Inter RAT HO Triggered by a mobile terminated call, UE in Active Mode Reference: TS 23.272 sections 7.3 and 7.4 Test Objective: Validate the successful CS-Fallback to UTRAN network triggered by the mobile terminated call while the UE is in Active Mode Pre-Test Conditions: UE supports CS fallback UE is in Active mode transmitting data UE is attached for both EPS and non-EPS services VoIP Services are not available 1 eNodeB and 1 nodeB will be required for this test
Test Procedure: Initiate a mobile originated speech call After the UE is handed over to UTRAN network and CS call has been established, release the CS call
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 eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell o 3G-SGSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Forward Relocation Response is sent by 3G-SGSN to MME MME sends a S1-AP Handover Command to eNodeB o RNC sends a Reloction Detect to 3G-SGSN o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. CS call is established via UTRAN. Validate that the CS call can be successfully performed. Validate that once the call is ended the UE returns to LTE network
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 2. Optional Measurement Report Solicitation 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 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 1b. NAS Extended Service Request 1d. S1-AP UE Context Modification Request with CS Fallback indicator 1c. CS Paging Reject 7a. Suspend (see TS 23.060) 8. Update bearer(s) 7b. Suspend Request / Response 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 1e. S1-AP UE Context Modification Response message 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 Reference: TS 23.216 section 6.2.2.1 Test Objective: Validate the successful SRVCC when the UE has a VoIP call ongoing Pre-Test Conditions: UE is registered on both MME and HSS
Test Procedure: Initiate speech through the IMS/LTE network Trigger SRVCC Inter RAT HO to UTRAN Validate that VoIP Call continues after the HO
Expected Results: Verify that: eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell. It shall also contain SRVCC HO Indication IE set to CS Only o 3SRVCC PS to CS Request sent from MME to MSC Server o MSC sends a Relocation Request from MME to 3G-SGSN o Relocation Request sent from MSC Server to RNC o Target RNC send Relocation Request Acknowledge to MSC o MSC Server sends SRVCC PS to CS Response to MME MME sends a S1-AP Handover Command to eNodeB o RNC Relocation Detect to MSC Server o RNC sends a Relocation Complete to MSC Server o MSC sends a SRVCC PS to CS Complete Notification to MME o MME sends SRVCC PS to CS Complete Notification Ack to MSC Server MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. Validate that voice call is ongoing via UTRAN
UE Source E-UTRAN Source MME MSC Server/ MGW Target MSC 14. Handover Command Target BSS 1. Measurement reports 3. Handover Required 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 Reference: TS 23.216 section 6.2.2.2 Test Objective: Validate the successful SRVCC when the UE has both data transfer and VoIP calls ongoing Pre-Test Conditions: UE is registered on both MME and HSS
Test Procedure: Initiate speech through the IMS/LTE network Initiate data transfer of a big file Trigger SRVCC Inter RAT HO to UTRAN Validate that both data transfer and VoIP Call continues after the HO
Expected Results: Verify that: eNodeB sends a S1-AP Handover Required to MME. The Handover Type IE shall be set to LTEtoUTRAN and the Target ID shall contain the RNC-ID of the target cell. It shall also contain SRVCC HO Indication IE set to PS and CS o 3SRVCC PS to CS Request sent from MME to MSC Server o MSC sends a Relocation Request from MME to 3G-SGSN o Relocation Request sent from MSC Server to RNC o 3G-SGSN forwards the relocation request to the target RNC o Target RNC sends back a Relocation Request acknowledge to 3G-SGSN o Target RNC send Relocation Request Acknowledge to MSC o Forward Relocation Response is sent by 3G-SGSN to MME o MSC Server sends SRVCC PS to CS Response to MME MME sends a S1-AP Handover Command to eNodeB o RNC Relocation Detect to MSC Server o RNC sends a Relocation Detect to 3G-SGSN o RNC sends a Relocation Complete to MSC Server o RNC sends a Relocation Complete to 3G-SGSN o 3G-SGSN sends a forward Relocation Complete Notification to MME o MSC sends a SRVCC PS to CS Complete Notification to MME o MME sends SRVCC PS to CS Complete Notification Ack to MSC Server o MME sends a Forward Relocation Complete ACK to 3G-SGSN o There is a Routing Area Update between UE and 3G-SGSN MME sends a S1-AP UE Context Release Command with Cause IE set to Successful Handover eNodeB sends a S1-AP UE Context Release Complete to MME. Validate that Data Transfer and voice call are ongoing via UTRAN
13. Handover Command 1. Measurement reports 3. Handover Required 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 Reference: TS 23.401 section 5.5.2.2 Test Objective: Validate the successful inter RAT Handover for a UE with a single RAB from UTRAN to LTE Pre-Test Conditions: UE is operating in the UTRAN network UE has established a single RAB
Test Procedure: Initiate data transfer of a big file Trigger an inter RAT Handover for LTE
Expected Results: Verify that: Validate that during the preparation phase in the 3G part: o RNC sends a Relocation Request to 3G-SGSN o 3G-SGSN forwards the relocation request to MME MME sends a S1-AP Handover Request to eNodeB; The Handover Request will present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup List IE group contains only 1 E-RABid eNodeB sends a S1-AP Handover Request Acknowledge containing the same 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
5a. Handover Request Acknowledge 8 . Create Indirect Data Forwarding Tunnel Request 7 . Forward Relocation Response PDN GW 8a. Create Indirect Data Forwarding Tunnel Response Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)
6 . Create Indirect Data Forwarding Tunnel Request
6 a . Create Indirect Data Forwarding Tunnel Response
Figure 119: Successful UTRAN to LTE Inter RAT HO for a single RAB (Preparation Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by MME to SGSN). Forward Relocation Request include the list of all the E-RABs to be established. Preparation phase is followed by the Execution Phase (call flow below)
UE Source RNC Target eNodeB Source SGSN Target MME Serving GW HSS 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 7. Forward Relocation Complete Notification 7a. Forward Relocation Complete Acknowledge 8. Modify Bearer Request 9a. Modify Bearer Response 10. Modify Bearer Response Uplink and Downlink User Plane PDUs Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used) If Direct Forwarding applies If Indirect Forwarding applies Target Serving GW For Serving GW relocation Steps 8, 9 and 10, and the following User Plane path, will be handled by Target Serving GW (A) 9. Modify Bearer Request 11. Tracking Area Update procedure 12. Delete Session Request (B) 12a. Delete Session Response 12b. Iu Release Procedure Sending of uplink data possible 13. Delete Indirect Data Forwarding Tunnel Request Via Source SGSN in case Direct Tunnel is not used Source 13a. Delete Indirect Data Forwarding Tunnel Response 14. Delete Indirect Data Forwarding Tunnel Request 14a. Delete Indirect Data Forwarding Tunnel Response
Figure 120: Successful UTRAN to LTE Inter RAT HO for a single RAB (Execution Phase)
Note: This call flow covers the Execution Phase (Until UTRAN to LTE Inter RAT HO is successfully completed)
6.2.6.1.4.2 Successful UTRAN to LTE Inter RAT Handover for multiple RABs
Test Name: Successful UTRAN to LTE Inter RAT Handover for multiple RABs Reference: TS 23.401 section 5.5.2.2 Test Objective: Validate the successful inter RAT Handover for a UE with multiple RABs from UTRAN to LTE Pre-Test Conditions: UE is operating in the UTRAN network UE has established at least 2 RABs
Test Procedure: Initiate data transfer of a big file over each RAB Trigger an inter RAT Handover for LTE Verify that the data transfer continue for the two RABs after the inter RAT HO is completed
Expected Results: Verify that: Validate that during the preparation phase in the 3G part: o RNC sends a Relocation Request to 3G-SGSN o 3G-SGSN forwards the relocation request to MME MME sends a S1-AP Handover Request to eNodeB; The Handover Request will present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup List IE group contains all the RAB-IDs eNodeB sends a S1-AP Handover Request Acknowledge containing the same 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 MME sends a Forward Relocation Complete Notification to 3G-SGSN o 3G-SGSN acknowledges by sending back a Forward Relocation Ack to MME There is a Tracking Area Update procedure from UE->eNodeB->MME After that, a Iu Release procedure between source RNC and 3G-SGSN shall be successfully performed Validate that the data is still ongoing via E-UTRAN for each E-RAB and no resource is hold by the UTRAN network
5a. Handover Request Acknowledge 8 . Create Indirect Data Forwarding Tunnel Request 7 . Forward Relocation Response PDN GW 8a. Create Indirect Data Forwarding Tunnel Response Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)
6 . Create Indirect Data Forwarding Tunnel Request
6 a . Create Indirect Data Forwarding Tunnel Response
Figure 121: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Preparation Phase)
Note: This call flow covers the Preparation Phase (Until Forward Relocation Response is sent by MME to SGSN). Handover Request will include the list of all the E-RABs to be established, and Handover Request Ack will include the list of all the E-RABs successfully established and, if occurs, the list of E-RABs failed to be set up. Preparation phase is followed by the Execution Phase (call flow below)
UE Source RNC Target eNodeB Source SGSN Target MME Serving GW HSS 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 7. Forward Relocation Complete Notification 7a. Forward Relocation Complete Acknowledge 8. Modify Bearer Request 9a. Modify Bearer Response 10. Modify Bearer Response Uplink and Downlink User Plane PDUs Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used) If Direct Forwarding applies If Indirect Forwarding applies Target Serving GW For Serving GW relocation Steps 8, 9 and 10, and the following User Plane path, will be handled by Target Serving GW (A) 9. Modify Bearer Request 11. Tracking Area Update procedure 12. Delete Session Request (B) 12a. Delete Session Response 12b. Iu Release Procedure Sending of uplink data possible 13. Delete Indirect Data Forwarding Tunnel Request Via Source SGSN in case Direct Tunnel is not used Source 13a. Delete Indirect Data Forwarding Tunnel Response 14. Delete Indirect Data Forwarding Tunnel Request 14a. Delete Indirect Data Forwarding Tunnel Response
Figure 122: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Execution Phase)
Note: This call flow covers the Execution Phase (Until UTRAN to LTE Inter RAT HO is successfully completed)
6.2.6.1.4.3 UTRAN to LTE Inter RAT Handover failure due to no resources at the eNodeB Test Name: Unsuccessful UTRAN to LTE Inter RAT Handover due to no resources at the eNodeB Reference: TS 23.401 section 5.5.2.2 Test Objective: Validate the call flow for an unsuccessful Inter RAT HO for a UE due to no resources at the eNodeB Pre-Test Conditions: UE is operating in the UTRAN network UE has established at least 1 RAB Configure eNodeB to present an overload situation
Test Procedure: Initiate data transfer of a big file over each RAB Trigger an inter RAT Handover for LTE Verify that the inter RAT HO fails but that the data transfer does not stop due to this failure.
Expected Results: Verify that: Validate that during the preparation phase in the 3G part: o RNC sends a Relocation Request to 3G-SGSN o 3G-SGSN forwards the relocation request to MME MME sends a S1-AP Handover Request to eNodeB; The Handover Request will present a Handover Type IE set to UTRANtoLTE and the E-RABs to Be Setup List IE group contains all the RAB-IDs eNodeB sends a S1-AP Handover Failure with a Cause IE Set to No Radio Resources Available at Target Cell After this failure reception, validate: o MME sends a Forward Relocation Complete Notification to 3G-SGSN o 3G-SGSN sends a Relocation Preparation Failure to source RNC Validate that, despite of the Inter RAT HO failure, the data is still ongoing via UTRAN as far as RF signal quality allows it.