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

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

Table of Contents 1 SCOPE... 10 2 REFERENCES... 10 3 ABBREVIATIONS... 11 4 OVERVIEW... 14 5 TEST CONFIGURATION... 16 5.1 NETWORK & INTERFACE CONFIGURATION (OVERVIEW)... 16... 17 5.2 NETWORK ELEMENTS SOFTWARE VERSION... 18 5.3 TEST EQUIPMENT... 18 6 DETAILED TEST CASES... 19 6.1 MANAGEMENT, TRACING AND LOCATION REPORT TEST CASES... 19 6.1.1 MANAGEMENT PROCEDURES OVER SCTP... 19 6.1.1.1 S1 Setup between MME and enodeb in a single PLMN configuration... 19 6.1.1.1.1 Successful S1 Setup... 19 6.1.1.1.2 Unsuccessful S1 Setup... 21 6.1.1.2 S1 Setup between MME and enodeb in a multiple PLMN configuration (MOCN configuration)... 22 6.1.1.2.1 Successful S1 Setup... 22 6.1.1.2.2 Unsuccessful S1 Setup... 23 6.1.1.3 S1 Configuration Update (MME Initiated)... 24 6.1.1.3.1 Successful S1 MME Configuration Update... 24 6.1.1.3.2 Unsuccessful S1 MME Configuration Update... 25 6.1.1.4 S1 Configuration Update (enodeb Initiated)... 26 6.1.1.4.1 Successful S1 Configuration Update (enodeb Initiated)... 26 6.1.1.4.2 Unsuccessful S1 Configuration Update (enodeb Initiated)... 27 6.1.1.5 S1 Reset Procedures... 27 6.1.1.5.1 S1 Reset initiated by enodeb... 28 6.1.1.5.2 S1 Reset initiated by MME... 29 6.1.1.6 S1 Recovery after nodes failure... 30 6.1.1.6.1 S1 Recovery after enodeb restart... 30 6.1.1.6.2 S1 Recovery after MME restart... 32 6.1.1.6.3 S1 Recovery after SGW restart... 33 6.1.1.6.4 S1 Recovery from S1 failure due to physical connections lost... 35 6.1.2 TRACE AND LOCATION REPORTING PROCEDURES... 37 6.1.2.1 Trace Procedures... 37 6.1.2.1.1 Trace Start... 37 6.1.2.1.1.1 Trace Start supporting S1 interface... 37 6.1.2.1.1.2 Trace Start supporting X2 interface... 39 6.1.2.1.2 Deactivate Trace... 41 6.1.2.2 Location Reporting Procedures... 43 6.1.2.2.1 Successful location reporting for a direct report of the UE location... 43 6.1.2.2.2 Successful location reporting for serving cell change... 45

6.1.2.2.3 Successful cancellation of location reporting for serving cell change... 47 6.2 FUNCTIONAL TEST CASES... 49 6.2.1 ATTACH/DETACH... 49 6.2.1.1 Successful EPS Attach with UE unknown in MME and no Ciphering... 49 6.2.1.2 Successful EPS Attach with UE unknown in MME and Ciphering... 52 6.2.1.3 Successful EPS Attach procedure with UE known in MME and no Ciphering... 55 6.2.1.4 Successful EPS Attach procedure with UE known in MME with Ciphering... 57 6.2.1.5 Successful EPS Attach procedure with IMSI... 59 6.2.1.6 Unsuccessful EPS Attach due to IMSI unknown on HSS... 61 6.2.1.7 Successful EPS Detach initiated by UE... 63 6.2.1.8 Successful EPS Detach initiated by UE due to switch off... 64 6.2.1.9 Successful EPS Detach initiated by MME... 66 6.2.2 E- RAB PROTOCOL PROCEDURES... 68 6.2.2.1 E- RAB Setup... 68 6.2.2.1.1 Successful E- RAB establishment for... 68 6.2.2.1.2 Successful E- RAB establishment for UE Aggregate Maximum Bit Rate IE is included 69 6.2.2.1.3 Successful E- RAB establishment for multiple E- RABs... 71 6.2.2.2 E- RAB Modify... 72 6.2.2.2.1 Successful E- RAB modification... 72 6.2.2.2.2 Successful E- RAB modification for multiple E- RABs... 74 6.2.2.2.3 Successful and Unsuccessful E- RAB modification for multiple E- RABs... 75 6.2.2.3 E- RAB Release... 76 6.2.2.3.1 E- RAB Release initiated by MME... 76 6.2.2.3.2 E- RAB Release initiated by enodeb... 78 6.2.3 EPC BEARERS FUNCTIONAL PROCEDURES... 80 6.2.3.1 Dedicated bearer Activation... 80 6.2.3.1.1 Successful Dedicated Bearer Activation initiated by the network... 80 6.2.3.1.2 Successful Dedicated Bearer Activation initiated by the UE... 82 6.2.3.1.3 Successful Dedicated Bearer Activation during attach... 84 6.2.3.2 Bearer Modification... 86 6.2.3.2.1 Bearer Modification initiated by the EPC... 86 6.2.3.2.1.1 PDN GW initiated bearer modification with QoS Update... 86 6.2.3.2.1.2 HSS initiated Subscriber QoS Modification... 87 6.2.3.2.1.3 Network Initiated Bearer modification without Bearer QoS Update... 88 6.2.3.2.2 Bearer Modification initiated by the UE... 90 6.2.3.2.2.1 UE Requested Bearer Modification accepted by the network... 90 6.2.3.2.2.2 UE Requested Bearer Modification without QoS update accepted by the network92 6.2.3.3 Dedicated Bearer deactivation... 94 6.2.3.3.1 PDN GW initiated Dedicated Bearer Deactivation... 94 6.2.3.3.2 MME initiated Dedicated Bearer Deactivation... 95 6.2.3.3.3 UE initiated Dedicated Bearer Deactivation... 97 6.2.4 IDLE MODE AND CONTEXT MANAGEMENT PROCEDURES... 98 6.2.4.1 Active to Idle mode Transition (Context Release)... 98 6.2.4.1.1 UE/eNodeB Context Release due to User Inactivity with a single bearer established 98 6.2.4.1.2 UE/eNodeB Context Release due to User Inactivity with multiple bearers established 100 6.2.4.2 UE Context Release due to radio connection with UE lost... 102 6.2.4.3 Tracking Area Update procedures... 103

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

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

Index of Figures Figure 1: S1 Interface Protocol Stack towards MME... 14 Figure 2: S1 Interface Protocol Stack towards S-GW... 15 Figure 3: Network Configuration for regular test cases... 16 Figure 4: Network Configuration for intra-rat HO Test Cases... 17 Figure 5: Network Configuration for Inter-RAT HO Test Cases... 17 Figure 6: Setup Procedure Successful Operation... 20 Figure 7: S1 Setup Procedure - Unsuccessful Operation... 21 Figure 8: S1 Setup Procedure: Successful Operation... 22 Figure 9: S1 Setup Procedure: Unsuccessful Operation... 23 Figure 10: MME Configuration Update Procedure: Successful Operation... 24 Figure 11: MME Configuration Update: Unsuccessful Operation... 25 Figure 12: ENB Configuration Update Procedure: Successful Operation... 26 Figure 13: ENB Configuration Update Procedure: Unsuccessful Operation... 27 Figure 14: Reset Procedure Initiated From the E-UTRAN Successful Operation... 28 Figure 15: Reset Procedure Initiated From the MME Successful Operation... 29 Figure 16: Reset Procedure Initiated From the E-UTRAN Successful Operation... 31 Figure 17: Reset Procedure Initiated From the MME Successful Operation... 33 Figure 18: UE Context Release Procedure Successful Operation... 34 Figure 19: Setup Procedure Successful Operation... 36 Figure 20: Trace Start Procedure... 38 Figure 21: Cell Traffic Trace Procedure - Successful Operation... 38 Figure 22: Trace Failure Indication Procedure... 38 Figure 23: Trace Start Procedure... 39 Figure 24: Cell Traffic Trace Procedure - Successful Operation... 40 Figure 25: Trace Failure Indication Procedure... 40 Figure 26: Deactivate Trace... 41 Figure 27: Trace Failure Indication Procedure... 42 Figure 28: Location Reporting Control Procedure - Successful Operation... 43 Figure 29: Location Report Failure Indication Procedure... 44 Figure 30: Location Reporting Control Procedure - Successful Operation... 45 Figure 31: Location Report Procedure - Successful Operation... 46 Figure 32: Location Report Failure Indication... 46 Figure 33: Location Reporting Control Procedure - Successful Operation... 47 Figure 34: Location Report Failure Indication Procedure... 48 Figure 35: Successful EPS Attach with UE unknown in MME and No Ciphering... 51 Figure 36: Successful EPS Attach with MME unknown in MME and Ciphering... 54 Figure 37: Successful EPS Attach procedure with UE known in MME and No Ciphering... 56 Figure 38: Successful EPS Attach with UE known in MME and Ciphering... 58 Figure 39: Successful EPS Attach with IMSI... 60 Figure 40: Unsuccessful EPS Attach due to IMSI unknown on HSS... 62 Figure 41: Successful EPS detach initiated by UE... 63 Figure 42: Successful EPS Detach initiated by UE due to switch off... 65 Figure 43: Successful EPS Detach initiated by MME... 67

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

Figure 81: Successful Service Request when UE is in Idle mode and has a mobile originating 1xCS fallback request... 132 Figure 82: Successful Service Request when UE is in Active Mode and has a mobile originating 1xCS fallback request... 134 Figure 83: Successful Initial UE message with Emergency Flag enabled... 135 Figure 84: GTP-U Echo mechanism... 136 Figure 85: GTP-U message "End of Marker"... 138 Figure 86: Graceful Error Indication handling by enodeb... 139 Figure 87: Graceful Error Indication handling by SGW... 141 Figure 88: Data Transfer on Default Bearer... 143 Figure 89: Data Transfer on Dedicated Bearer with non-gbr Service and AM Mode. 145 Figure 90: Data Transfer on Dedicated Bearer with non-gbr service and UM Mode. 147 Figure 91: Data Transfer on Dedicated Bearer with GBR Service and AM Mode... 149 Figure 92: Data Transfer on Dedicated Bearer with GBR Service and UM Mode... 151 Figure 93: Successful X2 HO with single bearer... 154 Figure 94: Successful HO with single E-RAB via X2 with Ciphering... 156 Figure 95: Successful X2 HO with Multiple E-RABs... 159 Figure 96: Partially Successful HO via X2 interface with Multiple E-RABs... 161 Figure 97: Unsuccessful X2 HO Due to EPC Failure... 163 Figure 98: Successful S1 HO with Single E-RAB... 165 Figure 99: Successful S1 HO with Multiple E-RABs... 167 Figure 100: Partially Successful S1 HO with Multiple E-RABs... 170 Figure 101: Unsuccessful S1 HO due to fail on MME-Target enodeb connectivity... 172 Figure 102: Unsuccessful S1 HO due to non common Ciphering algorithm... 174 Figure 103: Unsuccessful S1 based HO due to no resources available at target enodeb... 176 Figure 104: Successful LTE to UTRAN HO for single E-RAB (Preparation Phase)... 178 Figure 105: Successful LTE to UTRAN HO for single E-RAB (Execution Phase)... 179 Figure 106: Successful LTE to UTRAN HO for Multiple E-RABs (Preparation Phase)... 181 Figure 107: Successful LTE to UTRAN HO with Multiple E-RABs (Execution Phase)... 182 Figure 108: LTE to UTRAN HO Failure due to connectivity issues... 183 Figure 109: LTE to UTRAN HO failure due to not resources at NodeB... 185 Figure 110: LTE to UTRAN CS-Fallback: MO call, UE in Idle Mode... 188 Figure 111: LTE to UTRAN CS-Fallback: MT Call, UE in Idle Mode (Preparation Phase)... 191 Figure 112: LTE to UTRAN CS-Fallback (Execution Phase with PS HO supported).. 192 Figure 113: LTE to UTRAN CS-Fallback (Execution Phase without PS HO Supported)... 193 Figure 114: LTE to UTRAN CS-Fallback, MO Call, UE in Active Mode... 196 Figure 115: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Preparation Phase)... 199 Figure 116: LTE to UTRAN CS-Fallback, MT Call, UE in Active Mode (Execution Phase) without PS HO Support... 200 Figure 117: LTE to UTRAN SRVCC, Inter RAT HO for VoIP Call... 203 Figure 118: LTE to UTRAN SRVCC, Inter RAT HO for Data Transfer with VoIP Call... 205

Figure 119: Successful UTRAN to LTE Inter RAT HO for a single RAB (Preparation Phase)... 207 Figure 120: Successful UTRAN to LTE Inter RAT HO for a single RAB (Execution Phase)... 208 Figure 121: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Preparation Phase)... 210 Figure 122: Successful UTRAN to LTE Inter RAT HO for Multiple RABs (Execution Phase)... 211 Figure 123: UTRAN to LTE Inter RAT HO failure due to no resources at enodeb... 213

1 Scope This document defines a proposal for the test suite to be used for S1 Interface Conformance testing. The goal is ensuring a graceful integration and interoperability between enodeb-mme and enodeb-sgw from different vendors. 2 References [1] 3GPP TS 36.413 Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) [2] 3GPP TS 29.281 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 BC BSC BM-SC BSS BTS CC CDMA CSG CN CS CSFB DL DRX ECGI E-DCH E-RAB enb EP EPC EPS E-UTRAN GBR GERAN GGSN GPRS GSM GTP GTP-U GUMMEI GUTI GW HeNB Access Stratum Broadcast Base Station Controller Broadcast-Multicast Service Centre Base Station Sub-system Base Transceiver Station Call Control Code Division Multiple Access Closed Subscriber Group Core Network Circuit Switched CS Fallback Downlink Discontinuous Reception E-UTRAN Cell Global Identifier Enhanced Dedicated Channels E-UTRAN Radio Access Bearer E-UTRAN NodeB Elementary Procedure Evolved Packet Core Evolved Packet System Evolved UTRAN Guaranteed Bit Rate GSM/EDGE Radio Access Network Gateway GPRS Support Node General Packet Radio Service Global System for Mobile communications GPRS Tunnelling Protocol GPRS Tunnelling Protocol-User plane Globally Unique MME Identifier Globally Unique Temporary UE Identity Gateway Home E-UTRAN NodeB

HFN HRPD HLR HSDPA HSS HSUPA HO ID IE IETF IMSI IOT IP LAI LTE MBMS MM MME MMI MO MOC MOCN MS MSC MT MTC NAS NNSF NRT O&M PDN PDCP PDP PDU P-GW PLMN PS PSTN Hyper Frame Number High Rate Packet Data Home Location Register High Speed Downlink Packet Access Home Subscriber Server High Speed Uplink Packet Access Handover Identifier Information Element Internet Engineering Task Force International Mobile Subscriber Identity Interoperability Test Internet Protocol Location Area Identifier Long Term Evolution Multimedia Broadcast Multicast Service Mobility Management Mobility Management Entity Man Machine Interface Mobile Originated Mobile Originated Call Multi Operator Core Network Mobile Station Mobile services Switching Center Mobile Terminated Mobile Terminated Call Non Access Stratum NAS Node Selection Function Non-Real Time Operation and Maintenance Packet Data Network Packet Data Convergence Protocol Packet Data Protocol Protocol Data Unit PDN Gateway Public Land Mobile Network Packet Switched Public Switched Telephone Network

PTM P-TMSI PTP QoS RAB RAC RAI RFCI RIM RLC RNC RRC RT SAP SAPI SCTP SGSN S-GW SMS SN SRVCC S-TMSI TAI TCP TE TEID TFT TI TMSI UDP UE UE-AMBR UL UMTS UP USIM UTRAN VLR Point To multipoint Packet TMSI Point To Point Quality of Service Radio Access Bearer Routing Area Code Routing Area Identifier RAB subflow Combination Indicator RAN Information Management Radio Link Control Radio Network Controller Radio Resource Control Real Time Service Access Point Service Access Point Identifier Stream Control Transmission Protocol Serving GPRS Support Node Serving Gateway Short Message Service Sequence Number Single Radio Voice Call Continuity S-Temporary Mobile Subscriber Identity Tracking Area Identity Transmission Control Protocol Terminal Equipment Tunnel Endpoint Identifier Traffic Flow Template Transaction Identifier Temporary Mobile Subscriber Identity User Datagram Protocol User Equipment UE-Aggregate Maximum Bit Rate Uplink Universal Mobile telecommunication System User Plane Universal Subscriber Identity Module UMTS Terrestrial Radio Access Network Visitor Location Register

4 Overview The purpose of this document is defining a test suite to guarantee the successful interoperability of the S1 interface between the EPC and the enb/e-utran. The E-UTRAN is connected to the MME (Mobility Management Entity) by means of the S1-MME for control-plane functionality and to the Serving Gateway (S-GW) by means of the S1-U for bearer-plane functionality The following main areas are covered in testing S1 interface: Protocol Transport Network Layer o SCTP o Multi-Homing Context Management Procedures Handover Signalling Paging NAS Transport Management Procedures UE Capability Info Indication Trace Procedures User Plane GTP-U Functional Oriented Test Mobility Management Session Management General Failure and Recovery Tests Data Transfer Paging Downlink Scheduling Figure 1 shows the S1-MME interface protocol stack. S1-AP SCTP IP L2 L1 S1-AP SCTP IP L2 L1 HeNB S1-MME MME Figure 1: S1 Interface Protocol Stack towards MME

Figure 2 shows the S1-U interface protocol stack. GTP-U UDP IP L2 L1 HeNB S1-U GTP-U UDP IP L2 L1 S-GW Figure 2: S1 Interface Protocol Stack towards S-GW For all the diagrams and call flows included into this test plan, dotted lines imply that the procedure is optional as per the applicable 3GPP specifications.

5 Test Configuration This section lists the test equipment necessary to perform the test cases detailed in this document, together with the network configurations that will be required to execute all the test cases included in this document. 5.1 Network & Interface Configuration (Overview) Figure 3 depicts the Network Configuration for regular test cases. HSS S1-MME MME S6a PCRF UE E-UTRAN S1-U S10 S11 Serving Gateway S5 Gx PDN Gateway SGi Rx Operator's IP Services (e.g. IMS, PSS etc.) TE Figure 3: Network Configuration for regular test cases Figure 4 depicts the Network Configuration for Intra-RAT HO test cases.

HSS S1-MME MME S6a PCRF UE E-UTRAN S1-MME S1-U S10 S11 Serving Gateway S5 Gx PDN Gateway SGi Rx Operator's IP Services (e.g. IMS, PSS etc.) TE E-UTRAN S1-U Figure 4: Network Configuration for intra-rat HO Test Cases Figure 5 depicts the Network Configuration for Inter-RAT HO test cases. IuCS MSS IuPS Gs D UE TE UTRAN SGSN S3 S1-MME MME S11 S10 E-UTRAN S1-U HSS S6a S4 Serving Gateway S12 S5 Gx PDN Gateway PCRF SGi Rx Operator's IP Services (e.g. IMS, PSS etc.) Figure 5: Network Configuration for Inter-RAT HO Test Cases

5.2 Network Elements Software Version Network Element Software Version enodeb MME SGW PGW HSS PCRF HLR (3G) SGSN (3G) 5.3 Test Equipment The following test equipment will be required in order to carry out the tests defined in this document and verify the results: Item/Tool Analyzer Simulator Mobiles Others Name/Model

6 Detailed Test Cases 6.1 Management, Tracing and Location Report Test Cases 6.1.1 Management Procedures over SCTP 6.1.1.1 S1 Setup between MME and enodeb in a single PLMN configuration 6.1.1.1.1 Successful S1 Setup Test Name: Successful establishment of SCTP association and Path Heartbeat in a single PLMN Configuration References: TS 36.413, Section 8.7.3.2 Test Objective: Verify the successful establishment of the SCTP and S1 connection between enodeb and MME as well as the periodic path heartbeat to monitor the link Pre-Test Conditions: MME is configured with the SCTP and S1 parameters (1 PLMN Id) enodeb is configured with the SCTP and S1 parameters (1 same PLMN Id) Both of the nodes shall be configured with the SCTP path heartbeat timer Verify IP connectivity between the two nodes Test Procedure: Power on the MME and enodeb Trigger enodeb to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by enodeb by sending a S1 setup Request message, including the TAC and the configured PLMN Identity included into the Broadcast PLMNs IE, MME responds with the S1 setup response message acknowledging the connectivity and including the same PLMN Identity S1 connectivity is successfully established between enodeb and MME. SCTP heartbeats messages are exchanged successfully between both of the nodes according to the timers configured.

enb MME S1 SETUP REQUEST S1 SETUP RESPONSE Figure 6: Setup Procedure Successful Operation

6.1.1.1.2 Unsuccessful S1 Setup Test Name: Unsuccessful establishment of SCTP association between enodeb and MME in a single PLMN Id Configuration References: TS 36.413, Section 8.7.3.3 Test Objective: Verify the the graceful failure of S1 setup establishment between enodeb and MME Pre-Test Conditions: MME is configured with S1 parameters different than the one configures on enodeb (different TAC or different PLMN Id) enodeb is configured with S1 parameters different than the one configured on MME (different TAC or different PLMN Id) Verify IP connectivity between the two nodes Test Procedure: Power on the MME and enodeb Trigger enodeb to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by enodeb by sending a S1 setup Request message, including the TAC and the configured PLMN Identity included into the Broadcast PLMNs IE, MME responds with the S1 setup failure including the reason of the unsuccessful establishment (e.g unknown TAC, unknown PLMN Id, etc) No resource is hold by any network element after the unsuccessful S1 establishment enb MME S1 SETUP REQUEST S1 SETUP FAILURE Figure 7: S1 Setup Procedure - Unsuccessful Operation

6.1.1.2 S1 Setup between MME and enodeb in a multiple PLMN configuration (MOCN configuration) 6.1.1.2.1 Successful S1 Setup Test Name: Successful establishment of SCTP association and Path Heartbeat in a multiple PLMN Configuration References: TS 36.413, Section 8.7.3.2 Test Objective: Verify the successful establishment of the SCTP and S1 connection between enodeb and MME as well as the periodic path heartbeat to monitor the link in a MOCN configuration Pre-Test Conditions: MME is configured with the SCTP and S1 parameters enodeb is configured with the SCTP and S1 parameters Both of the nodes shall be configured with the SCTP path heartbeat timer Verify IP connectivity between the two nodes Test Procedure: Power on the MME and enodeb Trigger enodeb to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by enodeb by sending a S1 setup Request message, including the TAC and the configured PLMN Identitier included into the Broadcast PLMNs IE, MME responds with the S1 setup response message acknowledging the connectivity and including the same PLMN Identitier S1 connectivity is successfully established between enodeb and MME. SCTP heartbeats messages are exchanged successfully between both of the nodes according to the timers configured. enb MME S1 SETUP REQUEST S1 SETUP RESPONSE Figure 8: S1 Setup Procedure: Successful Operation

6.1.1.2.2 Unsuccessful S1 Setup Test Name: Unsuccessful establishment of SCTP association between enodeb and MME in a multiple PLMN Id Configuration References: TS 36.413, Section 8.7.3.3 Test Objective: Verify the the graceful failure of S1 setup establishment between enodeb and MME Pre-Test Conditions: MME is configured with S1 parameters different than the one configures on enodeb (different TAC Ids) enodeb is configured with S1 parameters different than the one configured on MME (different TAC Ids) Verify IP connectivity between the two nodes Test Procedure: Power on the MME and enodeb Trigger enodeb to initiate the S1 Setup Expected Results: Verify that: SCTP connection is initiated by enodeb by sending a S1 setup Request message, including the TAC and the configured PLMN Identitier included into the Broadcast PLMNs IE, MME responds with the S1 setup failure including the reason of the unsuccessful establishment (e.g unknown TAC, unknown PLMN Id, etc) No resource is hold by any network element after the unsuccessful S1 establishment enb MME S1 SETUP REQUEST S1 SETUP FAILURE Figure 9: S1 Setup Procedure: Unsuccessful Operation

6.1.1.3 S1 Configuration Update (MME Initiated) 6.1.1.3.1 Successful S1 MME Configuration Update Test Name: Successful MME Configuration Update References: TS 36.413, Section 8.7.5.2 Test Objective: Validate the successful application level configuration data update when initiated by MME Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Verify IP connectivity between the two nodes Test Procedure: Trigger MME to initiate the S1 Setup Update by changing the configuration (eg change the name of MME or changing the MME relative capacity) Expected Results: Verify that: Validate that MME sends a S1-AP:MME Configuration Update including the new parameters (e.g new MME name, or new MME relative capacity) Validate that enodeb is acknowledging the update by sending back a S1-AP MME Configuration Update Acknowledge to MME enb MME MME CONFIGURATION UPDATE MME CONFIGURATION UPDATE ACKNOWLEDGE Figure 10: MME Configuration Update Procedure: Successful Operation

6.1.1.3.2 Unsuccessful S1 MME Configuration Update Test Name: Unsuccessful MME Configuration Update References: TS 36.413, Section 8.7.5.3 Test Objective: Validate the graceful unsuccessful application level configuration data update when initiated by MME Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Make sure enodeb is not configured to accept the PLMN-ID that MME will send during the S1 MME Configuration Update. Verify IP connectivity between the two nodes Test Procedure: Trigger MME to initiate the S1 Setup Update by changing the configuration including a parameter not acceptable by enodeb (eg unknown PLMN in enodeb) Expected Results: Verify that: Validate that MME sends a S1-AP:MME Configuration Update including the new parameters (e.g new PLMN-ID) Validate that enodeb is sending back a S1-APL MME configuration Update Failure including the reason of the unsuccessful S1 update. enb MME MME CONFIGURATION UPDATE MME CONFIGURATION UPDATE FAILURE Figure 11: MME Configuration Update: Unsuccessful Operation

6.1.1.4 S1 Configuration Update (enodeb Initiated) 6.1.1.4.1 Successful S1 Configuration Update (enodeb Initiated) Test Name: Successful enodeb Configuration Update References: TS 36.413, Section 8.7.4.2 Test Objective: Validate the successful application level configuration data update between enodeb and MME when is initiated by enodeb Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Verify IP connectivity between the two nodes Test Procedure: Trigger enodeb to initiate the S1 Setup Update by changing the configuration (eg supported TAC change in enodeb) Expected Results: Verify that: Validate that enodeb sends a S1-AP:EnodeB Configuration Update including the new parameters (e.g new TAC supported) Validate that MME is acknowledging the update by sending back a S1-AP enodeb Configuration Update Acknowledge to enodeb Validate that new S1 parameters have been successfully negotiated at both of the nodes. enb MME ENB CONFIGURATION UPDATE ENB CONFIGURATION UPDATE ACKNOWLEDGE Figure 12: ENB Configuration Update Procedure: Successful Operation

6.1.1.4.2 Unsuccessful S1 Configuration Update (enodeb Initiated) Test Name: Unsuccessful enodeb Configuration Update References: TS 36.413, Section 8.7.4.3 Test Objective: Validate the graceful unsuccessful application level configuration data update between enodeb and MME when is initiated by enodeb Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Verify IP connectivity between the two nodes Test Procedure: Trigger enodeb to initiate the S1 Setup Update by changing the configuration to one which MME can not accept (e.g TAC change to unknown TAC in MME) Expected Results: Verify that: Validate that enodeb sends a S1-AP:EnodeB Configuration Update including the new parameters (e.g new TAC supported) Validate that MME is sending back a S1-SP enodeb configuration update failure including the reason of the unsuccessful S1 update. enb MME ENB CONFIGURATION UPDATE ENB CONFIGURATION UPDATE FAILURE Figure 13: ENB Configuration Update Procedure: Unsuccessful Operation

6.1.1.5 S1 Reset Procedures 6.1.1.5.1 S1 Reset initiated by enodeb Test Name: S1 Reset initiated by enodeb References: TS 36.413, Section 8.7.1.2.2 Test Objective: Validate the successful reset initiated by enodeb and the consequent initialization of the MME Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Verify IP connectivity between the two nodes Test Procedure: Trigger enodeb to send a S1 Reset to MME Expected Results: Verify that: Validate that enodeb sends a S1-AP Reset to MME Validate that MME sends back a S1-AP Reset Acknowledge message Validate that MME is releasing all allocated resources on S1 related to the UE and removing the S1AP ID for all the UE associations. enb MME RESET RESET ACKNOWLEDGE Figure 14: Reset Procedure Initiated From the E-UTRAN Successful Operation

6.1.1.5.2 S1 Reset initiated by MME Test Name: S1 Reset initiated by MME References: TS 36.413, Section 8.7.1.2.1 Test Objective: Validate the successful reset initiated by MME and the consequent initialization of the enodeb Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME Verify IP connectivity between the two nodes Test Procedure: Trigger MME to send a S1 Reset to enodeb Expected Results: Verify that: Validate that MME sends a S1-AP Reset to enodeb Validate that enodeb sends back a S1-AP Reset Acknowledge message Validate that enodeb is releasing all allocated resources on S1 related to the UE and removing the S1AP ID for all the UE associations. enb MME RESET RESET ACKNOWLEDGE Figure 15: Reset Procedure Initiated From the MME Successful Operation

6.1.1.6 S1 Recovery after nodes failure 6.1.1.6.1 S1 Recovery after enodeb restart Test Name: S1 recovery after enodeb restart References: TS 36.413, Section 8.7.1.2.2 Test Objective: Validate the S1 recovers successfully from the unexpected restart of the enodeb Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Trigger the enodeb to restart as in case of a failure (e.g power cycling) If no failure can be triggered, the pre-condition can be to execute a normal restart as in test case 6.1.1.5.1). Test Procedure: Initiated the system restart from enodeb (preferably by emulating is unexpected, failure e.g power cycle-). Expected Results: Verify that: If the failure does allow the enodeb to send the S1 Reset: o Verify that enodeb sends S1-AP: S1 RESET to MME o Verify that MME acknowledges by sending back a S1-AP: S1 RESET acknowledgement to enodeb o Validate that all the resources have been released after the restart Validate that the S1 recovers from the restart, enodeb is sending a S1-AP S1 SETUP REQUEST Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP RESPONSE Validate that UE can reestablish the context and resume the data transfer successfully

enb MME RESET RESET ACKNOWLEDGE Figure 16: Reset Procedure Initiated From the E-UTRAN Successful Operation

6.1.1.6.2 S1 Recovery after MME restart Test Name: S1 recovery after MME restart References: TS 36.413, Section 8.7.1.2.1 Test Objective: Validate the S1 recovers successfully from the unexpected restart of the MME Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Trigger the MME to restart as in case of a failure (e.g power cycling) If no failure can be triggered, the pre-condition can be to execute a normal restart as in test case 6.1.1.5.2). Test Procedure: Initiated the system restart from MME (preferably by emulating is unexpected, failure e.g power cycle-). Expected Results: Verify that: If the failure does allow the MME to send the S1 Reset o Verify that MME sends S1-AP: S1 RESET to enodeb o Verify that enodeb acknowledges by sending back a S1-AP: S1 RESET acknowledgement to MME o Validate that all the resources have been released after the restart Validate that the S1 recovers from the restart, enodeb is sending a S1-AP S1 SETUP REQUEST Validate that MME is successfully acknowledging by sending S1-AP S1 SETUP RESPONSE Validate that UE can reestablish the context and resume the data transfer successfully

enb MME RESET RESET ACKNOWLEDGE Figure 17: Reset Procedure Initiated From the MME Successful Operation 6.1.1.6.3 S1 Recovery after SGW restart Test Name: S1 recovery after S-GW restart while data transfer is ongoing References: TS 36.413, Section 8.3.3.2 Test Objective: Validate the S1-U recovers successfully from the unexpected restart of the S-GW Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Initiated the system restart from S-GW (emulate is unexpected, failure) Expected Results: Verify that: Verify that, when S-GW restarts, GTP-U may send a notification to the higher layer and O&M entities Verify that, upon S-GW reinitialization, the data can be resumed successfully. If no same Tunnel Endpoints are honored at both of directions, GTP-U error indication will be sent to the other end to indicate about the Tunnel ID mismatch. This procedure may involve a UE Context release from MME (S-GW can notify MME via S11) and UE context setup to re-activate the UE context successfully. In Figure 18, UE context successfully established is not an actual procedure within the 3GPP S1-AP specs. The message UE Context is successfully established is meant to indicate that there are a collection of procedures executed in order to resume UE operation.

enb MME UE CONTEXT RELEASE COMMAND UE CONTEXT RELEASE COMPLETE UE CONTEXT is successfully established Figure 18: UE Context Release Procedure Successful Operation

6.1.1.6.4 S1 Recovery from S1 failure due to physical connections lost Test Name: S1 recovery from S1 failure due to transmission network failure (physical connections lost) References: TS 36.413, Section 8.7.3.2 Test Objective: Validate the S1 recovers successfully from a physical connection failure Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Cause a failure on all the physical links carrying S1, for example by disconnecting the cable or shutting down the interface Reconnect the cable before enodeb and MME triggers RESET failure (if disconnection of the cable, enodeb and MME will not trigger RESET) Expected Results: Verify that: Message flow may depend on the vendor implementation Expected behavior is enodeb to start a S1 SETUP REQUEST to MME, MME to acknowledge and UE context activation is being successfully re-established after the physical link recovery UE can resume the data transmission and no resource from previous call is hold by any network element

enb MME S1 SETUP REQUEST S1 SETUP RESPONSE Figure 19: Setup Procedure Successful Operation

6.1.2 Trace and Location Reporting Procedures 6.1.2.1 Trace Procedures 6.1.2.1.1 Trace Start 6.1.2.1.1.1 Trace Start supporting S1 interface Test Name: MME requests the enodeb to start a trace supporting S1 interface and minimum depth References: TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2 Test Objective: Note: Validate that MME is able to request the enodeb to start a trace session that supports S1 interface and minimum depth 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 enb MME TRACE START

Figure 20: Trace Start Procedure enodeb MME CELL TRAFFIC TRACE Figure 21: Cell Traffic Trace Procedure - Successful Operation enb MME TRACE FAILURE INDICATION Figure 22: Trace Failure Indication Procedure

6.1.2.1.1.2 Trace Start supporting X2 interface Test Name: MME requests the enodeb to start a trace supporting X2 interface and minimum depth References: TS 36.413, Sections 8.10.1.2, 8.10.2.2, & 8.10.4.2 Test Objective: Note: Validate that MME is able to request the enodeb to start a trace session that supports X2 interface and minimum depth 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 enb MME TRACE START Figure 23: Trace Start Procedure

enodeb MME CELL TRAFFIC TRACE Figure 24: Cell Traffic Trace Procedure - Successful Operation enb MME TRACE FAILURE INDICATION Figure 25: Trace Failure Indication Procedure

6.1.2.1.2 Deactivate Trace Test Name: MME requests the enodeb to stop the trace session References: TS 36.413, Sections 8.10.3.2 & 8.10.2.2 Test Objective: Note: Validate that MME is able to request the enodeb to stop the trace session 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 enb MME DEACTIVATE TRACE Figure 26: Deactivate Trace

enb MME TRACE FAILURE INDICATION Figure 27: Trace Failure Indication Procedure

6.1.2.2 Location Reporting Procedures 6.1.2.2.1 Successful location reporting for a direct report of the UE location Test Name: Location Reporting Control sent to Request a direct report for a UE location References: TS 36.413, Sections 8.11.1.2 & 8.11.2.2 Test Objective: Note: Validate that MME is able to request the enodeb to report where the UE is currently located 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) enb MME LOCATION REPORTING CONTROL Figure 28: Location Reporting Control Procedure - Successful Operation

enb MME LOCATION REPORT FAILURE INDICATION Figure 29: Location Report Failure Indication Procedure

6.1.2.2.2 Successful location reporting for serving cell change Test Name: Successful location reporting for serving cell change References: TS 36.413, Sections 8.11.3.2, 8.11.1.2, & 8.11.2.2 Test Objective: Note: 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 This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Verify IP connectivity between the two nodes Test Procedure: Initiate the location reporting for a serving cell change for the UE Move the UE to another cell Expected Results: Verify that: MME sends a S1-AP: Location Reporting Control by including a Request Type IE with Event IE= Change of Service Cell and Report Area IE= ECGI Verify that when the UE moves to a new cell the enodeb is sending a S1:AP Location Report message with a E-UTRAN CGI IE indicating the cell where the UE is located. The Location Report message also includes a TAI IE indicating the tracing area where the UE is located and a Request Type IE including Event IE= Change of Service cell And Report Area IE= ECGI Remark: If the location report control failed, the enodeb shall send to MME a S1-AP Location Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a ongoing HO) enb MME LOCATION REPORTING CONTROL Figure 30: Location Reporting Control Procedure - Successful Operation

enb MME LOCATION REPORT Figure 31: Location Report Procedure - Successful Operation enb MME LOCATION REPORT FAILURE INDICATION Figure 32: Location Report Failure Indication

6.1.2.2.3 Successful cancellation of location reporting for serving cell change Test Name: Successful cancellation of location reporting for serving cell change References: TS 36.413, Sections 8.11.1.2 & 8.11.2.2 Test Objective: Note: 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 This is an optional requirement (not mandatory feature as per applicable specs) Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is at least one UE attached with active context and data transfer is ongoing Currently the location reporting is active for a serving cell change. Verify IP connectivity between the two nodes Test Procedure: Initiate the cancel of the location reporting for serving cell change for the UE Move the UE to another cell Expected Results: Verify that: During the cancellation of the location reporting, the MME sends a S1-AP: Location Reporting Control by including a Request Type IE with Event IE= Stop Change of Service Cell and Report Area IE= ECGI Verify that when the UE moves to a new cell the enodeb not sending any S1-AP Location Report message. Remark: If the location report control failed, the enodeb shall send to MME a S1-AP Location Report Failure Indication with a Cause IE indicating the reason for the failure (e.g due to a ongoing HO) enb MME LOCATION REPORTING CONTROL Figure 33: Location Reporting Control Procedure - Successful Operation

enb MME LOCATION REPORT FAILURE INDICATION Figure 34: Location Report Failure Indication Procedure

6.2 Functional Test Cases 6.2.1 Attach/Detach 6.2.1.1 Successful EPS Attach with UE unknown in MME and no Ciphering Test Name: Successful EPS Attach with the UE unknown in MME and no Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the ciphering is disabled Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached and no context exists for the UE Ciphering is disabled GUTI is unknown in the MME Test Procedure: Trigger UE attach Send Data in both of directions

Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE= IMSI enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0 for Ciphering enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed

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

6.2.1.2 Successful EPS Attach with UE unknown in MME and Ciphering Test Name: Successful EPS Attach with the UE unknown in MME and Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the ciphering is enabled Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached and no context exists for the UE Ciphering is enabled GUTI is unknown in the MME Test Procedure: Trigger UE attach Send Data in both of directions

Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE= IMSI enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA1 or EEA2 for Ciphering as per the configuration enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with Ciphering being performed

Figure 36: Successful EPS Attach with MME unknown in MME and Ciphering

6.2.1.3 Successful EPS Attach procedure with UE known in MME and no Ciphering Test Name: Successful EPS Attach with the UE known in MME and no Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is known to the MME and the ciphering is disabled Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached and no context exists for the UE Ciphering is disabled GUTI is known in the MME Test Procedure: Trigger UE attach Send Data in both of directions

Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0 for Ciphering enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed Figure 37: Successful EPS Attach procedure with UE known in MME and No Ciphering

6.2.1.4 Successful EPS Attach procedure with UE known in MME with Ciphering Test Name: Successful EPS Attach with the UE known in MME and Ciphering References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is known to the MME and the ciphering is enabled Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached and no context exists for the UE Ciphering is enabled GUTI is known in the MME Test Procedure: Trigger UE attach Send Data in both of directions

Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA1 or EEA2 for Ciphering as per the configuration enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed Figure 38: Successful EPS Attach with UE known in MME and Ciphering

6.2.1.5 Successful EPS Attach procedure with IMSI Test Name: Successful EPS Attach with IMSI References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: Validate the successful attach when UE is unknown to the MME and the UE has no GUTI Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached UE has no GUTI Test Procedure: Trigger UE attach Send Data in both of directions Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to IMSI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0, EEA1 or EEA2 for Ciphering as per the configuration enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Default EPS Bearer Context Accept message. Validate that the Data can be transferred on both of directions with no Ciphering being performed

Figure 39: Successful EPS Attach with IMSI

6.2.1.6 Unsuccessful EPS Attach due to IMSI unknown on HSS Test Name: Unsuccessful EPS Attach due to IMSI unknown on HSS References: 3GPP TS 23.401, Section 5.3.2.1 Test Objective: 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 Validate the graceful failed EPS Attach when IMSI is unknown on HSS Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is not attached and no GUTI is known on MME IMSI is unknown on HSS Test Procedure: Trigger UE attach Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE= IMSI enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP: Downlink NAS Transport encapsulating an Attach Reject with the corresponding Cause IE included. No resource is hold by any network element

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

6.2.1.7 Successful EPS Detach initiated by UE Test Name: Successful EPS Detach UE initiated References: 3GPP TS 23.401, Section 5.3.8.2.1 Test Objective: 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 Validate the successful detach procedure when is initiated by the UE Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is attached Test Procedure: Trigger UE detach Expected Results: Verify that: enodeb sends MME a S1-AP: Uplink NAS Transport encapsulating a Detach Request including the GUTI inside the EPS mobile Identity IE MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Detach Accept MME sends a S1-AP Downlink NAS Transport encapsulating a S1 UE Context Release Command enodeb acknowledges it back by sending a S1-AP Uplink NAS Transport encapsulating a S1 UE Context Release complete. There is no resource hold by any network element after the detach is completed. Figure 41: Successful EPS detach initiated by UE

6.2.1.8 Successful EPS Detach initiated by UE due to switch off Test Name: Successful EPS Detach UE initiated References: 3GPP TS 23.401, Section 5.3.8.2.1 Test Objective: 3GPP TS 36.413, Section 8.6.2.3, 8.3.3.2 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 Test Objective: 3GPP TS 24.301, 5.5.2.3.1 3GPP TS 36.413, Section 8.3.3.2 Validate the successful detach procedure when is initiated by the MME Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW UE is attached and in active state Test Procedure: Trigger UE detach from the MME Expected Results: Verify that: MME sends to enodeb a S1-AP: Uplink NAS Transport encapsulating a Detach Request enodeb sends to MME a S1-AP Downlink NAS Transport encapsulating a NAS Detach Accept MME sends to enodeb a S1-AP Downlink NAS Transport encapsulating a S1 UE Context Release Command enodeb acknowledges it back by sending a S1-AP Uplink NAS Transport encapsulating a S1 UE Context Release complete. There is no resource held by any network element after the detach is completed. Remark 1: If MME includes a Detach Type requesting UE to make a new attach inside the initial Detach Request, the UE should start a new attach as soon as the current context is completed released.

Figure 43: Successful EPS Detach initiated by MME

6.2.2 E-RAB Protocol Procedures 6.2.2.1 E-RAB Setup 6.2.2.1.1 Successful E-RAB establishment Test Name: Successful Establishment of single E-RAB References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish an E-RAB for a UE Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is no existing E-RAB on UE Test Procedure: Initiate a procedure that requires E-RAB establishment (e.g service request) Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) Validate that enodeb is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RAB, including the same E-RAB ID IE originally included into the request. Validate that the UE can send data by using the established E-RAB Remarks 1: If the E-RAB is not successfully established (e.g due to no resources available on enodeb) the enodeb will answer with a S1-AP: E-RAB SETUP Response including a E-RAB Failed to Setup List IE containing the ID for the E-RAB that was unable to be established. Figure 44: Successful E-RAB establishment for single E-RAB

6.2.2.1.2 Successful E-RAB establishment UE Aggregate Maximum Bit Rate IE is included Test Name: Successful Establishment of single E-RAB when UE Aggregate Maximum Bit Rate IE is contained References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish an E-RAB for a UE when UE Aggregate Maximum Bit Rate IE is included Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is an existing E-RAB using all of the Aggregate Maximum Bit Rate for the UE as per UE Context (default bearer) Test Procedure: Configure MME to include the UE Aggregate Maixmum Bit Rate IE during the establishment of the new E-RAB Initiate a procedure that requires an additional E-RAB establishment (e.g creation of a dedicated bearer). Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing one E-RAB to be setup (E-RAB ID IE) and the UE Aggregate Maximum Bit Rate IE Validate that enodeb is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RAB, including the same E-RAB ID IE originally included into the request. Validate that the Aggregate Maximum Bit Rate is successfully changed at both of the sides to support the new E-RAB. Validate that the Data Radio Bearer is established for the requested E-RAB with the appropriated resources based on the E-RAB Level QoS Parameter IE Validate that the UE can send data over all of the established E-RABs. Remarks 1: If the E-RAB is desired to be pre-empted, the Priority Level shall be set to be low priority and the Pre-emption Vulnerability has to be Pre-emptable. The no pre-empting E-RAB will then present the Priority Level set to high and the Pre-emption Capability has to be may trigger pre-emption. In this case, if no enough resources are available the high priority E-RAB will be established and the pre-emptable E-RAB will be released out.

Figure 45: Successful E-RAB establishment for single E-RAB with UE Maximum Aggregate IE included

6.2.2.1.3 Successful E-RAB establishment for multiple E-RABs Test Name: Successful establishment of Multiple E-RABs References: 3GPP TS 36.413, Section 8.2.1.2 Test Objective: Validate the possibility to establish multiple E-RAB for a UE Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is no existing E-RAB on UE Test Procedure: Initiate a procedure that requires multiple E-RAB establishment (e.g service request) Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Setup Request including the E-RAB to be Setup List IE containing multiple E-RAB to be setup (multiple E-RAB ID IEs) Validate that enodeb is acknowledging the successful establishment by sending a S1-AP E-RAB Setup Response, including the E-RAB Setup Items IE for the successfully established E-RABs, including the same E-RAB ID IEs originally included into the request for each successfully established E-RAB Validate that the UE can send data by using ALL the successfully established 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 Figure 46: Successful E-RAB establishment for Multiple E-RABs

6.2.2.2 E-RAB Modify 6.2.2.2.1 Successful E-RAB modification of single E-RAB Test Name: Successful E-RAB modification of single E-RAB References: 3GPP TS 36.413, Section 8.2.2.2 Test Objective: Validate the possibility to modify an existing E-RAB Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There is an existing E-RAB on UE Test Procedure: Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ by including new TFT Filters/QoS Parameters) Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB to be Modified List IE containing one E-RAB to Be Modified Item (with the corresponding E-RAB ID IE) Validate that enodeb is acknowledging the modification by sending back a S1-AP E-RAB Modify Response message with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs (with same E-RAB ID IE). Validate that the new parameters (QoS and/or TFT Filters) are properly updated at both of the sides and that the data is transferred accordingly. Remarks 1: The MME can include the UE Aggregate Maximum Bit Rate IE into the S1-AP: E-RAB Modify Request. In that case, the data radio bearer shall be modified for the requested E-RAB with the appropriate resources based on the E-RAB level QoS Parameter IE, reflecting the change in the aggregate maximum bit rate Remarks 2: The MME can attempt to modify the existing E-RAB while pre-empting another E-RAB on the UE. For this purpose, the MME will include into the S1-AP: E-RAB Modify Request message the E-RAB to be Modified List IE containing one E-RAB to Be Modified Item IE with the corresponding E-RAB ID, the E-RAB Priority Level set to 1 and the Pre-emption Capability set to may trigger pre-emption. In this case, if no enough resources are available on enodeb the others E-RAB will be released by using a S1-AP E-RAB Release procedure for the low priority E-RABs. Remarks 3: If the E-RAB is not successfully modified the enodeb will send a S1-AP E-RAB Modify Response including a E-RAB Failed to Modify List IE with the same ID of the E-RAB included into the request. In this case, the former QoS/TFT parameters of the bearer will be honored by all the nodes.

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

6.2.2.2.2 Successful E-RAB modification for multiple E-RABs Test Name: Successful E-RAB modification of multiple E-RABs References: 3GPP TS 36.413, Section 8.2.2.2 Test Objective: Validate the possibility to modify existing E-RABs Pre-Test Conditions: Initial S1 setup has been successfully established between enodeb and MME There are multiple E-RABs existing on UE Test Procedure: Initiate a procedure that requires E-RAB modification (e.g HSS sends an ISDR to MME by including new QoS Parameters, or PGW sends an EGP_UPDATE_REQ by including new TFT Filters/QoS Parameters) for multiple E-RABs Expected Results: Verify that: Validate that MME is sending S1-AP E-RAB Modify Request including the E-RAB to be Modified List IE containing all E-RAB to Be Modified Item (with the corresponding E-RAB ID IEs) Validate that enodeb is acknowledging the modification by sending back a S1-AP E-RAB Modify Response message with the same E-RAB Modify List IE containing the same E-RAB Modify Item IEs (with same E-RAB ID IEs). Validate that the new parameters (QoS and/or TFT Filters) are properly updated at both of the sides and that the data is transferred accordingly on all the bearers. Figure 48: Successful E-RAB Modification for multiple E-RABs

6.2.2.2.3 Successful and Unsuccessful E-RAB modification for multiple 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 Test Objective: 3GPP TS 24.301, Section 6.4.2.2 3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3 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 Test Objective: 3GPP TS 24.301, Section 6.4.2.2 3GPP TS 36.413, Section 8.2.1.2, 8.6.2.3 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: References: Test Objective: Successful Dedicated Bearer Activation during attach 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 Validate the successful dedicated bearer activation during UE attach Pre-Test Conditions: UE is not attached Network is configured to trigger a dedicated bearer activation during the UE attach Test Procedure: Trigger UE to attach Expected Results: Verify that: enodeb sends a S1-AP Initial UE message encapsulating a NAS Attach Request to MME MME sends back a S1-AP Initial Context Setup Request including both NAS Attach Accept and NAS Activate Default EPS Bearer Context Request MME sends a S1-AP: E-RAB set request encapsulating a NAS Activate Dedicated EPS Bearer Context Request to enodeb. The NAS message will include the EPS Bearer identity IE of the new dedicated bearer, the EPS QoS IE and the corresponding Traffic Flow Template IE Validate that enodeb sends back a S1-AP: Initial Context Setup Response. Validate that enodeb sends to MME a S1-AP: Uplink NAS Transport encapsulating a NAS Attach Complete and NAS Activate Default EPS Bearer Context Accept message. Validate that enodeb sends to MME a S1-aP: E-RAB Setup Response Validate that enodeb sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Activate Dedicated EPS Bearer Context Accept, cinluding the same EPS Bearer identity and the Procedure transaction identity IE. Validate that both default and dedicated bearers have been established on every node and that the data transmission in DL/UL honors the QoS/TFT Filter rules on that bearer.

Figure 54: Successful Bearer Activation during Attach

6.2.3.2 Bearer Modification 6.2.3.2.1 Bearer Modification initiated by the EPC 6.2.3.2.1.1 PDN GW initiated bearer modification with QoS Update Test Name: PDN GW initiated bearer modification with QoS Update References: 3GPP TS 23.401, 5.4.2.1 Test Objective: 3GPP TS 24.301, Section 6.4.3.1 3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3 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. Figure 55: PGW Initiated Bearer Modification with QoS Update

6.2.3.2.1.2 HSS initiated Subscriber QoS Modification Test Name: HSS initiated bearer modification with QoS Update References: 3GPP TS 23.401, 5.4.2.2 Test Objective: 3GPP TS 24.301, Section 6.4.3.1 3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3 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. Figure 56: HSS initiated Subscriber QoS Modification

6.2.3.2.1.3 Network Initiated Bearer modification without Bearer QoS Update Test Name: Network initiated bearer modification without QoS Update References: 3GPP TS 23.401, 5.4.2.2, 5.4.3 Test Objective: 3GPP TS 24.301, Section 6.4.3.1 3GPP TS 36.413, Section 8.2.2.2, 8.6.2.3 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 Test Objective: 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 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 Test Objective: 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 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

6.2.3.3 Dedicated Bearer deactivation 6.2.3.3.1 PDN GW initiated Dedicated Bearer Deactivation Test Name: PDN GW initiated bearer deactivation References: 3GPP TS 23.401, 5.4.4.1 Test Objective: 3GPP TS 24.301, Section 6.4.4.2 3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3 Validate the successful dedicated bearer deactivation when initiated by PDN GW Pre-Test Conditions: UE is attached There are at least two E-RABs on UE Test Procedure: Initiate bearer deactivation from the PDN GW Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that enodeb is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that enodeb sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the rest of the bearers (e.g default). Figure 60: PGW Initiated Dedicated Bearer Deactivation

6.2.3.3.2 MME initiated Dedicated Bearer Deactivation Test Name: MME initiated bearer deactivation References: 3GPP TS 23.401, 5.4.4.2 Test Objective: 3GPP TS 24.301, Section 6.4.4.2 3GPP TS 36.413, Section 8.2.3.2.1, 8.6.2.3 Validate the successful dedicated bearer deactivation when initiated by MME Pre-Test Conditions: UE is attached There are at least two E-RABs on UE Test Procedure: Initiate bearer deactivation from the MME Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that enodeb is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that enodeb sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the remaining bearers (e.g default).

Figure 61: MME initiated Dedicated Bearer Deactivation

6.2.3.3.3 UE initiated Dedicated Bearer Deactivation Test Name: UE initiated bearer deactivation References: 3GPP TS 23.401, 5.4.5, 5.4.4.2 Test Objective: 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 Validate the successful dedicated bearer deactivation when initiated by UE Pre-Test Conditions: UE is attached There are at least two E-RABs on UE Test Procedure: Initiate bearer deactivation from the UE Expected Results: Verify that: Validate that enodeb is sending a S1-AP Uplink NAS Transport encapsulating a NAS Bearer Resource Modification Request including a ESM Cause IE set to Regular deactivation Validate that MME sends a S1-AP: E-RAB Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that enodeb is sending S1-AP: E-RAB Release Response containing the same E-RAB Release List IE Validate that enodeb sends to MME S1-AP: Uplink NAS Transport encapsulating the NAS Deactivate EPS Bearer Context Accept. Validate that the dedicated bearer has been released on every node and that all the traffic is now being routed through one of the rest of the bearers (e.g default). Figure 62: UE initiated Dedicated Bearer Deactivation

6.2.4 Idle Mode and Context Management Procedures 6.2.4.1 Active to Idle mode Transition (Context Release) 6.2.4.1.1 UE/eNodeB Context Release due to User Inactivity with a single bearer established Test Name: UE/eNodeB Context Release due to User Inactivity with single bearer established References: 3GPP TS 23.401, 5.3.5 Test Objective: 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2 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 Test Objective: 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2 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 Test Name: UE Context Release due to radio connection with UE Lost References: 3GPP TS 23.401, 5.3.5 3GPP TS 36.413, Section 8.3.2.2, 8.3.3.2 Test Objective: Validate the successful UE Context release due to radio connection with UE lost Pre-Test Conditions: UE is attached UE is in active mode and a context exists for the UE on every node Test Procedure: Make the UE to go out of radio coverage (e.g moving the UE or using attenuators) Expected Results: Verify that: Validate that enodeb is sending a S1-AP UE context Release Request including a Cause IE set to Radio Connection with UE lost Validate that MME sends a S1-AP: UE Context Release Command encapsulating a NAS Deactivate EPS Bearer Context Request including the E-RAB to be Released List IE Validate that enodeb is sending S1-AP: UE Context Release Complete Validate that the UE context is successfully released and there is no longer any resource hold by any network element for that UE Figure 65: UE Context Release due to Radio connection with UE lost

6.2.4.3 Tracking Area Update procedures 6.2.4.3.1 Normal Tracking area Update Test Name: Normal Tracking Area Update References: 3GPP TS 23.401, 5.3.3.2 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.3.3.2 Test Objective: Validate the normal tracking update Pre-Test Conditions: UE is attached UE is in Idle Mode A neighbor cell is configured with a TA which is not in UEs TA list Test Procedure: Make the UE to move to the neighboring cell Expected Results: Verify that: Validate that enodeb sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Normal Tracking Area Update Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to enodeb Validate that enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept Validate that enodeb is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete, Finally, validate that MME is sending a S1-AP UE Context Release Command is enodeb is acknowledging it back by sending back a S1-AP UE Context Release Complete. Validate that the UE context is successfully kept on both MME and enodeb and UE remains in Idle

Figure 66: Normal Tracking Area Update

6.2.4.3.2 Normal Tracking area Update with bearer establishment requested Test Name: Normal Tracking Area Update with bearer establishment requested References: 3GPP TS 23.401, 5.3.3.2 Test Objective: 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 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 Test Objective: 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 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 Test Objective: 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 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 Test Objective: 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 Validate the successful combined tracking and locating area update with bearer establishment requested. This may happen when the UE moves to a neighbor cell and data traffic is resumed through one of the bearers. Pre-Test Conditions: UE is attached UE is attached for both EPS and non-eps services only and one or several services are established with data transfer ongoing UE supports CS fallback A neighbor cell is configured with a TA which is not in the UEs TA list Test Procedure: Stop traffic to put the UE in Idle state Move the UE to the neighboring cell and resume traffic

Expected Results: Verify that: Validate that enodeb sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, including a EPS Update Type IE set to Combined TA/LA updating and EPS bearer context status IE indicating the correct EPS contexts as active on the UE Validate that MME sends S1-AP: Downlink NAS Transport encapsulating a NAS Authentication Request to enodeb Validate that enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Authentication Response to MME Validate that MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Security Mode Command Validate that enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Security Mode Complete Validate that MME is sending a S1-AP Downlink NAS Transport encapsulating A NAS Tracking Area Update Accept including a EPS bearer context status IE indicating the correct the EPS contexts as active in the MME Validate that enodeb is sending a S1-AP Uplink NAS Transport encapsulating a NAS Tracking Area Update Complete. Validate that, MME is subsequently performing a Initial Context Setup and E-RAB Setup (if any dedicated bearers) Validate that the default and dedicated bearers (if any) are successfully established. Validate that services are re-established and data transfer can be resumed. Figure 70: Combined Tracking and Location Area Update with bearer establishment requested

6.2.4.3.6 Periodic Tracking area Update Test Name: Periodic Tracking Area Update References: 3GPP TS 23.401, 5.3.3.2 Test Objective: Pre-Test Conditions: UE is attached UE is in Idle Mode 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 Validate the successful Periodic Tracking area update 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 Test Objective: 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2 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 Test Objective: 3GPP TS 24.301, 5.5.3 3GPP TS 36.413, Section 8.6.2.1, 8.6.2.2, 8.3.3.2 Validate the tracking area update procedure rejected when the network has been implicitly detached the UE Pre-Test Conditions: UE is attached UE is in idle state A neighboring cell is configured with a TA which is not in UEs TA list Test Procedure: Remove the UE from the cell radio coverage in order to have the periodic tracking area update timer (T3412) expires and also the mobile reachable timer expired. The network will then implicitly detach the UE. Validate the procedure on MME Move the UE back under the radio coverage Expected Results: Verify that: Validate that enodeb sends S1-AP: Initial UE message encapsulating a NAS Tracking Area Update Request, Validate that MME sends S1-AP: Downlink NAS Transport encapsulating NAS Tracking Area Update Reject. The EMM Cause IE including a implicitly detached Validate that MME sends a S1-AP UE Context Release Command Validate that enodeb sends a S1-AP UE Context Release Complete Validate that the UE performs a new attach procedure and is successfully completed

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

6.2.4.4 Paging 6.2.4.4.1 Paging with Paging DRX IE Test Name: Paging with Paging DRX IE References: 3GPP TS 23.401, 5.3.4.3 Test Objective: 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.5.2, 8.6.2.1 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. Figure 74: Paging with Paging DRX IE

6.2.4.4.2 Paging without Paging DRX IE Test Name: Paging without Paging DRX IE References: 3GPP TS 23.401, 5.3.4.3 Test Objective: 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.5.2, 8.6.2.1 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. Figure 75: Paging without Paging DRX IE

6.2.4.5 Idle to Active Mode (Service Request) 6.2.4.5.1 Successful Service Request invoked when the UE receives a paging request with CN domain indicator set to PS from the network in ECM-Idle mode (Single bearer) Test Name: Successful Service Request invoked when the UE receives a paging request with CN domain indicator set to PS from the network in ECM- Idle Mode References: 3GPP TS 23.401, 5.3.4.3 Test Objective: 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 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 Test Objective: 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 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 Test Objective: 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 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 Test Objective: 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 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 Test Objective: 3GPP TS 24.301, 5.6.1 3GPP TS 36.413, Section 8.6.2.1, 8.3.1.2 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: References: Test Objective: Successful Service Request invoked when the is in Idle mode and has a mobile originating 1xCS fallback request from the upper layer 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 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: References: Test Objective: Successful Service Request invoked when the is in Active mode and has a mobile originating 1xCS fallback request from the upper layer 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 Validate the successful Service Request invoked when the is in Active mode and has a mobile originating 1xCS fallback request from the upper layer Pre-Test Conditions: UE is attached UE supports CS fallback UE is attached for both EPS and non EPS services UE is in Connected state Test Procedure: Initialize a CS call from the UE. Expected Results: Verify that: Validate that enodeb sends a S1-AP Initial UE message encapsulating a NAS Extended Service Request with Service Type IE set to mobile originating CS fallback or 1xCS fallback Validate that MME sends S1-AP: UE Context Modification Request a CS Fallback Indicator IE. Validate that enodeb sends to MME a S1-AP UE Context Modification Response Validate that the CS callback is successfully established and that the UE can establish the CS Call Remark1: If no CS domain is available the MME will reject by answering the Initial UE message from enodeb with a S1-AP: Initial Context Setup Request encapsulating a NAS Service Reject with EMM Cause IE set to CS domain not available

Figure 82: Successful Service Request when UE is in Active Mode and has a mobile originating 1xCS fallback request

6.2.4.5.8 Successful Initial UE message with Emergency Flag enabled Test Name: Successful initial UE message when UE originating a call with Emergency Flag enabled References: 3GPP TS 23.401, 5.3.2.1 Test Objective: Pre-Test Conditions: UE is not attached UE is LTE capable Validate the successful Initial Context Setup procedure when emergency mode is enabled 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. Figure 83: Successful Initial UE message with Emergency Flag enabled

6.2.5 User Plane Protocol and Data Transfer Test Cases 6.2.5.1.1 User Plane Control Test Cases 6.2.5.1.1.1 GTP-U echo mechanism Test Name: GTP-U echo mechanism Reference: TS 29.281 Section 7.2 Test Objective: Validate the echo mechanism in both UL and DL directions Pre-Test Conditions: Configure both enodeb and SGW to present a echo request timer for testing purposes. Test Procedure: Initiate a UE attach Expected Results: Verify that: Validate that once a GTP-U tunnel is established by the network, enodeb is able to send a GTP-U: Echo Request to SGW. SGW is capable of acknowledging it by sending back a GTP-U: Echo Response. Validate that SGW is also capable of sending a GTP-U: Echo Request as per the configuration and that is successfully acknowledged by enodeb with a GTP-U: Echo Response. Figure 84: GTP-U Echo mechanism

6.2.5.1.1.2 GTP-U message End of Marker Test Name: GTP-U message End of Marker Reference: TS 29.281 Section 7.3.2 Test Objective: Validate that the message End of Marker is properly used during a HO Pre-Test Conditions: S1 interface is properly set up between enodeb and MME X2 interface is properly set up. UE is attached and a single E-RAB exists for the UE. Test Procedure: Start an application to start a download of a large file while HO happens (e.g video streaming session, FTP, etc) Change the radio condition in the enodebs to trigger a HO Expected Results: Verify that: Validate that, prior to the HO, there is a User data transmission ongoing from between Source enodeb and SGW When X2 HO happens and the UE has moved to target enodeb, the UL Data transmission starts automatically from Target enodeb to SGW as soon as the UE context is established through the target enodeb. Validate that Target enodeb sends a S1:AP Path Switch Request to MME to indicate that X2 HO is in process Validate that SGW sends a GTP-U End of Marker to the Source enodeb to indicate that the DL path has been moved Validate that Source enodeb sends a GTP-U End Of Marker to Target enodeb Validate that DL data is resumed between SGW and Target enodeb Validate that Target enodeb is sending a S1-AP: Path Switch Request Acknowledgement to MME in order to indicate the successful end of HO. Remark 1: During this process the Target enodeb can perform a Tracking Area Update procedure with MME if required per the TA configuration on the network.

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

6.2.5.1.1.3 Graceful Error Indication handling by enodeb Test Name: Graceful Error Indication Handling by enodeb Reference: TS 23.007 section 21.6 Test Objective: Validate the appropriate handling of the Error Indication by enodeb from a S-GW Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW One or more E-RAB established for the UE Test Procedure: Force S-GW to send a GTP-U: Error Indication (e.g manual command on SGW, making enodeb to send a UL data for an unexisting EPS Bearer in UL due to HO or manually using an unknown TEID) Expected Results: Verify that: Validate that, SGW is sending a GTP-U: Error Indication including as information element the TEID for which that Error Indication was triggered Validate that enodeb is subsequently initiating the UE Context Release for the EPS bearer by sending a S1-AP UE Context Release req to MME, initiating the 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. Figure 86: Graceful Error Indication handling by enodeb

6.2.5.1.1.4 Graceful Error Indication handling by S-GW Test Name: Graceful Error Indication Handling by S-GW Reference: TS 23.007 section 21.7 Test Objective: Validate the appropriate handling of the Error Indication by S-GW from a enodeb Pre-Test Conditions: S1 interface is properly set up between enodeb and MME/SGW One or more E-RAB established for the UE Test Procedure: Force enodeb to send a GTP-U: Error Indication (e.g manual command on enodeb, making S-GW to send a DL data for an unexisting EPS Bearer in DL due to HO or manually using an unknown TEID) Expected Results: Verify that: Validate that, enodeb is sending a GTP-U: Error Indication including as information element the TEID for which that Error Indication was triggered Validate that upon the reception of the Error Indication with the GTP-U Identifier from the enodeb to the S-GW, the S-GW does not delete the associated bearer Context but just all the enodeb GTP-U TEIDs for this UE. The S-GW then starts buffering DL packets received from this UE and sends Downlink Data Notification message to the MME which triggers the re-establishment of the corresponding bearers. The call flow would be as follows: Upon the reception of the GTP-U Error Indication from enodeb, S-GW sends a S11 Downlink Data Notification to MME MME is sending a S1-AP: Paging to all enodebs belonging to the same TA in which the UE is currently registered The enodeb is sending S1-AP: Initial UE message containing a Service Request to the MME MME is sending a S1-AP: Initial Context setup Request to enodeb enodeb sends a S1-AP: Initial Context Setup Complete to MME Data is re-established on both of directions.

Figure 87: Graceful Error Indication handling by SGW

6.2.5.1.2 Data Transfer on Default Bearer Test Name: Successful Data Transfer on Default Bearer Reference TS 23.401 Section 5.3.2.1 Test Objective: Pre-Test Conditions: UE is not attached Validate the successful data transfer on both of directions on default bearer Test Procedure: Perform UE attach with not any dedicated bearer being initiated by the network Initiate traffic from/to the UE with different traffic types: HTTP, FTP, etc Expected Results: Verify that: enodeb sends MME a S1-AP: Initial UE Message encapsulating the NAS Attach Request, which includes the EPS Mobile Identity IE (set to GUTI) and the ESM message container IE with the NAS PDN Connectivity Request message MME sends a S1-AP: Downlink NAS Transport encapsulating the NAS Identity Request message, with Identity type IE= IMSI enodeb sends a S1-AP Uplink NAS Tansport encapsulating the NAS: Identity Response message with the IMSI IE included. MME sends a S1-AP Downlink NAS Transport encapsulating a NAS Authentication Request message enodeb sends a S1-AP Uplink NAS Transport encapsulating the NAS Authentication Response message The MME sends a S1-AP: Downlink NAS Transport encapsulating a NAS Security Mode Command, with the Selected NAS Security Algorithms IE including EEA0, EEAA1 or EEA2 for Ciphering as per the configuration enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS security mode complete MME sends a S1-AP Downlink NAS Transport encapsulating a NAS ESM Information Request enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS ESM Information Response MME sends a S1-AP: Initial Context Setup Request encapsulating a NAS Attach Accept message. The message will include the NAS Activate Default EPS bearer context Request message, with the new GUTI IE included. enodeb sends a S1-AP: Initial Context Setup Response message enodeb sends a S1-AP Uplink NAS Transport encapsulating a NAS Attach Complete. The ESM message container IE will include a NAS Activate Deftault EPS Bearer Context Accept message. Validate that all kind of Data can be transferred on the default bearer on both of directions for any traffic type.

UE enodeb 1. Attach Request 2. Attach Request 4. Identity Request 4. Identity Response new MME 5a. Authentication / Security 5b. Identity Request/Response 6. Ciphered Options Request Old MME/SGSN 3. Identification Request 3. Identification Response 6. Ciphered Options Response 7. Delete Sesion Request (E) 5b. ME Identity Check EIR 7. Delete Session Response 8. Update Location Request Serving GW PDN GW PCRF HSS 9. Cancel Location 9. Cancel Location Ack 7. PCEF Initiated IP-CAN Session Termination (A) (F) 10. Delete Session Request 10. Delete Session Response 10. PCEF Initiated IP-CAN Session Termination (B) 16. Create Session Response 17. Initial Context Setup Request / Attach Accept 18. RRC Connection Reconfiguration 19. RRC Connection Reconfiguration Complete 20. Initial Context Setup Response 21. Direct Transfer 22. Attach Complete First Uplink Data 12. Create Session Request 23. Modify Bearer Request 11. Update Location Ack 13. Create Session Request 14. PCEF Initiated IP-CAN Session Establishment/Modification (C) 15. Create Session Response First Downlink Data (if not handover) 23a. Modify Bearer Request 23b. Modify Bearer Response First Downlink Data 24. Modify Bearer Response 25. Notify Request 26. Notify Response (D) Figure 88: Data Transfer on Default Bearer

6.2.5.1.3 Data Transfer on Dedicated Bearer Test Cases 6.2.5.1.3.1 Successful Data Transfer with non-gbr Service and AM Mode Test Name: Sucessful Data Transfer with non-gbr Service and AM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with non-gbr Service and AM Mode on enodeb Pre-Test Conditions: UE is in Active Mode enodeb will use the RLC AM Mode Test Procedure: Perform UE attach Initiate traffic to the UE with non-gbr, using RLC AM Mode at the enodeb that will entail the creation of a dedicated bearer Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that enodeb is sending a S1-AP E-RAB Setup Response Validate that enodeb is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both enodeb and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.

Figure 89: Data Transfer on Dedicated Bearer with non-gbr Service and AM Mode

6.2.5.1.3.2 Successful Data Transfer with non-gbr Service and UM Mode Test Name: Sucessful Data Transfer with non-gbr Service and UM Mode Reference: TS 23.401 and 36.413 and 29.281 Test Objective: Validate the successful data transfer with non-gbr Service and UM Mode on enodeb Pre-Test Conditions: UE is in Active Mode enodeb will use the RLC UM Mode Test Procedure: Perform UE attach Initiate traffic to the UE with non-gbr, using RLC UM Mode at the enodeb that will entail the creation of a dedicated bearer Expected Results: Verify that: Validate that MME sends a S1-AP: E-RAB Setup Request encapsulating a NAS Activate Dedicated EPS Bearer Context Request. The NAS message shall include the EPS QoS IE, the TFT IE and the Linked EPS Bearer Identity IE Validate that enodeb is sending a S1-AP E-RAB Setup Response Validate that enodeb is sending a S1 AP: Uplink NAS Transport encapsulating a ANS Activate dedicated EPS Bearer Context Accept. This NAS message shall include the EPS bearer identity and the Procedure transaction Identity IE Validate that the dedicated bearer is established successfully and both enodeb and SGW/PGW have the same TFT/QoS features for the bearer Validate the appropriate Data Transfer, honoring the QoS and the TFT filters.

Figure 90: Data Transfer on Dedicated Bearer with non-gbr service and UM Mode