Nviot MTC UUU 520 PDF

Network Vendors IOT Forum
Master Test Catalogue
UMTS Uu Interface
between Network and User Equipment
Document Number Version Network Vendors IOT Forum Date Page

nviot_mtc_UUU_520.doc 5.2.0 Confidential 10-Apr-06 1 of 1076
Master Test Catalogue - UMTS Uu Interface

COPYRIGHT Network Vendors IOT Forum

All rights reserved.
No part of this document may be copied, distributed, transmitted, transcribed, stored in a retrieval system, or translated into any human or
computer language without the prior written permission of the Network Vendors IOT Forum.
The manufacturer has made every effort to ensure that the instructions contained in the documents are adequate and free of errors and
omissions. The manufacturer will, if necessary, explain issues that may not be covered by the documents. The manufacturer's liability for any
errors in the documents is limited to the correction of errors and the aforementioned advisory services.
The documents have been prepared to be used by professional and properly trained personnel and the customer assumes full responsibility
when using them. The manufacturer welcomes customer comments as part of the process of continual development and improvement of the
documentation in the best way possible from the user's viewpoint.
Any trademarks mentioned in the documents are the property of their respective owners.
Network Vendors IOT Forum.


Table Of Contents
1 Scope .......................................................................................................... 6
2 References ................................................................................................... 6
2.1 Applicable Documents................................................................................... 6
2.2 Standards ..................................................................................................... 6
3 Abbreviations ................................................................................................ 6
4 Overview...................................................................................................... 9
5 Test Configuration......................................................................................... 9
5.1 Network Configuration ................................................................................. 10
5.1.1 Network Configuration A .................................................................................... 10
5.1.2 Network Configuration B .................................................................................... 11
5.1.3 Network Configuration C .................................................................................... 12
5.1.4 Network Configuration D .................................................................................... 13
5.1.5 Network Configuration E .................................................................................... 14
5.1.6 Network Configuration F..................................................................................... 15
5.1.7 Network Configuration G .................................................................................... 16
5.1.8 Network Configuration H .................................................................................... 17
6 Functional Test case list.............................................................................. 18
6.1 Mobility....................................................................................................... 18
6.1.1 CS 18
6.1.2 PS 18
6.1.3 Cell Update ....................................................................................................... 19
6.2 CS Call (incl. emergency call, VT call and CS data)....................................... 19
6.3 PS Call....................................................................................................... 20
6.4 Multi services call........................................................................................ 21
6.5 Power Control............................................................................................. 21
6.5.1 Open Loop Power Control .................................................................................. 21
6.5.2 Inner Loop Power Control................................................................................... 22
6.5.3 Outer Loop Power Control .................................................................................. 22
6.6 3G HO scenarios ........................................................................................ 22
6.6.1 General / soft and softer handover ...................................................................... 23
6.6.2 General / inter-frequency handovers ................................................................... 24
6.6.3 Compressed Mode ............................................................................................ 25
6.7 Inter System Mobility (incl.Cell re selection, HHO) ......................................... 25
6.8 Supplementary Services .............................................................................. 26
6.9 SMS........................................................................................................... 26
6.10 UE Positioning Test Cases .......................................................................... 27
6.10.1 UE positioning / UE based A-GPS test cases ...................................................... 27
6.10.2 UE positioning / UE assisted A-GPS test cases ................................................... 27
6.10.3 UE positioning / Test cases that apply to both UE-based and UE-assisted A-GPS . 28
6.11 Ciphering.................................................................................................... 28
6.12 HSDPA ...................................................................................................... 29
6.12.1 Basic Session Setup and Termination ................................................................. 29
6.12.2 Session Setup and Termination with Active CS Call ............................................. 29
6.12.3 Establishment of HS-DSCH when in Soft Handover ............................................. 29
6.12.4 Mobility between 2 HSDPA cells (serving HS-DSCH cell change) ......................... 29
6.12.5 Reconfigurations Between HS-DSCH and DCH and Vice-Versa ........................... 30
6.12.6 Transitions between cell_DCH and cell_FACH (start and stop of HS-DSCH
reception) ................................................................................................... 32
6.12.7 Inter-frequency handovers .................................................................................. 32
6.12.8 Active Set Update of DCH with active HS-DSCH ................................................. 32
6.12.9 Inter-RAT HO and cell re-selection...................................................................... 33
6.13 IMS ............................................................................................................ 33
6.13.1 Session Initiation ............................................................................................... 33
6.13.2 Session Release................................................................................................ 34
6.13.3 Registration and Authentication .......................................................................... 34
6.13.4 QoS Setup and Negotiation ................................................................................ 34

6.13.5 SIP Compression............................................................................................... 35

6.13.6 Mobility and inter RA T........................................................................................ 35
6.13.7 Media Resources interaction .............................................................................. 36
6.13.8 Location Services .............................................................................................. 36
6.13.9 Stand-Alone Transactions .................................................................................. 37
7 Protocol Test Case List ............................................................................... 39
7.1 Idle Mode ................................................................................................... 39
7.2 Layer 2....................................................................................................... 39
7.3 Radio ......................................................................................................... 39
7.4 Mobility Management .................................................................................. 42
7.5 Call Control ................................................................................................ 43
7.6 Session Management .................................................................................. 44
7.7 Packet Switched Mobility Management ......................................................... 45
7.8 General Tests............................................................................................. 45
7.9 Radio Bearer Services................................................................................. 47
7.9.1 Combinations on DPCH ..................................................................................... 47
7.9.2 Combinations on PDSCH and DPCH .................................................................. 52
7.9.3 Combinations on SCCPCH................................................................................. 52
7.9.4 Combinations on PRACH................................................................................... 53
7.10 Supplementary Services .............................................................................. 53
7.11 SMS........................................................................................................... 53
7.12 Inter system hard handover from GSM to UTRAN ......................................... 53
8 Functional test cases................................................................................... 54
Test Purpose: ............................................................................................................................564
9 Protocol test cases.....................................................................................596
Document History .......................................................................................................................1075


Table Of Figures
Figure 1: Network Configuration A: Configuration with 1 Cells, 1 NodeB, 1 RNC ............................. 10
Figure 2: Network Configuration B: Configuration with 2 Cells, 1 NodeB, 1 RNC .............................. 11
Figure 3: Network Configuration C: Configuration with 3 Cells, 1 NodeB, 1 RNC .............................. 12
Figure 4: Network Configuration D: Configuration with 6 Cells, 2 NodeBs, 1 RNC ............................ 13
Figure 5: Network Configuration E: Configuration with 6 Cells, 2NodeBs, 2 RNCs ............................ 14
Figure 6: Network Configuration F: Configuration for Intersystem Handover Tests............................ 15
Figure 7: Network Configuration G: Configuration for Inter PLMN Handover Tests............................ 16


1 Scope
Interoperability testing (IOT) ensures compatibility between elements of two different suppliers at a
particular interface. This document specifies the test suite to be used for the evaluation of compatibility
between all elements of the UMTS network and the User Equipment (UE) in particular i.e. the Uu
interface between the UMTS Network and the User Equipment (UE).
The equipment under test that means the UMTS network and the UE, which are interconnected and
have passed the tests defined in this document will be deemed to be compatible with respect to their
interworking on the Uu interface.
The main concern of IOT is the verification of the compatibility on the Uu interface. A test will be
regarded as passed only if the functionality described in the particular test case has been achieved
and the protocol interworking defined for the test case could be observed at the interface. The latter
will be ensured by closely monitoring all messages exchanged at the interface during the test and later
by checking these messages against the appropriate UMTS recommendations.
This document is not designed as formal proof of UMTS conformance, however these tests will
provide a fair degree of confidence that the elements under test will be capable of offering requested
functionalities.
Interoperability testing is a part of the system test. The precondition for doing IOT between the UMTS
network and the User Equipment is to have pretested equipment. The pretesting shall be done before
doing IOT in order to ensure the functionality of the test cases which are selected from this catalogue
for the IOT session.
2 References
2.1 Applicable Documents
[1] Network Vendor IOT Forum - IOT Methodology
2.2 Standards
[2] 3GPP TS 34.123 -1 User Equipment (UE) conformance specification
[3] 3GPP TS 51.010 -1 Mobile Station (MS) conformance specification
3 Abbreviations
A2P AAL type 2 channel Path identifier
AAL2 ATM Adaptation Layer type 2
AAL5 ATM Adaptation Layer type 5
ALCAP Access Link Control Application Part
AMR Adaptive Multi Rate vocoder (or codec)
ATM Asynchronous Transfer Mode
BC Broadcast
BSC Base Station Controller
BSS Base Station Sub-system
BSSMAP BSS Management Application Part
BTS Base Transceiver Station
CC Call Control
CEID Connection Element Identifier
CID Channel Identifier
CN Core Network

CS Circuit Switched
DL Downlink
DRX Discontinuous Reception
DSAID Destination Signalling Association Identifier
DT1 Data Form 1
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile communications
GTP GPRS Tunnelling Protocol
GTP-U GPRS Tunnelling Protocol-User plane
HLR Home Location Register
HO Handover
ID Identifier
IE Information Element
IETF Internet Engineering Task Force
IMSI International Mobile Subscriber Identity
IOT Interoperability Test
IP Internet Protocol
LAI Location Area Identifier
M3UA SS7 MTP3 User Adaptation Layer
MM Mobility Management
MMI Man Machine Interface
MO Mobile Originated
MOC Mobile Originated Call
MS Mobile Station
MSC Mobile services Switching Center
MT Mobile Terminated
MTC Mobile Terminated Call
MTP Message Transfer Part
NAS Non Access Stratum
NSAPI Network Service Access Point Identifier
OSAID Originating Signalling Association Identifier
PDN Packet Data Network
PDP Packet Data Protocol
PDU Protocol Data Unit
PHS Personal Handy phone System
PIAFS PHS Internet Access Forum Standard
PLMN Public Land Mobile Network
PS Packet Switched
PSTN Public Switched Telephone Network
P-TMSI Packet TMSI
PTP Point To Point
PVC Permanent Virtual Connexion
PVC Permanent Virtual Circuit
QoS Quality of Service
RAB Radio Access Bearer
RAC Routing Area Code
RAI Routing Area Identifier
RANAP Radio Access Network Application Part
RFCI RAB subFlow Combination Indicator
RLC Radio Link Control
RNC Radio Network Controller
RNS Radio Network Subsystem
RRC Radio Resource Control
SA Service Area
SAAL-NNI Signalling AAL-Network to Network Interface
SABP Service Area Broadcast Protocol
SAP Service Access Point


SAPI Service Access Point Identifier

SCCF-NNI Service Specific Coordination Function Network Node Interface
SCCP Signalling Connection Control Part
SCTP Stream Control Transmission Protocol
SD Switched Data
SDU Service Data Unit
SGSN Serving GPRS Support Node
SLTA Signalling Link Test Ack Message
SLTM Signalling Link Test Message
SMpSDU Support Mode for predefined SDU size
SMS Short Message Service
SPC Signalling Point Connection
SRNS Serving RNS
SS7 Common Channel Signalling number 7
SSCF Service Specific Coordination Function
SSCOP Service Specific Connection Oriented Protocol
STC Signalling Transport Converter
SUGR Served User Generated Reference
TCP Transmission Control Protocol
TE Terminal Equipment
TEID Tunnel Endpoint Identifier
TFT Traffic Flow Template
TI Transaction Identifier
TLLI Temporary Logical Link Identity
TMSI Temporary Mobile Subscriber Identity
UDI Unrestricted Digital Information
UDP User Datagram Protocol
UDT Unit Data
UE User Equipment
UEA UMTS Encryption Algorithm
UIA UMTS Integrity Algorithm
UL Uplink
UMTS Universal Mobile telecommunication System
UP User Plane
USIM Universal Subscriber Identity Module
UTRAN UMTS Terrestrial Radio Access Network
VCI Virtual Circuit Identifier
VLR Visitor Location Register
VPI Virtual Path Identifier
XUDT Extended Unit Data


4 Overview
The purpose of this testing is to verify the correct implementation of the Uu interface between the
UMTS network and the UE.
The different protocol test cases shown in this document are derived from the 3GPP Technical
Specifications (TS) 34.123-1 v5.3.0 and 51.010-1 vxxxx (which corresponce to the March 2003 core
specsification version. These test cases building the master test catalogue have been modified for IOT
purposes. In original they are written for the use with a System Simulator.
The default parameter for the test cases can be found in 3GPP TS 34.108.
Functional oriented test cases have been specified and are included primarily as triggers for the
protocol oriented test cases. The functional to protocol cross-referencing is done using the latest
version of the corresponding cross-referencing matrix. This matrix, stored in the same location as the
Master Test Catalogue, shows the protocol test cases that will be triggered by executing a specific
functional test case. One functional test case can be used as a trigger for several protocol test cases
and a single protocol test case could be triggered by several functional test cases.
When a protocol test case requires a functional test case as a trigger and the successful outcome of
the protocol test case requires the failure of the functional test case, the outcome of the functional test
case should be ignored, as the focus in this situation is only on the outcome of the protocol test case.
The methodology that is applicable to this testing activity is defined in [1].
Bearers used for test execution are not specified for some testcases, so its up to the IOT parties to
agree on bearers to be used for test execution and add this information to the test plan / test report. Its
recommended to select testcases that are used to test all compatible RABs / RAB cominations.
5 Test Configuration
This section lists the network elements necessary to perform all the test cases detailed in this
document. Lack of any of the required network entities will render some test cases to be impossible.
The detailed network configurations are needed to perform the tests defined in this document. First the
test case one-liners and then the detailed descriptions identify which configuration should be used to
perform the test.
Eventual service specific equipment/servers (e.g. SMS) needed for the execution of several test cases
might be added to the presented configurations on a case-by-case basis and will be mentioned within
the detailed test case descriptions.
The interoperability test cases will be executed in an IOT lab environment. Field testing is outside the
scope of the document.


5.1 Network Configuration
5.1.1 Network Configuration A
Core Network
(CS/PS)
Iu Interface
Iu Monitor
(optional)
RNC
IuB Interface
IuB Monitor
Node B
Cell 1
UE TE
Figure 1: Network Configuration A: Configuration with 1 Cells, 1 NodeB, 1 RNC


5.1.2 Network Configuration B
Core Network
(CS/PS)
Iu Interface
Iu Monitor
(optional)
RNC
IuB Interface
IuB Monitor
Node B
Cell 1 Cell 2
UE TE
Figure 2: Network Configuration B: Configuration with 2 Cells, 1 NodeB, 1 RNC


5.1.3 Network Configuration C
Core Network
(CS/PS)
Iu Interface
Iu Monitor
(optional)
RNC
IuB Interface
IuB Monitor
Node B
Cell 1 Cell 2 Cell 3
UE TE
Figure 3: Network Configuration C: Configuration with 3 Cells, 1 NodeB, 1 RNC


5.1.4 Network Configuration D
Core Network
(CS/PS)
Iu Interface
Iu Monitor
(optional)
RNC
IuB Interface
IuB Monitor
Node B Node B
Cell 1 Cell 2 Cell

Cell 13 Cell 1 Cell 2 Cell 3
UE TE
Figure 4: Network Configuration D: Configuration with 6 Cells, 2 NodeBs, 1 RNC


5.1.5 Network Configuration E
Core Network
(CS/PS)
Iu Interface
Iu Monitor
(optional)
RNC RNC
IuB Interface
IuB Monitor
Node B Node B
Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3
UE TE
Figure 5: Network Configuration E: Configuration with 6 Cells, 2NodeBs, 2 RNCs


5.1.6 Network Configuration F
3G Core 2G Core
Network Network
(CS)
Iu Interface
Iu Monitor
(optional)
RNC BSC
IuB Interface
IuB Monitor
ABIS Interface
ABIS Monitor
Node B BTS
Cell 1 Cell 2 Cell 3 Cell 3 Cell 3 Cell 3
UE TE
Figure 6: Network Configuration F: Configuration for Intersystem Handover Tests


5.1.7 Network Configuration G
3G Core 3G Core
Network Network
Iu Interface
Iu Monitor
(optional)
RNC RNC
C
IuB Interface
IuB Monitor
Node B BTS
Cell 1 Cell 1
UE TE
Figure 7: Network Configuration G: Configuration for Inter PLMN Handover Tests


5.1.8 Network Configuration H
Core Network
3G/2G(CS/PS)
Iu Interface
Iu Monitor
(optional) A Interface Iu Interface
BSC RNC RNC

MCC=X MNC=A MCC=X MNC=B MCC=X MNC=C
IuB Monitor
IuB Interface
Abis Interface
Abis Monitor
BTS Node B Node B
Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3
UE TE
Figure 8: Network Configuration H: Configuration for Equivalent PLMN Tests

Creation Template for the MTC - UMTS Uu Interface

6 Functional Test case list

This section gives a one-line description of each test case. The listed tests are functional test cases.
The test cases are based on the version Mar 2003 of the 3GPP core.
Total number of test cases: 181
6.1 Mobility
6.1.1 CS
Test Id Description Config.

F_6.1.1.1 UE location update following switch on (normal case A,B,C,D,E,F
F_6.1.1.2 UE changing of LA D,E
F_6.1.1.3 Periodic location update A,B,C,D,E,F
F_6.1.1.4 UE location update following switch on (IMSI invalid) A,B,C,D,E,F
F_6.1.1.5 UE location update following switch on (PLMN not allowed) A,B,C,D,E,F
F_6.1.1.6 UE location update following switch on (service not subscribed) A,B,C,D,E,F
F_6.1.1.7 Location update accepted (TMSI unknown) A,B,C,D,E,F
F_6.1.1.8 Location update following LA change during CS call A,B,C,D,E,F
Number of test cases: 8
6.1.2 PS

F_6.1.2.1 MS PS attach following switch on (successful case) A,B,C,D,E,F
MS PS attach following switch on (unsuccessful case IMSI unknown A,B,C,D,E,F
F_6.1.2.2
in HLR)
MS PS attach following switch on (unsuccessful case PLMN not A,B,C,D,E,F
F_6.1.2.3
allowed)
MS PS attach following switch on (unsuccessful case GPRS service A,B,C,D,E,F
F_6.1.2.4
not allowed)
MS PS attach following switch on (unsuccessful cases Authentication A,B,C,D,E,F
F_6.1.2.5
rejected)
MS combined PS/CS attach following switch on. PS only attach A,B,C,D,E,F
F_6.1.2.6
accepted
MS combined PS/CS attach following switch on. PS and non-PS attach A,B,C,D,E,F
F_6.1.2.7
accepted
F_6.1.2.8 Routing Area Update B,C,D,E
F_6.1.2.9 Combined RA/LA Update, RA only B,C,D,E
F_6.1.2.10 Combined RA/LA Update, Combined RA/LA updated B,C,D,E
F_6.1.2.11 Periodic RA update A,B,C,D,E
F_6.1.2.12 Detach by power off A,B,C,D,E,F
F_6.1.2.13 Detach without power off A,B,C,D,E,F
F_6.1.2.14 CN initiated detach A,B,C,D,E,F
F_6.1.2.15 S-RNS Relocation E
F_6.1.2.16 URA Update: Change of URA B,C,D,E
F_6.1.2.17 URA Update: Periodical URA A,B,C,D,E,F


F_6.1.2.18 URA Update: re-entering of service area after T305 expiry B,C,D,E
F_6.1.2.19 Routing Area Update performed after a PS Call B,C,D,E
F_6.1.2.20 Routing Area Update performed after a combined Call B,C,D,E
F_6.1.2.21 C
Cell reselection intra frequency (UE is idle mode):
F_6.1.2.22 Cell re-selection inter-frequency inta-nodeB/ inter sector (UE is C
idle mode):
Cell re-selection between inter-frequency and inter RAT cells (UE F
F_6.1.2.23
is idle mode):
F_6.1.2.24 C
Cell reselection with new neighbouring cells(UE is idle mode)
6.1.3 Cell Update

F_6.1.3.1 UE perform cell Update after a cell reselection in CELL_FACH B,C,D,E
F_6.1.3.2 UE perform cell update after a cell reselection in CELL_PCH B,C,D,E
F_6.1.3.3 Periodical cell update in CELL_FACH A,B,C,D,E,F
F_6.1.3.4 Cell Update when UE performs UL data transmission in URA_PCH B,C,D,E,F
Cell Update, because UE is re-entering of service area in CELL_PCH A,B,C,D,E,F
F_6.1.3.5
or CELL_FACH
F_6.1.3.6 UE perform cell update due to Radio Link Failure A,B,C,D,E
F_6.1.3.7 Cell update with SRNS relocation E
F_6.1.3.8 UE perform URA update after a URA reselection in URA_PCH D,E
F_6.1.3.9 Periodical cell update in CELL_PCH A,B,C,D,E,F
F_6.1.3.10 Cell Update , when UE perform UL data transmission in CELL_PCH A,B,C,D,E,F
F_6.1.3.11 Cell update when UE is paged in CELL_PCH A,B,C,D,E,F
F_6.1.3.12 Cell update because UE is paged in URA_PCH A,B,C,D,E,F
F_6.1.3.13 Periodical ura update in URA_PCH A,B,C,D,E,F
F_6.1.3.14 RRC connection re-establishment following radio link failure (CS RAB) A,B,C,D,E
RRC connection re-establishment following RLC unrecoverable error A,B,C,D,E
F_6.1.3.15
(PS RAB)
6.2 CS Call (incl. emergency call, VT call and CS data)

F_6.2.1 Emergency Call: Normal case A,B,C,D,E,F
F_6.2.2 Emergency Call: Normal case Network Releases the call A,B,C,D,E,F
F_6.2.3 Emergency Call: Normal case UE releases the call A,B,C,D,E,F
F_6.2.4 Emergency Call: Forbidden PLMN A,B,C,D,E,F
F_6.2.5 Emergency Call: IMSI not allowed A,B,C,D,E,F
F_6.2.6 Mobile-Originate CS Data - Setup A,B,C,D,E,F
F_6.2.7 Mobile Terminated CS Data - Setup A,B,C,D,E,F


F_6.2.8 CS Data - Network Release A,B,C,D,E,F

F_6.2.9 CS Data Call - Mobile Release A,B,C,D,E,F
F_6.2.10 MO Voice Call A,B,C,D,E,F
F_6.2.11 MT Voice Call A,B,C,D,E,F
F_6.2.12 Voice Call Release: UE initiated A,B,C,D,E,F
F_6.2.13 Voice Call Release: Network initiated A,B,C,D,E,F
A,B,C,D,E,F,
F_6.2.14 Mobile-to-Mobile Video Telephony call setup
G
A,B,C,D,E,F,
F_6.2.15 Mobile-to-Mobile Video Telephony call release
G
Unsuccessful mobile-to-mobile video telephony call, terminating mobile A,B,C,D,E,F,
F_6.2.16
is not a 3G-324M UE G
F_6.2.17 AMR Rate Control DL -two AMR rates A,B,C,D,E,F
F_6.2.18 AMR Rate Control DL - Multiple AMR rates A,B,C,D,E,F
F_6.2.19 AMR Rate Control UL -two AMR rates A,B,C,D,E,F
F_6.2.20 AMR Rate Control UL - Multiple AMR rates A,B,C,D,E,F
Mobile-to-Mobile Video Telephony call leads to speech when called A,B,C,D,E,F,
F_6.2.21
party does not support VT (Rel-5) G
6.3 PS Call

F_6.3.1 UE initiated PS call QoS offered by Network is the requested QoS A,B,C,D,E,F
F_6.3.2 UE initiated PS call QoS rejected by UE A,B,C,D,E,F
F_6.3.3 UE initiated PS call with UE initiated PDP context modification A,B,C,D,E,F
UE initiated successful secondary PDP context activation/ QoS offered A,B,C,D,E,F

F_6.3.4
by Network is the requested QoS
F_6.3.5 UE initiated unsuccessful secondary PDP Context Activation A,B,C,D,E,F
Network initiated PDP context modification (QoS higher than or equal A,B,C,D,E,F
F_6.3.6
to the minimum QoS set in the UE)
Network initiated PDP context modification (lower than the minimum A,B,C,D,E,F
F_6.3.7 QoS set in the
UE)
F_6.3.8 UE initiated PDP Context Modification not accepted by the network A,B,C,D,E,F
F_6.3.9 PDP context deactivation initiated by UE A,B,C,D,E,F
F_6.3.10 PDP context deactivation initiated by network A,B,C,D,E,F
F_6.3.11 PDP context activation rejected by the network A,B,C,D,E,F
F_6.3.12 PDP context preservation NW initiated reestablishment A,B,C,D,E,F
F_6.3.13 PDP context preservation UE initiated establishment A,B,C,D,E,F
F_6.3.14 NW initiated PS call A,B,C,D,E,F
F_6.3.15 2 primary PDP context activation A,B,C,D,E,F
F_6.3.16 2 secondary PDP context activation A,B,C,D,E,F
Transport channel type switching From CELL_DCH to CELL_FACH, A,B,C,D,E,F
F_6.3.17
and CELL_FACH to CELL_DCH
F_6.3.18 Change of PS radio bearer through RRC Radio Bearer Reconfiguration A,B,C,D,E


Change of PS radio bearer through RRC Radio Bearer Reconfiguration E

F_6.3.19
in soft handover (inter-RNC)
6.4 Multi services call

F_6.4.1 Multi-Service: Mobile Originate AMR then PS data call A,B,C,D,E,F
F_6.4.2 Mobile Originate PS data call and AMR call A,B,C,D,E,F
F_6.4.3 Multi-Service: Attach on Demand A,B,C,D,E,F
F_6.4.4 Multi-Service: PS/AMR-UE receives SMS message A,B,C,D,E,F
F_6.4.5 Multi-Service: PS/AMR-NW releases the AMR call A,B,C,D,E,F
F_6.4.6 Multi-Service: PS/AMR-NW releases the PS Data Call A,B,C,D,E,F
F_6.4.7 Multi-Service: PS/AMR Intra-node B Inter-Freq Hand Over, blind B,C
Multi-Service: PS/AMR Intra-nodeB Inter-freq Hand Over, with B,C
F_6.4.8
measurements
F_6.4.9 Multi-Service: PS/AMR Inter-node B Inter-freq Hand Over, blind D
Multi-Service: PS/AMR Inter-nodeB Inter-freq Hand Over, with D
F_6.4.10
measurements
F_6.4.11 Multi-Service: PS/AMR Inter-RNC Inter-freq Hand Over, blind E
Multi-Service: PS/AMR Inter-RNC Inter-freq Hand Over, with E
F_6.4.12
measurements
Multi-Service: Mobile Originates PS Call - Network Originates AMR A,B,C,D,E,F
F_6.4.13
Call
F_6.4.14 Multi-Service: Mobile Releases the AMR First then PS data Call A,B,C,D,E,F
Multi-Service: Mobile Releases the AMR First then Network Releases A,B,C,D,E,F
F_6.4.15
the PS data Call
Multi-Service: Mobile Releases the PS Call then Network Releases the A,B,C,D,E,F
F_6.4.16
AMR Call
Multi-Service: Network Releases the AMR Call then Mobile Releases A,B,C,D,E,F
F_6.4.17
the PS Call
Multi-Service: Network Releases the PS Call then Mobile Releases the A,B,C,D,E,F
F_6.4.18
AMR Call
F_6.4.19 Multi-Service: Mobile Originates PS Data call followed by VT call A,B,C,D,E,F
F_6.4.20 Multi-Service: Mobile Originates VT call followed by PS Data call A,B,C,D,E,F
Multi-Service: NW releases the VT call followed by Mobile originated A,B,C,D,E,F
F_6.4.21
PS Data call release
6.5 Power Control
6.5.1 Open Loop Power Control

F_6.5.1.1 RACH preamble initial power setting (FDD) A
F_6.5.1.1a UpPCH transmission power setting (TDD) A
F_6.5.1.2 RACH power ramping Transmission (FDD) A


F_6.5.1.2a UpPCH power ramping Transmission (TDD) A

F_6.5.1.3 RACH power ramping Timing verification (FDD) A
F_6.5.1.4 RACH power ramping Power ramp step parameter check (FDD) A
F_6.5.1.4a UpPCH power ramping Power ramp step parameter check (TDD) A
F_6.5.1.5 RACH message part timing and power verification (FDD) A
F_6.5.1.5a RACH message part timing and power verification (TDD) A
F_6.5.1.6 Uplink DCH initial power General test (FDD) A
F_6.5.1.6a Uplink DCH initial power General test (TDD) A
6.5.2 Inner Loop Power Control

F_6.5.2.1 Inner loop power control in the UL DCH A,B,C,D,E,F
F_6.5.2.2 Inner loop power control DL DCH A,B,C,D,E,F
Inner loop power control in the UL DCH in Soft Handover mode B,C,D,E,F
F_6.5.2.3
(FDD)
F_6.5.2.3a Inner loop power control in the UL DCH in Baton Handover mode. B,C,D,E,F
Inner loop power control in the UL DCH in Softer Handover mode B,C,D,E,F
F_6.5.2.4
(FDD)
F_6.5.2.5 Inner loop power control DL DCH in Soft Handover mode (FDD) B,C,D,E,F
F_6.5.2.5a Inner loop power control DL DCH in Baton Handover mode (TDD) B,C,D,E,F
F_6.5.2.6 Inner loop power control in the UL DCH in Compressed mode (FDD) B,C,D,E,F
F_6.5.2.7 Inner loop power control DL DCH in Compressed mode (FDD) B,C,D,E,F
6.5.3 Outer Loop Power Control

F_6.5.3.1 Uplink outer loop power control Initial SIR target is too high A
F_6.5.3.2 Uplink outer loop power control Initial SIR target is too low A
F_6.5.3.3 Uplink outer loop power control Multi-service A
F_6.5.3.4 Downlink outer loop power control Variation of BLER target A
F_6.5.3.5 Downlink outer loop power control multi-service A
6.6 3G HO scenarios
General remarks on handover test cases
- test cases were designed so that they can be ran in CS only, PS only or CS+PS. The test report
shall show which configuration was used
- ciphering is optional. The test report shall show if each test case was run with or without ciphering
- integrity must be activated.


- Measurements can be set up using SIB#11 or with a MEASUREMENT CONTROL message,

depending on network implementation. The message flow will show both cases.
- Periodical and/or event-triggered measurements can be set up by the network
6.6.1 General / soft and softer handover
The purpose is to validate the soft and softer handover interoperability between 3GPP network and
terminal equipment. The test cases remain generic and apply to CS RABs and/or PS RABs. The inter-
RNC soft handovers are not covered by these test cases as the mechanisms and signaling included
are transparent to the UE.
A soft handover is performed when a radio link is added from a cell that carries the same radio
frequency, but that does not belong to the node B where the radio connection was originally
established (the case when the new cell belongs to the same nodeB is called softer handover)
Each node B has its own synchronization reference and the 2 cells are time-shifted by an arbitrary
number of chips. Thus, UE measurements related to synchronization, such as the SFN-CFN, are
compulsory. When the radio link is added, the related CFN is shifted in time with the cell SFN in order
to match the CFN of the original cell. The offset is based on the UEs measurement (expectedly 0.5
chip accurate). However, in order to maintain orthogonality properties within the new cell, it is rounded
to the closest 256 chip boundary, which is also the maximum code length (the 512-SF being a special
case).
The UE receives two signals which may be shifted in time by a max of 128 chips. The signals are
merged by the rake receiver of the UE.
On the Iub interface, a new aal2 FP circuit is established with the target nodeB. In DL, the circuit
carries exactly the same info as what is transmitted to the other nodeB. The same UL signal is
received by each nodeB and carried back with the Quality Estimate and radio CRC error indication in
each FP connection to the RNC.
Reference: 3GPP TS 25.133 clause 5.1, 8.1.2, 8.1.2.2

3G Handovers / soft and softer handover / Softer handover / Addition B,C
F_6.6.1.1
of one radio link
3G Handovers / soft and softer handover / Softer handover / Addition C
F_6.6.1.2
of two radio links
3G Handovers / soft and softer handover / Softer handover / Removal C
F_6.6.1.3
of a radio link
3G Handovers / soft and softer handover / Softer handover / Combined C
F_6.6.1.4
addition and removal of a radio link
3G Handovers / soft and softer handover / Softer handover / Primary D,E
F_6.6.1.5
cell change
3G Handovers / soft and softer handover / Soft handover / Addition of a D,E
F_6.6.1.6
radio link
3G Handovers / soft and softer handover / Soft handover / Addition of 2 D,E
F_6.6.1.7
radio links (softer + soft)
Generic / soft and softer handover / Soft handover / active set update D,E
F_6.6.1.8
when active set is full
Generic / soft and softer handover / Inter-RNC Soft handover followed E
F_6.6.1.9
by SRNS relocation
F_6.6.1.10 3G Handovers / intra-frequency handover / inter-RNC handover E


6.6.2 General / inter-frequency handovers
The purpose is to validate the inter-frequency hard handover interoperability between 3GPP network
and terminal equipment. The test cases remain generic and apply to CS RABs and/or PS RABs.
An inter-frequency handover is performed when a radio link is added from a cell that carries a different
radio frequency. That cell can belong to the same node B as the original cell, or to a different one.
6.6.2.1 3G Handovers / inter-frequency handover / intra-nodeB handover

3G Handovers / inter-frequency handover / intra-nodeB handover B,C
F_6.6.2.1.1
(blind)
3G Handovers / inter-frequency handover / intra-nodeB handover (with B,C
F_6.6.2.1.2
inter-frequency measurements)
3G Handovers / inter-frequency handover / intra-nodeB handover C
F_6.6.2.1.3
(blind), with UE in softer HO (2 legs) prior to hard HO
3G Handovers / inter-frequency handover / intra-nodeB handover (with C
F_6.6.2.1.4
measurements), with UE in softer HO (2 legs) prior to hard HO
6.6.2.2 3G Handovers / inter-frequency handover / inter-nodeB handover

3G Handovers / inter-frequency handover / inter-nodeB handover D
F_6.6.2.2.1
(blind)
3G Handovers / inter-frequency handover / inter-nodeB handover (with D
F_6.6.2.2.2
3G Handovers / inter-frequency handover / inter-nodeB handover D
F_6.6.2.2.3
3G Handovers / inter-frequency handover / inter-nodeB handover (with D
F_6.6.2.2.4
6.6.2.3 3G Handovers / inter-frequency handover / inter-RNC handover

F_6.6.2.3.1 3G Handovers / inter-frequency handover / inter-RNC handover (blind) E
3G Handovers / inter-frequency handover / inter-RNC handover (with E
F_6.6.2.3.2
3G Handovers / inter-frequency handover / inter-RNC handover E
F_6.6.2.3.3
3G Handovers / inter-frequency handover / inter-RNC handover (with E
F_6.6.2.3.4
3G Handovers / inter-frequency handover / Combined hard handover E,G
F_6.6.2.3.5
and SRNS relocation


6.6.2.4 3G Handovers / inter-frequency handover / inter-PLMN handover

F_6.6.2.4.1 3G Handovers / inter-frequency handover / inter-PLMN (blind) G
3G Handovers / inter-frequency handover / inter-PLMN (with G
F_6.6.2.4.2
measurements)
6.6.3 Compressed Mode

F_6.6.3.1 Compressed mode / GSM measurements F,G
F_6.6.3.2 Compressed mode / GSM measurements / Softer Handover F
F_6.6.3.3 Compressed mode / Inter-frequency measurements B.C
F_6.6.3.4 Compressed mode / Inter-frequency measurements / Softer Handover C
6.7 Inter System Mobility (incl.Cell re selection,

HHO)

F_6.7.1 Inter system handover to UTRAN/From GSM/Speech/Success F
Inter system handover to UTRAN/From GSM/Data/Same data F
F_6.7.2
rate/Success
Inter system handover to UTRAN/From GSM/Data/Data rate F
F_6.7.3 upgrading/Success
Inter system handover to UTRAN/ From GSM/Speech/Establishment/ F

F_6.7.4
Success
Inter system handover to UTRAN/From GSM/Speech/Blind F
F_6.7.5
HO/Success
F_6.7.6 Inter system handover to UTRAN/ From GSM/Speech/Failure F
F_6.7.7 Inter system 2G to 3G cell reselection in Idle Mode F,H
F_6.7.8 Inter system 2G to 3G cell reselection in Packet Transfer Mode F,H
F_6.7.9 Inter system 3G to 2G cell reselection in Idle Mode F,H
Inter system 3G to 2G cell reselection in Connected Mode (Cell_FACH F,H
F_6.7.10
state)
Inter system 3G to 2G cell reselection in Connected Mode (URA_PCH F
F_6.7.11
state)
Inter system 3G to 2G cell reselection in Connected Mode (Cell_PCH F
F_6.7.12
state)
Inter-RAT mobility / RRC connection reject Redirection to GSM F,G
F_6.7.13
(successful case)
Inter-RAT mobility / RRC connection reject Redirection to GSM F,G
F_6.7.14
(unsuccessful case)
Inter-RAT mobility / Handover to 2G during call establishment - F,G
F_6.7.15
Directed retry


Supplementary Services
No detailed descriptions included

F_6.8.1 Call Deflection (CD)
F_6.8.2.1 Call Forwarding (CF) Unconditional
F_6.8.2.2 Call Forwarding (CF) - Mobile Subscriber busy
F_6.8.2.3 Call Forwarding (CF) - No Reply
F_6.8.2.4 Call Forwarding (CF) - Mobile Subscriber unreachable
F_6.8.3 Call Holding (CH)
F_6.8.4 Call Waiting (CW)
F_6.8.5.1 Call Barring/Restriction (CB) - Bar All Outgoing Calls (BAOC)
Call Barring/Restriction (CB) Bar All International Outgoing Calls
F_6.8.5.2 (BAIC)
F_6.8.5.3 Call Barring/Restriction (CB) Bar All Incoming Calls
F_6.8.6.1 Call Number Identification Presentation (CLIP)
F_6.8.6.2 Call Number Identification Presentation Restriction (CLIR)
F_6.8.7.1 Multi-party Calls 3-Party Calls
F_6.8.7.2 Multi-party Calls 3-Party Calls with addition/Deletion of Members
F_6.6.8.2 Other Services - Unstructured Supplementary Services (USSD)
F_6.6.8.2 Other Services - Closed User Group (CUG)
Other Services - UE shall support the supplementary services listed
F_6.6.8.2 below
F_6.6.8.2 Other Services - User to User Signalling (UUS)
6.8 SMS

F_6.9.1 MT CS SMS in idle mode A,B,C,D,E,F
F_6.9.2 MT CS SMS during a voice call A,B,C,D,E,F
F_6.9.3 MT CS SMS during a CS data call A,B,C,D,E,F
F_6.9.4 MO CS SMS A,B,C,D,E,F
F_6.9.5 SMS on CS mode / Multiple SMS mobile originated / UE in idle mode A,B,C,D,E,F
SMS on CS mode / Multiple SMS mobile originated / UE in active A,B,C,D,E,F
F_6.9.6
mode
SMS on CS mode / Test of capabilities of simultaneously receiving a A,B,C,D,E,F
F_6.9.7
short message whilst sending a mobile originated short message
F_6.9.8 MT PS SMS A,B,C,D,E,F
F_6.9.9 MT PS SMS during a PS data call A,B,C,D,E,F
F_6.9.10 MO PS SMS A,B,C,D,E,F
F_6.9.11 MO PS SMS during a PS data call A,B,C,D,E,F
F_6.9.12 SMS on PS mode / Test of capabilities of simultaneously receiving a A,B,C,D,E,F



F_6.9.13 MT PS SMS during a voice call A,B,C,D,E,F
F_6.9.14 MT CS SMS during a PS data call A,B,C,D,E,F
F_6.9.15 MT PS SMS during a CS data call A,B,C,D,E,F
F_6.9.16 MO CS SMS during a PS data call A,B,C,D,E,F
F_6.9.17 Short message service cell broadcast A,B,C,D,E,F
6.9 UE Positioning Test Cases
General comments on UE positioning test cases:
1) Different positioning methods can be configured by the network in order to determine the UEs
position, depending on UE capabilities: OTDOA, GPS, cell ID. This document only covers the
GPS-based method.
2) According to 3GPP, all RRC states are applicable for UE positioning measurement reports.
3) The UE positioning measurement reports can be triggered for different reasons. The request
to position the UE can come from: an external LCS client via the GMSC (MT-LR), the network
(e.g. for Emergency calls NI-LR) or the UE (MO-LR).
4) There are many different possible uses for the positioning information. The positioning
functions may be used internally by the UTRAN, by value-added network services, by the UE
itself or through the network, and by "third party" services. The feature may also be used by
an emergency service (which may be mandated (FCC rule in US) or "value-added"), but the
location service is not exclusively for emergencies.
5) 3GPP references: TS23.171 and TS25.305, TS24.030, TS24.080
6.9.1 UE positioning / UE based A-GPS test cases
UE based A-GPS method refers to the case where the UE position calculation is performed by the UE
to locate itself. It requires handsets to be equipped with a full GPS receiver function.

UE positioning / UE based A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.1.1
Request (MT-LR) in idle mode
UE positioning / UE based A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.1.2
Request (MT-LR) in cell_DCH
UE positioning / UE-based A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.1.3 Request (MT-LR) using location notification (LR goes through after no
response from user)
UE positioning / UE based A-GPS / Network Induced Location Request A,B,C,D,E
F_6.10.1.4
(NI-LR) / Emergency Call
F_6.10.1.5 UE positioning / UE based A-GPS / GPS assistance data not sufficient A,B,C,D,E
UE positioning / UE based A-GPS / Mobile Origination Location A,B,C,D,E
F_6.10.1.6
Request (MO-LR) in idle mode
UE positioning / UE based A-GPS / Mobile Origination Location A,B,C,D,E
F_6.10.1.7
Request (MO-LR) in cell_DCH
6.9.2 UE positioning / UE assisted A-GPS test cases


UE assisted A-GPS method refers to the case where the UE position calculation is performed by the
network. It requires that the wireless network infra-structure be equipped with some reference GPS
receiver that can simultaneously see the same satellites as the handset.

UE positioning / UE assisted A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.2.1
Request (MT-LR) in idle mode
UE positioning / UE assisted A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.2.2
Request (MT-LR) in cell_DCH
UE positioning / UE-assisted A-GPS / Mobile Terminated Location A,B,C,D,E
F_6.10.2.3 Request (MT-LR) using location notification (LR goes through after no
response from user)
UE positioning / UE Assisted A-GPS / Network Induced Location A,B,C,D,E
F_6.10.2.4
Request (NI-LR) / Emergency Call
UE positioning / UE Assisted A-GPS / GPS assistance data not A,B,C,D,E
F_6.10.2.5
sufficient
UE positioning / UE Assisted A-GPS / Mobile Origination Location A,B,C,D,E
F_6.10.2.6
Request (MO-LR) in idle mode
UE positioning / UE assisted A-GPS / Mobile Origination Location A,B,C,D,E
F_6.10.2.7
Request (MO-LR) in cell_DCH
6.9.3 UE positioning / Test cases that apply to both UE-based and UE-assisted
A-GPS

UE positioning / General / Mobile Terminated Location Request (MT- A,B,C,D,E
F_6.10.3.1
LR) using location notification (permission is denied)
UE positioning / General / Mobile Terminated Location Request (MT- A,B,C,D,E
F_6.10.3.2
LR) using location notification (no response from user)
6.10 Ciphering

F_6.11.1 CS - Ciphering of SRB at Location update A,B,C,D,E
F_6.11.2 CS - Ciphering at CS voice call setup A,B,C,D,E
F_6.11.3 PS - Ciphering of SRB at Routing area update A,B,C,D,E
F_6.11.4 PS - Ciphering at PS data session setup A,B,C,D,E
CS+PS - Ciphering after addition of a CS call to a PS session - mixed A,B,C,D,E
F_6.11.5
addition and release
CS+PS - Ciphering after addition of a PS session to a CS call mixed A,B,C,D,E
F_6.11.6
addition and release


6.11 HSDPA
6.11.1 Basic Session Setup and Termination

F_6.12.1.1 Successful establishment of HS-DSCH PS session A, B, C, D,
E, F, G
F_6.12.1.2 Successful termination of HS -DSCH PS session A, B, C, D,
E, F, G
6.11.2 Session Setup and Termination with Active CS Call

F_6.12.2.1 Successful establishment of HS-DSCH PS session then CS call A, B, C, D,
E, F, G
F_6.12.2.2 Successful establishment of CS call then HS -DSCH PS session A, B, C, D,
E, F, G
F_6.12.2.3 Successful termination of HS -DSCH PS session and keep DCH AMR/ A, B, C, D,
CSD call active E, F, G
F_6.12.2.4 Successful termination of DCH AMR/ CSD call and keep the HS -DSCH A, B, C, D,
PS session active E, F, G
6.11.3 Establishment of HS-DSCH when in Soft Handover

Successful PS call establishment of HS-DSCH when in SHO with on- B, C, D, E
F_6.12.3.1
going CS
6.11.4 Mobility between 2 HSDPA cells (serving HS-DSCH cell change)

F_6.12.4.1 Intra-NodeB serving HS-DSCH cell change / PS only B, C
F_6.12.4.2 Inter-NodeB serving HS-DSCH cell change / PS only B, C
F_6.12.4.3 Inter-RNC (with IUR) serving HS-DSCH cell change / PS only B, C
F_6.12.4.4 Intra-NodeB serving HS-DSCH cell change / PS + CS B, C
F_6.12.4.5 Inter-NodeB serving HS-DSCH cell change / PS + CS B, C


6.11.5 Reconfigurations Between HS-DSCH and DCH and Vice-Versa
6.11.5.1 Reconfiguration from HS-DSCH to DCH PS only

F_6.12.5.1.1 Reconfiguration from HS-DSCH to DCH - PS only - intra-cell A, B, C, D, E
Reconfiguration from HS-DSCH to DCH - PS only - intra-sector - B, C, D, E
F_6.12.5.1.2
HSDPA on a separate frequency
Reconfiguration from HS-DSCH to DCH after active set update - PS B
F_6.12.5.1.3
only - intra-NodeB / inter-sector
Reconfiguration from HS-DSCH to DCH after active set update - PS C
F_6.12.5.1.4
only - intra-NodeB / inter-sector - HSDPA on a separate frequency
Reconfiguration from HS-DSCH to DCH after active set update - PS D
F_6.12.5.1.5
only - inter-NodeB
Reconfiguration from HS-DSCH to DCH after active set update - PS D
F_6.12.5.1.6
only - inter-NodeB - HSDPA on a separate frequency
Reconfiguration from HS-DSCH to DCH after active set update - PS E
F_6.12.5.1.7
only - inter-RNC with Iur
Reconfiguration from HS -DSCH to DCH after radio link removal PS D, E
F_6.12.5.1.8
only
Reconfiguration from HS-DSCH to DCH after active set update - PS E
F_6.12.5.1.9
only - inter-RNC with Iur - HSDPA on a separate frequency
Reconfiguration from HS-DSCH to DCH - PS only - inter-RNC without E
F_6.12.5.1.10
Iur (separate frequencies)
6.11.5.2 Reconfiguration from DCH to HS-DSCH PS only

F_6.12.5.2.1 Reconfiguration from DCH cell to HS -DSCH - PS only - Intra-cell A, B, C, D, E
Reconfiguration from DCH to HS-DSCH - PS only - intra-sector - B, C, D, E
F_6.12.5.2.2
Reconfiguration from DCH to HS-DSCH after active set update - PS B
F_6.12.5.2.3
only - intra-NodeB / inter-sector
Reconfiguration from DCH to HS -DSCH after active set update PS C
F_6.12.5.2.4
only - intra-NodeB / inter-sector - HSDPA on a separate frequency
Reconfiguration from DCH to HS-DSCH after active set update - PS D
F_6.12.5.2.5
only - inter-NodeB
Reconfiguration from DCH to HS-DSCH after active set update - PS D
F_6.12.5.2.6
only - inter-NodeB - HSDPA on a separate frequency
Reconfiguration from DCH to HS-DSCH after active set update - PS E
F_6.12.5.2.7
only - inter-RNC with Iur
Reconfiguration from DCH to HS-DSCH after active set update - PS E
F_6.12.5.2.8
only - inter-RNC with Iur - HSDPA on a separate frequency
Reconfiguration from DCH to HS-DSCH - PS only - inter-RNC without E
F_6.12.5.2.9


6.11.5.3 Reconfiguration from HS-DSCH to DCH CS +PS

F_6.12.5.3.1 Reconfiguration from HS-DSCH to DCH CS + PS - intra-cell A, B ,C, D, E
Reconfiguration from HS -DSCH to DCH CS + PS - intra-sector - B ,C, D, E
F_6.12.5.3.2
Reconfiguration from HS-DSCH to DCH after active set update CS
F_6.12.5.3.3
+PS - intra-NodeB / inter-sector
Reconfiguration from HS -DSCH to DCH after active set update - CS
F_6.12.5.3.4
+PS - intra-NodeB / inter-sector - HSDPA on a separate frequency
F_6.12.5.3.5
+PS - inter-NodeB
F_6.12.5.3.6
+PS - inter-NodeB - HSDPA on a separate frequency
Reconfiguration from HS -DSCH to DCH after active set update - CS E
F_6.12.5.3.7
+PS - inter-RNC with Iur
Reconfiguration from HS-DSCH to DCH after radio link removal - CS D, E
F_6.12.5.3.8
+PS
Reconfiguration from HS -DSCH to DCH after active set update - CS E
F_6.12.5.3.9
+PS - inter-RNC with Iur - HSDPA on a separate frequency
Reconfiguration from HS-DSCH to DCH - CS +PS - inter-RNC without E
F_6.12.5.3.10
Iur
6.11.5.4 Reconfiguration from DCH to HS-DSCH PS + CS

F_6.12.5.4.1 Reconfiguration from DCH to HS-DSCH - CS + PS - Intra-cell A, B, C, D, E
Reconfiguration from DCH to HS -DSCH - CS + PS - intra-sector, intra- B, C, D, E
F_6.12.5.4.2
cell - HSDPA on a separate frequency
Reconfiguration from DCH to HS -DSCH after active set update - CS
F_6.12.5.4.3
+PS - intra-NodeB / inter-sector
F_6.12.5.4.4
+PS - intra-NodeB / inter-sector - HSDPA on a separate frequency
F_6.12.5.4.5
+PS - inter-NodeB
F_6.12.5.4.6
+PS - inter-NodeB - HSDPA on a separate frequency
Reconfiguration from DCH to HS -DSCH after active set update - CS E
F_6.12.5.4.7
+PS - inter-RNC with Iur
Reconfiguration from DCH to HS -DSCH after active set update - CS E
F_6.12.5.4.8
+PS - inter-RNC with Iur - HSDPA on a separate frequency
Reconfiguration from DCH to HS-DSCH - CS +PS - inter-RNC without E
F_6.12.5.4.9
6.11.5.5 Transitions between single and multi-RAB

CS RB setup with active HS-DSCH reconfiguration from HS-DSCH to A, B, C, D, E
F_6.12.5.5.1
DCH


CS RB release in CS+PS on DCH reconfiguration from DCH to HS - A, B, C, D, E

F_6.12.5.5.2
DSCH
6.11.6 Transitions between cell_DCH and cell_FACH (start and stop of HS-
DSCH reception)

Normal transition from cell_DCH to cell_FACH and back to cell_DCH A, B, C, D, E
F_6.12.6.1
(stop-start HSDPA)
Normal transition from cell_DCH to cell_PCH and back to cell_DCH A, B, C, D, E
F_6.12.6.2
(stop-start HSDPA)
Normal transition from cell_DCH to URA_PCH and back to CELL_DCH A, B, C, D, E
F_6.12.6.3
(stop-start HSDPA)
6.11.7 Inter-frequency handovers

Inter-Frequency handover from HSDPA cell to another HSDPA cell B, C, D, E
F_6.12.7.1
with prior measurements on the target frequency
Inter-Frequency handover from HSDPA cell to another HSDPA cell B, C, D, E
F_6.12.7.2
without prior measurements on the target frequency
Inter-frequency handover to HSDPA cell, Compressed Mode with UE C, D, E
F_6.12.7.3
in softer HO (2 legs) prior to Hard Handover
Inter-Frequency handover from HSDPA cell to another HSDPA cell E
F_6.12.7.4
including SRNS relocation
Multi-Service: Inter-Frequency handover from HSDPA cell to another B, C, D, E
F_6.12.7.5
HSDPA cell with prior measurements on the target frequency
Multi-Service: Inter-Frequency handover from HSDPA cell to another B, C, D, E
F_6.12.7.6
HSDPA cell without prior measurements on the target frequency
Multi-Service: Inter-frequency handover to HSDPA cell, C, D, E
F_6.12.7.7 Compressed Mode with UE in softer HO (2 legs) prior to Hard
Handover
Multi-Service: Inter-Frequency handover from HSDPA cell to another E
F_6.12.7.8
HSDPA cell including SRNS relocation
6.11.8 Active Set Update of DCH with active HS-DSCH

F_6.12.8.1 Active Set Update in the presence of an active HS-DSCH / Soft D, E
handover on DCH / Addition of one radio link / PS only
handover on DCH / Deletion of one radio link / PS only
handover on DCH / Deletion of one radio link of serving cell / PS only


F_6.12.8.4 Active Set Update in the presence of an active HS-DSCH / Soft B, C

handover on DCH / Combined addition and deletion of a radio link / PS
only
6.11.9 Inter-RAT HO and cell re-selection

F_6.12.9.1 Inter-RAT Cell Change Order from UTRAN to F
GPRS/CELL_DCH/Success (stop of HS-DSCH reception)
F_6.12.9.2 Inter-RAT Cell Change Order from UTRAN to F
GPRS/CELL_DCH/Failure (Physical channel Failure, stop of HS -DSCH
reception)
F_6.12.9.3 Inter-RAT cell change order from UTRAN/To GPRS/CELL_FACH/No F
RAB established/Success
6.12 IMS
6.12.1 Session Initiation
6.12.1.1 Mobile originated Session Initiation Procedure

Successful mobile origination procedure mobile is not located in its A
IMS_SO_1
HPLMN Traffic class I/B
Successful mobile origination procedure mobile is not located in its A
IMS_SO_2
HPLMN Traffic class PS conversational
Unsuccessful mobile origination procedure Failure in termination A
IMS_SO_3
procedure
Unsuccessful mobile origination procedure Session abandoned or A
IMS_SO_4
resource failure
6.12.1.2 Mobile terminated Session Initiation Procedure

Successful Mobile Termination Procedure mobile is not located in its A
IMS_ST_1
HPLMN
Unsuccessful Mobile Termination Procedure due to UE-detected A
IMS_ST_2
failure/resource failure
IMS_ST_3 Unsuccessful Mobile Termination Procedure due to origination failure A
Unsuccessful Mobile Termination Procedure due Mobile termination, A
IMS_ST_4
roaming, terminal is out of radio coverage


6.12.2 Session Release
6.12.2.1 Mobile terminal initiated session release

A,B,C,D,E,F,
IMS_SR_1 Mobile terminal initiated session release
G,H
6.12.2.2 PSTN/ Network initiated session release

A,B,C,D,E,F,
IMS_SR_2 PSTN/ Network initiated session release
G,H
6.12.3 Registration and Authentication

IMS_REG_1 Successful initial registration
IMS_REG_2 Successful re-registration without authentication
IMS_REG_3 Successful re-registration with authentication
IMS_REG_4 Successful user initiated de-registration without authentication.
IMS_REG_5 Initial registration failure due to user authentication failure
IMS_REG_6 Registration failure due to network authentication failure
IMS_REG_7 Registration failure due to synchronization failure
IMS_REG_8 Registration failure User unknown or Roaming not allowed
IMS_REG_9 Registration failure due to authentication timer expiry (incomplete
authentication)
IMS_REG_10 Network initiated re-authentication
6.12.4 QoS Setup and Negotiation
6.12.4.1 Mobile Originated

Mobile Originating with Service-based Local Policy, without resource A
IMS_QoS_1
reservation protocol, only GPRS procedures
Mobile Originated sessions requesting the establishment of QoS A
IMS_QoS_2
preconditions and coordination with GPRS bearer level


6.12.4.2 Mobile Terminated

Mobile Termination, with Service-based Local Policy, without resource A
IMS_QoS_3
reservation protocol, only GPRS procedures
Mobile Terminated sessions requesting the establishment of QoS A
IMS_QoS_4
6.12.5 SIP Compression
6.12.5.1 SIP compression procedures at the UE

Compression of SIP requests and responses transmitted to the P-
IMS_SCU_1
CSCF
Decompression of SIP requests and responses received from the P-
IMS_SCU_2
CSCF
6.12.5.2 SIP compression procedures at the P-CSCF

Compression of SIP requests and responses transmitted to the P-
IMS_SCP_1
CSCF
Decompression of SIP requests and responses received from the P-
IMS_SCP_2
CSCF
6.12.6 Mobility and inter RAT
6.12.6.1 Handover and cell reselection, 3G band

IMS_MOB_1 Soft/Softer Handover while active IMS session ongoing C
Hard Handover inter-frequency intra-node B while active IMS session C
IMS_MOB_2
ongoing
Hard Handover inter-RNC (inter PLMN) while active IMS session G
IMS_MOB_3
ongoing
Soft/Softer Handover between HSDPA cell while active IMS session B or C
IMS_MOB_4
ongoing
IMS_MOB_5 Cell reselection while inactive IMS session ongoing: success B or C
Cell reselection while inactive IMS session ongoing: insufficient B or C
IMS_MOB_6
resources at destination
Cell reselection while inactive IMS session ongoing: change of IP B or C
IMS_MOB_7
address


6.12.6.2 Handover and cell reselection, Inter RAT

IMS_MOB_8 Hard Handover to 2G band while active IMS session ongoing F
IMS_MOB_9 Handover to 3G from 2G band while active IMS session ongoing F
IMS_MOB_10 Cell reselection while inactive IMS session ongoing: success F
Cell reselection while inactive IMS session ongoing: insufficient F
IMS_MOB_11
resources at destination
Cell reselection while inactive IMS session ongoing: change of IP F
IMS_MOB_12
address
6.12.7 Media Resources interaction
6.12.7.1 Direct interactions UE MRFC

IMS_MRI_1 SIP REFER method (session invitations with consultation.)
MRFC uses of information received from a UE (session invitations
IMS_MRI_2
without consultation.)
6.12.7.2 Interactions UE MRFC via the Ut interface

IMS_MRI_3 Management and configuration of MRF data through Ut interface
6.12.8 Location Services
6.12.8.1 Mobile Terminating Location Request during IMS session

LCS Mobile terminated location request/ UE-Based GPS/ During
IMS_LCS _MT_1
IMS session.
LCS Mobile terminated location request/ UE- Assisted GPS/
IMS_LCS_MT_2
During IMS session.


6.12.8.2 Mobile Terminating Location Request during IMS session Privacy aspect

LCS Mobile terminated location request/ UE-Assisted GPS/
IMS_LCS_MT_3 Privacy Verification/ Location Allowed if No Response during IMS
session.
LCS Mobile terminated location request/ UE-Based GPS/ Privacy
IMS_LCS_MT_4 Verification/ Location Not Allowed if No Response during IMS
connection.
6.12.8.3 Mobile Originating Location Request IMS session

LCS Mobile originated location request/ UE-Based GPS/ Position
IMS_LCS_MO_1
estimate request/ Success during IMS Session.
LCS Mobile originated location request/ UE-Assisted GPS/
IMS_LCS_MO_2
Position Estimate/ Success during IMS Session.
6.12.9 Stand-Alone Transactions
6.12.9.1 Registration transaction

IMS_SA _1 IMS registration procedure.
IMS_SA _3 IMS registration - connection failure, timeout procedure.
6.12.9.2 BYE Transactions

IMS_SA _4 Mobile initiated session release - BYE request
IMS_SA _5 BYE request - 481(Call/Transaction Does Not Exist)
IMS_SA _6 BYE request - 408 (Request Timeout)
IMS_SA _7 BYE request - timeout is returned by the client transaction
6.12.9.3 Messaging Transaction

IMS_SA _8 UE send MESSAGE request
UE send MESSAGE request
IMS_SA _9
- connection failure


6.12.9.4 OPTIONS Transaction

IMS_SA _10 UE initiated OPTIONS request
IMS_SA _11 Processing of OPTIONS Request - 486 (Busy Here).


7 Protocol Test Case List

This section gives a one-line description of each test case. The listed tests are based on the 3GPP
version Mar 2003 of the core specifications that relates to the Jun 2003 test specification.
Total number of test cases: 338
7.1 Idle Mode

PLMN selection of RPLMN, HPLMN, UPLMN and OPLMN; Manual A,B,C,D,E,F
B_6.1.1.1
mode
B_6.1.2.1 Cell reselection C
E_6.1.2.2 Cell reselection using Qhyst, Qoffset and Treselection B,C,D,E
HCS cell reselection using reselection timing parameters for the H C
E_6.1.2.4
criterion
E_6.1.2.6 Emergency calls C
B_6.1.2.9 Cell reselection using cell status and cell reservations C,D,E
7.2 Layer 2
Test Id. Description Config.

B_7.1.2.2.1 Correct application of Dynamic Persistence (FDD) A,B,C,D,E,F
B_7.1.2.3.1 Correct Selection of RACH parameters (FDD) A,B,C,D,E,F
E_7.1.11.1 Ciphering A,B,C,D,E,F
7.3 Radio

B_8.1.1.1 RRC / Paging for Connection in idle mode A,B,C,D,E,F
B_8.1.1.2 RRC / Paging for Connection in connected mode (CELL_PCH) A,B,C,D,E,F
B_8. 1.1.4 RRC / Paging for Notification in idle mode A,B,C,D,E,F
B_8.1.1.5 RRC / Paging for Notification in connected mode (CELL_PCH) A,B,C,D,E,F
B_8.1.1.7 RRC / Paging for Connection in connected mode (CELL_DCH) A,B,C,D,E,F
B_8.1.2.1 RRC / RRC Connection Establishment in CELL_DCH state: Success A,B,C,D,E,F
RRC / RRC Connection Establishment: Reject ("wait time" is not equal
E_8.1.2.4 B,C
to 0)
B_8.1.3.1 RRC / RRC Connection Release in CELL_DCH state: Successful A,B,C,D,E,F
RRC / RRC Connection Release using on DCCH in CELL_FACH state:
B_8.1.3.2 A,B,C,D,E,F
Successful
RRC / RRC Connection Release using on CCCH in CELL_FACH state:
E_8.1.3.3 A,B,C,D,E,F
Failure
RRC Connection Release in CELL_DCH state (Frequency band
B_8.1.3.6 A,B,C,D,E,F
modification): Success
B_8.1.5.1 RRC / UE Capability in CELL_DCH state: Success A,B,C,D,E,F
B_8.1.5.2 RRC / UE Capability in CELL_DCH state: Success after T304 timeout A,B,C,D,E,F


B_8.1.5.4 RRC / UE Capability in CELL_FACH state: Success A,B,C,D,E,F

B_8.1.9 RRC / Signalling Connection Release Request A,B,C,D,E,F
B_8.1.11 Signalling Connection Release (Invalid configuration) A,B,C,D,E,F
RRC / Radio Bearer Establishment for transition from CELL_DCH to
E_8.2.1.1 A,B,C,D,E,F
CELL_DCH: Success (Data integrity protection algorithm is not applied)
E_8.2.1.3 A,B,C,D,E,F
CELL_DCH: Failure (Unsupported configuration)
E_8.2.1.4 CELL_DCH: Failure (Physical channel Failure and successful reversion A,B,C,D,E,F
to old configuration)
B_8.2.1.8 A,B,C,D,E,F
CELL_FACH: Success
RRC / Radio Bearer Establishment for transition from CELL_FACH to
B_8.2.1.10 A,B,C,D,E,F
CELL_DCH: Success
RRC / Radio Bearer Establishment for transition from CELL_FACH to
B_8.2.1.16 A,B,C,D,E,F
CELL_FACH: Success
RRC / Radio Bearer Establishment from CELL_DCH to CELL_PCH:
B_8.2.1.19 A,B,C,D,E,F
Success
RRC / Radio Bearer Establishment from CELL_DCH to URA_PCH:
B_8.2.1.20 A,B,C,D,E,F
Success
RRC / Radio Bearer Establishment from CELL_DCH to URA_PCH:
B_8.2.1.21 A,B,C,D,E,F
Success
Radio Bearer Establishment for transition from CELL_DCH to
B_8.2.1.22 A,B,C,D,E,F
CELL_FACH (Frequency band modification): Success
Radio Bearer Establishment for transition from CELL_FACH to
B_8.2.1.23 A,B,C,D,E,F
CELL_DCH (Frequency band modification): Success
RRC / Radio Bearer Reconfiguration (Hard Handover) from CELL_DCH
B_8.2.2.1 B,C,D,E
to CELL_DCH: Success
RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH:
E_8.2.2.3 A,B,C,D,E,F
Failure (Physical channel failure and reversion to old configuration)
RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_FACH:
B_8.2.2.8 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_DCH:
B_8.2.2.10 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration from CELL_FACH to
B_8.2.2.17 A,B,C,D,E,F
CELL_FACH: Success
RRC / Radio Bearer Reconfiguration from CELL_FACH to
E_8.2.2.18 B,C,D,E
CELL_FACH: Success (Physical channel failure)
RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_PCH:
B_8.2.2.21 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration from CELL_DCH to URA_PCH:
B_8.2.2.22 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_PCH:
B_8.2.2.23 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration from CELL_FACH to URA_PCH:
B_8.2.2.24 A,B,C,D,E,F
Success
RRC / Radio Bearer Reconfiguration for transition from CELL_FACH to
E_8.2.2.25 CELL_DCH including modification of previously signalled CELL_DCH A,B,C,D,E,F
configuration
Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH: Success
E_8.2.2.26 A,B,C,D,E,F
(Incompatible Simultaneous Reconfiguration)
RRC / Radio Bearer Release for transition from CELL_DCH to
B_8.2.3.1 A,B,C,D,E,F
CELL_DCH: Success
RRC / Radio Bearer Release for transition from CELL_DCH to
B_8.2.3.7 A,B,C,D,E,F
CELL_FACH: Success
B_8.2.3.9 RRC / Radio Bearer Release for transition from CELL_FACH to A,B,C,D,E,F


CELL_DCH: Success
RRC / Radio Bearer Release for transition from CELL_FACH to
B_8.2.3.15 A,B,C,D,E,F
CELL_FACH: Success
B_8.2.3.18 RRC / Radio Bearer Release from CELL_DCH to CELL_PCH: Success A,B,C,D,E,F
B_8.2.3.19 RRC / Radio Bearer Release from CELL_DCH to URA_PCH: Success A,B,C,D,E,F
Radio Bearer Release for transition from CELL_DCH to CELL_FACH
B_8.2.3.20 A,B,C,D,E,F
(Frequency band modification): Success
Radio Bearer Release from CELL_DCH to CELL_PCH (Frequency
B_8.2.3.21 A,B,C,D,E,F
band modification): Success
RRC / Transport channel reconfiguration from CELL_DCH to
B_8.2.4.1 CELL_DCH (Hard handover to intra-frequency): Success with no B,C,D,E
transport channel type switching
E_8.2.4.5 A,B,C,D,E,F
CELL_DCH: Failure (Incompatible simultaneous reconfiguration)
B_8.2.4.7 A,B,C,D,E,F
CELL_FACH: Success
RRC / Transport channel Reconfiguration from CELL_DCH to
B_8.2.4.20 A,B,C,D,E,F
CELL_PCH: Success
Transport channel reconfiguration from CELL_FACH to CELL_DCH
B_8.2.4.25 A,B,C,D,E,F
B_8.2.5.1 RRC / Transport format combination Control in CELL_DCH: restriction A,B,C,D,E,F
RRC / Physical channel reconfiguration for transition from CELL_DCH
B_8.2.6.1 B,C,D,E
to CELL_DCH (Hard handover to another frequency): Success
E_8.2.6.2 to CELL_DCH (Hard handover to another frequency): Failure A,B,C,D,E,F
(Unsupported configuration)
E_8.2.6.3 to CELL_DCH (Hard handover to another frequency): Failure (Physical A,B,C,D,E,F
channel failure and reversion to old channel)
E_8.2.6.5 to CELL_DCH (Hard handover to another frequency): Failure A,B,C,D,E,F
(Incompatible simultaneous reconfiguration)
B_8.2.6.7 A,B,C,D,E,F
to CELL_FACH: Success
E_8.2.6.8 B,C
to CELL_FACH: Success (Physical channel failure)
RRC / Physical channel reconfiguration for transition from CELL_FACH
B_8.2.6.9 A,B,C,D,E,F
E_8.2.6.10 A,B,C,D,E,F
to CELL_DCH: Failure (Unsupported configuration)
E_8.2.6.11 to CELL_DCH: Failure (Physical channel failure and reversion to old A,B,C,D,E,F
configuration)
E_8.2.6.13 A,B,C,D,E,F
to CELL_DCH: Failure (Incompatible simultaneous reconfiguration)
B_8.2.6.19 RRC / Physical channel from CELL_DCH to CELL_PCH: Success A,B,C,D,E,F
Physical channel reconfiguration for transition from CELL_DCH to
B_8.2.6.25 A,B,C,D,E,F
Physical Channel Reconfiguration from CELL_DCH to CELL_PCH
B_8.2.6.26 A,B,C,D,E,F
Physical channel reconfiguration from CELL_FACH to CELL_PCH:
B_8.2.6.27 A,B,C,D,E,F
Success
B_8.3.1.1 RRC / Cell Update: cell reselection in CELL_FACH B,C,D,E
B_8.3.1.3 RRC / Cell Update: periodical cell update in CELL_FACH A,B,C,D,E,F
E_8.3.1.5 RRC / Cell Update: UL data transmission in URA_PCH A,B,C,D,E,F
E_8.3.1.9 RRC / Cell Update: re-entering of service area after T305 expiry and A,B,C,D,E,F


being out of service area

RRC / Cell Update: Radio Link Failure (T314>0, T315=0), CS RAB
E_8.3.1.18 B,C,D,E
established
E_8.3.1.28 Cell Update: Radio Link Failure (T314=0, T315>0), PS RAB B,C,D,E
Cell Update: re-entering of service area from URA_PCH after T316
E_8.3.1.31 B,C,D,E
expiry but before T317 expiry
B_8.3.2.1 RRC / URA Update: URA reselection B,C,D,E
B_8.3.2.2 RRC / URA Update: Periodical URA update A,B,C,D,E,F
E_8.3.3.1 RRC / UTRAN Mobility Information: Success E
B_8.3.4.1a RRC / Active set update in softer handover: Radio Link addition (FDD) B,C
B_8.3.4.1b RRC / Active set update in soft handover: Radio Link addition (FDD) D,E
B_8.3.4.2a RRC / Active set update in softer handover: Radio Link removal (FDD) B,C
B_8.3.4.2b RRC / Active set update in soft handover: Radio Link removal (FDD) D,E
RRC / Active set update in softer handover: Combined radio link
E_8.3.4.3a B,C
addition and removal (active set is not full) (FDD)
RRC / Active set update in soft handover: Combined radio link addition
E_8.3.4.3b D,E
and removal (active set is not full) (FDD)
B_8.3.7.1 Inter system handover from UTRAN/To GSM/Speech/Success F
Inter system handover from UTRAN/To GSM/Data/Same data
B_8.3.7.2 F
rate/Success
Inter system handover from UTRAN/To GSM/Data/Data rate down
E_8.3.7.3 F
grading/Success
Inter system handover from UTRAN/To
E_8.3.7.4 F
GSM/Speech/Establishment/Success
E_8.3.7.5 Inter system handover from UTRAN/To GSM/Speech/Failure F
Cell reselection if cell becomes barred or S<0; UTRAN to GPRS
B_8.3.9.1 F
(CELL_FACH)
Cell reselection if cell becomes barred or S<0; UTRAN to GPRS
E_8.3.9.2 F
(URA_PCH)
Inter-RAT cell change order from UTRAN/To
B_8.3.11.1 F
GPRS/CELL_DCH/Success
Inter-RAT cell change order from UTRAN/To
B_8.3.11.2 F
GPRS/CELL_FACH/Success
RRC / Measurement Control and Report: Intra-frequency measurement
B_8.4.1.1 B,C,D,E
for transition from idle mode to CELL_DCH state (FDD)
RRC / Measurement Control and Report: Inter-frequency measurement
B_8.4.1.2 B,C,D,E
for transition from idle mode to CELL_DCH state (FDD)
RRC / Measurement Control and Report: Intra-frequency measurement
E_8.4.1.5 C
for transition from CELL_DCH to CELL_FACH state (FDD)
RRC / Measurement Control and Report: Inter- frequency measurement
E_8.4.1.6 B,C,D,E
for transition from CELL_DCH to CELL_FACH state (FDD)
RRC / Measurement Control and Report: Intra- frequency measurement
E_8.4.1.7 C
for transition from CELL_FACH to CELL_DCH state (FDD)
RRC / Measurement Control and Report: Inter- frequency measurement
E_8.4.1.8 B,C,D,E
for transition from CELL_FACH to CELL_DCH state (FDD)
RRC / Measurement Control and Report: Cell forbidden to affect
E_8.4.1.14 C
reporting range (FDD)
7.4 Mobility Management

B_9.1 TMSI reallocation B,C,D,E


B_9.2.1 Authentication accepted A,B,C,D,E,F

E_9.2.2 Authentication rejected B,C,D,E
E_9.2.3 Authentication rejected by the UE (MAC code failure) A,B,C,D,E,F
E_9.2.4 Authentication reject by the UE (SQN failure) A,B,C,D,E,F
B_9.3.1.4.1 General Identification Test1 A,B,C,D,E,F
E_9.3.2 Handling of IMSI shorter than the maximum length A,B,C,D,E,F
B_9.4.1 Location updating / accepted B,C,D,E
E_9.4.2.1 Location updating / rejected / IMSI invalid B,C,D,E
Location updating / abnormal cases / Failure due to non-integrity B,C,D,E,F
E_9.4.3.5
protection
E_9.4.4 Location updating / release / expiry of T3240 B,C,D,E
B_9.4.5.3 Location updating / periodic normal / test 2 B,C,D,E
E_9.4.5.4.1 Location updating / periodic HPLMN search / UE waits time T B,C,D,E
E_9.4.5.4.2 Location updating / periodic HPLMN search / UE in manual mode B,C,D,E
E_9.4.6 Location updating / interworking of attach and periodic B,C,D,E
Location Updating / accept with replacement or deletion of Equivalent B,C,D,E
E_9.4.7
PLMN list
B_9.5.2 MM connection / establishment in security mode A,B,C,D,E,F
E_9.5.4 MM connection / establishment rejected A,B,C,D,E,F
E_9.5.6 MM connection / expiry T3230 A,B,C,D,E,F
E_9.5.7.1 MM connection / abortion by the network / cause #6 B,C,D,E
E_9.5.8.1 MM connection / follow-on request pending / test 1 A,B,C,D,E,F
7.5 Call Control

B_10.1.2.1.1 Outgoing call / U0 null state / MM connection requested A,B,C,D,E,F
E_10.1.2.2.1 Outgoing call / U0.1 MM connection pending / CM service rejected A,B,C,D,E,F
B_10.1.2.2.2 Outgoing call / U0.1 MM connection pending / CM service accepted A,B,C,D,E,F
B_10.1.2.3.1 Outgoing call / U1 call initiated / receiving CALL PROCEEDING A,B,C,D,E,F
B_10.1.2.3.2 Outgoing call / U1 call initiated / rejecting with RELEASE COMPLETE A,B,C,D,E,F
E_10.1.2.3.5 Outgoing call / U1 call initiated / receiving ALERTING A,B,C,D,E,F
E_10.1.2.3.6 Outgoing call / U1 call initiated / entering state U10 A,B,C,D,E,F
Outgoing call / U3 Mobile originating call proceeding / ALERTING A,B,C,D,E,F
B_10.1.2.4.1
received
Outgoing call / U3 Mobile originating call proceeding / CONNECT A,B,C,D,E,F
E_10.1.2.4.2
received
Outgoing call / U3 Mobile originating call proceeding / PROGRESS A,B,C,D,E,F
E_10.1.2.4.3
received without in band information
Outgoing call / U3 Mobile originating call proceeding / PROGRESS with A,B,C,D,E,F
B_10.1.2.4.4
in band information
Outgoing call / U3 Mobile originating call proceeding / DISCONNECT A,B,C,D,E,F
E_10.1.2.4.5
with in band tones
Outgoing call / U3 Mobile originating call proceeding / DISCONNECT A,B,C,D,E,F
B_10.1.2.4.6
without in band tones
Outgoing call / U3 Mobile originating call proceeding / RELEASE A,B,C,D,E,F
E_10.1.2.4.7
received
Outgoing call / U3 Mobile originating call proceeding / termination A,B,C,D,E,F
E_10.1.2.4.8
requested by the user
B_10.1.2.5.1 Outgoing call / U4 call delivered / CONNECT received A,B,C,D,E,F


E_10.1.2.5.2 Outgoing call / U4 call delivered / termination requested by the user A,B,C,D,E,F
E_10.1.2.5.3 Outgoing call / U4 call delivered / DISCONNECT with in band tones A,B,C,D,E,F
E_10.1.2.5.4 Outgoing call / U4 call delivered / DISCONNECT without in band tones A,B,C,D,E,F
E_10.1.2.5.5 Outgoing call / U4 call delivered / RELEASE received A,B,C,D,E,F
B_10.1.2.5.7 Outgoing call / U4 call delivered / traffic channel allocation A,B,C,D,E,F
B_10.1.2.6.1 U10 active / termination requested by the user A,B,C,D,E,F
E_10.1.2.6.2 U10 active / RELEASE received A,B,C,D,E,F
E_10.1.2.6.3 U10 active / DISCONNECT with in band tones A,B,C,D,E,F
E_10.1.2.6.4 U10 active / DISCONNECT without in band tones A,B,C,D,E,F
E_10.1.2.6.5 U10 active / RELEASE COMPLETE received A,B,C,D,E,F
E_10.1.2.6.6 U10 active / SETUP received A,B,C,D,E,F
B_10.1.2.7.2 U11 disconnect request / RELEASE received A,B,C,D,E,F
B_10.1.2.9.4 Outgoing call / U19 release request / RELEASE COMPLETE received A,B,C,D,E,F
Incoming call / U9 mobile terminating call confirmed / alerting or A,B,C,D,E,F
B_10.1.3.3.1
immediate connecting
E_10.1.3.3.2 Incoming call / U9 mobile terminating call confirmed / DTCH assignment A,B,C,D,E,F
Incoming call / U9 mobile terminating call confirmed / termination A,B,C,D,E,F
E_10.1.3.3.3
requested by the user
Incoming call / U9 mobile terminating call confirmed / DISCONNECT A,B,C,D,E,F
E_10.1.3.3.4
received
Incoming call / U9 mobile terminating call confirmed / RELEASE A,B,C,D,E,F
E_10.1.3.3.5
received
B_10.1.3.4.1 Incoming call / U7 call received / call accepted A,B,C,D,E,F
B_10.1.3.4.2 Incoming call / U7 call received / termination requested by the user A,B,C,D,E,F
E_10.1.3.4.3 Incoming call / U7 call received / DISCONNECT received A,B,C,D,E,F
E_10.1.3.4.4 Incoming call / U7 call received / RELEASE received A,B,C,D,E,F
E_10.1.3.4.8 Incoming call / U7 call received / RELEASE COMPLETE received A,B,C,D,E,F
B_10.1.3.5.1 Incoming call / U8 connect request / CONNECT acknowledged A,B,C,D,E,F
B_10.1.3.5.8 Incoming call / U8 connect request / DTCH assignment A,B,C,D,E,F
E_10.1.4.1.1 In-call functions / DTMF information transfer / base procedures A,B,C,D,E,F
B_10.1.4.2.1 In-call functions / User notification / UE terminated A,B,C,D,E,F
E_10.3 User to user signalling A,B,C,D,E,F
7.6 Session Management

Attach initiated by context activation/QoS Offered by Network is the
B_11.1.1.1 A,B,C,D,E,F
QoS Requested
E_11.1.1.2.1 QoS offered by the network is a lower QoS / QoS accepted by UE A,B,C,D,E,F
E_11.1.1.2.2 QoS offered by the network is a lower QoS / QoS rejected by UE A,B,C,D,E,F
PDP context activation requested by the network, successful and
B_11.1.2 A,B,C,D,E,F
unsuccessful
E_11.1.3.1 Abnormal Cases / T3380 Expiry A,B,C,D,E,F
Successful secondary PDP context activation procedure initiated by the
B_11.1.4.1.1 A,B,C,D,E,F
UE/QoS Offered by Network is the QoS Requested
Unsuccessful Secondary PDP Context Activation Procedure Initiated by
E_11.1.4.2 A,B,C,D,E,F
the UE
B_11.2.1 Network initiated PDP context modification A,B,C,D,E,F
UE initiated PDP context modification/UE initiated PDP context
B_11.2.2.1 A,B,C,D,E,F
modification accepted by network
E_11.2.2.2 UE initiated PDP context modification/UE initiated PDP context A,B,C,D,E,F

modification not accepted by network

B_11.3.1 PDP context deactivation initiated by the UE A,B,C,D,E,F
B_11.3.2 PDP context deactivation initiated by the network A,B,C,D,E,F
7.7 Packet Switched Mobility Management

B_12.2.1.1 PS attach / accepted A,B,C,D,E,F
E_12.2.1.2 PS attach / rejected / IMSI invalid / illegal UE B,C,D,E
E_12.2.1. 4 PS attach / rejected / PLMN not allowed C
E_12.2.1.5a PS attach / rejected / roaming not allowed in this location area C
E_12.2.1.10 PS attach / abnormal cases / Failure due to non-integrity protection A,B,C,D,E,F
B_12.2.2.1 Combined PS attach / PS and non-PS attach accepted A,B,C,D,E,F
E_12.2.2.2 Combined PS attach / PS only attach accepted A,B,C,D,E,F
B_12.2.2.3 Combined PS attach / PS attach while IMSI attach A,B,C,D,E,F
E_12.2.2.6 Combined PS attach / rejected / PS services not allowed B,C,D,E
E_12.2.2.7a Combined PS attach / rejected / location area not allowed C
E_12.3.1.1 PS detach / power off / accepted A,B,C,D,E,F
B_12.3.1.2 PS detach / accepted A,B,C,D,E,F
B_12.3.1.5 PS detach / powered off / accepted / PS/IMSI detach A,B,C,D,E,F
E_12.3.1.7 PS detach / accepted / IMSI detach A,B,C,D,E,F
B_12.3.2.3 PS detach / IMSI detach / accepted A,B,C,D,E,F
E_12.3.2.4 PS detach / re-attach requested / accepted A,B,C,D,E,F
B_12.4.1.1 Routing area updating / accepted B,C,D,E
E_12.4.2.1 Combined routing area updating / combined RA/LA accepted B,C,D,E
E_12.4.2.2 Combined routing area updating / UE in CS operation at change of RA B,C,D,E
E_12.4.2.3 Combined routing area updating / RA only accepted B,C,D,E
B_12.4.3.1 Periodic routing area updating / accepted A,B,C,D,E,F
B_12.5 P-TMSI reallocation A,B,C,D,E,F
B_12.6.1.1 Authentication accepted B,C,D,E
E_12.6.1.2 Authentication rejected - by the network B,C,D,E
E_12.6.1.3.1 GMM cause MAC failure B,C,D,E
B_12.7.1 General Identification A,B,C,D,E,F
B_12.9.1 Service Request Initiated by UE Procedure A,B,C,D,E,F
B_12.9.2 Service Request Initiated by Network Procedure A,B,C,D,E,F
E_12.9.7a Service Request / rejected / No PDP context activated A,B,C,D,E,F
Service Request / RAB re-establishment / UE initiated / Single PDP A,B,C,D,E,F
E_12.9.12
context
Service Request / RAB re-establishment / UE initiated / multiple PDP A,B,C,D,E,F
E_12.9.13
contexts
Service Request / RAB re-establishment / Network initiated / single PDP A,B,C,D,E,F
E_12.9.14
context
7.8 General Tests

B_13.2.1.1 Emergency call / with USIM / accept case A,B,C,D,E,F
B_13.2.2.1 Emergency call / without USIM / accept case A,B,C,D,E,F


B_13.2.2.2 Emergency call / without USIM / reject case A,B,C,D,E,F


7.9 Radio Bearer Services
7.9.1 Combinations on DPCH

B_14.2.1 Stand-alone UL:1.7 DL:1.7 kbps SRBs for DCCH A,B,C,D,E,F
Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + UL:3.4
B_14.2.4 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH
Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9
B_14.2.4a A,B,C,D,E,F
4.75) kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
B_14.2.5 A,B,C,D,E,F
Conversational / speech / UL:(10.2, 6.7, 5.9, 4.75) DL:(10.2, 6.7, 5.9,
B_14.2.5a A,B,C,D,E,F
4.75) kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
B_14.2.6 A,B,C,D,E,F
Conversational / speech / UL:7.4 DL:7.4 kbps / CS RAB+ UL:3.4 DL:3.4
B_14.2.7 A,B,C,D,E,F
kbps SRBs for DCCH
Conversational / speech / UL:(7.4, 6.7, 5.9, 4.75) DL:(7.4, 6.7, 5.9, 4.75)
B_14.2.7a A,B,C,D,E,F
kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
B_14.2.8 A,B,C,D,E,F
B_14.2.9 A,B,C,D,E,F
B_14.2.10 A,B,C,D,E,F
B_14.2.11 A,B,C,D,E,F
Conversational / unknown / UL:28.8 DL:28.8 kbps / CS RAB + UL:3.4
B_14.2.12 A,B,C,D,E,F
Conversational / unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4
B_14.2.13.1 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH / 20 ms TTI
B_14.2.13.2 A,B,C,D,E,F
B_14.2.14.1 A,B,C,D,E,F
B_14.2.14.2 A,B,C,D,E,F
Streaming / unknown / UL:14.4/DL:14.4 kbps / CS RAB + UL:3.4 DL:3.4
B_14.2.15 A,B,C,D,E,F
kbps SRBs for DCCH
B_14.2.16 A,B,C,D,E,F
kbps SRBs for DCCH
B_14.2.17 A,B,C,D,E,F
kbps SRBs for DCCH
Interactive or background / UL:32 DL:8 kbps / PS RAB + UL:3.4 DL:3.4
B_14.2.23.1 A,B,C,D,E,F
kbps SRBs for DCCH / (TC, 10 ms TTI)
B_14.2.23.2 A,B,C,D,E,F
B_14.2.23.3 A,B,C,D,E,F
kbps SRBs for DCCH / (CC, 10 ms TTI)
B_14.2.23.4 A,B,C,D,E,F



B_14.2.23a.1 A,B,C,D,E,F
kbps SRBs for DCCH / CC
B_14.2.23a.2 A,B,C,D,E,F
kbps SRBs for DCCH / TC
Interactive or background / UL:16 DL:16 kbps / PS RAB + UL:3.4
B_14.2.23b A,B,C,D,E,F
B_14.2.23c A,B,C,D,E,F
Interactive or background / UL:32 DL:32 kbps / PS RAB (20 ms TTI) +
B_14.2.23d A,B,C,D,E,F
UL:3.4 DL:3.4 kbps SRBs for DCCH
Interactive or background / UL:32 DL: 64 kbps / PS RAB + UL:3.4
B_14.2.25.1 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH / (TC, 10 ms TTI)
B_14.2.25.2 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH / (TC, 20 ms TTI)
B_14.2.25.3 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH / (CC, 10 ms TTI)
B_14.2.25.4 A,B,C,D,E,F
DL:3.4 kbps SRBs for DCCH / (CC, 20 ms TTI)
B_14.2.26 A,B,C,D,E,F
B_14.2.27 A,B,C,D,E,F
B_14.2.28 A,B,C,D,E,F
Interactive or background / UL:64 DL:144 kbps / PS RAB + UL:3.4 DL:
B_14.2.29 A,B,C,D,E,F
3.4 kbps SRBs for DCCH
B_14.2.30 A,B,C,D,E,F
3.4 kbps SRBs for DCCH
B_14.2.31.1 A,B,C,D,E,F
3.4 kbps SRBs for DCCH /10 ms TTI
B_14.2.31.2 A,B,C,D,E,F
3.4 kbps SRBs for DCCH /20 ms TTI
B_14.2.32.1 A,B,C,D,E,F
3.4 kbps SRBs for DCCH / 10 ms TTI
B_14.2.32.2 A,B,C,D,E,F
3.4 kbps SRBs for DCCH / 20 ms TTI
B_14.2.33.1 A,B,C,D,E,F
B_14.2.33.2 A,B,C,D,E,F
B_14.2.34.1 A,B,C,D,E,F
B_14.2.34.2 A,B,C,D,E,F
B_14.2.35.1 A,B,C,D,E,F
B_14.2.35.2 A,B,C,D,E,F



Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive
B_14.2.38.1 or background / UL:32 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs A,B,C,D,E,F
for DCCH / (TC, 20 ms TTI
for DCCH / (TC, 10 ms TTI
for DCCH / (CC, 10 ms TTI
for DCCH / (CC, 20 ms TTI
B_14.2.38a or background / UL:0 DL:0 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs A,B,C,D,E,F
for DCCH.
B_14.2.38b or background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs A,B,C,D,E,F
for DCCH.
B_14.2.38c or background / UL:32 DL:32 kbps / PS RAB + UL:3.4 DL:3.4 kbps A,B,C,D,E,F
SRBs for DCCH.
or background / UL:64 DL:64 kbps / PS RAB + Interactive or
B_14.2.38d A,B,C,D,E,F
background / UL:64 DL:64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH.
B_14.2.38e 4.75) kbps / CS RAB + Interactive or background / UL:0 DL:0 kbps / PS A,B,C,D,E,F
RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
B_14.2.38f 4.75) kbps / CS RAB + Interactive or background / UL:8 DL:8 kbps / PS A,B,C,D,E,F
B_14.2.38g 4.75) kbps / CS RAB + Interactive or background / UL:16 DL:16 kbps / A,B,C,D,E,F
PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
B_14.2.38h 4.75) kbps / CS RAB + Interactive or background / UL:32 DL:32 kbps / A,B,C,D,E,F
B_14.2.38i 4.75) kbps / CS RAB + Interactive or background / UL:64 DL:64 kbps / A,B,C,D,E,F
B_14.2.38j 4.75) kbps / CS RAB + Interactive or background / UL:64 DL:128 kbps / A,B,C,D,E,F
B_14.2.39.1 or background / UL:32 DL:64 kbps / PS RAB+ UL:3.4 DL: 3.4 kbps A,B,C,D,E,F
SRBs for DCCH / (TC, 10 ms TTI)



SRBs for DCCH / (TC, 20 ms TTI)
SRBs for DCCH / (CC, 10 ms TTI)
SRBs for DCCH / (CC, 20 ms TTI)
B_14.2.40 or background / UL:64 DL:64 kbps / PS RAB+ UL:3.4 DL: 3.4 kbps A,B,C,D,E,F
SRBs for DCCH
B_14.2.41 or background / UL:64 DL:128 kbps / PS RAB + UL:3.4 DL:3.4 kbps A,B,C,D,E,F
SRBs for DCCH
B_14.2.42.1 or background / UL:64 DL:256 kbps / PS RAB + UL:3.4 DL:3.4 kbps A,B,C,D,E,F
SRBs for DCCH / 10ms TTI
B_14.2.42.2 or background / UL:64 DL:256 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH / 20 ms TTI
Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Streaming
B_14.2.45 / unknown / UL:57.6 DL:57.6 kbps / CS RAB + UL:3.4 DL:3.4 kbps A,B,C,D,E,F
SRBs for DCCH
Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB +
B_14.2.49 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4 A,B,C,D,E,F
Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL(12.2 7.95 5.9
B_14.2.49a 4.75) kbps / CS RAB + Conversational / unknown / UL:64 DL:64 kbps / A,B,C,D,E,F
CS RAB+ UL:3.4 DL: 3.4 kbps SRBs for DCCH (20ms TTI)
Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL(12.2 7.95 5.9
B_14.2.49a.1 4.75) kbps / CS RAB + Conversational / unknown / UL:64 DL:64 kbps / A,B,C,D,E,F
CS RAB+ UL:3.4 DL: 3.4 kbps SRBs for DCCH (40ms TTI)
Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB
B_14.2.49.1 A,B,C,D,E,F
Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI
Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB +
B_14.2.49.2 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4 A,B,C,D,E,F



Conversational / unknown / UL:64 DL:64 kbps / CS RAB +
B_14.2.50 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4 A,B,C,D,E,F
Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI +
B_14.2.51.1 Interactive or background / UL:64 DL:64 kbps / PS RAB + UL:3.4 A,B,C,D,E,F
B_14.2.51a.1 Interactive or Background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 A,B,C,D,E,F
kbps SRBs for DCCH
B_14.2.51a.2 Interactive or Background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 A,B,C,D,E,F
kbps SRBs for DCCH
B_14.2.51b.1 Interactive or Background / UL:16 DL:64 kbps / PS RAB + UL:3.4 A,B,C,D,E,F
B_14.2.51b.2 Interactive or Background / UL:16 DL:64 kbps / PS RAB + UL:3.4 A,B,C,D,E,F
Interactive or background / UL:8 DL:8 kbps / PS RAB + Interactive or
B_14.2.56 background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for A,B,C,D,E,F
DCCH
Interactive or background / UL:64 DL:64 kbps / PS RAB + Interactive or
B_14.2.57 background / UL:64 DL:64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs A,B,C,D,E,F
for DCCH
Streaming / unknown / UL:16 DL:64 kbps / PS RAB + Interactive or
B_14.2.58 background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for A,B,C,D,E,F
DCCH


7.9.2 Combinations on PDSCH and DPCH

Interactive or background / UL:64 DL:384 kbps / PS RAB / 10 ms TTI +
B_14.3.2.1 A,B,C,D,E,F
UL:3.4 DL: 3.4 kbps SRBs for DCCH
Interactive or background / UL:64 DL:384 kbps / PS RAB / 20 ms TTI +
B_14.3.2.2 A,B,C,D,E,F
UL:3.4 DL: 3.4 kbps SRBs for DCCH
Interactive or background / UL:64 DL:2048 kbps / PS RAB / 10 ms TTI
B_14.3.3.1 A,B,C,D,E,F
+ UL:3.4 DL: 3.4 kbps SRBs for DCCH
Interactive or background / UL:64 DL:2048 kbps / PS RAB / 20 ms TTI
B_14.3.3.2 A,B,C,D,E,F
+ UL:3.4 DL: 3.4 kbps SRBs for DCCH
SRBs for DCCH
B_14.3.5.2 or background / UL:64 DL:384 kbps / PS RAB / 20 ms TTI + UL:3.4 A,B,C,D,E,F
SRBs for DCCH
B_14.3.6.2 or background / UL:64 DL:2048 kbps / PS RAB / 20 ms TTI + UL:3.4 A,B,C,D,E,F
7.9.3 Combinations on SCCPCH

B_14.4.1 Stand- alone signalling RB for PCCH A,B,C,D,E,F
One SCCPCH: Interactive/Background 32 kbps PS RAB + SRBs for
B_14.4.2.1 A,B,C,D,E,F
CCCH + SRB for DCCH + SRB for BCCH
Two SCCPCHs: Interactive/Background 32 kbps PS RAB + SRBs for
B_14.4.2.2 A,B,C,D,E,F
One SCCPCH/connected mode: Interactive/Background 32 kbps PS
B_14.4.2.3 A,B,C,D,E,F
RAB + SRBs for CCCH + SRB for DCCH + SRB for BCCH
One SCCPCH: Interactive/Background 32 kbps PS RAB +
B_14.4.2a1 Interactive/Background 32 kbps PS RAB + SRBs for CCCH + SRB for A,B,C,D,E,F
DCCH + SRB for BCCH
Two SCCPCHs: Interactive/Background 32 kbps PS RAB +
B_14.4.2a2 Interactive/Background 32 kbps PS RAB + SRBs for CCCH + SRB for A,B,C,D,E,F
DCCH + SRB for BCCH
One SCCPCH/connected mode: Interactive/Background 32 kbps PS
B_14.4.2a3 RAB + Interactive/Background 32 kbps PS RAB + SRBs for CCCH + A,B,C,D,E,F
SRB for DCCH + SRB for BCCH
Interactive/ Background 32 kbps RAB + SRBs for PCCH + SRB for
B_14.4.3 A,B,C,D,E,F
B_14.4.4 RB for CTCH + SRB for CCCH +SRB for BCCH A,B,C,D,E,F


7.9.4 Combinations on PRACH

Interactive/Background 32 kbps PS RAB + SRB for CCCH + SRB for
B_14.5.1 A,B,C,D,E,F
DCCH
Interactive/Background 32 kbps PS RAB + Interactive/Background 32
B_14.5.2 A,B,C,D,E,F
kbps PS RAB + SRB for CCCH + SRB for DCCH
7.10 Supplementary Services

TBD
7.11 SMS

B_16.1.1 SMS on CS mode / SMS mobile terminated A,B,C,D,E,F
B_16.1.2 SMS on CS mode / SMS mobile originated A,B,C,D,E,F
E_16.1.9.1 SMS on CS mode / Multiple SMS mobile originated / UE in idle mode A,B,C,D,E,F
E_16.1.9.2 SMS on CS mode / Multiple SMS mobile originated / UE in active mode A,B,C,D,E,F
SMS on CS mode / Test of capabilities of simultaneously receiving a
E_16.1.10 A,B,C,D,E,F
B_16.2.1 SMS on PS mode / SMS mobile terminated A,B,C,D,E,F
B_16.2.2 SMS on PS mode / SMS mobile originated A,B,C,D,E,F
SMS on PS mode / Test of capabilities of simultaneously receiving a
E_16.2.10 A,B,C,D,E,F
E_16.3 Short message service cell broadcast A,B,C,D,E,F
7.12 Inter system hard handover from GSM to UTRAN

B_60.1 Inter system handover to UTRAN/ From GSM/Speech/Success F
Inter system handover to UTRAN/ From GSM/Data/Same data
B_60.2 F
rate/Success
Inter system handover to UTRAN/ From GSM/Data/Data rate
B_60.3 F
upgrading/Success
Inter system handover to UTRAN/ From
E_60.4 F
Inter system handover to UTRAN/ From GSM/Speech/Blind
B_60.5 F
HO/Success
E_60.6 Inter system handover to UTRAN/ From GSM/Speech/Failure F


8 Functional test cases
F_6.1.1.1 UE location update following switch on (normal case)
Test Purpose:
To verify that UE is able to register on an authorized NW, and to verify that NW is able to affect a
TMSI to a UE.
Pre-requisites:
Configuration: A,B, C, D, E, F.
One cell A
IMSI attach/detach is allowed on cell A.
UE has been previously registered on the same cell (UE has a valid TMSI (=TMSI1)
UE is switch off.
UE in automatic PLMN selection mode.
Test Procedure:
Switch on UE.
A normal location updating with TMSI is performed in cell A.
The RRC CONNECTION is released
Test Verification:
Verify that UE is able to select RPLMN first.

Verify that NW is able to keep the same TMSI if still valid.
Message Flow:
Step Direction Message Comments

UE NW
1 RRC CONNECTION REQUEST "Establishment cause": Registration.
2 RRC CONNECTION SETUP Target RRC state is either cell_DCH or
cell_FACH.
3 RRC CONNECTION SETUP
COMPLETE
4 LOCATION UPDATING REQUEST "location updating type" = normal, "CKSN" =
CKSN1, "location area identification" = a,
"mobile station class mark 1" and "mobile
identity" = TMSI1.
5 AUTHENTICATION REQUEST* * Optional
6 AUTHENTICATION ACCEPT* * Optional
7 SECURITY MODE COMMAND
8 SECURITY MODE COMPLETE
9 LOCATION UPDATING ACCEPT "Mobile identity" = old TMSI (=TMSI1), LAI =
a.
Or no mobile identity (NW dependant)
10 RRC CONNECTION RELEASE
COMPLETE


Remarks:
Note that in step 2, the SRNC can either put the UE in cell_DCH or cell_FACH. The test report shall
indicate which one was tested.
Protocols tests related:

Test ID Protocol test case
1 B_6.1.1.1 PLMN selection of RPLMN, HPLMN, UPLMN and OPLMN; Manual mode
2a B_8.1.2.1 RRC / RRC Connection Establishment in CELL_DCH state: Success
2b Not mapped RRC/RRC Connection Establishment in CELL_FACH state: Success
3 B_9.5.2 MM connection / establishment in security mode
4 B_9.2.1 Authentication accepted
5 B_9.4.1 Location updating / accepted
6a B_8.1.3.1 RRC / RRC Connection Release in CELL_DCH state: Successful
6b RRC / RRC Connection Release using on DCCH in CELL_FACH state:
B_8.1.3.2
Successful


F_6.1.1.2 UE changing of LA
Test Purpose:
To verify that UE is able to perform a location update procedure when detecting a change in LA after a
cell reselection.
To verify that network is able to perform a location update procedure.
Pre-requisites:
Configuration: D, E.
Two cells: A and B, belonging to different location areas a and b
The UE has a valid TMSI. It is "idle updated" on cell A.
Test Procedure:
Make cell B more suitable for UE in order to force a cell reselection.

A normal location updating with TMSI is performed in cell A .
Test Verification:
Verify that UE is able to reselect correctly cell B.

Verify that UE performs a location update procedure.
Verify that NW allocates a new TMSI to UE.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = TMSI1.
9 LOCATION UPDATING ACCEPT "Mobile identity" = TMSI2, LAI = b.
10 TMSI REALLOCATION COMPLETE

COMPLETE
Remarks:



1 B_6.1.2.1 Cell reselection
B_8.1.3.2
Successful


F_6.1.1.3 Periodic location update
Test Purpose:
To verify that UE and network are able to perform a periodic location update procedure after timing
expiry.
Pre-requisites:
Configuration: A,B,C,D, E,F.

One cells: A
The UE has a valid TMSI stored. UE is switch off.
Periodic location update is activated.
T3212 is set to the minimum allowed by network (suggestion : 6 minutes)
Test Procedure:
Power on UE, and wait for the location update procedure.

Wait for the expiry of T3212
A periodic location updating with TMSI is performed in cell A..
Test Verification:
Verify that UE performs a location update procedure.

Verify that a periodic location is performed at timer expiry.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = TMSI1.
a.Or no mobile identity (NW dependant)
COMPLETE
Wait for the expiry of T3212
cell_FACH.
COMPLETE



UE NW
16 LOCATION UPDATING REQUEST "location updating type" = periodic.
a.Or no mobile identity (NW dependant)
COMPLETE
Remarks:
Note that in steps 2 and 14, the SRNC can either put the UE in cell_DCH or cell_FACH. The test
report shall indicate which one was tested.

6 B_9.4.5.3 Location updating / periodic normal / test 2
B_8.1.3.2
Successful


F_6.1.1.4 UE location update following switch on (IMSI invalid)
Test Purpose:
To verify that UE is able to manage reject causes during a location update.
Pre-requisites:
One cell A
IMSI stored in USIM is not registered in HLR of NW, no TMSI stored.
UE is switch off.
Test Procedure:
Switch on UE.
A normal location updating with IMSI is performed in cell A.
NW reject the location updating with cause IMSI invalid.
Test Verification:
Verify that UE enter a limited state and is not able to initiate any CS action (except emergency call)
until power off.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = IMSI.
5 LOCATION UPDATING REJECT Reject cause = 2 (IMSI unknown in HLR)
COMPLETE
Remarks:



4 B_9.4.2.1 Location updating / rejected / IMSI invalid
B_8.1.3.2
Successful


F_6.1.1.5 UE location update following switch on (PLMN not allowed)
Test Purpose:
Pre-requisites:
One cell A
HPLMN on USIM different of PLMN of NW. No roaming allowed.
UE is switch off.
Test Procedure:
Switch on UE.
NW reject the location updating with cause PLMN not allowed.
Test Verification:
Verify that UE consider PLMN as forbidden and update field into USIM.
Verify that UE dont perform any location update procedure on NW except if manual mode selected
and if user try a location on forbidden PLMN.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = IMSI.
5 LOCATION UPDATING REJECT Reject cause = 11 (PLMN not allowed)
COMPLETE
Remarks:



4 Missing test for protocol error 11
B_8.1.3.2
Successful


F_6.1.1.6 UE location update following switch on (service not subscribed)
Test Purpose:
Pre-requisites:
One cell A
CS services not subscribed in HLR.
UE is switch off.
Test Procedure:
Switch on UE.
NW reject the location updating with cause service not subscribed.
Test Verification:
Verify that UE consider SIM as not suitable for CS services.

Verify that UE dont perform any location update procedure on NW..
Eventually verify that UE is able to perform PS services.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = IMSI.
5 LOCATION UPDA TING REJECT Reject cause = (service not subscribed)
COMPLETE
Remarks:



4 Missing test for protocol error
B_8.1.3.2
Successful


F_6.1.1.7 Location update accepted (TMSI unknown)
Test Purpose:
To verify that UE is able to register on an authorized NW, and to verify that NW is able to affect a
TMSI to a UE.
Pre-requisites:
One cell A
UE has been previously registered on the same cell but TMSI has been deleted on NW..
UE is switch off.
Test Procedure:
Switch on UE.
A normal location updating with TMSI is performed in cell A.
The RRC CONNECTION is released.
Test Verification:
Verify that UE is able to select RPLMN first.

Verify that NW is able to keep the same TMSI if still valid.
Message Flow:

UE NW
cell_FACH.
COMPLETE
identity" = TMSI.
5 IDENTITY REQUEST "Identity type" IE is IMSI.
6 IDENTITY RESPONSE "Mobile identity" IE specifies the IMSI of the
UE.
7 AUTHENTICATION REQUEST
8 AUTHENTICATION ACCEPT
11 LOCATION UPDATING ACCEPT "Mobile identity" = TMSI2, LAI = b.

COMPLETE


Remarks:

4 Missing test for protocol error
B_8.1.3.2
Successful


F_6.1.1.8 Location update following LA change during CS call
Test Purpose:
To verify that UE is able to delay location update to the end of CS call if LA has change during call.
Pre-requisites:
Two cells A and B belonging to different LA.
A CS call is established on cell A.
Test Procedure:
Radio conditions are then changed so that cell 2 satisfies the criterion to perform handover.
Release call.
Test Verification:
Verify that UE dont perform any location update procedure during call.
Verify that location update procedure is perform after call has been released.
Message Flow:

UE NW
1 MEASUREMENT REPORT (DCCH) UE sends intra-frequency measurements, as
requested by UTRAN.
The tester modifies radio conditions
according to step 2 in the test procedure.
2 MEASUREMENT REPORT (DCCH) UE returns intra-frequency measurements, as
requested by UTRAN.
handover decision Made by the RNC
3 ACTIVE SET UPDATE (DCCH) RRC
4 ACTIVE SET UPDATE COMPLETE RRC
(DCCH)
5 DISCONNECT (CC) UE requests the NW to clear the end-to-end
connection
6 RELEASE (CC) NW intends to release the transaction
identifier, and that the receiving equipment
shall release the transaction identifier after
the Release complete.
7 RELEASE COMPLETE (CC)
8 RRC CONNECTION RELEASE To release the RRC connection
COMPLETE
cell_FACH.
COMPLETE
identity" = TMSI1.



UE NW
a.
Or no mobile identity (NW dependant)
COMPLETE
Remarks:

B_8.1.3.2
Successful


F_6.1.2.1 MS PS attach following switch on (successful case)
Test Purpose:
The purpose of this test is to verify the attach procedure used by a UE to attach for PS services.
Reference: 3GPP TS 24.008 section 4.7.3.1.
Pre-requisites:
Configurations: A, B, C, D, E, F
The UE has a valid IMSI or P-TMSI
Test procedure:
Power on UE. If attach is not performed at power on, it should by triggered by MMI or AT commands.
Test Verification:
Verify that the monitored message sequence is correct.

Message Flow:

UE NW
1 RRC CONNECTION Establishment cause = registration
REQUEST
cell_FACH.
COMPLETE
4 ATTACH REQUEST Type of attach=GPRS attach
5 IDENTITY REQUEST*
6 IDENTITY RESPONSE*
7 AUTHENTICATION AND
CIPHERING REQUEST*
CIPHERING RESPONSE*
9 SECURITY MODE COMMAND Mobile starts integrity protection (and
activates ciphering if requested)
10 SECURITY MODE
COMPLETE
11 ATTACH ACCEPT Attach result = PS only attached
Mobile identity = P-TMSI (new/old)
P-TMSI signature = P-TMSI signature
(new/old)
12 ATTACH COMPLETE* Mandatory, when new p-TMSI is allocated
13 RRC CONNECTION
RELEASE**
14 RRC CONNECTION
RELEASE COMPLETE**


Remarks:
Depending on Network configuration and the Mobile identity used, messages marked with * are
optional.
Messages marked with ** may not appear depending on FOR flag in attach request message:
FOR = NO FOLLOW-ON REQUEST PENDING: Network shall release the RRC
Connection. Mobile shall move into IDLE state.
FOR = FOLLOW-ON REQUEST PENDING: Network shall keep RRC connection
established. Mobile shall remain in CELL_DCH/CELL/FACH state.
If the Mobile identity in the ATTACH ACCEPT message as a P-TMSI new to the UE, the UE will
acknowledge this P-TMSI by sending ATTACH COMPLETE message.
Protocol test cases used:

2 B_12.2.1.1 PS attach / accepted
3 B_12.7.1 General Identification
4 B_12.6.1.1 Authentication accepted
5 Not mapped Security Mode procedure
B_8.1.3.2
Successful
NOTE:
New protocol test case/s must be added (5, 1b)


F_6.1.2.2 MS PS attach following switch on (unsuccessful case IMSI unknown in HLR)
Test Purpose:
The purpose of this test is to verify the Attach procedure when the network rejects a PS attach
request.
Reference: 3GPP TS 24.008 section 4.7.3.1
Pre-requisites:
UE/CN configuration must be changed in order to trigger the failure scenario (i.e. IMSI not present
in HLR, PLMN stored in USIM not allowed, etc)
Test Procedure:
Power on UE. If attach is not performed at power on, it should by triggered by MMI or AT commands
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLETE
4 ATTACH REQUEST Type of attach {GPRS attach}
5 IDENTITY REQUEST*
7 ATTACH REJECT GMM CAUSE: IMSI unknown in HLR
8 RRC CONNECTION
RELEASE
9 RRC CONNECTION
RELEASE COMPLETE
Remarks:
optional.
After step 13, mobile should not attempt to perform another attach procedure unless initial
conditions change (i.e. not forbidden PLMN is selected manually in the UE)



2 E_12.2.1.2 PS attach / rejected / IMSI invalid / illegal UE
B_8.1.3.2
Successful
NOTES:
New protocol test case/s must be added (1b)


F_6.1.2.3 MS PS attach following switch on (unsuccessful case PLMN not allowed)
Test Purpose:
request.
Pre-requisites:
UE/CN configuration must be changed in order to trigger the failure scenario (i.e. USIM PLMN not
allowed in HLR, etc)
Test Procedure:
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLETE
5 IDENTITY REQUEST*
7 ATTACH REJECT GMM CAUSE: PLMN not allowed
8 RRC CONNECTION
RELEASE
9 RRC CONNECTION
RELEASE COMPLETE
Remarks:
optional.
It has to be checked, that the network PLMN is listed in the forbidden PLMN list on the USIM.



2 E_12.2.1.4 PS attach / rejected / PLMN not allowed
B_8.1.3.2
Successful
NOTES:


F_6.1.2.4 MS PS attach following switch on (unsuccessful case GPRS service not allowed)
Test Purpose:
request.
Pre-requisites:
UE/CN configuration must be changed in order to trigger the failure scenario (i.e. the GPRS
service is not subscribed etc.)
Test Procedure:
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLE TE
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
9 SECURITY MODE Mobile starts integrity protection (and
COMMAND* ciphering if requested)
10 SECURITY MODE
COMPLETE*
11 ATTACH REJECT GMM CAUSE: GPRS service not allowed
12 RRC CONNECTION
RELEASE
13 RRC CONNECTION
RELEASE COMPLETE
Remarks:
optional.

conditions change (i.e. the USIM is not valid anymore for GPRS services)

2 Not mapped PS attach / rejected / GPRS Services not allowed
B_8.1.3.2
Successful
NOTES:
New protocol test case/s must be added (1b, 5)


F_6.1.2.5 MS PS attach following switch on (unsuccessful cases Authentication rejected)
Test Purpose:
request.
Pre-requisites:
UE/CN configuration must be changed in order to trigger the failure scenario (i.e. wrong
authentication keys, etc)
Test Procedure:
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLETE
5 IDENTITY REQUEST*
CIPHERING REQUEST
CIPHERING RESPONSE
CIPHERING REJECT
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
Remarks:
optional.


3 E_12.6.1.2 Authentication rejected - by the network
B_8.1.3.2
Successful
NOTES:


F_6.1.2.6 MS combined PS/CS attach following switch on. PS only attach accepted.
Test Purpose:
The purpose of this test is to verify the combined PS/CS attach procedure, when it is completed
successfully.
Pre-requisites:
UE is configured to performed combined PS/CS attach at power on.
The Network is operating in Network Mode of Operation 1.
CN is configured so that CS attach will not succeed.
Test Procedure:
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLETE
4 ATTACH REQUEST Type of attach: Combined PS / IMSI attach
5 IDENTITY REQUEST*
CIP HERING REQUEST*
CIPHERING RESPONSE*
10 SECURITY MODE
COMPLETE
11 ATTACH ACCEPT Attach result = {PS only attached}
(new/old)
Mobile identity = TMSI (new/old)
GMM cause = 'MSC temporarily not
reachable', 'Network failure' or
'Congestion' (arbitrarily chosen)


UE NW
12 ATTACH COMPLETE*
13 RRC CONNECTION
RELEASE**
14 RRC CONNECTION
RELEASE COMPLETE**
Remarks:
optional.
established. Mobile shall remain in CELL_DCH state.
If the ATTACH ACCEPT message contains a Mobile identity P-TMSI new to the UE, the UE will
acknowledge this P-TMSI by sending ATTACH COMPLETE message.
The UE will try to attach the CS domain five times.

2 E_12.2.2.2 Combined PS attach / PS only attach accepted
B_8.1.3.2
Successful
NOTES:


F_6.1.2.7 MS combined PS/CS attach following switch on. PS and non-PS attach accepted
Test Purpose:
The purpose of this test is to verify the combined PS/CS attach procedure, when it is completed
successfully.
Pre-requisites:
UE is configured to performed combined PS/CS attach at power on.
The Network is operating in Network Mode of Operation 1.
Test Procedure:
Test Verification:

Message Flow:

UE NW
REQUEST
cell_FACH.
COMPLETE
4 ATTACH REQUEST Type of attach: Combined PS / IMSI attach
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
10 SECURITY MODE
COMPLETE
11 ATTACH ACCEPT Attach result = {Combined PS / IMSI
attached,}
(new/old)
Mobile identity = TMSI (new/old)
12 ATTACH COMPLETE*
13 RRC CONNECTION
RELEASE**


UE NW
14 RRC CONNECTION
RELEASE COMPLETE**
Remarks:
optional.
established. Mobile shall remain in CELL_DCH state.
If the ATTACH ACCEPT message contains a Mobile identity TMSI or P-TMSI new to the UE, the
UE will acknowledge this TMSI or P-TMSI by sending ATTACH COMPLETE message.

2 B_12.2.2.1 Combined PS attach / PS and non-PS attach accepted
B_8.1.3.2
Successful
NOTES:


F_6.1.2.8 Routing Area Update
Test Purpose:
The purpose of this Test Case is to verify that the Routing Area Update procedure is performed
correctly
Pre-requisites:
Configuration: B, C, D, E.
Two cells, Cell1 and Cell2, with different Routing Areas
The UE is attached for PS services
UE is in idle mode, camping in Cell1.
Test Procedure:
Change attenuation so that UE moves to Cell2 coverage.

Routing Area Update procedure should take place.
Test Verification:

Message Flow:
Step Direction Message Comment

UE NW
1 RRC CONNECTION REQUEST
2 RRC CONNECTION SETUP Target RRC state is either
cell_DCH or cell_FACH.
COMPLETE
4 ROUTING AREA UPDATING Update type = 'RA updating'
REQUEST P-TMSI signature
Routing area identity = RAI
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
11 ROUTING AREA UPDATING
ACCEPT
COMPLETE*
COMPLETE


Remarks:
optional.
If the Mobile identity in the ROUTING AREA UPDATING ACCEPT message is a P-TMSI new to
the UE, the UE will acknowledge this P-TMSI by sending ROUTING AREA UPDATING
COMPLETE message.
Note that in step 2, the SRNC can either put the UE in cell_DCH or cell_FACH. The test report
shall indicate which one was tested.
Test Id Test name

2a B_8. 1.2.1 RRC / RRC Connection Establishment in CELL_DCH state: Success
5 TBD Security mode procedure
6 B_12.4.1.1 Routing area updating / accepted
7a E_8. 1.3.1 RRC / RRC Connection Release in CELL_DCH state: Successful
B_8.1.3.2
Successful
NOTE:


F_6.1.2.9 Combined RA/LA Update, RA only
Test Purpose:
The purpose of this Test Case is to verify that the Combined RA/LA Update procedure is performed
correctly .
Pre-requisites:
Two cells, Cell1 and Cell2, in different Location Areas
Both cells operating in network operation mode I.
The UE is registered for PS services and CS services
CN is configured so that LA will not be completed.
Test Procedure:
Change RF condition so that UE moves to Cell2 coverage.

Combined RA/LA Update procedure should take place.
Test Verification:

Message Flow:

UE NW
2 RRC CONNECTION SETUP Target RRC state is either cell_DCH
or cell_FACH.
COMPLETE
4 ROUTING AREA UPDATING Update type = 'Combined RA/LA
REQUEST updating'
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
11 ROUTING AREA UPDATING Update result = { RA only
ACCEPT
COMPLETE*
COMPLETE


Remarks:
optional.
Test Id Protocol Test Case

6 E_12.4.2.3 Combined routing area updating / RA only accepted
B_8.1.3.2
Successful
NOTE:


F_6.1.2.10 Combined RA/LA Update, Combined RA/LA updated
Test Purpose:
The purpose of this Test Case is to verify that the Combined RA/LA Update procedure is performed
correctly
Pre-requisites:
Two cells, Cell1 and Cell2, in different Location Areas
The UE is registered for PS services and CS services
Test Procedure:
Change RF condition so that UE moves to Cell2 coverage.

Combined RA/LA Update procedure should take place.
Test Verification:

Message Flow:

UE NW
or cell_FACH.
COMPLETE
4 ROUTING AREA UPDATING Update type = 'Combined RA/LA
REQUEST updating'
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
11 ROUTING AREA UPDATING Update result = {Combined RA/LA
ACCEPT updated}
COMPLETE*
COMPLETE

Remarks:
optional.

6 E_12.4.2.1 Combined routing area updating / combined RA/LA accepted
B_8.1.3.2
Successful
NOTE:


F_6.1.2.11 Periodic RA update
Test Purpose:
The purpose of this Test Case is to verify that the Periodic RA Update procedure is performed
correctly .
Pre-requisites:
Configuration: A, B, C, D, E.
The UE is attached for PS services
UE is in idle mode
Timer T3312 is set to a known value (i. e. 6 minutes)
Test Procedure:
Wait until T3312 expires.

Periodic RA Update procedure should take place.
Test Verification:

Message Flow:

UE NW
or cell_FACH.
COMPLETE
4 ROUTING AREA UPDATING Update type = 'Periodic updating'
REQUEST
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
10 SECURITY MODE COMPLE TE
11 ROUTING AREA UPDATING Update result = 'RA updated'
ACCEPT
COMPLETE*
COMPLETE


Remarks:
optional.

6 E_12.4.3.1 Periodic routing area updating / accepted
B_8.1.3.2
Successful
NOTE:


F_6.1.2.12 Detach by power off
Test Purpose:
The purpose of this test is to verify the detach procedure when it is triggered by a UE power off.
Pre-requisites:
UE is previously attached for PS services
UE has a valid P-TMSI-1, P-TMSI-1 signature.
Test procedure:
Power off the UE: mobile should send a DETACH REQUEST message to the NW, and RRC
Connection is released.
Test Verification:

Message Flow:

UE NW
1 RRC CONNECTION Establishment cause= detach
REQUEST*
2 RRC CONNECTION SETUP* Target RRC state is either cell_DCH or
cell_FACH.
COMPLETE*
4 DETACH REQUEST Type of detach: {GPRS detach with
switching off / GPRS/IMSI detach with
switching off}
5 RRC CONNECTION
RELEASE
Remarks:
Messages marked with * will only appear if mobile has not an already opened RRC connection
(i.e. mobile has an active PDP context)

2 Not mapped Detach by power off
NOTES:


F_6.1.2.13 Detach without power off
Test Purpose:
The purpose of this test is to verify the detach procedure when it is not triggered by a UE power off.
Pre-requisites:
UE is previously attached for PS services
Test procedure:
A normal detach procedure is triggered through the UE MMI. The UE sends a DETACH
REQUEST message to the NW and detach procedure is completed.
Test Verification:

Message Flow:

UE NW
1 RRC CONNECTION Establishment cause= detach
REQUEST**
2 RRC CONNECTION SETUP** Target RRC state is either cell_DCH or
cell_FACH.
COMPLETE**
4 DETACH REQUEST Type of detach = {GPRS detach without
switching off / IMSI detach / Combined
GPRS/IMSI detach without switching off}
5 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
10 SECURITY MODE
COMPLETE
11 DETACH ACCEPT GPRS only detach add the other
outcomes
12 RRC CONNECTION
RELEASE
13 RRC CONNECTION
RELEASE COMPLETE


Remarks:
optional.
Messages marked with ** will only appear if mobile has not an already opened RRC
connection (i.e. mobile has an active PDP context)

2 B_12.3.1. 2 PS detach / accepted
2b B_12.3.1.6 PS detach / accepted / PS/IMSI detach
2c E_12.3.1.7 PS detach / accepted / IMSI detach
2d B_12.3.2.3 PS detach / IMSI detach / accepted
B_8.1.3.2
Successful
NOTES:
Protocol test case in second place can be 2 OR 2b OR 2c OR 2d



F_6.1.2.14 CN initiated detach
Test Purpose:
The purpose of this test is to verify CN initiated GPRS detach procedure (i.e. The subscriber is
cancelled in the HLR while a PDP context is active).
Pre-requisites:
UE is previously attached for PS services, and a PDP context is active.
Test procedure:
Detach procedure is triggered from CN (i.e. subscriber is cancelled in the HLR)

The CN sends a DETACH REQUEST message to the UE and detach procedure is completed.
Test Verification:

Message Flow:

UE NW
1 DETACH REQUEST Type of detach: {re-attach required, re-
attach not required}
Mobile identity: P_TMSI
2 DETACH ACCEPT GPRS only detach
3 RRC CONNECTION If re-attach was requested the RRC
RELEASE signalling connexion will not be released
and the CN waits for a new GPRS attach
message
4 RRC CONNECTION
RELEASE COMPLETE
Remarks:
When receiving the DETACH REQUEST message and the detach type IE indicates "re-attach not
required" or "re-attach required", the MS shall implicitely deactivate the PDP. The UE shall
then send a DETACH ACCEPT message to the network. The UE shall, after the completion of
the GPRS detach procedure, initiate a GPRS attach procedure if indicated by the network in
the detach type IE.
If detach type indicates re-attach not required, CN shall start RRC connection release.

1 E_12.3.2.4 PS detach / re-attach requested / accepted
2 B_8.1.3.1 RRC / RRC Connection Release in CELL_DCH state: Successful


F_6.1.2.15 S-RNS Relocation
Test Purpose:
The purpose of this procedure is to check that the UTRAN to CN connection point can be moved at
the UTRAN side from the source RNC to the target.
Reference: 3GPP TS 23.060 section 6.9.2.
Pre-requisites:
Configuration: E.
2 RNC.
Iur interface.
UE in PMM-CONNECTED state.
Test Procedure:
The UE moves out of the Source RNC coverage area. Source SRNC takes the decision of moving
the UTRAN to CN connection point at the UTRAN side to a Target SRNC, i.e., the Iu links are
relocated. The Target SRNC is also chosen by the Source SRNC.
The Target RNC sends to the UE a UTRAN MOBILITY INFORMATION message incluiding a new
U-RNTI (UTRAN Radio Network Temporary Identity) containing new SNRC and S-RNTI. The UE
answers with a UTRAN MOBILITY INFORMATION CONFIRM message.
Test Verification:
To verify that the monitored message sequence is correct.
Message Flow:
UE NW
1 UTRAN MOBILITY Incluiding a new U-RNTI
INFORMATION
2 UTRAN MOBILITY
INFORMATION CONFIRM

1 E_8.3.3.1 UTRAN Mobility Information: Success


F_6.1.2.16 URA Update: Change of URA
Test purpose:
To verify the procedure to update UTRAN with the current URA of the UE after a change of URA has
occurred in URA_PCH state. It may also be used for supervision of the RRC connection, even if no
change of URA takes place.
Reference: 3GPP TS 25.331 clause 8.3.1
Pre-requisites:
Configurations: B, C, D, E
Network: 2 cells - Cell 1 with URA-ID 1 and cell 2 active with URA-ID 2
UE is in URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108, with URA -ID 1 from the
list of URA-ID in cell 1
Test Procedure:
Change RF condition so that UE selects Cell2.
URA Update procedure should take place.
Test verification:
Message flow:

UE NW
1 URA UPDATE The UE shall perform a cell
reselection first and when it
finds that its current URA -
ID 1 is not in the newly
broadcasted list of URA -
IDs, it shall then transmit
this message and set value
"change of URA" into IE
"URA update cause".
2 URA UPDATE CONFIRM Message comprises IE
"RRC State Indicator" set
"URA_PCH", and also IE
"URA Identity" equals to
"URA-ID 2".
Remarks:
After step 1, the UE shall find that URA-ID 2 is not in its maintained list of URA-IDs. After cell
reselection, the UE shall move to CELL_FACH state and transmit URA UPDATE message setting
value "change of URA" into IE "URA update cause".

2 B_8.3.2.1 URA Update: Change of URA


F_6.1.2.17 URA Update: Periodical URA
Test purpose:
To verify the procedure to update UTRAN with the current URA of the UE when the UE detects that it
is still within the service area after the expiry of periodic URA updating timer T305.
Pre-requisites:
Network: 1 cell
UE: URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108.
Set T305 to a value other than infinity.
Test Procedure:
Wait until the expiry of timer T305, set according to the value specified in system information
The UE moves to CELL_FACH state and transmits a URA UPDATE message to the network on the
uplink CCCH.
Network replies with an URA UPDATE CONFIRM message sent on downlink CCCH.
Test verification:
Message flow:

UE NW
1 The UE is in URA_PCH
state. Tester wait until T305
timer has expired.
2 URA UPDATE UE shall transmit this
message and set value
periodic URA update into
IE URA update cause.
3 URA UPDATE CONFIRM
Remarks:
After step 1 the UE shall detect the expiry of timer T305, move to CELL_FACH state, and transmit a
URA UPDATE message which is set the value periodical cell update into IE URA update cause.

1 B_8.3.2.2 URA Update: Periodical URA


F_6.1.2.18 URA Update: re-entering of service area after T305 expiry
Test Purpose:
To verify the procedure to execute an URA update procedure when the UE re-enters the service area
before the expiry of timer T307, after being out of service area at the expiry of timer T305.
Pre-requisites:
Configuration: B, C, D, E
Network: 1 cell with URA-ID 1
UE: URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108, with URA-ID 1
in the list of URA -ID.
Set T305 to a value other than infinity.
Test Procedure:
Modify downlink attenuation to leave the UE out or coverage.

At the expiry of the timer T305, the UE is still out of the service area .
Modify downlink attenuation to restore coverage. The UE shall detect that it returns to
normal service before T307 expires.
The UE shall move to CELL_FACH state and starts transmitting a URA UPDATE
message which contains the value " periodical URA update " in IE "URA update
cause" to the NW on the uplink CCCH.
After the NW receives this message, it transmits a URA UPDATE CONFIRM message
which includes the IE "new C-RNTI", and "new U-RNTI" to the UE on the downlink
DCCH.
Then the UE shall transmit an UTRAN MOBILITY INFORMATION CONFIRM message on the
uplink DCCH.
Test Verification:
Message Flow:

UE NW
1 URA UPDATE Value " periodical URA
update " shall be set in IE
"URA update cause"
2 URA UPDATE CONFIRM The message includes IEs
"new C-RNTI" , and "new
U-RNTI"
3 UTRAN MOBILITY INFORMATION

CONFIRM


Remarks:
The UE shall transmit a URA UPDATE message which sets value " periodical URA update " into IE
"URA update cause".
After step 2 the UE shall transmit an UTRAN MOBILITY INFORMATION CONFIRM message on the
uplink DCCH.

1 E_8.3.2.3 URA Update: re-entering of service area after T305 expiry


F_6.1.2.19 Routing Area Update performed after a PS Call
Test Purpose:
correctly after a PS Call in connected mode.
Pre-requisites:
UE is attached.
UE is in connected mode, camping in Cell 1.
PDP Context activated.
Both routing areas are in the same location area.
Test Procedure:
Change attenuation so that UE moves to Cell with a different Routing Area.

PDP Context deactivated
Test Verification:
Make sure that after the PS call in connected mode is ended a Routing Area Update was performed.
Message Flow:

UE NW
UE Initiate PDP context
deactivation
1 DEACTIVATE PDP CONTEXT Request a PDP deactivation
REQUEST
2 DEACTIVATE PDP CONTEXT Accept PDP context
ACCEPT deactivation
4 RRC CONNECTION RELEASE Target RRC state is either

cell_DCH or cell_FACH
5 RRC CONNECTION RELEASE .
COMPLETE
RRC CONNECTION REQUEST
RRC CONNECTION SETUP Target RRC state is either
COMPLETE
8 IDENTITY REQUEST*

CIPHERING REQUEST*
CIPHERING RESPONSE*
ACCEPT
COMPLETE*
COMPLETE
Remarks:
optional.
If the Mobile identity in the ROUTING AREA UPDATING ACCEPT message is a P-TMSI new to the
UE, the UE will acknowledge this P-TMSI by sending ROUTING AREA UPDATING COMPLETE
message.
Covered protocol tests:
Test Id Test name

1 B_11.3.1 PDP context deactivation initiated by the UE
15 E_8. 1.3.1 RRC / RRC Connection Release in CELL_DCH state: Successful
16 RRC / RRC Connection Release using on DCCH in CELL_FACH
B_8.1.3.2
state: Successful


F_6.1.2.20 Routing Area Update performed after a combined Call
Test Purpose:
correctly after a combined Call
Pre-requisites:
The UE has a PS and CS call in cell 1.
Both routing areas are in the same location area.
Test Procedure:
Change the radio condition, so that the UE moves to the other routing area in cell 2.
End both CS and PS call.
Test Verification:
Make sure that after the combined call is ended a Routing Area Update is performed.
Message Flow:

UE NW
UE Voice call released
1 DISCONNECT (CC) UE requests the NW to clear
the end-to-end connection
2 RELEASE (CC) NW intends to release the
transaction identifier, and that
the receiving equipment shall
release the transaction
identifier after the Release
complete.
UE Initiate PDP context

deactivation
6 DEACTIVATE PDP CONTEXT Request a PDP deactivation
REQUEST
7 DEACTIVATE PDP CONTEXT Accept PDP context
ACCEPT deactivation
8 RRC CONNECTION RELEASE Target RRC state is either
COMPLETE
RRC CONNECTION REQUEST
RRC CONNECTION SETUP Target RRC state is either


COMPLETE
12 IDENTITY REQUEST*
CIPHERING REQUEST*
CIPHERING RESPONSE*
ACCEPT
COMPLETE*
COMPLETE
Remarks:
optional.
If the Mobile identity in the ROUTING AREA UPDATING ACCEPT message is a P-TMSI new to the
UE, the UE will acknowledge this P-TMSI by sending ROUTING AREA UPDATING COMPLETE
message.
Test Id Test name

2 B_8.1.3.1 RRC/ RRC Connection Release in Cell_DCH state: Success
4 E_10.1.2.6.2 U10 call active / RELEASE received
5 E_10.1.2.6.5 U10 call active / RELEASE COMPLETE received
6 B_11.3.1 PDP context deactivation initiated by UE
8 B_14.2.x All suitable RABs can be used for this test
21b RRC / RRC Connection Release using on DCCH in CELL_FACH
B_8.1.3.2
state: Successful


F_6.1.2.21 Cell reselection intra frequency (UE is idle mode):
Test Purposes:
Test to verify that the UE performs the cell reselection intra frequency procedure correctly.
Note: All cell reselection parameters are properly set on the net work side to perform the successful
completion of the cell reselection.
The protocol aspects are tested in B_6.1.2.1, E_6.1.2.2 and E_6.1.2.4
Pre-requisites:
Configuration: C
Cell 1and cell 3 are on the same frequency
Cell environment is described in SIB11
Test Procedure:
a) The NW activates Cell 1-3. Increase the attenuation on Cell 3.

b) Switch on the UE. UE selects cell 1 and performs CS registration and PS attach (for auto-
attach UEs)
c) RF conditions are changed so that cell 3 is becoming better than the cell1.

d) UE should reselect Cell 3
Test Verification:
To verify from the UE traces it has performed a cell reselection and not a cell selection.
From UE trace, make sure that:
Intra frequency measurements were triggered
S criteria was met
Ranking process selects the best cell
Message Flow:
Direction Message Comments

UE NW
System information UE reads system information from NW.
Remarks:
Depending on the network configuration, if LAI or RAI is different on the target cell from the
initial cell, the UE will trigger a Location update procedure or Routing Area update procedure.
Test ID Protocol Test case

2 E_6.1.2.2 Cell reselection using Qhyst, Qoffset and Treselection
3 F_6.1.1.2 UE changing of LA
4 F_6.1.2.8 Routing Area Update


F_6.1.2.22 Cell re-selection inter-frequency inta-nodeB/ inter sector (UE is idle mode):
Test Purposes:
Test to verify that the UE performs the cell reselection procedure correctly.
Note: All cell reselection parameters are properly set on the network side to perform the successful
completion of the cell reselection procedure.
The protocols aspects are tested in B_6.1.2.1, E_6.1.2.2 and E_6.1.2.4
Pre-requisites:
Configuration: C
Cell 1and cell 3 are emitting on different frequencies
Test Procedure:
a) The NW activates Cell 1-3. Increase the attenuation on Cell 3.

b) Switch on the UE. UE selects cell 1 and performs CS registration and PS attach (for auto-
attach UEs)
c) RF conditions are changed so that cell 3 is becoming better than the cell1.
d) UE should reselect Cell 3
Test Verification:
Verify from the UE traces it has performed a cell reselection and not a cell selection.
From UE trace, make sure that:
Intra frequency measurements were triggered
S criteria was met
Ranking process selects the best cell
Message Flow:

UE NW
Remarks:
Depending on the network configuration, if LAI or RAI is different on the target cell from the
source cell , the UE will trigger a Location update procedure or Routing Area update procedure.



F_6.1.2.23 Cell re-selection between inter-frequency and inter RAT cells (UE is idle mode):
Test Purposes:
Test to verify that the UE performs the cell reselection on the proper cell among the inter RAT and
Inter frequency according parameter broadcasted in SIB3 and SIB 11.
Note: All cell reselection parameters are properly set on the network side in order that inter RAT and
inter frequency measurements are triggered and S criteria is always met.
Pre-requisites:
Configuration: F
Cell 1 and 3 are defined as UMTS cells
UMTS Cell 1and cell 3 are emitting on different frequencies
Cell 4 and 6 are defined as 2G cells
Cell reselection parameters for cell 1 are defined as follow :
Set Qhyst1 to a high value = 40 dB for the UMTS serving cell.
Set Qoffset1 to a nominal value = 0 dB for the GSM neighbouring cell.
Set Qoffset2 to a nominal value = -50 dB for the UMTS neighbouring 3.
Test Procedure:
a) The NW activates Cell 1-3. Attenuate the UMTS cell 3 and GSM cells 4 and 6
b) Switch on the UE
c) It must register on the 3G cell1 (depending on the UE implementation, it could register on
CS or PS domain only or both)
RF conditions are changed so that cell 2G cells (cell 4 and 6) and 3G cell (cell 3) becoming
better than the cell1.
Test Verification:
The UE should reselect the FDD cell 3 and no 2G cells
To verify from the UE traces it has performed a cell reselection and not a cell selection.
Message Flow:

UE NW
Remarks:
Depending on the network configuration, if LAI or RAI is different on the target cell, the UE will
trigger a Location update procedure or Routing Area update procedure.






F_6.1.2.24 3G to 3G cell reselection with new neighbouring cells(UE is idle mode)
Test Purposes:
Test to verify that the UE performs cell reselection procedure on the right neighbor cell.
Note: All cell reselection parameters are properly set on the network side in order that intra frequency
measurement is always triggered and S criteria met.
Pre-requisites:
Configuration: C
Cell 1,cell 2 and 3 are emitting on the same frequency
FDD cell 1 is neighbour with FDD cell 2 only
FDD cell 2 is neighbour with FDD cell 1 and 3
FDD cell 3 is neighbour with FDD cell 1
Set reselection parameters as followed:

Qhyst21 = Qhyst22 =Qhyst23
Qoffset22,1= Qhyst21
Qoffset21,2 = Qoffset22,3 = Qoffset23,1 < Qhyst21
For example, the re-selection value could be set as followed:

Set Qhyst2s with the following values:
Qhyst21 = 10dB
Qhyst22 = 10dB
Qhyst23 = 10dB
Set Qoffset2s,n (where s = serving cell and n = neighbour cell) to:
Qoffset21,2 = -20 dB
Qoffset22,1 = 10 dB
Test Procedure:
a) FDD cell 2 and cell 3 are attenuated.
b) Switch the UE on, it must camp on the cell1(depending on the UE implementation, it could
register on CS or PS domain only or both).
c) RF conditions are changed so cell2 and cell3 have same RF condition as cell 1 The UE
should reselect the 3G cell2, then alternatively cell3, cell1, cell2...
Test Verification:
The UE alternatively reselects cell 1, cell 2, cell3

Message Flow:

UE NW

Remarks:
Depending on the network configuration, if LAI or RAI is different on the target cell, the UE will
trigger a Location update procedure or Routing Area update procedure.



F_6.1.3.1 UE perform cell Update after a cell reselection in CELL_FACH.
Test Purpose:
To verify that UE is able to perform a cell update procedure after UE perform a cell reselection.
To verify that network is able to perform a cell update procedure.
References: 3GPP TS 25.331 clause 8.3.1
Pre-requisites:
Two cells: A and B,
The UE is in CELL_FACH state on cell A.
Test Procedure:
A normal cell updating is performed in cell B.
Test Verification:
Verify that UE performs a cell update procedure.
Verify that NW indicates the correct state to UE.
Message flow:

UE NW
1 The UE is in the
CELL_FACH state in cell A
and perform a cell
reselection to cell B
2 CELL UPDATE Cell update cause = cell
reselection
3 CELL UPDATE CONFIRM RRC State Indicator =
CELL_FACH.
If the CELL UPDATE
CONFIRM message
includes "Physical channel
information elements". the
PHYSICAL CHANNEL
4 UE shall transmit a
RECONFIGURATION COMPLETE
PHYSICAL CHANNEL
RECONFIGURATION
COMPLETE as response
message (OPTION).
Remarks:

2 B_8.3.1.1 RRC / Cell Update: cell reselection in CELL_FACH


F_6.1.3.2 UE perform cell update after a cell reselection in CELL_PCH.
Test Purpose:
To verify that UE is able to perform a cell update procedure after UE perform a cell reselection.
To verify that network is able to perform a cell update procedure.
Pre-requisites:
Two cells: A and B
The UE is in CELL_PCH state on cell A
Test Procedure:
A normal cell updating is performed in cell B.
Test Verification:
Verify that NW indicate the correct state to UE.
Message flow:

UE NW
1 The UE is in the
CELL_PCH state in cell A
and perform a cell
2 CELL UPDATE The UE moves to
CELL_FACH state and
transmits this message
Cell update cause = cell
reselection
CELL_PCH.
If the CELL UPDATE
CONFIRM message
PHYSICAL CHANNEL
PHYSICAL CHANNEL
RECONFIGURATION
message (OPTION).
The UE is in CELL_PCH
5
state in cell B
Remarks:

2 B_8.3.1.2 RRC / Cell Update: cell reselection in CELL_PCH


F_6.1.3.3 Periodical cell update in CELL_FACH
Test Purpose:
To verify that UE and network are able to perform a periodic cell update procedure after timing expiry.
Pre-requisites:
One cells: A
The UE is in CELL_FACH state on cell A
T305 is set to 10 minutes
Test Procedure:
A normal cell updating is performed in cell A.
Set the T305 to the minimum allowed by network (suggestion: 5 minutes)
Wait for 5 minutes
A periodic cell updating is performed in cell A
Test Verification:
Verify that a periodic cell update is performed at timer expiry
Message flow:

UE NW
1 The UE is in the
CELL_FACH state. Tester
waits until T305 has
expired.T305= 10 minutes
2 CELL UPDATE Cell update cause =
periodical cell updating
3 CELL UPDATE CONFIRM
INFORMAT UTRAN MOBILITY INFORMATION
UTRAN4MOBILITY IE T305 is set to 5
minutes.
CONFIRM
6 CELL UPDATE UE shall transmit this
message 5 minutes after
step 5
Cell update cause =
Remarks:

1 B_8.3.1.3 RRC / Cell Update: periodical cell update in CELL_FACH


F_6.1.3.4 Cell Update when UE performs UL data transmission in URA_PCH
Test Purpose:
To verify the update of the UTRAN with the current cell information if the UE wants to transmit uplink
data while in URA_PCH state
Pre-requisites:
Configurations: B, C, D, E, F
Two or more cells: A, B
The UE is in URA_PCH state on cell A
Test Procedure:
UE perform a SMS sending procedure
A cell updating is performed in cell A before the SMS sending procedure
UE send out the SMS.
Test Verification:
Verify that UE performs a cell update procedure before SMS sending.
Verify that the cell update for UL data transmission is correct and SMS can be sent out
Message flow:

UE NW
1 The UE is in the URA_PCH
state and a SMS need to
be sent out.
2 CELL UPDATE The UE shall move to
CELL FACH state
Cell Update Message IE
Cell update cause =
uplink data transmission
3 CELL UPDA TE CONFIRM
4 UTRAN MOBILITY INFORMATION Message depending on the
CONFIRM content of the cell update
confirm
5 --> CP-DATA Contains RP-DATA RPDU
(SMS SUBMIT TPDU)
6 <-- CP-ACK
7 <-- CP-DATA Contains RP-ACK RPDU
8 --> CP-ACK
Remarks:

1 B_8.3.1.5 RRC / Cell Update: UL data transmission in URA_PCH
2 B_16.2.2 SMS on PS mode / SMS mobile originated


F_6.1.3.5 Cell Update, because UE is re-entering of service area in CELL_PCH or CELL_FACH
Test Purpose:
Verify that when a UE detects that it's out of service area after experiencing a T305 timer expiry, it
shall try to search for a suitable cell to camp on. At the same time, it shall start timer T307. If the UE
subsequently re-enters the service area of a cell before T307 expires, it shall perform a cell update
procedure.
Pre-requisites:
One cells A
The UE is in CELL_PCH or CELL_FACH state on cell A
T305 and T307 are set to the minimum allowed by network (suggestion: 5 minutes)
Test Procedure:
Put the UE in shield for 5 minutes, wait for the T305 timer expiry
Take the UE out of shield before the next 5 minutes(before the T307 timer expiry).
A cell updating is performed in cell A.
Test Verification:
Verify that UE performs a cell update procedure after re-entering service area.
Verify that the cell update for re-entering service area is correct
Message flow:

UE NW
1 Put the UE in the shield.
Let the UE out of service
area. Take the UE out of
shield after the T305 timer
expiry.
2 CELL UPDATE Cell Update Message IE
Cell update cause = "re-
entered service area"
3 CELL UPDATE CONFIRM "RRC State Indicator" is set
to "CELL_PCH" if the UE
was in CELL_PCH state
before it lost coverage
Remarks:

1 RRC / Cell Update: re-entering of service area after T305 expiry and being out
B_8.3.1.9
of service area


F_6.1.3.6 UE perform cell update due to Radio Link Failure
Test Purpose:
Verify that when a UE loses the radio connection due to e.g. radio link failure in CELL_DCH state..
After a successful cell re-selection and subsequent transition to CELL_FACH state, the UE transmits
CELL UPDATE message on the uplink CCCH.
Pre-requisites:
Configurations: A, B, C, D, E
One cells: A
The UE is in CELL_DCH state camp on cell A
T313 is set to a value allowed by network(suggest 3 seconds)
(Timer is not used in the test case)
Test Procedure:
Put the UE in shield and wait for the T313 timer expiry
Take the UE out of shield after the T313 timer expiry
A cell updating is performed in cell A.
Test Verification:
Verify that UE performs a cell update procedure after Radio Link Failure
Verify that the cell update for Radio Link Failure is correct
Message flow:

UE NW
1 Put the UE in the shield.
Take the UE out of shield
after the T313 timer expiry.
UE move to CELL_DCH.
2 CELL UPDATE Cell Update Message IE
Cell update cause =
"radio link failure"
3 CELL UPDATE CONFIRM Including dedicated
physical channel
parameters.
4 PHYSICAL CHANNEL
Remarks:

1 E_8.3.1.18 RRC / Cell Update: Radio Link Failure (T314>0, T315=0)


F_6.1.3.7 Cell update with SRNS relocation
Test Purpose:
Verify that UE perform a cell update after SRNC the UE belonged to changed.
References: 3GPP TS 25.931 clause 7.11.2.1
Pre-requisites:
Configurations: E
Two cells: cell A belong to RNC A and cell B belong to RNC B
UE in CELL_PCH or CELL_FACH state camp on cell A
Cell A and B have the same location and routing area id.
Test Procedure:
A cell updating with SRNS relocation is performed in cell B.
Test Verification:
Serving RNC relocation procedure is executed in cell updating procedure.
Message flow:

UE NW
1 The UE is in the
CELL_PCH state in cell A
and perform a cell
CELL_FACH state and
Cell update cause = cell
reselection
3 CELL UPDATE CONFIRM Network responds to UE by
RRC Cell Update Confirm,
including old S-RNTI and
SRNC ID as UE identifiers.
Message contains also the
new S-RNTI, SRNC-ID and
C-RNTI. LAI and RAI are
sent.
4 UTRAN Mobility Information Confirm
Remarks:

1 F_6.1.2.15 S-RNS Relocation


F_6.1.3.8 UE perform URA update after a URA reselection in URA_PCH.
Test Purpose:
To verify that UE is able to perform a URA update procedure after UE perform a URA reselection.
To verify that network is able to perform a URA update procedure.
Pre-requisites:
Configurations: D, E
Two cells: cell A belong to URA A and cell B belong to URA B
The UE in URA_PCH camp on cell A
Test Procedure:
Make cell B more suitable for UE in order to force a URA reselection.
A normal URA updating is performed in cell B.
Test Verification:
Verify that UE is able to reselect cell B correctly.
Verify that UE performs a URA update procedure.
Verify that NW indicates the correct state to UE.
Message flow:

UE NW
state in cell A and perform
a URA reselection to cell B
2 URA UPDATE The UE moves to
CELL_FACH state and
URA update cause =
change of URA
3 URA UPDATE CONFIRM RRC State Indicator =
URA_PCH.
The UE is in URA_PCH
4
state in cell B
Remarks:

1 B_8.3.2.1 RRC / URA Update: URA reselection
2 F_6.1.2.16 URA Update: Change of URA


F_6.1.3.9 Periodical cell update in CELL_PCH
Test Purpose:
To verify that UE and network are able to perform a periodic cell update procedure after timing expiry.
Pre-requisites:
One cell: A
Test Procedure:
Wait until expiry of T305
A periodic cell updating is performed in cell A
Test Verification:
Verify that a periodic cell update is performed after timer expiry
Message flow:

UE NW
1 The UE is in the
CELL_PCH state. UE
perform a periodical cell
updating after T305 has
expired.T305= 10 minutes
CELL_PCH.
Remarks:

1 F_6.1.2.17 URA Update: Periodical URA Wrong protocol test case, please correct


F_6.1.3.10 Cell Update , when UE perform UL data transmission in CELL_PCH
Test Purpose:
To verify the update of the UTRAN with the current cell information if the UE wants to transmit uplink
data in URA_PCH state
Pre-requisites:
One cell: A
Test Procedure:
UE perform a SMS sending procedure
A cell updating is performed in cell A before the SMS sending procedure
UE sends out the SMS.
Test Verification:
Verify that UE performs a cell update procedure before SMS sending.
Verify that the cell update for UL data transmission is correct and SMS can be sent out
Message flow:

UE NW
1 The UE is in the
CELL_PCH state and a
SMS need to be sent out.
CELL FACH state
Cell Update Message IE
Cell update cause =
uplink data transmission
CELL_FACH.
If the CELL UPDATE
CONFIRM message
PHYSICAL CHANNEL
PHYSICAL CHANNEL
RECONFIGURATION
message (OPTION).
5 --> CP-DATA Contains RP-DATA RPDU
(SMS SUBMIT TPDU)
6 <-- CP-ACK
8 --> CP-ACK
Remarks:

1 E_8.3.1.5 RRC / Cell Update: UL data transmission in URA_PCH


F_6.1.3.11 Cell update when UE is paged in CELL_PCH
Test Purpose:
To verify that UE is able to perform a cell update procedure in CELL_PCH when the UE is paged.
Pre-requisites:
One cells: A
Test Procedure:
Call the UE by PSTN.
A cell updating is performed in cell A
Test Verification:
Verify that a cell update is performed when the UE is paged
Message flow:

UE NW
1 The UE is in the
CELL_PCH state. Call the
UE by PSTN.
2 PAGING TYPE 1
paging response
CELL_FACH.
If the CELL UPDATE
CONFIRM message
PHYSICAL CHANNEL
PHYSICAL CHANNEL
RECONFIGURATION
message (OPTION).
Call set up procedure will continue
Remarks:

1 B_8.1.1.2 RRC / Paging for Connection in connected mode (CELL_PCH)


F_6.1.3.12 Cell update because UE is paged in URA_PCH
Test Purpose:
To verify that UE is able to perform a cell update procedure in URA_PCH when the UE is paged.
Pre-requisites:
One cells: A
Test Procedure:
Call the UE.
A cell updating is performed in cell A
Test Verification:
Verify that a cell update is performed when the UE is paged
Message flow:

UE NW
state. Call the UE.
2 PAGING TYPE 1
paging response
CELL_FACH.
If the CELL UPDATE
CONFIRM message
PHYSICAL CHANNEL
PHYSICAL CHANNEL
RECONFIGURATION
message (OPTION).
The call set up procedure will continue
Remarks:

1 B_8.1.1.2 RRC / Paging for Connection in connected mode (CELL_PCH)


F_6.1.3.13 Periodical ura update in URA_PCH
Test Purpose:
To verify that UE and network are able to perform a periodic ura update procedure after timing expiry.
Pre-requisites:
One cell: A
Test Procedure:
Wait until expiry of T305
A periodic ura updating is performed in cell A
Test Verification:
Verify that a periodic ura update is performed after timer expiry
Message flow:

UE NW
state. UE perform a
periodical ura updating
after T305 expired.T305=
10 minutes
2 URA UPDATE ura update cause =
periodic URA update
3 URA UPDATE CONFIRM RRC State Indicator =
URA_PCH.
Remarks:
None


F_6.1.3.14 RRC connection re-establishment following radio link failure (CS RAB)
Test Purpose:
To check that when the RRC connection can be re-established using the cell update procedure.
Pre-requisites:
Configuration: A, B, C, D, E (2 UTRA cells)
A CS call is established with cell 1, and UE is in cell_DCH state. T314 is different than 0 (otherwise
UE will go directly to idle mode). Note: network should use T314, but T315 could also be used.
Test Procedure:
Radio link failure criteria is triggered (cell 1 is switched OFF). UE selects cell 2 and transmits cell
update with cause radio link failure. Network transmits cell update confirm with new physical layer
parameters.
Test Verification:
If the RRC connection is re-established, verify that the CS call continues on cell 2.
Message flow:
UE NW
1 Radio link failure occurs on

cell 1
2 CELL UPDATE Cause: radio link failure
3 CELL UPDATE CONFIRM or RRC
CONNECTION RELEASE
4 (RRC CONNECTION RELEASE
COMPLETE)
Depending on the content of
the cell update message, a
reconfiguration complete
message may be sent by the
UE
Remarks:

1 8.3.1.18 Cell Update: Radio Link Failure (T314>0, T315=0), CS RAB established


F_6.1.3.15 RRC connection re-establishment following RLC unrecoverable error (PS RAB)
Test Purpose:
To check that when the RRC connection can be re-established using the cell update procedure for a
PS RAB.
Pre-requisites:
Configuration: A, B, C, D, E (2 UTRA cells)
A PS call is established with cell 1, and UE is in cell_DCH state. T315 is different than 0 (otherwise UE
will go directly to idle mode).
Note: network should use T315, but T314 could also be used.
Test Procedure:
RLC unrecoverable error criteria is triggered. UE transmits cell update with cause RLC unrecoverable
error. Network either transmits cell update confirm with new physical layer parameters or releases the
RRC connection.
Test Verification:
If the RRC connection is re-established, verify that the PS call continues on cell 2.
If the RRC connection is released, verify that a session establishment is performed on cell 2.
Message flow:
UE NW
1 RLC unrecoverable error

occurs on cell 1
2 CELL UPDATE Cause: RLC unrecoverable
error
3 CELL UPDATE CONFIRM or RRC
CONNECTION RELEASE
4 (RRC CONNECTION RELEASE
COMPLETE)
Depending on the content of
the cell update message, a
reconfiguration complete
message may be sent by the
UE
Remarks:

1 8.3.1.28 Cell Update: Radio Link Failure (T314=0, T315>0), PS RAB


F_6.2.1 Emergency Call: Normal case
Test Purpose:
The purpose of this test is to verify the UE can make an emergency call under normal scenario by
dialling any predetermined emergency calling code.
References: 24.008
Pre-requisites:
Configuration: A, B, C, D, E, F.
UE has proper emergency calling code programmed, i.e. 911 or 112 in its USIM card.
Test Procedure:
The UE camps on a suitable cell.
The UE originate an emergency call with connection cause of Emergency Call.
The network then checks the connection cause and allows the call to go through.
Test Verification:
Verify that the UE sends RRC CONNECTION REQUEST message with establishment cause set to
emergency call.
Verify that EMERGENCY SETUP message is sent.
Verify that the call go through with proper audio on both Uplink and Downlink.
Verify that the UE displays the call type is Emergency call.
Message Flow:
UE NW
1 UE camps and performs a

successful Location Update
2 RRC CONECTION REQUEST Establishment Cause is Emergency Call
COMPLETE
5 CM SERVICE REQUEST
(OPTIONAL)
7 AUTHENTICATION
RESPONSE (OPTIONAL)
(7a) SECURITY MODE COMMAND
(optional)
(7b) SECURITY MODE
COMPLETE (optional)
8 CM SERVICE ACCEPT CM SERVICE ACCEPT is only sent in case
security mode control procedure is not performed.
9 EMERGENCY SETUP
MESSAGE
10 CALL PROCEEDING
11 RADIO BEARER SETUP
COMPLETE


13 ALERT MESSAGE
14 CONNECT MESSAGE
15 CONNECT ACK MESSAGE
16 Conversation takes place
Remarks:

1 B_8.1.2.1 RRC / RRC Connection Establishment in CELL_DCH state: Success
4 B_X.X.X Security Mode procedure
5 E_8.2.1.1 RRC/ Radio Bearer Establishment for transition from CELL_DCH:
Success
8 B_10.1.2.1.1 Outgoing call / U0 null state / MM connection requested
9 B_10.1.2.2.2 Outgoing call / U0.1 MM connection pending / CM service accepted
10 B_10.1.2.4.1 Outgoing call / U3 UE originating call proceeding / ALERTING received
11 E_10.1.2.4.2 Outgoing call / U3 UE originating call proceeding / CONNECT received
12 E_10.1.2.4.7 Outgoing call / U3 UE originating call proceeding / RELEASE received
13 B_10.1.2.5.1 Outgoing call / U4 call delivered / CONNECT received
16 E_10.1.2.6.6 U10 call active / SETUP receive


F_6.2.2 Emergency Call: Normal case Network Releases the call
Test Purpose:
The purpose of this test is to verify that UE can handle a Network Release emergency call.
References: 24.008
Pre-requisites:
Test Procedure:
Test Verification:
emergency call.
Verify that the call is released properly by the network.
Message Flow:
UE NW

COMPLETE
(OPTIONAL)
7 AUTHENTICATION
RESPONSE (OPTIONAL)
(optional)
(7b) SECURITY MODE
COMPLETE (optional)
9 EMERGENCY SETUP
MESSAGE
10 CALL PROCEEDING
COMPLETE
13 ALERT MESSAGE


14 CONNECT MESSAGE
Conversation takes place
16 DISCONNECT MESSAGE
17 RELEASE MESSAGE
18 RELEASE COMPLETE
MESSAGE
21 RRC CONNECTION
RELEASE
22 RRC CONNECTION
RELEASE COMPLETE
UE goes back to Idle state
Remarks:

Success


F_6.2.3 Emergency Call: Normal case UE releases the call
Test Purpose:
The purpose of this test is to verify that UE can release an emergency call.
References: 24.008
Pre-requisites:
Test Procedure:
Test Verification:
emergency call.
Verify that the call is released properly by the UE.
Message Flow:
UE NW

COMPLETE
(OPTIONAL)
7 AUTHENTICATION
RESPONSE (OPTIONAL)
(optional)
(7b) SECURITY MODE
COMPLETE (optional)
9 EMERGENCY SETUP
MESSAGE
10 CALL PROCEEDING
COMPLETE
13 ALERT MESSAGE


14 CONNECT MESSAGE
17 RELEASE MESSAGE
18 RELEASE COMPLETE
MESSAGE
21 RRC CONNECTION
RELEASE
22 RRC CONNECTION
RELEASE COMPLETED
Remarks:

Success


F_6.2.4 Emergency Call: Forbidden PLMN
Test Purposes:
The purpose of this test is to verify the UEs ability to make an emergency call on a cell that has
forbidden PLMN.
Pre-requisites:
CN/UE is configured to cause the forbidden PLMN .
Test Procedure:
The UE camps on the network.
The network rejects location update initiated by the UE. Reject Cause shall be PLMN not allowed. At
this time, the UE enters Limited Service state.
The UE originates a call by dialling emergency calling code.
Test Verification:
Verify that UEs location update request is rejected by the network.
emergency call.
Verify that Emergency Setup message is sent.
Message Flow:
UE NW
UE failed LOCTION UPDATE Replace with UE camps and received a Location
with Reject Cause of PLMN Reject with Reject Cause of PLMN not Allowed.
not Allowed
UE goes into Limited Service
state
UE makes an emergency call
by dialling an appropriate
Emergency Dialling Code
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
(optional)
(6b) SECURITY MODE
COMPLETE (optional)
8 EMERGENCY SETUP
MESSAGE
9 CALL PROCEEDING



UE NW
COMPLETE
12 ALERT MESSAGE
13 CONNECT MESSAGE
Call is established.
Conversation takes place.
Remarks:

Success


F_6.2.5 Emergency Call: IMSI not allowed
Test Purposes:
The purpose of this test is to verify that the UE is able to make an emergency call on a network even
though its IMSI is not allowed by the network.
Pre-requisites:
The UE has an invalid IMSI.
Test Procedure:
The UE camps on the network.
The network rejects location update initiated by the UE. The Reject Cause shall be IMSI Unknown
UE make an emergency call.
Test Verification:
Verify that UEs location update request is rejected by the network.
Emergency Call.
Verify that the Emergency Setup is sent.
Message Flow:

UE NW
UE failed Location Update with
Rejection Cause of IMSI
Invalid
UE makes an emergency call
by dialling an appropriate
Emergency Dialling Code
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
(optional)
(6b) SECURITY MODE
COMPLETE (optional)
8 EMERGENCY SETUP
MESSAGE
9 CALL PROCEEDING



UE NW
COMPLETE
12 ALERT MESSAGE
13 CONNECT MESSAGE
Call is established.
Conversation takes place.
Remarks:

3 E_9.4.2.1 Location updating / rejected / IMSI invalid
Success


F_6.2.6 Mobile-Originate CS Data - Setup
Purpose:
The purpose of this test is to verify that UE can originate and perform data trans fer on a circuit switch
data call.
Pre-requisites:
Configuration: A, B, C, D, E, F
UE has a valid USIM.
UE has application to initiate date transfer and data reception. If not, other applications such as
Procomm or Hyper Terminal can be used via desktop or laptop computers.
Test Procedure:
UE camps on a suitable cell.
UE initiates a CS data call (either with existing application or the use of external application such as
Procomm or Hyper terminal via laptop or desktop computers).
Network shall specify the configuration of 64K DL and 64K UL through Radio Bearer Setup.
UE shall acknowledge the configuration and proceed to complete the call. Once the call is established,
data transfer and data reception can begin.
Test Verification:
Verify that the data throughput are at the rate specified i.e. 64Kbps.
Message Flow:
UE NW
1 RRC CONNECTION UE shall use
REQUEST. OriginatingConversationalCall_Establishment
Cause in establishment cause.
2 RRC CONNECTION SETUP Target RRC state is either cell_DCH or cell_FACH.
COMPLETE
5 AUTHENTICATION REQUEST Optional
6 AUTHENCTICATION Optional
RESPONSE
8 SECURITY MODE
COMPLETE
9 SETUP
10 CALL PROCEEDING
11 RADIO BEARER SETUP NW specifies the configuration of 64K UL and 64K
DL. RRC target state should be cell_DCH
COMPLETE
13 CONNECT
14 ALERT MESSAGE
15 CONNECT ACK
16 The call is established. Data Data transfer can be initiated by UEs build-in
transfer begins. applications or by using external applications such
as Procomm or Hyper Terminal via desktop or
laptop computer.


17 Verify throughput on both

Uplink and Downlink.
Remarks:
At step 1, UE shall initiate the call from a build-in applications or external applications (Procomm or
Hyper Terminal) running on laptop or desktop computers data cable.
At step 17, UE can disconnect from its user interface or from applications running lapt op or desktop
computer.
The use of radio bearer has to be mentioned the Join Test Report (JTR).

Success
6 B_8.2.3.1 RRC / Radio Bearer Release for transition from CELL_DCH to
CELL_DCH: Success


F_6.2.7 Mobile Terminated CS Data - Setup
Purpose:
The purpose of this test is to verify that UE can perform data transfer on a circuit switch data call
initiated by the network
Pre-requisites:
Test Procedure:
UE camps on a suitable cell.
UE initiates a CS data call (either with existing application or the use of external application such as
Procomm or Hyper terminal via laptop or desktop computers).
Network shall specify the configuration of 64K DL and 64K UL through Radio Bearer Setup.
UE shall acknowledge the configuration and proceed to complete the call. Once the call is established,
data transfer and data reception can begin.
UE shall release the call once data transmission is completed.
Test Verification:
Verify that the data through are at the rate specified i.e. 64Kbps.
Message Flow:
UE NW
1 PAGING TYPE 1 NW shall send a PAGING TYPE 1 with correct
paging cause.
2 RRC CONNECTION
REQUEST
COMPLETE
5 PAGING RESPONSE
7 AUTHENCATICATION Optional
RESPONSE
9 SECURITY MODE OPTIONAL IDENTITY REQUEST
COMPLETE
10 SETUP
11 CALL CONFIRM
12 RADIO BEARER SETUP NW specifies the configuration of 64K UL and 64K
DL. RRC target state should be cell_DCH
13 RADIO BEARER SETUP "Identity type" IE is IMSI.
COMPLETE
14 ALERT
15 CONNECT
16 CONNECT ACK
17 The call is established. Data Data transfer can be initiated by UEs build-in
transfer begins. application or by using external application such as
Procomm or Hyper Terminal via desktop or laptop
computer.
18 Verify throughput on both
Uplink and Downlink.


Remarks:

2 B_8.1.1.1 RRC / Paging for Connection in idle mode
Success
CELL_DCH: Success


F_6.2.8 CS Data - Network Release
Test Purpose:
The purpose of this test is to verify that UE can perform a release of a circuit switch data call by the
network after data transfer is.
Pre-requisites:
UE is currently on a circuit switch data call.
Test Procedure:
UE completes data transfer.
Network shall release the call once data transmission is completed.
Test Verification:
Verify that the data throughput are at the rate specified i.e. 64Kbps.
Verify the UE properly released the call.
Message Flow:
UE NW
UE completes data transfer
2 RELEASE MESSAGE
3 RELEASE COMPLETE
MESSAGE
6 RRC CONNECTION
RELEASE
7 RRC CONNECTION
RELEASE COMPLETED
Remarks: None



F_6.2.9 CS Data Call - Mobile Release
Test Purpose:
The purpose of this test is to verify that UE can perform data transfer on a circuit switch data call
initiated by the network and released by the UE with the rates of 64K on the UL and 64K on the DL.
Pre-requisites:
UE is currently in a circuit switch data call.
Test Procedure:
UE shall release the call once data transmission is completed.
Test Verification:
Verify that the data through are at the rate specified i.e. 64Kbps.
Verify the UE properly released the call.
Message Flow:
UE NW
2 RELEASE MESSAGE
3 RELEASE COMPLETE
MESSAGE
6 RRC RELEASE
7 RRC CONNECTION
RELEASE COMPLETED
Remarks:
At step 1, UE can disconnect from its user interface or from applications running laptop or desktop
computer.



F_6.2.10 MO Voice Call
Test Purpose:
The purpose of this test is to verify that a mobile originated call is successful.
Pre-requisites:
The UE is present in the HLR & VLR databases
An IMSI is activated in a mobile station within coverage area from the network
The mobile is attached and the stored Location Area Identification is the same as the one,
which is actually broadcasted on the BCCH of the current serving cell
Test Procedure:
The mobile is made to establish a speech call.
Test Verification:
To verify that the MO call is successful
To verify DTMF tones during an MO call
Verify the messages transmitted over the Iu and Iub interfaces in order to validate the
message flow below.
Once speech signalling has been successfully exchanged, check that the speech quality is
correct in both uplink and downlink
DTMF tones: once the MO call is established, check that if you hit the keys on the phone, you
get the tones at the other end
Message Flow:
UE NW
1 UE An MO speech call is attempted.
2 RRC CONNECTION REQUEST Cause = originated conversational call, UE id = TMSI
and LAI
3 RRC CONNECTION SETUP With U-RNTI and signalling RB info. Target RRC
state is either cell_DCH or cell_FACH.
COMPLETE
5 CM SERVICE REQUEST (MM) Mobile ID = TMSI
6 AUTHENTICATION REQUEST* *Optional
7 AUTHENTICATION ACCEPT* *Optional
10 SETUP (CC)
11 CALL PROCEDING (CC)
12 RADIO BEARER SETUP UL:12.2 DL:12.2 kbps speech RAB is allocated, with
all corresponding parameters. Target RRC state is
cell_DCH.
13 RADIO BEARER SETUP COMPLETE
14 ALERTING (CC)
15 CONNECT
16 CONNECT ACKNOWLEDGEMENT
(CC)
Note: depending on network implementation, measurements can be set up before/during/after this message flow.


Remarks:
At step 12, the NW allocates the UL:12.2 DL:12.2 kbps speech RAB to the UE.
After step 16, the speech quality in UL and DL must is correct, and DTMF tones work.

Success


F_6.2.11 MT Voice Call
Test Purpose:
The purpose of this test is to verify that a mobile terminated call is successful.
Pre-requisites:
The UE is present in the HLR & VLR databases
An IMSI is activated in a mobile station within coverage area from the network
The mobile is attached and the stored Location Area Identification is the same as the one,
which is actually broadcasted on the BCCH of the current serving cell
Test Procedure:
A call is made to the mobile. The UE requests an RRC connection and the call is established
according to the message flow below.
Test Verification:
To verify that the MO call is successful
To verify DTMF tones during an MO call
message flow below.
Once speech signalling has been successfully exchanged, check that the speech quality is
correct in both uplink and downlink
DTMF tones: once the MO call is established, check that if you hit the keys on the phone, you
get the tones at the other end
Message Flow:
UE NW
1 PAGING (type 1)
2 RRC CONNECTION REQUEST Cause = Terminated conversational call, UE id =
TMSI and LAI
COMPLETE
5 RR PAGING RESPONSE
9 SETUP (CC)
11 RADIO BEARER SETUP UL:12.2 DL:12.2 kbps speech RAB is allocated, with
all corresponding parameters. Target RRC state is
cell_DCH.
13 ALERTING (CC)
14 CONNECT
(CC)
Note: depending on network implementation, measurements can be set up before/during/after this message flow.


Remarks:
At step 1, the paging cause is Terminated conversational call and the CN domain identity is CS
domain (check over Iub)
At step 11, the NW allocates the UL:12.2 DL:12.2 kbps speech RAB to the UE.
After step 15, the speech quality in UL and DL must is correct, and DTMF tones work.

Success


F_6.2.12 Voice Call Release: UE initiated
Test Purpose:
The purpose of this test is to perform a call release initiated by the UE.
Pre-requisites:
A speech call had been successfully established, but not released
Test Procedure:
The mobile releases the previously established speech call.
Test Verification:
To verify that call release is successful
message flow below.
Message Flow:
UE NW
connection
2 RELEASE (CC) NW intends to release the transaction identifier, and
that the receiving equipment shall release the
transaction identifier after the Release complete.
COMPLETE
Remarks:
After step 5, the radio connection is released.



F_6.2.13 Voice Call Release: Network initiated
Test Purpose:
The purpose of this test is to perform a call release initiated by the network.
Pre-requisites:
A speech call had been successfully established, but not released
Test Procedure:
The network initiates the release of the previously established speech call.
Test Verification:
To verify that call release is successful
message flow below.
Message Flow:
Note: The only difference with respect to the UE initiated one is that in this case the CN sends the
CC disconnect message. The NAS messages are similar except from the optional IE.

UE NW
connection
2 RELEASE (CC) NW intends to release the transaction identifier, and
that the receiving equipment shall release the
transaction identifier after the Release complete.
COMPLETE
Remarks:
After step 5, the radio connection is released.



F_6.2.14 Mobile-to-Mobile Video Telephony call setup
Purpose:
The purpose of the test is to verify that the UE can successfully setup a mobile-to-mobile video
telephony call.
References: 26.110, 26.111, 26.911, 23.972
Pre-requisites:
Configuration: A, B, C, D, E, F, G
The two UEs have a valid USIM.
The two UEs must be 3G-324M terminals. 3G-324M is based on ITU-T H.324 recommendation and
has been modified by 3GPP for purposes of 3GPP circuit switched network based video telephony.
3G-324M implementations require having H.223 with Annex A and B as multiplexing protocol, and
H.245 version 3 or later versions for system control protocol. 3G-324M terminals offering audio
communication shall support the AMR audio codec. Support for G.723.1 is not mandatory, but
recommended. 3G-324M terminals offering video communication shall support the H.263 video codec.
Support for MPEG-4 simple profile and H.261 is optional.
Test Procedure:
The two subscribers are registered with 3G-324M services. The UEs camp on a suitable cell. The
calling UE initiates a Video Telephony call to the other UE. The network shall specify the configuration
of 64K DL and 64K UL through Radio Bearer Setup. The UEs shall acknowledge the configuration and
shall proceed to the establishment of the 3G-324M session (capability exchange, master/slave
determination, multiplex table entry exchange, opening of logical channels for audio and video). Once
the call is established, the two UEs shall exchange audio and video.
Test Verification:
Verify that the call is established and that audio and video are sent and received successfully and that
the data throughput corresponds to the specified rate, i.e. 64kbps.
Verify in Terminal Capability Set message that AMR is declared as supported audio codec and that
H.263 is declared as supported video codec (mandatory).
Verify that the Uplink and downlink voice and video quality are correct.
Message Flow:
Calling UE NW
cell_FACH.
COMPLETE
5 AUTHENTICATION Optional
REQUEST
RESPONSE
7 SECURITY MODE
COMMAND
8 SECURITY MODE
COMPLETE
9 SETUP


10 CALL PROCEEDING
11 RADIO BEARER SETUP NW specifies the configuration of 64K UL and
64K DL. RRC target state should be cell_DCH
COMPLETE
Called UE NW
13 PAGING (type 1)
14 RRC CONNECTION REQUEST Cause = Terminated conversational call
COMPLETE
19 AUTHENTICATION ACCEPT Optional
22 SETUP (CC)
23 CALL CONFIRM
24 RADIO BEARER SETUP NW specifies the configuration of 64K UL and 64K DL.
RRC target state should be cell_DCH
COMPLETE
Calling Called
UE UE
26 ALERT MESSAGE
27 CONNECT
28 CONNECT ACK
A transparent 64k UL/DL

Radio Bearer is then available
to carry any kind of 3G-324M
data as UMTS User Plane
data.
The following message flow
show the 3G-324M protocol
29 H. 245 TERMINAL It contains the terminal's capability to transmit and
CAPABILITY SET receive: H223 multiplex capabilities (max AL2 and
AL3 SDU size, support for AL regarding data,
video and audio streams; etc)., audio and video
capabilities (codec, bit rate, image format, etc)
30 H.245 MASTER SLAVE This procedure allows terminals in a call to
DETERMINATION determine which terminal is the master and which
terminal is the slave
31 H. 245 TERMINAL
CAPABILITY SET
32 H.245 MASTER SLAVE
DETERMINA TION
33 H. 245 TERMINAL
CAPABILITY SET ACK
34 H. 245 TERMINAL
CAPABILITY SET ACK
DETERMINATION ACK
DETERMINATION ACK
37 H.245 MULTIPLEX ENTRY This is used to send H.223 multiplex table entries
SEND from the transmitter to the receiver


38 H.245 MULTIPLEX ENTRY

SEND ACK
SEND
SEND ACK
41 H.245 OPEN LOGICAL This is used to open a unidirectional logical
CHANNEL channel for audio*
42 H.245 OPEN LOGICAL
CHANNEL ACK
CHANNEL CONFIRM
44 H.245 OPEN LOGICAL This is used to open a unidirectional logical
CHANNEL channel for audio*
CHANNEL ACK
CHANNEL CONFIRM
47 H.245 OPEN LOGICAL This is used to open a bidirectional logical
CHANNEL channel for video*
CHANNEL ACK
CHANNEL CONFIRM
On going Video telephony call

* The logical channel may use two types of adaptation layer for the multiplexing protocol H223: AL2,
designed primarily for the transfer of digital audio or AL3, designed primarily for the transfer of digital
video. It is recommended that terminals support video also using Adaptation Layer Type 2 (AL2)
where retransmission is not possible and overhead is slightly smaller. The logical channels for audio
and video may be unidirectional or bidirectional but more generally it will be unidirectional for audio
and bidirectional for video. However, when using AL3 adaptation layer the logical channel shall be
bidirectional.
Remarks:
Note that in step 2 and step15, the SRNC can either put the UE in cell_DCH or cell_FACH. The test

Success
CELL_DCH: Success


F_6.2.15 Mobile-to-Mobile Video Telephony call release
Purpose:
The purpose of the test is to verify that the UE can successfully release a mobile-to-mobile video
telephony call.
References: 26.110, 26.111, 26.911, 23.972
Pre-requisites:
The two UEs must be 3G-324M terminals.
Test Procedure:
The two UEs are exchanging audio and video. The calling UE shall release the call.
Test Verification:
Verify that the call and all associated resources are released successfully.
Message Flow:
Calling Called
UE UE
On going Video telephony call,
calling UE releases the call
1 H.245 END SESSION

COMMAND
2 H.245 END SESSION
COMMAND
4 RELEASE MESSAGE
5 RELEASE COMPLETE
MESSAGE
Calling NW
UE
6 RRC RELEASE
7 RRC CONNECTION
RELEASE COMPLETED
Called NW
UE
8 RRC RELEASE
9 RRC CONNECTION
RELEASE COMPLETED



F_6.2.16 Unsuccessful mobile-to-mobile video telephony call, terminating mobile is not a 3G-
324M UE
Purpose:
The purpose of the test is to verify the procedure of a mobile-to-mobile 3G-324M video telephony call
rejected by the network because the terminating UE is not 3G-324M.
Referenc es: 26.110, 26.111, 26.911, 23.972, 24.008 5.3.6.2.2 & 5.4
Pre-requisites:
The calling UE must be a 3G-324M terminal whereas the called UE should not.
Test Procedure:
The UEs camp on a suitable cell. The calling UE initiates a Video Telephony call to the other UE. The
called mobile rejects the call because 3G-324M service is not subscribed.
Test Verification:
Verify that the call is released successfully and that it does not affect the calling UE.
Message Flow:
Calling UE NW
cell_FACH.
COMPLETE
REQUEST
RESPONSE
7 SECURITY MODE
COMMAND
8 SECURITY MODE
COMPLETE
9 SETUP
10 CALL PROCEEDING
11 RADIO BEARER SETUP NW specifies the configuration of 64K UL and
64K DL. RRC target state should be cell_DCH
COMPLETE
Called UE NW
13 PAGING (type 1)
14 RRC CONNECTION Cause = Terminated conversational call
REQUEST
cell_FACH.


COMPLETE
REQUEST
20 SECURITY MODE
COMMAND
22 SETUP (CC)
23 RELEASE COMPLETE Cause = bearer service not implemented
24 RRC RELEASE
25 RRC CONNECTION
RELEASE COMPLETED
Calling NW
UE
26 RRC RELEASE
27 RRC CONNECTION
RELEASE COMPLETED
Remarks:

Success
CELL_DCH: Success


F_6.2.17 AMR Rate Control DL -two AMR rates
Test Purpose:
The purpose of this test is to verify successful downlink AMR rate switching between two bit rates, rate
A and rate B, during a CS voice call.
The test is written in a generic form, where Rates A (upper) and B (lower) can be selected among any
of the available ones (12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.15, 4.75).
Reference: 3GPP TS 25.415, section 6.5.3, 6.6.2.3, 6.6.3.4

3GPP TS 26.101, section 4.2.2
3GPP TS 25.331, section 10.2.33
Pre-requisites:
The UE is in IDLE state, registered at the network and ready for establishing a Voice Call.
UE has indicated at Radio Bearer Capabilities that can use both AMR rates A and B.(has to be
checked, if it is really indicated in the message)
The network has been configured to use at least two DL AMR rates, A (upper) and B (lower) to
establish a CS call.
Test Procedure:
NOTE: Conditions upon which Rate Control Procedure is triggered at RNC are implementation
specific and are not covered at Specs. Each vendor must determine, according to the AMR Rate
Control Algorithm implemented at RNC, the setup, load and RF conditions that should be forced
during testing for triggering increase and/or decrease of Bit Rate during voice call period.
Establish a MO Voice Call with RF conditions that allows RNC to be using upper bit rate (A).
Modify RF or Load condition in order to force RNC to trigger Rate Control Procedure indicating to the
CN to reduce its bit rate for DL Transmission to the lower allowed bit rate (B).
Verify the UE can receive correctly downlink voice using lower bit Rate (B).
Go back to initial RF conditions forcing RNC to trigger Rate Control again indicating CN to increase Bit
Rate employed for DL Transmission to bit Rate (A).
Verify the UE can receive correctly again downlink voice using upper bit Rate (A).
Test Verification:
Verify that the message flow is correct.
.
At RB Setup message sent by the RNC to the UE, verify that Added or Reconfigured TrCH
information list IE is including information for three coordinated DCHs corresponding to three
subflows that compound AMR. Additionally, check that Added or Reconfigured DL TrCH information
IE is including information relate to SDU size and number of transport blocks allowed for each of that
DCHs. TFI for each of them will be numbered from 0 till N-1, being N number of Transport Formats
allowed for this DCH. For more information about Radio Bearer Setup message codification check
3GPP TS 25.331, section 10.2.33

Verify that Iub Data Frame sent by the RNC to the UE is including the TFI for each one of the three
coordinated DCH that correspond to the SDU sizes and transport blocks matching Bit Rates A and B
according to RB Setup captured previously. For reference of DL Data Frame Structure, check 3GPP
TR 25.427, section 6.2.3
Verify voice quality during the whole procedure, checking that is correct at UE and CN side when bit
rate is increased (Bit Rate A) and decreased (Bit Rate B) during test duration.
Message Flow:

UE NW
1 UE An MO speech call is intiated.
COMPLETE
5 CM SERVICE REQUEST (MM)
10 SETUP (CC)
12 RADIO BEARER SETUP With at least AMR rates A and B.
14 ALERTING (CC)
15 CONNECT
(CC)
17 Data transmission Bit Rate (A) Verify the UE can receive correctly downlink voice
using upper bit Rate (A) checking voice quality.
18 Change RF conditions to trigger AMRC to change to
AMR rate B.
19 Data transmission Bit Rate (B) Verify the UE can receive correctly downlink voice
using lower bit Rate (B) checking voice quality.
AMR rate A.
21 Data transmission Bit Rate (A) Verify the UE can receive correctly downlink voice
Remarks:
Just for tester information, but not related to UU interface testing, note that DL Rate Control procedure
will be triggered when RNC sends IU UP Control Frame PDU Type 14 (Procedure Indicator=1, Rate
Control) and including RFCI for upper bit Rate (A) set to: 1=RFCI barred, or 0=RFCI allowed.
Additionally, CN should be sending, from this moment and on, Data PDU including RFCI
corresponding to allowed bit rate. For more information related to Iu Rate Control procedure check
3GPP TS 25.415, sections 6.5.3, 6.6.2.2, 6.6.2.3.



NOTES:


F_6.2.18 AMR Rat e Control DL - Multiple AMR rates
Test Purpose:
The purpose of this test is to verify successful downlink AMR rate switching between several bit rates,
rate R1 till RN during a CS voice call.
This test will cover the situation where the network has been configured to use the maximum allowed
number of DL AMR rates to establish the CS call.

3GPP TS 25.331, section 10.2.33
Pre-requisites:
UE has indicated at Radio Bearer Capabilities that can support all the AMR rates used in the test.
The Network is configured to use the maximum allowed number of DL AMR Rates to establish the CS
call.
Test Procedure:
NOTE: Conditions upon which Rate Control Procedure is triggered at RNC are implementation
specific and are not covered at Specs. Each vendor must determine, according to the AMR Rate
Control Algorithm implemented at RNC, the setup, load and RF conditions that should be forced
during testing for triggering increase and/or decrease of Bit Rate during voice call period.
NOTE: Additionally, it is not defined at specs the maximum number of AMR Rates that the Network is
configuring for DL use, so test description will assume that the Network will choose N rates (R1 till RN )
Establish a MO Voice Call with RF conditions that allows RNC to be using highest bit rate (R1) of those
chosen to establish the call.
Verify the UE can receive correctly downlink voice using upper bit Rate (R1), checking voice quality.
Modify RF or Load condition in order to force RNC to trigger Rate Control Procedure indicating to the
CN to reduce its bit rate for DL Transmission to the next lower allowed bit rate (R2).
Verify the UE can receive correctly downlink voice using this Rate (R2).
Repeat steps above N times in order to force RNC to trigger Rate Control again indicating CN to
decrease, step by step, Bit Rate employed for DL Transmission to lower Rates (R3,. RN ).
Modify RF/Load conditions forcing RNC to trigger Rate Control again indicating CN to increase Bit
Rate employed for DL Transmission to upper bit Rate in one step (RN-1).
Verify the UE can receive correctly again downlink voice using upper bit Rate (RN-1).


Repeat steps above N times in order to force RNC to trigger Rate Control again indicating CN to
increase, step by step, Bit Rate employed for DL Transmission to upper Rates (RN-2,. R2, R1).
Test Verification:
DCHs, that will be mapping rates R1 till RN . TFI for each of them will be numbered from 0 till X-1, being
X number of Transport Formats allowed for this DCH. For more information about Radio Bearer Setup
message codification check 3GPP TS 25.331, section 10.2.33
Verify that Iub Data Frame sent by the RNC to the NodeB is including the TFI for each one of the three
coordinated DCH that correspond to the SDU sizes and transport blocks matching the Bit Rate Rx in
use at each moment, according to RB Setup captured previously. For reference of DL Data Frame
Structure, check 3GPP TR 25.427, section 6.2.3
rate is increased and decreased step by step among different AMR Bit Rates during test duration,
according to information provided at Test Procedure.
Message Flow:

UE NW
1 UE An MO speech call is initiated.
COMPLETE
10 SETUP (CC)
12 RADIO BEARER SETUP With AMR rates R 1 to R N .
14 ALERTING (CC)
15 CONNECT
(CC)
17 Data transmission Bit Rate (R1) Verify the UE can receive correctly downlink voice
using upper bit Rate (R1) checking voice quality.
DL AMR rate R 2.
using bit Rate (R2) checking voice quality.
20 Change RF conditions to trigger AMRC to decrease
DL AMR rate.
21 Repeat the previous two steps until R n is reached
22 Data transmission Bit Rate (RN) Verify the UE can receive correctly downlink voice
using lowest bit Rate (RN) checking voice quality


AMR rate R N-1.

20 Data transmission Bit Rate (RN-1) Verify the UE can receive correctly downlink voice
increasing again used Rate (RN-1) checking voice
quality.
20 Change RF conditions to trigger AMRC to increase
DL AMR rate.
21 Repeat the previous two steps until R 1 is reached
using highest bit Rate (R1) checking voice quality.
Remarks:
Just for tester information, but not related to UU interface testing, note that DL Rate Control procedure
will be triggered when RNC sends IU UP Control Frame PDU Type 14 (Procedure Indicator=1, Rate
Control) and including RFCI for each bit Rate (Ri) set to: 0=RFCI allowed or 1=RFCI barred.
Additionally, CN should be sending, from this moment on, Data PDU including RFCI corresponding to
the allowed Rates. .For more information related to Iu Rate Control procedure check 3GPP TS 25.415,
sections 6.5.3, 6.6.2.2, 6.6.2.3.

6 E_10.1.2. 4.2 Outgoing call / U3 UE originating call proceeding / CONNECT received
NOTES:


F_6.2.19 AMR Rate Control UL -two AMR rates
Test Purpose:
The purpose of this test is to verify successful uplink AMR rate switching between two bit rates, rate A
and rate B, during a CS voice call.
The test is written in a generic form, where Rates A (upper) and B (lower) can be selected among any
of the available ones (12.2, 10.2, 7.95, 7.4, 6.7, 5.9, 5.15, 4.75).

3GPP TS 25.331, section 10.2.33, 8.2.5, 10.2.53
Pre-requisites:
UE has indicated at Radio Bearer Capabilities that can use both AMR rates A and B.(see comment in
the first test case)
The network has been configured to use at least two UL AMR rates, A (upper) and B (lower) to
establish a CS call.
Test Procedure:
Establish a MO Voice Call with RF conditions that allows use of upper bit rate (A).
Modify RF or Load condition in order to force Network indicating to the UE to reduce its bit rate for UL
Transmission to the lower allowed bit rate (B).
Verify the UE can transmit correctly uplink voice using lower bit Rate (B).
Go back to initial RF conditions forcing Network to indicate to the UE to increase Bit Rate employed
for UL Transmission to bit Rate (A).
Verify the UE can transmit correctly again uplink voice using upper bit Rate (A).
Test Verification:
subflows that compound AMR. Additionally, check that Added or Reconfigured UL TrCH information
DCHs. TFI for each of them will be numbered from 0 till N-1, being N number of Transport Formats
allowed for this DCH. Additionally for UL, it should be checked also UL Transport Channel Information
common for all transport channels IE that can include at Transport Format Combination subset IE
information about initially allowed TFI to be used for UL. For more information about Radio Bearer
Setup message codification check 3GPP TS 25.331, sections 10.2.33, 10.2.53
Verify that Iub Data Frame sent by the NodeB to the RNC is including the TFI for each one of the three
coordinated DCH that correspond to the SDU sizes and transport blocks matching Bit Rates A and B
according to RB Setup captured previously. For reference of UL Data Frame Structure, check 3GPP
TR 25.427, section 6.2.2
Verify at RRC Transport Format Combination Control messages that, included in Transport Format
Combination Subset IE, TFIs related to AMR Rates A and B are allowed or removed from allowed list
according to AMR Rate modification performed. UE should sending Data according to allowed TFIs.

rate is increased (Bit Rate A) and decreased (Bit Rate B) during test duration.
Message Flow:
UE NW
1 UE An MO speech call is intiated.
COMPLETE
10 SETUP (CC)
12 RADIO BEARER SETUP With at least AMR rates A and B.
14 ALERTING (CC)
15 CONNECT
(CC)
17 Data transmission Bit Rate (A) Verify the UE can transmit correctly uplink voice
AMR rate B
19 RRC TRANSPORT FORMAT
COMBINATION CONTROL
20 Data transmission Bit Rate (B) Verify the UE can transmit correctly uplink voice
using lower bit Rate (B) checking voice quality.
AMR rate A.
COMBINATION CONTROL
23 Data transmission Bit Rate (A) Verify the UE can transmit correctly uplink voice
Remarks:
AMRC may also be initiated for DL transmission.

NOTES:


F_6.2.20 AMR Rate Control UL - Multiple AMR rates
Test Purpose:
The purpose of this test is to verify successful uplink AMR rate switching between several bit rates,
rate R1 till RN during a CS voice call.
This test will cover the situation where the network has been configured to use the maximum allowed
number of UL AMR rates to establish the CS call.

3GPP TS 25.331, sections 10.2.33, 8.2.5, 10.2.53
Pre-requisites:
UE has indicated at Radio Bearer Capabilities that can support all the AMR rates used in the test.
The Network is configured to use the maximum allowed number of UL AMR Rates to establish the CS
call.
Test Procedure:
Establish a MO Voice Call with RF conditions that allows to use highest bit rate (R1) of those chosen to
establish the call.
Verify the UE can transmit correctly uplink voice using upper bit Rate (R1 ), checking voice quality.
Modify RF or Load condition in order to force Network indicating to the UE to reduce its bit rate for UL
Transmission to the next lower allowed bit rate (R2).
Verify the UE can transmit correctly uplink voice using this Rate (R2).
Repeat steps above N times in order to force Network to indicate to the UE to decrease, step by step,
Bit Rate employed for UL Transmission to lower Rates (R3,. RN ).
Modify RF/Load conditions forcing Network to indicate to the UE to increase Bit Rate employed for UL
Transmission to upper bit Rate in one step (RN-1).
Verify the UE can transmit correctly again uplink voice using upper bit Rate (RN-1).
Repeat steps above N times in order to force Network to indicate to the UE to increase, step by step,
Bit Rate employed for UL Transmission to upper Rates (RN-2,. R2, R1).
Test Verification:


DCHs, that will be mapping rates R1 till RN . TFI for each of them will be numbered from 0 till X-1, being
X number of Transport Formats allowed for this DCH. Additionally for UL, it should be checked also
UL Transport Channel Information common for all transport channels IE that can include at Transport
Format Combination subset IE information about initially allowed TFI to be used for UL. For more
information about Radio Bearer Setup message codification check 3GPP TS 25.331, section 10.2.33,
10.2.53
Verify that Iub Data Frame sent by the NodeB to the RNC is including the TFI for each one of the three
coordinated DCH that correspond to the SDU sizes and transport blocks matching the Bit Rate Rx in
use at each moment, according to RB Setup captured previously. For reference of UL Data Frame
Structure, check 3GPP TR 25.427, section 6.2.2
Verify at RRC Transport Format Combination Control messages that, included in Transport Format
Combination Subset IE, TFIs related to AMR Rates from R1 till RN that are allowed or removed from
allowed list according to AMR Rate modification performed. UE should sending Data according to
allowed TFIs.
rate is increased and decreased step by step among different AMR Bit Rates during test duration,
according to information provided at Test Procedure.
Message Flow:

UE NW
1 UE An MO speech call is initiated.
COMPLETE
10 SETUP (CC)
12 RADIO BEARER SETUP With AMR rates R 1 to R N .
14 ALERTING (CC)
15 CONNECT
(CC)
17 Data transmission Bit Rate (R1) Verify the UE can transmit correctly uplink voice
using upper bit Rate (R1) checking voice quality.
UL AMR rate R 2
COMBINATION CONTROL
using bit Rate (R2) checking voice quality.
21 Change RF conditions to trigger AMRC to decrease
UL AMR rate
22 Repeat the previous three steps until R n is reached


COMBINATION CONTROL
24 Data transmission Bit Rate (RN) Verify the UE can transmit correctly uplink voice
using lowest bit Rate (RN) checking voice quality
AMR rate R N-1.
COMBINATION CONTROL
27 Data transmission Bit Rate (RN-1) Verify the UE can transmit correctly uplink voice
increasing again used Rate (RN-1) checking voice
quality.
28 Change RF conditions to trigger AMRC to increase
UL AMR rate.
29 Repeat the previous three steps until R 1 is reached
COMBINATION CONTROL
using highest bit Rate (R1) checking voice quality.
Remarks:
AMRC may also be initiated for DL transmission.

NOTES:


F_6.2.21 Mobile-to-Mobile Video Telephony call leads to speech when called party does not
support VT (Rel-5)
Purpose:
The purpose of the test is to verify that the UEs and network can established a mobile-to-mobile a CS
call, when the calling UE initiates a setup a VT and the called UE does not support Video Telephony.
References: 26.110, 26.111, 26.911, 23.972
Pre-requisites:
The calling UE must be 3G-324M terminals. 3G-324M is based on ITU-T H.324 recommendation and
has been modified by 3GPP for purposes of 3GPP circuit switched network based video telephony.
The called UE does only support AMR
3G-324M implementations require having H.223 with Annex A and B as multiplexing protocol, and
H.245 version 3 or later versions for system control protocol. 3G-324M terminals offering audio
communication shall support the AMR audio codec. Support for G.723.1 is not mandatory, but
recommended. 3G-324M terminals offering video communication shall support the H.263 video codec.
Support for MPEG-4 simple profile and H.261 is optional.
Test Procedure:
Only one subscriber (the calling) is registered with 3G-324M services. The UEs camp on a suitable
cell. The calling UE initiates a Video Telephony call to the other UE. The network shall specify the
configuration of 64K DL and 64K UL through Radio Bearer Setup to the calling UE.
The called UE sends its Bearer Capability within the CC Call Confirmed message, saying to the
network that it does not support 3G-324M. The network will configures a 12.2 AMR radio access
bearer.
Test Verification:
Verify that the call is established in audio successfully.

Verify in the Bearer Capability of the called UE the AMR is declared and supported but H.263 is not
supported.
Verify that the Uplink and downlink voice quality are correct.


Message Flow:
Calling UE NW
cell_FACH.
COMPLETE
4 CM SERVICE RE QUEST
REQUEST
RESPONSE
7 SECURITY MODE
COMMAND
8 SECURITY MODE
COMPLETE
9 SETUP
10 CALL PROCEEDING Bearer capability
11 RADIO BEARER SETUP UL/DL 64kbps RAB is allocated, with all
corresponding parameters. Target RRC state is
cell_DCH.
COMPLETE
Called UE NW
13 PAGING (type 1)
14 RRC CONNECTION REQUEST Cause = Terminated conversational call
COMPLETE
22 SETUP (CC)
23 CALL CONFIRM
24 RADIO BEARER SETUP NW specifies the configuration of AMR 12,2. RRC
target state should be cell_DCH

COMPLETE
Calling Called
UE UE
26 ALERT MESSAGE
27 CONNECT
28 CONNECT ACK
29 MODIFY
30 RADIO BEARER SETUP RAB is changed from 64/64 kbps to AMR 12,2
RECON FIGURATION kbps
RECON FIGURATION
COMPLETE
32 MODIFY COMPLETE

33 CS call is established
34
35
Remarks:

Success
CELL_DCH: Success


F_6.3.1 UE initiated PS call QoS offered by Network is the requested QoS
Test Purpose:
To test the UE behaviour when the NW responds to the PDP context activation request with the
requested QoS.
Reference: 3GPP TS 24.008 clauses 6.1.3.1 and 6.1.3.1.1
Pre-requisites:
The UE has to be attached.

The UE has to be in idle mode
The UE and the network shall be prepared to establish and use a PS session
Test Procedure:
Attached UE shall initiate a ACTIVATE PDP CONTEXT REQUEST

The QoS requested by the UE has to match the QoS in the ACTIVATE PDP CONTEXT ACCEPT
message, which the NW has to reply.
Start data transfer using DL and UL.
Test Verification:
Verify that the monitored sequence is correct.
Message Flow:

UE NW
1 UE The Tester shall initiate a PS
session
2 --> RRC CONNECTION REQUEST (CCCH) RRC
3 <-- RRC CONNECTION SETUP (CCCH) RRC - Target RRC state is
either cell_DCH or
cell_FACH.
4 --> RRC CONNECTION SETUP COMPLETE (DCCH) RRC
5 --> SERVICE REQUEST GMM
6 <-- AUTHENTICATION AND CIPHERING REQUEST* GMM
7 --> AUTHENTICATION AND CIPHERING RESPONSE* GMM
8 <-- SECURITY MODE COMMAND RRC
9 --> SECURITY MODE COMPLETE RRC
10 --> ACTIVATE PDP CONTEXT REQUEST SM
11 <-- RADIO BEARER SETUP RRC RAB SETUP - Target
RRC state is either cell_DCH
or
cell_FACH.
12 --> RADIO BEARER SETUP COMPLETE RRC
13 <-- ACTIVATE PDP CONTEXT ACCEPT SM
Verify the user plane


Remarks:

1 E_11.1.1.1 QoS offered by network is requested QoS
Success (Data integrity protection algorithm is not applied)
* = so marked messages are optional


F_6.3.2 UE initiated PS call QoS rejected by UE
Test Purpose:
The Test purpose is to verify the QoS reject procedure.
Reference: 3GPP TS 24.008 clause 6.1.3.1.1
Pre-requisites:

The UE has an internal minimum QoS that is higher than the subscribed QoS.
Test Procedure:
The UE has to request a PDP context activation with a subscribed QoS. The NW offers the subscribed
QoS. The UE has to reject this offer by sending the DEACTIVATE PDP CONTEXT REQUEST
message, because the minimum QoS is higher than the requested QoS.
Test Verification:
Message Flow:

UE NW
session
either cell_DCH or
cell_FACH.
10 --> ACTIVATE PDP CONTE XT REQUEST SM
or
cell_FACH.
13 <-- ACTIVATE PDP CONTEXT ACCEPT Accept the PDP context
activation
(NW accept with a
subscribed QoS
14 --> DEACTIVATE PDP CONTEXT REQUEST UE rejects because the
negotiated QoS is lower than
the minimum QoS set in the
UE
15 <-- DEACTIVATE PDP CONTEXT ACCEPT

16 <-- RRC CONNECTION RELAESE

17 --> RRC CONNECTION RELAESE COMPLETE
Remarks:

5 E_11.1.1.2.2 QoS offered by the network is a lower QoS / QoS rejected by UE
*= so marked messages are optional


F_6.3.3 UE initiated PS call with UE initiated PDP context modification
Test Purpose:
The Test purpose is to verify if the PDP context modification. The requested QoS is to be offered and
accepted by the NW.
Pre-requisites:
Test Procedure:
After having an active PDP context it is to be modified. The requested QoS in the MODIFY PDP
CONTEXT REQUEST message is to be accepted by the NW with the MODIFY PDP CONTEXT
ACCEPT message. Start data transfer using DL and UL.
Test Verification:

Verify the integrity of the data.
Message Flow:
UE NW
session
either cell_DCH or
cell_FACH.
or
cell_FACH.
13 <-- ACTIVATE PDP CONTEXT ACCEPT
14 --> MODIFY PDP CONTEXT REQUEST (UE TO Request the modification of
NETWORK DIRECTION) a PDP context, with new
QoS
15 <-- RADIO BEARER
RECONFIGURATION
16 --> RADIO BEARER
17 <-- MODIFY PDP CONTEXT ACCEPT (NETWORK TO UE Accept the PDP context
DIRECTION) modification with QoS
requested


Remarks:

1a B_8.1.2.1 RRC/ RRC Connection Establishment in Cell_DCH state: Success
4 B_11.2.2.1 UE initiated PDP context modification/ UE initiated PDP context
modification accepted by network
7 B_8.2.2.1 Radio Bearer Reconfiguration


F_6.3.4 UE initiated successful secondary PDP context activation/ QoS offered by Network is
the requested QoS
Test Purpose:
It is to be verified the correct behaviour of the NW and UE for the secondary PDP context activation
with the requested QoS.
Pre-requisites:

Test Procedure:
PDP context activation is successful established. The tester requests secondary PDP context
activation. The ACTIVATE SECONDARY PDP CONTEXT REQUEST has to be acknowledged by the
NW with the ACTIVATE SECONDARY PDP CONTEXT ACCEPT message offering the requested
QoS. Start data transfer using DL and UL.
Test Verification:
Message Flow:
UE NW
session
3 <-- RRC CONNECTION SETUP (CCCH) RRC
11 <-- RADIO BEARER SETUP RRC RAB SETUP
14 UE Initiate a secondary PDP
context activation
15 --> ACTIVATE SECONDARY PDP CONTEXT REQUEST Request a Secondary PDP
context activation
18 <-- ACTIVATE SECONDARY PDP CONTEXT ACCEPT Accept the Secondary PDP
context activation
19 NW Wait for T3380 seconds to
ensure no further activate
request messages come
from the UE


Remarks:

5 B_11.1.4.1.1 Successful secondary PDP context activation initiated by UE/ QoS
offered by Network is the requested QoS


F_6.3.5 UE initiated unsuccessful secondary PDP Context Activation
Test Purpose:
It is to verify the correct behaviour from UE and NW for a rejected secondary PDP Context Activation.
Pre-requisites:

Test Procedure:
activation. The ACTIVATE SECONDARY PDP CONTEXT REQUEST has to be rejected by the NW
with the ACTIVATE SECONDARY PDP CONTEXT REJECT message. Start data transfer using DL
and UL.
Test Verification:

Message Flow:
UE NW
session
context activation
context activation
16 <-- ACTIVATE SECONDARY PDP CONTEXT REJECT NW rejects the Secondary
PDP context activation with
cause '#43: unknown PDP
context'
from the UE


Remarks:

4 E_11.1.4.2 Unsuccessful secondary PDP Context Activation initiated by UE


F_6.3.6 Network initiated PDP context modification (QoS higher than or equal to the minimum
QoS set in the UE)
Test Purpose:
It is to be verified that the UE properly react on the NW initiated MODIFY PDP CONTEXT REQUEST
message.
Pre-requisites:

The UE has to have the state to establish a PS session
Test Procedure:
A PDP context is activated by the user and accepted by the NW. The tester triggers the sending of a
MODIFY PDP CONTEXT REQUEST message to the UE with a QoS that is acceptable to the UE
(higher than or equal to the minimum QoS set in the UE). The UE shall send a MODIFY PDP
CONTEXT ACCEPT message in return. Start data transfer using DL and UL.
Test Verification:

Message Flow:

UE NW
session
14 <-- MODIFY PDP CONTEXT REQUEST (NETWORK TO Request the modification of
UE DIRECTION) a PDP context, with QoS
higher than or equal to the
minimum QoS set in the UE
<--
-->
15 --> MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK Accept the PDP context
DIRECTION) modification
16 <-- RADIO BEARER RECONFIGURATION
17 --> RADIO BEARER RECONFIGURATION COMPLETE


Remarks:

4 B_11.2.1 Network initiated PDP context modification
7 B_8.2.2.1 Radio Bearer Reconfiguration


F_6.3.7 Network initiated PDP context modification (lower than the minimum QoS set in the
UE).
Test Purpose:
It is to be verified that the UE properly react on the NW initiated MODIFY PDP CONTEXT REQUEST
message.
Pre-requisites:

The UE has to have the state to establish a PS session
Test Procedure:
A PDP context is activated by the user and accepted by the NW. The tester triggers the sending of a
MODIFY PDP CONTEXT REQUEST message to the UE with a QoS that is not acceptable to the UE
(lower than the minimum QoS set in the UE). The UE shall send a DEACTIVATE PDP CONTEXT
REQUEST message in return.
Test Verification:
Message Flow:

UE NW
session
14 <-- MODIFY PDP CONTEXT REQUEST (NETWORK TO Request the modification of
UE DIRECTION) a PDP context, QoS lower
than the minimum QoS set in
the UE
15 --> DEACTIVATE PDP CONTEXT REQUEST Initiate the PDP context
deactivation. Cause set to
'QoS not acceptable'
16 <-- DEACTIVATE PDP CONTEXT ACCEPT Accept the PDP context
deactivation

Remarks:

4 B_11.2.1 Network initiated PDP context modification
7 B_8.1.3.1 RRC / RRC Connection Release


F_6.3.8 UE initiated PDP Context Modification not accepted by the network
Test Purpose:
It is to test if the PDP Context Modification procedure is properly rejected by network.
Reference: 3GPP TS 24.008 clauses 6.1.3.3, 6.1.3.3.2 and 6.1.3.3.3.
Pre-requisites:

Test Procedure:
A PDP context is activated by the user and accepted by the NW. The UE initiates a PDP context
modification by sending a MODIFY PDP CONTEXT REQUEST message. The NW rejects the context
modification and replies with the MODIFY PDP CONTEXT REJECT with cause set to # 26: insufficient
resources. Start data transfer using DL and UL.
Test Verification:

Message Flow:
UE NW
session
14 --> MODIFY PDP CONTEXT Request (UE TO NETWORK
DIRECTION)
15 <-- MODIFY PDP CONTEXT REJECT
ensure no further MODIFY
PDP CONTEXT REQUEST
(UE TO NETWORK
DIRECTION) messages are
sent by the UE
17 Check that the context is still
active.


Remarks:

4 E_11.2.2.2 UE initiated PDP Context Modification not accepted by the network


F_6.3.9 PDP context deactivation initiated by UE
Test Purpose:
To test the UE and NW behaviour upon receipt the DEACTIVATE PDP CONTEXT ACCEPT message.
Reference: 3GPP TS 24.008 clause 6.1.3.4, 6.1.3.4.1
Pre-requisites:

Test Procedure:
A PDP context is activated by the user and accepted by the NW. The user then requests PDP context
deactivation. The UE shall send a DEACTIVATE PDP CONTEXT REQUEST message to the NW. The
NW shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message. The NW shall then wait
for T3390 seconds to ensure T3390 has been stopped and that no further messages are sent from the
UE.
Test Verification:

Message Flow:
UE NW
session
14 UE Initiate PDP context
deactivation
15 --> DEACTIVATE PDP CONTEXT REQUEST Request a PDP deactivation
16 <-- DEACTIVATE PDP CONTEXT ACCEPT Accept PDP context
deactivation
17 <-- RRC CONNECTION RELEASE
18 --> RRC CONNECTION RELEASE COMPLETE
ensure that no further
deactivate request
messages are sent


Remarks:

Success


F_6.3.10 PDP context deactivation initiated by network
Test Purpose:
To test the UE and NW behaviour upon receipt the DEACTIVATE PDP CONTEXT ACCEPT message.
Reference: 3GPP TS 24.008 clauses 6.1.3.4, 6.1.3.4.2
Pre-requisites:

Test Procedure:
A PDP context is activated by the user and accepted by the NW. The NW then sends a DEACTIVATE
PDP CONTEXT REQUEST message. The UE shall reply with a DEACTIVATE PDP CONTEXT
ACCEPT message.
Test Verification:

Message Flow:

UE NW
session
activation
14 <-- DEACTIVATE PDP CONTEXT REQUEST NW initiates Deactivate PDP
context
15 --> DEACTIVATE PDP CONTEXT ACCEPT UE accepts deactivation
17 --> RRC CONNECTION RELEASE COMPLETE


Remarks:

5 B_11.3.2 PDP context deactivation initiated by the network


F_6.3.11 PDP context activation rejected by the network
Test Purpose:
To test the correct behaviour of UE and NW upon the receipt of the Activate PDP context Reject
message.
Reference: 3GPP TS 24.008 clause 6.1.3.1.3; 6.1.3.1.5
Pre-requisites:

Test Procedure:
The UE has to send the ACTIVTE PDP CONTEXT REQUEST message. The network has to reject
this request with the ACTIVATE PDP CONTEXT REJECT message. The reject reason has to be #
27:missing or unknown APN.
Test Verification:
Message Flow:

UE NW
session
11 <--
12 -->
13 <-- ACTIVATE PDP CONTEXT REJECT Reject the PDP context
activation (# 27: missing or
unknown APN)


Remarks:



F_6.3.12 PDP context preservation NW initiated reestablishment
Test Purpose:
To test the UE and NW behaviour for the PDP context preservation procedure.
Reference: 3GPP TS 23.060 clauses 9.2.5.2; 6.12.2
Pre-requisites:

Test Procedure:
A PDP context has to be active. While having an inactive PDP context the PDP context inactivity timer
has to expire. This triggers the network to release the dedicated RAB, while the PDP context remains
active. The network has to page the UE to re-establish the RAB. Send data on UL an DL to ensure
that the PDP context is active.
Test Verification:

Message Flow:

UE NW
1 NW PDP context inactivity timer
expires
2 <-- RADIO BEARER RELEASE
3 --> RADIO BEARER RELEASE COMPLETE
6 <-- Paging NW pages for UE


Remarks:

1 B_8.2.3.1 RRC/ Radio Bearer Release for transition from CELL_DCH to
CELL_DCH: Success



F_6.3.13 PDP context preservation UE initiated establishment
Test Purpose:
To test the UE and NW behaviour for the PDP context preservation procedure.
Reference: 3GPP TS 23.060 clauses 9.2.5.2; 6.12.2
Pre-requisites:

Test Procedure:
A PDP context has to be active. While having an inactive PDP context the PDP context inactivity timer
has to expire. This triggers the network to release the dedicated RAB. The UE has to send a service
request to re-establish the RAB. Send data on UL a DL to ensure that the PDP context is active.
Test Verification:

Message Flow:

UE NW
1 NW PDP context inactivity timer
expires
2 <-- RADIO BEARER RELEASE
3 --> RADIO BEARER RELEASE COMPLETE
6 UE UE starts with Service
request procedure


Remarks:

1 B_8.2.3.1 RRC/ Radio Bearer Release for transition from CELL_DCH to
CELL_DCH: Success



F_6.3.14 NW initiated PS call
Test Purpose:
The purpose of this test is to verify , that a NW initiated PDP Context activation is possible.
Pre-requisites:

Test Procedure:
The tester initiates a PDP Context activation from the NW side

The UE starts the PDP context activation procedure.
Start data transfer using DL and UL.
Test Verification:

Message Flow:

UE NW
1 NW The Tester shall initiate a PS
session from the NW side
2 <-- PAGING TYPE1 (PCCH) Paging
Target RRC state is either
cell_DCH or
cell_FACH.
11 <-- REQUEST PDP CONTEXT ACTIVATION SM
cell_DCH or


cell_FACH.
Verify the integrity of the
user plane
Remarks:

1 E_11.1.2 PDP context activation requested by the network, successful and
unsuccessful


F_6.3.15 2 primary PDP context activation
Test Purpose:
The test purpose is to verify, that it is possible to activate an additional primary PDP context.
Pre-requisites:

Test Procedure:
After having an active PDP context is activated a second primary context (with a different APN/PDP
address) is activated.
Test Verification:

Message Flow:

UE NW
1 UE The Tester shall initiate a
PDP context with APN/PDP
address x.
cell_DCH or
cell_FACH.
cell_DCH or
cell_FACH.
Verify the integrity of the
user plane
14 UE The Tester shall initiate a
second primary PDP context


with APN/PDP address y.

cell_DCH or
cell_FACH.
Verify the integrity of the first
and second user plane
* optional
Remarks:



F_6.3.16 2 secondary PDP context activation
Test Purpose:
The test purpose is to verify, that it is possible to activate an additional secondary PDP context.
Pre-requisites:

Test Procedure:
activation (same APN/PDP address as the primary one, but a different QoS profile). After having an
active secondary PDP context a second secondary context (with a same APN/PDP address, but
different QoS profile) is activated. Start data transfer using DL and UL.
Test Verification:

Message Flow:

UE NW
session
context activation (same
APN/PDP address but
different QoS profile to the
primary context)
context activation


context activation
from the UE
context activation (same
APN/PDP address but
different QoS profile to the
primary and the other
secondary context)
context activation
22 <-- RADIO BEARER SETUP RRC RB SETUP
context activation
NW Wait for T3380 seconds to
from the UE
* optional
Remarks:

5 B_11.1.4.1.1 Successful secondary PDP context activation initiated by UE/ QoS
offered by Network is the requested QoS


F_6.3.17 Transport channel type switching From CELL_DCH to CELL_FACH, and

CELL_FACH to CELL_DCH
Test Purpose:
The purpose of this test is to verify the successful transport channel type switching according to the
control of UTRAN.
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH_ DCH (state 6-10) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in CELL_DCH state and PS data is transferred between PS CN and UE. Stop data
transmission both in DL and UL directions, RNC sends TRANSPORT CHANNEL
RECONFIGURATION, indicating the new channel parameters of the same cell. UE then reconfigures
the new channel parameters according to the message and finally transmit a TRANSPORT CHANNEL
RECONFIGURATION COMPLETE message using AM RLC to RNC.
UE starts to upload a big file which can trigger a traffic volume measurement report. According to
report, the RNC sends TRANSPORT CHANNEL RECONFIGURATION, indicating the new channel
parameters of the same cell. UE then reconfigures the new channel parameters according to the
message and finally transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE message
using AM RLC to RNC. PS data transmission starts again.
Test Verification:
.
At the first TRANSPORT CHANNEL RECONFIGURATION message sent by the RNC to the UE,
verify that RRC State indicator IE is CELL_FACH, "Uplink DPCH Info" IE and Downlink DPCH
Info IEs are not specified, and corresponding TrCH information elements and UL/DL radio resources
are correct. The transport channel is switched from DCH to common type.
At the second reconfiguration procedure, verify that RNC sends to UE the TRANSPORT CHANNEL
RECONFIGURATION message, in which RRC State indicator IE is CELL_DCH, "Uplink DPCH Info"
IE and Downlink DPCH Info IEs are specified, and corresponding TrCH information elements and
UL/DL radio resources are correct. The transport channel is switched from common type to DCH.
After reconfiguration, the UE sends TRANSPORT CHANNEL RECONFIGURATION COMPLETE

message to the RNC and turn into correct state.


Message Flow:

UE NW
1 UE is in CELL_DCH state. Stop data transmission
1a MEASUREMENT REPORT Triggered by traffic volume Event 4b.(optional)
2 TRANSPORT CHANNEL
RECONFIGURATION
UE performs reconfiguration.
3 TRANSPORT CHANNEL This message should be sent on the common
RECONFIGURATION COMPLETE physical channel.
Check that the CELL_FACH state is reached
4 Start PS data transmission from UE.
4a MEASUREMENT REPORT Triggered by traffic volume Event 4a.(optional)
5 TRANSPORT CHANNEL
RECONFIGURATION
UE performs reconfiguration.
6 TRANSPORT CHANNEL This message should be sent on the dedicated
RECONFIGURATION COMPLETE physical channel.
PS Data transmission
Remarks:
The transport channel type switching can also be realized by RADIO BEARER RECONFIGURATION
depending on realizations of different vendors.
Measurement report event 4a and 4b could be a trigger for this test case, but it is depending on the
realisation of the different vendors.

1 RRC / Transport channel reconfiguration from CELL_DCH to CELL_FACH:
B_8.2.4.7
Success


F_6.3.18 Change of PS radio bearer through RRC Radio Bearer Reconfiguration
Test Purpose:
To confirm that the UE reconfigures the radio bearers according to a RADIO BEARER
RECONFIGURATION message, which indicates a modification of the RB parameters to use in uplink
and downlink.
Reference: 3GPP TS 25.331 clause 8.2.2.
Pre-requisites:
Configurations: A, B, C, D, E
A PS call has been established using the default PS call setup.
Test Procedure:
The UE is in CELL_DCH state. Radio and/or test conditions are modified so that the criterion (or
criteria) for triggering a PS RB change (downgrade) is satisfied. The NW transmits a RADIO BEARER
RECONFIGURATION message to the UE, which commands a modification of the RB combination to
use. The RNC shall allocate a PS I/B RB to the UE with a lower bit rate (in UL and DL if possible - only
in DL otherwise) than the original RB. The UE reconfigures the new physical channel and transmits a
RADIO BEARER RECONFIGURATION COMPLETE message on the DCCH using AM RLC.
Radio and/or test conditions are again modified so that the criterion (or criteria) for triggering a PS RB
change (upgrade) is satisfied. The NW transmits a RADIO BEARER RECONFIGURATION message
to the UE, which commands a modification of the RB combination to use. The RNC shall allocate a PS
I/B RB to the UE with a higher bit rate (in UL and DL if possible - only in DL otherwise) than the
original RB. The UE reconfigures the new physical channel and transmits a RADIO BEARER
RECONFIGURATION COMPLETE message on the DCCH using AM RLC.
Test Verification:

Verify that both the UE and UTRAN use the correct RB configuration after each reconfiguration.
Verify that the data throughput is at the correct rate.
Message Flow:

UE NW
1 RADIO BEARER RECONFIGURATION A RB with a lower bit rate is

allocated
2 RADIO BEARER RECONFIGURATION
COMPLETE
3 RADIO BEARER RECONFIGURATION A RB with a higher bit rate is
allocated
COMPLETE
Remarks:
After steps 1 and 3 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE
message on the new DPCH after the specified activation time has expired.
After steps 2 and 4, PS data shall be exchanged between UE and NW to check that new RBs are
applied on both sides.



1 8.2.X.X* RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH:
Success
*There is no protocol test case in 34.123-1 covering this scenario


F_6.3.19 Change of PS radio bearer through RRC Radio Bearer Reconfiguration in soft
handover (inter-RNC)
Test Purpose:
To confirm that while in macro-diversity, the UE reconfigures the radio bearers according to a RADIO
BEARER RECONFIGURATION message, which indicates a modification of the RB parameters to use
in uplink and downlink.
Pre-requisites:
Configurations: E (Iur connection is needed)

A PS call has been established using the default PS call setup, and the UE is in macro-diversity with 2
cells belonging to different RNCs
Test Procedure:
The UE is in CELL_DCH state. Radio and/or test conditions are modified so that the criterion (or
criteria) for triggering a PS RB change (downgrade) is satisfied. The NW transmits a RADIO BEARER
RECONFIGURATION message to the UE, which commands a modification of the RB combination to
use. The RNC shall allocate a PS I/B RB to the UE with a lower bit rate (in UL and DL if possible - only
in DL otherwise) than the original RB. The UE reconfigures the new physical channel and transmits a
RADIO BEARER RECONFIGURATION COMPLETE message on the DCCH using AM RLC.
Radio and/or test conditions are again modified so that the criterion (or criteria) for triggering a PS RB
change (upgrade) is satisfied. The NW transmits a RADIO BEARER RECONFIGURATION message
to the UE, which commands a modification of the RB combination to use. The RNC shall allocate a PS
I/B RB to the UE with a higher bit rate (in UL and DL if possible - only in DL otherwise) than the
original RB. The UE reconfigures the new physical channel and transmits a RADIO BEARER
Test Verification:

Verify that both the UE and UTRAN use the correct RB configuration after each reconfiguration.
Verify that the same bit rate (i.e. SF) is allocated in both cells
Message Flow:
UE NW
1 RADIO BEARER RECONFIGURATION A RB with a lower bit rate is

allocated
COMPLETE
3 RADIO BEARER RECONFIGURATION A RB with a higher bit rate is
allocated
COMPLETE
Remarks:
After steps 1 and 3 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE
message on the new DPCH after the specified activation time has expired.
After steps 2 and 4, PS data shall be exchanged between UE and NW to check that new RBs are
applied on both sides.



1 8.2.X.X* RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH:
Success
*There is no protocol test case in 34.123-1 covering this scenario


F_6.4.1 Multi-Service: Mobile Originate AMR then PS data call
Test Purpose:
The purpose of this test is to verify the UE can make an AMR voice call and PS data call
simultaneously
References: 3GPP TS 25.331, 3GPP TS 24.008 clauses 6.1.3.1 and 6.1.3.1.1
Pre-requisites:
Test Procedure:
UE camps on a suitable cell and perform successful location update and PS attach.
UE originates an AMR call.
UE originates a PS data call.
Test Verification:
Verify that both AMR and PS data calls were setup properly.
Verify that audio quality is not affected after both calls were setup.
Verify that data throughput is not affected after both calls were setup.
Message Flow:
UE NW
UE camps and performs a

and a successful PS attach.
1 RRC CONECTION REQUEST UE originates an AMR call
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
9 SETUP MESSAGE
10 CALL PROCEEDING
COMPLETE
13 ALERT MESSAGE
14 CONNECT MESSAGE
16 GMM SERVICE REQUEST
AUTHENTICATION and
CIPHERING REQUEST

(OPTIONAL)
17 AUTHENTICATION and
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
20 ACTIVATE PDP CONTEXT
MESSAGE
COMPLETE
ACCEPT
Start data transfer Data transfer can be initiated by launching web
browser or access a known ftp server.
Remarks:

Success


F_6.4.2 Mobile Originate PS data call and AMR call
Test Purpose:
The purpose of this test is to verify that UE can make a PS data call then an AMR call simultaneously.
Pre-requisites:
Test Procedure:
UE camps on a suitable cell and performs successful PS attach and location update.
UE originates a PS data call. Data rate is to be determined depending on the available

configuration offered by the network.
Test Verification:
Message Flow:
UE NW
1 RRC CONNECTION UE originates a PS data call.

REQUEST Note: Configuration of PS data call depends the
networks availability.
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
MESSAGE
COMPLETE
ACCEPT
(OPTIONAL)
18 AUTHENTICATION
RESPONSE (OPTIONAL)



COMPLETE
21 CM SERVICE ACCEPT
22 SETUP MESSAGE
23 CALL PROCEEDING
COMPLETE
26 ALERT MESSAGE
27 CONNECT MESSAGE
Remarks:

Success


F_6.4.3 Multi-Service: Attach on Demand
Test Purposes:
The purpose of this test is to verify the UEs ability to perform an Attach on Demand in a multi-service
call.
Pre-requisites:
Test Procedure:
The UE camps on the network and performs a Location Update (CS domain only).
UE initiates an AMR voice call.
UE initiates a PS data call.
Test Verification:
Verify that UEs location update on the CS domain is successful.
Verify that the AMR call is properly setup with proper audio on both UL and DL.
Verify that UE performs an Attach prior proceeding with the PS data call.
Verify data throughput both Uplink and Downlink.
Message Flow:

UE NW
UE camps and performs a Location Update on CS
domain.
1 RRC CONECTION REQUEST UE originates an AMR call.
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
9 SETUP MESSAGE
10 CALL PROCEEDING
COMPLETE
13 ALERT MESSAGE
14 CONNECT MESSAGE
UE performs a PS Attach.
16 PS ATTACH REQUEST
17 IDENTITY REQUEST
(OPTIONAL)
CIPHERING REQUEST
(OPTIONAL)



UE NW
19 AUTHE NTICATION and
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
22 PS ATTACH ACCEPT
23 PS ATTACH COMPLETE
UE performs PS call
CIPHERING REQUEST
(OPTIONAL)
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
29 ACTIVATING PDP CONTEXT
MESSAGE
31 RDADIO BEARER SETUP
COMPLETE
ACCEPT
Start data transmission
Remarks:

Success


F_6.4.4 Multi-Service: PS/AMR-UE receives SMS message
Purpose:
The purpose of this test is to verify that UE can receive an SMS message while it is in a multi-service
call.
Pre-requisites:
UE performs Location Update and Attach successfully.
Test Procedure:
Network sends an arbitrary SMS message in CS domain.
Test Verification:
Verify that audio quality is good on both UL and DL.
Verify data throughput on both UL and DL.
Verify that the UE successfully receives a SMS message. (User should verify the contents of
SMS message)
Message Flow:
UE NW
PS call and AMR call have
been previously established
1 CP-DATA UE receives SMS from NW
2 CP-ACK
WAIT
3 CP-ACK (RP -ACK RPDU)
4 CP-ACK
Remarks:


F_6.4.5 Multi-Service: PS/AMR-NW releases the AMR call
Purpose:
The purpose of this test is to verify that the UE can continue to sustain a PS call after the AMR call is
released in a Multi-Service call.
References:
Pre-requisites:
PS data and AMR calls have been successfully established.
Test Procedure:
NW releases the AMR call.
Test Verification:
Verify that the AMR is released properly.

Verify that the data throughput is not affected after the ANR call is released.
Message Flow:

UE NW

NW releases AMR call
2 RELEASE MESSAGE
3 RELEASE COMPLETE
MESSAGE
4 RADIO BEARER RELEASE
COMPLETE
Remarks:

3 B_10.1.2.7.2 U11 disconnect request / RELEASE received


F_6.4.6 Multi-Service: PS/AMR-NW releases the PS Data Call
Purpose:
The purpose of this test is to verify that the UE can sustain the AMR call after the network releases the
PS data call.
References: 3GPP TS 25-331, 3GPP TS 24-008
Pre-requisites:
PS data and AMR calls have been successfully established.
Test Procedure:
NW releases the PS data call.
Test Verification:
Verify that the PS data call is released properly.

Verify that the AMR call is not interrupted and audio quality is not affected after the PS data
call is released.
Message Flow:

UE NW

NW releases PS data call
1 DE-ACTIVATE PDP
CONTEXT
2 DE-ACTIVATE PDP
CONTEXT ACCEPT
COMPLETE
Remarks:



F_6.4.7 Multi-Service: PS/AMR Intra-node B Inter-Freq Hand Over, blind
Purpose:
The purpose of this test is to verify that in a Multi-Service call when the UE satisfies the criteria for
being handed over to another frequency, an inter-frequency handover can successfully be performed
by the UTRAN and UE. For this particular test case, no inter-frequency measurements are made by
the mobile.
Reference: TS 34-108, TS 25-331.
Pre-requisites:
Configuration: B or C (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel
2)
Intra-frequency measurements are set up by UTRAN using a MEASUREMENT CONTROL
message (or SIB#11).
SIB#11 of cell1 is configured to show parameters of cell 2.
A CS and PS call has been established with cell 1, and the UE is in the following state:
For CS+PS: UE is in CS+PS-DCCH+DTCH_DCH (state not described in 34.108 v3.8.0).
Test Procedure:
Intra node B/Inter-Frequency Hand Over procedure is triggered.
Note: in this test case, intra-frequency measurements are set up by UTRAN and can be used as a
criterion for triggering the inter-frequency hard handover. However, other criteria can be used.
UE is sending measurement reports (if configured by UTRAN). Test conditions are then
changed so that the criterion/criteria for triggering an inter-frequency handover to cell 2 is/are
fulfilled.
RNC sends RADIO BEARER RECONFIGURATION or PHYSICAL CHANNEL
RECONFIGURATION to UE, giving the parameters of cell 2. The UE configures layer 1 to
begin reception on the new frequency.
After the UE receives confirmation from its physical layer, a RADIO BEARER
RECONFIGURATION COMPLETE or PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message is sent to the RNC.
Test Verification:
Verify that after the inter-frequency hard handover, the quality of the transmission is as
follows:
1) No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality
Estimate (QE) and the CRC Indication (CRCI) in the uplink dedicated FP frames, as
specified in TS 25.427.
2) No degradation of the downlink BLER shall be seen on the UE log, if available
Voice quality: No major disturbance to be heard in the landline phone or in the UE
3) Packet call: no major impact on throughput. The TCP repetitions shall be checked. On
the Iub, there should be no or only a few RLC retransmission or reset of the protocol.
4) After step 1, check the consistency of the measurements reported by the mobile. The
measurements shall not contain inter-frequency measurements.
5) After step 4, check that the RNC requests an inter-frequency hard HO by sending a RB
reconfiguration or PHYSICAL CHANNEL RECONFIGURATION message to the UE.
6) After step 5, check that the UE responds on the UTRA RF channel 2.


7) After step 6, check that the old radio link with cell 1 (on UTRA RF channel 1) was
deleted.
Message Flow:

UE NW
PS and CS call have been previously

established
1 MEASUREMENT REPORT UE returns intra-frequency
measurements, as requested
by UTRAN.
2 The tester modifies radio
conditions according to the
test procedure.
by UTRAN.
4 Inter-frequency handover decision Made by the RNC
5 RADIO BEARER RECONFIGURATION or RRC With parameters of
PHYSICAL CHANNEL cell2
RECONFIGURATION (DCCH)
6 RADIO BEARER RECONFIGURATION RRC
COMPLETE or PHYSICAL CHANNEL
RECONFIGURATION COMPLETE (DCCH)
Remarks:
Test to be performed in different cell but same sector.

1 B_8.2.2.1 RRC / Radio Bearer Reconfiguration (Hard Handover) from CELL_DCH
2 B_8.2.6.1 RRC / Physical channel reconfiguration for transition from CELL_DCH


F_6.4.8 Multi-Service: PS/AMR Intra-nodeB Inter-freq Hand Over, with measurements
Purpose:
To check that in a Multi-Service call when the UE satisfies the criteria for being handed over to
another frequency, an inter-frequency handover can successfully be performed by the UTRAN and
UE. For this particular test case, inter-frequency measurements are made by the mobile using
compressed mode or a dual receiver, depending on UE capabilities.
References: TS-34.108, TS -25.331.
Pre-requisites:
Configuration: B or C (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel
2)
Inter-frequency measurements are set up by UTRAN using a MEASUREMENT CONTROL
SIB#11 of cell1 is configured to show parameters of cell 2.
A PS call and CS call have been established with cell 1, and the UE is in the following state:
For CS+PS: UE is in CS+PS-DCCH+DTCH_DCH (state not described in 34.108 v3.8.0)
Test Procedure:
Intra node B/Inter-Frequency Hand Over procedure is triggered.
Note: depending on UE capabilities, compressed mode can be configured during the call setup(for
FDD).
UE is sending inter-frequency measurement reports. Test conditions are then changed so that
the criterion/criteria for triggering an inter-frequency handover to cell 2 is/are fulfilled. RNC
sends RADIO BEARER RECONFIGURATION or PHYSICAL CHANNEL
RECONFIGURATION to UE, giving the parameters of cell 2.
The UE configures layer 1 to begin reception on the new frequency. After the UE receives
confirmation from its physical layer, a RADIO BEARER RECONFIGURATION COMPLETE or
PHYSICAL CHANNEL RECONFIGURATION COMPLETE message is sent to the RNC.
Test Verification:
follows:
1) To confirm that after the inter-frequency hard handover, the quality of the transmission
is as follows:
2) No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality
3) No degradation of the downlink BLER shall be seen on the UE log, if available
4) Voice quality: No major disturbance to be heard in the landline phone or in the UE
5) Packet call: no major impact on throughput. The TCP repetitions shall be checked
on the Gi interface. On the Iub, there should be no or only a few RLC retransmission
or reset of the protocol.
6) After step 1, check the consistency of the measurements reported by the mobile. The
measurements must contain inter-frequency measurements.
7) After step 4, check that the RNC requests an inter-frequency hard HO by sending a
RB reconfiguration or PHYSICAL CHANNEL RECONFIGURATION message to the
UE.


8) After step 5, check that the UE responds on the UTRA RF channel 2.
9) After step 6, check that the old radio link with cell 1 (on UTRA RF channel 1) was
deleted.
Message Flow:
UE NW
PS and CS call have been previously

established
1 MEASUREMENT REPORT UE returns inter-frequency
by UTRAN.
test procedure.
by UTRAN.
Remarks:

1 B_8.4.1.2 RRC / Measurement Control and Report: Inter-frequency measurement
for transition from idle mode to CELL_DCH state


F_6.4.9 Multi-Service: PS/AMR Inter-node B Inter-freq Hand Over, blind
Purpose:
To check that in a Multi-Service call when the UE satisfies the criteria for being handed over to
another frequency, an inter-node B inter-frequency handover can successfully be performed by the
UTRAN and UE. For this particular test case, no inter-frequency measurements are made by the
mobile.
References: 3GPP TS.34-108, 3GPP TS.25-331
Pre-requisites:
Configuration: D (2 cells: cell 1 on nodeB1 using UTRA RF channel 1, cell 2 on nodeB2 using
UTRA RF channel 2)
SIB#11 of cell1 is configured to show parameters of cell 2
A PS call and CS have been established with cell 1, and the UE is in the following state:
Test Procedure:
Inter node B/Inter-Frequency Blind Hand Over procedure is triggered.
fulfilled. RNC sends RADIO BEARER RECONFIGURATION or PHYSICAL CHANNEL
RECONFIGURATION to UE, giving the parameters of cell 2.
The UE configures layer 1 to begin reception on the new frequency. After the UE receives
confirmation from its physical layer, a RADIO BEARER RECONFIGURATION COMPLETE or
PHYSICAL CHANNEL RECONFIGURATION COMPLETE message is sent to the RNC.
Test Verification:
follows:
1. No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality
2. No degradation of the downlink BLER shall be seen on the UE log, if available
3. Voice quality: no major disturbance to be heard in the landline phone or in the UE
4. Packet call: no major impact on throughput. The TCP repetitions shall be checked on
the Gi interface. On the Iub, there should be no or not too many RLC retransmissions
or reset of the protocol.
5. After step 1, check the consistency of the measurements reported by the mobile. The
6. After step 4, check that the RNC requests an inter-frequency hard HO by sending a
RB reconfiguration or PHYSICAL CHANNEL RECONFIGURATION message to the
UE.
7. After step 5, check that the UE responds on the UTRA RF channel 2.
8. After step 6, check that the old radio link with nodeB1 (on UTRA RF channel 1) was
deleted.


Message Flow:
UE NW
PS and CS calls have been previously

established
by UTRAN.
test procedure.
by UTRAN.
Remarks:



F_6.4.10 Multi-Service: PS/AMR Inter-nodeB Inter-freq Hand Over, with measurements
Purpose:
To verify that in a Multi-Service call when an UE satisfies the criteria for being handed over to another
frequency, an inter-node B inter-frequency handover can successfully be performed by the UTRAN
and UE. For this particular test case, inter-frequency measurements are made by the mobile using
compressed mode or a dual receiver, depending on UE capabilities(for FDD).
References:
Pre-requisites:
Configuration: D (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel 2)
SIB#11 is configured to show parameters of cell 2
A PS data call and an AMR call have been established with cell 1, and the UE is in the
following state:
Test Procedure:
Inter node B/Inter-Frequency Hand Over procedure is triggered.
Note: depending on UE capabilities, compressed mode can be configured during the call setup.
UE is sending measurement reports. Radio conditions are then changed so that the
criterion/criteria for triggering an inter-frequency handover to cell 2 is/are fulfilled.
RNC sends RADIO BEARER RECONFIGURATION or PHYSICA L CHANNEL
Test Verification:
Verify that after the inter-frequency hard handover, the quality of the transmission is as follows:
1. No degradation of the uplink BLER shall be seen on the Iub thanks to the
Quality Estimate (QE) and the CRC Indication (CRCI) in the uplink dedicated FP
frames, as specified in TS 25.427.
3. Voice quality: no major disturbance to be heard in the landline phone or in the
UE
4. Packet call: no major impact on throughput. The TCP repetitions shall be
checked on the Gi interface. On the Iub, there should be no or not too many RLC
retransmissions or reset of the protocol.
5. After step 1, check the consistency of the measurements reported by the
mobile. The measurements must contain inter-frequency measurements.
6. After step 4, check that the RNC requests an inter-frequency hard HO by
sending a RB reconfiguration or PHYSICAL CHANNEL RECONFIGURATION message
to the UE.
8. After step 6, check that the old radio link with node1 (on UTRA RF channel 1)
was deleted.
Message Flow:



UE NW

established
by UTRAN.
test procedure.
by UTRAN.
Remarks:



F_6.4.11 Multi-Service: PS/AMR Inter-RNC Inter-freq Hand Over, blind
Purpose:
To check that in a Multi-Service call when an UE satisfies the criteria for being handed over to another
frequency, an inter-RNC inter-frequency handover can successfully be performed by the UTRAN and
UE. For this particular test case, no inter-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: E (2 cells: cell 1 on nodeB1 using UTRA RF channel 1, cell 2 on nodeB2 using
UTRA RF channel 2)
SIB#11 is configured to show parameters of cell 2 (on UTRA RF channel 2)
A PS data call and CS data call have been established with cell 1, and the UE is in the
following state:
Test Procedure:
Inter RNC /Inter-Frequency Blind Hand Over procedure is triggered.
fulfilled.
SRNC sends RADIO BEARER RECONFIGURATION or PHYSICAL CHANNEL
COMPLETE message is sent to the SRNC (to be checked).
Test Verification:
Verify that after the inter-frequency hard handover, the quality of the transmission is as follows:
1. No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate
(QE) and the CRC Indication (CRCI) in the uplink dedicated FP frames, as specified in TS
25.427.
4. Packet call: no major impact on throughput. The TCP repetitions shall be checked on the
Gi interface. On the Iub, there should be no or not too many RLC retransmissions or reset
of the protocol.
6. After step 4, check that the RNC requests an inter-frequency hard HO by sending a RB
8. After step 6, check that the old radio link with nodeB1 (on UTRA RF channel 1) was
deleted.
Message Flow:



UE NW

established
by UTRAN.
test procedure.
by UTRAN.
Remarks:


F_6.4.12 Multi-Service: PS/AMR Inter-RNC Inter-freq Hand Over, with measurements
Purpose:
To verify that in a Multi-Service call when an UE satisfies the criteria for being handed over to another
frequency, an inter-RNC inter-frequency handover can successfully be performed by the UTRAN and
UE. For this particular test case, inter-frequency measurements are made by the mobile using
compressed mode or a dual receiver, depending on UE capabilities(for FDD).
Pre-requisites:
Configuration: E (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel 2)
A PS data call and CS AMR call have been established with cell 1, and the UE is in the
following state:
Test Procedure:
Inter RNC B/Inter-Frequency Hand Over procedure is triggered.
fulfilled.
RNC sends RADIO BEARER RECONFIGURATION or PHYSICAL CHANNEL
Test Verification:
Verify that the UE can make inter-frequency measurements and return them coherently to
UTRAN
Verify that a new radio link is set up with nodeB2
Verify that the old radio link with nodeB1 is deleted
follows:
1. No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate
25.427.
4. Packet call: no major impact on throughput. The TCP repetitions shall be checked on the
Gi interface. On the Iub, there should be no or not too many RLC retransmissions or reset
of the protocol.
measurements must contain inter-frequency measurements.
6. After step 4, check that the RNC requests an inter-frequency hard HO by sending a RB
8. After step 6, check that the old radio link with node1 (on UTRA RF channel 1) was
deleted. Also, check the quality of the transmission shall be verified, according to the test
verification.


Message Flow:
UE NW

established.
by UTRAN.
test procedure.
by UTRAN.
Remarks:


F_6.4.13 Multi-Service: Mobile Originates PS Call - Network Originates AMR Call
Test Purpose:
The purpose of this test is to verify that UE can make a PS data call then receive an AMR call
originated by the network.
References: 3GPP TS 25.331, 3GPP TS 24.008 clauses 6.1.3.1 and 6.1.3.1.1.
Pre-requisites:
Test Procedure:
UE camps on a suitable cell and performs successful PS attach and location update (The
PS attach can be initiated either automatically or manually. In this cases PS attach will
follow by the Location Update).
Network originates an AMR call to the mobile.
Test Verification:
Message Flow:
UE NW
UE has successfully camped on a suitable cell,

performed location update and attach procedures.
REQUEST Note: Configuration of PS data call depends on
2 RRC CONNECTION SETUP Network can setup RRC Connection in either
Cell_DCH or Cell FACH.
COMPLETE
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
MESSAGE
COMPLETE
ACCEPT
13 Start data transfer Data transfer can be initiated by launching web
14 PAGING TYPE 2 Network initiates an AMR call.
15 PAGING RESPONSE


(OPTIONAL)
17 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
20 SETUP MESSAGE
21 CALL CONFIRMED
COMPLETE
24 ALERT MESSAGE
25 CONNECT MESSAGE
Remarks:
Optional: Network can initiate a measurement control at any point during the test case.

Success


F_6.4.14 Multi-Service: Mobile Releases the AMR First then PS data Call
Test Purpose:
The purpose of this test is to verify that UE can properly terminate the AMR call first then the PS data
call second in a multi-service call.
Pre-requisites:
UE is in a multi-service call
Test Procedure:
UE terminates the AMR call.
UE terminates the PS data call.
Test Verification:
Verify that the AMR was released properly by the UE and no data throughput was affected.
Verify that the PS call was released properly by the UE.
Verify that UE is idle in the current cell after all calls are released.
Message Flow:
UE NW
UE is in a multi-service call.
1 DISCONNECT MESSAGE UE disconnect the AMR call.
2 RELEASE MESSAGE
3 RELEASE COMPLETE
COMPLETE
AMR RAB is releases but PS RAB remains intact.
Verify that throughput is not affected after AMR
RAB was released.
6 DE-ACTIVATE PDP UE release PS data call.
CONTEXT
7 DE-ACTIVATE PDP
CONTEXT ACCEPT
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
UE is idle in the current cell after all calls are
released.
Remarks:
Optional: Network can initiate a measurement control at any point during the test case.



Success


F_6.4.15 Multi-Service: Mobile Releases the AMR First then Network Releases the PS data
Call
Test Purpose:
The purpose of this test is to verify that UE can properly release the AMR call first then the network
releases PS data call second in a multi-service call.
Pre-requisites:
Test Procedure:
UE terminates the AMR call.
UE terminates the PS data call.
Test Verification:
Verify that the AMR was released properly by the UE and no data throughput was affected.
Verify that the PS call was released properly by the NW.
Message Flow:
UE NW
1 DISCONNECT MESSAGE UE disconnect the AMR call.
2 RELEASE MESSAGE
3 RELEASE COMPLETE
COMPLETE
Verify that throughput is not affected after AMR
RAB was released.
6 DE-ACTIVATE PDP UE release PS data call.
CONTEXT
7 DE-ACTIVATE PDP
CONTEXT ACCEPT
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
released.
Remarks:
After step 4, RNC could re-configure PS RAB to a higher data rate (network implementation
dependant).



Success


F_6.4.16 Multi-Service: Mobile Releases the PS Call then Network Releases the AMR Call
Test Purpose:
The purpose of this test is to verify that UE can properly release the PS call first then the network
releases AMR call in a multi-service call.
Pre-requisites:
Test Procedure:
UE releases the PS call.
Network releases the AMR call.
Test Verification:
Verify that the PS call is released properly by the UE and audio quality is not affected during
and after the PS call was released.
Verify that the AMR call was released properly by the network.
Message Flow:
UE NW
1 DEACTIVATE PDP CONTEXT UE disconnect the PS call.
REQUEST
2 DEACTIVATE PDP CONTEXT
ACCEPT
COMPLETE
PS RAB is releases but AMR RAB remains intact.
Verify that audio quality is not affected during and
after PS RAB was released.
5 DISCONNECT Network releases AMR data call.
6 RELEASE
7 RELEASE COMPLETE
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
released.
Remarks:


Success


F_6.4.17 Multi-Service: Network Releases the AMR Call then Mobile Releases the PS Call
Test Purpose:
The purpose of this test is to verify that an UE can perform a multi-service call in which the network
releases the AMR call first the UE releases the PS call.
Pre-requisites:
Test Procedure:
Network releases the AMR call.
UE releases the PS call.
Test Verification:
Verify that the AMR call is released properly by the network and data throughput is not
affected after the AMR call was released.
Verify that the PS call was released properly by the UE.
Message Flow:
UE NW
1 DISCONNECT Network disconnects the AMR call.
2 RELEASE
3 RELESE COMPLETE
COMPLETE
Verify that data throughput is not affected after
AMR RAB was released.
6 DEACTIVATE PDP CONTEXT UE releases PS data call.
ACCEPT
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
released.
Remarks:
After step 4, RNC could re-configure PS RAB to a higher data rate (network implementation
dependant).



Success


F_6.4.18 Multi-Service: Network Releases the PS Call then Mobile Releases the AMR Call
Test Purpose:
The purpose of this test is to verify that an UE can perform a multi-service call in which the network
releases the PS call first the UE releases the AMR call.
Pre-requisites:
Test Procedure:
Network releases the PS call.
UE releases the AMR call.
Test Verification:
Verify that the PS call is released properly by the network and audio quality is not affected
during and after the PS call was released.
Verify that the AMR call was released properly by the UE.
Message Flow:
UE NW
1 DEACTIVATE PDP CONTEXT Network releases the PS call.

ACCEPT
COMPLETE
PS RAB is releases but AMR RAB remains intact.
Verify that audio quality is not affected during and
after PS RAB was released.
5 DISCONNECT UE releases AMR call.
6 RELEASE
7 RELEASE COMPLETE
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE
released.
Remarks:



Success


F_6.4.19 Multi-Service: Mobile Originates PS Data call followed by VT call
Test Purpose:
The purpose of this test is to verify that UE can make a PS data call followed by Video telephony call
simultaneously.
Pre-requisites:
UE camps on a suitable cell and performs successful PS and CS registrations.
Test Procedure:
UE originates a PS data call. Data rate offered depends on the QoS requested by UE and
on the configuration offered by the network.
After PS call is setup while file transfer is on going, UE originates video telephony call.
NW may initiate measurements at any time after establishing RRC Connection.
Test Verification:
Verify that both PS data and VT calls are setup properly.
Verify that data throughput is not affected after adding VT call to PS data call.
Verify that video/audio quality is not affected while UE is active on both PS data and VT calls.
Message Flow:
UE NW

REQUEST Note: Data rate offered depends on configuration
supported by NW.
2 RRC CONNECTION SETUP NW can put UE in CELL_DCH or CELL_FACH
state with this message
COMPLETE
5 GMM AUTHENTICATION AND
CIPHERING REQUEST
(OPTIONAL)
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
REQUEST (SM)
COMPLETE
ACCEPT (SM)
browser or accessing a known ftp server.
13 CM SERVICE REQUEST UE originates VT call
(MM)

(OPTIONAL)
15 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
18 SETUP (CC)
19 CALL PROCEEDING (CC)
COMPLETE
22 ALERT MESSAGE (CC)
23 CONNECT MESSAGE (CC)
(CC)
Video call is up. User should
be able to view other party and
conversation should be
possible between both the
parties
Remarks:

Success


F_6.4.20 Multi-Service: Mobile Originates VT call followed by PS Data call
Test Purpose:
The purpose of this test is to verify that UE can make a Video telephony call followed by PS data call
simultaneously.
Pre-requisites:
UE camps on a suitable cell and performs successful PS and CS registrations.
Test Procedure:
UE originates video telephony call.
While the video conference is taking place, UE originates a PS data call. Data rate offered
depends on the QoS requested by UE and on the configuration offered by the network.
NW may initiate measurements at any time after establishing RRC Connection.
Test Verification:
Verify that both VT and PS Data calls are setup properly.
Verify that video/audio quality is not affected after adding PS Data call to VT call.
Verify that data throughput is not affected when both VT and PS Data calls are active.
Message Flow:
UE NW
1 RRC CONNECTION UE originates VT call

REQUEST
2 RRC CONNECTION SETUP NW can put UE in CELL_DCH or in CELL_FACH
state
COMPLETE
(MM)
(OPTIONAL)
6 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
9 SETUP (CC)
10 CALL PROCEEDING (CC)
11 RADIO BEARER SETUP NW puts UE in CELL_DCH state
COMPLETE
13 ALERT MESSAGE (CC)
14 CONNECT MESSAGE (CC)
(CC)
Video call is up. User should
be able to view other party and
conversation should be
possible between both the

parties
16 GMM SERVICE REQUEST UE originates a PS data call
CIPHERING REQUEST
(OPTIONAL)
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
REQUEST (SM)
22 RADIO BEARER SETUP Note: Data rate offered depends on configuration
supported and available on NW side.
COMPLETE
ACCEPT (SM)
browser or accessing a known ftp server.
Remarks:

Success


F_6.4.21 Multi-Service: NW releases the VT call followed by Mobile originated PS Data call
release
Purpose:
The purpose of this test is to verify that the UE can continue to sustain a PS call after the VT call is
released by network in a Multi-Service call. This test also verifies mobile originated PS Data call
release after releasing VT call.
References:
Pre-requisites:
UE camps on a suitable cell and performs successful CS and PS registrations.
PS Data and VT calls have been successfully established.
Test Procedure:
NW releases the VT call.
Then Mobile releases the PS Data call.
Test Verification:
Verify that the VT call is released properly.
Verify that the data throughput is not affected after releasing VT call.
Verify that PS Data call is released properly.
Message Flow:

UE NW
PS Data call and VT call have

NW releases VT call
1 DISCONNECT (CC)
2 RELEASE (CC)
COMPLETE
Verify that Data through put is
not affected after the VT call
release
Mobile releases PS Data call
REQUEST (SM)
ACCEPT (SM)
COMPLETE
10 RRC CONNECTION
RELEASE
11 RRC CONNECTION
RELEASE COMPLETE


Remarks:

B_8.1.3.2
Successful


F_6.5.1.1 RACH preamble initial power setting (FDD)
Test Purpose:
To verify that the UE UL Initial power for Rach preambles is in line with the formula:
Pini = P-CPICH DL Tx Power + UL Interference + Constant Value - P-CPICH RSCP
References: 3GPP TS 25.214, clause 6 Random access procedure

3GPP TS 25.331 clause 8.5.7 Open loop power control
Pre-requisites:
Configuration: A
Parameters used to set the RACH preamble initial power setting are set in SIB#5 (constant value, P-
CPICH DL Tx power, power ramp step, Preamble retrans max, powerOffsetPp-m) and SIB#7 (UL
Interference)
A spectrum analyzer is needed to perform the test.
- tool on the UE to extract the P-CPICH RSCP measurements
Test Procedure:
a) Initiate a call with the UE. Measure initial power (P ini) for RACH preamble on the spectrum analyzer.
Verify the value of Pini in the UE traces (if available). Verify that the value of Pini is coherent with the
formula stated in the test purpose.
b) Re-start the test procedure, but change the setting of the parameter P-CPICH DL Tx power in
SIB#5 and check that the value of Pini is still coherent with the formula.
c) Re-start the test procedure, but change the setting of the parameter constant value SIB#5 and
check that the value of Pini is still coherent with the formula.
d) Re-start the test procedure, but change the setting of the parameter UL interference in SIB#7 and
check that the value of Pini is still coherent with the formula.
e) Re-start the test procedure, but change the total attenuation between the Node B and the UE so
that P-CPICH RSCP varies, and check that the value of Pini is still coherent with the formula.
Test Verification:
To confirm that the formula to set the initial PRACH preamble power is correctly implemented in the
UE, after each test step.
Message flow:
a)
UE NW
1 SYSTEM INFORMATION
2 RACH preambles are sent
b)
UE NW


c)
UE NW
d)
UE NW
e)
UE NW
Remarks:
Covered protocol tests: None.


F_6.5.1.1a UpPCH transmission power setting (TDD)
Test Purpose:
To verify that the UE transmit power for each UpPCH is in line with the formula:
PUpPCH = LPCCPCH + PRXUpPCHdes+ (i-1) *Pwrramp
References: 3GPP TS 25.224, clause 5.6 Random access procedure

Pre-requisites:
Configuration: A
Parameters used to set the UpPCH transmission power setting are set in SIB5 ( P-CCPCH Tx power
to calculate the pathloss LPCCPCH , PRXUpPCHdes , power ramp step, max SYNC_UL transmissions) .
- tool on the UE to extract the P-CCPCH RSCP measurements
Test Procedure:
a) Initiate a call with the UE. Measure initial power (P UpPCH) for UpPCH on the spectrum analyzer.
Verify the value of PUpPCH in the UE traces (if available). Verify that the value of PUpPCH is coherent with
the formula stated in the test purpose.
b) Re-start the test procedure, but change the setting of the parameter PRXUpPCHdes in SIB#5 and
check that the value of PUpPCH is still coherent with the formula.
c) Re-start the test procedure, but change the setting of the parameter Pwrramp SIB#5 and check that
the value of PUpPCH is still coherent with the formula.
d) Re-start the test procedure, but change the total attenuation between the Node B and the UE so
that LPCCPCH varies, and check that the value of PUpPCH is still coherent with the formula.
Test Verification:
To confirm that the formula to set the UpPCH power is correctly implemented in the UE, after each
test step.
Message flow:
a)
UE NW
2 UpPCH is sent
b)
UE NW
2 UpPCH is sent


c)
UE NW
2 UpPCH is sent
d)
UE NW
2 UpPCH is sent
Remarks:


F_6.5.1.2 RACH power ramping Transmission (FDD)
Test Purpose:
To verify that the UE correctly applies the power ramping procedure defined in 3GPP core
specifications.

Pre-requisites:
Configuration: A
Parameters used to set the RACH preamble initial power are set in SIB#5 (constant value, P-CPICH
DL Tx power, power ramp step, Preamble retrans max, powerOffsetPp-m) and SIB#7 (UL
Interference)

the uplink and downlink has to be seperated Valid for the next test cases as well
UE is camped on the cell Valid for the next test cases as well
Test Procedure:
Disconnect the RX cable at the nodeB side. Initiate a call with the UE. The RX cable being
disconnected, the UE should send UL RACH preambles up to Preamble Retrans Max (set in SIB#5
range = 164).
Test Verification:
To confirm that the number of preambles sent by the UE corresponds to the one set in SIB#5.
Message flow:

UE NW
Remarks:


F_6.5.1.2a UpPCH power ramping Transmission (TDD)
Test Purpose:
To verify that the UE correctly applies the power ramping procedure defined in 3GPP core
specifications.

Pre-requisites:
Configuration: A

UE is camped on the cell Valid.
Test Procedure:
Disconnect the RX cable at the nodeB side. Initiate a call with the UE. The RX cable being
disconnected, the UE should send UpPCH up to max SYNC_UL transmissions (set in SIB5 ).
Test Verification:
To confirm that the number of UpPCH sent by the UE corresponds to the one set in SIB5.
Message flow:

UE NW
2 UpPCHs are sent
Remarks:


F_6.5.1.3 RACH power ramping Timing verification (FDD)
Test Purpose:
To verify that the timing of the RACH preambles sent by the UE is correct.

3GPP TS 25.211 clause 7.3 PRACH/AICH timing relation
Pre-requisites:
Configuration: A
Interference)
Test Procedure:
Disconnect the RX cable at the nodeB side. Initiate a call with the UE. Measure the timing between
each PRACH preamble and check that it is coherent with the values set in SIB#5. Note that according
to 3GPP TS 25.211, the minimum time difference between 2 preambles (p-p,min) is 15,360 chips (3
access slots) if parameter AICH transmission timing is set to 0, and 20,480 chips (4 access slots) if
AICH transmission timing is set to 1.
Test Verification:
Confirm that the timing between each preamble is equal or greater than p-p,min.
Each preamble should start on an access slot, so the timing between preambles should always be a
multiple of (10 / 15 ) x2 = 1.33 ms.
Message flow:

UE NW
Remarks:


F_6.5.1.4 RACH power ramping Power ramp step parameter check (FDD)
Test Purpose:
To verify that the power step used by the UE between each RACH preamble is correct.

Pre-requisites:
Configuration: A
Interference)
Test Procedure:
Disconnect the RX cable at the nodeB side. Initiate a call with the UE. Using the spectrum analyzer,
measure the power difference between each PRACH preamble and check that it is coherent with the
values set in SIB#5. If available, check the power ramp step in the UE traces. The test shall be
redone with 2 different values of power ramp step.
Note that in order to see the power ramping of the UE, an appropriate setting of the parameters in
SIB#5 is necessary. It is suggested that parameters are set so that the initial power (Pini) is minimal.
Test Verification:
Confirm that the power difference between each preamble is coherent with the settings in SIB#5.
Verification is done using a spectrum analyzer and the UE traces (if available).
Message flow:

UE NW
Remarks:


F_6.5.1.4a UpPCH power ramping Power ramp step parameter check (TDD)
Test Purpose:
To verify that the power step used by the UE between each UpPCH is correct.

Pre-requisites:
Configuration: A
Test Procedure:
Disconnect the RX cable at the nodeB side. Initiate a call with the UE. Using the spectrum analyzer,
measure the power difference between each UpPCH and check that it is coherent with the
parameters(power ramp step) set in SIB5. If available, check the power ramp step in the UE traces.
The test shall be redone with 2 different values of power ramp step.
Note that in order to see the power ramping of the UE, an appropriate setting of the parameters in
SIB5 is necessary. It is suggested that parameters are set so that the initial power (Pini) is minimal.
Note: once the UE reaches maximum UL transmission power, power ramping should stop.
Test Verification:
Confirm that the power difference between each UpPCH is coherent with the settings in SIB5.
Verification is done using a spectrum analyzer and the UE traces (if available).
Message flow:

UE NW
2 UpPCHs are sent
Remarks:


F_6.5.1.5 RACH message part timing and power verification (FDD)
Test Purpose:
To verify that the timing and the power used to send the RACH message part are correct.
Pre-requisites:
Configuration: A
Interference)
Test Procedure:
Initiate a call with the UE. Using the spectrum analyzer, measure and calculate* the power difference
between the last transmitted PRACH preamble and the control part of the RACH message, and check
that it is coherent with the values set in SIB#5 (powerOffsetPp-m = Pmessage-control Ppreamble). If
available, measure the PowerOffsetPp-m in the UE traces.
Also, verify the time difference between the start of the RACH message, and the start of the last
transmitted preamble.
Note that according to 3GPP TS 25.211, the time difference between the last preamble and the RACH
message (p- m) is 15,360 chips (3 access slots) if parameter AICH transmission timing is set to 0, and
20,480 chips (4 access slots) if AICH transmission timing is set to 1.
* Note that the spectrum analyzer will measure the total power received for the RACH message (i.e.
data part + control part). It is possible to calculate the power used for the control part using the gain
factors of the TFC used to transmit the message.
Test Verification:
Verify on the spectrum analyzer the difference in power between the last preamble and the control
part of the massage.
Verify that the RACH message part is sent 3 or 4 access slots after the last preamble.(depending on
Aich Transmission Timing)
Verify in the UTRAN that the RACH Message part is received properly. If it is, the UTRAN should send
an RRC connection setup message to the UE.
Message flow:
UE NW
4 RRC CONNECTION SETUP Confirms that the RACH
message was sent
Remarks:


F_6.5.1.5a RACH message part timing and power verification (TDD)
Test Purpose:
To verify that the UE transmit power for PRACH is in line with the formula:
PPRACH = LPCCPCH + PRXPRACHdes + (iUpPCH -1) * Pwrramp (where, PRXPRACHdes is get from FPACH send by
NodeB)
To verify that the time for the start of PRACH is in line with the formula:
TTX-PRACH= TRX-PRACH - ( UpPCHADV+ UpPCHPOS- 8*16T C) (where, UpPCHPOS is get from FPACH send
by NodeB)

Pre-requisites:
Configuration: A
Test Procedure:
Initiate a call with the UE. Using the spectrum analyzer, measure and calculate the power of PRACH.
If available, measure the PRXPRACHdes and UpPCHPOS in the UE traces. Verify that the power of PRACH
is coherent with the formula stated in the test purpose. Verify that the time for the start of PRACH is
coherent with the formula stated in the test purpose.
Test Verification:
Verify that the timing and the power used to send the PRACH are correct.
Verify in the UTRAN that the RACH Message part is received properly. If it is, the UTRAN should send
an RRC connection setup message to the UE.
Message flow:
UE NW
2 UpPCH is sent
3 FPACH
5 RRC CONNECTION SETUP Confirms that the PRACH
message was sent
Remarks:


F_6.5.1.6 Uplink DCH initial power General test (FDD)
Test Purpose:
Verify the UE UL Initial power of the DCH is following the formula:
DPCCH_Initial_power = DPCCH_Power_offset CPICH_RSCP
Note: DPCCH Power Offset being set by RRC and CPICH RSCP being measured by the UE. UE
traces are needed to verify the formula.

3GPP TS 25.331 clause 8.5.7 Open loop power control, and clause 8.5.3 Open loop power control
upon establishment of DPCCH
Pre-requisites:
Configuration: A
Parameters used for the RACH open loop power control are set in SIB#5 (constant value, P-CPICH
Interference)
A spectrum analyzer is needed to perform the test. UE traces are needed to perform this test, unless
other means can be used to perform the test.
Test Procedure:
Initiate a call with the UE. Verify the value of DPCCH Power Offset in the RRC connection Setup
message (on the Iub interface), and in the UE traces (if available). Verify the value of CPICH RSCP
in the UE traces (if available). Using the spectrum analyzer, measure* the DPCCH Initial Power and
check that it follows the formula specified in the test purpose. The DPCCH initial power in measured
on the first message transmitted on DCH in UL (i.e. RRC connection setup complete in this case).
The test should be re-run with a different value for the DPCCH Power Offset.
The test should be re-run a second time with a different attenuation between UE and nodeB.
* Note that the spectrum analyzer will measure the power of DPCCH + power of DPDCH. It is possible
to calculate the power used for the DPCCH using the gain factors of the TFC used to transmit the
message.
Also note that this test procedure is specific to the case where the UE is put into cell_DCH state at
RRC connection. If the network wishes to put the UE into cell_FACH at establishment of the RRC
connection, the test can also be run at a later stage of the call setup (e.g. RB setup in cell_DCH).
Test Verification:
Verify that the DPCCH Initial Power used by the UE is coherent with the formula:
DPCCH_Initial_power = DPCCH_Power_offset CPICH_RSCP, and that the NW can receive the
message correctly.


Message flow:
UE NW
5 RRC CONNECTION SETUP COMPLETE DPCCH initial power in
measured on this message if the
NW put the UE in cell_DCH.
Otherwise, it is measured later
on the first UL message on DCH
Call continues, but the remaining
signalling isnt needed for the
test purpose
Remarks:



F_6.5.1.6a Uplink DCH initial power General test (TDD)
Test Purpose:
Verify the UE UL Initial power of the DCH is following the formula:
PDPCH = PRXPDPCHdes +LPCCPCH

Pre-requisites:
Configuration: A
to calculate the pathloss LPCCPCH , PRXUpPCHdes , power ramp step, max SYNC_UL transmissions)
Test Procedure:
Initiate a call with the UE. Verify the value of PRXPDPCHdes in the RRC connection Setup message (on
the Iub interface), and in the UE traces (if available). Verify the value of LPCCPCH in the UE traces (if
available). Using the spectrum analyzer, measure the PDPCH and check that it follows the formula
specified in the test purpose. The PDPCH is measured on the first message transmitted on UL DCH (i.e.
RRC connection setup complete in this case).
The test should be re-run with a different value for the PRXPDPCHdes .
The test should be re-run a second time with a different attenuation between UE and nodeB.
*Note that this test procedure is specific to the case where the UE is put into cell_DCH state at RRC
connection. If the network wishes to put the UE into cell_FACH at establishment of the RRC
connection, the test can also be run at a later stage of the call setup (e.g. RB setup in cell_DCH).
Test Verification:
Verify that the PDPCH used by the UE is coherent with the formula stated in the test purpose.
Message flow:
UE NW
2 UpPCH are sent
3 FPACH
6 RRC CONNECTION SETUP COMPLETE PDPCH is measured on this
message if the NW put the UE in
cell_DCH. Otherwise, it is
measured later on the first UL
message on DCH
Remarks:





F_6.5.2.1 Inner loop power control in the UL DCH
Test Purposes:
The main objective of the test case is to verify that the uplink inner loop power control is functional and
that the measured SIR converges on a target SIR at the Node B. The outer loop power control
function is disabled so that the Node B controls the uplink SIR to a static target. The measured SIR at
the Node B is compared to the SIR target and the TPC bits are transmitted on the downlink. The
power transmitted by the UE must change according to the received TPCs.
Reference: 3GPP TS 25.214 clause 5.1.2.2 (for FDD)

3GPP TS 25.224 clause 5.1. 1.4 (for TDD)
Pre-requisites:
Set the uplink SIR target to a known value
Deactivate the outer loop power control in the RNC if possible
Equipment to monitor the UL power (spectrum analyser, special s/w tools etc.)
Test Procedure:
Initiate a speech call from the UE on the Cell_DCH

Monitor the SIR measured at the Node B, the TPC bits on the downlink DPCCH (for FDD) or
DPCH (for TDD) and the TX power in the UE.
Repeat the test with different attenuations applied to the uplink signal and check that the TX
power change accordingly
Test Verification:
Check the behaviour of the power control algorithm by analysing the

parameters/measurements obtained against section 5.1.2.2 of 25.214 (for FDD) or section
5.1.1.4 of 25.224 (for TDD).
Check that the SIR measured at the Node B follows the SIR and that the TX power in the UE
changes accordingly.
Message Flow:
Generic call setup message flow is used, as illustrated in test cases F_6.2.10 and F_6.3.1.
Remarks:

None.


F_6.5.2.2 Inner loop power control DL DCH
Test Purposes:
The main objective of the test case is to verify that the downlink inner loop power control is functional
and that the measured SIR converges on a target SIR at the UE. The outer loop power control
function is disabled so that the UE controls the downlink SIR to a static target. The measured SIR at
the UE is compared to the SIR target and the TPC bits are transmitted on the uplink. The power
transmitted by the Node B must change according to the received TPCs.
Reference: 3GPP TS 25.214 clause 5.2.1.2(for FDD)

3GPP TS 25.224 clause 5.1. 2.4(for TDD)
Pre-requisites:
Set the downlink SIR target in the UE to a known value.
Deactivate the outer loop power control in the UE if possible.
Equipment to monitor the DL power (spectrum analyser, special s/w tools etc.)
Test Procedure:
Initiate a speech call from the UE on a Cell-DCH

Monitor the SIR measured at the UE, the TPC bits on the uplink DPCCH (for FDD) or DPCH
(for TDD) and the TX power at the Node B.
Repeat the test with different attenuations applied to the downlink signal and check that the
SIR and TX power change accordingly
Test Verification:

parameters/measurements obtained against section 5.2.1.2 of 25.214 (for FDD) or section
5.1.2.4 of 25.224 (for TDD).
Check that the SIR measured at the UE follows the target SIR and that the TX power in the
Node B changes accordingly.
Message Flow:
Remarks:

None.


F_6.5.2.3 Inner loop power control in the UL DCH in Soft Handover mode (FDD)
Test Purposes:
The main objective of the test case is to verify that the uplink inner loop power control is functional in
Soft Handover mode, and that the measured SIR converges on a target SIR at the serving cells. The
outer loop power control function is disabled so that the network controls the uplink SIR to a static
target. The measured SIR at the serving cells is compared to the SIR target and the TPC bits are
transmitted on the downlink. The power transmitted by the UE must change according to the received
TPCs.
Reference: 3GPP TS 25.214 clause 5.1.2.2
Pre-requisites:
Test Procedure:
Initiate a speech call from the UE on Cell_DCH

Bring the UE to Soft Handover mode.
Monitor the SIR measured at serving cells in the active set, the TPC bits on the downlink
DPCCH and the TX power in the UE.
Repeat the test with different attenuations applied to the uplink signal to all serving cells and
check that the TX power change accordingly
Test Verification:

parameters/measurements obtained against section 5.1.2.2 of 25.214.
Check that the SIR measured at the serving cells in the active set follows the target SIR, and
that the TX power in the UE changes accordingly.
Verify, that the UE combines the TPC bits from both cells correctly.
Verify, that the UTRAN sends the TPC bits correctly.
Message Flow:
Generic call setup message flow is used, as illustrated in test case F_6.2.10, F_6.3.1 and F_6.6.5.
Remarks:

None.


F_6.5.2.3a Inner loop power control in the UL DCH in Baton Handover mode.
Test Purposes:
To verify that the uplink inner loop power control is functional in Baton Handover mode, and that the
measured SIR converges on a target SIR at the serving cells. The outer loop power control function is
disabled so that the network controls the uplink SIR to a static target. The measured SIR at the
serving cells is compared to the SIR target and the TPC bits are transmitted on the downlink. The
power transmitted by the UE must change according to the received TPCs.
Reference: 3GPP TS 25.224 clause 5.1.1. 4
Pre-requisites:
Test Procedure:

Bring the UE to Baton Handover mode.
Monitor the SIR measured at the serving cell, the TPC bits on the downlink DPCH and the TX
power in the UE.
Repeat the test with different attenuations applied to the uplink signal to the serving cell and
Test Verification:

Check that the SIR measured at the serving cell follows the target SIR, and that the TX power
in the UE changes accordingly.
Message Flow:
Generic call setup message flow is used, as illustrated in test case F_6.2.10, F_6.3.1 and F_6.6.2.2.2.
Remarks:

None.


F_6.5.2.4 Inner loop power control in the UL DCH in Softer Handover mode (FDD)
Test Purposes:
Softer Handover mode, and that the measured SIR converges on a target SIR at the serving cells. The
outer loop power control function is disabled so that the network controls the uplink SIR to a static
target. The measured SIR at the serving cells is compared to the SIR target and the TPC bits are
transmitted on the downlink. The power transmitted by the UE must change according to the received
TPCs.
Pre-requisites:
Test Procedure:

Bring the UE to Softer Handover mode.
Monitor the SIR measured at serving cells in the active set, the TPC bits on the downlink
DPCCH and the TX power in the UE.
Repeat the test with different attenuations applied to the uplink signal to all serving cells and
Test Verification:

Message Flow:
Generic call setup message flow is used, as illustrated in test case F_6.2.10, and F_6.3.1 F_6.6.1.
Remarks:

None.


F_6.5.2.5 Inner loop power control DL DCH in Soft Handover mode (FDD)
Test Purposes:
in Soft Handover mode, and that the measured SIR/BLER converges on a target SIR/BLER at the UE.
The outer loop power control function is disabled so that the UE controls the downlink SIR/BLER to a
static target. The measured SIR/BLER at the UE is compared to the SIR/BLER target and the TPC
bits are transmitted on the uplink until the SIR/BLER target is reached. The power transmitted by the
Node B must change according to the received TPCs.
Pre-requisites:
Set the downlink target (SIR or BLER) in the UE to a known value.
Test Procedure:

Bring the UE to Soft Handover mode.
Monitor the SIR/BLER measured at the UE, the TPC bits on the uplink DPCCH and the TX
power at the serving cells.
SIR/BLER and TX power change accordingly
Test Verification:

parameters/measurements obtained against the section 5.2.1.2 of 25.214.
Check that the SIR/BLER measured at the UE follows the target SIR/BLER and that the TX
power in the Node B changes accordingly.
Message Flow:
Generic call setup message flow is used, as illustrated in test cases F_6.2.10, F_6.3.1 and F_6.6.5.
Remarks:

None.


F_6.5.2.5a Inner loop power control DL DCH in Baton Handover mode (TDD).
Test Purposes:
To verify that the downlink inner loop power control is functional in Baton Handover mode, and that the
measured SIR/BLER converges on a target SIR/BLER at the UE. The outer loop power control
function is disabled so that the UE controls the downlink SIR/BLER to a static target. The measured
SIR/BLER at the UE is compared to the SIR/BLER target and the TPC bits are transmitted on the
uplink until the SIR/BLER target is reached. The power transmitted by the Node B must change
according to the received TPCs.
Pre-requisites:
Set the downlink target (SIR or BLER) in the UE to a known value.
Test Procedure:

Bring the UE to Baton Handover mode.
Monitor the SIR/BLER measured at the UE, the TPC bits on the uplink DPCH and the TX
power at the serving cell.
Test Verification:

parameters/measurements obtained against the section 5.1.2.4 of 25.224.
Message Flow:
Generic call setup message flow is used, as illustrated in test cases F_6.2.10, F_6.3.1 and F_6.6.2.2.2
Remarks:

None.


F_6.5.2.6 Inner loop power control in the UL DCH in Compressed mode (FDD).
Test Purposes:
Compress mode, and that the measured SIR converges on a target SIR at the serving cell. The outer
loop power control function is disabled so that the network controls the uplink SIR to a static target.
The measured SIR at the serving cell is compared to the SIR target and the TPC bits are transmitted
on the downlink. The power transmitted by the UE must change according to the received TPCs.
Pre-requisites:
Test Procedure:

Bring the UE to compress mode.
Monitor the SIR measured at serving cell, the TPC bits on the downlink DPCCH and the TX
power in the UE.
Repeat the test with different attenuations applied to the uplink signal and check that the TX
power change accordingly
Test Verification:

Message Flow:
Remarks:
The trigger for the compressed mode, the number of the transmission gaps etc. are driven by the
network.

None.


F_6.5.2.7 Inner loop power control DL DCH in Compressed mode (FDD)
Test Purposes:
in Compress mode, and that the measured SIR/BLER converges on a target SIR/BLER at the UE. The
outer loop power control function is disabled so that the UE controls the downlink SIR/BLER to a static
target. The measured SIR/BLER at the UE is compared to the SIR/BLER target and the TPC bits are
transmitted on the uplink. The power transmitted by the Node B must change according to the
received TPCs.
Pre-requisites:
Set the downlink SIR/BLER target in the UE to a known value.
Test Procedure:

Bring the UE to Compress mode.
Monitor the SIR/BLER measured at the UE, the TPC bits on the uplink DPCCH and the TX
power at the serving cell.
Test Verification:

parameters/measurements obtained against section 5.2.1.3 of.25.214
Message Flow:
Remarks:

None.


F_6.5.3.1 Uplink outer loop power control Initial SIR target is too high
Test Purpose:
Verify that the outer loop power control converges when the initial SIR target is set too high
References: 3GPP TS 25.427 clause 5.4
Pre-requisites:
Configuration: A
A spectrum analyzer is needed to perform the test. Internal NodeB traces are also needed, unless
other means of measuring the UL SIR are available.
Test Procedure:
Set the initial SIR target to the maximum value, 17.3 dB.
Initiate a call with the UE. Monitor the UL target SIR on the Iub, and the current UL SIR in the nodeB.
Test Verification:
Verify that both the UL SIR target sent from the RNC to the nodeB and the current UL SIR are
decreasing.
Using the spectrum analyzer, verify that the average UE UL power is decreasing.
Verify that the UL BLER in the nodeB still meets the requirements for the service in UTRAN.
Note: In a lab environment, the SIR target should go down to a lower value and then remain constant.
The BLER target requirement for UL DCH should always be met.
Message flow:
Use the message flow for a call setup (CS or PS).
Remarks:
Covered protocol tests: same as call setup.


F_6.5.3.2 Uplink outer loop power control Initial SIR target is too low
Test Purpose:
Verify that the outer loop power control converges when the initial SIR target is set too low
Pre-requisites:
Configuration: A
Test Procedure:
Set the initial SIR target to the minimum value, -8.2 dB.
Initiate a call with the UE. Monitor the UL target SIR on the Iub, and the current UL SIR in the nodeB.
Test Verification:
Verify that both the UL SIR target sent from the RNC to the nodeB and the current UL SIR are
increasing.
Using the spectrum analyzer, verify that the average UE UL power is increasing.
Verify that the UL BLER in the nodeB still meets the requirements for the service in UTRAN.
Note: In a lab environment, the SIR target should go up to a higher value and then remain constant.
The BLER target requirement for UL DCH should always be met.
Also note that the stable RF environment of the lab may lead to difficulties in seeing the effect of the
outer loop power control.
Message flow:
Remarks:


F_6.5.3.3 Uplink outer loop power control Multi-service
Test Purpose:
Verify that the outer loop power control converges in multi-service CS+PS (where CS and PS services
have different BLER requirements)
Pre-requisites:
Configuration: A
A CS and a PS service with different UL BLER requirements should be chosen
Test Procedure:
1 - Set the initial SIR target to the minimum value, -8.2 dB.
Initiate a multi-service CS+PS call with the UE. Monitor the UL target SIR on the Iub, and the current
UL SIR in the nodeB. Terminate the call.
2 - Set the initial SIR to the maximum value, 17.3 dB.
Initiate a multi-service CS+PS call with the UE. Monitor the UL target SIR on the Iub, and the current
UL SIR in the nodeB. Terminate the call.
Test Verification:
1 - Verify that both the UL SIR target sent from the RNC to the nodeB and the current UL SIR are
increasing.
Using the spectrum analyzer, verify that the average UE UL power is increasing.
Verify that the UL BLER in the nodeB still meets the requirements for both CS and PS services in
UTRAN, after convergence of the SIR target.
Note: In a lab environment, the SIR target should go up to a higher value and then remain constant.
The BLER target requirement for UL DCH of both CS and PS services should always be met once the
SIR target has converged.
2 - Verify that both the UL SIR target sent from the RNC to the nodeB and the current UL SIR are
decreasing.
Using the spectrum analyzer, verify that the average UE UL power is decreasing.
Verify that the UL BLER in the nodeB still meets the requirements for both CS and PS services in
UTRAN.
Note: In a lab environment, the SIR target should go down to a lower value and then remain constant.
The BLER target requirement for UL DCH of both CS and PS services should always be met.
Also note that the stable RF environment of the lab may lead to difficulties in seeing the effect of the
outer loop power control.
Message flow:
Use the message flow for a multi-service call setup.
Remarks:


F_6.5.3.4 Downlink outer loop power control Variation of BLER target
Test Purpose:
Verify that the outer loop power control in the UE converges when the initial target BLER is modified
Pre-requisites:
Configuration: A
A code domain analyzer (or means of measuring the DCH DL power) is needed to perform the test.
Internal UE traces are also needed.
Test Procedure:
Set the initial DL BLER target to 0.1 (suggested).

Initiate a call with the UE. Monitor the DL DCH power with the code domain analyzer and the DL
current BLER in the UE traces.
Re-run the test with the initial DL BLER target set to 1 (or a higher value than the first time).
Test Verification:
Verify that the DCH DL power is lower when the BLER target is set to a higher value.
Verify that the current BLER meets the BLER target.
Message flow:
Remarks:


F_6.5.3.5 Downlink outer loop power control multi-service
Test Purpose:
Verify that the outer loop power control in the UE converges when the initial target BLER is modified,
in a multi-service scenario
Pre-requisites:
Configuration: A
A code domain analyzer (or means of measuring the DCH DL power) is needed to perform the test.
Internal UE traces are also needed.
A CS and a PS service with different DL BLER requirements should be chosen
Test Procedure:
Set the initial DL BLER target to different values for CS and PS transport channels. For example, use
target_BLER CS DCH = 0.01 and target BLER PS DCH = 0.1.
Initiate a call with the UE. Monitor the DL DCH power with the code domain analyzer and the DL
current BLER in the UE traces.
Invert the values of target BLER for CS and PS (the CS target becomes the PS target and vice-versa),
and re-run the test.
Test Verification:
Verify that the current BLER meets the BLER target for both CS and PS transport channels.
Message flow:
Use the message flow for a multi-service call setup.
Remarks:


F_6.6.1.1 3G Handovers / soft and softer handover / Softer handover / Addition of one radio link
Test Purpose:
To check that when a cell satisfies the criterion for being added in the UE active set, the RNC triggers
an active set update procedure, and a radio link is added to the active set.
Pre-requisites:
Configurations: B or C
Intra-frequency measurements are set up by UTRAN using a MEASUREMENT CONTROL message
(or SIB#11).
A call has been established with cell 1, and the UE is in the following state:
For CS: UE is in CS-DCCH+DTCH_DCH (state 6-9) as specified in clause 7.4 of TS 34.108.
For PS: UE is in PS-DCCH+DTCH_DCH (state 6-10) as specified in clause 7.4 of TS 34.108.
Criterion used to add a link to the active set:
(CPICH Ec/No Best_Cell CPICH Ec/No Cell_X) < ADD_DELTA
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cell 2 satisfies the
criterion to be added in the active set (see pre-requisites). RNC sends ACTIVE SET UPDATE to UE,
with parameters of cell 2 to be added to the active set. The UE configures layer 1 to begin reception
for the additional radio link. After the UE receives confirmation from its physical layer, an ACTIVE SET
UPDATE COMPLETE message is sent to the UTRAN.
Initial RF conditions: CPICH Ec/No for cell 1= -1 dB, for cell 2 = -6 dB
Step 2: CPICH Ec/No for cell 2 = -1 dB (ADD_DELTA / 2)
Test Verification:
To confirm that the measurements reported by the UE are consistent
To confirm that after the softer handover (after step 6), the quality of the transmission is as follows:
No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate (QE) and
the CRC Indication (CRCI) in the uplink dedicated FP frames, as specified in TS 25.427.
No degradation of the downlink BLER shall be seen on the UE log, if available
Voice quality: no disturbance to be heard in the landline phone or in the UE
Packet call: no impact on throughput. The TCP repetitions shall be checked on the Gi interface. On
the Iub, there should be no RLC retransmission or reset of the protocol.
In step 5, check that the RNC performs the addition of a radio link according to the criterion
At step 6, check the traces of NBAP Radio Link Addition request/response and RRC Active Set
Update/complete messages over the Iub.


Message flow:
UE NW
1 MEASUREMENT REPORT (DCCH) UE sends intra-frequency
measurements, as requested by
UTRAN.
conditions according to step 2 in
the test procedure.
3 MEASUREMENT REPORT (DCCH) UE returns intra-frequency
UTRAN.
4 softer handover decision Made by the RNC
(DCCH)
Remarks:

1 B_8.4.1.1 RRC / Measurement Control and Report: Intra-frequency measurement
2 B_8.3.4.1a RRC / Active set update in softer handover: Radio Link addition


F_6.6.1.2 3G Handovers / soft and softer handover / Softer handover / Addition of two radio
links
Test Purpose:
To check that when 2 cells satisfy the criterion for being added in the UE active set, the RNC triggers
an active set update procedure, and 2 radio links are added to the active set.
Pre-requisites:
Configuration: C
(or SIB#11).
Intra-NodeB timing:
Sector 1: T_cell=0
Sector 2: T_cell=3 (768 chips)
Sector 3: T_cell=6 (1536 chips)
(Use these values only as guidance)
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cells 1 and 2 satisfy
the criterion to be added in the active set (see pre-requisites). RNC sends ACTIVE SET UPDATE to
UE, with parameters of cells 1 and 2 to be added to the active set. The UE configures layer 1 to begin
reception for the additional radio links. After the UE receives confirmation from its physical layer, an
ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
(Use these values only as guidance.)
Initial RF conditions: CPICH Ec/No for cell 1= -6dB, for cell 2 = -7dB, for cell 3 = -1dB
Step 2: CPICH Ec/No for cell 1 = -1dB (ADD_DELTA / 2), cell 2 = -1dB (ADD_DELTA / 2)
(The change for cells 1 and 2 must be done in parallel.)
Test Verification:
To confirm that after the addition of 2 radio links (after step 6), the quality of the transmission is as
follows:
After step 3, check that, after modifying radio conditions, the UE sends an RRC measurement report
with:
CFN-SFN2 Observed Time Difference parameter =(off=0 ; tm=768)
CFN-SFN1 Observed Time Difference parameter =(off=0 ; tm =1536)
CPICH Ec/No with expected value
In step 5, check that the RNC performs the addition of 2 radio links according to the criterion


At step 6, check the traces of NBAP Radio Link Addition request/response and RRC Active Set
Update/complete messages over the Iub, for cells 1 and 2.
Message flow:

UE NW
UTRAN.
the test procedure.
UTRAN.
(DCCH)
Remarks:



F_6.6.1.3 3G Handovers / soft and softer handover / Softer handover / Removal of a radio link
Test Purpose:
To check that when 1 cell satisfies the criterion for being removed, the RNC triggers an active set
update procedure and 1 radio link is removed from the active set.
Pre-requisites:
Configuration: C
(or SIB#11).
A call has been established with cell 1 and cell 2 has been added to the active set, and the UE is in
the following state:
Criterion used to remove a link from the active set:
(CPICH Ec/No Best_Cell CPICH Ec/No Cell_X) > REMOVE_DELTA
Test Procedure:
UE is sending measurement reports. Radio conditions are then modified so that cell 2 satisfies the
criterion for being removed. RNC sends ACTIVE SET UPDATE to UE, with an indication to remove
cell 2 from the active set. After the UE receives confirmation from its physical layer, an ACTIVE SET
Initial conditions: CPICH Ec/No for cell 1= -1 dB, for cell 2 = -1 dB
Step 2: CPICH Ec/No for cell 2 = -1dB 2*REMOVE_DELTA
Test Verification:
To confirm that after the removal of a radio link (after step 2), the quality of the transmission is as
follows:
No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate
25.427.
Packet call: no impact on throughput. The TCP repetitions shall be checked on the Gi
interface. On the Iub, there should be no RLC retransmission or reset of the protocol.
After step 1, compare the values of the Intra-frequency measurement quantity (CPICH Ec/N0, CPICH
RSCP, Pathloss or UTRA Carrier RSSI) with the one obtained with a code domain analyzer, if
available. Check the consistency of the measurements reported by the mobile.
In step 2, check that the RNC performs the removal of 1 radio link.
At step 6, check the traces of RRC Active Set Update/complete messages over the Iub, for cell 2.


Message flow:
UE NW
UTRAN.
conditions according to the test
procedure.
UTRAN.
(DCCH)
Remarks:

2 B_8.3.4.2a RRC / Active set update in softer handover: Radio Link removal (FDD)


F_6.6.1.4 3G Handovers / soft and softer handover / Softer handover / Combined

addition and removal of a radio link
Test Purpose:
To check that when 1 cell satisfies the criterion for being added in the UE active set, and another
satisfies the criterion for being removed, the RNC triggers an active set update procedure, and 1 radio
link is added to the active set while the other is removed.
Pre-requisites:
Configuration: C
(or SIB#11).
Criterion used to remove a link from the active set:
Test Procedure:
UPDATE COMPLETE message is sent to the UTRAN. Radio conditions are then modified so that cell
3 satisfies the criterion for being added to the active set, and cell 2 satisfies the criterion for being
removed. RNC sends ACTIVE SET UPDATE to UE, with parameters of cell 3 to be added to the
active set, and an indication to remove cell 2 from the active set. After the UE receives confirmation
from its physical layer, an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Step 7: CPICH Ec/No for cell 3 = -1dB (ADD_DELTA / 2) and CPICH Ec/No for cell 2 = -1dB
2*REMOVE_DELTA
Test Verification:
To confirm that after the simultaneous addition and removal of a radio link (after step 11), the quality of
the transmission is as follows:
After step 1, compare the values of the Intra-frequency measurement quantity (CPICH Ec/N0, CPICH
RSCP, Pathloss or UTRA Carrier RSSI) with the one obtained with a code domain analyzer, if
available. Check the consistency of the measurements reported by the mobile.


In step 10, check that the RNC performs the addition of 1 radio link and the removal of another
according to the criteria
At step11, check the traces of NBAP Radio Link Addition request/response and RRC Active Set
Update/complete messages over the Iub, for cells 1 and 2.
Message flow:

UE NW
UTRAN.
the test procedure.
UTRAN.
(DCCH)
the test procedure.
UTRAN.
(DCCH)
Remarks:

3 E_8.3.4.3a RRC / Active set update in softer handover: Combined radio link
addition and removal (active set is not full)


F_6.6.1.5 3G Handovers / soft and softer handover / Softer handover / Primary cell change
Test Purpose:
To check when a cell satisfies the criterion for becoming the UEs primary cell, it is chosen by the RNC
as the new primary cell.
Pre-requisites:
Configuration: D or E (with 3 sectors per nodeB: cells 1, 2 and 3 on nodeB1, and cells 4, 5 and 6 on
nodeB2)
(or SIB#11).
Criterion used for defining the primary cell:
(CPICH Ec/No Cell_X CPICH Ec/No Current_Primary_Cell) > NEW_DELTA
Neighboring cell definition (the 6 cells must be up and transmitting):
cell 1: cell 3, 4, 5 and 6
cell 3: cell 1 & cell 2
Test Procedure:
UPDATE COMPLETE message is sent to the UTRAN. Radio conditions are then changed so that the
criterion for changing the primary cell is satisfied. After a MEASUREMENT REPORT from the UE,
UTRAN sends a new MEASUREMENT CONTROL message, showing a new intra-frequency cell info
list due to the primary cell change.
The pathloss between the UE and the different cells is modified as follows:
Initial conditions: CPICH Ec/No for cell 1 = -6dB
CPICH Ec/No for cell 2 = -6dB
CPICH Ec/No for cells 4, 5 and 6 = -6dB
Step 2: CPICH Ec/No for cell 1 = -1dB

Step 7: CPICH Ec/No for cell 1 = -1dB

CPICH Ec/No for cell 3 = -1dB N*NEW_DELTA, where N>1 and is such that cell 3 is
not removed from the active set (CPICH Ec/No cell 1 CPICH Ec/No cell 3 <
REMOVE_DELTA)
Test Verification:
To confirm that after the primary cell change (after step 11), the quality of the transmission is as
follows:



After step 1, check that the UE sends RRC measurement report with CPICH Ec/No of cells 1 & 2.
After step 5, check that the RNC performs the addition of a radio link for cell 1, according to the
criterion defined in pre-requisites.
After step 6, check the traces of NBAP Radio Link Addition request/response and RRC Active Set
Update/complete messages over the Iub, for cell 1.
After step 9, check in the RNC trace that the primary cell was updated. Also check on the Iub that the
RNC sends the measurement control to the UE, with an updated intra-frequency cell info list.
In step 11, check that the UE updated its reported set correctly (cell2 removed, cells 4,5,6 added).
Message flow:
UE NW

by UTRAN.
conditions according to step 2
in the test procedure.
by UTRAN.
5 ACTIVE SET UPDATE (DCCH) RRC With parameters of cell
1
6 ACTIVE SET UPDATE COMPLETE (DCCH) RRC
by UTRAN.
9 Primary cell change decision Made by the RNC
10 MEASUREMENT CONTROL With new intra-frequency cell
info list
11 MEASUREMENT REPORT With updated reported cell list
Remarks:



F_6.6.1.6 3G Handovers / soft and softer handover / Soft handover / Addition of a radio link
Test Purpose:
To check that when a cell (that isnt in the active set) satisfies the criterion for being added to the UE
active set, the RNC triggers an active set update procedure (for soft handover), and a radio link is
added to the active set.
Pre-requisites:
Configurations: D or E (cell 1 on nodeB1 and cell 2 on nodeB2)

(or SIB#11).
A call has been established with cell 1 (nodeB1), and the UE is in the following state:
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cell 2 (node B2)
satisfies the criterion to be added to the active set (see pre-requisites). RNC sends ACTIVE SET
UPDATE to UE, with parameters of cell 2 to be added to the active set. The UE configures layer 1 to
begin reception for the additional radio link. After the UE receives confirmation from its physical layer,
an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Test Verification:
To confirm that after the soft handover (after step 6), the quality of the transmission is as follows:
After step 1, check the value of CFN-SFN2 Observed Time Difference reported by the UE
In step 5, check that the RNC performs the addition of a radio link according to the related criterion
Update/complete messages over the Iub, for cell 2. Compare the following parameters to (OFF, Tm)
values reported by the UE:
Frame offset/chip offset (in Radio Link Setup Request) should be identical.
DPCH-Frame offset (in Active Set Update) the Frame Offset + Chip Offset are rounded to the
closest 256 chip boundary according to the following rules from 3GPP TS 25.402:
IF (Frame Offset x 38,400 + Chip Offset) modulo 256 [chips] = {1127}, THEN round (Frame Offset
x 38,400 + Chip Offset) modulo 256 frames down to the closest 256 chip boundary.
IF (Frame Offset x 38,400 + Chip Offset) modulo 256 [chips] = {128255}, THEN round (Frame
Offset x 38,400 + Chip Offset) modulo 256 frames up to the closest 256 chip boundary.


IF (Frame Offset x 38,400 + Chip Offset) modulo 256 [chips] = 0, THEN (Frame Offset x 38,400 +
Chip Offset) is already on a 256 chip boundary.
Message flow:

UE NW
UTRAN.
the test procedure.
UTRAN.
4 soft handover decision Made by the RNC
(DCCH)
Remarks:

2 B_8.3.4.1b RRC / Active set update in soft handover: Radio Link addition


F_6.6.1.7 3G Handovers / soft and softer handover / Soft handover / Addition of 2 radio links
(softer + soft)
Test Purpose:
To check that when 2 cells (that arent in the active set) satisfy the criterion for being added in the UE
active set, the RNC triggers an active set update procedure, and 2 radio links are added to the active
set.
Pre-requisites:
Configuration: D or E (cells 1 and 2 on nodeB1, and cell 3 on nodeB2)

(or SIB#11).
Neighbors of cell 2: cell 1 + cell 3
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cell 1 and cell 3
satisfy the criterion to be added in the active set (see pre-requisites). RNC sends ACTIVE SET
UPDATE to UE, with parameters of cell 1 and cell 3 to be added to the active set. The UE configures
layer 1 to begin reception for the additional radio links. After the UE receives confirmation from its
physical layer, an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Step 1: CPICH Ec/No for: cell 1= -6dB, for cell 2 = -1dB, for cell 3 = -6dB
Step 5: CPICH Ec/No for cell 1 = -1dB (ADD_DELTA / 2)

CPICH Ec/No for cell 3 = -1dB (ADD_DELTA / 2)
Test Verification:
Packet call: no impact on throughput. The TCP repetitions shall be checked. On the Iub, there should
be no RLC retransmission or reset of the protocol.
In step 5, check that the RNC performs the addition of 2 radio links to the active set, according to the
criterion defined in the pre-requisites.
Update/complete messages over the Iub, for the 2 added cells. Also check that the AAL2 connection
between RNC and node B1 is maintained.


Message flow:
UE NW
UTRAN.
the test procedure.
UTRAN.
4 Soft/softer handover decision Made by the RNC
(DCCH)
Remarks:



F_6.6.1.8 Generic / soft and softer handover / Soft handover / active set update when active set
is full
Test Purpose:
To check that when the active set is full but a new best cell is measured from the monitored set, the
active set is updated.
Pre-requisites:
Configuration: D or E (with 3 sectors per nodeB: cells 1, 2 and 3 on nodeB1, and cells 4, 5 and 6 on
nodeB2)
(or SIB#11).
Maximum active set size configured in the RNC: 4 links

Neighboring cell definition:
cell 3: cell 1, 2, 4, 5 and 6
cell 1: cell 3, 4, 5 and 6
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cells 1,2 and 4
satisfy the criterion to be added in the active set (see pre-requisites). RNC sends ACTIVE SET
UPDATE to UE, with parameters of cells 1&2 and 4 to be added to the active set. The UE configures
layer 1 to begin reception for the additional radio links. After the UE receives confirmation from its
physical layer, an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Radio conditions are again modified so that cell 5satisfies the condition to be added in the active set.
As the active set is full, the RNC decides to remove cell 1 (worst cell). RNC sends ACTIVE SET
UPDATE to the UE, adding one cell (cell 5) to the active set and removing another (cell1). The UE
configures layer 1 to begin reception for the additional radio links. After the UE receives confirmation
from its physical layer, an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Initial conditions: CPICH Ec/No for NodeB1: cell 1= -6dB, cell 2 = -6dB, cell 3 = -1dB
CPICH Ec/No for NodeB2: cell 4 = -6dB, cell 5 = -7dB, cell 6 = -7dB
Step 2: CPICH Ec/No for NodeB1 cell 1 = -1dB (ADD_DELTA/2), cell 2 = -1dB (ADD_DELTA / 3),
cell 3 = -1dB
CPICH Ec/No for NodeB2 cell 4 = -1dB - (ADD_DELTA / 3)
Step 7: CPICH Ec/No for Node B2 cell 5 = -1 dB - (ADD_DELTA / 3)
Test Verification:


After step 5, check that the RNC performs the addition of 3 radio links for cells 1,2 and 4, according to
the criterion defined in pre-requisites.
Update/complete messages over the Iub, for cells 1,2 and 4.
After step 10, check that the RNC performs one leg removal decision, and one leg addition, according
to the criterion defined in pre-requisites.
After step 11, check the traces of NBAP Radio Link Deletion request/response on nodeB1, NBAP
Radio Link Setup request/response on NodeB2, and RRC Active Set Update/complete messages over
the Iub: field Radio Link Addition Information contains cell 5 while field Radio Link Removal
Information contains cell 3.
Message flow:
UE NW

by UTRAN.
by UTRAN.
4 Softer/soft handover decision Made by the RNC
5 ACTIVE SET UPDATE (DCCH) RRC With parameters of
cells 1,2 and 4
by UTRAN.
9 Soft handover decision Made by the RNC
10 ACTIVE SET UPDATE (DCCH) Cell 3 is removed, cell 5 is
added to the active set.
11 ACTIVE SET UPDATE COMPLETE (DCCH)
Remarks:



F_6.6.1.9 Generic / soft and softer handover / Inter-RNC Soft handover followed by SRNS
relocation
Test Purpose:
To check that in order to optimize the path between UE and CN, the NW can change the UTRAN to
CN point of connection at the UTRAN from the source RNC to the target RNC. If needed, the UE will
need to perform an LA and/or RA update while in PMM-CONNECTED.
Note: in this case, the 2 procedures are independent. However, the original cell needs to be out of the
UEs active set in order to start the SRNS relocation.
Pre-requisites:
Configuration: E (cell1 from RNC1 and cell2 from RNC2)

(or SIB#11).
Test Procedure:
for the additional radio links. After the UE receives confirmation from its physical layer, an ACTIVE
SET UPDATE COMPLETE message is sent to the UTRA N.
Radio conditions are again modified so that cell 1 satisfies the condition to be removed from the active
set. RNC sends ACTIVE SET UPDATE to the UE, removing cell 1 from the active set. The UE
configures layer 1 to begin reception. After the UE receives confirmation from its physical layer, an
The SRNS then decides to perform an SRNS relocation to optimize the radio path between UE and
CN. A preparation phase is done in the NW.
The target SRNC sends a UTRAN Mobility Information message. This message contains UE
information elements and CN information elements. The UE information elements include among
others new SRNC identity and S-RNTI. The CN information elements contain among others Location
Area Identification and Routing Area Identification.
Upon reception of the UTRAN Mobility Information message the MS may start sending uplink user
data to the target SRNC. When the MS has reconfigured itself, it sends the UTRAN Mobility
Information Confirm message to the target SRNC. This indicates that the MS is also ready to receive
downlink data from the target SRNC.
Note that the SRNS relocation can be performed in a lossless manner. This is decided by UTRAN,
depending on the RNC and UE capabilities (need to support PDCP is required).
Initial conditions: CPICH Ec/No for cell 1= -1dB, cell 2 = -6dB

Step 2: CPICH Ec/No for cell 1 = -1dB, cell 2 = -1dB
Step 7: CPICH Ec/No for cell 1 = -1 dB (2 * REMOVE_DELTA), cell 2 = -1 dB
Test Verification:
Verify that there isnt a significant break in the communication during the procedure.


Verify that the old link between the source RNC and the CN is broken (Iu released)
Verify the speech/data quality after the combined procedure.
Verify that if the UE receives a new LAI and/or RAI, it initiates a LA and/or RA update procedure.
In case of a lossless SRNS relocation, verify that no data is lost.
Message flow:
UE NW

by UTRAN.
by UTRAN.
5 ACTIVE SET UPDATE (DCCH) RRC With parameters of cell
2
by UTRAN.
9 Decision to remove cell 1 Made by the RNC
10 ACTIVE SET UPDATE (DCCH) Cell 1 is removed
11 ACTIVE SET UPDATE COMPLETE (DCCH)
12 Decision to perform an SRNS relocation Made by SRNC
13 UTRAN MOBILITY INFORMATION Contains S-RNTI, SRNC ID,
LAI and RAI
CONFIRM
15 SRNS relocation is completed
in the NW
16 LA or RA UPDATE REQUEST** Initiated by the UE in case of a
new LAI and/or new RAI
17 LA or RA UPDATE ACCEPT**
** Only needed if the LAI and/or the RAI are different from the ones stored in the UE.
Remarks:

3 B_8.3.4.2b RRC / Active set update in soft handover: Radio Link removal
4 E_8.3.3.1 RRC / UTRAN Mobility Information: Succsess
6 B_12.4.1. 1 Routing area updating / accepted


F_6.6.1.10 3G Handovers / intra-frequency handover / inter-RNC handover
Test Purpose:
To check that when a UE satisfies the criteria for being handed over to another cell an inter-RNC intra-
frequency handover can successfully be performed by the UTRAN and UE. For this particular test
case, intra-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: E (2 cells: cell 1 and cell 2 using UTRA RF channel 1)

(or SIB#11).
Test Procedure:
UE is sending measurement reports (if configured by UTRAN). Radio conditions are then changed so
that the criterion/criteria for triggering an intra-frequency handover to cell 2 is/are fulfilled. RNC sends
RADIO BEARER RECONFIGURATION to UE, giving the parameters of cell 2. After the UE receives
confirmation from its physical layer, a RADIO BEARER RECONFIGURATION COMPLETE message
is sent to the RNC.
Test Verification:
To confirm that the UE can make intra-frequency measurements and return then coherently to UTRAN
To confirm that a new radio link is set up with nodeB2
To confirm that the old radio link with nodeB1 is deleted
To confirm that after the intra-frequency/inter RNC hard handover, the quality of the transmission is as
follows:
Voice quality: no major disturbance to be heard in the landline phone or in the UE
Packet call: no major impact on throughput. The TCP repetitions shall be checked on the Gi interface.
On the Iub, there should be no or not too many RLC retransmissions or reset of the protocol.
After step 1, check the consistency of the measurements reported by the mobile. The measurements
must contain intra-frequency measurements.
After step 4, check that the RNC requests an intra-frequency hard HO by sending a RB
reconfiguration message to the UE.
After step 5, check that the UE responds on the UTRA RF channel 1.
After step 6, check that the old radio link with node1 (on UTRA RF channel 1) was deleted. Also,
check the quality of the transmission shall be verified, according to the test verification.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
4 Inter-RNC handover decision Made by the RNC
5 RADIO BEARER RECONFIGURATION RRC With parameters of
(DCCH) cell2
COMPLETE (DCCH)
Note: a different reconfiguration procedure may be used (Physical channel reconfiguration or transport
channel reconfiguration)
Remarks:



F_6.6.2.1.1 3G Handovers / inter-frequency handover / intra-nodeB handover (blind)
Test Purpose:
To check that when a UE satisfies the criteria for being handed over to another frequency, an inter-
case, no inter-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: B or C (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel 2)
(or SIB#11).
Test Procedure:
that the criterion/criteria for triggering an inter-frequency handover to cell 2 is/are fulfilled. RNC sends
RADIO BEARER RECONFIGURATION to UE, giving the parameters of cell 2. The UE configures
layer 1 to begin reception on the new frequency. After the UE receives confirmation from its physical
layer, a RADIO BEARER RECONFIGURATION COMPLETE message is sent to the RNC.
Test Verification:
To confirm that after the inter-frequency hard handover, the quality of the transmission is as follows:
Packet call: no major impact on throughput. The TCP repetitions shall be checked. On the Iub, there
should be no or only a few RLC retransmission or reset of the protocol.
shall not contain inter-frequency measurements.
After step 4, check that the RNC requests an inter-frequency hard HO by sending a RB
After step 6, check that the old radio link with cell 1 (on UTRA RF channel 1) was deleted.
Message flow:



UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.1.2 3G Handovers / inter-frequency handover / intra-nodeB handover (with inter-

frequency measurements)
Test Purpose:
case, inter-frequency measurements are made by the mobile using compressed mode or a dual
receiver, depending on UE capabilities.
Pre-requisites:
Inter-frequency measurements are set up by UTRAN using a MEASUREMENT CONTROL message
(or SIB#11).
Test Procedure:
UE is sending inter-frequency measurement reports. Radio conditions are then changed so that the
criterion/criteria for triggering an inter-frequency handover to cell 2 is/are fulfilled. RNC sends RADIO
BEARER RECONFIGURATION to UE, giving the parameters of cell 2. The UE configures layer 1 to
begin reception on the new frequency. After the UE receives confirmation from its physical layer, a
RADIO BEARER RECONFIGURATION COMPLETE message is sent to the RNC.
Test Verification:
On the Iub, there should be no or only a few RLC retransmission or reset of the protocol.
must contain inter-frequency measurements.
After step 6, check that the old radio link with cell 1 (on UTRA RF channel 1) was deleted.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.1.3 3G Handovers / inter-frequency handover / intra-nodeB handover (blind), with UE in

softer HO (2 legs) prior to hard HO
Test Purpose:
To check that when a UE is in macro-diversity with 2 cells and satisfies the criteria for being handed
over to another frequency, an intra-NodeB inter-frequency handover can successfully be performed by
the UTRAN and UE. For this particular test case, no inter-frequency measurements are made by the
mobile.
Pre-requisites:
Configuration: C (3 cells: cell 1 and cell 2 on using UTRA RF channel 1, cell 3 using UTRA RF
channel 2)
(or SIB#11).
Test Procedure:
that cell 2 satisfies the criterion to be added in the active set (see pre-requisites). RNC sends ACTIVE
SET UPDATE to UE, with parameters of cell 2 to be added to the active set. The UE configures layer
1 to begin reception for the additional radio link. After the UE receives confirmation from its physical
layer, an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Radio conditions are then changed so that the criterion/criteria for triggering an inter-frequency
handover to cell 3 is/are fulfilled. RNC sends RADIO BEARER RECONFIGURATION to UE, giving the
parameters of cell 3. The UE configures layer 1 to begin reception on the new frequency. After the UE
receives confirmation from its physical layer, a RADIO BEARER RECONFIGURATION COMPLETE
message is sent to the RNC.
Initial RF conditions: CPICH Ec/No for cell 1= -1 dB, for cell 2 = -6 dB, for cell 3 = -1 dB (suggestion)
Test Verification:
After steps 1 and 7, check the consistency of the measurements reported by the mobile. The


At step 12, check that the UE responds on the UTRA RF channel 2.
After step 12, check that the old radio links with (on UTRA RF channel 1) were deleted.
Message flow:

UE NW

by UTRAN.
test procedure.
by UTRAN.
by UTRAN.
test procedure.
measurements, as reques ted
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:
Test ID Protocol Te st case



F_6.6.2.1.4 3G Handovers / inter-frequency handover / intra-nodeB handover (with

Test Purpose:
over to another frequency, an intra-NodeB inter-frequency handover can successfully be performed by
the UTRAN and UE. For this particular test case, inter-frequency measurements are made by the
mobile.
Pre-requisites:
Configuration: C (3 cells: cell 1 and cell 2 using UTRA RF channel 1, cell 3 using UTRA RF channel 2)
Intra-frequency and inter-frequency measurements are set up by UTRAN using a MEASUREMENT
CONTROL message (or SIB#11).
Test Procedure:
Test Verification:
measurements report shall contain inter-frequency measurements.


After step 12, check that the old radio links (on UTRA RF channel 1) were deleted.
Message flow:

UE NW
1 MEASUREMENT REPORT UE returns intra-frequency and

inter-frequency
by UTRAN.
test procedure.
frequency and inter-frequency
by UTRAN.
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:



F_6.6.2.2.1 3G Handovers / inter-frequency handover / inter-nodeB handover (blind)
Test Purpose:
nodeB inter-frequency handover can successfully be performed by the UTRAN and UE. For this
particular test case, no inter-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: D (2 cells: cell 1 on nodeB1 using UTRA RF channel 1, cell 2 on nodeB2 using UTRA
RF channel 2)

(or SIB#11).
Test Procedure:
Test Verification:
After step 6, check that the old radio link with nodeB1 (on UTRA RF channel 1) was deleted.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.2.2 3G Handovers / inter-frequency handover / inter-nodeB handover (with inter-

frequency measurements)
Test Purpose:
nodeB inter-frequency handover can successfully be performed by the UTRAN and UE. For this
particular test case, inter-frequency measurements are made by the mobile using compressed mode
or a dual receiver, depending on UE capabilities.
Pre-requisites:
Configuration: D (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF channel 2)
(or SIB#11).
SIB#11 is configured to show parameters of cell 2
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that the criterion/criteria
for triggering an inter-frequency handover to cell 2 is/are fulfilled. RNC sends RADIO BEARER
RECONFIGURATION to UE, giving the parameters of cell 2. The UE configures layer 1 to begin
reception on the new frequency. After the UE receives confirmation from its physical layer, a RADIO
BEARER RECONFIGURATION COMPLETE message is sent to the RNC.
Test Verification:
After step 6, check that the old radio link with node1 (on UTRA RF channel 1) was deleted.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.2.3 3G Handovers / inter-frequency handover / inter-nodeB handover (blind), with UE in

Test Purpose:
over to another frequency, an inter-NodeB inter-frequency handover can successfully be performed by
mobile.
Pre-requisites:
Configuration: D (3 cells: cell 1 and cell 2 on nodeB1 using UTRA RF channel 1, cell 3 on nodeB2
using UTRA RF channel 2)
(or SIB#11).
Test Procedure:
Test Verification:


After step 12, check that the old radio links with nodeB1 (on UTRA RF channel 1) were deleted.
Message flow:

UE NW

by UTRAN.
test procedure.
by UTRAN.
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:



F_6.6.2.2.4 3G Handovers / inter-frequency handover / inter-nodeB handover (with

Test Purpose:
over to another frequency, an inter-NodeB inter-frequency handover can successfully be performed by
mobile.
Pre-requisites:
Configuration: D (3 cells: cell 1 and cell 2 on NodeB1 using UTRA RF channel 1, cell 3 on NodeB2
Test Procedure:
Initial RF conditions: CPICH Ec/No for cell 1= -1 dB, for cell 2 = -6 dB, for cell 3 (of NodeB 2) = -1 dB
(suggestion)
Test Verification:


Message flow:

UE NW

by UTRAN.
test procedure.
by UTRAN.
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:



F_6.6.2.3.1 3G Handovers / inter-frequency handover / inter-RNC handover (blind)
Test Purpose:
RNC inter-frequency handover can successfully be performed by the UTRAN and UE. For this
particular test case, no inter-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: E (2 cells: cell 1 on nodeB1 using UTRA RF channel 1, cell 2 on nodeB2 using UTRA
RF channel 2)

(or SIB#11).
Test Procedure:
Test Verification:
After step 6, check that the old radio link with nodeB1 (on UTRA RF channel 1) was deleted.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.3.2 3G Handovers / inter-frequency handover / inter-RNC handover (with inter-frequency

measurements)
Test Purpose:
RNC inter-frequency handover can successfully be performed by the UTRAN and UE. For this
particular test case, inter-frequency measurements are made by the mobile using compressed mode
or a dual receiver, depending on UE capabilities.
Pre-requisites:
(or SIB#11).
Test Procedure:
Test Verification:
To confirm that the UE can make inter-frequency measurements and return then coherently to UTRAN
To confirm that a new radio link is set up with nodeB2
To confirm that the old radio link with nodeB1 is deleted
After step 6, check that the old radio link with node1 (on UTRA RF channel 1) was deleted. Also,
check the quality of the transmission shall be verified, according to the test verification.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:



F_6.6.2.3.3 3G Handovers / inter-frequency handover / inter-RNC handover (blind), with UE in

Test Purpose:
over to another frequency, an inter-RNC inter-frequency handover can successfully be performed by
mobile.
Pre-requisites:
Configuration: E (3 cells: cell 1 and cell 2 on nodeB1-RNC1 using UTRA RF channel 1, cell 3 on
nodeB2-RNC2 using UTRA RF channel 2)
(or SIB#11).
Test Procedure:
handover to cell 3 is/are fulfilled. The serving RNC sends RADIO BEARER RECONFIGURATION to
UE, giving the parameters of cell 3. The UE configures layer 1 to begin reception on the new
frequency. After the UE receives confirmation from its physical layer, a RADIO BEARER
RECONFIGURATION COMPLETE message is sent to the target RNC.
Test Verification:


Message flow:

UE NW

by UTRAN.
test procedure.
by UTRAN.
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:



F_6.6.2.3.4 3G Handovers / inter-frequency handover / inter-RNC handover (with

Test Purpose:
over to another frequency, an inter-RNC inter-frequency handover can successfully be performed by
mobile.
Pre-requisites:
Configuration: E (3 cells: cell 1 and cell 2 on NodeB1-RNC1 using UTRA RF channel 1, cell 3 on
NodeB2-RNC2 using UTRA RF channel 2)
Test Procedure:
handover to cell 3 is/are fulfilled. The serving RNC sends RADIO BEARER RE CONFIGURATION to
UE, giving the parameters of cell 3. The UE configures layer 1 to begin reception on the new
frequency. After the UE receives confirmation from its physical layer, a RADIO BEARER
RECONFIGURATION COMPLETE message is sent to the target RNC.
Test Verification:


Message flow:

UE NW

by UTRAN.
test procedure.
by UTRAN.
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:



F_6.6.2.3.5 3G Handovers / inter-frequency handover / Combined hard handover and SRNS

relocation
Test Purpose:
To check that when the UTRAN decides to perform an inter-RNC hard handover, the NW can change
the UTRAN to CN point of connection at the UTRAN from the source RNC to the target RNC. The UE
will need to perform the hard handover and, if needed, perform a LA and/or RA update while in PMM-
CONNECTED.
Note1: this scenario is applicable in 2 cases: inter-PLMN (where there is no Iur) and intra-PLMN
Note2: for this scenario, measurement reports are usually used as a trigger in the UTRAN. However,
the procedure can also be done without measurements, and thus this is left to the testing parties to
decide.
Pre-requisites:
Inter-frequency measurements can be set up by UTRAN using a MEASUREMENT CONTROL
message (or SIB#11). A configuration G has to be added (new 2 PLMN with 1RNC and NodeB each)
Test Procedure:
handover to cell 2 is/are fulfilled. The SRNC decides to perform a combined hard handover and SRNS
relocation. The Source RNC will communicate with the Target RNC to establish the RABs and prepare
the relocation. The Source RNC sends a RADIO BEARER RECONFIGURATION message
(originating from the Target RNC) to UE. This RRC message will include UE information IEs (such as
the new SRNC ID) and CN information IEs (such as LAI and RAI). The UE configures layer 1 to begin
reception on the new frequency. After the UE receives confirmation from its physical layer, a RADIO
BEARER RECONFIGURATION COMPLETE message is sent to the Target RNC. The SRNS
relocation will then be completed in the NW.
If a change of LA and/or RA has occurred during the procedure, the UE will perform a LA and/or RA
update procedure.
Note that the Target RNC can send a different RRC message than the RB reconfiguration (physical or
transport channel reconfiguration messages can also be used).
Test Verification:
Verify that if the UE receives a new LAI and/or RAI, it initiates a LA and/or RA update procedure.


Message flow:
UE NW
1 Combined hard handover and SRNS Made by the SRNC

relocation decision
(DCCH) cell2. Including new RNC ID,
LAI and RAI.
COMPLETE (DCCH)
SRNS relocation is completed
in the NW
4** LA or RA UPDATE REQUEST** Initiated by the UE in case of a
new LAI and/or new RAI
5** LA or RA UPDATE ACCEPT**
** Only needed if the LAI and/or the RAI are different from the ones stored in the UE.
Remarks:



F_6.6.2.4.1 3G Handovers / inter-frequency handover / inter-PLMN (blind)
Test Purpose:
To check that when a UE satisfies the criteria for being handed over to another PLMN, an inter-PLMN
handover can successfully be performed by the UTRAN and UE and is followed by an SRNS
relocation. For this particular test case, no inter-frequency measurements are made by the mobile.
Pre-requisites:
Configuration: G (2 PLMNs, 1 cell in PLMN1: cell1 using UTRA RF channel 1 and 1 cell in PLMN2:
cell 2 using UTRA RF channel 2)
The UE has selected the cell1 in PLMN1. The UE has received the list of equivalent PLMNs through
Location Update Accept or Routing Area Update Accept message. The equivalent PLMN list contains
PLMN2.
(or SIB#11).
Test Procedure:
that the criterion/criteria for triggering an inter PLMN handover to cell2 is/are fulfilled. The SRNC
decides to perform a combined hard handover and SRNS relocation. The Source RNC will
communicate with the Target RNC to establish the RABs and prepare the relocation. The Source RNC
sends a RADIO BEARER RECONFIGURATION message (originating from the Target RNC) to UE.
This RRC message will include UE information IEs (such as the new SRNC ID) and CN information
IEs (such as LAI and RAI). The UE configures layer 1 to begin reception on the new frequency. After
the UE receives confirmation from its physical layer, a RADIO BEARER RECONFIGURATION
COMPLETE message is sent to the Target RNC. The SRNS relocation will then be completed in the
NW and is followed by LA and/or RA update procedure.
Test Verification:
Verify that the UE initiates a LA and/or RA update procedure.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
relocation decision
LAI and RAI.
COMPLETE (DCCH)
in the NW
7 LA and/or RA UPDATE REQUEST
8 LA and/or RA UPDATE ACCEPT
Remarks:



F_6.6.2.4.2 3G Handovers / inter-frequency handover / inter-PLMN (with measurements)
Test Purpose:
relocation. For this particular test case, inter-frequency measurements are made by the mobile using
Pre-requisites:
cell 2 using UTRA RF channel 2)
The UE has selected the cell1 in PLMN1. The UE has received the list of equivalent PLMNs through
Location Update Accept or Routing Area Update Accept message. Th e equivalent PLMN list contains
PLMN2.
Intra-frequency and Inter-frequency measurements can be set up by UTRAN using a
MEASUREMENT CONTROL message (or SIB#11).
SIB#11 is configured to show parameters of cell 2 PLMN2 (on UTRA RF channel 2)
A call has been established with cell 1 PLMN1, and the UE is in the following state:
Test Procedure:
that the criterion/criteria for triggering an inter PLMN handover to cell2 is/are fulfilled. The SRNC
decides to perform a combined hard handover and SRNS relocation. The Source RNC will
communicate with the Target RNC to establish the RABs and prepare the relocation. The Source RNC
sends a RADIO BEARER RECONFIGURATION message (originating from the Target RNC) to UE.
This RRC message will include UE information IEs (such as the new SRNC ID) and CN information
IEs (such as LAI and RAI). The UE configures layer 1 to begin reception on the new frequency. After
the UE receives confirmation from its physical layer, a RADIO BEARER RECONFIGURATION
COMPLETE message is sent to the Target RNC. The SRNS relocation will then be completed in the
NW and is followed by LA and/or RA update procedure.
Test Verification:
Verify that the UE initiates a LA and/or RA update procedure.


Message flow:
UE NW

by UTRAN.
test procedure.
by UTRAN.
relocation decision
LAI and RAI.
COMPLETE (DCCH)
in the NW
7 LA and/or RA UPDATE REQUEST
8 LA and/or RA UPDATE ACCEPT
Remarks:



F_6.6.3.1 Compressed mode / GSM measurements
Test Purpose:
To check that when the criteria for activating inter-system measurements are satisfied, compressed
mode is properly activated in UL and/or DL, that the UE can measure the GSM cells RSSI and
decode its BSIC and that compressed mode is deactivated when inter-system measurements are no
more required.
References: 3GPP TS 25.133 clause 8.1.2.5, 3GPP TS 25.331 clause 8.4.1.3.
Pre-requisites:
Configuration: F or G.
A call has been established on cell1, and the UE is in the following state:
Test Procedure:
At the RRC connection establishment, the UE indicates to the network, in the RRC Connection Setup
Complete, in the UE Radio Access Capabilities, if compressed mode is required in UL and or DL for
the FDD, GSM450, GSM480, GSM850, GSM900P, GSM900E, GSM1800, GSM1900 bands.
Compressed mode configuration is given to the UE in the Radio Bearer setup/reconfiguration
message or in the PHYSICAL CHANNEL Reconfiguration message during or following the call
establishment. Regarding GSM measurements, there may be up to 3 pattern sequences needed:
- GSM RSSI Measurement Pattern Sequence,
- GSM Initial BSIC Identification Pattern Sequence,
- GSM BSIC Re-confirmation Pattern Sequence.
criterion for triggering inter-system measurements and compressed mode. However, other criteria can
be used.
that the criterion/criteria for triggering compressed mode and inter-system measurements is/are
fulfilled. RNC sends MEASUREMENT CONTROL to UE, giving for each TGPS (Transmission, Gap
Pattern Sequence) the activation CFN and the status flag set to active.
If the compressed mode is using finite length patterns, it does not need to be deactivated but may
need to be reactivated if the inter-system measurements criteria is /are still verified. In that case, the
network reactivates the compressed mode by sending MEASUREMENT CONTROL to the UE.
If the compressed mode is using infinite length patterns, it shall be deactivated by the network with a
MEASUREMENT CONTROL sent to the UE if inter-system measurements criteria is /are no more
verified.
Test Verification:
To confirm that compressed mode is activated when the inter-system measurements criteria is /are
valid.
To verify that the UE can acquire a GSM cell, can measure the cells RSSI and decode the BSIC of
cell.
To verify that, the accuracy of GSM Carrier RSSI measurements, is within acceptable limits.
To confirm that during the compressed mode activation, the quality of the transmission is as follows:
No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate (QE)
and the CRC Indication (CRCI) in the uplink dedicated FP frames, as specified in TS 25.427.



Packet call: no major impact on throughput. The TCP repetitions shall be checked. On the Iub,
there should be no or only a few RLC retransmission or reset of the protocol.
To confirm that, if the compressed mode is using finite length patterns, it is reactivated if the inter-
system measurements criteria is /are still verified.
To confirm that, if the compressed mode is using infinite length patterns, it is deactivated if inter-
system measurements criteria is /are no more valid.
Message flow:

UE NW

2 RRC CONNECTION SETUP GSM capabilities required
3 RRC CONNECTION SETUP UE Radio Access
COMPLETE Capabilities
CS or PS call establishment
test procedure.
5 MEASUREMENT CONTROL TGPS CFN, TGPS Status
flag set to active
6 MEASUREMENT REPORT GSM RSSI, BSIC verified
or non verified
7 MEASUREMENT REPORT* GSM RSSI, BSIC verified
or non verified
8 MEASUREMENT CONTROL For CM reactivation or
deactivation
Remarks:
*Optional: Measurement reports can be periodic and are sent according to the reporting period. They
can be also event triggered measurement report and are sent only when the reporting criteria are
fulfilled.

1b Not mapped RRC / RRC Connection Establishment in CELL_FACCH state: Success


F_6.6.3.2 Compressed mode / GSM measurements / Softer Handover
Test Purpose:
To check that when a UE is in macro-diversity with 2 cells and when the criteria for activating inter-
system measurements are satisfied, compressed mode is properly activated in UL and/or DL, that the
UE can measure the GSM cells RSSI and decode its BSIC and that compressed mode is deactivated
when inter-system measurements are no more required.
Pre-requisites:
Configuration: F
Test Procedure:
At the RRC connection establishment, the UE indicates to the network, in the RRC Connection Setup
Complete, in the UE Radio Access Capabilities, if compressed mode is required in UL and or DL for
establishment. Regarding GSM measurements, there may be up to 3 pattern sequences needed:
- GSM RSSI Measurement Pattern Sequence,
- GSM Initial BSIC Identification Pattern Sequence,
- GSM BSIC Re-confirmation Pattern Sequence.
that cell 2 satisfies the criterion to be added in the active set. RNC sends ACTIVE SET UPDATE to
UE, with parameters of cell 2 to be added to the active set. The UE configures layer 1 to begin
reception for the additional radio link. After the UE receives confirmation from its physical layer, an
be used.
that the criterion/criteria for triggering compressed mode and inter-system measurements is/are
need to be reactivated if the inter-system measurements criteria is /are still verified. In that case, the
network reactivates the compressed mode by sending MEASUREMENT CONTROL to the UE.
MEASUREMENT CONTROL sent to the UE if inter-system measurements criteria is /are no more
verified.
Test Verification:
To confirm that compressed mode is activated when the inter-system measurements criteria is /are
valid.
To verify that the UE can acquire a GSM cell, can measure the cells RSSI and decode the BSIC of
cell.


To verify that, the accuracy of GSM Carrier RSSI measurements, is within acceptable limits.
No degradation of the uplink BLER shall be seen on the Iub thanks to the Quality Estimate (QE)
and the CRC Indication (CRCI) in the uplink dedicated FP frames, as specified in TS 25.427.
Packet call: no major impact on throughput. The TCP repetitions shall be checked. On the Iub,
there should be no or only a few RLC retransmission or reset of the protocol.
system measurements criteria is /are still verified.
system measurements criteria is /are no more valid.
Message flow:

UE NW

measurements, as
requested by UTRAN.
test procedure.
measurements, as
requested by UTRAN.
(DCCH)
test procedure.
flag set to active
12 MEASUREMENT REPORT GSM RSSI, BSIC verified
or non verified
13 MEASUREMENT REPORT* GSM RSSI, BSIC verified
or non verified
deactivation
Remarks:
fulfilled.



1b Not mapped RRC / RRC Connection Establishment in CELL_FACH state: Success


F_6.6.3.3 Compressed mode / Inter-frequency measurements
Test Purpose:
To check that when the criteria for activating inter-frequency measurements are satisfied, compressed
mode is properly activated in UL and/or DL, that the UE can measure the new frequency CPICH
Ec/No and CPICH RSCP and that compressed mode is deactivated when inter-frequency
measurements are no more required.
Pre-requisites:
Test Procedure:
At the RRC connection establishment, the UE indicates to the network in the RRC Connection Setup
Complete, in the UE Radio Access Capabilities if compressed mode is required in UL and or DL for
establishment. Regarding FDD inter-frequency measurements, only 1 pattern sequence is needed:
FDD Measurement Pattern Sequence.
criterion for triggering inter-frequency measurements and compressed mode. However, other criteria
can be used.
that the criterion/criteria for triggering compressed mode and inter-frequency measurements is/are
need to be reactivated if the inter-frequency measurements criteria is /are still verified. In that case,
the network reactivates the compressed mode by sending MEASUREMENT CONTROL to the UE.
MEASUREMENT CONTROL sent to the UE if inter-frequency measurements criteria is /are no more
verified.
Test Verification:
To confirm that compressed mode is activated when the inter-frequency measurements criteria is /are
valid.
To verify that the UE can measure the new frequency CPCIH Ec/No and CPICH RSCP and that the
measurements are within acceptable limits.


frequency measurements criteria is /are still verified.
frequency measurements criteria is /are no more valid.
Message flow:

UE NW

test procedure.
flag set to active
6 MEASUREMENT REPORT CPICH Ec/No, CPICH
RSCP
7 MEASUREMENT REPORT* CPICH Ec/No, CPICH
RSCP
deactivation
Remarks:
fulfilled.

1b Not mapped RRC / RRC Connection Establishment in CELL_FACCH state: Success
3 E_8.4.1.8 RRC / Measurement Control and Report: Inter- frequency measurement
for transition from CELL_FACH to CELL_DCH state


F_6.6.3.4 Compressed mode / Inter-frequency measurements / Softer Handover
Test Purpose:
To check that when a UE is in macro-diversity with 2 cells and when the criteria for activating inter-
frequency measurements are satisfied, compressed mode is properly activated in UL and/or& DL, that
the UE can measure the new frequency CPICH Ec/No and CPICH RSCP and that compressed mode
is deactivated when inter-frequency measurements are no more required.
Pre-requisites:
Configuration: C (cells 1&2 using UTRA RF channel 1, cell 3 using UTRA RF channel 2)
Test Procedure:
At the RRC connection establishment, the UE indicates to the network in the RRC Connection Setup
Complete, in the UE Radio Access Capabilities if compressed mode is required in UL and or DL for
Compressed mode configuration is given to the UE in the Radio Bearer setup/reconfiguration or in the
PHYSICAL CHANNEL Reconfiguration message during or following the call establishment. Regarding
FDD inter-frequency measurements, only 1 pattern sequence is needed: FDD Measurement Pattern
Sequence.
that cell 2 satisfies the criterion to be added in the active set. RNC sends ACTIVE SET UPDATE to
UE, with parameters of cell 2 to be added to the active set. The UE configures layer 1 to begin
reception for the additional radio link. After the UE receives confirmation from its physical layer, an
be used.
that the criterion/criteria for triggering compressed mode and inter-frequency measurements is/are
need to be reactivated if the inter-frequency measurements criteria is /are still verified. In that case,
the network reactivates the compressed mode by sending MEASUREMENT CONTROL to the UE.
MEASUREMENT CONTROL sent to the UE if inter-frequency measurements criteria is /are no more
verified.
Test Verification:
To confirm that compressed mode is activated when the inter-frequency measurements criteria is /are
valid.
To verify that the UE can measure the new frequency CPCIH Ec/No and CPICH RSCP and that the
measurements are within acceptable limits.


frequency measurements criteria is /are still verified.
frequency measurements criteria is /are no more valid.
Message flow:

UE NW

measurements, as
requested by UTRAN.
test procedure.
measurements, as
requested by UTRAN.
(DCCH)
test procedure.
flag set to active
12 MEASUREMENT REPORT CPICH Ec/No, CPICH
RSCP
13 MEASUREMENT REPORT* CPICH Ec/No, CPICH
RSCP
deactivation
Remarks:
fulfilled.

1b Not mapped RRC / RRC Connection Establishment in CELL_FACH state: Success
3 E_8.4.1.8 RRC / Measurement Control and Report: Inter- frequency measurement
for transition from CELL_FACH to CELL_DCH state


F_6.7.1 Inter system handover to UTRAN/From GSM/Speech/Success
Test Purpose:
To test that UE supporting both GSM and UTRAN handovers to the indicated channel in the UTRAN
target cell when it is in the speech call active state in the GSM serving cell and receives a
INTERSYSTEM TO UTRAN HANDOVER COMMAND.
Reference: 3GPP TS 25.331 Clause 8.3.6, 3GPP TS 04.18 Clause 3.4.4a.
Pre-requisites:
Configurations: F
Test Procedure:
The NW starts the GSM cell and UTRAN cell with cell selection conditions in favour of GSM cell,
the UE selects the GSM cell for camping on. UTRAN cell broadcasts SIB16 that contains
the pre-configuration for conversational/speech /UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4
DL3.4 kbps SRBS.
After UE received and stored the SIB16, the NW brings the UE into the call active state (CC state
U10) with FR speech call (for execution counter M = 1).
The NW configures the dedicated channel corresponding to the pre-configuration in UTRAN cell,
and then sends INTERSYSTEM TO UTRAN HANDOVER COMMAND indicating the
dedicated channel of the target cell to the UE through the GSM serving cell.
After the UE receives the command it shall configure itself accordingly and switch to the dedicated
channel of UTRAN cell.
The NW checks whether the handover is performed by checking that the UE transmits
HANDOVER TO UTRAN COMPLETE to the NW through DCCH of the UTRAN cell.
The above procedure is executed maximum four times, each time for different initial conditions:
If the UE supports GSM FR, the procedure is executed for execution counter M = 1;
If the UE supports GSM EFR, the procedure is executed for execution counter M = 2;
If the UE supports GSM AMR, the procedure is executed for execution counter M = 3;
If the UE supports GSM HR, the procedure is executed for execution counter M = 4.
Test Verification:


Message Flow:
This sequence is performed for a maximum execution counter M = 1, 2, 3, 4, depending on the PIXIT
parameters.
UE NW
1 NW The NW configures GSM and UTRAN cells, UE camps
on GSM cell and receives SIB16 from UTRAN cell.
2 UE The NW brings the UE into GSM U10 state in cell 1 and
for M = 1: the UE is in GSM FR speech call;
for M = 2: the UE is in GSM EFR speech call;
for M = 3: the UE is in GSM AMR speech call;
for M = 4: the UE is in GSM HR speech call.
3 NW The NW configures the dedicated channel with the
configuration: conversational/speech/UL:12.2 DL:12.2
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs in UTRAN cell.
4 INTERSYSTEM TO UTRAN Send on cell 1 (GSM cell)
HANDOVER COMMAND
5 UE The UE accepts the handover command and configures
its lower layers using the parameters contained in the
INTERSYSTEM TO UTRAN HANDOVER COMMAND
6 NW The NW waits for uplink physical channel in
synchronization
7 HANDOVER TO UTRAN The NW receives this message on DCCH of cell 2
COMPLETE (UTRAN cell). It implies that the down link physical
channel has synchronised with UTRAN.
8 Verify that there is audio on the UL and DL
Remarks:
After HANDOVER TO UTRAN COMPLETE the ongoing call shall be continued on UTRAN cell.


F_6.7.2 Inter system handover to UTRAN/From GSM/Data/Same data rate/Success
Test Purpose:
To test that the UE handovers to the indicated UTRAN target cell and the data rate of the target
channel is the same as the old channel when it is in the data call active state in the GSM serving cell
and receives a INTER SYSTEM TO UTRAN HANDOVER COMMAND.
Pre-requisites:
Configurations: F
Test Procedure:
The NW starts the GSM cell and the UTRAN cell. The cell selection conditions of these two
cells are in favour of GSM cell. The UE selects the GSM cell for camping on.
After the UE receives and stores pre-configuration information from SIB16 broadcast in the
UTRAN cell, the NW brings the UE into the call active state (CC state U10) with 14.4
kbps CS data call (for execution counter M = 1).
The NW configures a dedicated channel corresponding to the pre-configuration
(streaming/unknown/UL:14.4 DL:14.4 kbps/CS RAB + UL:3.4 DL3.4 kbps SRBS for M =
1) in UTRAN cell, then sends INTER SYSTEM TO UTRAN HANDOVER COMMAND
indicating the dedicated channel of the target cell to the UE through the GSM serving
cell.
After the UE receives the command it shall configure itself accordingly and switch to the
dedicated channel of the UTRAN cell.
The above procedure is executed maximum three times, each time for different initial conditions:
If the UE supports GSM 14.4 kbps CS data and UTRAN streaming/unknown/UL:14.4 DL:14.4
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs, the procedure is executed for execution
counter M = 1;
counter M = 2;
counter M = 3;
Alternatively a conversational class can be used.
Test Verification:


Message Flow:
This sequence is performed for a maximum execution counter M = 1, 2, 3.

UE NW
1 NW The NW configures GSM and UTRAN cells, the UTRAN
cell broadcasts SIB16 containing pre-configuration
information:
For M = 1: (streaming/unknown/UL:14.4 DL:14.4 kbps/CS
RAB + UL:3.4 DL3.4 kbps SRBs);
RAB + UL:3.4 DL3.4 kbps SRBs).
UE camps on GSM cell and received SIB16 from UTRAN
cell.
2 UE The NW bring the UE into GSM U10 state in cell 1 and
for M = 1: the UE is in GSM 14.4 kbps CS data call;
3 NW The NW configures a dedicated channel in the UTRAN
cell with the configuration:
RAB + UL:3.4 DL3.4 kbps SRBs)
4 INTER SYSTEM TO UTRAN Send on cell 1 (GSM cell)
HANDOVER COMMAND
INTER SYSTEM TO UTRAN HANDOVER COMMAND
synchronization.
8 Check data rate on the new UMTS cell is the same as the
rate on the GSM cell.
Remarks:


F_6.7.3 Inter system handover to UTRAN/From GSM/Data/Data rate upgrading/Success
Test Purpose:
To test that the UE being in the data call active state handovers from the GSM serving cell to the
indicated channel of a higher data rate in the UTRAN target cell after it receives a INTER SYSTEM TO
UTRAN HANDOVER COMMAND.
Reference: 3GPP TS 25.331 Clause 8.3.6, 3GPPTS 04.18 Clause 3.4.4a.
Pre-requisites:
Configurations: F
Test Procedure:
The NW starts the GSM cell and the UTRAN cell with cell selection conditions in favour of GSM
cell. In UTRAN cell SIB16 is broadcast. The UE selects the GSM cell and received the
pre-configuration information from SIB16.
The NW brings the UE into the call active state (CC state U10) with 14.4 kbps CS data call (for
execution counter M = 1).
(streaming/unknown/UL:28.8 DL:28.8 kbps/CS RAB + UL:3.4 DL3.4 kbps SRBS for M =
1), then sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating the
After the UE receives the command it shall configure itself accordingly and switch to the new
channel of the UTRAN cell.
The above procedure is executed maximum three times, each time for different conditions:
counter M = 1;
counter M = 2;
counter M = 3;
Test Verification:


Message Flow:

UE NW
1 NW The NW configures GSM and UTRAN cells, the UTRAN
cell broadcasts SIB16 containing pre-configuration
information:
RAB + UL:3.4 DL3.4 kbps SRBs).
UE camps on GSM cell and received SIB16 from UTRAN
cell.
2 UE The NW brings the UE into GSM U10 state in cell 1 and
3 NW The NW configures a dedicated channel in the UTRAN
cell with the configuration:
RAB + UL:3.4 DL3.4 kbps SRBs)
HANDOVER COMMAND
synchronization
8 Check that UE transfers data at the new data rate in
UMTS cell.
Remarks:


F_6.7.4 Inter system handover to UTRAN/ From GSM/Speech/Establishment/Success
Test Purpose:
The purpose of this test is to verify handovers from the GSM serving cell to the indicated channel in
UTRAN target cell when the MS is in the call establishment phase and receives a INTER SYSTEM TO
Reference: 3GPP 25.331 section 8.3.6 and & GSM TS 04.18 section 3.4.4a & 3GPP TS 51.010-1
section 26.6.5.1 & 3GPP TS 34.108 section 6.2.
Pre-requisites:
Configuration: F
The MS shall be in CC state U1 in the GSM cell.
The MS supports both GSM and UTRAN Radio Access Technologies.
The MS supports UTRAN AMR.
The MS supports GSM FR.
Test Procedure:
The NW starts GSM cell and UTRAN cell with the cell selection conditions in favour of GSM cell.
The MS selects the GSM cell.
After the MS camps on the GSM cell and received SIB16 broadcast in the UTRAN cell, the MS is
triggered to make an MO speech call.
After the NW received SETUP message it configures a dedicated channel corresponding to the
predefined configuration (conversationa/speech/UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4
DL3.4 kbps SRBS) described by SIB16.
Then the NW sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating the
dedicated channel to the MS through the GSM serving cell.
After the MS receives the command and it shall configure itself accordingly and switch to the new
The NW checks whether the handover is performed by checking that the MS transmits
Test Verification:
Verify that after step 11 the ongoing call is continued on UTRAN cell.
Message Flow:

MS NW
1 NW The NW configures GSM and UTRAN cells, MS
camps on GSM cell and received SIB16 from
UTRAN cell.
2 MS To trigger MS to make an MO call
3 CHANNEL REQUEST initiate outgoing call
4 IMMEDIATE ASSIGNMENT SDCCH, U0
5 CM SERVICE REQUEST U0.1
6 SETUP U1
7 NW The NW configures a dedicated channel with the
configuration: conversational/speech/UL:12.2
DL:12.2 kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs
in UTRAN cell.
8 INTER SYSTEM TO UTRAN Send on GSM cell


HANDOVER COMMAND
9 MS The MS accepts the handover command and
configures its lower layers using the parameters
contained in the INTER SYSTEM TO UTRAN
HANDOVER COMMAND
synchronization
11 HANDOVER TO UTRAN The NW receives this message on DCCH of the
COMPLETE UTRAN cell. It implies that the down link physical
12 Check data transfer on UMTS Cell
Remarks:
None.


F_6.7.5 Inter system handover to UTRAN/From GSM/Speech/Blind HO/Success
Test Purpose:
To test that the UE handovers from the GSM serving cell to the indicated channel of UTRAN target
cell when it is in the speech call active state without any knowledge of the target system (blind
handover) and receives a INTER SYSTEM TO UTRAN HANDOVER COMMAND.
Pre-requisites:
Configurations: F
Test Procedure:
cell, SIB16 is not broadcast in the UTRAN cell and the UE does not have any
predefined configuration stored. The UE selects the GSM cell.
The NW brings the UE into the call active state (CC state U10) with FR speech. The NW
configures a dedicated channel (conversational/speech/UL:12.2 DL:12.2 kbps/CS RAB
+ UL:3.4 DL3.4 kbps SRBS), then sends INTER SYSTEM TO UTRAN HANDOVER
COMMAND indicating the dedicated channel of the target cell to the UE through the
GSM serving cell.
dedicated channel of UTRAN cell.
Test Verification:
Message Flow:
UE NW
1 UE The NW bring the UE into GSM U10 state in cell 1 and
the UE has no any pre-configuration information stored
2 NW The NW configures dedicated channel with the
configuration: conversational/speech/UL:12.2 DL:12.2
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs in UTRAN cell.
HANDOVER COMMAND
synchronization
7 Check for voice on UL and DL while UE is in the new
UMTS cell.
Remarks:


F_6.7.6 Inter system handover to UTRAN/ From GSM/Speech/Failure
Test Purpose:
The purpose of this test is to verify the reactivation of the old channels and the transmission of
HANDOVER FAILURE message to the network on the old channel in the GSM cell when the INTER
SYSTEM TO UTRAN HANDOVER COMMAND and the handover to UTRAN fails.
section 26.6.5.1 & 3GPP TS 34.108 section 6.1
Pre-requisites:
Configuration: F
Test Procedure:
cell.
SIB16 is broadcast in UTRAN cell.
The NW brings the MS into the call active state (CC state U10) with FR speech call.
The NW does not configure the dedicated channel corresponding to the predefined configuration
described in SIB16 (conversationa/speech/UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4 DL3.4
kbps SRBS), then sends INTE R SYSTEM TO UTRAN HANDOVER COMMAND indicating the
dedicated channel of the target cell to the MS through the GSM serving cell.
Test Verification:
Verify that the handover is failed by checking that the MS returns to the old channel and transmits
HANDOVER FAILURE to the NW through the old channel.
Message Flow:
MS NW
1 NW The NW starts GSM and UTRAN cells, SIB16 is
broadcast in the UTRAN cell. The MS camps on
GSM cell and received SIB16.
2 MS The NW bring the MS into GSM U10 state in cell
1
3 NW There is no dedicated channel with the
in UTRAN cell.
HANDOVER COMMAND
HANDOVER COMMAND
6 MS The MS fails to establish a connection to UTRAN
cell
7 HANDOVER FAILURE The NW receives this message on DCCH of GSM
cell (old channel)
Remarks:
None.


F_6.7.7 Inter system 2G to 3G cell reselection in Idle Mode
Test Purpose:
To verify that UE reselects 3G cell that meets cell reselection criteria in idle mode on a 2G cell
Reference: 3GPP TS25.331 Section 8.3.8
Pre-requisites:
Configuration: F (UTRAN and GSM/GPRS cells belong to same PLMN but different location area)
(or)
Configuration: H (UTRAN and GSM/GPRS cells belong to equivalent PLMNs)
UE supports Both GSM/GPRS and WCDMA radio access technologies
UE camps on a suitable 2G cell and performs successful PS and CS registrations.
The 3G neighbor cell information of 2G cell refers to target 3G cell
Test Procedure:
When UE is in Idle mode on a 2G cell, radio conditions are modified such that UE ranks 3G cell better
than serving cell
After reselecting to 3G cell UE performs Location Area Update and Routing Area Update procedures
in case of NMO II (or) performs Combined Routing Area Update procedure in case of NMO I
Test Verification:
Verify that UE ranks 3G neighbor cells correctly

Verify that UE reselects to 3G cell according to the network settings for cell reselection parameters
Verify that UE performs Location Area Update and Routing Area Update procedures in case of NMO II
(or) performs Combined Routing Area Update procedure in case of NMO I after reselecting to target
3G cell.
Verify that the establishment cause in RRC Connection Request message is set to Inter-RAT cell
reselection by UE
Message Flow:
UE NW
1 NW The NW configures 2G and 3G cells, UE camps on
2G cell
2 UE UE reads the 3G neighbor cell information from
system information of 2G cell. Radio conditions are
modified such that UE starts evaluation of cell
reselection criteria
3 UE UE reselects to 3G cell according to the network
settings. UE stops GSM mode and starts WCDMA
mode.
4 UE UE performs Location Area Update and Routing
Area Update procedures in case of NMO II (or)
performs Combined Routing Area Update
procedure in case of NMO I on WCDMA cell and
stays on WCDMA cell. Verify that RRC Connection
Establishment cause is set to Inter-RAT cell
reselection


Remarks:
On 2G cell, UE evaluates 3G neighbors broadcasted in system information as follows

If 2G cell supports PBCCH, UE considers 3G neighbor information from PSI3 Qtr system information
message
If 2G cell does not support PBCCH, UE considers 3G neighbor information from SI2 Qtr system
information message or SI2ter system information message or both


F_6.7.8 Inter system 2G to 3G cell reselection in Packet Transfer Mode
Test Purpose:
To verify that UE reselects WCDMA cell that meets cell reselection criteria in packet transfer mode on
a 2G cell
Pre-requisites:
(or)
GSM/GPRS cell supports NC 0 or NC 1
PS data call is established on 2G cell and data transfer is in progress
Test Procedure:
When UE is in packet transfer mode on a 2G cell, radio conditions are modified such that UE ranks 3G
cell better than serving cell
in case of NMO II (or) performs Combined Routing Area Update procedure in case of NMO I and
resumes the data transfer
Test Verification:
Verify that UE ranks 3G neighbor cells correctly while in packet transfer mode
Verify that UE reselects to 3G cell according to the network settings for cell reselection parameters
(or) performs Combined Routing Area Update procedure in case of NMO I after reselecting to 3G cell.
Verify that the establishment cause in RRC Connection Request message is set to Inter-RAT cell
reselection by UE
Verify that UE resumes data transfer on 3G cell
Message Flow:
UE NW
2G cell
3 UE UE reselects to 3G cell according to the network
settings.. UE stops GSM mode and starts WCDMA
mode.
procedure in case of NMO I on WCDMA cell. Verify


that RRC Connection Establishment cause is set to

Inter-RAT cell reselection
5 UE UE resumes data transfer by performing GMM
Service Request procedure and Radio Bearer
Setup procedure
Remarks:
On 2G cell, UE evaluates 3G neighbors broadcasted in system information as follows

If 2G cell supports PBCCH, UE considers 3G neighbor cell information from PSI3 Qtr system
information message
If 2G cell does not support PBCCH, UE considers 3G neighbor cell information from SI2 Qtr system
information message
UE can set FOR bit to 1 in Routing Area update Request message after reselecting to WCDMA cell


F_6.7.9 Inter system 3G to 2G cell reselection in Idle Mode
Test Purpose:
To verify that UE reselects 2G cell that meets cell reselection criteria in idle mode on a 3G cell
3GPP TS25.304 Section 5.2.6
Pre-requisites:
(or)
Test Procedure:
When UE is in Idle mode on a 3G cell, radio conditions are modified such that UE ranks 2G cell better
than serving cell
After reselecting to 2G cell UE performs
Location Area Update and Routing Area Update procedures in case of NMO II or
Combined Routing Area Update procedure in case of NMO I
Test Verification:
Verify that UE ranks 2G neighbor cells correctly
Verify that UE reselects to 2G cell accoring to NW settings for cell reselection parameters after
validating that neighbor cell is better ranked than the current cell for timer interval Treselection
(or) performs Combined Routing Area Update procedure in case of NMO I after reselecting to target
2G cell.
Message Flow:
UE NW
3G cell
3 UE UE reselects to 2G cell after validating that
neighbor cell is better ranked than the current cell
for timer interval Treselection. UE stops WCDMA
mode and starts GSM mode.
procedure in case of NMO I on 2G cell and stays on
2G cell


Remarks:


F_6.7.10 Inter system 3G to 2G cell reselection in Connected Mode (Cell_FACH state)
Test Purpose:
To verify that UE reselects 2G cell that meets cell reselection criteria in Cell_FACH state
Reference: 3GPP TS25.331 Section 8.3.9; TS 34.123 Section 8.3.9
Pre-requisites:
(or)
UE is in Cell_FACH state and data transfer is taking place.
Test Procedure:
When UE is in Cell_FACH state, radio conditions are modified such that UE ranks 2G cell better than
serving cell
in case of NMO II (or) performs Combined Routing Area Update procedure in case of NMO I and
resumes the data transfer
Test Verification:
Verify that UE ranks 2G neighbor cells correctly while in Cell_FACH state

Verify that UE reselects to 2G cell accoring to NW settings for cell reselection parameters after
Verify that UE resumes data transfer on 2G cell
Message Flow:
UE NW
3G cell


procedure in case of NMO I on 2G cell

5 NW NW may request for PDP context modification
6 UE UE resumes data transfer on 2G cell
Remarks:

1 Cell reselection if cell becomes barred or S<0; UTRAN to GPRS
B_8.3.9.1
(CELL_FACH)
2 Successful Cell Reselection with RAU Qoffset value modification;
B_8.3.9.5 UTRAN to GPRS (CELL_FACH)


F_6.7.11 Inter system 3G to 2G cell reselection in Connected Mode (URA_PCH state)
Test Purpose:
To verify that UE reselects 2G cell that meets cell reselection criteria in URA_PCH state
Pre-requisites:
(or)
Test Procedure:
PS data call is initiated and UE is transitioned to URA_PCH state

When UE is in URA_PCH state, radio conditions are modified such that UE ranks 2G cell better than
serving cell
in case of NMO II (or) performs Combined Routing Area Update procedure in case of NMO I.
Start data transfer. UE should be able to send/receive data to/from the network
Test Verification:
Verify that UE transitions to URA_PCH state successfully during PS data call

Verify that UE ranks 2G neighbor cells correctly while in URA_PCH state
Verify that UE reselects to 2G cell according to network settings for cell reselection parameters after
Verify that UE is able to send/receive data to/from the network
Message Flow:
UE NW
3G cell
system information of 3G cell. PS data call is
initiated and UE is transitioned to URA_PCH state.
Radio conditions are modified such that UE starts
evaluation of cell reselection criteria



5 UE Data transfer is started. Verify that UE is able to
send/receive data to/from the network
Remarks:

1 RRC / Radio Bearer Reconfiguration from CELL_DCH to URA_PCH:
B_8.2.2.22
Success
2 E_8.3.9.2 Cell reselection if cell becomes barred or S<0; UTRAN to GPRS
(URA_PCH)


F_6.7.12 Inter system 3G to 2G cell reselection in Connected Mode (Cell_PCH state)
Test Purpose:
To verify that UE reselects 2G cell that meets cell reselection criteria in Cell_PCH state
Pre-requisites:
(or)
Test Procedure:
PS data call is initiated and UE is transitioned to Cell_PCH state

When UE is in Cell_PCH state, radio conditions are modified such that UE ranks 2G cell better than
serving cell
in case of NMO II (or) performs Combined Routing Area Update procedure in case of NMO I.
Start data transfer. UE should be able to send/receive data to/from the network
Test Verification:
Verify that UE transitions to Cell_PCH state successfully during PS data call

Verify that UE ranks 2G neighbor cells correctly while in Cell_PCH state
Verify that UE reselects to 2G cell according network settings for cell reselection parameters after
Verify that UE is able to send/receive data to/from the network
Message Flow:
UE NW
3G cell
system information of 3G cell. PS data call is
initiated and UE is transitioned to Cell_PCH state.
Radio conditions are modified such that UE starts
evaluation of cell reselection criteria



5 UE Data transfer is started. Verify that UE is able to
send/receive data to/from the network
Remarks:

1 RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_PCH:
B_8.2.2.21
Success


F_6.7.13 Inter-RAT mobility / RRC connection reject Redirection to GSM (successful case)
Test Purpose:
To check that when the network rejects the RRC connection request from the UE, and includes the
inter-RAT info IE (within the redirection info IE), the UE is able to select a suitable cell in GSM.
Pre-requisites:
Configuration: F and G (2 cells: cell 1 using GSM, cells 2-3-4 using UTRA)
SIB#11 of cell 2 is configured to show parameters of cell 1

No resources are available on the 3G side to perform the call (this should trigger the redirection to 2G,
but other triggers can be used)
Test Procedure:
A call attempt is made in 3G. UTRAN redirects the UE to GSM using the RRC connection reject. UE
selects cell 1 and performs outgoing call.
Test Verification:
After having selected a cell in GSM, the call attempt should be triggered.
Message flow:
UE NW

2 RRC CONNECTION REJECT Redirection info = inter-RAT
info = GSM
Remarks:

1 8.1.2.12 RRC Connection Establishment: Reject with interRAT Info is set to GSM


F_6.7.14 Inter-RAT mobility / RRC connection reject Redirection to GSM (unsuccessful case)
Test Purpose:
To check that when the network rejects the RRC connection request from the UE, and includes the
inter-RAT info IE (within the redirection info IE),but the 2G cell is not available, the UE does not
request an RRC connection establishment for a certain time (i.e. wait time).
Pre-requisites:
Configuration: F and G (2 cells: cell 1 using GSM, cells 2-3-4 using UTRA)

No resources are available on the 3G side to perform the call (this should trigger the redirection to 2G)
Cell 1 is switched OFF or barred
Test Procedure:
A call attempt is made in 3G. UTRAN redirects the UE to GSM using the RRC connection reject. UE
does not find a suitable cell in 2G and performs RRC connection request after wait time indicated in
RRC connection reject.
Test Verification:
If there is no suitable cell in GSM, the UE shall not attempt an RRC connection request before wait
time has expired (if wait time = 0, the procedure shall not be repeated).
Message flow:
UE NW

2 RRC CONNECTION REJECT Redirection info = inter-RAT
info = GSM
3 UE waits for wait time before
trying another RRC connection
request
Network implementation is
open, i.e. it can accept the
RRC connection or reject it.
Remarks:

1 8.1.2.12 RRC Connection Establishment: Reject with interRAT Info is set to GSM


F_6.7.15 Inter-RAT mobility / Handover to 2G during call establishment - Directed retry
Test Purpose:
To check that the network can hand over the UE to GSM during the call establishment, using the
directed retry procedure.
Pre-requisites:
Configuration: F, G (2 cells: cell 1 using GSM, cells 2-3-4 using UTRA)

The trigger to perform directed retry to 2G is up to network implementation.
Test Procedure:
A call attempt is made in 3G. UTRAN redirects the UE to GSM using the Handover from UTRAN
command message. Call establishment continues in GSM.
Test Verification:
After having being handed over to GSM, the call establishment should succeed.
Message flow:
UE NW

3 RRC CONNECTION SETUP COMPLETE
5 (AUTHENTICATION REQUEST)
6 (AUTHENTICATION RESPONSE)
9 SETUP
10 CALL PROCEEDING
11 HANDOVER FROM UTRAN COMMAND
12 The call establishment is
completed in GSM. A
handover complete is sent by
the UE on a 2G dedicated
channel.
Remarks:

1 8.3.7.4 Inter system handover from UTRAN/To


F_6.8.1 Supplementary Services


F_6.9.1 MT CS SMS in idle mode
Test Purpose:
To verify the ability of a UE to receive and decode the SMS where provided for the point to point
service.
Reference: 3GPP TS 23.040, clause 3.1.
Pre-requisites:
UE is attached for CS services
The UE/USIM has to have enough memory space for the reception of the SMS.
Test Procedure:
Initiate a MT SMS
After decoding SMS, the operator shall clear the stored SMS message manually.
Test Verification:

Verify the ability of a UE to receive and decode the SMS where provided for the point to point
service.
Check that the message , which is displayed, is exactly the same message, which was sent.
Message Flow:
UE NW
1 PAGING TYPE 1
3 RRC CONNECTION SETUP NW assigns DPCH resources to allow UE to establish
an RRC connection.
COMPLETE
5 --> PAGING RESPONSE
6 <-- AUTHENTICATION REQUEST Optional
7 --> AUTHENTICATION RESPONSE Optional
8 <-- SECURITY MODE COMMAND Optional
9 --> SECURITY MODE COMPLETE Optional
10 <-- CP-DATA Contains RP-DATA RPDU (SMS DELIVER TPDU)
11 --> CP-ACK
12 --> CP-DATA Contains RP-ACK RPDU
13 <-- CP-ACK
COMPLETE
Remarks:
None


Related protocol test cases used:



F_6.9.2 MT CS SMS during a voice call
Test Purpose:
service.
Pre-requisites:
UE is attached for CS services and is already engaged in a voice call.
Test Procedure:
Initiate a MT SMS
Test Verification:

service.
Message Flow:
UE NW
1 voice call ongoing A speech call is established on a DTCH and the state
U10 of call control is entered.
5 --> CP-ACK
8 <-- CP-ACK The UE shall indicate that a SM has arrived.
Remarks:
None


F_6.9.3 MT CS SMS during a CS data call
Test Purpose:
service.
Pre-requisites:
UE is attached for CS services and is already engaged in a MO CS data call.
Test Procedure:
Initiate a MT SMS
Test Verification:

service.
Message Flow:
UE NW
1 MO data call ongoing A MO CS data call is established on a DTCH and the
state U10 of call control is entered.
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.4 MO CS SMS
Test Purpose:
To verify that the UE is able to correctly send a short message where the SMS is provided for the
point to point service.
Pre-requisites:
Confi gurations: A, B, C, D, E, F
Test Procedure:
Initiate an MO CS SMS.
Test Verification:
Message Flow:
UE NW
2 --> RRC CONNECTION REQUEST CCCH
3 <-- RRC CONNECTION SETUP CCCH
4 --> RRC CONNECTION SETUP DCCH
COMPLETE
5 --> CM SERVICE REQUEST
7 --> AUTHENTICATION RESPONSE Optional
10 --> CP-DATA Contains RP-DATA RPDU (SMS SUBMIT TPDU)
11 <-- CP-ACK Sent within TC1M after step 10
13 NW Waits max 25 s for CP-ACK
14 --> CP-ACK
15 <-- RRC CONNECTION RELEASE RRC connection is released.
16 --> RRC CONNECTION RELEASE
COMPLETE
Remarks:
None



F_6.9.5 SMS on CS mode / Multiple SMS mobile originated / UE in idle mode
Test Purpose:
The purpose of this test is to verify the ability of sending multiple short messages on the same RRC
connection when there is no call in progress.
Reference: 3GPP TS 23.040 section 3.1 & 3GPP TS 24.011 section 5.4
Pre-requisites:
Configuration: A,B,C,D,E,F [The CN has to include an SMS Centre.]

The UE shall be in MM-state "Idle, updated".
Test Procedure:
The UE shall be set up to send 3 short messages as multiple SM to the NW.
Test Verification:
Message Flow:

UE NW
2 --> RRC CONNECTION CCCH
REQUEST
COMPLETE
7 --> AUTHENTICATION Optional
RESPONSE
9 --> SECURITY MODE Optional
COMPLETE
10 --> CP-DATA Contains RP-DATA RPDU (SMS SUBMIT TPDU).
The Transaction Identifier used in steps 10, 11, 12
and 14 shall be x.
11 <-- CP-ACK
12 <-- CP-DATA Final CP -DATA of first short message transfer
contains RP-ACK RPDU Check, if the RRC
connection has to be released or can be released.
13 --> CM SERVICE REQUEST Shall not be sent before the final CP-DATA of the
first short message transfer has been received. CM
service type set to "Short message transfer".
14 --> CP-ACK Final CP -ACK of first short message transfer shall
be sent within 5 s of step 13
15 <-- CM SERVICE ACCEPT
16 --> CP-DATA Shall not be sent before the CP -ACK of the first
short message transfer is sent (step 14). Contains
RP-DATA RPDU (SMS SUBMIT TPDU). The
Transaction Identifier used in steps 16, 17, 18 and
20 shall be y where y <> x (see step 10).
17 <-- CP-ACK



UE NW
18 <-- CP-DATA Final CP -DATA of the previous short message
transfer contains the correct RP-ACK RPDU
previous short message transfer. CM service type
set to "Short message transfer".
20 --> CP-ACK Final CP -ACK of previous short message transfer
shall be sent within 5 s of step 19
22 --> CP-DATA Shall not be sent before the CP -ACK of the
previous short message transfer (step 20).
Contains RP-DATA RPDU (SMS SUBMIT TPDU).
and 25 shall be z, where z <> y (see step 16).
23 <-- CP-ACK
24 <-- CP-DATA Contains the correct RP-ACK RPDU
25 --> CP-ACK Shall be sent within 5 s of step 24
26 <-- RRC CONNECTION RRC connection is released.
RELEASE
27 --> RRC CONNECTION
RELEASE COMPLETE
Remarks:
In step 13 the UE shall transmit a CM SERVICE REQUEST for the new CM connection (for the
second short message) before the final CP-ACK for the old MM connection is transmitted.
third short message) before the final CP-ACK for the old MM connection is transmitted.



F_6.9.6 SMS on CS mode / Multiple SMS mobile originated / UE in active mode
Test Purpose:
The purpose of this test is to verify the ability of sending concatenated multiple short messages when
there is a call in progress.
Pre-requisites:

Test Procedure:
A data or speech call is established on a DTCH with the NW and the state U10 of call control is
entered.
The UE is set up to send 3 short messages as multiple SM to the NW.
Test Verification:

Message Flow:

UE NW
1 NW A data or speech call is established on a DTCH and
the state U10 of call control is entered.
2 UE The UE is set up to send 3 short messages as
multiple SM
3 --> CM SERVICE REQUEST Sent in a layer 2 frame on the DCCH. CM service
type set to "short message transfer"
The Transaction Identifier used in steps 7, 8, 9 and
11 shall be x.
8 <-- CP-ACK
9 <-- CP-DATA Final CP -DATA of fi rst short message transfer
contains RP-ACK RPDU
first short message transfere has been received.
Sent in a layer 2 frame on the DCCH. CM service
14 <-- CP-ACK



UE NW
previous short message transfer. Sent in a layer 2
frame on the DCCH. CM service type set to "short
message transfer"
20 <-- CP-ACK
RELEASE
RELEASE COMPLETE
Remarks:



F_6.9.7 SMS on CS mode / Test of capabilities of simultaneously receiving a short message

whilst sending a mobile originated short message
Test Purpose:
The purpose of this test is to verify the capability of simultaneously receiving a network originated SM
whilst sending a mobile originated SM.
Reference: 3GPP TS 23.040 section 3.1.
Pre-requisites:

Test Procedure:
The NW is configured to receive a mobile originated SM.
The UE shall be set up to send a SM to the NW.
The NW is configured to send a SM to the UE simultaneously.
After decoding SMS, the operator shall clear the stored SMS message manually
Test Verification:

Verify that after step 12 UE correctly receive the SM and indicate that a message has arrived.
Verify that the message text displayed by the UE is the same as the text send by the network.
Message Flow:

UE NW
1 <-- SYSTEM INFORMATION BCCH
REQUEST
COMPLETE

7 --> AUTHENTICATION Optional
RESPONSE
COMPLETE
11 NW The NW sends an SM to the UE
13 UE The UE shall correctly receive the SM and indicate
that a message has arrived. In the MO case the UE
shall send the CP-ACK message with transaction
identifier assigned to this transfer. In the MT case
the UE shall send a CP-ACK message and a CP-
DATA message containing the RP-ACK RPDU. The
transaction identifier shall be the same as chosen



UE NW
by the NW for the MT transfer.
Remarks:
Time values for NW wait times are chosen sufficiently high to be sure that the UE has enough time
to respond to the different messages.



F_6.9.8 MT PS SMS
Test Purpose:
service.
Pre-requisites:
UE is attached for PS services
Test Procedure:
Initiate an MT PS SMS
Test Verification:
Message Flow:
UE NW
COMPLETE
5 --> SERVICE REQUEST
6 <-- AUTHENTICATION AND Optional
CIPHERING REQUEST
7 --> AUTHENTICATION AND Optional
CIPHERING RESPONSE
11 --> CP-ACK
13 <-- CP-ACK
COMPLETE
Remarks:
None



F_6.9.9 MT PS SMS during a PS data call
Test Purpose:
service.
Pre-requisites:
UE is attached for PS services and is already engaged in a MO PS data call
Test Procedure:
After decoding SMS, the operator shall clear the stored SMS message manually
Test Verification:
Message Flow:
UE NW
1 MO PS data call ongoing
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.10 MO PS SMS
Test Purpose:
Pre-requisites:
UE is attached for PS services
Test Procedure:
Initiate an MO PS SMS
Test Verification:
Message Flow:
UE NW
COMPLETE
CIPHERING REQUEST
CIPHERING RESPONSE
13 --> CP-ACK
14 <-- RRC CONNECTION RELEASE RRC connection is released.
15 --> RRC CONNECTION RELEASE
COMPLETE
Remarks:
None



F_6.9.11 MO PS SMS during a PS data call
Test Purpose:
Pre-requisites:
UE is attached for PS services and is already engaged in a MO PS data call.
Test Procedure:
Initiate a MO PS SMS
Test Verification:
Message Flow:
UE NW
2 UE The UE is set up to send an SM
4 <-- SERVICE ACCEPT
9 --> CP-ACK
Remarks:
None
Related protocol test cases:

1 B_12.9.1 Service Request Initiated by UE Procedure


F_6.9.12 SMS on PS mode / Test of capabilities of simultaneously receiving a short message

Test Purpose:
Pre-requisites:

The UE shall be in GMM-state "GMM-REGISTERED".
Test Procedure:

Test Verification:
Message Flow:

UE NW
REQUEST
COMPLETE
CIPHERING REQUEST
CIPHERING RESPONSE
COMPLETE


Remarks:
Time values for NW wait times are chosen sufficiently high to be sure that the UE has enough time
to respond to the different messages.



F_6.9.13 MT PS SMS during a voice call
Test Purpose:
service.
Pre-requisites:
UE is attached for CS and PS services and is already engaged in a MO CS call
Test Procedure:
Initiate a MT PS SMS
Test Verification:
Message Flow:
UE NW
1 MO CS call ongoing
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.14 MT CS SMS during a PS data call
Test Purpose:
service.
Pre-requisites:
UE is attached for CS and PS services and is already engaged in a MO PS data call
Test Procedure:
Initiate an MT CS SMS
Test Verification:
Message Flow:
UE NW
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.15 MT PS SMS during a CS data call
Test Purpose:
service.
Pre-requisites:
UE is attached for PS services and is already engaged in a MO CS data call
Test Procedure:
Test Verification:
Message Flow:
UE NW
1 MO CS data call ongoing
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.16 MO CS SMS during a PS data call
Test Purpose:
service.
Pre-requisites:
UE is attached for CS and PS services and is already engaged in a MO PS data call.
Test Procedure:
Initiate an MO CS SMS
Test Verification:
Message Flow:
UE NW
1 PS data call ongoing
3 --> CP-ACK
5 <-- CP-ACK
Remarks:
None


F_6.9.17 Short message service cell broadcast
Test Purpose:
The purpose of this test is to verify the transmission of SMS-CB messages.

Reference: 3GPP TS 23.041 section 8 & 3GPP TS 25.324 section 11.
Pre-requisites:
Periodic location updating is disabled.
The UE shall be in the idle updated state.
The UE supports the short message transmission cell broadcast.
Test Procedure:
Three Cell Broadcast (CB) messages are sent by the NW on the CBCH with message codes 0,1,1
in serial number fields respectively.
Test Verification:
Verify that the UE received the messages.
In consequence of test the UE shall ignore the third message and store two messages.
Message Flow:

UE NW
1 <-- BMC CBS Message with message code 0
.. .. ..
Remarks:
The SMS-CB messages (BMC) are sent continuously.


F_6.10.1.1 UE positioning / UE based A-GPS / Mobile Terminated Location Request (MT-LR) in

idle mode
Test Purpose:
To check that when UE is in idle mode and its position is requested by an LCS client, the network is
able to select a UE positioning method and request the UEs position, which will return it with the help
of the GPS Assistance Data provided by the network.
Pre-requisites:
Configuration: A, B, C, D, E, with Iupc and SAS

UE supports UE-based A-GPS positioning method.
UE is in idle mode
Test Procedure:
UE position is requested by an LCS client outside the network. UE shall be paged. RRC connection is
established and authentication is performed (optional). LCS Location Notification may occur
depending on the UE subscription and the type of LCS client. Depending on the UE capabilities, the
SRNC selects the UE positioning method (UE based A-GPS) and sends to the UE certain GPS
assistance information using the RRC measurement control message. Note that in order to optimize
radio resources and not block other radio procedures (such as active set updates), the assistance
data may be sent in several measurement control messages. Also note that the network may also
broadcast the assistance data to UEs, through SIB#15. The SRNC will request that the UE report its
position in the last measurement control message. The assistance data that may be transferred to
the UE is specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the position estimate to the
SRNC. This estimate includes the position, the estimated accuracy of the results and the time of the
estimate. UTRAN will forward the position estimate to the core network.
Test Verification:
Verify that the UE includes the A-GPS positioning capability in the RRC connection setup complete
message.
Verify that the RNC selects a positioning method coherent with the UE positioning capabilities
Verify that the RNC sends the GPS assistance data (including all mandatory information) to the UE
using the RRC measurement control message and/or SIB#15
Verify that the UE returns its position, using the position choice (e.g. Ellipsoid point, Ellipsoid point with
uncertainty circle, etc.) requested by the SRNC.
Verify that the RNC does shape conversion (if necessary) and forwards the UE position to the CN.
Message flow:
UE NW
1 PAGING TYPE 1
4 RRC CONNECTION SETUP COMPLETE Support of A-GPS UE-based
is included
5 PAGING RESPONSE
6 AUTHENTICATION REQUEST*
7 AUTHENTICATION RESPONSE*



10 REGISTER** LCS Location notification
Invoke
11 RELEASE COMPLETE** LCS Location notification
return result
12 MEASUREMENT CONTROL Delivery of GPS assistance
data
12a MEASUREMENT CONTROL Included if network decides to
segment the assistance data
into several messages
12b MEASUREMENT CONTROL Last measurement control
message includes the request
for the UE position. The total
number of
MEASUREMENT_CONTROL
messages could be less or
equal to 4
13 MEASUREMENT REPORT Includes UE position
15 RRC CONNECTION RELEASE COMPLETE
* optional
** These messages are optional and depend on the LCS client type and user subscription. See details
in 3GPP TS23.171 The message content is defined in 3GPP TS24.080.
Remarks:
At step 4, check that the UE includes its UE positioning capabilities
In step 11, if privacy verification was requested, the tester shall allow the location request to go
through
At step 13, check that the UE includes the position (using the position method requested by the RNC),
the estimated accuracy of the results and the time of the estimate

4 B_x.x.x Security Mode procedure
B_8.1.3.2
Successful
Note that there is no test case for GPS position reporting in 34.123-1.


F_6.10.1.2 UE positioning / UE based A-GPS / Mobile Terminated Location Request (MT-LR) in

cell_DCH
Test Purpose:
To check that when UE is in RRC cell_DCH state and its position is requested by an LCS client, the
network is able to select a UE positioning method and request the UEs position, which will return it
with the help of the GPS Assistance Data provided by the network.
Pre-requisites:

UE is in RRC cell_DCH state
Test Procedure:
UE position is requested by an LCS client outside the network. LCS Location Notification may occur
SRNC selects the UE positioning method (UE based A-GPS). If the UE had a PS connection, the
network will page it first, and the UE will return PAGING RESPONSE message. The SRNC will send
to the UE certain GPS assistance information using the RRC measurement control message. Note
that in order to optimize radio resources and not block other radio procedures (such as active set
updates), the assistance data may be sent in several measurement control messages. Also note that
the network may also broadcast the assistance data to UEs, through SIB#15. The SRNC will request
that the UE report its position in the last measurement control message. The assistance data that
may be transferred to the UE is specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the
position estimate to the SRNC. This estimate includes the position, the estimated accuracy of the
results and the time of the estimate. UTRAN will forward the position estimate to the core network.
Test Verification:
message.
Message flow:
UE NW
0a PAGING TYPE 2* See note below

0b PAGING RESPONSE* See note below
0c AUTHENTICATION REQUEST* See note below. Optional
0d AUTHENTICATION RESPONSE* See note below. Optional
0e SECURITY MODE COMMAND* See note below
0f SECURITY MODE COMPLETE* See note below
Invoke
return result


data
number of
MEASUREMENT_CONTROL
equal to 4
* These messages are only sent if the UE had a PS connection at the beginning of the test.
Remarks:
In step 2, if privacy verification was requested, the tester shall allow the location request to go through

1 B_8.1.1.7 RRC / Paging for Connection in connected mode (cell_DCH)


F_6.10.1.3 UE positioning / UE-based A-GPS / Mobile Terminated Location Request (MT-LR)

using location notification (LR goes through after no response from user)
Test Purpose:
To check that when the user does not respond to a privacy verification request when receiving a LCS
location notification invoke message, the network is able to allow or disallow the location request
based on user subscription.
Pre-requisites:

UE is in idle mode
UE subscription profile is set so that the location request is accepted in the absence of a response
from the user to a privacy verification request
Test Procedure:
established and authentication is performed (optional). LCS Location Notification is performed
indicating the type of location request (e.g. current location) and the identity of the LCS client, with a
privacy verification request. The tester shall not give an answer to the privacy verification request.
When the timer in the network expires, the network shall consider that there is no answer from the
user, and thus the location request shall go through.
The SRNC selects the UE positioning method (UE based A-GPS) and sends to the UE certain GPS
broadcast the assistance data to UEs, through SIB#15. The SRNC will request that the UE report its
position in the last measurement control message. The assistance data that may be transferred to
the UE is specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the position estimate to the
SRNC. This estimate includes the position, the estimated accuracy of the results and the time of the
estimate. UTRAN will forward the position estimate to the core network. RRC connection is released.
Test Verification:
message.
Verify that when no answer is given to the privacy verification, the positioning request still goes
through


Message flow:
UE NW
1 PAGING TYPE 1
is included
5 PAGING RESPONSE
6 AUTHENTICATION REQUEST* Optional
7 AUTHENTICATION RESPONSE* Optional
10 REGISTER LCS Location notification
Invoke, with privacy
permission request
11 The user shall not answer for
a pre-determined time set by
the network
data
number of
MEASUREMENT_CONTROL
equal to 4
* Optional
Remarks:
At step 11, the tester shall not answer to the privacy verification request. According to the UE
subscription, the location request shall go through

B_8.1.3.2
Successful


F_6.10.1.4 UE positioning / UE based A-GPS / Network Induced Location Request (NI-LR) /

Emergency Call
Test Purpose:
To check that when UE initiates an emergency call, the network is able to select a UE positioning
method and request the UEs position, which will return it with the help of the GPS Assistance Data
provided by the network.
Pre-requisites:
UE is switched on
Test Procedure:
Emergency call is established. The RNC will trigger the A-GPS procedure based on the Location
Request from the MSC during the setup or the call. Depending on the UE capabilities, the SRNC
selects the UE positioning method (UE based A-GPS) and sends to the UE certain GPS assistance
information using the RRC measurement control message. Note that in order to optimize radio
resources and not block other radio procedures (such as active set updates), the assistance data may
be sent in several measurement control messages. Also note that the network may also broadcast
the assistance data to UEs, through SIB#15. The SRNC will request that the UE report its position in
the last measurement control message. The assistance data that may be transferred to the UE is
specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the position estimate to the SRNC.
This estimate includes the position, the estimated accuracy of the results and the time of the estimate.
UTRAN will forward the position estimate to the core network.
Test Verification:
message.
using the RRC measurement control message
Message flow:
UE NW
Emergency call setup from F_6.2.1 is used

data
for the UE position, the
number of messages can vary
* Optional


Remarks:


F_6.10.1.5 UE positioning / UE based A-GPS / GPS assistance data not sufficient
Test Purpose:
To check that when the UE requests more assistance data from the RNC because it doesnt have the
appropriate GPS assistance data to calculate its position, the network returns the requested data and
the UE sends its position to the RNC.
Pre-requisites:

UE assistance data (e.g. reference time) storage shall be empty
UE position storage shall be empty
UE is in idle mode
Test Procedure:
depending on the UE subscription. Depending on the UE capabilities, the SRNC selects the UE
positioning method (UE based A-GPS) and sends to the UE certain GPS assistance information using
the RRC measurement control message. Note that in order to optimize radio resources and not block
other radio procedures (such as active set updates), the assistance data may be sent in several
measurement control messages. Also note that the network may also broadcast the assistance data
to UEs, through SIB#15. In order to perform this test, not all assistance data is sent to the UE. It is
recommended that no assistance data be sent to the UE. The SRNC will request that the UE report its
position in the last measurement control message. UE will request more assistance data from the
RNC in a MEASUREMENT REPORT, because it doesnt have enough to calculate its position. The
SRNC will return the requested assistance data in a MEASUREMENT CONTROL, and requests the
UE position. The UE then returns the position estimate to the SRNC. This estimate includes the
position, the estimated accuracy of the results and the time of the estimate. UTRAN will forward the
position estimate to the core network.
Test Verification:
message.
Verify that the UE is able to request more assistance data from the network using the measurement
control message, when it doesnt have enough data to perform a position fix.
Verify that after being requested to send more assistance data, the RNC is able to deliver the specific
GPS assistance data (including all mandatory information) requested by the UE using the RRC
measurement control message


Message flow:
UE NW
1 PAGING TYPE 1
is included
5 PAGING RESPONSE
8 SECURITY_MODE_COMMAND
9 SECURITY_MODE_COMPLETE
9a REGISTER** LCS Location notification
Invoke
9b RELEASE COMPLETE** LCS Location notification
return result
10 MEASUREMENT CONTROL Delivery of limited GPS
assistance data
for the UE position
11 MEASUREMENT REPORT UE cannot fulfil the request.
Measurement report is sent for
additional assistance data.
12 MEASUREMENT CONTROL The SRNC sends more
assistance data based on UE
request
Remarks:
At step 11 check that the UE requests new assistance data to the NW.
At step 13, check that the UE includes the position (using the position method requested by the RNC)

B_8.1.3.2
Successful


F_6.10.1.6 UE positioning / UE based A-GPS / Mobile Origination Location Request (MO-LR) in

idle mode
Test Purpose:
To check that when a UE is in idle mode and an LCS client embedded in or associated with it requests
its location, the network is able to return an estimate of its position to the UE.
Note: according to 3GPP TS 23.171, the UE can use the MO-LR procedure to request either its own
location, location assistance data or broadcast assistance data message ciphering keys from the
network. However, TS 24.030 v330 clause 5.1 states: In UMTS, the gpsAssistanceData and
deCipheringKeys shall not be used as values of molr-Type parameter. Note that this is only true in
R99.
Thus, only a request for its own location can be done by a R99 UMTS terminal. So, for this specific
test case, the UE will calculate its own position (as decided by the RNC), return it to the UTRAN,
which will forward it to the core network, and return it to the UE.
Pre-requisites:

UE is in idle mode
LCS client is embedded in or associated to the UE
Test Procedure:
UE position is requested by an LCS client embedded in or associated with the UE. An RRC
connection request is triggered. After completion of the RRC connection, UE sends CM service
request indicating a request for a call independent supplementary services to the 3G-VMSC via the
SRNC.
Authentication is performed (optional). The UE sends a LCS MO-LR Location Services invoke (in a
REGISTER message) to the 3G-VMSC, in order to request a location estimate. The 3G-VMSC verifies
in the UE's subscription profile that the UE has permission to request its own location. Depending on
the UE capabilities, the SRNC selects the UE positioning method (UE based A-GPS) and sends to the
UE certain GPS assistance information using the RRC measurement control message. Note that in
order to optimize radio resources and not block other radio procedures (such as active set updates),
the assistance data may be sent in several measurement control messages. Also note that the
network may also broadcast the assistance data to UEs, through SIB#15. The SRNC will request that
the UE report its position in the last measurement control message. The assistance data that may be
transferred to the UE is specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the position
estimate to the SRNC. This estimate includes the position, the estimated accuracy of the results and
the time of the estimate. UTRAN will forward the position estimate to the core network.
The 3G-VMSC returns an LCS MO-LR Return Result to the UE (using a FACILITY message), carrying
the location estimate requested by the UE.
Test Verification:
message.
Verify that the RNC sends GPS assistance data (including all mandatory information) to the UE using
the RRC measurement control message. The assistance data included in the Location Services
Invoke message shall be included by the RNC.


Message flow:
UE NW

is included
9 REGISTER See TS24.030. This message
carries LCS requested QoS
information (e.g. accuracy,
response time)
data
11 MEASUREMENT CONTROL Included if network decides to
12 MEASUREMENT REPORT Includes position estimate
13 FACILITY See TS24.030. Includes
position estimates
14 RELEASE COMPLET See TS24.030
* optional
Remarks:
At step 13, check that the network returns the UE position to the UE.

5a B_8.1.3.1 RRC / RRC Connection Release in CE LL_DCH state: Successful
B_8.1.3.2
Successful


F_6.10.1.7 UE positioning / UE based A-GPS / Mobile Origination Location Request (MO-LR) in

cell_DCH
Test Purpose:
To check that when a UE is in cell_DCH and an LCS client embedded in or associated with it requests
deCipheringKeys shall not be used as values of molr-Type parameter. Note that this is only true for
R99.
Thus, only a request for its own location can be done by a R99 UMTS terminal.
Pre-requisites:

UE is in cell_DCH
Test Procedure:
UE position is requested by an LCS client embedded in or associated with the UE. UE sends CM
service request indicating a request for a call independent supplementary services to the 3G-VMSC
via the SRNC.
the UE capabilities, the SRNC selects the UE positioning method (UE based A-GPS) and sends to the
UE certain GPS assistance information using the RRC measurement control message. Note that in
order to optimize radio resources and not block other radio procedures (such as active set updates),
network may also broadcast the assistance data to UEs, through SIB#15. The SRNC will request that
the UE report its position in the last measurement control message. The assistance data that may be
transferred to the UE is specified in 3GPP TS25.305, clause 10.5.1. The UE then returns the position
estimate to the SRNC. This estimate includes the position, the estimated accuracy of the results and
the time of the estimate. UTRAN will forward the position estimate to the core network.
Test Verification:
the RRC measurement control message. The assistance data included in the Location Services
Invoke message shall be included by the RNC.


Message flow:
UE NW
1 CM SERVICE REQUEST** Sent on the already

established RRC connection
2a AUTHENTICATION REQUEST** See note below. Optional
2b AUTHENTICATION RESPONSE** See note below. Optional
2c SECURITY MODE COMMAND** See note below
2d SECURITY MODE COMPLETE** See note below
response time)
data
6 MEASUREMENT REPORT Includes position estimate
position estimates
8 RELEASE COMPLETE See TS24.030
* optional
** These messages are only included if the UE had a PS connection before the beginning of the test.
Remarks:
Covered prot ocol tests:



F_6.10.2.1 UE positioning / UE assisted A-GPS / Mobile Terminated Location Request (MT-LR)

in idle mode
Test Purpose:
To check that when UE is in idle mode and its position is requested by an LCS client, the network is
able to calculate a UEs position, based on measurements made by the UE with the help of GPS
Assistance Data (provided by the network).
Pre-requisites:

UE supports UE-assisted A-GPS positioning method.
UE is in idle mode
Network is equipped with some reference GPS receiver that can simultaneously see the same
satellites as the terminal.
Test Procedure:
established and authentication is performed (optional). LCS Location Notification may occur
SRNC selects the UE positioning method (UE assited A-GPS) and sends to the UE certain GPS
broadcast the assistance data to UEs, through SIB#15. The network may optionally request some
information from the nodeB (LMU update and RTT measurements) to compensate for the one-way
propagation delays. The SRNC requests from the UE the measurement of GPS satellite
pseudoranges and other information specified in 25.305 clause 10.5.1. The SRNC may request SFN-
SFN Observed Time Difference measurements and Rx-Tx timing difference information from the UE to
support the processing related to the RTT measurements.
The UE then returns the requested information to the SRNC. The UE position is calculated in the
SRNC. UTRAN will forward the position estimate to the core network. Note that if there is insufficient
information to yield a UE positioning estimate, the SRNC may start a new process.
Test Verification:
message.
the RRC measurement control message
Verify that the UE returns the information requested by the SRNC.
Verify that the RNC is able to calculate the UE position and forward it to the CN.
Message flow:



UE NW
1 PAGING TYPE 1
4 RRC CONNECTION SETUP COMPLETE Support of A-GPS UE-
Assisted is included
5 PAGING RESPONSE
Invoke
return result
data
to return specific information
(see test procedure)
13 MEASUREMENT REPORT Includes information requested
by the SRNC.
14 SRNC calculates the UE position
* optional
Remarks:
At step 4, check that the UE includes its UE positioning capabilities
In step 11, if privacy verification was requested, the tester shall allow the location request to go
through
At step 13, check that the UE includes the information requested by the SRNC

B_8.1.3.2
Successful


F_6.10.2.2 UE positioning / UE assisted A-GPS / Mobile Terminated Location Request (MT-LR)

in cell_DCH
Test Purpose:
To check that when UE is in cell_DCH and its position is requested by an LCS client, the network is
able to calculate a UEs position, based on measurements made by the UE with the help of GPS
Assistance Data (provided by the network).
Pre-requisites:

UE is in cell_DCH
Network is equipped with some reference GPS receiver that can simultaneously see the same
satellites as the terminal.
Test Procedure:
UE position is requested by an LCS client outside the network. If a CS connection isnt already
established, the UE shall be paged, and it responds with a PAGING RESPONSE to the network. LCS
Location Notification may occur depending on the UE subscription and the type of LCS client.
Depending on the UE capabilities, the SRNC selects the UE positioning method (UE assited A-GPS)
and sends to the UE certain GPS assistance information using the RRC measurement control
message. Note that in order to optimize radio resources and not block other radio procedures (such as
active set updates), the assistance data may be sent in several measurement control messages.
Also note that the network may also broadcast the assistance data to UEs, through SIB#15. The
network may optionally request some information from the nodeB (LMU update and RTT
measurements) to compensate for the one-way propagation delays. The SRNC requests from the UE
the measurement of GPS satellite pseudoranges and other information specified in 25.305 clause
10.5.1. The SRNC may request SFN-SFN Observed Time Difference measurements and Rx-Tx timing
difference information from the UE to support the processing related to the RTT measurements.
Test Verification:
message.


Message flow:
UE NW
1 PAGING TYPE 2* See note below.

2 PAGING RESPONSE* See note below.
3 AUTHENTICATION REQUEST* See note below. Optional.
4 AUTHENTICATION RESPONSE* See note below. Optional.
5 SECURITY MODE COMMAND* See note below
6 SECURITY MODE COMPLETE* See note below
Invoke
return result
data
by the SRNC.
11 SRNC calculates the UE position and
returns it to the core network.
* These messages are only sent if the UE had a PS connection at the beginning of the test.
Remarks:
In step 8, if privacy verification was requested, the tester shall allow the location request to go through

1 B_8.1.1.7 RRC / Paging for Connection in connected mode (cell_DCH)


F_6.10.2.3 UE positioning / UE-assisted A-GPS / Mobile Terminated Location Request (MT-LR)

using location notification (LR goes through after no response from user)
Test Purpose:
Pre-requisites:

UE is in idle mode
UE subscription profile is set so that the location request is accepted in the absence of a response
from the user to a privacy verification request
Test Procedure:
user, and thus the location request shall go through.
the SRNC selects the UE positioning method (UE assisted A-GPS) and sends to the UE certain GPS
broadcast the assistance data to UEs, through SIB#15. The network may optionally request some
information from the nodeB (LMU update and RTT measurements) to compensate for the one-way
propagation delays. The SRNC requests from the UE the measurement of GPS satellite
pseudoranges and other information specified in 25.305 clause 10.5.1. The SRNC may request SFN-
SFN Observed Time Difference measurements and Rx-Tx timing difference information from the UE to
support the processing related to the RTT measurements.
Test Verification:
message.
Verify that when no answer is given to the privacy verification, the positioning request still goes
through


Message flow:
UE NW
1 PAGING TYPE 1
4 RRC CONNECTION SETUP COMPLETE Support of A-GPS UE-assisted
is included
5 PAGING RESPONSE
Invoke, with privacy
permission request
the network
data
by the SRNC.
* Optional
Remarks:
subscription, the location request shall go through

B_8.1.3.2
Successful


F_6.10.2.4 UE positioning / UE Assisted A-GPS / Network Induced Location Request (NI-LR) /

Emergency Call
Test Purpose:
To check that when UE initiates an emergency call, the network is able to select a UE positioning
method and calculate the UEs position, with the help of GPS measurements made by the UE.
Pre-requisites:
UE is switched on and in idle mode.
Test Procedure:
Emergency call is established. The RNC will trigger the A-GPS procedure based on the Location
Request from the MSC during the setup or the call. Depending on the UE capabilities, the SRNC
selects the UE positioning method (UE assisted A-GPS) and sends to the UE certain GPS assistance
information using the RRC measurement control message. Note that in order to optimize radio
resources and not block other radio procedures (such as active set updates), the assistance data may
be sent in several measurement control messages. Also note that the network may also broadcast
the assistance data to UEs, through SIB#15. The SRNC requests from the UE the measurement of
GPS satellite pseudoranges and other information specified in 25.305 clause 10.5.1. The SRNC may
request SFN-SFN Observed Time Difference measurements and Rx -Tx timing difference information
from the UE to support the processing related to the RTT measurements.
Test Verification:
message.
Message flow:
UE NW
Emergency call setup from F_6.2.1 is used

data
by the SRNC
3 SRNC calculates the UE position and


Remarks:
At step 2, check that the UE includes the information requested by the SRNC.
After step 3, check over the Iu interface that the RNC has correctly calculated the UE position.


F_6.10.2.5 UE positioning / UE Assisted A-GPS / GPS assistance data not sufficient
Test Purpose:
To check that when the UE requests more assistance data from the RNC because it doesnt have the
appropriate GPS assistance data to calculate its position, the network returns the requested data and
the UE sends its position to the RNC.
Pre-requisites:

UE assistance data (e.g. reference time) storage shall be empty
UE position storage shall be empty
UE is in idle mode
Test Procedure:
depending on the UE subscription. Depending on the UE capabilities, the SRNC selects the UE
positioning method (UE assisted A-GPS) and sends to the UE certain GPS assistance information
using the RRC measurement control message. Note that in order to optimize radio resources and
not block other radio procedures (such as active set updates), the assistance data may be sent in
several measurement control messages. Also note that the network may also broadcast the
assistance data to UEs, through SIB#15. In order to perform this test, not all assistance data is sent to
the UE. It is recommended that no assistance data be sent to the UE. The SRNC will request that the
UE report some GPS measurements in a measurement control message. UE will request more
assistance data from the RNC in a MEASUREMENT REPORT, because it doesnt have enough to
perform the measurements. The SRNC will return the requested assistance data in a
MEASUREMENT CONTROL, and request again the GPS measurements. The UE then sends the
requested measurements to the SRNC. The SRNC then calculates the UE position and forwards the
position estimate to the core network.
Test Verification:
message.
Verify that the UE is able to request more assistance data from the network using the measurement
control message, when it doesnt have enough data to perform the requested A-GPS measurements
Verify that after being requested to send more assistance data, the RNC is able to deliver the specific
GPS assistance data (including all mandatory information) requested by the UE using the RRC
measurement control message


Message flow:
UE NW
1 PAGING TYPE 1
is included
5 PAGING RESPONSE
8 SECURITY_MODE_COMMAND
9 SECURITY_MODE_COMPLETE
9a REGISTER** LCS Location notification
Invoke
9b RELEASE COMPLETE** LCS Location notification
return result
10 MEASUREMENT CONTROL Delivery of limited GPS
assistance data
for GPS measurements
11 MEASUREMENT REPORT UE cannot fulfil the request.
Measurement report is sent for
additional assistance data.
12 MEASUREMENT CONTROL The SRNC sends more
assistance data based on UE
request
13 MEASUREMENT REPORT Includes requested
measurements
SRNC calculates the UE position and
Remarks:
At step 11, check that the UE requests new assistance data to the NW.
After step 13, check over the Iu interface that the RNC has correctly calculated the UE position.

B_8.1.3.2
Successful


F_6.10.2.6 UE positioning / UE Assisted A-GPS / Mobile Origination Location Request (MO-LR)

in idle mode
Test Purpose:
To check that when a UE is in idle mode and an LCS client embedded in or associated with it requests
deCipheringKeys shall not be used as values of molr-Type parameter. Note that this is only true in
R99.
Pre-requisites:

UE is in idle mode
Test Procedure:
UE position is requested by an LCS client embedded in or associated with the UE. An RRC
connection request is triggered. After completion of the RRC connection, UE sends CM service
request indicating a request for a call independent supplementary services to the 3G-VMSC via the
SRNC.
the UE capabilities, the SRNC selects the UE positioning method (UE assisted A-GPS) and sends to
the UE certain GPS assistance information using the RRC measurement control message. Note that
in order to optimize radio resources and not block other radio procedures (such as active set updates),
network may also broadcast the assistance data to UEs, through SIB#15. The SRNC requests from
the UE the measurement of GPS satellite pseudoranges and other information specified in 25.305
clause 10.5.1. The SRNC may request SFN-SFN Observed Time Difference measurements and Rx-
Tx timing difference information from the UE to support the processing related to the RTT
measurements.
Test Verification:
message.
the RRC measurement control message.
Verify that the UE returns the GPS measurements requested by the SRNC.


Verify that the CN returns the UE position to the UE.
Message flow:
UE NW

is included
response time)
data
12 MEASUREMENT REPORT Includes GPS measurments
position estimates
* optional
Remarks:
At step 12, check that the UE includes the requested GPS measurements

B_8.1.3.2
Successful


F_6.10.2.7 UE positioning / UE assisted A-GPS / Mobile Origination Location Request (MO-LR)

in cell_DCH
Test Purpose:
To check that when a UE is in cell_DCH and an LCS client embedded in or associated with it requests
deCipheringKeys shall not be used as values of molr-Type parameter. Note that this is only true for
R99.
Pre-requisites:

UE is in cell_DCH
Test Procedure:
UE position is requested by an LCS client embedded in or associated with the UE. UE sends CM
servi ce request indicating a request for a call independent supplementary services to the 3G-VMSC
via the SRNC.
the UE capabilities, the SRNC selects the UE positioning method (UE assisted A-GPS) and sends to
the UE certain GPS assistance information using the RRC measurement control message. Note that
in order to optimize radio resources and not block other radio procedures (such as active set updates),
network may also broadcast the assistance data to UEs, through SIB#15. The SRNC requests from
the UE the measurement of GPS satellite pseudoranges and other information specified in 25.305
clause 10.5.1. The SRNC may request SFN-SFN Observed Time Difference measurements and Rx-
Tx timing difference information from the UE to support the processing related to the RTT
measurements.
Test Verification:
the RRC measurement control message.
Verify that the UE returns the GPS measurements requested by the SRNC.
Verify that the RNC calculates the UE position and forwards it to the CN.
Verify that the CN returns the UE position to the UE.


Message flow:
UE NW
1 CM SERVICE REQUEST** Sent on the already

established RRC connection
2a AUTHENTICATION REQUEST** See note below. Optional
2b AUTHENTICATION RESPONSE** See note below. Optional
2c SECURITY MODE COMMAND** See note below
2d SECURITY MODE COMPLETE** See note below
response time)
data
6 MEASUREMENT REPORT Includes GPS measurements
position estimates
* optional
** These messages are only included if the UE had a PS connection before the beginning of the test.
Remarks:
At step 6, check that the UE includes GPS measurements requested by the RNC



F_6.10.3.1 UE positioning / General / Mobile Terminated Location Request (MT-LR) using

location notification (permission is denied)
Test Purpose:
To check that when the user denies the permission to be localized by a value-added LCS client when
receiving a LCS location notification invoke message, with a privacy verification request, the location
request does not go through.
Pre-requisites:

UE supports UE-based or UE -assisted (or both) A-GPS positioning method
UE is in idle mode
User subscription is configured, so that the privacy verification request can be denied.
Test Procedure:
privacy verification request. The tester shall deny the privacy verification request, so that the location
request from the LCS client doesnt go through. The SRNC releases the RRC connection.
Test Verification:
Verify that when the user denies permission for positioning, the location request doesnt go through,
and the RRC connection is released.
Message flow:
UE NW
1 PAGING TYPE 1
or UE-assisted or both is
included
5 PAGING RESPONSE
Invoke with privacy verification
11 RELEASE COMPLETE LCS Location notification
return result permission is
denied
* Optional


Remarks:
In step 10, privacy verification is requested

In step 11, the UE shall notify the user/tester of the location request, and indicate to the UE user
whether the location request will be allowed or not allowed in the absence of a response. Tester shall
deny permission.

B_8.1.3.2
Successful


F_6.10.3.2 UE positioning / General / Mobile Terminated Location Request (MT-LR) using

location notification (no response from user)
Test Purpose:
Pre-requisites:

UE supports UE-based or UE -assisted (or both) A-GPS positioning method.
UE is in idle mode
Configure the UE subscription profile so that the location request is rejected in the absence of a
response from the user to a privacy verification request.
Test Procedure:
user, and thus the location request is rejected.
Test Verification:
Verify that when no answer is given to the privacy verification, the positioning request doesnt go
through.
Message flow:
UE NW
1 PAGING TYPE 1
or UE-assisted (or both) is
included
5 PAGING RESPONSE
Invoke with privacy verification
the network
* Optional


Remarks:
subscription, the location request doesnt go through.

B_8.1.3.2
Successful


F_6.11.1 CS - Ciphering of SRB at Location update
Test Purpose:
To check that ciphering can be activated with the security mode command procedure, with new (AKA
performed) or old (AKA not performed) CS keys, and that ciphering is properly applied on SRBs.
Pre-requisites:
Configuration: A, B, C, D or E
UE is powered OFF
Terminal and infrastructure vendors should ensure that they are aligned in terms of support of 3GPP
CRs impacting ciphering
Test Procedure:
UE is powered ON, and a location update is initiated. If an AKA procedure was performed, a new
CK CS is generated, and activated at security mode command. HFNs of all SRBs should be initialized at
0.
When the LAU procedure is completed, power OFF the UE.
UE is powered back ON, and a LAU is initiated. This time the Start CS in the RRC connection setup
complete message should be different than 0.
Note: 2 Location updates are performed just to make sure that the case with Start CS different than zero
tested
Test Verification:
If AKA is used, verify that the new ciphering key is activated at security mode command.
Verify that for both procedures the UE includes the STARTCS in the initial direct transfer message
(LAU request), as per 3GPP CR1282.
Verify that the Security Mode Command carries DL Ciphering Activation Time
Verify that the Security Mode Complete carries UL Ciphering Activation Time
Verify that after Security mode complete, after the expiration of the ciphering activation time, all
messages are ciphered with the proper key.
Verify that both the UE and the network are able to decipher the messages.
Message flow:

UE NW
1 UE is powered ON


2 RRC CONNECTION REQUEST Registration

4 RRC CONNECTION SETUP Includes STARTCS and
COMPLETE STARTPS
5 LOCATION AREA UPDATE REQUEST Includes STARTCS
7 AUTHENTICATION RESPONSE *
8 SECURITY MODE COMMAND Includes DL Ciphering
Activation Time
9 SECURITY MODE COMPLETE Includes UL Ciphering
Activation Time
10 LOCATION AREA UPDATE
COMPLETE
11 TMSI REALLOCATION COMPLETE**
COMPLETE
14-26 UE is powered OFF and
then ON again and the
procedure is repeated
* optional
** depends on the allocation of a new TMSI by the core CS
Remarks:

1 PLMN selection of RPLMN, HPLMN, UPLMN and OPLMN; Manual
B_6.1.1.1
mode
5 Not mapped Security Mode Command
B_8.1.3.2
Successful
8 B_9.1 TMSI Reallocation


F_6.11.2 CS - Ciphering at CS voice call setup
Test Purpose:
To check that after ciphering has been activated for the SRBs, ciphering can be activated for the traffic
channel with the radio bearer setup procedure.
Pre-requisites:
UE is powered ON and has performed CS registration
Measurements are set up by the network.
Test Procedure:
Perform an outgoing MO CS speech call.
After the call is set up, radio conditions should be changed to trigger an active set update procedure.
If SMS is supported over CS, an SMS is sent to the UE. Otherwise, DTMF tones can be used to verify
ciphering on SRB#3 or 4.
The call is released.
Test Verification:
- Verify that the RB setup complete message contains the ciphering (COUNT-C) activation time (Same
for UL and DL for RLC TM) and Start CS (as per 3GPP CR 1466 June 02).
- Verify that at RB activation time, DTCHs become active and is ciphered (HFNs are initialized with the
START value sent in the IDT, and are frozen).
- Verify that at COUNT-C activation time, DTCHs are still ciphered (HFNs are initialized with the
START value sent in the RB setup complete, and are normally incremented)
- Verify that all Measurement reports sent on UL SRB#1 after Ciphering Activation time are being
ciphered, and can be de-ciphered properly by the network. If possible wait more than 128
Measurement Reports so that RLC HFN for RLC UM uplink is incremented.
- Verify that the active set update (UL) and Active set update complete (DL) sent on SRB#2 are
properly ciphered and deciphered
- Verify that RLC ACKs in UL and DL are not ciphered
- Verify, if applicable, that the SMS messaging sent on SRB#3 or SRB#4 is properly ciphered and
deciphered
in UL and DL
- Verify that the RRC connection release message sent on DL SRB#1 is properly ciphered and
deciphered
Message flow:



UE NW

COMPLETE STARTPS
4 CM SERVICE REQUEST Includes STARTCS
Activation Time
Activation Time
9 SETUP (CC)
11 RADIO BEARER SETUP Includes RB Activation time
12 RADIO BEARER SETUP COMPLETE Includes ciphering
activation time and
STARTCS
13 ALERTING (CC)
14 CONNECT
15 CONNECT ACKNOWLEDGEMENT (CC)
16 MEASUREMENT REPORT Decision to perform an
active set update
17 ACTIVE SET UPDATE
18 ACTIVE SET UPDATE COMPLETE
19 CP-DATA**
20 CP-ACK**
21 CP-DATA**
22 CP-ACK**
23 DISCONNECT (CC)
24 RELEASE (CC)
* optional
** in case SMS is supported over CS
Note: the network may send measurement control messages during the call setup to activate
measurements
Remarks:



3 Not mapped Security Mode Command (TC8.1.7 in 34.123-1)

Success
10 B_16.1.1 SMS on CS mode / SMS mobile terminated

15 B_8.1.3.2 RRC / RRC Connection Release using on DCCH in CELL_FACH state:
Successful


F_6.11.3 PS - Ciphering of SRB at Routing area update
Test Purpose:
To check that ciphering can be activated with the security mode command procedure, with new (AKA
performed) or old (AKA not performed) PS keys, and that ciphering is properly applied on SRBs.
Pre-requisites:
UE is powered ON and has performed CS registration
Test Procedure:
PS attach procedure is initiated (auto or manual). If an AKA procedure was performed, a new CK PS is
generated, and activated at security mode command. HFNs of all SRBs should be initialized at 0.
When the attach procedure is completed, power OFF the UE.
UE is powered back ON, and a LAU/registration is initiated. The PS attach procedure is then initiated.
This time the Start PS in the RRC connection setup complete message should be different than 0.
Note: 2 PS attaches are performed just to make sure that the case with Start PS different than zero
tested
Test Verification:
If AKA is used, verify that the new ciphering key is activated at security mode command.
Verify that for both procedures the UE includes the STARTPS in the initial direct transfer message
(Attach request), as per 3GPP CR1282.
Verify that the Security Mode Command carries DL Ciphering Activation Time
Verify that the Security Mode Complete carries UL Ciphering Activation Time
Verify that after Security mode complete, after the expiration of the ciphering activation time, all
messages are ciphered with the proper key.
Verify that both the UE and the network are able to decipher the messages.
Message flow:



UE NW

COMPLETE STARTPS
4 ATTACH REQUEST Includes STARTPS
5 AUTHENTICATION AND CIPHERING
REQUEST*
RESPONSE *
Activation Time
Activation Time
9 ATTACH ACCEPT
10 ATTACH COMPLETE**
COMPLETE
13-24 UE is powered OFF and
then ON again and the
procedure is repeated
* optional
** depends on the allocation of a new P-TMSI by the core PS
Remarks:

1 PLMN selection of RPLMN, HPLMN, UPLMN and OPLMN; Manual
B_6.1.1.1
mode
5 Not mapped Security Mode Command
B_8.1.3.2
Successful


F_6.11.4 PS - Ciphering at PS data session setup
Test Purpose:
To check that after ciphering has been activated for the SRBs, ciphering can be activated for the PS
traffic channel with the radio bearer setup procedure.
Pre-requisites:
UE is powered ON and has performed CS registration and PS attach
Test Procedure:
Initiate an MO PS data session.
After the call is set up, radio conditions should be changed to trigger an active set update procedure.
If SMS is supported in PS, an SMS is sent to the UE to verify ciphering on SRB#3 or 4.
The session is terminated.
Test Verification:
- Verify that the RB Setup Complete message carries STARTPS.
- Verify that at RB activation time, and starting at RLC SN=0, PS DTCH becomes active and is
ciphered.
- Verify that all Measurement reports sent on UL SRB#1 after Ciphering Activation time are being
ciphered, and can be de-ciphered properly by the network. If possible wait more than 128
Measurement Reports so that RLC HFN for RLC UM uplink is incremented.
- Verify that the active set update (UL) and Active set update complete (DL) sent on SRB#2 are
properly ciphered and deciphered
- Verify that RLC ACKs in UL and DL are not ciphered
- Verify, if SMS were sent over PS, that the SMS messaging sent on SRB#3 or SRB#4 is properly
ciphered and deciphered in UL and DL
- Verify that the RRC connection release message sent on DL SRB#1 is properly ciphered and
deciphered
Message flow:



UE NW

COMPLETE STARTPS
4 SERVICE REQUEST Includes STARTPS
REQUEST*
RESPONSE *
Activation Time
Activation Time
9 ACTIVATE PDP CONTEXT REQUEST
10 RADIO BEARER SETUP Includes RB Activation time
11 RADIO BEARER SETUP COMPLETE Includes STARTPS
12 ACTIVATE PDP CONTEXT ACCEPT
13 MEASUREMENT REPORT Decision to perform an
active set update
14 ACTIVE SET UPDATE
16 CP-DATA**
17 CP-ACK**
18 CP-DATA**
19 CP-ACK**
20 DEACTIVATE PDP CONTEXT REQUEST
21 DEACTIVATE PDP CONTEXT ACCEPT
COMPLETE
* optional
** in case SMS is supported over PS
Note: the network may send measurement control messages during the call setup to activate
measurements
Remarks:




8 B_16.2.1 SMS on PS mode / SMS mobile terminated
10a B_8.2.3.1 RRC / Radio Bearer Release for transition from CELL_DCH to
CELL_DCH: Success
10b B_8.2.3.7 RRC / Radio Bearer Release for transition from CELL_DCH to
CELL_FACH: Success
11a B_8.1.3.1 RRC/ RRC Connection Release in Cell_DCH state: Success
11b B_8.1.3.2 RRC / RRC Connection Release using on DCCH in CELL_FACH state:
Successful


F_6.11.5 CS+PS - Ciphering after addition of a CS call to a PS session - mixed addition and
release
Test Purpose:
To check that when a PS session is ongoing and a CS speech call is added, ciphering is correctly
applied on SRBs, PS DTCH and CS DTCH. Also, successive additions and releases are performed to
verify ciphering on SRBs.
Pre-requisites:
UE is powered ON and has an ongoing PS data session
Test Procedure:
Initiate an MT CS speech call.
Keep the CS call ongoing for 1 minute in order to increment RLC HFN.
Release the CS call
Initiate an MO CS speech call

Release the PS session
Establish a new PS session
Test Verification:
- Verify that the Security Mode Command carries DL Ciphering Activation Time for each SRB
- Verify that the Security Mode Complete carries UL Ciphering Activation Time for each SRB
- Verify that after Security Mode Complete and after Ciphering Activation Times, all messages should
be ciphered using the latest CK(CS) and not the previously used CK(PS).
- Verify that the RB Setup Complete carries STARTCS and CFN Activation time
- Verify that the voice is audible at the very beginning of the call, before activation time has elapsed
- Verify that at Ciphering Activation Time, RB is ciphered (HFNs are initialized with the START value
sent in the RB setup complete message, and are incremented)
- Verify that no measurement report is sent between Security Mode Complete and the corresponding
RLC-Ack.
- Verify that both network and UE are able to decipher the SRBs, CS DTCH and PS DTCH
- After each RB addition or release, verify that ciphering/deciphering is properly done on the SRBs:
Verify Ciphering on SRB1 by looking at RRC/ Measurement Reports
Verify Ciphering on SRB2 by looking at RRC/ Active Set Updates
Verify Ciphering on SRB3 by looking at DTMF messages
- Verify that there is no impact on the initial PS call
- When the CS call is released, verify that SRBs are still ciphered with the CK(CS)
Message flow:



UE NW
1 PAGING TYPE 2 (DCCH)

2 PAGING RESPONSE Contains STARTCS
5 SECURITY MODE COMMAND DL Ciphering activation
times for SRBs
6 SECURITY UL Ciphering activation
MODE times for SRBs
COMPLETE
7 SETUP
8 CALL PROCEEDING
10 RADIO BEARER SETUP COMPLETE Contains STARTCS and
CFN activation time
11 ALERTING
12 CONNECT
13 CONNECT ACKNOWLEDGE
14 DISCONNECT
15 RELEASE
16 RELEASE COMPLETE
18 RADIO SRB should still be
BEARER ciphered with CS key
RELEASE
COMPLETE
19 Establish CS speech again
SRBs are still ciphered
with CS key
20 Release PS session
SRBs are still ciphered with
CS key
21 Establish PS session
after ciphering activation
time in SMC, SRBs are
ciphered with PS CK
22 Release PS session
SRBs are still ciphered with
PS key
* optional
Remarks:



Success

CELL_DCH: Success
CELL_FACH: Success


F_6.11.6 CS+PS - Ciphering after addition of a PS session to a CS call mixed addition and
release
Test Purpose:
To check that when a CS call is ongoing and a PS session is added, ciphering is correctly applied on
SRBs, PS DTCH and CS DTCH. Also, successive additions and releases are performed to verify
ciphering on SRBs.
Pre-requisites:
UE is powered ON and has an ongoing CS call.
Test Procedure:
Initiate an MO PS data session. Exchange PS traffic so that the RLC SN wraps around, to increment
the HFNs.
Establish PS session
Release CS call
Establish CS call
Release CS call.
Test Verification:
- Verify that the Security Mode Command carries DL Ciphering Activation Time for each SRB
- Verify that the Security Mode Complete carries UL Ciphering Activation Time for each SRB
- Verify that after Security Mode Complete and after Ciphering Activation Times, all messages should
be ciphered using the latest CK(PS) and not the previously used CK(CS).
- Verify that the RB Setup Complete carries STARTPS and CFN Activation time
- Verify that At RB Activation Time and starting at RLC SN=0, RB becomes active and is ciphered
- Verify that no measurement report is sent between Security Mode Complete and the corresponding
RLC-Ack.
- Verify that both network and UE are able to decipher the SRBs, CS DTCH and PS DTCH
- After each RB addition or release, verify that ciphering/deciphering is properly done on the SRBs:
Verify Ciphering on SRB1 by looking at RRC/ Measurement Reports
Verify Ciphering on SRB2 by looking at RRC/ Active Set Updates
Verify Ciphering on SRB3 by looking at DTMF messages
- Verify that there is no audible impact on CS call quality
- When the PS call is released, verify that SRBs are still ciphered with the CK(PS)


Message flow:
UE NW
1 SERVICE REQUEST Contains STARTPS

REQUEST*
RESPONSE*
4 SECURITY MODE COMMAND DL Ciphering activation
times for SRBs
5 SECURITY MODE COMPLETE UL Ciphering activation
times for SRBs
6 ACTIVATE PDP CONTEXT REQUEST
RADIO BEARER SETUP Includes RB Activation time
7 Includes STARTPS
RADIO
BEARER
SETUP
COMPLETE
8 ACTIVATE
PDP
CONTEXT
ACCEPT
REQUEST
ACCEPT
12 RADIO BEARER RELEASE SRBs should still be
COMPLETE ciphered with the PS key
13 A PS session is established
SRBs are still ciphered
with PS CK
14 CS call is released SRBs
still ciphered with PS key
15 CS call is established
after ciphering activation
times in SMC, SRBs are
now ciphered with CS key
16 CS call is released SRBs
are still ciphered with CS
CK
* optional
Remarks:



Success

CELL_DCH: Success
CELL_FACH: Success


F_6.12.1.1 Successful establishment of HS-DSCH PS session
Test Purpose:
The purpose of this test is to verify that HS-DSCH PS session establishment is successful in a cell
supporting HSDPA.
Pre-requisites:
Configurations: A, B, C, D, E, F or G
UE supports HSDPA
There is at least one cell available supporting HSDPA
UE is attached and is in idle mode
UE and the network is prepared to establish and use a HS -DSCH PS session
Test Procedure:
UE initiates PDP context activation procedure. The QoS requested is the subscribed QoS.
Start UL and DL data transfer.
Test Verification:
Verify that the monitored sequence is correct and DL data throughput is as expected.
Message flow:

UE NW
session
either cell_DCH or
cell_FACH.
4 --> RRC CONNECTION SETUP COMPLETE (DCCH) RRC UE states its HSDPA
capability to the RNC.
6 <-- AUTHENTICATION AND CIPHERING REQUEST GMM (optional)
7 --> AUTHENTICATION AND CIPHERING RESPONSE GMM (optional)
10 --> ACTIVATE PDP CONTEXT REQUEST SM Requested QoS is
subscribed QoS.
11 <-- RADIO BEARER SETUP RRC RB SETUP - Target
RRC state is cell_DCH
13 <-- ACTIVATE PDP CONTEXT ACCEPT SM - QoS parameters
provided by the network is
as defined in the HLR. Verify
the user plane.
Remarks:

In step 4, UE states its HSDPA capability to the RNC inside Physical Channel Capability IE (inside UE
Radio Access Capability IE) in the RRC Connection Setup Complete message.
In step 11, RNC takes into account the UE capability information, information concerning whether HS-
DSCH is supported in the selected cell and RAB parameters and decides to map the service to
HSDPA. RNC selects HS-DSCH transport channel in the downlink. HSDPA configuration parameters
are included in the RB Setup message (inside dl Transport Channel Type IE and dl HS-PDSCH
information IE).
In step 13, new QoS parameters for high data rate (Maximum/ Guaranteed bit rate for downlink
(extended)) will be included if SGSN wants to indicate a Maximum bit rate for downlink from 8700
kbps to 16000 kbps.



F_6.12.1.2 Successful termination of HS -DSCH PS session
Test Purpose:
The purpose of this test is to verify that HS -DSCH PS session termination is successful.
Pre-requisites:
UE supports HSDPA
UE has established a successful HS -DSCH PS session in the cell supporting HSDPA
Test Procedure:
UE initiates PDP context deactivation procedure.
Test Verification:
Message flow:

UE NW
1 UE Initiate PDP context
deactivation
2 --> DEACTIVATE PDP CONTEXT REQUEST SM - Request a PDP
deactivation
3 <-- DEACTIVATE PDP CONTEXT ACCEPT SM - Accept PDP context
deactivation
4 <-- RADIO BEARER RELEASE RRC
5 --> RADIO BEARER RELEASE COMPLETE RRC
6 <-- RRC CONNECTION RELEASE RRC
7 --> RRC CONNECTION RELEASE COMPLETE RRC
Remarks:

CELL_DCH: Success


F_6.12.2.1 Successful establishment of HS-DSCH PS session then CS call
Test Purpose:
The purpose of this test is to verify that UE can make a HS-DSCH PS session and an AMR/ CS D call
simultaneously.
Pre-requisites:
UE supports HSDPA
UE and the network is prepared to establish and use a Multi-Service call with HS -DSCH PS session
Test Procedure:
UE originates a HS-DSCH PS session.

UE originates an AMR/ CSD call.
Test Verification:

Verify that both HS-DSCH PS session and AMR/ CSD call were setup properly.
Verify that audio/video quality is not affected after both calls were setup.
Verify that data throughput is not affected during and after CS call setup.
Message flow:

UE NW
session
either cell_DCH or
cell_FACH.
6 <-- AUTHENTICATION AND CIPHERING REQUEST GMM
7 --> AUTHENTICATION AND CIPHERING RESPONSE GMM
subscribed QoS.



the user plane.
14 Start data transfer
15 --> CM SERVICE REQUEST MM
16 <-- AUTHENTICATION REQUEST MM
17 --> AUTHENTICATION RESPONSE MM
20 --> SETUP CM
21 <-- CALL PROCEEDING CM
22 <-- RADIO BEARER SETUP RRC
24 <-- ALERTING CM
25 <-- CONNECT CM
26 --> CONNECT ACK CM
Remarks:
information IE).
kbps to 16000 kbps.

Success


F_6.12.2.2 Successful establishment of CS call then HS -DSCH PS session
Test Purpose:
The purpose of this test is to verify that UE can make an AMR/ CSD call and a HS -DSCH PS session
simultaneously.
Pre-requisites:
UE supports HSDPA
UE and the network is prepared to establish and use a Multi-Service call with HS -DSCH PS session
Test Procedure:
UE originates an AMR/ CSD call.

UE originates a HS-DSCH PS session.
Test Verification:

Verify that both AMR/ CSD call and HS-DSCH PS session were setup properly.
Verify that audio/video quality is not affected during and after both calls were setup.
Message flow:

UE NW
1 UE The Tester shall initiate an
AMR/ CSD call
cell_DCH.
5 --> CM SERVICE REQUEST MM
6 <-- AUTHENTICATION REQUEST MM
7 --> AUTHENTICATION RESPONSE MM
10 --> SETUP CM
11 <-- CALL PROCEEDING CM
12 <-- RADIO BEARER SETUP RRC
14 <-- ALERTING CM
15 <-- CONNECT CM
16 --> CONNECT ACK CM



19 <-- AUTHENTICATION AND CIPHERING REQUEST GMM
20 --> AUTHENTICATION AND CIPHERING RESPONSE GMM
subscribed QoS.
the user plane.
27 Start data transfer
Remarks:
information IE).
kbps to 16000 kbps.

Success


F_6.12.2.3 Successful termination of HS -DSCH PS session and keep DCH AMR/ CSD call active
Test Purpose:
The purpose of this test is to verify that UE can sustain the AMR/ CSD call after the HS-DSCH PS
session is released in a Multi-Service call.
Pre-requisites:
UE supports HSDPA
There is atleast one cell available supporting HSDPA
HS-DSCH PS session and AMR/ CSD call have been successfully established.
Test Procedure:
UE initiates PDP context deactivation procedure.
Test Verification:

Verify that the HS-DSCH PS session is released properly.
Verify that the AMR/ CSD call is not interrupted and audio quality is not affected after the HS-DSCH
PS session is released.
Message flow:

UE NW
1 UE HS-DSCH PS session and
AMR/ CSD call have been
previously established. UE
releases PS session
2 --> DEACTIVATE PDP CONTEXT REQUEST SM - Request a PDP
deactivation
deactivation
6 <-- SIGNALLING CONNECTION RELEASE RRC
Remarks:



F_6.12.2.4 Successful termination of DCH AMR/ CSD call and keep the HS -DSCH PS session
active
Test Purpose:
The purpose of this test is to verify that UE can sustain a HS-DSCH PS session after the AMR/ CSD
call is released in a Multi-Service call.
Pre-requisites:
UE supports HSDPA
There is atleast one cell available supporting HSDPA
HS-DSCH PS session and AMR/ CSD call have been successfully established.
Test Procedure:
UE releases the AMR/ CSD call.
Test Verification:

Verify that the AMR/ CSD call is released properly.
Verify that the HS-DSCH PS session and data throughput is not affected after the AMR/ CSD call is
released.
Message flow:

UE NW
1 UE HS-DSCH PS session and
AMR/ CSD call have been
previously established. UE
releases AMR/ CSD call
2 --> DISCONNECT CM
3 <-- RELEASE CM
4 --> RELEASE COMPLETE CM
7 <-- SIGNALLING CONNECTION RELEASE RRC
Remarks:



F_6.12.3.1 Successful PS call establishment of HS-DSCH when in SHO with on-going CS
Test Purpose:
To check that when in Soft Handover for an on going CS call, the establishment of PS Call is
successful in one cell of the supporting HS -DSCH in the active set.
Pre-requisites:
Configurations: B, C, D or E
UE supports HSDPA
MO/MT CS call has been successfully established, and the CS Call is on going
The UE is in Soft Handover in CELL_DCH for that call.
At least one HSDPA cell exists in the active set. If there are several HSPDA cells in the Active
Set, the RNC shall select the one candidate HSPDA cell.
Test procedure:
UE originates a PS data call.
Test Verification:
Verify that the CS Call goes on and stays in Soft Handover (assuming no radio condition
change).
Verify that the monitored message sequence is correct and the messages contents are
correct.
Verify that PS data can be transferred on HS-DSCH
Message Flow:

UE NW
1 CS Call is on going and the UE is in Soft
Handover
2 GMM SERVICE REQUEST UE originates a PS data call
CIPHERING REQUEST
(OPTIONAL)
CIPHERING RESPONSE
(OPTIONAL)
COMPLETE
REQUEST (SM)
8 RADIO BEARER SETUP The Network sends the RADIO BEARER
SETUP message to the UE to request the
establishment of the radio bearer
9 RADIO BEARER SETUP UE transmits a RADIO BEARER SETUP
COMPLETE COMPLETE message using AM RLC.
ACCEPT (SM)
11 Start data transfer The data transfer can be started (web
browser or accessing a known ftp server).



1 F_6.2.10 / F_6.2.11 MT/MO Voice Call


F_6.12.4.1 Intra-NodeB serving HS-DSCH cell change / PS only
Test Purpose:
To check that the serving HS -DSCH cell is changed successfully, when a cell satisfies the criterion to
be the new serving HS -DSCH cell and the UTRAN triggers the HS-DSCH cell change procedure. The
target cell is on the same NodeB as the source cell.
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on the same NodeB (softer handover).
UE is HSDPA capable
Intra-frequency measurements are set up by UTRAN using a MEASUREMENT CONTROL (or
SIB#11)
A call has been established and the Active Set contains cell 1 + cell 2. Cell 1 is the serving HS-DSCH
cell.
The UE is in the following state:
PS_DCCH+DTCH_HS-DSCH (state 6-17) as specified in 7.4 of 34.108.
Test procedure:
UE is sending measurement reports. Radio conditions are changed so that cell 2 satisfies the criterion
to become the new serving HS-DSCH cell. The UTRAN decides to change the serving HS-DSCH cell
and the RNC establishes the radio link for the HS-DSCH to the target cell. Then the UTRAN sends the
RECONFIGURATION message to the UE providing information about the HSDPA configuration and
activation time. The UE shall respond with RECONFIGURATION COMPLETE message.
Test Verification:
Verify that the monitored message sequence is correct. Serving cell change procedure does not
impact HS-DSCH reception. No data is lost.


Message Flow:

UE NW
1 MEASUREMENT REPORT (DCCH) UE sends intra-frequency measurements,
as requested by UTRAN.
2 The tester modifies radio conditions such
that the non-serving HS -DSCH cell 2 in
the Active Set satisfies the criterion to be
the new serving HS-DSCH cell.
as requested by UTRAN. (e.g. event 1d)
4 serving HS -DSCH cell change decision
by UTRAN
5 RADIO BEARER * Including new HSDPA configuration (and
RECONFIGURATION (DCCH) Activation Time if synchronized Cell
Change)
6 RADIO BEARER *
(DCCH)
* Alternatively Transport Channel reconfiguration or Physical Channel reconfiguration could be used


F_6.12.4.2 Inter-NodeB serving HS-DSCH cell change / PS only
Test Purpose:
target cell is on the same RNC but on a different NodeB than the source cell.
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on different NodeBs (soft handover).
UE is HSDPA capable
SIB#11)
A call has been established and the Active Set contains Cell 1 + Cell 2. Cell 1 is the serving HS-DSCH
cell.
Test procedure:
UE is sending measurement reports. Radio conditions are changed again so that cell 2 satisfies the
criterion to become the new serving HS-DSCH cell. The UTRAN decides to change the serving HS-
DSCH cell and the RNC establishes the radio link for the HS-DSCH to the target cell. Then the
UTRAN sends the RECONFIGURATION message to the UE providing information about the HSDPA
configuration and activation time. The UE shall respond with RECONFIGURATION COMPLETE
message.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception is not impacted by
serving cell change procedure. No data is lost.


Message Flow:

UE NW
by UTRAN
Change)
6 RADIO BEARER
*RECONFIGURATION COMPLETE
(DCCH)


F_6.12.4.3 Inter-RNC (with IUR) serving HS-DSCH cell change / PS only
Test Purpose:
target cell is on a different RNC than the source cell.
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on different NodeBs (soft handover).
UE is HSDPA capable
SIB#11)
A call has been established and the Active Set contains Cell 1 + Cell 2. Cell 1 is the serving HS-DSCH
cell.
Test procedure:
message.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception is not impacted by
serving cell change procedure, no data is lost.


Message Flow:

UE NW
by UTRAN
5 RADIO BEARER *) Including new HSDPA configuration (and
Change)
6 RADIO BEARER *)
(DCCH)
*) Alternatively Transport Channel reconfiguration or Physical Channel reconfiguration could be used


F_6.12.4.4 Intra-NodeB serving HS-DSCH cell change / PS + CS
Test Purpose:
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on the same NodeB (softer handover)
UE is HSDPA capable
SIB#11)
A CS call, which is mapped to the DCH, has been established. The Active Set contains Cell 1 + Cell 2.
Additionally, a PS call, which is mapped to the HS -DSCH, has been established and Cell 1 is the
serving HS -DSCH cell.
CS+PS_DCCH+DTCH_DCH+HS-DSCH not specified in 7.4 of 34.108.
Test procedure:
UE is sending measurement reports. Radio conditions are changed so that Cell 2 satisfies the criterion
to become the new serving HS-DSCH cell. The UTRAN decides to change the serving HS-DSCH cell
and the RNC establishes the radio link for the HS-DSCH to the target cell. Then the UTRAN sends the
RECONFIGURATION message to the UE providing information about the HSDPA configuration and
activation time. The UE shall respond with RECONFIGURATION COMPLETE message.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH service as well as CS service
(speech, video) are not impacted. No data lost and no visible / auditable impact is observed.


Message Flow:

UE NW
by UTRAN
Change)
6 RADIO BEARER *
(DCCH)


F_6.12.4.5 Inter-NodeB serving HS-DSCH cell change / PS + CS
Test Purpose:
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on the same RNC but on different
NodeBs (soft handover).
UE is HSDPA capable
A CS call, which is mapped to the DCH, has been established. The Active Set contains Cell 1 + Cell 2.
Additionally, a PS call, which is mapped to the HS -DSCH, has been established and Cell 1 is the
serving HS -DSCH cell.
CS+PS_DCCH+DTCH_DCH+HS-DSCH not specified in 7.4 of 34.108.
Test procedure:
message.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH service as well as CS service
(speech, video) are not impacted. No data lost and no visible / auditable impact is observed.


Message Flow:

UE NW
by UTRAN
Change)
6 RADIO BEARER *
(DCCH)


F_6.12.5.1.1 Reconfiguration from HS-DSCH to DCH - PS only - intra-cell
Test Purpose:
Check that the reconfiguration from HS-DSCH to DCH can successfully be performed by the UTRAN
and UE.
Pre-requisites:
Configuration: A, B, C, D or E: the nodeB supports HSDPA.
UE supports HS-PDSCH
UE is in PS-DCCH+DTCH_HS -DSCH (state 6-17) as specified in clause 7.4 of TS 34.108 v5.1.0
(June 2004)
Test Procedure:
The UTRAN performs a reconfiguration procedure to reconfigure the PS session from HS -DSCH to
DCH. The trigger of reconfiguration depends on Network implementation.
Test Verification:
Verify that no data is lost during the reconfiguration to DCH
Verify that UE reconfigures properly, i.e. that the RLC, TrCH and Phy CH parameters specified in the
reconfiguration message are used.
Message flow:

UE NW
1 RADIO BEARER Reconfigures from HS -

RECONFIGURATION* DSCH to DCH
COMPLETE*
* Note that a transport channel reconfiguration or a physical channel reconfiguration procedure could
be used, depending on network implementation. But in that case, the RLC parameters cannot be
reconfigured.
Remarks:
Test ID Protocol Te st case

1 8.2.2.36 (from Radio Bearer Reconfiguration for transition from CELL_DCH to
34.123) CELL_DCH: Success (Start and stop of HS-DSCH reception)


F_6.12.5.1.2 Reconfiguration from HS -DSCH to DCH - PS only - intra-sector, inter-cell - HSDPA on

a separate frequency
Test Purpose:
To check that when the criterion/criteria for reconfiguring from HS -DSCH to DCHis/are satisfied, the
reconfiguration can successfully be performed by the UTRAN and UE. For this test case, HSDPA is
deployed on a separate frequency.
Pre-requisites:
Configuration: B, C, D or E: cell 1 supports HSDPA and uses RF channel 1, cell 2 does not support
HSDPA and uses RF channel 2.
(June 2004)
Test Procedure:
Note: Criterion to trigger the inter frequency hard handover depends on the network implementation
Radio/test conditions are changed so that the criterion/criteria for triggering an inter-frequency
handover to cell 2 is/are fulfilled. RNC sends a RADIO BEARER RECONFIGURATION message
instructing the UE to perform an inter-frequency hard handover to cell 2 and stop the reception of HS-
DSCH
Test Verification:
Verify that no data is lost during the reconfiguration to DCH and the hard handover.
Verify that UE reconfigures properly, i.e. that the RLC, TrCH and PhyCH parameters specified in the
Verify that after step 2 the UE responds on the RF channel 2.
Verify that the old radio link with cell1 (on RF channel 1) was deleted.
Message flow:

UE NW
1 Made by the RNC

Reconfiguration / Inter-frequency handover
decision
2 RADIO BEARER Hard handover and
RECONFIGURATION* reconfiguration from HS-
DSCH to DCH
COMPLETE*
reconfigured.


Remarks:

1 Radio Bearer Reconfiguration for transition from CELL_DCH to
8.2.2.39 (from
CELL_DCH: Success (Timing re-initialised hard handover to another
34.123)
frequency, start and stop of HS-DSCH reception)


F_6.12.5.1.3 Reconfiguration from HS -DSCH to DCH after active set update - PS only - intra-
NodeB / inter-sector
Test Purpose:
To check that when the UE moves into a cell where HSDPA resources are not available, the network
can reconfigure from HS-DSCH to DCH and then eventually perform an active set update procedure
to remove the original radio link. Source and target cells belong to the same Node B.
Pre-requisites:
Configuration: B: nodeB1 cell 1 supports HSDPA uses RF Channel 1, cell 2 does not support HSDPA)
on RF channel 1.
(June 2004)
Measurements are set up using measurement control or SIB#11
Test Procedure:
criterion to be added to the active set. RNC sends ACTIVE SET UPDATE to UE, with parameters of
cell 2 to be added to the active set.
Radio conditions are then changed again so that the criterion for reconfiguring the HS-DSCH link is
satisfied (e.g. primary cell change and no HSDPA resources are available in the target cell). The
network initiates a reconfiguration procedure to reconfigure from HS -DSCH to DCH.
Depending on how the reconfiguration is triggered, and on network implementation, the network may
perform an active set update procedure to remove cell 1 from the active set.
Test Verification:



Message flow:

UE NW
1 -> MEASUREMENT REPORT (DCCH) UE returns intra-frequency

measurements, as
requested by UTRAN.
conditions so that cell 2 is
added to the active set
3 -> MEASUREMENT REPORT (DCCH) UE returns intra-frequency
measurements, as
requested by UTRAN.
4 Softer handover decision Made by the RNC.
5 <- ACTIVE SET UPDATE (DCCH) RRC
6 -> ACTIVE SET UPDATE COMPLETE RRC
(DCCH)
7 The tester modifies
radio/test conditions to
trigger a reconfiguration
from HS-DSCH to DCH
(e.g. with a primary cell
change)
8 <- RADIO BEARER Reconfigures from HS -
9 -> RADIO BEARER RECONFIGURATION
COMPLETE*
(10) <- (ACTIVE SET UPDATE) Removes cell 1 from active
set
(11) -> (ACTIVE SET UPDATE COMPLETE)
reconfigured.
Remarks:

1 B_8.3.4.1b RRC / Active set update in soft handover: Radio Link addition (FDD)
3 B_8.3.4.2b RRC / Active set update in soft handover: Radio Link removal (FDD)
Note from editor: a test case should be added for active set update removing the HS-DSCH RL before
reconfiguration can be done. This should be in the active set update section


F_6.12.5.1.4 Reconfiguration from HS -DSCH to DCH after active set update - PS only - intra-
Node B / inter-sector - HSDPA on a separate frequency
Test Purpose:
To check that when the UE moves into a cell in which HSDPA resources are not available, the
network can perform an inter-frequency reconfiguration procedure from HS-DSCH to DCH and then
eventually perform an active set update procedure to remove the original radio link. Source and target
cells belong to the same Node B. HSDPA is deployed on a separate frequency.
Pre-requisites:
Configuration: C (1RNC, 1Node B, 2 sectors - 4 cells): nodeB1 supports HSDPA for all its sectors, but
HSDPA is only deployed on RF channel 1, i.e. cell 1 (of sector 1) and cell 2 (of sector 2). HSDPA
resources are only available in cell 1. Cells 3 (sector 1) and 4 (sector 2) are used for R99 DCH
service.
(June 2004)
Test Procedure:
satisfied (e.g. primary cell change and no HSDPA resources are available in target cell). The
network initiates an inter-frequency reconfiguration procedure to reconfigure from HS-DSCH to DCH
and on cells 3 and 4, on RF channel 2.
Test Verification:



Message flow:

UE NW
1 <- MEASUREMENT REPORT (DCCH) UE returns intra-frequency

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
4 soft handover decision Made by the RNC.
(DCCH)
from HS-DSCH to DCH
change)
COMPLETE*
set
reconfigured.
Remarks:



F_6.12.5.1.5 Reconfiguration from HS -DSCH to DCH after active set update - PS only - inter-
NodeB
Test Purpose:
To check that when the UE moves out of HSDPA coverage (or into a cell in which no HSDPA
resources are available), the network can reconfigure from HS-DSCH to DCH and then eventually
perform an active set update procedure to remove the original radio link. Source and target cells
belong to different Node Bs.
Pre-requisites:
Configuration: D: nodeB1 (cells 1-2-3) supports HSDPA (and associated DCH) on RF channel 1,
nodeB2 (cells 4-5-6) does not support HSDPA (or supports HSDPA but has no HSDPA resources
available) and uses RF channels 1.
(June 2004)
Test Procedure:
satisfied (e.g. primary cell change and target cell does not support HSDPA or has no HSDPA
resources available). The network initiates a reconfiguration procedure to reconfigure from HS-DSCH
to DCH, on RF channel 1.
Test Verification:



Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
from HS-DSCH to DCH
change)
COMPLETE*
set
reconfigured.
Remarks:
Test ID Protocol Test ca se



F_6.12.5.1.6 Reconfiguration from HS -DSCH to DCH after active set update - PS only - inter-
NodeB - HSDPA on a separate frequency
Test Purpose:
To check that when the UE moves out of HSDPA coverage or into a cell in which HSDPA resources
are not available, the network can perform an inter-frequency reconfiguration procedure from HS-
DSCH to DCH and then eventually perform an active set update procedure to remove the original
radio link. Source and target cells belong to the same Node B. HSDPA is deployed on a separate
frequency.
Pre-requisites:
Configuration: D (1RNC, 2 Node B with 2 cells each part of the same sector): nodeB1 (cells 1,2 of
RF channels 1 and 2 respectively), supports HSDPA on RF Channel 1 (cell 1). nodeB2 (cells 3 and 4
on RF channels 1 and 2 respectively) doesnt support HSDPA (or has no resources for it).
(June 2004)
Test Procedure:
satisfied (e.g. primary cell change and target cell doesnt support HSDPA). The network initiates an
inter-frequency reconfiguration procedure to reconfigure from HS -DSCH to DCH and on cells 2 and 4,
on RF channel 2.
Test Verification:



Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
from HS-DSCH to DCH
change)
COMPLETE*
set
reconfigured.
Remarks:



F_6.12.5.1.7 Reconfiguration from HS -DSCH to DCH after active set update - PS only - inter-RNC
with Iur
Test Purpose:
To check that when the UE moves out of HSDPA coverage, the network first reconfigures the HS-
DSCH radio link, and then removes it through an active set update procedure.
Pre-requisites:
Configuration: E: nodeB1 (cells 1-2-3) supports HSDPA, nodeB2 (cells 4-5-6) does not support
HSDPA
(June 2004)
Test Procedure:
satisfies the criterion to be added to the active set. RNC sends ACTIVE SET UPDATE to UE, with
parameters of cell 4 to be added to the active set.
satisfied. The network initiates a reconfiguration procedure to reconfigure from HS-DSCH to DCH.
Test Verification:



Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
7 The tester modifies radio/test
conditions so that a
reconfiguration from HS-
DSCH to DCH is triggered
(e.g. a primary cell change)
COMPLETE*
(10) (ACTIVE SET UPDATE) Removes cell 1 from active
set
(11) (ACTIVE SET UPDATE COMPLETE)
reconfigured.
Remarks:



F_6.12.5.1.8 Reconfiguration from HS -DSCH to DCH after radio link removal - PS only
Test Purpose:
To check that when the UE suddenly moves out of HSDPA coverage and the network removes the
HS-DSCH radio link, the network is able to reconfigure the PS session to DCH.
Pre-requisites:
Configuration: D or E: nodeB1 (cells 1-2-3) supports HSDPA, nodeB2 (cells 4-5-6) does not support
HSDPA
(June 2004)
Test Procedure:
satisfies the criterion to be added to the active set, but with cell 1 staying the primary cell. RNC sends
ACTIVE SET UPDATE to UE, with parameters of cell 4 to be added to the active set.
Radio conditions are then changed again so that the criterion for removing the HS -DSCH radio link is
Test Verification:



Message flow:

UE NW

by UTRAN.
by UTRAN.
removed from the active set.
8 ACTIVE SET UPDATE (DCCH) RRC Removes cell 1
from active set
(DCCH)
10 RADIO BEARER Reconfigures the PS RAB
RECONFIGURATION* mapping from HS-DSCH to
DCH
COMPLETE*
reconfigured.
Remarks:

2 B_8.2.2.36 Radio Bearer Reconfiguration for transition from CELL_DCH to
(new) CELL_DCH: Success (Start and stop of HS-DSCH reception)


F_6.12.5.1.9 Reconfiguration from HS -DSCH to DCH after active set update - PS only - inter-RNC
with Iur - HSDPA on a separate frequency
Test Purpose:
DSCH radio link, and then removes it through an active set update procedure,
when moving between 2 RNCs with an Iur. For this test case, HSDPA is deployed on a separate
frequency than DCH.
Pre-requisites:
Configuration: E: nodeB1 (cells 1-2-3) supports HSDPA (and associated DCH) on RF channel 1 (and
R99 DCH on RF channel 2), nodeB2 (cells 4-5-6) does not support HSDPA and uses RF channels 1
and 2
(June 2004)
Test Procedure:
satisfied. The network initiates a reconfiguration procedure to reconfigure from HS-DSCH to DCH, on
RF channel 2.
Test Verification:



Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
from HS-DSCH to DCH
change)
COMPLETE*
set
reconfigured.
Remarks:



F_6.12.5.1.10 Reconfiguration from HS -DSCH to DCH - PS only - inter-RNC without Iur
Test Purpose:
To check that when the UE has an active PS HS -DSCH session and it moves out of HSDPA
coverage, a reconfiguration from HS-DSCH to DCH can successfully be performed between the
network and the UE, when moving between 2 RNCs without Iur.
Pre-requisites:
Configuration: E: nodeB1 (cells 1-2-3) supports HSDPA (and associated DCH) on RF channel 1,
nodeB2 (cells 4-5-6) does not support HSDPA and uses RF channels 2
(June 2004)
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed again so that the
criterion/criteria for handing the UE over to cell 4 is/are satisfied. The network initiates a hard
handover / reconfiguration procedure, and reconfigures the radio link from HS-DSCH to DCH.
Note: The trigger of the radio bearer reconfiguration depends on the network implementation.
Test Verification:

Message flow:

UE NW

and/or inter-frequency
by UTRAN.
COMPLETE*
reconfigured.


Remarks:



F_6.12.5.2.1 Reconfiguration from DCH to HS-DSCH - PS only - Intra-cell
Test Purpose:
To check that the Reconfiguration from DCH to HS-DSCH can successfully be performed by the
UTRAN and UE
Pre-requisites:
Configuration: A, B, C, D or E: the UTRAN supports HSDPA

A call has been established, and the UE is in the following state:

UE is in PS-DCCH+DTCH_DCH (state 6-10) as specified in clause 7.4 of TS 34.108
Test Procedure:
Radio/test conditions are modified so that the trigger to reconfigure from DCH to HS -DSCH is met.
The UTRAN performs a reconfiguration procedure to reconfigure the PS session from DCH to HS-
DSCH. The trigger of reconfiguration depends on Network implementation.
Test Verification:
Verify that no data is lost during the reconfiguration to DS -DSCH
Message flow:

UE NW
1 RADIO BEARER Reconfigures from DCH to

RECONFIGURATION* HS-DSCH
COMPLETE*
be used, depending on network implementation. But for these procedures, the RLC info parameters
cannot be reconfigured.
Remarks:

1 8.2.2.36
Radio Bearer Reconfiguration for transition from CELL_DCH to
(From
CELL_DCH: Success (Start and stop of HS-DSCH reception)
34.123)


F_6.12.5.2.2 Reconfiguration from DCH to HS-DSCH - PS only - intra-sector, inter-cell - HSDPA on

a separate frequency
Test Purpose:
UTRAN and UE. For this test case, HSDPA is deployed on a separate frequency than DCH.
Pre-requisites:
Configuration: B, C, D or E: 2 RF channels per nodeB sector (considered separate cells 1 and 2). Cell
1 uses RF channel 1 and supports HSDPA. Cell 2 uses RF channel 2 and does not support HSDPA.
Test Procedure:
Radio/Tests conditions are changed so that the criterion/criteria for triggering a reconfiguration from
DCH to HS-DSCH is/are fulfilled. RNC sends a RADIO BEARER RECONFIGURATION message
instructing the UE to perform an inter-frequency hard handover to cell 1 and start the reception of HS-
DSCH
Test Verification:
Verify that no data is lost during the reconfiguration to DCH and the hard handover.
Message flow:

UE NW
1 RADIO BEARER Switches from DCH to HS-

RECONFIGURATION* DSCH with a frequency carrier
change.
COMPLETE*
reconfigured.


Remarks:

1 8.2.2.39 Radio Bearer Reconfiguration for transition from CELL_DCH to
(From CELL_DCH: Success (Timing re-initialised hard handover to another
34.123) frequency, start and stop of HS-DSCH reception)
Note from editor: in the test case, it is not specified whether the hard handover is blind or with
measurements. Two test cases could be written: one for blind handover and one with inter-frequency
measurements.


F_6.12.5.2.3 Reconfiguration from DCH to HS-DSCH after active set update - PS only - intra-
NodeB / inter-sector
Test Purpose:
To check that when the UE has an active PS DCH call and HSDPA resources become available, a
reconfiguration from DCH to HS -DSCH can successfully be performed.
Pre-requisites:
Configuration B: (1 RNC, 1 Node B, 2 cells), cell 1 supports HSDPA, cell 2 does not have HSDPA
resources available
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cell 1 is added to the
active set of the UE. RNC sends ACTIVE SET UPDATE to UE, with parameters of cell 1 to be added
to the active set.
Radio/test conditions are modified again to trigger a reconfiguration from DCH to HS-DSCH.
The UTRAN then performs a reconfiguration procedure to reconfigure the PS session on HS -DSCH.
The network may perform an active set update procedure to remove cell 2 from the active set, if the
criterion is met.
Test Verification:
Verify that no data is lost during the reconfiguration to HS -DSCH
Verify that UE correctly decodes the HS-SCCH channel after the reconfiguration


Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
4 softer handover decision Made by the RNC.
(DCCH)
radio/test conditions so that
a reconfiguration from DCH
to HS-DSCH is triggered
(e.g. primary cell change)
8 RADIO BEARER Reconfi gures from DCH to
COMPLETE*
(10) (ACTIVE SET UPDATE (DCCH)) RRC
(11) (ACTIVE SET UPDATE COMPLETE RRC
(DCCH))
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.2.4 Reconfiguration from DCH to HS-DSCH after active set update - PS only - intra-
NodeB / inter-sector - HSDPA on a separate frequency
Test Purpose:
To check that when the UE has an active PS DCH call and HSDPA resources become available, a
reconfiguration from DCH to HS -DSCH can successfully be performed, with HSDPA deployed on a
separate frequency.
Pre-requisites:
Configuration: C: nodeB1 with 2 sectors, each sector is configured with 2 RF channels. Sector 1: cell 1
(RF channel 1) and cell 2 (RF channel 2). Sector 2: cell 3 (RF channel 1) and cell 4 (RF channel 2).
HSDPA is deployed on RF channel 1. HSDPA resources are available in cell 1, but not in cell 3.
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed so that cell 2 (node B1) is
added to the active set of the UE. RNC sends ACTIVE SET UPDATE to UE, with parameters of cell 2
to be added to the active set.
Radio/test conditions are modified again to trigger a reconfiguration from DCH to HS-DSCH (e.g.
primary cell change cell 2 becomes the best cell).
The UTRAN then performs an inter-frequency reconfiguration procedure to reconfigure the PS session
on HS -DSCH on cell 1 (with associated DCH on cell 1 and 3).
criterion is met.
Test Verification:



Message flow:

UE NW

by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
8 RADIO BEARER Reconfigures from DCH
RECONFIGURATION* to HS -DSCH on cell1.
COMPLETE*
(DCCH))
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.2.5 Reconfiguration from DCH to HS-DSCH after active set update - PS only - inter-
NodeB
Test Purpose:
To check that when the UE has an active PS DCH call and it moves into HSDPA coverage (or into a
cell in which HSDPA resources are available), after an active set update procedure, a reconfiguration
from DCH to HS -DSCH can successfully be performed. UE is moving between 2 cells belonging to
different node B on the same frequency.
Pre-requisites:
Configuration: D (1 RNC, 2 Node Bs, 6 cells): nodeB1 (cells 1-2-3) supports HSDPA (and associated
DCH) on RF channel 1, nodeB2 (cells 4-5-6) does not support HSDPA (or doesnt have available
resources for HSDPA0 and uses RF channels 1.
Test Procedure:
primary cell change and target cell support HSDPA).
The UTRAN then performs a reconfiguration procedure to reconfigure the PS session on HS-DSCH,
with the establishment on RF channel 1.
criterion is met.
Test Verification:



Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
4 soft handover decision Made by the RNC. Primary
cell change.
(DCCH)
COMPLETE*
(DCCH))
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


NodeB - HSDPA on a separate frequency
Test Purpose:
To check that when the UE has an active PS DCH call and it moves into HSDPA coverage (or into a
cell in which HSDPA resources are available), the network can perform reconfiguration from DCH to
HS-DSCH on a cell with a different frequency.
Pre-requisites:
Configuration: D: (1 RNC, 2 Node Bs, 4 cells) nodeB1: 1 sector with 2 cells: cell 1 on RF channel 1
(used for HSDPA), cell 2 on RF channel 2 (for classic R99 DCH), nodeB2 does not support HSDPA
(or has no resources available for it).
Cells 3 and 4 are on RF channel 1 and 2 respectively.
Test Procedure:
primary cell change).
The UTRAN then performs an inter-frequency reconfiguration procedure to reconfigure the PS session
on HS -DSCH on cell 1 (with associated DCH on cell 1 and 3).
Test Verification:



Message flow:

UE NW

by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
RECONFIGURATION* HS-DSCH on cell 1
COMPLETE*
(DCCH))
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


RNC with Iur
Test Purpose:
To check that when the UE has an active PS DCH call and it moves into HSDPA coverage, a
reconfiguration from DCH to HS -DSCH can successfully be performed between the network and the
UE, when moving between 2 RNCs with an Iur.
Pre-requisites:
HSDPA
Test Procedure:
The UTRAN then performs a reconfiguration procedure to reconfigure the PS session on HS -DSCH.
Test Verification:



Message flow:

UE NW

by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
8 RADIO BEARER Reconfigures from DCH
RECONFIGURATION* to HS -DSCH
9 ( RADIO BEARER RECONFIGURATION
COMPLETE*
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.2.8 Reconfiguration from DCH to HS-DSCH after active set update - PS only - inter-RNC
Test Purpose:
UE, when moving between 2 RNCs with an Iur. For this test case, HSDPA is deployed on a separate
frequency than DCH.
Pre-requisites:
Test Procedure:
(RF channel 2) to be added to the active set.
The UTRAN then performs a reconfiguration procedure to reconfigure the PS session on HS-DSCH,
Test Verification:



Message flow:

UE NW

by UTRAN.
measurements, as
requested by UTRAN.
cell change.
(DCCH)
COMPLETE*
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.2.9 Reconfiguration from DCH to HS-DSCH - PS only - inter-RNC without Iur (separate
frequencies)
Test Purpose:
UE, when moving between 2 RNCs without Iur.
Pre-requisites:
Test Procedure:
for handing the UE over to cell 1 is/are met. RNC initiates the RB reconfiguration procedure to perform
the hard HO and reconfigure the PS session to HS-DSCH.
Test Verification:


Message flow:

UE NW
1 MEASUREMENT REPORT (DCCH) UE returns measurements,

conditions so that an inter-
RNC HO is triggered
4 Hard handover decision Made by the RNC
COMPLETE*
reconfigured.
Remarks:

1 8.2.2.36
(From
34.123)


F_6.12.5.3.1 Reconfiguration from HS-DSCH to DCH CS + PS - intra-cell
Test Purpose:
Check that the reconfiguration from HS-DSCH to DCH can successfully be performed by the UTRAN
and UE.
Pre-requisites:

A multi service call has been established with cell 1.
Test Procedure:
The UTRAN performs a reconfiguration procedure to reconfigure the CS + PS session from HS-DSCH
to DCH. The trigger of reconfiguration depends on Network implementation.
Test Verification:
Verify that no data is lost during the reconfiguration to DCH and no performance loss on CS call.
Message flow:

UE NW

COMPLETE*
reconfigured.
Remarks:

1 8.2.2.36
(From
34.123)


F_6.12.5.3.2 Reconfiguration from HS -DSCH to DCH CS + PS - intra-sector - HSDPA on a

separate frequency
Test Purpose:
To check that when the criterion/criteria for reconfiguring from HS -DSCH to DCHis/are satisfied, the
reconfiguration can successfully be performed by the UTRAN and UE. For this test case, HSDPA is
deployed on a separate frequency.
Pre-requisites:
Configuration: B, C, D or E: cell 1 supports HSDPA and uses RF channel 1, cell 2 does not support
HSDPA and uses RF channel 2.
Test Procedure:
Note: Criterion to trigger the inter frequency hard handover depends on the network implementation
Radio/test conditions are changed so that the criterion/criteria for triggering an inter-frequency
handover to cell 2 is/are fulfilled. RNC sends a RADIO BEARER RECONFIGURATION message
instructing the UE to perform an inter-frequency hard handover to cell 2 and stop the reception of HS-
DSCH
Test Verification:
Verify that no data is lost and there is no performance loss on CS call during the reconfiguration to
DCH and the hard handover.
Message flow:

UE NW
1 Made by the RNC

Reconfiguration / Inter-frequency handover
decision
2 RADIO BEARER Hard handover and
RECONFIGURATION* reconfiguration from HS-
DSCH to DCH
COMPLETE*
reconfigured.


Remarks:

Note from editor: in the test case, it is note specified whether the hard handover is blind or with
measurements. Two test cases could be written: one for blind handover and one with
inter-frequency measurements


F_6.12.5.3.7 Reconfiguration from HS -DSCH to DCH after active set update - CS +PS - inter-RNC
with Iur
Test Purpose:
DSCH radio link, and then removes it through an active set update procedure.
Pre-requisites:
HSDPA
A CS+PS call has been established with cell 1.
Test Procedure:
Test Verification:
DCH.


Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
conditions s o that a
DSCH to DCH is triggered
(e.g. a primary cell change)
COMPLETE*
set
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.3.8 Reconfiguration from HS -DSCH to DCH after radio link removal - CS +PS
Test Purpose:
To check that when the UE suddenly moves out of HSDPA coverage and the network removes the
HS-DSCH radio link, the network is able to reconfigure the PS and CSsession to DCH.
Pre-requisites:
Configuration: D or E: nodeB1 (cells 1-2-3) supports HSDPA, nodeB2 (cells 4-5-6) does not support
HSDPA
A CS + PS call has been established with cell 1.
Test Procedure:
satisfies the criterion to be added to the active set, but with cell 1 staying the primary cell. RNC sends
ACTIVE SET UPDATE to UE, with parameters of cell 4 to be added to the active set.
Radio conditions are then changed again so that the criterion for removing the HS -DSCH radio link is
Test Verification:
Verify that no data is lost, there is no performance loss on CS callduring the reconfiguration to DCH


Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
cell 1 is removed from the
active set.
8 ACTIVE SET UPDATE (DCCH) RRC Removes cell 1
from active set
(DCCH)
10 RADIO BEARER Reconfigures the PS and
RECONFIGURATION* CS RAB mapping from HS -
DSCH to DCH
COMPLETE*
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.3.9 Reconfiguration from HS -DSCH to DCH after active set update - CS +PS - inter-RNC
Test Purpose:
DSCH radio link, and then removes it through an active set update procedure,
when moving between 2 RNCs with an Iur. For this test case, HSDPA is deployed on a separate
frequency than DCH.
Pre-requisites:
and 2
Test Procedure:
Radio conditions are then changed again so that the criterion for reconfiguring the HD-DSCH link is
satisfied. The network initiates a reconfiguration procedure to reconfigure from HS-DSCH to DCH, on
RF channel 2.
Test Verification:
Verify that no data is lost and there is no performance loss on CS callduring the reconfiguration to
DCH.


Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
conditions to trigger a
DSCH to DCH (e.g. with a
primary cell change)
COMPLETE*
set
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.3.10 Reconfiguration from HS -DSCH to DCH - CS +PS - inter-RNC without Iur
Test Purpose:
To check that when the UE has an active PS HS -DSCH session and it moves out of HSDPA
coverage, a reconfiguration from HS-DSCH to DCH can successfully be performed between the
network and the UE, when moving between 2 RNCs without Iur.
Pre-requisites:
UE supports HS-P DSCH
A CS+PScall has been established with cell 1.
Test Procedure:
UE is sending measurement reports. Radio conditions are then changed again so that the
criterion/criteria for handing the UE over to cell 4 is/are satisfied. The network initiates a hard
handover / reconfiguration procedure, and reconfigures the radio link from HS-DSCH to DCH.
Note: The trigger of the radio bearer reconfiguration depends on the network implementation.
Test Verification:
DCH
Message flow:

UE NW

and/or inter-frequency
measurements, as
requested by UTRAN.
COMPLETE*
reconfigured.


Remarks:

1 8.2.2.36
(From
34.123)
reconfiguration can be done (e.g. when turning a street corner). This should be in the active set
update section.


F_6.12.5.4.1 Reconfiguration from DCH to HS-DSCH - CS + PS - Intra-cell
Test Purpose:
UTRAN and UE
Pre-requisites:
Configuration: A, B, C, D or E: the UTRAN supports HSDPA

A CS+PS call has been established, and the UE is in the following state:
UE is in PS+CS-DCCH+DTCH_DCH (state 6-14) as specified in clause 7.4 of TS 34.108
Test Procedure:
Radio/test conditions are modified so that the trigger to reconfigure from DCH to HS -DSCH is met.
The UTRAN performs a reconfiguration procedure to reconfigure the CS+PS session from DCH to HS-
DSCH. The trigger of reconfiguration depends on Network implementation.
Test Verification:
Verify that no data is lost and that there is no performance loss on CS call during the reconfiguration
during the reconfiguration to DS -DSCH.
Message flow:

UE NW

COMPLETE*
be used, depending on network implementation. But for these procedures, the RLC info parameters
cannot be reconfigured.
Remarks:

1 8.2.2.36
(From
34.123)


F_6.12.5.4.2 Reconfiguration from DCH to HS-DSCH - CS + PS - intra-sector, intra-cell - HSDPA

on a separate frequency
Test Purpose:
UTRAN and UE. For this test case, HSDPA is deployed on a separate frequency than DCH.
Pre-requisites:
Configuration: B, C, D or E: 2 RF channels per nodeB sector (considered separate cells 1 and 2). Cell
1 uses RF channel 1 and supports HSDPA. Cell 2 uses RF channel 2 and does not support HSDPA.
A multi service call has been established with cell 2, and the UE is in the following state:
Test Procedure:
Radio/Tests conditions are changed so that the criterion/criteria for triggering a reconfiguration from
DCH to HS-DSCH is/are fulfilled. RNC sends a RADIO BEARER RECONFIGURATION message
instructing the UE to perform an inter-frequency hard handover to cell 1 and start the reception of HS-
DSCH
Test Verification:
Verify that no data is lost and no performance loss on CS call can be noticed during the
reconfiguration to HS -DSCH and the hard handover.
Message flow:

UE NW
1 RADIO BEARER Switches from DCH to HS-

RECONFIGURATION* DSCH with a frequency carrier
change.
COMPLETE*
reconfigured.


Remarks:

Note from editor: in the test case, it is not specified whether the hard handover is blind or with
measurements. Two test cases could be written: one for blind handover and one with inter-frequency
measurements.


F_6.12.5.4.7 Reconfiguration from DCH to HS-DSCH after active set update - CS +PS - inter-RNC
with Iur
Test Purpose:
To check that when the UE has an active CS+PS DCH call and it moves into HSDPA coverage, a
UE, when moving between 2 RNCs with an Iur.
Pre-requisites:
HSDPA
A CS+PS call has been established with cell 4, and the UE is in the following state:
PS+CS-DCCH+DTCH_DCH (state 6-14) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UTRAN then performs a reconfiguration procedure to reconfigure the CS+PS session on HS-
DSCH.
Test Verification:
Verify that no data is lost and that there is no performance loss on CS call during the reconfiguration to
HS-DSCH.


Message flow:

UE NW

by UTRAN.
measurements, as
requested by UTRAN.
(DCCH)
COMPLETE*
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.4.8 Reconfiguration from DCH to HS-DSCH after active set update - CS +PS - inter-RNC
Test Purpose:
UE, when moving between 2 RNCs with an Iur. For this test case, HSDPA is deployed on a separate
frequency than DCH.
Pre-requisites:
A multi service call has been established with cell 4, and the UE is in the following state:
Test Procedure:
(RF channel 2) to be added to the active set.
The UTRAN then performs a reconfi guration procedure to reconfigure the PS session on HS-DSCH,
Test Verification:
Verify that no data is lost during and there is no performance loss on CS call during the reconfiguration
to HS-DSCH.


Message flow:

UE NW

measurements, as
requested by UTRAN.
measurements, as
requested by UTRAN.
cell change.
(DCCH)
COMPLETE*
reconfigured.
Remarks:

2 8.2.2.36
(From
34.123)


F_6.12.5.4.9 Reconfiguration from DCH to HS-DSCH - CS +PS - inter-RNC without Iur (separate
frequencies)
Test Purpose:
UE, when moving between 2 RNCs without Iur.
Pre-requisites:
A CS+PS call has been established with cell 4, and the UE is in the following state:
UE is in PS+CS-DCCH+DTCH_DCH (state 6-14) as specified in clause 7. 4 of TS 34.108
Test Procedure:
for handing the UE over to cell 1 is/are met. RNC initiates the RB reconfiguration procedure to perform
the hard HO and reconfigure the PS session to HS-DSCH.
Test Verification:
HS-DSCH.


Message flow:

UE NW

conditions so that an inter-
RNC HO is triggered
4 Hard handover decision Made by the RNC
COMPLETE*
reconfigured.
Remarks:
Covered prot ocol tests:

1 8.2.2.36
(From
34.123)


F_6.12.5.5.1 CS RB setup with active HS -DSCH reconfiguration from HS -DSCH to DCH
Test Purpose:
Check that when there is an active PS call on HSDPA, the network is able to set up a CS RAB without
dropping the PS session.
Pre-requisites:

(June 2004)
Test Procedure:
A mobile terminating CS call is triggered and PAGING TYPE 2 is sent to the UE. The CS service is
then established. At RB setup, the UTRAN sets up the CS RAB, stops HS-DSCH reception and maps
the PS DTCH on DCH. RLC info parameters may be modified with an RB reconfiguration procedure
after the CS service is established.
Test Verification:
Verify that the CS service can be set up properly

Verify that the network reconfigures the PS DTCH from HS-DSCH to DCH either during the RB setup
procedure or after the CS call has been established.


Message flow:

UE NW
1 PAGING TYPE 2
2 PAGING RESPONSE
(3) (AUTHENTICATION REQUEST)
(4) (AUTHENTICATION RESPONSE)
7 SETUP
8 CALL PROCEEDING
9 RADIO BEARER SETUP CS RAB is set up
11 ALERTING
12 CONNECT
13 CONNECT ACKNOWLEDGE
(14) (RADIO BEARER May be used depending on
RECONFIGURATION) network implementation
(15) (RADIO BEARER
RECONFIGURATION COMPLETE)
Remarks:

1 RRC / Radio Bearer Establishment for transition from CELL_DCH to
B_8.2.1.1
CELL_DCH: Success
2 B_8.1.1.7 RRC / Paging for Connection in connected mode (CELL_DCH)
4 B_10.1.3.4.1 Incoming call / U7 call received / call accepted
5 B_10.1.3.5.1 Incoming call / U8 connect request / CONNECT acknowledged
6 Incoming call / U9 mobile terminating call confirmed / alerting or
B_10.1.3.3.1
immediate connecting


F_6.12.5.5.2 CS RB release in CS+PS on DCH reconfiguration from DCH to HS-DSCH
Test Purpose:
Check that when a CS call is released in CS+PS and that there are resources available for HSDPA,
the network is able to reconfigure the PS session from DCH to HS -DSCH
Pre-requisites:

Test Procedure:
The CS call is terminated by the tester (UE initiated termination). The network should trigger a
reconfiguration of the PS session from DCH to HS-DSCH.
Test Verification:
Verify that the CS service is released properly

Verify that the network reconfigures the PS session from DCH to HS-DSCH either during the RB
release of after the CS call is released.
Message flow:

UE NW
1 DISCONNECT CC
2 RELEASE CC
3 RELEASE COMPLETE CC
4 RADIO BEARER RELEASE RRC
5 RADIO BEARER RELEASE RRC
COMPLETE
(6) (RADIO BEARER May be used depending on
RECONFIGURATION) network implementation
(7) (RADIO BEARER
RECONFIGURATION COMPLETE)


Remarks:

2 RRC / Radio Bearer Release for transition from CELL_DCH to
B_8.2.3.1
CELL_DCH: Success


F_6.12.6.1 Normal transition from cell_DCH to cell_FACH and back to cell_DCH (stop-start
HSDPA)
Test Purpose:
To verify that UE is able to stop and start correctly HSDPA call, and discard all HSDPA informations
when going to cell_FACH state.
Pre-requisites:
Configuration: A,B, C, D, E,. Node B support HSDPA

One cell A
UE support HSDPA
A call has been established with cell A, and the UE is in the following state:
UE is in PS-DCCH+DTCH_HS -DSCH. UE has a radio bearer mapped on HS -DSCH established.
UE is able to keep all mandatory parameters.
Test Procedure:
Step 1
Stop any data transfer and wait until the UTRAN performs a reconfiguration procedure to reconfigure
the PS session from HS-DSCH to FACH.
Make a short ping (that dont trigger a transition to cell_DCH), to verify that UE has effectively stop
HSDPA.
Step 2
Start a data transfer.
The UTRAN performs a reconfiguration procedure to reconfigure the PS session from CELL_FACH to
HS-DSCH. PS data transmission start again.
Test Verification:
Step 1
Verify that UE clear all informations related to HSDPA (HS-PDSCH configuration, H-RNTI,). This
check is optional depending on capacity of trace tool of UE.
Verify that UE behave as if HSDPA have never been available.
Verify that ping is OK while UE stays in cell_FACH state.
Step 2
Verify that UE is able to move to CELL_DCH state, resume HS-DSCH reception, and reconfigures
properly, i.e. that the RLC, TrCH and PhyCH parameters specified in the reconfiguration message are
used.
Verify that data transfer is retrieved.


Message Flow:

UE NW
Stop data transfer
1 RADIO BEARER Indicating transition to cell_FACH state
RECONFIGURATION*
2 RADIO BEARER
RECONFIGURATION
COMPLETE *
Short ping as verification
Waiting period
Data transfer start
3 RADIO BEARER Start of HS -DSCH reception and transition to
RECONFIGURATION* CELL_DCH state
4 RADIO BEARER
RECONFIGURATION
COMPLETE *
Remarks:
reconfigured.
Related protocol test 8.2.2.37


F_6.12.6.2 Normal transition from cell_PCH to cell_DCH and back to cell_PCH (start-stop
HSDPA)
Test Purpose:
when going to cell_PCH state.
Pre-requisites:
One cell A
UE support HSDPA
Test Procedure:
Step 1
Stop data transfer, and wait until the UTRAN performs a reconfiguration procedure to reconfigure the
PS session from HS -DSCH to PCH.
Step 2
Restart a data transfer.
The UTRAN performs a reconfiguration procedure to reconfigure the PS session from CELL_PCH to
CELL_FACH and to HS -DSCH. (send data downlink for exemple).
Test Verification:
Step 1
Verify that UE clears all informations related to HSDPA (HS-PDSCH configuration, H-RNTI,). This
Step 2
used.


Message Flow:

UE NW
Stop data transmission
1 RADIO BEARER Indicating transition to cell_PCH state
RECONFIGURATION*
2 RADIO BEARER
RECONFIGURATION
COMPLETE *
Start Data transfer
RECONFIGURATION*
4 RADIO BEARER
RECONFIGURATION
COMPLETE *
6 RADIO BEARER
RECONFIGURATION
COMPLETE *
Add a transition to FACH
Remarks:
reconfigured.
none


F_6.12.6.3 Normal transition from URA_PCH to cell_DCH and back to URA_PCH (start-stop
HSDPA)
Test Purpose:
when going to URA_PCH state.
Pre-requisites:
One cell A
UE support HSDPA
Test Procedure:
Step 1
Stop data transfer, and wait until the UTRAN performs a reconfiguration procedure to reconfigure the
PS session from HS -DSCH to URA_PCH.
Step 2
Restart a data transfer.
The UTRAN performs a reconfiguration procedure to reconfigure the PS session from URA_PCH to
CELL_FACH and to HS -DSCH. (send data downlink for exemple).
Test Verification:
Step 1
Verify that UE clears all informations related to HSDPA (HS-PDSCH configuration, H-RNTI,). This
Step 2
used.


Message Flow:

UE NW
Stop data transmission
1 RADIO BEARER Indicating transition to URA_PCH state
RECONFIGURATION*
2 RADIO BEARER
RECONFIGURATION
COMPLETE *
Start Data transfer
RECONFIGURATION*
4 RADIO BEARER
RECONFIGURATION
COMPLETE *
6 RADIO BEARER
RECONFIGURATION
COMPLETE *
Remarks:
reconfigured.
none


F_6.12.7.1 Inter-Frequency handover from HSDPA cell to another HSDPA cell with prior
measurements on the target frequency
Purpose:
To verify that the UE in PS call on a HSDPA cell

performs compressed mode measurements on the target frequency
performs Inter-frequency handover when the criteria is met and is directed by the network
using Reconfiguration message
UTRAN and UE will be able to maintain the call on new cell after successful handover.
Pre-requisites:
Configuration: B, C, D or E (2 cells: cell 1 using UTRA RF channel 1, cell 2 using UTRA RF

channel 2)
UE and NW are HSDPA capable
message (or SIB#11). Inter-Frequency neighbour list of cell 1 contains cell 2
A PS data call has been established on cell 1 and the UE is in the following state:
PS_DCCH+DTCH_HS-DSCH (state 6-17) as specified in 7.4 of TS 34.108 v5.1.0
Test Procedure:
Radio conditions are modified such that NW activates compressed mode measurements on
the target frequency after receiving measurement reports from UE
Radio conditions are still modified such that UE sends measurement report to the network to
trigger Inter-frequency handover
NW sends Reconfiguration message to the UE to trigger Inter-frequency handover. The UE
configures layer 1 to begin reception on the new frequency.
After receiving confirmation from its physical layer, UE sends Reconfiguration complete to
NW.
Test Verification:
Verify that
The monitored message sequence is correct
HS-DSCH reception is not affected after handing over to target cell
No data is lost during and after the handover


Message Flow:
UE NW
PS call has been previously established Data transfer is on going

test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:
Transport channel or Physical Channel Reconfiguration messages can also be used for triggering the
handover


F_6.12.7.2 Inter-Frequency handover from HSDPA cell to another HSDPA cell without prior
measurements on the target frequency
Purpose:

performs Inter-frequency handover when directed by the network using Reconfiguration
message without performing any measurements on the target frequency (blind handover)
Pre-requisites:

channel 2)
Test Procedure:
Radio conditions are modified such that network sends Reconfiguration message to the UE to
trigger Inter-frequency handover. The UE configures layer 1 to begin reception on the new
frequency.
NW.
Test Verification:
Verify that


Message Flow:
UE NW

NW configures Intra-
Frequency measurements
The tester reduces the power
of serving cell
MEASUREMENT REPORT UE reports measurements on
serving cell
Inter-frequency handover decision Made by the RNC
RADIO BEARER RECONFIGURATION RRC With parameters of
(DCCH) cell2
RADIO BEARER RECONFIGURATION RRC
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.3 Inter-frequency handover to HSDPA cell, Compressed Mode with UE in softer HO (2

legs) prior to Hard Handover
Purpose:
To verify that the UE in softer handover with 2 active legs during PS call
Pre-requisites:
Configuration: C, D or E (3 cells: cell 1 & 2 using UTRA RF channel 1, cell 3 using UTRA RF
channel 2)
message (or SIB#11). Inter-Frequency neighbour list of cells 1 and 2 contains cell 3
UE has cells 1 and 2 in softer handover
Test Procedure:
Radio conditions are modified such that NW adds cells 1 and 2 to the active set
Radio conditions are still modified such that NW activates compressed mode measurements
on the target frequency and triggers Inter-frequency handover to cell 3 after receiving
measurement reports from UE
NW.
Test Verification:
Verify that


Message Flow:
UE NW
PS call has been previously established. UE Data transfer is on going

has cells 1 and 2 in active set
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.4 Inter-Frequency handover from HSDPA cell to another HSDPA cell including SRNS
relocation
Purpose:

performs Inter-frequency handover to a cell on another RNC when the criteria is met and is
directed by the network using Reconfiguration message. This procedure includes SRNS
relocation
Pre-requisites:
Configuration: E (2 cells: cell 1 on NodeB -1 using UTRA RF channel 1, cell 1 on NodeB -2

message (or SIB#11). Inter-Frequency neighbour list of cell 1 (NodeB-1) contains cell 1
(NodeB -2)
A PS data call has been established on cell 1 (NodeB-1) and the UE is in the following state:
Test Procedure:
NW sends Reconfiguration message to the UE to trigger Inter-frequency handover to the
target cell on second RNC. This procedure includes SRNS relocation. The UE configures
layer 1 to begin reception on the new frequency.
NW.
Test Verification:
Verify that


Message Flow:
UE NW

test procedure.
by UTRAN.
3 Inter-frequency handover decision Made by the SRNC
(DCCH) cell1 (NodeB-2)
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.5 Multi-Service: Inter-Frequency handover from HSDPA cell to another HSDPA cell with
prior measurements on the target frequency
Purpose:
To verify that the UE in multi-service (AMR+PS) call on a HSDPA cell

Pre-requisites:

channel 2)
message (or SIB#11). Inter-Frequency neighbour list of cell 1 contains cell 2
A multi-service (AMR+PS) call has been established on cell 1 and the UE is in the following
state: CS+PS_DCCH+DTCH_HS -DSCH
Test Procedure:
NW.
Test Verification:
Verify that
Voice quality is not affected


Message Flow:
UE NW
Multi-service (AMR+PS) call has been Data transfer is on going

previously established
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.6 Multi-Service: Inter-Frequency handover from HSDPA cell to another HSDPA cell
without prior measurements on the target frequency
Purpose:

performs Inter-frequency handover when directed by the network using Reconfiguration
message without performing any measurements on the target frequency (blind handover)
Pre-requisites:

channel 2)
Test Procedure:
Radio conditions are modified such that network sends Reconfiguration message to the UE to
trigger Inter-frequency handover. The UE configures layer 1 to begin reception on the new
frequency.
NW.
Test Verification:
Verify that


Message Flow:
UE NW

NW configures Intra-
Frequency measurements
The tester reduces the power
of serving cell
MEASUREMENT REPORT UE reports measurements on
serving cell
Inter-frequency handover decision Made by the RNC
RADIO BEARER RECONFIGURATION RRC With parameters of
(DCCH) cell2
RADIO BEARER RECONFIGURATION RRC
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.7 Multi-Service: Inter-frequency handover to HSDPA cell, Compressed Mode with UE in

softer HO (2 legs) prior to Hard Handover
Purpose:
To verify that the UE in softer handover with 2 active legs during multi-service (AMR+PS) call
Pre-requisites:
Configuration: C, D or E (3 cells: cell 1 & 2 using UTRA RF channel 1, cell 3 using UTRA RF
channel 2)
message (or SIB#11). Inter-Frequency neighbour list of cells 1 and 2 contains cell 3
UE has cells 1 and 2 in softer handover
Test Procedure:
Radio conditions are modified such that NW adds cells 1 and 2 to the active set
Radio conditions are still modified such that NW activates compressed mode measurements
on the target frequency and triggers Inter-frequency handover to cell 3 after receiving
measurement reports from UE
NW.
Test Verification:
Verify that


Message Flow:
UE NW

previously established. UE has cells 1 and 2
in active set
test procedure.
by UTRAN.
(DCCH) cell3
COMPLETE (DCCH)
Remarks:
handover


F_6.12.7.8 Multi-Service: Inter-Frequency handover from HSDPA cell to another HSDPA cell
including SRNS relocation
Purpose:

performs Inter-frequency handover to a cell on another RNC when the criteria is met and is
directed by the network using Reconfiguration message. This procedure includes SRNS
relocation
Pre-requisites:
Configuration: E (2 cells: cell 1 on NodeB -1 using UTRA RF channel 1, cell 1 on NodeB -2

message (or SIB#11). Inter-Frequency neighbour list of cell 1 (NodeB-1) contains cell 1
(NodeB -2)
A multi-service (AMR+PS) call has been established on cell 1 (NodeB-1) and the UE is in the
following state: CS+PS_DCCH+DTCH_HS-DSCH
Test Procedure:
NW sends Reconfiguration message to the UE to trigger Inter-frequency handover to the
target cell on second RNC. This procedure includes SRNS relocation. The UE configures
layer 1 to begin reception on the new frequency.
NW.
Test Verification:
Verify that


Message Flow:
UE NW

test procedure.
by UTRAN.
3 Inter-frequency handover decision Made by the SRNC
(DCCH) cell1 (NodeB-2)
COMPLETE (DCCH)
Remarks:
handover


F_6.12.8.1 Active Set Update in the presence of an active HS-DSCH / Soft handover on DCH /
Addition of one radio link / PS only
Test Purpose:
To check that in the presence of an active HS -DSCH, the RNC triggers an active set update
procedure when a cell satisfies the criterion for being added in the UE active set.
Pre-requisites:
Configurations: D or E
Cell 1 and Cell 2 are both HSDPA cells of different NodeBs from one RNC.
UE is HSDPA capable
SIB#11)
Test procedure:
criterion to be added in the active set, but does not become the primary cell. RNC sends ACTIVE SET
UPDATE to UE, with parameters of cell 2 to be added to the active set. The UE configures layer 1 to
begin reception for the additional radio link. After the UE receives confirmation from its physical layer,
an ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception is not affected by active
set update procedure. No data is lost.
Message Flow:

UE NW
that cell 2 satisfy the criterion to be added
to the active set.
as requested by UTRAN. (e.g. event 1a)
4 soft handover decision by UTRAN
6 ACTIVE SET UPDATE RRC
COMPLETE(DCCH)





Deletion of one radio link / PS only
Test Purpose:
procedure when a cell satisfies the criterion for being deleted from the UE active set.
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells of different NodeBs from one RNC
UE is HSDPA capable
SIB#11)
A call has been established. Cell 1 and Cell 2 are both in the Active Set. The HSDPA call is connected
to Cell 1, and the UE is in the following state:
Test procedure:
criterion to be removed from the active set RNC sends ACTIVE SET UPDATE to UE, with parameters
of cell 2 to be removed from the active set. The UE re-configures layer 1 to stop reception for the
removed radio link. After the UE receives confirmation from its physical layer, an ACTIVE SET
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception is not affected by active
Message Flow:

UE NW
that cell 2 satisfies the criterion to be
as requested by UTRAN. (e.g. event 1b)
4 Radio link removal
decision by UTRAN
COMPLETE(DCCH)





Deletion of one radio link of serving cell / PS only
Test Purpose:
procedure when a cell satisfies the criterion for being deleted from the UE active set incl. immediate
serving cell change as radio link to serving cell got lost.
Pre-requisites:
Cell 1 and Cell 2 are both HSDPA cells of different NodeBs from one RNC
UE is HSDPA capable
SIB#11)
Test procedure:
criterion to be removed from the active set. RNC sends ACTIVE SET UPDATE to UE, with parameters
of cell 1 to be removed from the active set. The UE re-configures layer 1 to stop reception for the
removed radio link. After the UE receives confirmation from its physical layer, an ACTIVE SET
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception recovers after active set
update procedure / serving cell change procedure, no data is lost.


Message Flow:

UE NW
as requested by UTRAN. (e.g. event 1b,
or event 1d followed by 1b)
4 RADIO BEARER Including new HSDPA configuration (and
*RECONFIGURATION (DCCH) Activation Time if synchronized Cell
Change)
5 RADIO BEARER *
(DCCH)
6 Radio link removal decision by UTRAN
COMPLETE(DCCH)
* Alternatively Transport Channel reconfiguration or Physical Channel reconfiguration could be used.
The reconfiguration of the HS -DSCH RL can also be performed after the active set update procedure.



Combined addition and deletion of a radio link / PS only
Test Purpose:
procedure when a cell satisfies the criterion for being added in the UE active set, and another satisfies
the criterion for being removed.
Pre-requisites:
Cell 1, 2 and 3 are all HSDPA cells
UE is HSDPA capable
SIB#11)
Test procedure:
criterion to be added to the active set (but does not become the primary cell) and cell 2 satisfies the
criterion to be removed from the Active Set (see pre-requisites). RNC sends ACTIVE SET UPDATE to
UE, with parameters of cell 3 being added and parameters of cell 2 to be removed from the active set.
The UE re-configures layer 1 to stop reception for the removed radio link and start reception of the
added radio link. After the UE receives confirmation from its physical layer, an ACTIVE SET UPDATE
COMPLETE message is sent to the UTRAN.
Test Verification:
Verify that the monitored message sequence is correct. HS-DSCH reception is not impacted by active


Message Flow:

UE NW
removed from and cell 3 to be added to
the active set.
as requested by UTRAN. (e.g. event 1a+
1b or event 1c)
4 soft handover decision by UTRAN
COMPLETE(DCCH)

2 B_8.3.4.2a RRC / Active set update in softer handover: Radio Link removal


F_6.12.9.1 Inter-RAT Cell Change Order from UTRAN to GPRS/CELL_DCH/Success (stop of

HS-DSCH reception)
Test Purpose:
To test that the UE shall be able to receive a CELL CHANGE ORDER FROM UTRAN message in
CELL_DCH state when Radio bearers are mapped to HSDSCH channels and perform a cell change
to another RAT, even if no prior UE measurements have been performed on the target cell and HS -
PDSCH channels are active. The UE regards the procedure as completed when it has received a
successful response from the target RAT, e.g. in case of GSM when it received the response to a
(PACKET) CHANNEL REQUEST in the new cell.
Pre-requisites:
Configuration: F (2 cells - Cell 1 is UTRAN, Cell 2 is GPRS)

All cells belong to the same PLMN and location area.
All UEs which support FDD, HS-PDSCH and GSM.
UE: PS-DCCH+DTCH_DCH_HSDCH (State 6-17) in cell 1 as specified in clause 7.4 of TS 34.108,
one PS domain RAB is established.
Test Procedure:
The UE is in CELL_DCH state and has a radio bearer mapped on HS -DSCH established. The NW
starts GPRS cell, then sends CELL CHANGE ORDER FROM UTRAN indicating the target cell
description, GPRS cell, to the UE through DCCH of the serving UTRAN cell. After the UE receives the
command it shall configure itself accordingly and switch to the new channel on the target GPRS cell.
The NW checks whether the cell change is performed by checking that the UE receives a successful
response to the CHANNEL REQUEST message from the NW through GPRS cell. The UE sends a RA
UPDATE REQUEST message to indicate that the UTRAN UE context needs to be transferred to
GPRS.
Test Verification:
After step 3 the UE shall transmit a CHANNEL REQUEST message on RACH.

Upon indication of the UE having successfully completed the cell change order, UTRAN should
release the radio connection and remove all context information for the concerned UE.


Message Flow:
UE NW
1 UE The NW brings the UE into PS-
DCCH+DTCH_DCH_HSDSCH in cell 1
2 NW The NW configures cell 2 as a GSM cell with GPRS
enabled
3 CELL CHANGE ORDER FROM Send on cell 1 (UTRAN cell) and the message indicates:
UTRAN
the target cell description for GPRS.
4 UE The UE accepts the cell change command and switches
to the GPRS cell specified in the CELL CHANGE
ORDER FROM UTRAN
5 CHANNEL REQUEST The NW receives this burst on the RACH of cell 2 to
establish temporary block flow (GPRS cell). It implies that
the UE has switched to GPRS cell.
6 IMMEDIATE ASSIGNMENT Uplink dynamic allocation. Sent on AGCH.
7 ROUTING AREA UPDATE
REQUEST


F_6.12.9.2 Inter-RAT Cell Change Order from UTRAN to GPRS/CELL_DCH/Failure (Physical

channel Failure, stop of HS-DSCH reception)
Test Purpose:
To verify that when UE received CELL CHANGE ORDER FROM UTRAN message in CELL_DCH
state and if the establishment of the connection to the other RAT failed due to expiry of timer T309
prior to the successful establishment of a connection to the target RAT.
Pre-requisites:

Test Procedure:
The UE is in CELL_DCH state and has a radio bearer mapped on HS -DSCH established. The NW
starts GPRS cell, then sends CELL CHANGE ORDER FROM UTRAN indicating the target cell
description, GPRS cell, to the UE through DCCH of the serving UTRAN cell. The UE starts the timer
T309. After the UE receives the command it shall configure itself accordingly but cannot complete the
cell change, as NW does not respond to the CHANNEL REQUEST message transmitted by UE till the
expiry of T309 timer. The NW checks that the cell change has failed by checking that the UE transmits
the CELL CHANGE ORDER FROM UTRAN FAILURE message to the NW in UTRAN cell.
Test Verification:
In step 5 the UE shall transmit a CHANNEL REQUEST message on RACH.

In step 7 the NW shall receive CELL CHANGE ORDER FROM UTRAN FAILURE message on the old


Message Flow:
UE NW
1 UE The NW bring the UE into PS-DCCH _DCH_HSDSCH
(State 6-17) in cell 1
2 NW The NW configures cell 2 as a GSM cell with GPRS
enabled
UTRAN
the target cell description for GSM/GPRS.
4 UE UE starts the timer T309. The UE accepts the cell change
command and switches to the GPRS specified in the
CELL CHANGE ORDER FROM UTRAN
5 CHANNEL REQUEST The NW receives this burst on RACH of cell 2 (GPRS
cell) to establish temporary block flow
6 NW does not respond to the channel request.
UE sends M + 1 CHANNEL REQUEST messages
The NW does not transmit a response and wait for T309
timer to expire.
7 CELL CHANGE ORDER FROM The NW receives the message on the old channel of
UTRAN FAILURE UTRAN cell.


F_6.12.9.3 Inter-RAT cell change order from UTRAN/To GPRS/CELL_FACH/No RAB

established/Success
Test Purpose:
CELL_FACH state and perform a cell change to another RAT, when no RABs are established.
Pre-requisites:

All cells belong to the same PLMN and different location area, routing area.
Test Procedure:
The NW starts the UTRAN cell and the UE is triggered to make an MO PS call. After the NW receives
SERVICE REQUEST message, the NW starts GPRS cell, then sends CELL CHANGE ORDER
FROM UTRAN indicating the target cell description. After the UE receives the command it shall
configure itself accordingly and switch to the new channel on the target GPRS cell. The NW checks
whether the cell change is performed by checking that the UE sends a PACKET CHANNEL
REQUEST through GPRS cell. The UE sends an RA UPDATE REQUEST message to indicate that
the UTRAN UE context needs to be transferred to GPRS.
Test Verification:
Upon indication of the UE having successfully completed the cell change order, UTRAN should
release the radio connection and remove all context information for the concerned UE.


Message Flow:
UE NW
1 UE Trigger the UE to initiate an MO PS call
2 SERVICE REQUEST
3 CELL CHANGE ORDER FROM Sent on cell 1 (UTRAN cell) and the message indicates:
UTRAN
ORDER FROM UTRAN
5 PACKET CHANNEL REQUEST The NW receives this burst on PRACH of cell 2 (GPRS
cell) to establish temporary block flow. It implies that the
UE has switched to GPRS cell.
6 PACKET UPLINK ASSIGNMENT Uplink dynamic allocation
Sent on PAGCH.
REQUEST


IMS_SO_1 Successful mobile origination procedure mobile is not located in its HPLMN traffic
class used is interactive /background
Test Purpose:
To check that a IMS session can be established successfully when the UE is not located in its home
PLMN.
Pre-requisites:
Configuration A
Network1: UTRAN1 Configuration A and IMS Core Network 1
UE1 (calling UE) is IMS registered on cell 1 and IMS core network is connected to this UTRAN1

UE2 (called UE) is IMS registered on cell 2 and IMS core network is connected to this UTRAN
Both IMS core network are connected.
UE supports SIP
Test Procedure:
Initiate an IMS procedure, the traffic class used is interactive / background.
Test Verification:
IMS session was initiated successfully by performing traffic.
Make sure throughput and the round trip delay is not affecting the application.


Message flow:

UE NW
1 UE is IMS registered
and PDP Context is activated
2 -> SIP: Invite
3 <- SIP: Trying
4 <- SIP: Session Progress
5 -> SIP: Prack
6 Resource Reservation
7 <- SIP: Ok
8 -> SIP: Update
9 <- SIP: Ok
10 <- SIP: Ringing
11 -> SIP: Prack
12 <- SIP: Ok
13 Approval of QOS commit
14 <- SIP: Ok
15 -> SIP: Ack


IMS_SO_2 Successful mobile origination procedure mobile is not located in its HPLMN traffic
class used is PS conversational/streaming
Test Purpose:
To check that a IMS session can be established successfully when the UE is not located in its home
PLMN.
Pre-requisites:
Configuration A

UE supports SIP
Test Procedure:
Initiate an IMS procedure the traffic class used is Ps conversational..
Test Verification:
IMS session was initiated successfully by performing traffic.


Message flow:

UE NW
2 -> SIP: Invite
3 <- SIP: Trying
5 -> SIP: Prack
7 <- SIP: Ok
8 -> SIP: Update
9 <- SIP: Ok
10 <- SIP: Ringing
11 -> SIP: Prack
12 <- SIP: Ok
14 <- SIP: Ok
15 -> SIP: Ack


IMS_SO_3 Unsuccessful mobile origination procedure Failure in termination procedure
Test Purpose:
To check that when called party is not reachable for some reasons. UE is handling the failure correctly
and the resources are properly released.
Pre-requisites:
UE supports SIP
Configuration A

Test Procedure:
To initiate the failure case in the termination procedure The called party may be, for example
busy. But different other reasons can lead to a failure in the termination procedure, such as
those different Sip error causes :
- 486 (Busy Here)
- 403 (Forbidden)
- 480 (Temporarily Unavailable)
- 486 (Busy Here).
Initiate an IMS procedure.
Test Verification:
Verify that calling party received busy message and all resources are properly released


Message flow:

UE NW
2 -> SIP: Invite
3 <- SIP: Trying
5 -> SIP: Prack
6 Ressource Reservation
7 <- SIP: Ok
8 -> SIP: Update
9 <- SIP: Ok
10 <- SIP: Ringing
11 -> SIP: Prack
12 <- SIP: Ok
13 SIP: Revoke QOS ressource
14 <- SIP: Error 486 (Busy Here),403
(Forbidden), 480 (Temporarily
Unavailable), 486 (Busy Here).
15 -> SIP: Ack


IMS_SO_4 Unsuccessful mobile origination procedure Session abandoned or resource

failure
Test Purpose:
To check that when called party is not reachable for some reasons. UE is handling the failure and the
resources are properly released.
Pre-requisites:
Configuration A

Test Procedure:
Initiate an IMS procedure, and then initiate a cancel from the UE.
Test Verification:
UE is able to trigger the cancel, and all the resources are properly released.


Message flow:

UE NW
2 -> SIP: Invite
3 <- SIP: Trying
5 -> SIP: Prack
7 <- SIP: Ok
8 -> SIP: Update
9 <- SIP: Ok
10 <- SIP: Ringing
11 -> SIP: Prack
12 <- SIP: Ok
13 -> SIP: Cancel
14 <- SIP: Ok
15 Revoke of QOS commit
16 <- SIP: Requested Terminated
17 -> SIP:ACK


IMS_ST_1 Successful Mobile Termination Procedure mobile is not located in its HPLMN
Test Purpose:
To check that a IMS session can be established with a terminating mobile when it is not in its home
PLMN.
Pre-requisites:
Configuration A
UE1 (calling UE) is IMS registered on cell 1 and IMS core network is connected to this UTRAN1. The
PLMN from Network1 is different from the UE HPLMN

Test Procedure:
Initiate an IMS procedure to the called UE.
Test Verification:
IMS session was initiated correctly by performing traffic.
Message flow:

UE NW
2 <- SIP :Invite
3 -> SIP: Trying
4 -> SIP: Session Progress
5 <- SIP: Prack
7 -> SIP: Ok
8 <- SIP: Update
9 -> SIP: Ok
10 -> SIP: Ringing
11 <- SIP: Prack
12 -> SIP: Ok
14 -> SIP: Ok
15 <- SIP: Ack


IMS_ST_2 Unsuccessful Mobile Termination Procedure due to UE-detected failure/resource

failure
Test Purpose:
To check that when a MO initiates an IMS procedure which is failing due an error detected in the
termination procedure.( user busy) messages are properly handled by calling UE. Resources are
correctly released.
Pre-requisites:
UE supports SIP
Configuration A

Test Procedure:
Called UE is busy.
Initiate a call and then cancel the call
Test Verification:
Message flow:

UE NW
2 <- SIP :Invite
3 -> SIP: Trying
5 <- SIP: Prack
7 <- SIP: Update
8 -> SIP: Ringing
9 <- SIP: Prack
10 -> Error (cause user busy)
11 <- SIP: Ack


IMS_ST_3 Unsuccessful Mobile Termination Procedure due to origination failure
Test Purpose:
To check that when a MO initiates a IMS procedure which is failing due an error detected in the
origination procedure, messages are properly handled by both UEs. Resources are correctly
released.
Pre-requisites:
UE supports SIP
Configuration A

Test Procedure:
Initiate a call and then cancel the call
Test Verification:


Message flow:

UE NW
2 <- SIP :Invite
3 -> SIP: Trying
5 <- SIP: Prack
7 -> SIP: Ok
8 <- SIP: Update
9
10 -> SIP: Ringing
11 <- SIP: Prack
13 <- SIP: Cancel
14 -> SIP: Ok
15 -> Request Terminated
16 <- SIP: Ack


IMS_ST_4 Unsuccessful Mobile Termination Procedure due Mobile termination, roaming,

terminal is out of radio coverage
Test Purpose:
To check that when a MO initiates an IMS procedure which is failing due an error detected in the
termination procedure (in this particular case the called UE out of of radio coverage) messages are
properly handled by both UEs. Resources are correctly released.
Pre-requisites:
UE supports SIP


Test Procedure:
To initiate the failure case in the termination procedure. The called party is out of radio
coverage, modify the radio condition so the called UE doesnt received any signal from Cell2
Initiate an IMS procedure.
Test Verification:
Verify that calling party received message and all resources are properly released


Message flow:

UE NW
2 <- SIP :Invite
3 -> SIP: Trying
5 <- SIP: Prack
7 -> SIP: Ok
8 <- SIP: Update
9 -> SIP: Ok
10 -> SIP: Ringing
11 <- SIP: Prack
12 -> SIP: Ok
14 -> SIP: Error
15 <- SIP: Ack


IMS_SR_1 Mobile terminal initiated session release
Test Purpose:
The purpose of this test is to verify that the mobile terminal initiated session release is completed
successfully.
Pre-requisites:
Configurations: Any
IMS capable UE
GPRS Attach procedure is performed and a PDP context is activated to carry the IMS signalling.
UE is registered with an S-CSCF in its home network.
UE has established successful IMS session including setting up a Secondary [PB1] PDP context for the
multimedia session.
Test Procedure:
Initiate session release from the MS
Test Verification:
Message flow:

UE NW
1 UE UE initiates IMS session
release
2 --> BYE[PB2] SIP
3 --> DEACTIVATE PDP CONTEXT REQUEST SM UE initiates the release
of the PDP context for IMS
traffic
deactivation
7 <-- 200 OK SIP
[PB3]of the PDP context for
IMS signalling
deactivation


Remarks:
In steps 1 and 2, UE hangs up which generates a SIP BYE request from the UE to the P-CSCF.
Steps 3 and 4 may take place before or after Step 2. UE initiates the release of the PDP context for
IMS traffic. The GPRS subsystem releases the PDP context. The IP network resources that had been
reserved for the message receive path to the mobile for this session are now released. This is initiated
from the GGSN. The GPRS subsystem responds to the UE with Deactivate PDP context accept
message. The P-CSCF removes the authorization for resources that had previously been issued for
this endpoint for this session. This step will also result in a release indication to the GPRS subsystem
to confirm that the IP bearers associated with the session have been deleted.
In steps 5 and 6, RNC will release the radio bearer associated with the Secondary PDP context for
IMS traffic.
In step 7, the P-CSCF forwards the 200 OK SIP response to the UE.
Optional steps 8 to 13 depend on UE configuration: UE releases the PDP context used for carrying the
IMS signalling and UE goes to RRC IDLE state.
Reference:
3GPP TS 23.228, section 5.10

3GPP TS 24.228, section 8


IMS_SR_2 PSTN/ Network initiated session release
Test Purpose:
The purpose of this test is to verify that the PSTN/ Network initiated session release is completed
successfully.
Pre-requisites:
Configurations: Any
IMS capable UE
GPRS Attach procedure is performed and a PDP context is activated to carry the IMS signalling.
UE is registered with an S-CSCF in its home network.
UE has established successful IMS session including setting up a Secondary PDP context for the
multimedia session.
Test Procedure:
Trigger PSTN/ Network initiated session release by one of the following:
PSTN initiated session release:

This can be triggered when PSTN party (involved in an IMS session with the UE) hangs up, which
generates an ISUP REL message to the MGCF. The MGCF generates BYE request towards the
UE to notify the mobile that the far end party has disconnected.
S-CSCF initiated session release:

This can be triggered when S-CSCF decides to terminate the session due to administrative
reasons (e.g. prepaid) or due to service expiration. In this case, S-CSCF generates BYE request
towards the called and calling user.
P-CSCF initiated session release:

This can be triggered when one of the two UEs (involved in an IMS session with each other)
triggers a bearer release e.g. by UE power down. It can also be triggered in the event of loss of
radio coverage for a PDP context with streaming or conversational class (In this case, the
maximum bitrate of the GTP tunnel between SGSN and GGSN is modified to 0 kbit/s in up- and
downlink direction. The P-CSCF/PDF receives an indication of PDP context modification). Upon
receipt of an indication that the radio interface resources/ radio coverage are no longer available
for the served user for whom an ongoing session exists, the P-CSCF will release the related
dialog by generating BYE request towards the other UE.
Application Server initiated session release:

If needed, the application server may initiate release requests to the entities involved in the
dialogs the application server manages. Application servers may initiate release requests in either
user agent or B2BUA mode. The AS shall simultaneously send the BYE request for both dialogs
managed by the B2BUA.
Test Verification:


Message flow:

UE NW
1 NW PSTN/ Network initiates IMS
session release
2 <-- BYE SIP
3 --> 200 OK SIP (message sequence not
defined, could be between 3
and 8)
4 <-- DEACTIVATE PDP CONTEXT REQUEST SM NW initiates the
release of the PDP context
for IMS traffic
5 --> DEACTIVATE PDP CONTEXT ACCEPT SM - Accept PDP context
deactivation
of the PDP context for IMS
signalling[PB4]
deactivation
Remarks:
In steps 1 and 2, PSTN/ Network initiates IMS session release. The P-CSCF removes the
authorization for resources that had previously been issued for this endpoint for this session. This step
will also result in a release indication to the GPRS subsystem to confirm that the IP bearers
associated with the session have been deleted. The P-CSCF forwards the SIP BYE request to the UE.
In step 3, UE responds with an acknowledgement, the SIP 200 OK message, which is sent back to the
P-CSCF. Please note this message is shown as an example only. It could be sent anywhere between
step 3 and 8.
In steps 4 and 5, Network initiates the release of the PDP context for IMS traffic. The GPRS
subsystem releases the PDP context. The IP network resources that had been reserved for the
message receive path to the mobile for this session are now released. This is initiated from the GGSN.
UE responds with Deactivate PDP context accept message.
In steps 6 and 7, RNC will release the radio bearer associated with the Secondary PDP context for
IMS traffic.
Optional steps 8 to 13 depend on UE configuration: UE releases the PDP context used for carrying the
IMS signalling and UE goes to RRC IDLE state.
Note :
Perform this test case for all network initiated session release scenarios mentioned in this Test
Procedure.
Reference:
3GPP TS 23.228, section 5.10
3GPP TS 24.228, section 8


IMS_REG_1 Successful initial registration
Test Purpose:
To check the registration signalling can be established successfully when the UE requests to register
the users SIP URI with a S-CSCF in the home network. This request is routed to the P-CSCF
because it is the only SIP known to the UE
Pre-requisites:
Configuration A
Network1: UMTS network plus IMS Subsytem
IMS core network is connected to this UTRAN1
UE support SIP
Test Procedure:
Activate a PDP context.

Initiate a Register Session.
Test Verification:
1. Verify that the UE is successfully registered.

2. Check the Request-URI in the method name, REGISTER.
3. Check the WWW-Authenticate field in 401 Unauthorized method.
4. Verify that the Authorization information are fulfilled in the second REGISTER request sent
from UE to P-CSCF
Message flow:

UE NW
1 GPRS Attach procedure;

PDP context Establishment and
P-CSCF Discovery
2 -> SIP: Register
3 <- SIP: 401 Unauthorized
4 -> SIP: Register
5 <- SIP:200 Ok


IMS_REG_2 Successful re-registration without authentication
Test Purpose:
To check the re-registration signalling can be established successfully when the

The registration expires in the UE. This request is sent to the same P-CSCF, which the UE initially
registered.
Pre-requisites:
Configuration A
UE support SIP
The same PDP Context allocated during the initial registration scenario is still used for re-
registration.
Test Procedure:
Activate a PDP context.

The registration expires in the UE.
Initiate a Re-register session.
Test Verification:

2. Verify that the Authorization information are fulfilled in the REGISTER request sent from UE
to P-CSCF
Message flow:

UE NW

P-CSCF Discovery
UE is IMS registered
2 -> SIP: Register
3 <- SIP:200 Ok


IMS_REG_3 Successful re-registration with authentication
Test Purpose:
In This scenario, the UE and the P-CSCF has a set of SAs and the SIP messages are protected using
the established SAs (security association) from previously success authenticated registration
procedure.
Pre-requisites:
Configuration A
UE support SIP
The re-registration can be triggered, e.g., by registration timer expiration.
Test Procedure:
The registration and the SA lifetime expires in the UE.

Initiate a Re-register session.
Test Verification:

2. Check the SAold in the method name, REGISTER.
3. Check the WWW-Authenticate field in 401 Unauthorized method.
4. Check the SAtmp in the second REGISTER request sent from UE to P-CSCF.
5. verify the OK message sent back to the UE.
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register UE was already
registered but
registration timed out
4 -> SIP: Register
5 <- SIP:200 Ok


IMS_REG_4 Successful user initiated de-registration without authentication
Test Purpose:
This scenario is triggered when the subscriber powers off and does not go off until the registration
transaction is completed. An explicit de-registration request (expires header is set to 0) is sent.
Pre-requisites:
Configuration A
UE support SIP
It assumed the UE and P-CSCF has a set of SAs established and the SIP messages are
protected.
Test Procedure:
UE is registered.
Switch off the UE.
Test Verification:
1. Verify the expire parameters and SA old info in BYE message.

2. Verify the 200 OK message sent back to the UE
3. Verify that the UE is not registered anymore
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: BYE
3 <- SIP:200 Ok GPRS detach
procedure executed
by UE


IMS_REG_5 Initial registration failure due to user authentication failure
Test Purpose:
The timer-await-auth expires at the S-CSCF, Upon authentication failure, the UE gets a 403 forbidden
message , and therefore the registration failed.
Pre-requisites:
Configuration A
UE support SIP
Test Procedure:
Try to register ( no existing SA)
Test Verification:
1. Check the REGISTER message sent from UE to P-CSCF.

2. Verify the 401Unauthorized message back to UE
3. Check the 403 forbidden message back to UE
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register
4 -> SIP: Register
5 <- SIP: 403 Forbidden Registration can be
repeated with correct
authentication
parameters


IMS_REG_6 Registration failure due to network authentication failure
Test Purpose:
This scenario occurs when the check of the MAC in the UE fails, the network can not authenticate the
UE and therefore hence registration fails.
Pre-requisites:
Configuration A
UE support SIP
Test Procedure:
The User send a Register with authenticationFailure to the network
Test Verification:
3. check the authentication failure sent in the second Register request
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register
4 -> SIP: Register
5 <- SIP: 403 Forbidden


IMS_REG_7 Registration failure due to synchronization failure
Test Purpose:
This scenario occurs in subsequent attempts other failure conditions ((i.e. user
authentication failure, network authentication failure). If the received SQN in the
UE is out of range, the UE sends a new Register with indications of
Synchronisation Failure
Pre-requisites:
Configuration A
UE support SIP
Test Procedure:
The User send a Register with indication of synchronization failure to the network
Test Verification:

3. check the synchronisation failure sent in the second Register request
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register
4 -> SIP: Register


IMS_REG_8 Registration failure User unknown or Roaming not allowed
Test Purpose:
This scenario occurs when the Roaming (from IMS perspective, means between different IMS cores)
is not allowed or the user is unknown.
Pre-requisites:
Configuration A
UE support SIP
Test Procedure:
Unknown user send Register to the network.
Test Verification:

Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register


IMS_REG_9 Registration failure due to authentication timer expiry (incomplete Authentication)
Test Purpose:
This scenario is triggered when the authentication timer (reg-await-auth) expires

at S-CSCF before authentication response is received.
Pre-requisites:
Configuration A
UE support SIP
Test Procedure:
User send register
Reg-await-auth timer expires
Test Verification:
2. Check the 401 Unauthorized message sent back to UE
nd
3. Check whether registration fails if 2 Register message is sent by the UE after Reg-await-
auth timer expires
Message flow:

UE NW

P-CSCF Discovery
2 -> SIP: Register
3 <- SIP: 401 Unauthorized Reg-await-auth timer
started
No Register message is received from the UE Reg-await-auth timer
expires


IMS_REG_10 Network initiated re-authentication
Test Purpose:
This scenario describes the notification of a UE that occurs when the S-CSCF
assigned to that user requests re-authentication.
Pre-requisites:
Configuration A
UE support SIP and registered , also the subscriber is considered to be roaming.
Test Procedure:
The UE is roaming between IMS subsystems
Test Verification:
1. Check the NOTIFY message sent from Network to the UE

2. Check the SIP 200 (OK) message sent from the UE to the network.
Message flow:

UE NW

P-CSCF Discovery
2 <- SIP: NOTIFY Could contain shorter
lifetime information
for re-authentication
3 -> SIP: 200 (OK)


IMS_QoS_1 Mobile Originating with Service-based Local Policy, without resource reservation
protocol, only GPRS procedures
Test Purpose:
To verify QoS interactions during a Mobile Originating SIP session establishment when SBLP is
applied
References: TS24.228 Sections 5.3.1, 5.3.5
Pre-requisites:
Configuration A

Both IMS core networks are connected.
UE supports SIP
Test Procedure:
Test Verification:
IMS session was initiated successfully by performing traffic

Make sure that UE associates the PDP context to the session by including the media
authorisation token information and the flow identifier(s) information
Make sure throughput and the round trip delay is not affecting the application
Message flow:

UE NW
1 -> SIP: INVITE
2 <- SIP: Trying
Authorise QoS resourses PDF has sufficient
information about this
session, such as the
end-points,
bandwidth
requirements, and
the characteristics of
the media exchange.
P-CSCF obtains the


Media Authorisation
Token from the PDF
3 <- SIP: Session Progress Contains the P-
Media Authorization
header, which holds
the Media
Authorisation Token
4 -> SIP: PRACK
5 <- SIP: OK (PRACK)
6 -> GPRS: Activate PDP Context
7 <- GPRS: Activate PDP Context Accept
UMTS Bearer Setup
8 -> SIP: UPDATE The UPDATE
request includes in
the SDP the
information the QoS
resource reservation
for both send and
receive mode was
successful from the
terminating endpoint
side
9 <- SIP: OK (UPDATE)
10 <- SIP: Ringing
11 -> SIP: PRACK
Approval of QoS Commit
13 <- SIP: OK (INVITE)
14 -> SIP: ACK


IMS_QoS_2 Mobile Originated sessions requesting the establishment of QoS preconditions and
coordination with GPRS bearer level
Test Purpose:
To verify QoS interactions during a Mobile Originating SIP session establishment when SBLP is not
applied
References: TS24.228 Section 5.3.3
Pre-requisites:
Configuration A

UE supports SIP
Test Procedure:
Test Verification:

Message flow:

UE NW
1 -> SIP: INVITE The SDP contains
the set of codecs
supported by the UE
and includes the
SDP extensions
required to establish
sessions with QoS
preconditions. The
UE also requests to
establish QoS
preconditions for all
the media streams,
but it does not


request confirmation
of the establishment
of the QoS
preconditions from
the terminating side
2 <- SIP: Trying
3 <- SIP: Session Progress The SDP contains
the set of codecs
supported by the
UAS and includes
the SDP extensions
sessions with QoS
preconditions. The
UAS supports the
QoS preconditions
and requests that
UAC sends a
confirmation when
the QoS
preconditions are
met
4 -> SIP: PRACK
UMTS Bearer Setup
8 -> SIP: UPDATE Includes in the SDP
information about the
successful QoS
bidirectional mode,
due to the successful
bidirectional PDP
context established
9 <- SIP: OK (UPDATE)
10 <- SIP: Ringing
11 -> SIP: PRACK
13 <- SIP: OK (INVITE)
14 -> SIP: ACK


IMS_QoS_3 Mobile Termination, with Service-based Local Policy, without resource reservation
protocol, only GPRS procedures
Test Purpose:
To verify QoS interactions during a Mobile terminated SIP session establishment when SBLP is
applied
References: TS24.228 Sections 5.3.2, 5.3.6
Pre-requisites:
Configuration A

UE supports SIP
Test Procedure:
Test Verification:

Make sure that UE associates the PDP context to the session by including the media
authorisation token information and the flow identifier(s) information
Message flow:

UE NW
1 <- SIP: INVITE Contains the P-
Media-Authorization
header, which holds
the Media
Authorisation Token
2 -> SIP: Trying
Authorise QoS resourses P-CSCF obtains the
Media Authorisation
Token from the PDF
4 <- SIP: PRACK


5 -> SIP: OK (PRACK)

6 -> GPRS: Activate PDP Context The UE associates
the PDP context to
the session by
including the media
authorisation token
information and the
flow identifier(s)
information
UMTS Bearer Setup
8 <- SIP: UPDATE
9 -> SIP: OK (UPDATE)
10 -> SIP: Ringing
11 <- SIP: PRACK
13 -> SIP: OK (INVITE)
Approval of QoS Commit
14 <- SIP: ACK


IMS_QoS_4 IMS_QoS_4 Mobile Terminated sessions requesting the establishment of QoS

Test Purpose:
To verify QoS interactions during a Mobile terminated SIP session establishment when SBLP is not
applied
References: TS24.228 Section 5.3.4
Pre-requisites:
Configuration A

UE supports SIP
Test Procedure:
Test Verification:

Message flow:

UE NW
1 <- SIP: INVITE The SDP contains
the set of codecs and
includes the SDP
extensions required
to establish sessions
with QoS
preconditions. The
UAC also requests to
establish QoS
preconditions for all
the media streams,
but it does
not request


confirmation of the
establishment of the
QoS preconditions
from the terminating
side (UAS)
2 -> SIP: Trying
3 -> SIP: Session Progress The SDP contains
the set of codecs
supported by the
UAS and includes
the SDP extensions
sessions with QoS
preconditions. The
UAS supports the
QoS preconditions
and requests that
UAC sends a
confirmation when
the QoS
preconditions are
met
4 <- SIP: PRACK
UMTS Bearer Setup
8 <- SIP: UPDATE The UPDA TE
request includes in
the SDP the
information about the
successful QoS
bidirectional mode,
due to the successful
bidirectional PDP
context established
9 -> SIP: OK (UPDATE)
10 -> SIP: Ringing
11 <- SIP: PRACK
13 -> SIP: OK (INVITE)
14 <- SIP: ACK


IMS_MOB_1 Soft/Softer Handover while active IMS session ongoing
Test Purpose:
The purpose of this test is to verify that the active IMS session is not impacted by a soft/softer
handover.
Pre-requisites:
Configuration: C
UE is IMS capable
UE has an established IMS session on cell 1.
(or SIB#11).
For PS: UE is in PS-DCCH+DTCH_DCH
Test Procedure:
criterion to be added in the active set, and cell 1 to be removed from the active set.
Test Verification:
Soft/softer handover procedure does not impact IMS session. IMS session continue without any
noticeable degradation.
Message flow:
UE NW
IMS session ongoing and data
transfer
UTRAN.
the test procedure.
UTRAN.
4 Soft/softer handover decision Made by the RNC
(DCCH)
the test procedure.
UTRAN.
9 IMS session continues
Remarks:
Test description only covers addition and removal of the leg.


IMS_MOB_2 Hard Handover inter-frequency intra-node B while active IMS session ongoing
Test Purpose:
The purpose of this test is to verify that the active IMS session is not impacted by a hard handover.
Pre-requisites:
Configurations: C
UE is IMS capable
(or SIB#11).
Test Procedure:
for triggering an inter-frequency handover to cell 2 is/are fulfilled.
Test Verification:
Inter frequency hard handover procedure does not impact IMS session. IMS session continue without
any noticeable degradation
Message flow:
UE NW
transfer
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
Remarks:
Only hard handover with measurement is described here. If a test with a blind handover is required,
please see F_6.6.2.1.1


IMS_MOB_3 Hard Handover inter-RNC (inter PLMN) while active IMS session ongoing
Test Purpose:
relocation. For this particular test case, inter-frequency measurements are made by the mobile using
Pre-requisites:
cell 2 using UTRA RF channel 2).
UE is IMS capable
The UE has received the list of equivalent PLMNs through Location Update Accept or Routing Area
Update Accept message. The equivalent PLMN list contains PLMN2.
(or SIB#11).
It is supposed that both PLMN can accept the same PDP context.
Test Procedure:
Radio conditions are then changed so that the criterion/criteria for triggering an inter PLMN handover
to cell2 is/are fulfilled.
Test Verification:
To confirm that after the inter-PLMN hard handover, the quality of the transmission is as follows:
IMS session continue without any noticeable degradation


Message flow:
UE NW
transfer
by UTRAN.
test procedure.
by UTRAN.
(DCCH) cell2
COMPLETE (DCCH)
7 LA and/or RA REQUEST
8 LA and/or RA ACCEPT
Remarks:
Only hard handover with measurement are described here. If a test with a blind handover is required,
please see F_6.6.2.1.1


IMS_MOB_4 Soft/Softer Handover between HSDPA cell while active IMS session ongoing
Test Purpose:
The purpose of this test is to verify that the active IMS session is not impacted by a soft/softer
handover.
Pre-requisites:
UE is IMS capable
Cell 1 and Cell 2 are both HSDPA cells. Cell 1 and Cell 2 are on different NodesB (soft handover).
UE is HSDPA capable
SIB#11).
PS_DCCH+DTCH_HS-DSCH
Test Procedure:
criterion to become the new serving HS -DSCH cell. The UTRAN decides to change the serving HS-
message.
Test Verification:
Soft/softer handover procedure does not impact IMS session. IMS session continue without any
noticeable degradation


Message flow:
UE NW
transfer
UTRAN.
conditions such that the non-
serving HS-DSCH cell 2 in the
Active Set satisfies the criterion
to be the new serving HS-DSCH
cell.
UTRAN.
4 serving HS-DSCH cell change decision by Made by the RNC
UTRAN
5 RADIO BEARER * RECONFIGURATION Including new HSDPA
(DCCH) configuration (and Activation
Time if synchronized Cell
Change)
6 RADIO BEARER *RECONFIGURATION
COMPLETE (DCCH)
Remarks:
None


IMS_MOB_5 Cell reselection while inactive IMS session ongoing: success
Test Purpose:
The purpose of this test is to verify that UE is able to perform a cell reselection and continue with an
inactive IMS session.
Pre-requisites:
2 cells, UE is camped on cell 1
UE is IMS capable
UE has an active IMS PDP context open, but state is IDLE_STATE
Test Procedure:
Radio conditions are changed so that cell 2 satisfies the criterion to become the new serving cell to
camp on for UE.
The UE camps on cell 2.
Initiate an IMS action
Test Verification:
IMS session can be restarted successfully by performing traffic.
Make sure cell reselection has not affected the application.
Message flow:
UE NW
IMS session inactive
conditions such cell 2 is the best
cell for UE
2 UE camp on cell 2
3 User initiate an IMS action
5 RRC CONNECTION SETUP Cell_DCH configuration
7 <- IMS session continues
Remarks:
None


IMS_MOB_6 Cell reselection while inactive IMS session ongoing: insufficient resources at
destination
Test Purpose:
The purpose of this test is to verify that IMS session will be correctly closed if there are insufficient
resources at destination.
Pre-requisites:
UE is IMS capable
Test Procedure:
Radio conditions are changed again so that cell 2 satisfies the criterion to become the new serving cell
to camp on for UE.
Test Verification:
Verify that GGSN report correctly PDP modification to PDF.
Verify that IMS pdp is released by network.
Message flow:
UE NW
cell for UE
2 UE camp on cell 2
Not enough resource to support
negotiated pdp
7 MODIFY PDP CONTEXT REQUEST
8 MODIFY PDP CONTEXT ACCEPT
GGSN report to PDF.
Decision to close PDP
9 DEACTIVATE PDP CONTEXT REQUEST Cause insufficient ressources
COMPLETE
Remarks:
Depending on network implementation, it is possible that pdp will be deactivate without a modify pdp
request


IMS_MOB_7 Cell reselection while inactive IMS session ongoing: change of IP address
Test Purpose:
The purpose of this test is to verify that IMS session will be correctly resumed if network has modified
IP address of the IMS session.
Pre-requisites:
UE is IMS capable
Test Procedure:
camp on for UE.
Initiate an IMS action.
Network changes IP address.
Verify that UE uses this new IP address to resume IMS session
Test Verification:
Verify that IMS session is resumed correctly
Message flow:
UE NW
cell for UE
2 UE camp on cell 2
7 MODIFY PDP CONTEXT REQUEST New IP address
9 IMS session continues or
restarts
Remarks:
None


IMS_MOB_8 Hard Handover to 2G band while active IMS session ongoing
Test Purpose:
To check that when a UE satisfies the criteria for being handed over to another RAT, an inter-band
handover can be successfully performed. For this particular test case, inter-RAT measurements are
made by the mobile using compressed mode or a dual receiver, depending on UE capabilities.
Pre-requisites:
Configuration: F ( cell 1 is UMTS: cell 2 is GPRS)

UE is IMS capable
(or SIB#11).
Test Procedure:
Radio conditions are then changed so that the criterion/criteria for triggering an inter RAT handover to
cell2 is/are fulfilled.
Test Verification:
To confirm that after the inter-RAT hard handover, the quality of the transmission is as follows:
IMS session continue without any noticeable degradation assuming GPRS throughput is enough to
maintain IMS session
Message flow:
UE NW
transfer
by UTRAN.
test procedure.
by UTRAN.
4 Inter-RAT handover decision Made by the RNC
5 CELL CHANGE ORDER from UTRAN Indicating cell 2
6 LAU and/or RAU REQUEST
7 LAU and/or RAU ACCEPT
8 LAU and/or RAU COMPLETE
9 IMS session resumes
Remarks:
None


IMS_MOB_9 Handover to 3G band while active IMS session ongoing
Test Purpose:
To check that when a UE satisfies the criteria for being handed over to 3G, an inter-band handover
can successfully be performed. For this particular test case, inter-RAT measurements are made by the
mobile using compressed mode or a dual receiver, depending on UE capabilities.
Pre-requisites:
Configuration: F (: cell1 is GSM: cell 2 is UMTS)

UE is IMS capable
GSM network is NC2 (cell reselection controlled by network in GPRS)
Test Procedure:
Radio conditions are then changed so that the criterion/criteria for triggering an inter RAT handover to
cell2 is/are fulfilled.
Test Verification:
To confirm that after the inter-RAT hard handover, the quality of the transmission is as follows:
IMS session continue without any noticeable degradation assuming GPRS throughput is enough to
maintain IMS session
Message flow:
UE NW
transfer
1 PACKET MEASUREMENT REPORT UE returns intra-frequency
by UTRAN.
test procedure.
3 PACKET MEASUREMENT REPORT UE returns intra-frequency
by UTRAN.
4 Inter-RAT handover decision Made by the RNC
5 PACKET CELL CHANGE ORDER from Indicating cell 2
UTRAN
9 RADIO BEARER RECONFIGURATION*
10 RADIOA BEARER RECONFIGURATION
COMPLETE*
11 IMS session resumes
Remarks:
* if qos is modified.


IMS_MOB_10 Cell reselection while inactive IMS session ongoing: success
Test Purpose:
The purpose of this test is to verify that UE is able to perform a cell reselection inter band and continue
with an inactive IMS session.
Pre-requisites:
Configurations: F, cell 1 is UMTS, cell 2 is GPRS

UE is camped on cell 1
UE is IMS capable
Test Procedure:
camp on for UE.
Test Verification:
IMS session can be restarted successfully by performing traffic.
Make sure cell reselection has not affected the application.
Message flow:
UE NW
cell for UE
2 UE camp on cell 2
6 User initiates IMS
Remarks:
None


IMS_MOB_11 Cell reselection while inactive IMS session ongoing: insufficient resources at
destination
Test Purpose:
The purpose of this test is to verify that IMS session will be correctly closed if there is insufficient
Pre-requisites:
Configurations: F, cell 1 is UMTS, cell 2 is GPRS

UE is IMS capable
Test Procedure:
camp on for UE.
Test Verification:

Verify that IMS pdp is released by network.
Message flow:
UE NW
cell for UE
2 UE camp on cell 2
GGSN report to PDF.
Decision to close PDP
9 DEACTIVATE PDP CONTEXT REQUEST Cause insufficient ressources
Remarks:
None


IMS_MOB_12 Cell reselection while inactive IMS session ongoing: change of IP adress
Test Purpose:
The purpose of this test is to verify that IMS session will be correctly closed if there is insufficient
Pre-requisites:
Configurations: F, cell 1 is UMTS, cell 2 is GSM

UE is IMS capable
Test Procedure:
Radio conditions are changed again so that cell 2 satisfies the criterion to become the new serving cell
to camp on for UE.
Initiate an IMS action.
Network change IP address.
Verify that UE use this new IP address to resume IMS session
Test Verification:

Verify that IMS session is resumed correctly
Message flow:
UE NW
cell for UE
2 UE camp on cell 2
IMS session continues
Remarks:
None


9 Protocol test cases
B_6.1.1.1 PLMN selection
Test Purposes:
Test to verify that the UE can present the available PLMN to the user when asked to do so in manual
mode and that the displayed PLMN can be selected / reselected by the user. If available, the RPLMN
shall be selected at switch-on.
Only UTRAN cells and a UE equipped with a USIM with Radio Access Technology fields set to
UTRAN are considered.
Reference : TS 23.122, clause 4.4.3.1, TS 23.122, clause 4.4.3.1.2, TS 23.122, clause 3.1.
NOTE: TS 31.102 defines the USIM fields.
Pre-requisites:
The UE is in manual PLMN selection mode.
Cell level is from table 6.3.
Radio Access Technology USIM field and cell are UTRAN.
Cell CPICH_ Test PLMN

Ec [dBm/3.84MHz] Channel
(FDD)
Cell 1 -60 1 PLMN 1
The UE is equipped with a USIM containing default values except for those listed below.
USIM field Priority PLMN

EFLOCI PLMN 1
Test Procedure:
a) The operator activates 1 cell and monitors the cell for random access requests from the UE.
b) The UE is switched on.
c) The NW waits for random access requests from the UE.
Cell 1 shall be selected.
Test Verification:
To verify that if available, the RPLMN is selected at switch-on.
Message Flow:

UE NW
Remarks:
In step c), the response from the UE shall be on Cell 1. The displayed PLMN shall be PLMN 1.


B_6.1.2.1 Cell reselection
Test Purposes:
Test to verify that the UE performs the cell reselection correctly for intra/inter-frequency cells if the
serving cell becomes barred or S<0.
Reference : TS 25.304 clause 5.2.1, TS 25.304 clause 4.3, TS 25.304 clause 5.2.5.1, TS 25.304
clause 5.2.6.1.4, TS 25.304 clause 5.3.1.1.
Pre-requisites:
Configuration: C
Treselection, Qhyst, Qoffset, TEMP_OFFSET and PENALTY_TIME are not used, so the cell-
ranking criterion R equals CPICH_RSCP for FDD cells.
Step a-c(FDD) :
Parameter Unit Cell 1 Cell 2 Cell 3

Test Channel 1 1 2
CPICH_Ec dB -60 -70 -80
Qrxlevmin dBm -115 -115 -115
Srxlev dBm 55 45 35
Intra-frequency
Not Not
cell re-selection Not Allowed
Allowed Allowed
indicator
CellBarred 0 0 0
Step d-f:
CellBarred 0->1 0 0
Step g-h:
Intra-frequency Not Not

Not Allowed
cell re-selection Allowed -> Allowed ->
-> Allowed
indicator Allowed Allowed
Step i(FDD) :
Qrxlevmin dBm 115 -> -51 -115 -115

Srxlev dBm 55 -> -9 45 35
Test Procedure:
a) The NW activates Cell 1-3 and monitors them for random access requests from the UE.
d) The NW sets Cell 1 to be barred.
e) The NW waits for random access requests from the UE.
f) The NW sets "Intra-frequency cell re-selection indicator" to "Allowed".
g) The NW waits for random access requests from the UE.
h) The stored information cell selection list in the UE is deleted and the UE is switched off.
Step a-e) is repeated except that in step d) for FDD cells, Qrxlevmin is increased to -50 dBm, so
S will become negative instead of the cell being barred while maintaining the same RF level.


Test Verification:
To verify that the UE performs cell reselection on the following occasions:

Serving cell becomes barred;
S<0 for serving cell.
Message Flow:

UE NW
Remarks:
In step c), after the UE has responded on Cell 1, it shall not respond on any other cell within 1
min.
In step e), the UE shall respond on Cell 3.
In step g), the UE shall respond on Cell 2.
In step i), the UE shall respond on Cell 2.


E_6.1.2.2 Cell reselection using Qhyst, Qoffset and Treselection
Test Purposes:
Test to verify that the UE performs the cell reselection correctly if system information parameters
Qoffset, Qhyst and Treselection are applied for non-hierarchical cell structures. TEMP_OFFSET and
PENALTY_TIME are only applicable when HCS is applied and are tested in clauses 6.1.2.4 and
6.1.2.5.
Reference : TS 25.304 clause 5.2.5.1, TS 25.304 clause 5.2.6.1.4.
Pre-requisites:
Step a-c(FDD):
Parameter Unit Cell 1 Cell 2
DBm/3.84M
CPICH_Ec -60 -70
Hz
Qhyst1s dBm 20
Rs * dBm -40
Rn* dBm -70
Step d-e(FDD):
dBm/3.84MH -60 -> - -70 -> -
CPICH_Ec
z 70 60
-40 -> -
Rs * dBm
50
-70 -> -
Rn* dBm
60
Step f-g(FDD):
Qhyst1s dBm 20 -> 0
Rs * dBm -50 -> -70
Rn* dBm -60
Step h-j(FDD):
dBm/3.84MH
CPICH_Ec -60 -70
z
Qoffset2s,n dBm 20
Rs * dBm -60
Rn* dBm -90
- 68 -> -
Rn* dB -68
81
Step k-l(FDD):
DBm/3.84MH -60 -> - -70 -> -
CPICH_Ec
z 70 60
-60 -> -
Rs * dBm
70
Rn* dBm -90 -> -


80
Step m-n(FDD):
Qoffset1s,n dBm 20 -> 0
Rs * dBm -70
Rn* dBm -80 -> -60
Step o-p(FDD):
Treselections s 30
Test procedure :
Method B is applied.
a) The NW activates Cell 1 and 2 and monitors them for random access requests from the UE.
c) The NW waits to see if there is any random access requests from the UE.
d) The NW changes the level of Cell 1 and 2 and waits for 10 s (TS 25.133, A.4.2.1.2 for FDD mode).
e) The NW waits for random access requests from the UE.
f) The NW resets Qhyst for Cell 1.
g) The NW waits for random access requests from the UE.
h) The stored information cell selection list in the UE is deleted and the UE is switched off.
i) The UE is switched on.
j) The NW waits to see if there is any random access requests from the UE.
k) The NW changes the level of Cell 1 and 2 and waits for 10 s (TS 25.133, clause A.4.2.1.2 for FDD
mode).
l) The NW waits for random access requests from the UE.
m) The NW resets Qoffset for Cell 1.
n) The NW waits for random access requests from the UE.
Step h-n) is repeated except that Treselection is 30 s
Test Verification :
To verify that the UE calculates R from Qhyst and Qoffset and that the modification of these
parameters on the BCCH triggers the cell reselection evaluation process. TEMP_OFFSET and
PENALTY_TIME are not applied.
To verify that the UE reselects the new cell, if the cell reselection criteria are fulfilled during a time
interval Treselection.
Message Flow:

UE NW
Remarks :
In step c), after the UE has responded on Cell 1, it shall not respond on any other cell within 1 min.
In step e), the UE shall keep responding on Cell 1.
In step g), the UE shall respond on Cell 2.
In step j), the UE shall select a cell to camp on and eventually make a reselection to Cell 1.
In step l), the UE shall keep responding on Cell 1.
In step n), the UE shall respond on Cell 2.


In step o), the UE shall respond as in previous steps except that when reselecting to Cell 2, there shall
be no response from the UE on Cell 2 within 28 s of broadcasting Qoffset but the UE shall
respond on Cell 2 within 34 s.
NOTE: Minimum time set by Treselection 2 s tolerance. Maximum time set by Treselection + 1 280
msec. for DRX cycle + 2 s tolerance


E_6.1.2.4 HCS Cell reselection using reselection timing parameters for the H criterion
Test Purposes :
Test to verify that the UE performs the cell reselection correctly for hierarchical cell structures using
TEMP_OFFSET and PENALTY_TIME applied to the H criterion.
Reference : TS 25.304 clause 5.2.2, TS 25.304 clause 5.2.6.1.4.
Pre-requisites :
Configuration: C
Step a-c(FDD):

dBm/3.8
CPICH_Ec -60 -70 -70
4MHz
HCS priority 2 4 7
Qhcss dBm -80
Qhcsn=2 dBm -50
Qhcsn=3 dBm -50
TEMP_OFFSET2n=2 dBm 30
TEMP_OFFSET2n=3 dBm 30
Hs * dBm 20
Hn=2* dBm -20
Hn=3* dBm -20
PENALTY_TIMEn=2 sec 40
PENALTY_TIMEn=3 sec 60
Step d-e(FDD):
Qhcss dBm -80

Qhcsn=2 dBm -50 -> -80
Qhcsn=3 dBm -50 -> -80
Hs * dBm 20
-20 -> 10
Hn=2* dBm
(after 40 sec)
-20 -> 10
Hn=3* dBm
(after 60 sec)
Test Procedure :
Method B is applied.
a) The NW activates the cells 1-3 and monitors them for random access requests from the UE.
d) The NW changes Qhcs for Cell 2 and 3.
The NW waits for random access requests from the UE.


Test Verification :
Verify that TEMP_OFFSET is applied to the H criterion for a period of PENALTY_TIME and that the
timer is started when Qmeas,n > Qhcsn if serving and neighbour cell have different HCS priorities.
Message Flow:

UE NW
Remarks :
In step c), after the UE has responded on Cell 1, it shall not respond on any other cell within 1 min.
In step e), there shall be no response from the UE on Cell 2 within 38 s of changing the parameters
but the UE shall respond on Cell 2 within 44 s. There shall be no response from the UE on Cell 3
within 58 s of changing the parameters but the UE shall respond on Cell 3 within 64 s.
NOTE: Minimum time set by PENALTY_TIME (cell 2) - 2 s tolerance. Maximum time set by
PENALTY_TIME (cell 2) + 1 280 msec. for DRX cycle + 2 s tolerance. Same calculation for Cell 3.


E_6.1.2.6 Emergency calls
Test Purposes :
Test to verify that the UE shall be able to initiate emergency calls when no suitable cells of the
selected PLMN are available, but at least one acceptable cell is available.
References : TS 25.304 clause 4.3, TS 25.304 clause 4.3, TS 25.304 clause 5.2.2.1, TS 25.304
clause 5.2.8, TS 25.304 clause 5.2.2.5, TS 25.304 clause 5.2.9.1.
Pre-requisites :
Configuration: C
In step a-d, Cell 1 and 2 are neither suitable nor acceptable cells. Cell 3 is an acceptable cell
but not suitable.
In step e-f, both Cell 1 and 3 are acceptable cells.
Cells 1, 2 and 3 are all in the same PLMN, which is different from the PLMN is the UEs USIM,
and which is in the forbidden PLMN list in the USIM.
Step a-d(FDD):

dBm/3
CPICH_Ec .84MH -65 -60 -70
z
Srxlev* dBm 15 -10 10
CellBarred 1 0 0
PLMN forbidden forbidden forbidden
Step e-f:
CellBarred 1 -> 0 0 0
Test Procedure :
Method C is applied.
a) The NW activates the cells and monitors them for random access requests from the
UE.
c) 50 s after switch on, an emergency call is initiated on the UE.
d) The NW waits for random access request from the UE.
e) The NW changes the CellBarred of Cell 1 to 0.
f) After 30 s an emergency call is initiated on the UE.
The NW waits for random access request from the UE.
Test Verification:
To verify that the UE shall be able to initiate emergency calls when no suitable cells of the


To verify that the UE selects a cell with S>0 and CellBarred = 0 (acceptable cell) when no
suitable cells of the selected PLMN are available.
To verify that the UE ranks the acceptable cells according to the cell-ranking criterion R
which in this test case equals Q as Qhyst, Qoffset, TEMP_OFFSET and PENALTY_TIME
parameters are not used. Treselection is not used either.
Remarks:
In step d), the first access from the UE shall be on Cell 3.

In step g), the first access from the UE shall be on Cell 1.


B_6.1.2.9 Cell reselection using cell status and cell reservations
Test Purposes :
1. To verify that when cell status is indicated as "not barred", "not reserved" for operator use and
"reserved" for future extension (Cell Reservation Extension),
- UEs behave as if cell status "barred" is indicated using the value "not allowed" in the IE
"Intra-frequency cell re-selection indicator" and the maximum value for Tbarred.
2. To verify that when cell status is indicated as "not barred" and "reserved" for operator use,
- UEs assigned to Access Class 11 or 15 may select/re-select this cell if in the home PLMN.
- UEs assigned to an Access Class in the range 0 to 9 and 12 to 14 shall behave as if cell
status "barred" is indicated using the value "not allowed" in the IE "Intra-frequency cell re-
selection indicator" and the maximum value for Tbarred.
Pre-requisites :
Configuration: C, D, E
Test procedure 1: Use of USIM with "Type A" EFACC as defined in TS 34.108.
Step a-c (FDD):

Test Channel 1 1 2
CPICH_Ec dBm/3.84 MHz -58 -68 -78
Srxlev* dB 25 15 5
Cell Reserved for
not reserved not reserved not reserved
operator use
Cell Reservation
Extension
Step d-e:
Cell Reserved for not reserved ->
not reserved not reserved
operator use reserved
Cell Reservation
Extension
Step f-g:
Cell Reserved for reserved ->
operator use not reserved
Cell Reservation
Extension
Test procedure 2: Use of USIM with "Type B" EFACC as defined in TS 34.108.
Step a-c (FDD):



Test Channel 1 1 2
CPICH_Ec dBm/3.84 MHz -58 -68 -78
Srxlev* dB 25 15 5
Cell Reserved for
operator use
Cell Reservation
Extension
Step d-e:
Cell Reserved for
operator use
Cell Reservation not reserved ->
Extension reserved
Step f-g:
Cell Reserved for not reserved ->
operator use reserved
Cell Reservation
reserved not reserved not reserved
Extension


Test Procedure :
Test procedure 1
The NW activates Cell 1,2 and 4, and monitors them for random access requests from the UE.
The UE is switched on.
The NW sets Cell 1 to "reserved" for operator use. The NW notifies UE of the BCCH modification.
The NW sets Cell 1 to "not reserved" for operator use.
Test procedure 2
The NW activates Cell 1,2 and 4, and monitors them for random access requests from the UE.
The UE is switched on.
The NW sets Cell 1 to "reserved" for future extension. The NW notifies UE of the BCCH modification.
The NW sets Cell 1 to "reserved" for operator use.
Test Verification:
To verify that the UE shall be able to initiate emergency calls when no suitable cells of the
To verify that the UE selects a cell with S>0 and CellBarred = 0 (acceptable cell) when no suitable
cells of the selected PLMN are available.
To verify that the UE ranks the acceptable cells according to the cell-ranking criterion R which in
this test case equals Q as Qhyst, Qoffset, TEMP_OFFSET and PENALTY_TIME parameters
are not used. Treselection is not used either.
Remarks:
Test procedure 1
In step c), the UE shall respond on Cell 1.
In step g), the UE shall respond on Cell 1 after 1280 seconds (maximum value for Tbarred) from SS notified UE of
the BCCH modification in Cell 1 in step d).


Test procedure 2
In step c), the UE shall respond on Cell 1.
In step g), the UE shall respond on Cell 1 after 1280 seconds (maximum value for Tbarred) from SS notified UE of
the BCCH modification in Cell 1 in step d).


B_7.1.2.2.1 Correct application of Dynamic Persistence (FDD)
Test Purposes:
To verify that the UE correctly operates the dynamic persistence algorithm outlined in fig 11.2.2.1 of
TS25.321.
Reference: 25.321, clause 11.2.2 (figure 11.2.2.1)
.
Pre-requisites:
NW: 1 cell, default parameters, Ciphering Off.
UE: The UE shall operate under normal test conditions, Ciphering Off.
The Test-USIM shall be inserted.
Test Procedure:
Iteration 1:
The tester changes the default system information messages such that the dynamic
persistence level is set to 8, and scaling factors are not transmitted. This results in a
dynamic persistence value (P i ) of 0.0078125 for all access service classes. Note: ASC#0
is not used because NumASC=7 and the lowest MLP value =1. - See 25.321, clause
11.2.1.
The tester waits until the UE has enough time to take account of the changes.
The NW repeatedly pages the UE 100 times, waiting for the reception of a RRC
CONNECTION REQUEST from the UE before each subsequent page.
Iteration 2
The tester performs these 3 steps once more, but changes the default system information
messages such that the dynamic persistence level is set to 1, and no scaling factors are
transmitted. This results in a dynamic persistence value (P i) of 1 for all access service
classes.
Test Verification:
To verify that the UE correctly operates the dynamic persistence algorithm outlined in fig
11.2.2.1 of TS25.321.
Message Flow:

UE NW
1 PAGE
The above sequence is repeated 100 times.


Remarks:
Iteration 1:
The NW shall receive a RRC CONNECTION REQUEST from the UE on average every
1.28 seconds 0.15s after each paging request.
Iteration 2:
The NW shall receive a RRC CONNECTION REQUEST from the UE within 150ms after
each paging request.


B_7.1.2.3.1 Correct Selection of RACH parameters (FDD)
Test Purpose:
To verify that the UE (All FDD UE) selects the correct initial access slot and PRACH signature.
Reference : TS 25.214 clause 6.1.
Pre-requisites:
The UE shall be attached to the network and in idle mode.
Preamble Retrans Max parameter in SIB5 set to 5.
2 ASC settings (ASC#0 and ASC#1) are defined (with default parameters) in SIB5, except
that the parameter assigned sub channel number is set as follows:
ASC#0 Assigned sub channel number = 0001B

ASC#1 Assigned sub channel number = 0010B
The available sub-channel number defined in SIB5 is set to 1111 1111 1111B. Note: this
value allows RACH transmission on all sub-channels defined by Assigned sub channel
number above.
The UE shall use Access Class AC#15 which provides permission to use ASC#0 for the
initial access. This condition is achieved by inserting the USIM card with Type B setting of
the parameter EFACC (Access Control Class) as defined in 3GPP TS 34.108.
Maximum number of preamble retransmission cycles in SIB 5 is set to Mmax = 1.
Test Procedure:
The NW pages the UE until it performs a RACH access.

The tester measures the access slot and preamble signature used.
The NW does not acknowledge the RACH access, causing the UE to retry.
The tester again measures the access slot and preamble signature used.
The tester repeats the the first 3 steps until the maximum number of retries Preamble Retrans
Max has been attempted, and monitors the RACH channel for10 seconds to ensure that no
further RACH accesses occur.
The tester measures the access slot and preamble signature used.
The NW responds with a negative acquisition indicator on the AICH.
The NW monitors the RACH channel for 10 seconds to ensure that no further RACH accesses
occur.
The tester measures the access slot used.
The NW acknowledges the RACH access normally.
The tester measures the first access slot used in the PRACH message part.
The NW monitors the RACH channel for 10 seconds to ensure that no further RACH accesses
occur.


Test Verification:
To verify that:
A1 the UE, initially:
- determines the ASC for the given Access Class (AC)
- derives the available uplink access slots, in the next full access slot set, for the set of
available RACH sub-channels within the given ASC with the help of TS 25.214, subclauses
6.1.1. and 6.1.2. and randomly select one access slot among the ones previously
determined.
- randomly select a new signature from the set of available signatures within the given
ASC.
A2 the UE, when not receiving any reply from UTRAN:
- selects the next available access slot in the set of available RACH sub-channels
within the given ASC.
- randomly select a new signature from the set of available signatures within the given
ASC.
- does not transmit on the PRACH resources specified in the BCH message SIB 5 after
that the physical random access procedure is terminated.
A3 the UE, when detecting a negative acquisition indicator:
does not transmit on the PRACH resources specified in the BCH message SIB 5 after that the
physical random access procedure is terminated.
A4 the UE, when detecting a positive acquisition indicator:

transmits the random access message three or four uplink access slots after the uplink access slot
of the last transmitted preamble depending on the AICH transmission timing parameter.
- terminates the random access procedure.


Message Flow:

UE NW
1 PAGE Preamble Retransmission Counter = 5
2 Access Preamble Access slot used = n, where n is defined by
the table below in remarks.
Signature used = any from {P 0 .. P7}

Preamble Retransmission Counter = 4
3 Access Preamble Access slot used = mod(n+3,15)

4 Access Preamble Access slot used = mod(n+6,15) Signature
used = any from {P 0 .. P7}
7 Wait for T = 10s NW monitors for RACH access attempts
8 PAGE
the table below in remarks
10 AICH = NEG ACQUISITION
IND
12 PAGE
the table below in remarks
14 AICH = POS ACQUISITION
IND
15 RRC_CONNECTION_REQUES Message part. Access slot used = mod(n+3,
T 15)
Remarks:
The UE shall be attached to the network and in idle mode.
A1
At the first access preamble
o the NW shall receive a PRACH preamble using an access slot as defined below and
using a preamble signature from the set of preamble signatures {P 0 .. P7}. See TS
25.213, clause 4.3.3.3 for a list of preamble codes.
o the access slot selected for the first access preamble can be any of the shaded
table entries given below for ASC#0, depending on SFN (Note: the table entries
which are not shaded are not allowed for ASC#0):


SFN modulo 8 of Sub-channel number

corresponding P-
0 1 2 3 4 5 6 7 8 9 10 11
CCPCH frame
0 0 1 2 3 4 5 6 7
1 12 13 14 8 9 10 11
2 0 1 2 3 4 5 6 7
3 9 10 11 12 13 14 8
4 6 7 0 1 2 3 4 5
5 8 9 10 11 12 13 14
6 3 4 5 6 7 0 1 2
7 8 9 10 11 12 13 14
A2
At the second, third, fourth and fifth access preamble
- the NW shall receive a PRACH preamble using an access slot mod(n + 3, 15), where
n is the access slot used in the previous step, and using a preamble signature from the set of
preamble signatures {P 0 .. P7}. See TS 25.213, clause 4.3.3.3 for a list of preamble codes.
After the fifth access preamble

- the NW shall not receive on the PRACH resources specified in the BCH message SIB
5 after that the physical random access procedure is terminated.
A3
After the negative acquisition from the NW
the NW shall not receive on the PRACH resources specified in the BCH message SIB 5
after that the physical random access procedure is terminated.
A4
At the last RRC connection request
the NW shall receive the random access message three access slots after the uplink
access slot of the preamble received in step 13.
After the negative acquisition from the NW

the NW shall not receive on the PRACH resources specified in the BCH message SIB 5
after that the physical random access procedure is terminated.


E_7.1.11.1 Ciphering
Test Purpose :
To verify that the ciphering is performed in the MAC layer for transparent RLC mode.
Reference : TS 25.301 sub-clause 5.3.1.2.
Pre-requisites :
default parameters. Transparent Mode, Ciphering On.
Test Procedure :
Change to a normal call set up procedure, and modify the rest of the test case accordingly.
The MAC entity of NW was configured as Ciphering mode as Start with CMAC_CONFIG-
REQ primitive.
NW configures its RLC entity Transparent mode.
The NW sends a DATA BLOCK from RLC PCO without MAC header. After having received
the data block via configured mapped channels, the UE forwards the data to its Radio Bearer
Loop Back entity. The received data shall be returned by the UE via its MAC configuration to
the NW.
The NW checks the returned data blocks and compares it with the data block sent before.
Message Flow :

UE NW
1 NW sends CMAC_CONFIG-REQ to set
ciphering mode as Start.
2 NW sends CMAC_MAC_HEADER_REQ
with disable_mac_header and
CRLC_CONFIG_REQ with RLC mode as
Transparent mode.
3 DATA BLOCKS NW sends data blocks from downlink radio
bearer, The data blocks is ciphered by NW
and deciphered by UE.
4 LOOP BACK DATA BLOCKS NW receives loop back data blocks from
uplink radio bearer. The loop back data is
ciphered by UE and deciphered by NW.
5 NW sends CMAC_MAC_HEADER_REQ
with enable_mac_header and
CRLC_CONFIG_REQ with RLC mode as
AM mode.
RADIO BEARER SET UP:
Information Element Value/remark

Ciphering mode info
- Ciphering mode command Start
- Ciphering algorithm UEA 1, kasumi.
RLC info
- RLC mode Transparent RLC


RB mapping info
-Downlink
- Number of logical channels 1
- Downlink transport channel type DCH
-Uplink
- Number of logical channels 1
- Uplink transport channel type DCH
Remarks :
The loop back data shall be identical to the data sent out by NW.


B_8.1.1.1 RRC/Paging for Connection in idle mode
Test Purpose:
To confirm that the UE establishes an RRC connection after it receives a PAGING TYPE 1 message,
which includes IE "Paging Record"(UE identity) set to the IMSI of the UE.
Reference: 3GPP TS 25.331 clause 8.1.2, 3GPP TS 25.211 clause 5.3.3.7, 3GPP TS 25.304 clause.
Pre-requisites:
NW: 1 cell
UE: Idle state (state 2 or state 3 or state 7) as specified in clause 7.4 of TS 34.108 with a CN
UE identity (set to IMSI in the CS domain), depending on the CN domain(s) supported by the
UE.
Test Procedure:
NW transmits SYSTEM INFORMATION BLOCK TYPE 1 or 13 messages, depending on the CN type

supported by the UE. The NW transmits a PAGING TYPE 1 message, which includes an unmatched
CN UE identity for the UE in the idle state. The UE shall not change its state. The NW transmits a
PAGING TYPE 1 message, which includes a matched CN UE identity for the UE in the idle state.
During transmission of PAGING TYPE 1 messages, NW selects the correct paging indicator on the
PICH in order to allow the UE to respond to paging. Then the UE transmits an RRC CONNECTION
REQUEST to the NW, the NW transmits an RRC CONNECTION SETUP to the UE. When the UE
receives this message, the UE establishes an RRC connection and transmits an RRC CONNECTION
SETUP COMPLETE message on the uplink DCCH.
NOTE: For UEs supporting GSM-MAP CN type only, SYSTEM INFORMATION TYPE 1 messages
are to be sent by NW in this test case. On the other hand, NW transmits SYSTEM
INFORMATION TYPE 13 messages if the UE under test supports only ANSI-41 CN type.
Test Verification:


Message Flow:

UE NW
1 SYSTEM INFORMATION BLOCK Transmit these messages on
TYPE 13 or SYSTEM the BCCH, in addition to the
INFORMATION BLOCK TYPE 1 normal BCCH transmissions.
See specific message contents.
2 PAGING TYPE 1 The NW transmits the
message, which includes an
unmatched identity (incorrect
IMSI), and the UE does not
change its state.
3 PAGING TYPE 1 The NW transmits the
message, which includes a
matched identity (test-SIM
IMSI).
5 RRC CONNECTION SETUP NW assigns DPCH resources
to allow UE to establish an
RRC connection.
COMPLETE
Remarks:
After step 2 the UE shall not transmit on the uplink CCCH in order to establish a RRC
connection.
After step 5 the UE shall have an RRC connection based on dedicated physical channel
resources and transmit an RRC CONNECTION SETUP COMPLETE message on the uplink
DCCH.


B_8.1.1.2 RRC/ Paging for Connection in connected mode (CELL_PCH)
Test Purpose:
The purpose of this test is to verify that the UE enters the CELL_FACH state after it receives a
PAGING TYPE 1 message, which indicates that the paging has originated from UTRAN. To verify that
the UE performs cell update procedure after entering the CELL_FACH state.
Pre-requisites:
NW: 1 cell
UE: CELL_PCH state (state 6-12) as specified in clause 7.4 of TS 34.108, depending on the
CN domain(s) supported by the UE with a valid U-RNTI already assigned by the NW.
Test Procedure:
NW transmits SYSTEM INFORMATION BLOCK TYPE 1 or 13 messages, depending on the CN type
supported by the UE. The NW transmits a PAGING TYPE 1 message, which includes an unmatched
U-RNTI in CELL_PCH state. The UE does not change its state. The NW transmits a PAGING TYPE 1
message, which includes a matched U-RNTI in the connected state. Then the UE enters the
CELL_FACH state and performs the cell updating procedure.
NOTE: For UEs supporting GSM-MAP CN type only, SYSTEM INFORMATION TYPE 1
messages are to be sent by NW in this test case. On the other hand, NW transmits
SYSTEM INFORMATION TYPE 13 messages if the UE under test supports only
ANSI-41 CN type.
Test Verification:


Message Flow:

UE NW
1 SYSTEM INFORMATION BLOCK Transmit these messages on
TYPE 13 or SYSTEM the BCCH, in addition to the
INFORMATION BLOCK TYPE 1 normal BCCH transmissions.
See specific message contents
2 PAGING TYPE 1 The NW transmits a message
including an unmatched
identifier. UE shall not respond
to the paging.
3 PAGING TYPE 1 The NW transmits the message
with the UTRAN being the
originator and including the
UE's assigned U-RNTI
4 CELL UPDATE The UE enters the
CELL_FACH state. UE
performs cell updating
procedure. The CELL UPDATE
message shall contain the
value "Cell Update Cause" set
to "paging response".
5 CELL UPDATE CONFIRM Use the default message
specified in Annex A.
Remarks:
After step 2 the UE shall not respond to the PAGING TYPE 1 message sent in step 2.
After step 3 the UE shall enter the CELL FACH state and send a CELL UPDATE message
with "Cell Update Cause" IE set to "paging response".


B_8.1.1.4 Paging for Notification in idle mode
Test Purpose:
When a system information block on the BCCH is modified, the PAGING TYPE 1 message can be
sent on the PCCH to inform UE in the idle mode about the changes, which are currently taking place.
The PAGING TYPE 1 message includes the IE "BCCH Modification Information". Upon receiving this
notification from the UTRAN, the UE shall read the relevant MIB and/or SIB(s) subsequently during
idle mode.
Reference: 3GPP TS 25.331 clause 8.1. 2.
Pre-requsites:
NW: 1 cell.
UE: Idle state (state 2 or state 3 or state 7) as specified in clause 7.4 of TS 34.108 with a CN
UE identity, depending on the CN domain(s) supported by the UE.
Test Procedure:
The NW transmits a PAGING TYPE 1 message. This message addresses the UE using its (P)TMSI
and the "paging cause" IE set to a terminating call type that is supported by the UE. The UE shall
respond with RRC CONNECTION REQUEST message. Then NW shall transmit RRC CONNECTION
REJECT message to UE.
The NW transmits a PAGING TYPE 1 message on the paging occasions assigned to the UE. The
message shall include the IE "BCCH Modification Information" indicating the time when the first
modified master information block is available. Before the starting time, NW continuously broadcast
the original MASTER INFORMATION BLOCK and various types of SYSTEM INFORMATION BLOCK
on the BCCH mapped to BCH transport channel. NW maintains this status until the SFN which
corresponds to the modification time is reached. Then it transmits the new master information block
followed by the new SYSTEM INFORMATION BLOCK TYPE 5 message. In the new SIB TYPE 5
message, the IE "Available Signature" is different when compared to the original SIB TYPE 5
message.
At the paging occasion, NW transmits a new PAGING TYPE 1 message. This message addresses the
UE using its (P)TMSI and the "paging cause" IE set to a terminating call type that is supported by the
UE. The UE shall respond with RRC CONNECTION REQUEST message. Then NW shall transmit
RRC CONNECTION REJECT message to UE.
Test Verification:
To confirm that the UE checks the new value tag of the master information block and reads the
updated SYSTEM INFORMATION BLOCK messages after it receives a PAGING TYPE 1 message
which includes the IE "BCCH Modification Information".


Message Flow:

UE NW
1 Void
2 PAGING TYPE 1 NW transmits the message
includes the IE "BCCH
Modification Information", with
the "Value Tag" changed from
the "MIB Value Tag" of the
current Master Information
Block. Also the modification
time is set to 4088 radio frame
from the current SFN. NW
continuously broadcast the
same MASTER
INFORMATION BLOCK and
various types of SYSTEM
INFORMATION BLOCK on
BCCH for a period stretching
4087 frames.
3 MASTER INFORMATION BLOCK NW starts to transmit the MIB
with the "MIB Value Tag" IE
different from the original
setting.
SYSTEM INFORMATION BLOCK
TYPE 5 At the same time, NW starts to
transmit the affected SIB TYPE
5 messages continuously. The
IE "Available Signature" is
changed from "0000 0000 1111
1111(B)" to "1111 1111 0000
0000(B)".
NW starts to monitor the uplink

RACH after approximately
4087 frames from step 2.
4 PAGING TYPE 1 NW starts to transmit this
message continuously on the
PCCH at the correct paging
occasion.
6 RRC CONNECTION REJECT
Remarks:
After step 4 the UE shall transmit RRC CONNECTION REQUEST messages in response to the
PAGING TYPE 1 messages sent in step 4.


B_8.1.1.5 Paging for Notification in connected mode (CELL_PCH)
Test Purpose:
When a system information block on the BCCH is modified, the message PAGING TYPE 1 can be
sent on the PCCH to inform UE in the CELL_PCH state about this change. This message includes the
IE "BCCH Modification Information". Upon receiving this notification from the UTRAN, the UE shall
read the relevant MIB and/or SIB(s) subsequently while in CELL_PCH state.
Reference: 3GPP TS 25.331 clause 8.1. 2.
Pre-requisites:
NW: 1 cell.
UE: CELL_PCH state (state 6-12) as specified in clause 7.4 of TS 34.108 with valid a U-RNTI
assigned to it.
Test Procedure:
The NW transmits a PAGING TYPE 1 message on the paging occasions assigned to the UE. The
message shall include the IE "BCCH Modification Information" indicating the time when the first
modified master information block is available. Before the starting time, NW continuously broadcast
the original MASTER INFORMATION BLOCK and various types of SYSTEM INFORMATION BLOCK
on the BCCH mapped to BCH transport channel. NW maintains this status until the SFN, which
corresponds to the modification time, is reached. Then it transmits the new master information block
followed by the new SYSTEM INFORMATION BLOCK TYPE 5 message. In the new SIB TYPE 5
message, the IE "Available Signature" is different when compared to the original SIB TYPE 5
message. At the paging occasion, NW transmits a new PAGING TYPE 1 message. This message
addresses the UE using its U-RNTI. The UE shall respond with a CELL UPDATE message and set IE
"cell update cause" to "paging response".
Test Verification:
To confirm that the UE, checks the new value tag of the master information block, and read the
SYSTEM INFORMATION messages after it receives a PAGING TYPE 1 message which includes the
IE "BCCH Modification Information".


Message Flow:

UE NW
1 Void
2 PAGING TYPE 1 NW transmits the paging
message which comprises IE
"BCCH Modification
Information", with the "Value
Tag" changed from the "MIB
Value Tag" of the current
Master Information Block. Also
the modification time is set to
4088 radio frame from the
current SFN. NW continuously
broadcast the same MASTER
INFORMATION BLOCK and
various types of SYSTEM
INFORMATION BLOCK on
BCCH for a period stretching
4087 frames.
3 MASTER INFORMATION BLOCK NW starts to transmit the MIB
with the "MIB Value Tag" IE
different from the original
setting.
SYSTEM INFORMATION BLOCK
TYPE 5 At the same time, NW starts to
transmit the affected SIB TYPE
5 continuously. The value of IE
"Available Signature" is
changed from "0000 0000 1111
1111(B)" to "1111 1111 0000
0000(B)".
NW starts to monitor the uplink

RACH after approximately
4087 SFN from step 2.
4 PAGING TYPE 1 NW transmits this message
continuously on the PCCH at
the correct paging occasion.
5 CELL UPDATE
Remarks:
After step 4 the UE shall transmit a CELL UPDATE message with IE "cell update cause" set to "paging
response".


B_8.1.1.7 Paging for Connection in connected mode (CELL_DCH)
Test Purpose:
This procedure is used to transmit a PAGING TYPE 2 message from the network to selected UE in
CELL_DCH state using the dedicated control channel (DCCH). The UE listens to it and responds to
this message accordingly.
When UE receives an invalid PAGING TYPE 2 message, UE shall perform procedure specific error
handling.
Pre-requisites:
NW: 1 cell.
UE: CELL_DCH state (state 6-9 or state 6-10) as specified in clause 7.4 of TS 34.108 after
executing a location registration and/or attach procedure. The UE has been registered in both
CS and PS domains.
Test Procedure:
The NW transmits an invalid PAGING TYPE 2 message. UE shall respond by transmitting a RRC
STATUS message on the DCCH using RLC-AM mode. Finally, NW transmits a PAGING TYPE 2
message, which includes a matched Paging Record Type Identifier. In the CS domain the UE shall
respond to this message by the transmission of an INITIAL DIRECT TRANSFER message. In the PS
Domain the UE will locally detach and then initiate a GPRS attach procedure (as per clause 4.7.9.1.2
of TS 24.008) also involving the transmission of an INITIAL DIRECT TRANSFER message..
Test Verification:
To confirm that the UE responds to a PAGING TYPE 2 message which includes IE "Paging Record
Type Identifier" for the UE.
To confirm that the UE responds with a RRC STATUS message after it received an invalid PAGING
TYPE 2 message.
Message Flow:

UE NW
1 Void
2 PAGING TYPE 2 See message content.
3 RRC STATUS The UE shall respond by
reporting the protocol error to
the NW.
4 PAGING TYPE 2 NW pages the UE with a
matched identifier and with a
valid "paging cause" IE.
5 UPLINK DIRECT TRANSFER The UE shall respond to the
paging message sent in step 3.
Remarks:
After step 2 the UE shall respond to the paging message by transmitting RRC STATUS on the DCCH,
stating the protocol error as "ASN.1 violation or encoding error".


After step 4 the UE shall respond to the paging message by transmitting an UPLINK DIRECT
TRANSFER message on the uplink DCCH.


B_8.1.2.1 RRC / RRC Connection Establishment in CELL_DCH state: Success
Test Purpose:
The purpose of this test is to verify that the UE leaves the Idle Mode and correctly establishes a
signalling link on the DCCH.
Pre-requisites:
NW: 1 cell
UE: Idle state (state 2 or state 3 or state 7) as specified in clause 7.4 of TS 34.108 ,depending
on the CN domain(s) supported by the UE.
Test Procedure:
The UE transmits an RRC CONNECTION REQUEST message to the NW on the uplink CCCH by
attempting to make an outgoing call. After NW receives this message, it assigns the necessary radio
resources and U-RNTI to be used by the UE. NW then transmits an RRC CONNECTION SETUP
message containing an IE "Initial UE Identity" that does not match the IE "Initial UE Identity" in the
most recent RRC CONNECTION REQUEST message sent by the UE. UE receives the RRC
CONNECTION SETUP message within timer T300 but discards it due to the IE "Initial UE Identity"
mismatch. UE shall wait for timer T300 to time out before re-transmitting a RRC CONNECTION
REQUEST message to the NW. NW again assigns the necessary radio resources and U-RNTI. NW
then follows by transmitting a RRC CONNECTION SETUP message containing an IE "Initial UE
Identity" that matches the IE "Initial UE Identity" in the most recent RRC CONNECTION REQUEST
sent by the UE. NW then waits for the UE to transmit an RRC CONNECTION SETUP COMPLETE
message on the DCCH.
Test Verification:
Message Flow:

UE NW
1 RRC CONNECTION REQUEST By outgoing call operation
2 RRC CONNECTION SETUP This message is not addressed
to the UE.
Only if possible with NW
3 RRC CONNECTION REQUEST UE shall re-transmit the request
message again after a time out
of T300 from step 1.
Only if possible with NW
3a NW checks IE UE Specific
Behaviour Information 1 idle is
not included in received RRC
CONNECTION REQUEST
message.
5 The UE configures the layer 2
and layer 1.
COMPLETE

Remarks:
After step 2 the UE shall re-transmit the RRC CONNECTION REQUEST message again in order to
continue the RRC connection establishment procedure.
After step 6 the UE shall establish an RRC connection and continue the procedure of the outgoing call
on the DCCH.


E_8.1.2.4 RRC / RRC Connection Establishment: Reject ("wait time" is not equal to 0)
Test Purpose:
The purpose of this test is to verify that the UE retries to establish the RRC connection aft er the "wait
time" if the UE receives an RRC CONNECTION REJECT message which includes the IE "wait time"
not set to 0.
To confirm that the UE performs a cell reselection when receiving an RRC CONNECTION REJECT
message, containing relevant frequency information of the target cell to be re-selected.
Pre-requisites:
Configuration: B, C
NW: 2 cells both cell 1 and cell 2 are active and suitable for camping, but cell 1 is
transmitted using a larger power. Cell 1 and cell 2 are being transmitted from different 2
UARFCNs.
UE: Idle state (state 2 or state 3 or state 7) as specified in clause 7.4 of TS 34.108 ,depending
Test Procedure:
The UE transmits an RRC CONNECTION REQUEST message to the NW on the uplink

CCCH by an outgoing call operation in cell 1.
NW rejects the first request by transmitting an RRC CONNECTION REJECT message which
indicates a non-zero wait time. In this message, frequency information for cell 2 is available.
NW then waits for RRC CONNECTION REQUEST message on the uplink CCCH of cell 2.
The tester will also monitor the uplink of cell 1 simultaneously to ensure that all transmission
activities from cell 1 have ceased.
When the UE has successfully camp onto cell 2, it shall send an RRC CONNECTION
REQUEST with the same establishment cause as its previous attempt in cell 1.
NW responds with an RRC CONNECTION REJECT message, indicating a non-zero "wait
time" and omitting the IE "Redirection Info".
The UE shall observe the wait time period indicated. After the wait time has elapsed, the UE
shall re-transmit RRC CONNECTION REEQUEST again.
Finally, NW transmits an RRC CONNECTION SETUP message to establish an RRC
connection with the UE, and the UE replies with an RRC CONNECTION SETUP COMPLETE
message and enters CELL_DCH state.
Test Verification:


Message Flow:

UE NW
1 RRC CONNECTION REQUEST NW prompts the operator to
make an outgoing call in cell 1.
2 RRC CONNECTION REJECT This message shall includes
the IE "wait time" set to 15
seconds and IE "frequency
info" set to the UARFCN of cell
2.
3 NW waits for a period of time
sufficient for UE to reselect to
cell 2. At the same time, it
monitors the uplink of cell 1 to
make sure that all
transmissions have ceased.
4 RRC CONNECTION REQUEST UE shall attempt to re-start an
RRC connection establishment
procedure in cell 2. The
establishment cause shall
remain unchanged.
5 RRC CONNECTION REJECT This message shall include the
IE "wait time" set to 15
seconds, but with IE
"Redirection Info" absent.
6 RRC CONNECTION REQUEST NW waits until the duration
specified in IE "wait time" has
elapsed and then listens to the
uplink CCCH for a second RRC
CONNECTION REQUEST
message.
7 RRC CONNECTION SETUP NW sends the message to UE,
to setup an RRC connection
with the UE.
8 The UE shall configure the
layer 2 and layer 1 in order to
access the uplink and downlink
DCCH assigned.
COMPLETE
Remarks:
After step 3 the UE shall have successfully re-selected to cell 2, using information transmitted in IE
"frequency info" of RRC CONNECTION REJECT message. UE shall trigger the start of RRC
connection establishment by transmitting RRC CONNECTION REQUEST. The establishment cause
shall be similar to the message sent in step 1.
After step 5 the UE shall observe the period specified in IE "wait time" of an RRC CONNECTION
REJECT message and not transmit an RRC CONNECTION REQUEST message in this period.
After step 7 the UE shall transmit an RRC CONNECTION SETUP COMPLETE message to NW on
uplink DCCH and then establish an RRC connection.


B_8.1.3.1 RRC / RRC Connection Release in CELL_DCH state: Success
Test Purpose:
The purpose of this test is to verify that the UE releases the L2 signalling link and dedicated resources
and goes back to the idle state after it receives an RRC CONNECTION RELEASE message from the
NW and transmits an RRC CONNECTON RELEASE COMPLETE message to the NW for N308 times
at the interval specified by the value of T308 timer. Reference: 3GPP TS 25.331 clause 8.1.3.
Pre-requisites:
NW: 1 cell
UE: CELL_DCH state (state 6-1 or state 6-3) as specified in clause 7.4 of TS 34.108,
depending on the CN domain(s) supported by the UE
Test Procedure:
The UE is brought to the CELL_DCH state by prompting the operator to initiate an outgoing call. After
the DCCH is established, NW transmits an RRC CONNECTION RELEASE message to the UE to
disconnect the connection. NW then waits for the UE to transmit an RRC CONNECTION RELEASE
COMPLETE message using unacknowledged mode. NW checks to see if P such messages has been
received at each expiry of T308 timer. P is equal to the value of IE "Number of RRC Message
Transmissions" in an RRC CONNECTION RELEASE message.
Test Verification:
Message Flow:

UE NW
1 The UE is in the CELL_DCH
state after a successful RRC
connection establishment by
virtue of the operator making
an outgoing call.
2 RRC CONNECTION RELEASE NW disconnect the
connection established. The
value in IE "Number of RRC
Message Transmissions" is
arbitrarily chosen from 4 to 8
and denoted by P.
3 RRC CONNECTION RELEASE NW waits for the arrival of
COMPLETE N308 such message at the
expiry of each T308 timer,
using unacknowledged
mode.
4 The UE releases L2
signalling link and dedicated
resources. Then the UE goes
to idle mode.


Remarks:
After step 2 the UE shall start to transmit P times RRC CONNECTION RELEASE COMPLETE
messages at the expiry of each T308 timer.
After step 3 the UE shall initiate the release L2 signalling link and dedicated resources, then it shall go
to idle mode.


B_8.1.3.2 RRC / RRC Connection Release using on DCCH in CELL_FACH state: Success
Test Purpose:
The purpose of this test is to verify that the UE releases the L2 signalling link and resources and goes
back to the idle state after it receives an RRC CONNECTION RELEASE message on downlink DCCH
from the NW. It shall transmit an RRC CONNECTON RELEASE COMPLETE message using
acknowledged mode on uplink DCCH to the NW.
Pre-requisites:
NW: 1 cell
UE: CELL_FACH state (state 6-2 or state 6-4) as specified in clause 7.4 of TS 34.108,
depending on the CN domain(s) supported by the UE.
Test Procedure:
The UE is brought to an initial state of CELL_FACH. After the successful establishment of the RRC
connection, the NW transmits an RRC CONNECTION RELEASE message to the UE to disconnect
the radio link. When the UE receives this message the UE transmits an RRC CONNECTION
RELEASE COMPLETE message using acknowledged mode to the NW. Finally, NW checks that the
UE performs proper release of all radio resources and then goes back to idle mode.
Test Verification:
Message Flow:

UE NW
1 The UE is brought to the
CELL_FACH state.
2 RRC CONNECTION RELEASE NW sends this message
using unacknowledged mode
RLC operations on the uplink
DCCH.
3 RRC CONNECTION RELEASE The UE transmits this
COMPLETE message using
acknowledged mode.
4 The UE releases L2
signalling link and radio
to idle mode.
Remarks:
After step 2 the UE shall transmit an RRC CONNECTION RELEASE COMPLETE message using
acknowledged mode then it shall receive a response for this message from the NW-RLC.
After step 3 the UE shall release its L2 signalling link and radio resources, then it shall go back to idle
mode.


E_8.1.3.3 RRC / RRC Connection Release using on CCCH in CELL_FACH state: Success
Test Purpose:
The purpose of this test is to verify that the UE releases all its radio resources upon the reception of a
RRC CONNECTION RELEASE message on the downlink CCCH, without transmitting RRC
CONNECTION RELEASE COMPLETE message on the uplink.
Reference: TS 25.331 clause 8.1.4.
Pre-requisites:
NW: 1 cell.
UE: CELL_FACH state (state 6-2 or state 6-4) as specified in clause 7.4 of TS 34.108,
Test Procedure:
The UE is brought to an initial state of CELL_FACH. After the successful establishment of the RRC
connection, NW transmits RRC CONNECTION RELEASE message on the downlink CCCH. The UE
shall terminate the RRC connection and release all radio resources allocated to it. NW monitors the
uplink DCCH and CCCH to verify that no transmission is detected.
Test Verification:
Message Flow:

UE NW
1 The UE is brought to the
CELL_FACH state.
2 RRC CONNECTION RELEASE NW transmits this message
on downlink CCCH.
3 NW waits for a period
equivalent to 60 seconds.
The UE shall not send any
response message on uplink
direction during this period. It
shall release the radio
resources allocated and
return to idle mode.
Remarks:
None


B_8.1.3.6 RRC Connection Release in CELL_DCH state (Frequency band modification):

Success
Test Purpose:
If the UE first receives an RRC CONNECTION RELEASE message in CELL_DCH state, it shall:
initialize the counter V308 to zero;
submit an RRC CONNECTION RELEASE COMPLETE message to the lower layers for transmission
using UM RLC on the DCCH to the UTRAN;
start timer T308 when the RRC CONNECTION RELEASE COMPLETE message is sent on the radio
interface.
If the timer T308 expires, the UE shall:

increment V308 by one;
if V308 is equal to or smaller than N308:

retransmit the RRC CONNECTION RELEASE COMPLETE message;
if V308 is greater than N308:

release all its radio resources;
enter idle mode;
perform cell-selection according to TS25.304;
procedure end;
Pre-requsites:
NW: 2 cellsCell 1 is active and cell 6 is inactive
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DCCH+DTCH_DCH (state 6-10) as specified in clause
7.4 of TS 34.108, depending on the CN domain(s) supported by the UE
Test Procedure:
Table 8.1.3.6
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
CPICH Ec dBm/ -55 -55 Off -55
3.84
MHz
Table 8.1.3.6 illustrates the downlink power to be applied for the 2 cells at various time instants of the
test execution. NW switches the power settings from columns "T0" to "T1", whenever the description
in multi-cell condition specifies the transmission power settings for cell 1 and cell 6.
The UE is in CELL_DCH state of cell 1 and the NW has configured its downlink transmission power
setting according to columns "T0" in table 8.1.3.6. The NW switches its downlink transmission power
settings to columns "T1" and transmits MEASUREMENT CONTROL message and add cell 6 into the
IE "inter-frequency cell info". The NW modify contents of SIB3 in cell 1 and cell 6. The NW transmits
an RRC CONNECTION RELEASE message. After the NW transmits an RRC CONNECTION
RELEASE message to the UE, the NW waits for the UE to transmit RRC CONNECTION RELEASE
COMPLETE messages using UM on DCCH and checks to see if N308+1 such messages has been
received. The UE leaves connected mode and enters idle mode in cell 1. The UE shall perform cell


reselection and camp on cell 6 after reading the system information. The NW calls for generic
procedure C.3 to check that UE is in Idle state.
Test Verification:
To confirm that when the UE receives an RRC CONNECTION RELEASE message the UE transmits
N308+1 RRC CONNECTION RELEASE COMPLETE messages using UM on DCCH.
To confirm that the UE enters into idle mode with performing cell-selection and selecting new cell
configured by NW.
Message Flow:

UE NW
1 The UE is in the CELL_DCH
state of cell 1 and the NW
has configured its downlink
transmission power setting
according to columns "T0" in
table 8.1.3.6.
2 The NW switches its
downlink transmission power
settings to columns "T1" in
table 8.1.3.6.
3 MEASUREMENT CONTROL The NW specifies inter-
frequency measurement for
cell 6.
4 System Information Block type 3 The NW modifies SIB 3 in
cell 6.
5 System Information Block type 3 The NW modifies SIB 3 in
cell 1 to indicate that the cell
is barred.
6 The NW waits for 5 s.
8 RRC CONNECTION RELEASE The NW waits for the arrival
COMPLETE of N308+1 such messages
send on UM RLC.
9 The UE releases signalling
radio bearer and dedicated
to idle mode in cell 1.
10 The UE select s cell 6 and
camp on it.
11 The NW waits for 15 s after
receiving the last RRC
CONNECTION
RELEASE COMPLETE
message.
12 CALL C.1 If the test result of C.1
indicates that UE is in
CELL_DCH state, the test
passes, otherwise it fails.


Remarks:
After step 6 the UE shall start to transmit N308 + 1 times RRC CONNECTION RELEASE COMPLETE
messages using UM on DCCH.
After step 11 the UE shall be in Idle mode in cell 6.


B_8.1.5.1 UE Capability in CELL_DCH state: Success
Test Purpose:
1. The UE CAPABILITY ENQUIRY message is sent by the UTRAN to request the UE to transmit
its capability information related to any radio access network that is supported by the UE or if
the UTRAN needs an update of the UE's UMTS capability information or of its inter-system
classmark.
2. When the UE receives a UE CAPABILITY ENQUIRY message, the UE transmits a UE
CAPABILITY INFORMATION message on the uplink DCCH. Then the UTRAN transmits a UE
CAPABILITY INFORMATION CONFIRM message.
3. If during the execution of UE capability update procedure, an invalid UE CAPABILITY
INFORMATION CONFIRM is received, the UE shall respond with RRC STATUS message and
decide whether to re-transmit UE CAPABILITY INFORMATION message by comparing its
internal counter against N304.
Reference: 3GPP TS 25.331 clauses 8.1.6 and 8.1.7.
Pre- Requsites:
Configurations: A, B, C, D, E, E, F
NW: 1 cell.
UE: CELL_DCH state (state 6-9 or state 6-10) as specified in clause 7.4 of TS 34.108,
Test Procedure:
The UE is brought to the CELL_DCH state after a successful outgoing call attempt. The NW transmits
an invalid UE CAPABILITY ENQUIRY message . This message lacks all IEs except IE "Message
Type". After receiving such a message, the UE shall report the error using RRC STATUS message
with the appropriate error cause specified. Then NW transmits a correct UE CAPABILITY ENQUIRY
message, the UE receives this message and transmits a UE CAPABILITY INFORMATION message
on the uplink DCCH which includes the "UE radio access capability" IE. The NW transmits a UE
CAPABILITY INFORMATION CONFIRM message to the UE to complete the test. Then NW initiates
another UE capability enquiry procedure. The UE shall reply with a UE CAPABILITY INFORMATION
message on the uplink DCCH. When NW receives this message, it transmits an invalid UE
CAPABILITY INFORMATION CONFIRM message. This message lacks all IEs except IE "Message
Type". The UE shall detect a protocol error and send RRC STATUS message to report this event.
After receiving RLC acknowledgement for this message, the UE shall re-transmit UE CAPABILITY
INFORMATION message on the uplink DCCH after the expiry of T304. NW completes this test by
transmitting an error-free UE CAPABILITY INFORMATION CONFIRM message similar to the
message sent in step 6.
Test Verification:
To confirm that the UE transmits a UE CAPABILITY INFORMATION message after it receives a UE

CAPABILITY ENQUIRY message from the NW. To confirm that the UE indicates an invalid message
reception when invalid UE CAPABILITY ENQUIRY and UE CAPABILITY INFORMATION CONFIRM
messages are received. The UE shall transmit RRC STATUS message with the correct error cause
value to NW.


Message Flow:

UE NW
1 The UE is brought to
CELL_DCH state after
an outgoing call has
been established
successfully.
2 UE CAPABILITY ENQUIRY See specific message
contents for this
message
3 RRC STATUS The IE "Protocol error
cause" found in IE
"Protocol error
information" shall be
set to "ASN.1 violation
or encoding error"
4 UE CAPABILITY ENQUIRY Use default message.
5 UE CAPABILITY INFORMATION Use default message.
6 UE CAPABILITY INFORMATION CONFIRM Use default message.
7 UE CAPABILITY ENQUIRY Same as in step 4.
8 UE CAPABILITY INFORMATION Shall be the same
message content as in
step 5.
9 UE CAPABILITY INFORMATION CONFIRM See specific message
contents for this
message
10 RRC STATUS UE shall detect an error
and then transmit this
message.
11 UE CAPABILITY INFORMATION UE shall re-transmit
this message after
T304 expires.
12 UE CAPABILITY INFORMATION CONFIRM NW sends an error-free
message to
acknowledge the
receipt of the uplink
message.
Remarks:
After step 2, the UE shall transmit a RRC STATUS message on the uplink DCCH, reporting the error
with protocol error cause set to "ASN.1 violation or encoding error".
After step 4 and 7 the UE shall transmit a UE CAPABILITY INFORMATION message on the uplink
DCCH to respond to the UE CAPABILITY ENQUIRY message.
After step 9, the UE shall transmit a RRC STATUS message on the uplink DCCH. The protocol error
cause shall be set to "ASN.1 violation or encoding error".
After step 10, the UE shall re-transmit the UE CAPABILITY INFORMATION message with a similar
content as in step 8 after the expiry of T304.


B_8.1.5.2 RRC / UE Capability in CELL_DCH state: Success after T304 timeout
Test Purpose:
The purpose of this test is to verify that the UE re-transmits a UE CAPABILITY INFORMATION
message until V304 is greater than N304, after the expiry of timer T304 when the UE cannot receive a
UE CAPABILITY INFORMATION CONFIRM message in response to a UE CAPABILITY
INFORMATION message.
Reference: 3GPP TS 25.331 clause 8.1.6 and 8.1.7.
Pre-requisites:
NW: 1 cell
CELL_DCH state (state 6-9 or state 6-10) as specified in clause 7.4 of TS 34.108, depending
Test Procedure:
The UE is brought to CELL_DCH state. When the NW transmits a UE CACAPABILITY ENQUIRY

message which includes the "Capability update requirement" IE, the UE shall reply with a UE
CAPABILITY INFORMATION message on the uplink DCCH which includes the "UE radio access
capability" IE. The NW does not transmits a UE CAPABILITY INFORMATION CONFIRM message to
the UE, resulting in the T304 timer to expire. The tester shall observe that the UE attempts to transmit
a UE CAPABILITY INFORMATION message again. The UE shall re-transmit N304 times, and NW
transmits a UE CAPABILITY INFORMATION CONFIRM message to answer the last request and
completes this test procedure.
Test Verification:
Message Flow:

UE NW
CELL_DCH state.
NW sets internal
counter K =0
2 UE CAPABILITY ENQUIRY Including the IE
"Capability update
requirement".
3 UE CAPABILITY INFORMATION Including the "UE radio
access capability".
4 If K is equal to N304,
then proceed to step 6.
5 The NW does not
transmit a response and
wait for T304 timer to
expire.
K=K+1 and goes to step
3.
6 UE CAPABILITY INFORMATION Use default meNWage
CONFIRM contents


Remarks:
After step 3 the UE shall re-transmits a UE CAPABILITY INFORMATION message on the uplink
DCCH, after each expiry of timer T304. The UE CAPABILITY INFORMATION message shall contain
IE "UE radio access capability" indicating the settings found in PIC/PIXIT statements. After (N304) re-
transmissions, the UE shall receive a UE CAPABILITY INFORMATION CONFIRM message.


B_8.1.5.4 RRC / UE Capability in CELL_FACH state: Success
Test Purpose:
The purpose of this test is to verify that the UE transmits an UE CAPABILITY INFORMATION
message after it receives a UE CAPABILITY ENQUIRY message from the NW. To confirm that the UE
indicates an invalid message reception when erroneous downlink UE CAPABILITY ENQUIRY and UE
CAPABILITY INFORMATION CONFIRM messages are received. The UE shall transmit RRC
STATUS message with the correct error cause value to NW.
Reference: 3GPP TS 25.331 clauses 8.1.6 and 8.1.7.
Pre-requisites:
NW: 1 cell
UE: CELL_FACH state (state 6-11) as specified in clause 7.4 of TS 34.108, depending on the
CN domain(s) supported by the UE.
Test Procedure:
The UE is brought to the CELL_FACH state after a successful outgoing call attempt. The NW
transmits an erroneous UE CAPABILITY ENQUIRY message containing invalid value in the IE
"Capability update requirement". After receiving such a message, the UE shall report an error using
RRC STATUS message with the appropriate error cause specified. Then NW transmits a UE
CAPABILITY ENQUIRY message which includes the IE "Capability update requirement". The UE
receives this message and transmits a UE CAPABILITY INFORMATION message on the uplink
DCCH, which includes the IE "UE radio access capability". The NW transmits a UE CAPABILITY
INFORMATION CONFIRM message to the UE to complete the UE capability enquiry procedure. Then
NW initiates another UE capability enquiry procedure by transmitting the same UE CAPABILITY
ENQUIRY message as in step 4. The UE shall reply with a UE CAPABILITY INFORMATION message
on the uplink DCCH. When NW receives this message, it transmits an erroneous UE CAPABILITY
INFORMATION CONFIRM message. The content of this message is lack of all IEs. The UE shall
detect a protocol error and send RRC STATUS message to report this event. After receiving the RLC
layer acknowledgement PDU for this message, the UE shall re-transmit UE CAPABILITY
INFORMATION message on the uplink DCCH by the expiry of T304. NW completes this test by
sending an error-free UE CAPABILITY INFORMATION CONFIRM message similar to the message
sent in step 6.
Test Verification:


Message Flow:

UE NW
CELL_FACH state after
an outgoing call has
been established
successfully.
2 UE CAPABILITY ENQUIRY See specific message
contents for this
message
3 RRC STATUS The IE "Protocol error
cause" found in IE
"Protocol error
information" shall be
set to "Information
element value not
comprehended"
4 UE CAPABILITY ENQUIRY Use default message.
5 UE CAPABILITY INFORMATION The message shall
include the IE UE
radio access capability
message
6 UE CAPABILITY INFORMATION CONFIRM Use default message.
7 UE CAPABILITY ENQUIRY Same as in step 4.
8 UE CAPABILITY INFORMATION The message content
shall be the same as in
step 5.
9 UE CAPABILITY INFORMATION CONFIRM See specific message
contents for this
message
10 RRC STATUS UE shall detect an error
and then transmit this
message on uplink
DCCH.
11 UE CAPABILITY INFORMATION UE shall re-transmit
this message after
T304's expiry.
12 UE CAPABILITY INFORMATION CONFIRM NW sends an error-free
message to
acknowledge the
receipt of the uplink
message.
Remarks:
After step 2, the UE shall transmit a RRC STATUS message on the uplink DCCH, reporting
the error with protocol error cause set to "Information element value not comprehended".
After step 4 the UE shall transmit a UE CAPABILITY INFORMATION message on the uplink
DCCH to respond to the downlink UE CAPABILITY ENQUIRY message.
After step 9, the UE shall transmit a RRC STATUS message on the uplink DCCH. The
protocol error cause shall be set to "ASN.1 violation or encoding error".
After step 10, the UE shall re-transmit the UE CAPABILITY INFORMATION message with a
similar content as in step 8.


B_8.1.9 RRC / Signalling Connection Release Request
Test Purpose:
The purpose of this test is to verify that the UE transmits a SIGNALLING CONNECTION RELEASE
INDICATION message after upper layer requests to release its signalling connection.
Pre-requisites:
NW: 1 cell
UE: Switched off (state 1) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE transmits an RRC CONNECTION REQUEST message to the NW on the uplink CCCH by
attempting to make an outgoing call Then the UE shall establish an RRC connection and transmit a
SERVICE REQUEST message or a CM SERVICE REQUEST message using the INITIAL DIRECT
TRANSFER message depending on supported CN domain. The NW does not respond to this
message, and the UE shall send a SIGNALLING CONNECTION RELEASE INDICATION message
which includes the CN domain identity with the same value as that in the INITIAL DIRECT TRANSFER
message.
Test Verification:
Message Flow:

UE NW
1 The UE initiates an outgoing
call.
2 RRC CONNECTION REQUEST .
4 The UE configures the layer 2
and layer 1.
COMPLETE
6 INITIAL DIRECT TRANSFER Depending on supported CN
(LOCATION UPDATING REQUEST) domain, includes SERVICE
REQUEST message ( PS
domain ) or CM SERVICE
REQUEST message ( CS
domain ) is emdedded in
INITIAL DIRECT TRANSFER
message.
7 The NW does not respond and
waits for T3317 ( PS domain) or
T3230+T3240 ( CS domain )
8 SIGNALLING CONNECTION
RELEASE REQUEST


Remarks:
After step 1 the UE shall initiate the LOCATION UPDATING procedure and establish an RRC
connection.
After step 7 the UE shall transmit a SIGNALLING CONNECTION RELEASE REQUEST
message which includes the same CN domain identity as that found in the INITIAL DIRECT
TRANSFER message.


B_8.1.11 Signalling Connection Release (Invalid configuration)
Test Purpose:
Upon reception of a SIGNALLING CONNECTION RELEASE message, the UE shall:
indicate the release of the signalling connection and pass the value of the IE "CN domain
identity" to upper layers;
remove the signalling connection with the identity indicated by the IE "CN domain identity"
from the variable ESTABLISHED_SIGNALLING_CONNECTIONS;
clear the entry for the SIGNALLING CONNECTION RELEASE message in the table
"Accepted transactions" in the variable TRANSACTIONS;
the procedure ends.
If radio access bearers for the CN domain indicated by the IE "CN domain identity" exist in the variable
ESTABLISHED_RABS, the UE shall:
transmit an RRC STATUS message on the uplink DCCH using AM RLC;

include the IE "Identification of received message"; and
set the IE "Received message type" to SIGNALLING CONNECTION RELEASE; and
set the IE "RRC transaction identifier" to the value of "RRC transaction identifier" in the entry
for the SIGNALLING CONNECTION RELEASE message in the table "Accepted transactions"
in the variable TRANSACTIONS and clear that entry;
include the IE "Protocol error information" with contents set to the value "Message not
compatible with receiver state";
when the RRC STATUS message has been submitted to lower layers for transmission:
continue with any ongoing processes and procedures as if the invalid SIGNALLING
CONNECTION RELEASE message has not been received.
Reference: 3GPP TS 25.331 clause 8.1.13.3 and 8.1.13.5.
Pre-requisites:
NW: 1 cell.
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS_DCCH+DTCH_DCH (state 6-10) as specified
in clause 7.4 of TS 34.108, depending on the CN domain(s) supported by the UE.
Test Procedure:
NW transmit MEASUREMENT CONTROL message to UE. In this message, NW requests UE to

perform traffic volume measurement. Key measurement parameters are as follows: measurement
quantity = "RLC Buffer Payload", report criteria = "periodic reporting criteria", reporting interval = "6
seconds", reporting amount = infinity. UE shall begin traffic volume measurements, and shall send
MEASUREMENT REPORT message after completing first measurement. UE shall send second
MEASUREMENT REPORT message 6 seconds after first MEASUREMENT REPORT message. Then
NW transmit SIGNALLING CONNECTION RELEASE message to UE. UE shall ignore the message
and send a RRC STATUS message to NW. Then the UE shall send MEASUREMENT REPORT
message to NW within the next 6 seconds.


Test Verification:
To confirm that the UE ignores the SIGNALLING CONNECTION RELEASE REQUEST message
which request the UE to release signalling connection of domain that contains established radio
access bearers.
To confirm that the UE transmit a RRC STATUS message to NW after detecting an invalid
configuration in the received message.
Message Flow:

UE NW
1 MEASUREMENT CONTROL Periodical traffic volume
measurement reporting is
requested.
2 MEASUREMENT REPORT
3 MEASUREMENT REPORT Time difference between earlier
and this MEASUREMENT
REPORT message should be 6
seconds.
4 SIGNALLING CONNECTION If the initial condition of the
RELEASE UE is state 6-9, set the IE
CN domain identity to CS
domain. If the initial
condition of the UE is state
6-10, set the IE CN domain
identity to PS domain.
5 RRC STATUS
6 MEASUREMENT REPORT This message should be
sent within 6 seconds after
the previous message.
Remarks:
After step 1 the UE shall transmit MEASUREMENT REPORT message twice at an interval of 6
seconds.
After step 4 the UE shall transmit a RRC STATUS message with protocol error cause set to Message
not compatible with receiver state.
After step 5 the UE shall transmit a MEASUREMENT REPORT within 6 seconds.


E_8.2.1.1 RRC / Radio Bearer Establishment for transition from CELL_DCH to CELL_DCH:
Test Purpose:
To confirm that the UE establishes a new radio bearer according to a RADIO BEARER SETUP
message received from the NW.
Pre-requisites:
NW: 1 cell
UE: CS-DCCH_DCH (state 6-5) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in the CELL_DCH state, after the test operator is prompted to make an out-going call.
Before step 1, only signalling radio bearers have been established. The NW transmits a RADIO
BEARER SETUP message to the UE after it sets up L1 including the start of tx/rx. This message
requests the establishment of RABs for carrying the traffic of the speech call. After the UE receives
this message, it configures them and establishes a radio bearer. Finally the UE transmits a RADIO
BEARER SETUP COMPLETE message using AM RLC. Then the UE and the NW enters the
communicating state. NW calls for generic procedure in clause C.3 of 3GPP TS 34-123-1 to check
that UE is in CELL_DCH state
Test Verification:
Message Flow:

UE NW
COMPLETE
3 CALL C.3 To confirm the
communication.
If the test result of C.3 of
3GPP TS 34.123-1 indicates
that UE is in CELL_DCH state,
the test passes, otherwise it
fails.
Note: Specific Message Contents refer to 3GPP TS 34.123-1 clause 8.2.1.1.4
Remarks:
After step 2 the UE shall communicate with the NW on the radio bearer for its implementation.


Failure (Unsupported configuration)
Test Purpose:
To confirm that the UE keeps its configuration and transmits a RADIO BEARER SETUP FAILURE
message in case of receiving a RADIO BEARER SETUP message which includes parameters of its
unsupported configuration
Pre-requisites:
NW: 1 cell
UE: CS-DCCH_DCH (state 6-5) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in the CELL_DCH state. The NW transmits a RADIO BEARER SETUP message as the
frequency cannot be supported by the UE. After the UE receives this message, it transmits a RADIO
BEARER SETUP FAILURE message on the DCCH using AM RLC which is set to "configuration
unsupported" in IE "failure cause"
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER SETUP Including the unsupported
configuration for the UE.
2 RADIO BEARER SETUP FAILURE The UE does not change the
configuration.
Remarks:
After step 1 the UE shall keep its configuration and transmit a RADIO BEARER SETUP FAILURE
message on the DCCH using AM RLC which is set to "configuration unsupported" in IE "failure cause


Failure (Physical channel Failure and successful reversion to old configuration)
Test Purpose:
To confirm that the UE reverts to the old configuration and transmits a RADIO BEARER SETUP
FAILURE message when the UE fails to configure the new radio bearer following detection of physical
channel failure after T312 expiry
Pre-requisites:
NW: 2 cell, cell 1 and 2
UE: CS-DCCH_DCH (state 6-5) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in the CELL_DCH state. The NW transmits a RADIO BEARER SETUP message to the UE
specifying a configuration on cell 2 but does not configure the new radio bearer. Then after T312
expiry, the UE reverts to the old configuration and transmits a RADIO BEARER SETUP FAILURE
message on the DCCH using AM RLC which is set to "physical channel failure" in IE "failure cause".
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER SETUP The NW does not configure
the new radio bearer stated in
the message.
2 The UE does not configure the
new radio bearer and reverts
to the old configuration.
3 RADIO BEARER SETUP FAILURE UE shall transmit this
message using the old RRC
signalling bearer operating in
RLC-AM mode.
Remarks:
After step 2 the UE shall revert to the old configuration and transmit a RADIO BEARER SETUP
FAILURE message on the DCCH using AM RLC which is set to "physical channel failure" in IE "failure
cause".


B_8.2.1.8 RRC / Radio Bearer Establishment for transition from CELL_DCH to CELL_FACH:
Success
Test Purpose:
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH_DCH (state 6-7) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in the CELL_DCH state, after the test operator is asked to initiate a packet-switched data
call. The NW transmits a RADIO BEARER SETUP message to the UE after it sets up L1. After the UE
receives this message, it configures them and establishes a radio bearer. Finally the UE transmits a
RADIO BEARER SETUP COMPLETE message using AM RLC. Then the UE and the NW enters the
communicating state. NW calls for generic procedure in clause C.2 of 3GPP TS 34.123-1 to check that
UE is in CELL_FACH state.
Test Verification:
Message Flow:
UE NW
1 RADIO BEARER SETUP NW requests delete test
operator is prompted to make
an outgoing packet-switched
data call.
2 The UE select PRACH and S-
CCPCH using SIB5 or SIB6
after entering CELL FACH
state.
COMPLETE
4 CALL C.2 To confirm the communication
between UE and NW, based
on the exchange of packets.
that UE is in CELL_FACH
state, the test passes,
otherwise it fails.
Remarks:
After step 3 the UE shall communicate with the NW on the radio bearer for its implementation.


B_8.2.1.10 RRC / Radio Bearer Establishment for transition from CELL_FACH to CELL_DCH:
Success
Test Purpose:
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH_FACH (state 6-8) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in the CELL_FACH state, after NW prompts the test operator to initiate a packet-switched
data call. The NW transmits a RADIO BEARER SETUP message to the UE after it sets up L1
including the start of tx/rx. After the UE receives this message, it configures them and establishes the
required radio bearers. Finally the UE transmits a RADIO BEARER SETUP COMPLETE message
using AM RLC. Then the UE and the NW enters the communicating state. NW calls for generic
procedure C.3 of 3GPP TS 34.123-1 to check that UE is in CELL_DCH state.
Test Verification:
Message Flow:

UE NW
COMPLETE
3 CALL C.3 To confirm the communication
3GPP TS34.123-1 indicates
fails.
Remarks:
After step 2 the UE shall communicate with the NW using the radio bearer indicated in RADIO
BEARER SETUP message. Particularly, NW shall be able to receive packet data using a terminal
equipment (TE) attached to the UE.


B_8.2.1.16 RRC / Radio Bearer Establishment for transition from CELL_FACH to CELL_FACH:
Success
Test Purpose:
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH_FACH (state 6-8) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in the CELL_FACH state, after the test operator is being prompted to make an outgoing
packet-switched call. The NW transmits a RADIO BEARER SETUP message to the UE after it sets up
L1 including the start of tx/rx. After the UE receives this message, it configures them and establishes a
radio bearer. Finally the UE transmits a RADIO BEARER SETUP COMPLETE message using AM
RLC. Then the UE and the NW enters the communicating state
Test Verification:
Message Flow:

UE NW
2 The UE select PRACH and S-
CCPCH using SIB5 or SIB6.
COMPLETE
4 To confirm the proper
establishment of the new radio
bearer by checking the packet
data exchanged between the
NW and a TE attached to the
UE.
Remarks:
After step 3 the UE shall communicate with the NW using the new radio bearer, this cans be
confirmed by the exchange of packet data between a terminal equipment (TE) attached to the UE and
the NW.


B_8.2.1.19 RRC / Radio Bearer Establishment from CELL_DCH to CELL_PCH: Success
Test Purpose:
To conform that the UE transmits a RADIO BEARER SETUP COMPLETE message and enters
CELL_PCH state after it received a RADIO BEARER SETUP message from NW and configured new
radio bearers.
Pre-requisites:
NW: 1 cell.
Test Procedure:
The UE is in the CELL_DCH state. The NW transmits a RADIO BEARER SETUP message. The UE
transmits RADIO BEARER SETUP COMPLETE message to the UE using AM RLC and enters into
CELL_PCH state. The NW transmits a PAGING TYPE 1 message, causing the UE to enter
CELL_FACH state and the UE shall transmit CELL UPDATE message on uplink CCCH with IE "Cell
update cause" set to "paging response".
Test Verification:
Message Flow:

UE NW
3 Configuration of Radio
Bearer after state transition.
4 PAGING TYPE 1 The NW transmits this
message included a matched
identity.
5 CELL UPDATE The UE is in CELL_FACH
state.
Remarks:
After step 1, the UE transmits RADIO BEARER SETUP COMPLETE message to the UE on uplink
DCCH using AM RLC.
After step 4, the UE shall transmit CELL UPDATE message on the CCCH.


B_8.2.1.20 RRC / Radio Bearer Establishment from CELL_DCH to URA_PCH: Success
Test Purpose:
To conform that the UE transmit a RADIO BEARER SETUP COMPLETE message and enters
URA_PCH state after it received a RADIO BEARER SETUP message from NW and configured the
new radio bearers.
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH_DCH (state 6-7) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in the CELL_DCH state. The NW transmits a RADIO BEARER SETUP message. The UE
transmits RADIO BEARER SETUP COMPLETE message to the UE using AM RLC and enters
URA_PCH state. The NW transmits a PAGING TYPE 1 message, causing the UE to enter
CELL_FACH state and the UE shall transmit CELL UPDATE message on uplink CCCH with IE "Cell
update cause" set to "paging response".
Test Verification:
Message Flow:

UE NW
3 Configuration of Radio
Bearer after state transition.
identity.
state.
Remarks:
After step 1, the UE transmits RADIO BEARER SETUP COMPLETE message to the UE on uplink
DCCH using AM RLC.
After step 4 the UE shall transmit CELL UPDATE message on the CCCH.


B_8.2.1.21 RRC connection establishment in CELL_DCH on another frequency
Test Purpose:
To confirm that the UE manages to synchronize on another frequency when so required by UTRAN in
the RRC CONNECTION SETUP message.
Pre-requisites:
Configurations: D, E, F
NW: 2 cells Cell 1 on UARFCN 1 and Cell 2 on UARFCN 2.
UE: Registered idle mode on CS (state 2) or Registered idle mode on PS (state 3) in cell 1 as
specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE. If the UE
supports both CS and PS domains, the initial state shall be Registered idle mode on CS/PS
(state 7).
Test Procedure:
The UE is initially in idle mode and is camping on cell 1. SIB 11 is broadcast in cell 1, and the
parameters used are as specified below. NW prompts delete the operator is prompted to make an
outgoing call of a supported traffic class. The UE shall transmit an RRC CONNECTION REQUEST on
the CCCH, and NW replies with the RRC CONNECTION SETUP, in which the IEs are set as
described below delete and a note saying: IE Frequency Info is set to cell 2 frequency The UE shall
send the RRC CONNECTION SETUP COMPLETE back to NW in cell 2 on the DPCH described in the
RRC CONNECTION SETUP message received from the NW.
Test Verification:
Message Flow:

UE NW
1 RRC CONNECTION REQUEST By outgoing call operation
3 The UE configures the layer
2 and layer 1
4 RRC CONNECTION SETUP This message is sent to on
COMPLETE the frequency indicated in the
RRC CONNECTION SETUP
message.
Remarks:
None


B_8.2.1.22 Radio Bearer Establishment for transition from CELL_DCH to CELL_FACH

Test Purpose:
1. To confirm that the UE transits from CELL_DCH to CELL_FACH according to the RADIO
BEARER SETUP message.
2. To confirm that the UE transmits RADIO BEARER SETUP COMPLETE message on the
uplink DCCH using AM RLC on a common physical channel in a different frequency.
Pre-requisites:
NW: 2 cellsCell 1 is active and cell 6 is inactive.
Test Procedure:
Table B_8.2.1.22
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
Table B_8.2.1.22 illustrates the downlink power to be applied for the 2 cells at various time instants of
the test execution. NW switches the power settings from columns "T0" to "T1", whenever the
description in multi-cell condition specifies the transmission power settings for cell 1 and cell 6.
The UE is in CELL_DCH state of cell 1 and the NW configures its downlink transmission power setting
according to columns "T0" in Table B_8.2.1.22. The NW switches its downlink transmission power
settings to columns "T1" and transmits MEASUREMENT CONTROL message in order for the UE to
know information of cell 6. The NW transmits a RADIO BEARER SETUP message including new
frequency information to the UE. After the UE receives this message, it transits from CELL_DCH in
cell 1 to CELL_FACH state in cell 6, and transmits CELL UPDATE with IE Cell update cause set to
cell reselection. Finally the UE transmits a RADIO BEARER SETUP COMPLETE message using AM
RLC in cell 6. The NW calls for generic procedure C.2 of 3GPP TS 34.123-1 to check that UE is in
CELL_FACH state.
Test Verification:


Message Flow:

UE NW
1 The initial state of UE is in
CELL_DCH state of cell 1 and
the NW has configured its
setting according to columns
"T0" in Table B_8.2.1.22.
2 The NW switches its downlink
transmission power settings to
columns "T1" in Table
B_8.2.1.22.
cell 6.
4 RADIO BEARER SETUP Including new frequency
information.
5 CELL UPDATE The IE "Cell update cause" is
set to "cell reselection".
6 CELL UPDATE CONFIRM Including the IE" New C-RNTI
CONFIRM
8 RADIO BEARER SETUP The UE selects PRACH and
COMPLETE S-CCPCH indicated in SIB5 or
SIB6 after entering CELL
FACH state in cell 6.
9 CALL C.2 If the test result of C.2 of
otherwise it fails.
Remarks:
After step 4 the UE shall transmit a CELL UPDATE message on the CCCH in cell 6.
After step 6 the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message on the
DCCH using AM RLC in cell 6.
After step 7 the UE shall transmit a RADIO BEARER SETUP COMPLETE message on the DCCH
using AM RLC in cell 6.
After step 8 the UE shall be in CELL_FACH state of cell 6.


B_8.2.1.23 Radio Bearer Establishment for transition from CELL_FACH to CELL_DCH

Test Purpose:
1. To confirm that the UE transits from CELL_FACH to CELL_DCH according to the RADIO
BEARER SETUP message.
2. To confirm that the UE transmits RADIO BEARER SETUP COMPLETE message on the
uplink DCCH using AM RLC on a dedicated physical channel in a different frequency.
Pre-requisites:
UE: CS-DCCH_FACH (state 6-6) or PS_DCCH_FACH (state 6-8) as specified in clause 7.4 of TS
34.108, depending on the CN domain(s) supported by the UE.
Test Procedure:
Table B_8.2.1.23
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
The UE is in CELL_FACH state of cell 1 and the NW has configured its downlink transmission power
setting according to columns "T0" in Table B_8.2.1.23. The NW switches its downlink transmission
power settings to columns "T1" and transmits a RADIO BEARER SETUP message including new
frequency information to the UE. After the UE receives this message, it configures them and
establishes the required radio access bearers and moves into cell 6. Finally the UE transmits a RADIO
BEARER SETUP COMPLETE message using AM RLC. The NW calls for generic procedure C.3 of
3GPP TS 34.123-1 to check that UE is in CELL_DCH state.
Test Verification:


Message Flow:

UE NW
CELL_FACH state of cell 1
and the NW has configured its
setting according to columns
"T0" in table B_8.2.1.23.
2 The NW switches its downlink
transmission power settings to
columns "T1" in table
B_8.2.1.23.
3 RADIO BEARER SETUP Including new frequency
information.
4 RADIO BEARER SETUP The UE sends this message in
COMPLETE cell 6.
fails.
Remarks:
After step 3 the UE shall transmit a RADIO BEARER SETUP COMPLETE message on the DCCH
After step 4 the UE shall be in CELL_DCH state of cell 6.


B_8.2.2.1 RRC / Radio Bearer Reconfiguration from CELL_DCH to

CELL_DCH: Success
Test Purpose:
RECONFIGURATION message, which indicates a hard handover to another UL scrambling code.
Pre-requisites:
NW: 1 cell.
7.4 of TS 34.108, depending on the CN domain(s) supported by the UE.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RECONFIGURATION message

to the UE, which commands a hard handover in the same cell to a new UL scrambling code to be
performed. The UE reconfigures the new physical channel and transmits a RADIO BEARER
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER UL scrambling code is
RECONFIGURATION modified.
2 RADIO BEARER
Remarks:
After step 1 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE message on
the new DPCH after the specified activation time has expired.


E_8.2.2.3 RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH: Failure

(Physical channel failure and reversion to old configuration)
Test Purpose:
To confirm that the UE reverts to the old configuration and transmits a RADIO BEARER
RECONFIGURATION FAILURE message on the DCCH using AM RLC if the UE fails to reconfigure
the radio bearer expires according to the RADIO BEARER RECONFIGURATION message before
timer T312.
Pre-requisites:
NW: 1 cell.
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DCCH+DTCH_DCH (state 6-10) as specified in
clause 7.4 of TS 34.108, depending on the CN domain(s) supported by the UE
Test Procedure:

including the new radio bearer parameters to the UE but it keeps its current dedicated physical
channel configuration. The UE shall revert to the old configuration. Then the UE shall transmit a
RADIO BEARER RECONFIGURATION FAILURE message on the DCCH using AM RLC, setting
value "physical channel failure" in IE "failure cause".
Test Verification:
Message Flow:
Step Direction Messa ge Comment

UE NW
1 RADIO BEARER
RECONFIGURATION
2 NW does not reconfigure L1.
3 RADIO BEARER The UE shall detect a failure
RECONFIGURATION FAILURE to reconfigure the new radio
bearer, and send this
message using the old radio
bearer configuration.
Remarks:
After step 2 the UE shall transmit a RADIO BEARER RECONFIGURATION FAILURE message on the
DCCH using AM RLC setting value "physical channel failure" in IE "failure cause".


B_8.2.2.8 RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_FACH: Success
Test Purpose:
To confirm that the UE establishes the reconfigured radio bearer(s) using common physical channel,
after UE receives a RADIO BEARER RECONFIGURATION message.
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH+DTCH_DCH (state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RECONFIGURATION message,

which invoke a transition from CELL_DCH to CELL_FACH. The UE reconfigures the radio bearers
and transmits a RADIO BEARER RECONFIGURATION COMPLETE message using AM RLC.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 RADIO BEARER The UE selects PRACH and
RECONFIGURATION COMPLETE S-CCPCH indicated in SIB5
and SIB6 after entering CELL
FACH state.
Remarks:
After step 1 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE message


B_8.2.2.10 RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_DCH: Success
Test Purpose:
RECONFIGURATION message.
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH+DTCH_FACH (state 6-11) as specified in clause 7.4 of TS 34.108
Test Procedure:
The UE is in CELL_FACH state. The NW transmits a RADIO BEARER RECONFIGURATION

message to the UE, The UE reconfigures the radio bearers and transmits a RADIO BEARER
RECONFIGURATION COMPLETE message using AM RLC.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER This message includes IE
RECONFIGURATION "Uplink DPCH Info"
Add a note: Set the IE RRC
State Indicator to CELL DCH
Add similar notes in the entire
section
2 Reconfiguration of radio
bearer
3 RADIO BEARER
Remarks:
the DCCH using AM RLC.


B_8.2.2.17 RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_FACH: Success
Test Purpose:
To confirm that the UE establishes radio bearers according to a RADIO BEARER

Pre-requisites:
NW: 2 cells Cell 1 and 2 are active.
UE: PS-DCCH+DTCH_FACH (state 6-11) as specified in clause 7.4 of TS 34.108. in cell 1.
Test Procedure:
Table B_8.2.2.17
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3.84 -60 - -75 -60
(FDD) MHz 75
the test execution. NW switches the power settings between columns T0 and T1, whenever the
description in multi-cell condition specifies a reverse in the transmission power settings for cell 1 and
cell 2.
The UE is in CELL_FACH state in cell 1. The NW transmits a RADIO BEARER RECONFIGURATION

message, which invoke a transition from CELL_FACH in the current cell to CELL_FACH in cell 2, to
the UE. The NW configures its downlink transmission power settings according to columns T1 in
Table B_8.2.2.17.The UE moves to cell 2 and configures the common physical channel and transmits
a RADIO BEARER RECONFIGURATION COMPLETE message using AM RLC.
Test Verification:


Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 The NW applies the downlink
transmission power settings,
according to the values in
columns T1 of table
B_8.2.2.17.
3 RADIO BEARER
Remarks:
After step 2 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE message


E_8.2.2.18 RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_FACH: Success

(Physical channel failure)
Test Purpose:
To confirm that the UE transmits RADIO BEARER RECONFIGURATION COMPLETE message in cell
2 after it completes a cell update procedure instigated by a RADIO BEARER RECONFIGURATION
message.
Pre-requisites:
NW: 2 cells Cell 1and 2 are active.

UE: PS-DCCH+DTCH_FACH (state 6-11) as specified in clause 7.4 of TS 34.108.
Test Procedure:
Table E_8.2.2.18
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH_Ec dBm -60 -75 -75 -60
(FDD) /3.84
MHz
Table E_8.2.2.18 illustrates the downlink power to be applied for the 2 cells at various time instants of
the test execution. NW switches the power settings between columns "T0" and "T1", whenever the
description in multi-cell condition specifies a reverse in the transmission power settings for cell 1 and
cell 2.
The UE is in CELL_FACH state in cell 1. On transmitting a RADIO BEARER RECONFIGURATION
message to the UE, the NW configures its downlink transmission power settings according to columns
"T1" in Table 8.2.2.18. The UE transmits a CELL UPDATE message on uplink CCCH with IE "Cell
update cause" set to "cell reselection". The NW shall transmit a CELL UPDATE CONFIRM message
on downlink CCCH after receiving CELL UPDATE message. UE transmit a UTRAN MOBILITY
INFORMATION CONFIRM message on the DCCH using AM RLC The UE transmits a RADIO
BEARER RECONFIGURATION COMPLETE message on the DCCH using AM RLC.
Test Verification:


Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 The NW applies the downlink
transmission power settings,
according to the values in
columns "T1" of Table
8.2.1.9.
3 CELL UPDATE The value "cell reselection"
shall be set in IE "cell update
cause".
4 CELL UPDATE CONFIRM See message content
CONFIRM
6 RADIO BEARER
Remarks:
After step 2 the UE shall transmit a CELL UPDATE message on the CCCH with IE "cell update cause"
After step 5 UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message on the DCCH
using AM RLC.
After step 6 UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE message on the
DCCH using AM RLC


B_8.2.2.21 RRC / Radio Bearer Reconfiguration from CELL_DCH to CELL_PCH: Success
Test Purpose:
To confirm that the UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message and
enters CELL_PCH state after it receives a RADIO BEARER RECONFIGURATION, which invoke the
UE to transit from CELL_DCH to CELL_PCH from NW.
Pre-requisites:
NW: 1 cell.
UE: PS-DCCH+DTCH_DCH(state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RECONFIGURATION message.
The UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message using AM RLC and
enters CELL_PCH state. The NW transmits a PAGING TYPE 1 message, causing the UE to enter
CELL_FACH state and the UE shall transmit a CELL UPDATE message on uplink CCCH with IE Cell
update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 RADIO BEARER
3 The UE is in CELL_PCH
state
identity.
state.
Remarks:
uplink DCCH using AM RLC.
After step 4 the UE shall transmit a CELL UPDATE message on the CCCH with IECell update cause
set to paging response.


B_8.2.2.22 RRC / Radio Bearer Reconfiguration from CELL_DCH to URA_PCH: Success
Test Purpose:
To confirm that the UE transmits a RADIO BEARER RECONFIGURATION COMPLETE and enters
URA_PCH state after it received a RADIO BEARER RECONFIGURATION message, which invoke the
UE to transit from CELL_DCH to URA_PCH from NW.
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH_DCH(state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RECONFIGURATION message.
The UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message using AM RLC and
enters into URA_PCH state. The NW transmits a PAGING TYPE 1 message and the UE shall enters
the CELL_FACH state after receiving this message. UE shall transmit a CELL UPDATE message with
IE Cell update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 RADIO BEARER
state.

identity.
state.
Remarks:
After step 4 the UE shall transmit a CELL UPDATE message on the CCCH with IE Cell update cause


B_8.2.2.23 RRC / Radio Bearer Reconfiguration from CELL_FACH to CELL_PCH: Success
Test Purpose:
To confirm that the UE transmits RADIO BEARER RECONFIGURATION COMPLETE message and
enters CELL_PCH state after it received a RADIO BEARER RECONFIGURATION message, which
invoke the UE to transit from CELL_FACH to CELL_PCH.
Pre-requisites:
NW: 1 cell
Test Procedure:
message. The UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message using
AM RLC and enters CELL_PCH state. The NW transmits a PAGING TYPE 1 message, causing the
UE to enter CELL_FACH state and the UE shall transmit a CELL UPDATE message on uplink CCCH
with IE Cell update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 RADIO BEARER
state.

identity.
state.
Remarks:


B_8.2.2.24 RRC / Radio Bearer Reconfiguration from CELL_FACH to URA_PCH: Success
Test Purpose:
To confirm that the UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message and
enters URA_PCH state after it receives a RADIO BEARER RECONFIGURATION message, which
invoke the UE to transit from CELL_FACH to URA_PCH.
Pre-requisites:
NW: 1 cell
Test Procedure:

message. The UE transmits a RADIO BEARER RECONFIGURATION COMPLETE message using
AM RLC and enters URA_PCH state. The NW transmits a PAGING TYPE 1 message, causing the UE
to enter CELL_FACH state and the UE shall transmit a CELL UPDATE message on uplink CCCH with
IE Cell update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 RADIO BEARER
state.

identity.
state.
Remarks:


E_8.2.2.25 RRC / Radio Bearer Reconfiguration for transition from CELL_FACH to CELL_DCH
including modification of previously signalled CELL_DCH configuration
Test Purpose:
To confirm that the UE applies a previously signalled configuration for CELL_DCH and in addition
modifies the parameters for which reconfiguration is requested in the RADIO BEARER
RECONFIGURATION message that is used to initiate transition from CELL_FACH to CELL_DCH
Pre-requisites:
NW: 1 cell
Test Procedure:
The UE is in CELL_FACH. The NW transmits a RADIO BEARER RECONFIGURATION message

including dedicated physical channel information to request the UE to transit from CELL_FACH to
CELL_DCH. Upon receiving this message, the UE establishes the radio bearer and transport channel
reconfiguration for CELL_DCH included in a previous RADIO BEARER SETUP message and modifies
the parameters for which reconfiguration was requested in the RADIO BEARER RECONFIGURATION
message. The UE transmits RADIO BEARER RECONFIGURATION COMPLETE message on the
DCCH using AM RLC.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER Initiates the transition from
RECONFIGURATION CELL_FACH to CELL_DCH
2 RADIO BEARER
Remarks:
After step 2 the UE shall transmit RADIO BEARER RECONFIGURATION COMPLETE message on


E_8.2.2.26 Radio Bearer Reconfiguration from CELL_DCH to CELL_DCH: Success

(Incompatible Simultaneous Reconfiguration)
Test Purpose:
To confirm that the UE ignores the subsequent security reconfiguration information which is
contained in the RADIO BEARER RECONFIGURATION message.
To confirm that the UE reconfigures according to the SECURITY MODE COMMAND
message.
To confirm that the UE transmits RADIO BEARER RECONFIGURATION FAILURE message
on the uplink DCCH using AM RLC.
To confirm that the UE transmits SECURITY MODE COMPLETE message on the uplink
DCCH using AM RLC.
Pre-requisites:
NW: 1 cell.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a SECURITY MODE COMMAND message. NW

then transmits a RADIO BEARER RECONFIGURATION message. The UE ignores the RADIO
BEARER RECONFIGURATION message and transmits a RADIO BEARER RECONFIGURATION
FAILURE message and configures the radio bearers according to the a SECURITY MODE
COMMAND message. On completion of ciphering reconfiguration, the UE shall transmit a SECUTIRY
MODE COMPLETE message on the DCCH using AM RLC.
Test Verification:
Message Flow:

UE NW
1 SECURITY MODE COMMAND This message includes IE
Ciphering mode info.
2 RADIO BEARER NW send this message before
RECONFIGURATION the activation time in step 1
expires. This message
includes IE Ciphering mode
info.
3 RADIO BEARER The UE ignores the ciphering
RECONFIGURATION FAILURE mode information in step 2.
Remarks:
After step 2 the UE shall transmit a RADIO BEARER RECONFIGURATION FAILURE message on the
DCCH using AM RLC and set the failure cause to incompatible simultaneous reconfiguration.
After step 3 the UE shall transmit a SECURITY MODE COMPLETE message on the DCCH using AM
RLC specified in step 1.

B_8.2.3.1 RRC / Radio Bearer Release for transition from CELL_DCH to CELL_DCH: Success
Test Purpose:
To confirm that the UE releases the existing radio bearer according to a RADIO BEARER RELEASE
message.
Pre-requisites:
NW: 1 cell
7.4 of TS 34.108. depending on the CN domain(s) supported by the UE.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RELEASE message to the UE.
The UE releases the radio access bearer and transmits a RADIO BEARER RELEASE COMPLETE
message on the uplink DCCH using AM RLC. NW calls for generic procedure C.3 of 3GPP TS 34.123-
1 to check that UE is in CELL_DCH state.
Test Verification:
Message Flow:

UE NW
2 RADIO BEARER RELEASE Release the radio bearer
COMPLETE
that UE is in CELL_DCH
otherwise it fails.
Remarks:
The UE shall transmit a RADIO BEARER RELEASE COMPLETE message.


B_8.2.3.7 RRC / Radio Bearer Release for transition from CELL_DCH to CELL_FACH:
Success
Test Purpose:
To confirm that the UE release the existing the radio bearer according to a RADIO BEARER
RELEASE message.
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH DCH (state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RELEASE message to the UE.
1 to check that UE is in CELL_FACH state.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER RELEASE NW releases the radio bearer
in the fashion specified in the
message and allocate
common channel resources to
carry the remaining radio
bearers.
2 The UE selects PRACH and
S-CCPCH indicated in SIB5
and SIB6 after entering CELL
FACH state.
The UE shall release on
delete dedicated channels,
and reconfigure the remaining
radio bearers using the
common channel.
COMPLETE
otherwise it fails.
Remarks:
The UE shall transmit a RADIO BEARER RELEASE COMPLETE message.


B_8.2.3.9 RRC / Radio Bearer Release for transition from CELL_FACH to CELL_DCH:
Success
Test Purpose:
To confirm that an UE, in state CELL_FACH, releases the radio access bearers using common
physical channel. After the release, it shall access the affected radio bearers on the DP CH.
Pre-requisites:
NW: 1 cell
Test Procedure:
The UE is in CELL_FACH state. The NW transmits a RADIO BEARER RELEASE message to the UE.
In this message, NW commands the UE to release radio access bearers on common physical
channel. At the same time, NW allocates DPCH to support the affected radio bearers. The UE shall
release the indicated radio access bearers and transmits a RADIO BEARER RELEASE COMPLETE
1 to check that UE is in CELL_DCH state.
Test Verification:
Message Flow:

UE NW
2 UE shall release the radio
access bearers carried by
common physical channel
COMPLETE
otherwise it fails.
Remarks:
The UE shall transmit a RADIO BEARER RELEASE COMPLETE message using the dedicated
physical channel allocated.


B_8.2.3.15 RRC / Radio Bearer Release for transition from CELL_FACH to CELL_FACH:
Success
Test Purpose:
To confirm that the UE release the existing the radio bearer(s) according to the RADIO BEARER
RELEASE message.
Pre-requisites:
NW: 1 cell
Test Procedure:
The UE is in CELL_FACH state. The NW transmits a RADIO BEARER RELEASE message to the UE.
1 to check that UE is in CELL_FACH state.
Test Verification:
Message Flow:

UE NW
2 Void
COMPLETE
4 RADIO BEARER The IE RAB information to
RECONFIGURATION reconfigure is included with
the same RAB identity as
was released with the
RADIO BEARER RELEASE
message.
5 RADIO BEARER The UE responds with
RECONFIGURATION FAILURE failure, in case the RB is
properly removed
otherwise it fails.
Remarks:
The UE shall transmit a RADIO BEARER RELEASE COMPLETE message using AM RLC on the
common physical channel.


B_8.2.3.18 RRC / Radio Bearer Release from CELL_DCH to CELL_PCH: Success
Test Purpose:
To confirm that the UE transmits a RADIO BEARER RELEASE COMPLETE before entering
CELL_PCH state after it received a RADIO BEARER RELEASE message and released its radio
access bearers.
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH DCH (state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RELEASE message. The UE
transmits RADIO BEARER RELEASE COMPLETE message using AM RLC and enters into
CELL_PCH state. NW calls for generic procedure C.4 of 3GPP TS 34.123-1 to check that UE is in
CELL_PCH state.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RELEASE
2 RADIO BEARER The UE sends this message
RELEASE COMPLETE before it completes state
transition.
NW waits 5 seconds to allow
the UE to read system
information before the next
step.
that UE is in CELL_PCH
otherwise it fails.
Remarks:
The UE transmits a RADIO BEARER RELEASE COMPLETE message on uplink DCCH using AM
RLC.


B_8.2.3.19 RRC / Radio Bearer Release from CELL_DCH to URA_PCH: Success
Test Purpose:
To confirm that the UE transmits a RADIO BEARER RELEASE COMPLETE before entering
URA_PCH state after it received a RADIO BEARER RELEASE message and released its radio
bearers.
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH_ DCH (state 6-10) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RELEASE message. The UE
transmits a RADIO BEARER RELEASE COMPLETE message using AM RLC and enters into
URA_PCH state. NW calls for generic procedure C.5 of 3GPP TS 34.123-1 to check that UE is in
URA_PCH state.
Test Verification:
Message Flow:

UE NW
1 RADIO BEARER
RELEASE
transition.
NW waits 5 seconds to allow
the UE to read system
information before the next
step.
that UE is in URA_PCH state,
fails.
Remarks:
The UE transmits a RADIO BEARER RELEASE COMPLETE message to the UE on uplink DCCH
using AM RLC.


B_8.2.3.20 Radio Bearer Release for transition from CELL_DCH to CELL_FACH (Frequency
band modification): Success
Test Purpose:
1. To confirm that the UE transits from CELL_DCH to CELL_FACH according to the RADIO
BEARER RELEASE message.
2. To confirm that the UE transmits RADIO BEARER RELEASE COMPLETE message on the
uplink DCCH using AM RLC on a common physical channel in a different frequency.
Pre-requisites:
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DTCH+DCCH_DCH (state 6-10) as specified in clause
7.4 of TS 34.108, depending to the CN domain(s) supported by the UE.
Test Procedure:
Table B_8.2.3.20
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
setting according to columns "T0" in Table B_8.2.3.20. The NW switches its downlink transmission
power settings to columns "T1" and then transmits MEASUREMENT CONTROL message in order for
the UE to know information of cell 6. The NW transmits a RADIO BEARER RELEASE message
including new frequency information to the UE. The UE releases the radio access bearer and moves
into cell 6. The UE transmits CELL UPDATE message with IE Cell update cause set to cell
reselection. NW then transmit CELL UDPATE CONFIRM with IE New C_RNTI. The UE shall
respond with an UTRAN MOBILITY INFORMATION CONFIRM message, and then transmits a RADIO
BEARER RELEASE COMPLETE message on the uplink DCCH using AM RLC. The NW calls for
generic procedure C.2 of 3GPP TS 34.123-1 to check that UE is in CELL_FACH state.
Test Verification:


Message Flow:

UE NW
CELL_DCH state of cell 1
and the NW has configured
its downlink transmission
power setting according to
B_8.2.3.20.
Table B_8.2.3.20.
cell 6.
4 RADIO BEARER RELEASE Including new frequency
information.
6 CELL UPDATE CONFIRM Including the IE" New C-
RNTI
CONFIRM
COMPLETE
otherwise it fails.
Remarks:
After step 7 the UE shall transmit a RADIO BEARER RELEASE COMPLETE message on the DCCH


B_8.2.3.21 Radio Bearer Release from CELL_DCH to CELL_PCH (Frequency band

Test Purpose:
To confirm that the UE transmits RADIO BEARER RELEASE COMPLETE message on the
To confirm that the UE transits from CELL_DCH to CELL_PCH according to the RADIO
BEARER RELEASE message.
To confirm that the UE releases the radio access bearer and selects a common physical
channel in a different frequency indicated by NW.
Pre-requisites:
NW: 2 cellsCells 1 is active and cell 6 is inactive.
Test Procedure:
Table B_8.2.3.21
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
setting according to columns T0 in table B_8.2.3.21. The NW switches its downlink transmission
power settings to columns T1 transmits MEASUREMENT CONTROL message in order for the UE to
know information of cell 6. The NW then transmits a RADIO BEARER RELEASE message including
new frequency information. The UE transmits a RADIO BEARER RELEASE COMPLETE message
using AM RLC and enters CELL_PCH state of cell 6, then the UE shall transmit CELL UPDATE
message on uplink CCCH with IE Cell update cause set to cell reselection, to complete the
procedure. The NW calls for generic procedure C.4 of 3GPP TS34.123-1 to check that UE is in
CELL_PCH state.
Test Verification:


Message Flow:

UE NW
B_8.2.3.21.
table B_8.2.3.21.
cell 6.
4 RADIO BEARER RELEASE Including new frequency
information.
transition. UE sends this
message in cell 1.
7 CELL UPDATE CONFIRM IE "RRC State Indicator" is
set to "CELL_PCH".
otherwise it fails.
Remarks:
After step 4 the UE shall transmit a RADIO BEARER RELEASE COMPLETE message on uplink
set to cell reselection in cell 6.
After step 8 the UE shall be in CELL_PCH state in cell 6.


B_8.2.4.1 RRC / Transport channel reconfiguration from CELL_DCH to CELL_DCH Success

with no transport channel type switching
Test Purpose:
To confirm that the UE reconfigures the channel configuration according to a TRANSPORT CHANNEL
RECONFIGURATION message, which also specifies a hard handover by changing the scrambling
code for the DPCH.
Pre-requisites:
NW: 1 cell
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DCCH+DTCH_ DCH (state 6-10) as specified in clause
7.4 of TS 34.108 depending on the CN domain(s) supported by the UE.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a TRANSPORT CHANNEL RECONFIGURATION

message to the UE, which includes new configuration parameters. The UE shall reconfigure the new
configuration and then transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE
message on the uplink DCCH using AM RLC.
Test Verification:
Message Flow:

UE NW
3 TRANSPORT CHANNEL UL scrambling code is
RECONFIGURATION modified,
Hard handover to cell 2.
Including UE information
elements("TFS"I)
5 TRANSPORT CHANNEL
Remarks:
The UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE message on the

DCCH using AM RLC.


E_8.2.4.5 Transport Channel Reconfiguration from CELL_DCH to CELL_DCH: Failure

(Incompatible simultaneous reconfiguration)
Test Purpose:
If the UE receives a TRANSPORT CHANNEL RECONFIGURATION message whilst reconfiguring

due to a radio bearer message other than TRANSPORT CHANNEL RECONFIGURATION, it shall
keep its configuration as if the TRANSPORT CHANNEL RECONFIGURATION message had not been
received.
Reference:
3GPP TS 25.331 clause 8.2.4.
Pre- requisites:
NW: 1 cell.
Test Procedure:

to the UE. The NW transmits a TRANSPORT CHANNEL RECONFIGURATION message before the
"activation time" indicated in the RADIO BEARER RECONFIGURATION message expires. When the
UE receives the TRANSPORT CHANNEL RECONFIGURATION message, the UE shall keep the
configuration as if it had not received the TRANSPORT CHANNEL RECONFIGURATION message
and shall transmit a TRANSPORT CHANNEL RECONFIGURATION FAILURE message on the DCCH
using AM RLC with IE "failure cause" set to "incompatible simultaneous reconfiguration". After the NW
acknowledges the TRANSPORT CHANNEL RECONFIGURATION FAILURE message, the UE
reconfigures the new physical channel configuration upon the activation time and transmits a RADIO
BEARER RECONFIGURATION COMPLETE message on DCCH using AM RLC.
Test verification:
To confirm that if the UE receives a TRANSPORT CHANNEL RECONFIGURATION message during

a reconfiguring procedure due to a radio bearer message other than a TRANSPORT CHANNEL
RECONFIGURATION, it shall keep its configuration as if the TRANSPORT CHANNEL
RECONFIGURATION message had not been received and complete the reconfiguration procedure
according to the previously received message.


Message Flow:

UE NW
1 RADIO BEARER Including IE "Uplink DPCH
RECONFIGURATION info".
2 TRANSPORT CHANNEL Sent before the time specified
RECONFIGURATION in IE "Activation Time Info" of
message in step 1 has
elapsed.
3 TRANSPORT CHANNEL The UE shall not change the
RECONFIGURATION FAILURE configuration due to the
reception of TRANSPORT
CHANNEL
RECONFIGURATION
message.
4 RADIO BEARER This message is on DCCH
RECONFIGURATION COMPLETE using AM RLC.
Remarks:
After step 2 the UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION FAILURE

message on the DCCH using AM RLC with IE "failure cause" set to "Incompatible simultaneous
reconfiguration".
After step 3 the UE transmit a RADIO BEARER RECONFIGURATION COMPLETE message on the
new configuration specified in step 1.


B_8.2.4.7 RRC / Transport channel reconfiguration from CELL_DCH to CELL_FACH: Success
Test Purpose:
To confirm that the UE reconfigures the channel according to a TRANSPORT CHANNEL

Pre-requisites:
NW: 1 cell
Test Procedure:
message to the UE and the UE performs a state transition from CELL_DCH to CELL_FACH in the
same cell. The UE then reconfigures the new channels according to this message and system
information messages. Finally, the UE shall transmit a TRANSPORT CHANNEL
RECONFIGURATION COMPLETE message using AM RLC.
Test Verification:
Message Flow:

UE NW
1 TRANSPORT CHANNEL IE "Uplink DPCH Info" and IE
RECONFIGURATION "Downlink DPCH Info" are not
specified.
2 UE shall perform the
reconfiguration
3 TRANSPORT CHANNEL
Remarks:
The UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE message on the



B_8.2.4.20 RRC / Transport channel Reconfiguration from CELL_DCH to CELL_PCH: Success
Test Purpose:
To confirm that the UE transmits a TRANSPORT CHANNEL RECONFIGURATION COMPLETE

message and enters CELL_PCH state after it receives a TRANSPORT CHANNEL
RECONFIGURATION message, which invoke the UE to transit from CELL_DCH to CELL_PCH
Pre-requisites:
NW: 1 cell
Test Procedure:

message, which invoke the UE to transit from CELL_DCH to CELL_PCH. The UE transmits a
TRANSPORT CHANNEL RECONFIGURATION COMPLETE message using AM RLC and enters
CELL_PCH state. The NW transmits a PAGING TYPE 1 message, causing the UE to enter
CELL_FACH state and the UE shall transmit a CELL UPDATE message on uplink CCCH with IE Cell
update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 TRANSPORT CHANNEL
RECONFIGURATION
2 TRANSPORT CHANNEL
RECONFIGURA TION COMPLETE
state.
identity.
state.
Remarks:
The UE shall transmit TRANSPORT CHANNEL RECONFIGURATION COMPLETE message on



B_8.2.4.25 Transport channel reconfiguration from CELL_FACH to CELL_DCH (Frequency band

Test Purpose:
1. To confirm that the UE transits from CELL_FACH to CELL_DCH according to TRANSPORT

CHANNEL RECONFIGURATION message.
2. To confirm that the UE transmits TRANSPORT CHANNEL RECONFIGURATION message on
the uplink DCCH using AM RLC on dedicated physical channel in a different frequency.
Pre-requisites:
Test Procedure:
Table B_8.2.4.25
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
The UE is in CELL_FACH state of ce11 1 and the NW has configured its downlink transmission power
setting according to columns "T0" in table B _8.2.4.25. The NW switches its downlink transmission
power settings to columns "T1" and transmits a TRANSPORT CHANNEL RECONFIGURATION
message, which includes new frequency information leading to a state transition from CELL_FACH to
CELL_DCH in cell 6. The UE shall reconfigure transport channel parameter and frequency band
according to this message. Finally, the UE transmits a TRANSPORT CHANNEL
RECONFIGURATION COMPLETE message using AM RLC in cell 6. The NW calls for generic
procedure C.3 of 3GPP TS 34.123-1 to check that UE is in CELL_DCH state.
Test Verification:


Message Flow:

UE NW
CELL_FACH state of cell 1
B_8.2.4.25.
table B_8.2.4.25.
3 TRANSPORT CHANNEL
RECONFIGURATION
4 Reconfiguration of transport
channel.
5 TRANSPORT CHANNEL The UE sends this message
RECONFIGURATION COMPLETE in cell 6.
otherwise it fails.
Remarks:
After step 4 the UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE

message on the DCCH using AM RLC in cell 6.
After step 5 the UE shall be in CELL_DCH state of cell 6.


B_8.2.5.1 RRC / Transport format combination Control in CELL_DCH: restriction
Test Purpose:
To confirm that the UE does not transmit any data on the DTCH for the user data radio bearer on the
uplink, following the reception of TRANSPORT FORMAT COMBINATION CONTROL message sent
from the NW, in which the IE " Restricted TrCH information Add is present.
Pre-requisites:
NW: 1 cell
UE: DCCH+DTCH_DCH (state 6-9 or state 6-10) as specified in clause 7.4 of TS 34.108, depending
PS case:
For the PS case the reference radio bearer configuration specified in TS 34.108, clause 6.10.3.4.1.26
(Interactive or background / UL:64 DL:64 kbps / PS RAB) is used.
RLC is configured for no discard.
Test Procedure:
a. The UE is in CELL_DCH state.

b. The NW close the UE test loop.
c. The NW transmits a TRANSPORT FORMAT COMBINATION CONTROL message using
AM_RLC on the DCCH, which indicates that only TF0 is allowed on the uplink for DCH
transport channel on the DTCH.
d. The NW transmits data to the UE..
e. The NW waits to check that no data is returned in uplink.
f. The NW transmits a TRANSPORT FORMAT COMBINATION CONTROL message using
AM_RLC on the DCCH, which enables all transport formats on the uplink for DCH transport
channel on the DTCH.
g. The NW checks that the sent data is returned from the UE.
Test Verification:


Message Flow:
PS paging procedure

UE NW
1 <-- SYSTEM INFORMATION (BCCH) Broadcast
2 <-- PAGING TYPE 1 (PCCH) Paging (PS domain, P-TMSI)
5 --> RRC CONNECTION SETUP COMPLETE RRC
(DCCH)
6a --> SERVICE REQUEST (DCCH) GMM
6b <-- SECURITY MODE COMMAND RRC see note 1
6c --> SECURITY MODE COMPLETE RRC see note 1
Note 1 Step 6b and Step 6c are inserted in order to stop T3317 timer in the UE, which starts after
transmitting SERVICE REQUEST message



UE NW
1 Paging Use the PS paging procedure for
testing of
PS reference radio bearer
configurations.
2 <-- ACTIVATE RB TEST MODE (DCCH) TC
3 --> ACTIVATE RB TEST MODE COMPLETE TC
(DCCH)
4 <-- RADIO BEARER SETUP (DCCH) RRC
5 --> RADIO BEARER SETUP COMPLETE (DCCH) RRC
6 <-- CLOSE UE TEST LOOP (DCCH) TC
UE test mode 1
RLC SDU size is for every active radio
bearer set to "UL RLC SDU size", as
specified for the sub-test.
7 --> CLOSE UE TEST LOOP COMPLETE (DCCH) TC
8 <-- TRANSPORT FORMAT COMBINATION RRC
CONTROL (DCCH) Transport format combinations is
limited to TF0 (no data)
9 <-- RLC SDU one RLC SDU of size 312 bits is sent
(payload size minus size of 7 bit
length indicator and expansion bit).
10 NW waits 5 seconds to secure that no

data is returned by the UE
11 <-- TRANSPORT FORMAT COMBINATION RRC
CONTROL (DCCH) All transport format combinations are
enabled
12 --> RLC SDU UE returns data
13 <-- OPEN UE TEST LOOP (DCCH) TC

14 --> OPEN UE TEST LOOP COMPLETE (DCCH) TC
15 RB RELEASE (DCCH) RRC
Optional step
16 <-- DEACTIVATE RB TEST MODE (DCCH) TC
Optional step
17 --> DEACTIVATE RB TEST MODE COMPLETE TC
(DCCH) Optional step
Remarks:
At step 10 no data shall be sent by the UE.

At step 13:
For PS case: NW shall receive one RLC SDU from the UE


B_8.2.6.1 RRC / Physical channel reconfiguration for transition from CELL_DCH to

CELL_DCH
(code modification): Success
Test Purpose:
To confirm that the UE reconfigures the physical channel parameters according to a PHYSICAL
CHANNEL RECONFIGURATION message received from the NW. After the reconfiguration, the UE
shall be able to communicate with the NW on the new physical channel.
Pre-requisites:
NW: 1 cell.
7.4 of TS 34.108, depending to the CN domain(s) supported by the UE.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a PHYSICAL CHANNEL RECONFIGURATION
message to the UE, which includes a new UL scrambling code. The UE shall reconfigure the physical
channel at the activation time specified in this message and transmits a PHYSICAL CHANNEL
RECONFIGURATION COMPLETE message on the uplink DCCH AM RLC after its transition.
Test Verification:
Message Flow:

UE NW
1 PHYSICAL CHANNEL Including new UL scrambling
RECONFIGURATION code.
2 PHYSICAL CHANNEL .
Remarks:
The UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message on the



E_8.2.6.2 Physical channel reconfiguration for transition from CELL_DCH to

CELL_DCH (code modification): Failure (Unsupported configuration)
Test Purpose:
The UE shall keep its old configuration when the UE receives a PHYSICAL CHANNEL
RECONFIGURATION message which includes an unsupported configuration and transmit a
PHYSICAL CHANNEL RECONFIGURATION FAILURE message on the DCCH using AM
RLC, with the reason "configuration unsupported" in IE "failure cause".
Pre-requisites:
NW: 1 cell.
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DCCH+DTCH_DCH (state 6-10) as specified
in clause 7.4 of TS 34.108, depending on the CN domain(s) supported by the UE..
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a PHYSICAL CHANNEL

RECONFIGURATION message to the UE, which includes configuration parameters
unsupported by the UE. The UE transmits a PHYSICAL CHANNEL RECONFIGURATION
FAILURE message on the DCCH using AM RLC which is set to "configuration unsupported"
in IE "failure cause".
Test Verification:
To confirm that the UE keeps its configuration and transmits a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC if the received
PHYSICAL CHANNEL RECONFIGURATION message includes unsupported configuration
parameters for the UE.
Message Flow:

UE NW
1 PHYSICAL CHANNEL Includes an configuration
RECONFIGURATION unsupported by the UE
2 PHYISICAL CHANNEL The UE shall not reconfigure
RECONFIGURATION FAILURE and continue to communicate
using the old configuration.
Remarks:
After step 1 the UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION FAILURE

message on the DCCH using AM RLC and set "configuration unsupported" in IE "failure
cause".



CELL_DCH (code modification): Failure (Physical channel failure and
reversion to old channel)
Test Purpose:
The UE shall revert to the old configuration when the UE fails to reconfigure the new physical
channel by the expiry of timer T312, and then transmit a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC indicating "physical
channel failure" in IE " failure cause".
Pre-Requisites:
NW: 1 cell.
in clause 7.4 of TS 34.108, depending on the CN domain(s) supported by the UE..
Test Procedure:
RECONFIGURATION message to the UE which includes new UL scrambling code. However,
the NW keeps its current dedicated physical channel configuration. The UE fails to
synchronise with the NW on the new physical channel and after T312 timer expires the UE
shall revert to the old configuration. Finally, the UE transmits a PHYSICAL CHANNEL
RECONFIGURA TION FAILURE message on the DCCH using AM RLC specifies "physical
channel failure" in IE "failure cause".
Test Verification:
To confirm that the UE reverts to the old configuration and transmits a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC if the UE fails to
reconfigure the new physical channel according to the received PHYSICAL CHANNEL
RECONFIGURATION message before timer T312 expiry.
Message Flow:
UE NW
1 PHYSICAL CHANNEL Including a new UL
RECONFIGURA TION scrambling code for FDD.
2 The NW does not reconfigure
the physical channel so that
the UE fails to synchronise
on the new physical channel.
3 PHYSICAL CHANNEL After T312 expires, the UE
RECONFIGURATION FAILURE shall revert to the old
configuration and transmits
this message.
Remarks:
After step 2 the UE shall revert to the old configuration and transmit a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC, with
the value "physical channel failure" in IE "failure cause".



CELL_DCH (code modification): Failure (Incompatible simultaneous
reconfiguration)
Test Purpose:
If the UE receives a PHYSICAL CHANNEL RECONFIGURATION message whilst

reconfiguring due to a radio bearer message other than PHYSICAL CHANNEL
RECONFIGURATION SETUP, it shall keep its configuration as if the PHYSICAL CHANNEL
RECONFIGURATION SETUP message had not been received.
Pre-requests:
NW: 1 cell
in clause 7.4 of TS 34.108, depending on the CN domain(s) supported by the UE.
Test Procedure:
The UE is in CELL_DCH state. The NW transmits a RADIO BEARER RECONFIGURATION

message to the UE. The NW transmits a PHYSICAL CHANNEL RECONFIGURATION
message before the "activation time" indicated in the RADIO BEARER RECONFIGURATION
message expires. When the UE receives the PHYSICAL CHANNEL RECONFIGURATION
message, the UE shall keep the configuration as if it had not received the PHYSICAL
CHANNEL RECONFIGURATION message and shall transmit a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC with IE "failure cause"
set to "incompatible simultaneous reconfiguration". After the NW acknowledges the
PHYSICAL CHANNEL RECONFIGURATION FAILURE message, the UE reconfigures the
new physical channel parameters upon the activation time and transmits a RADIO BEARER
RECONFIGURATION COMPLETE message on DCCH using AM RLC.
Test Verification:
To confirm that if the UE receives a PHYSICAL CHANNEL RECONFIGURATION message

during a reconfiguring procedure due to a radio bearer message other than PHYSICAL
CHANNEL RECONFIGURATION, it shall keep its configuration as if the PHYSICAL
CHANNEL RECONFIGURATION message had not been received and complete the
reconfiguration procedure according to the previously received message.
Message Flow:

UE NW
1 RADIO BEARER
RECONFIGURATION
2 PHYSICAL CHANNEL Sent before the "Activation
RECONFIGURATION Time Info" specified in the
message in step 1 has
elapsed.
3 PHYSICAL CHANNEL The UE does not change the
RECONFIGURATION FAILURE configuration.


Remarks:

message on the DCCH using AM RLC with IE "failure cause" set to "Incompatible
simultaneous reconfiguration".
After step 4 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE
message using AM RLC on the DCCH.


B_8.2.6.7 RRC / Physical channel reconfiguration for transition from CELL_DCH to

CELL_FACH: Success
Test Purpose:
To confirm that the UE reconfigures a common physical channel according to the PHYSICAL
CHANNEL RECONFIGURATION message, which invoke the UE to transit from CELL_DCH
to CELL_FACH.
Pre-requisites:
Network: 1 cell
UE: PS-DCCH+DTCH_DCH (state 6-10) as specified in clause 7.4 of TS 34.108
Test Procedure:

RECONFIGURATION message to the UE. The UE shall then reconfigure the specified
common physical channel according to this message and the system information messages.
Following this, it shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message using AM RLC on the DCCH.
Test Verification:
Message Flow:

UE NW
1 PHYSICAL CHANNEL IE Uplink DPCH Info and IE
RECONFIGURATION Downlink DPCH Info are not
specified.
reconfiguration.
3 PHYSICAL CHANNEL
Remarks:
The UE shall transit from CELL_DCH to CELL_FACH and transmit a PHYSICAL CHANNEL
RECONFIGURATION COMPLETE message on the common physical channel.



CELL_FACH: Success (Cell re-selection)
Test Purpose:
The UE shall initiate the cell update procedure when the UE performs cell reselection during a
physical channel reconfiguration procedure. After the UE completes cell update procedure,
the UE shall continue to perform the physical channel reconfiguration procedure and correctly
reconfigure the physical channel.
Pre-requisites:
NW: 1 cell.
Test Procedure:
The UE is in CELL_DCH. The NW transmits a PHYSICAL CHANNEL RECONFIGURATION
message, which includes IE Primary CPICH info and no dedicated physical channel
information to invoke the UE to transit from CELL_DCH to CELL_FACH. As the UE cannot
detect the specified cell. The UE shall initiate the cell update procedure. The UE transmits
CELL UPDATE message on uplink CCCH with IE "Cell update cause" set to "cell reselection".
The NW shall transmit CELL UPDATE CONFIRM message on downlink CCCH after receiving
CELL UPDATE message. The UE then transmit a UTRAN MOBILITY INFORMATION
CONFIRM message on the DCCH using AM RLC. The UE transmits a PHYSICAL CHANNEL
Test Verification:
To confirm that the UE transmits a PHYSICAL CHANNEL RECONFIGURATION FAILURE

message after the UE completes a cell update procedure.
Message Flow:

UE NW
1 PHYSICAL CHANNEL This message include IE
RECONFIGURATION "Primary CPICH info"." for
FDD.
2 CELL UPDATE The value "cell reselection"
shall be set in IE "Cell
update cause".
CONFIRM
5 PHYSICAL CHANNEL


Remarks:
After step 1 the UE shall transmit a CELL UPDATE message on the CCCH with IE "Cell
update cause" set to "cell reselection".
After step 4 UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message on
After step 5 UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message on the DCCH using AMRLC.


B_8.2.6.9 RRC / Physical channel reconfiguration for transition from CELL_FACH to

CELL_DCH: Success
Test Purpose:
To confirm that the UE reconfigures a new physical channel according to a PHYSICAL

CHANNEL RECONFIGURATION message, which invoke UE to transit from CELL_FACH to
CELL_DCH
Pre-requisites:
Network: 1 cell
The UE has to have the information for the state CELL_DCH
Test Procedure:

RECONFIGURATION message to the UE to start a transit from CELL_DCH to CELL_FACH.
The UE shall reconfigure the common physical channel correctly according to this message.
To complete this procedure, the UE shall transmit a PHYSICAL CHANNEL
RECONFIGURATION COMPLETE message using AM RLC. The NW transmits a PHYSICAL
CHANNEL RECONFIGURATION message to the UE to invoke the UE to transit from
CELL_FACH to CELL_DCH. The UE shall reconfigure the new dedicated physical channel
correctly according to this message. To complete this procedure, the UE shall transmit a
PHYSICAL CHANNEL RECONFIGURATION COMPLETE message using AM RLC.
Test Verification:
Message Flow:

UE NW
reconfiguration.
2 PHYSICAL CHANNEL
RECONFIGURATION
3 The UE shall configure the
allocated dedicated physical
channels.
4 PHYSICAL CHANNEL
Remarks:
The UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION message on the
The UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION message on the new
dedicated physical channel.


E_8.2.6.10 Physical channel reconfiguration for transition from CELL_FACH to

CELL_DCH: Failure (Unsupported configuration)
Test Purpose:
The UE shall keep its old configuration when the it receives a PHYSICAL CHANNEL
RECONFIGURATION message, which specifies unsupported configuration parameters for
the UE. It shall then transmit a PHYSICAL CHANNEL RECONFIGURATION FAILURE
message on the DCCH using AM RLC, reporting the cause "configuration unsupported" in IE
" failure cause".
Reference 3GPP TS 25.331 clause 8.2.6
Pre-requisites:
NW: 1 cell
UE: PS-DCCH+DTCH_DCH(state 6-10) as specified in clause 7.4 of TS 34.108
The UE has to have the data for CELL_DCH state
Test Procedure:
RECONFIGURATION message to the UE to invoke the UE to transit from CELL_DCH to
CELL_FACH. The UE shall reconfigure the common physical channel correctly according to
this message. To complete this procedure, the UE shall transmit a PHYSICAL CHANNEL
CHANNEL RECONFIGURATION message to the UE, which includes unsupported frequency
for the UE. The UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION FAILURE
message on the DCCH using AM RLC, setting "configuration unsupported" in IE "failure
cause".
Test Verification:
To confirm that the UE keeps its configuration and transmits a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC, if the received
PHYSICAL CHANNEL RECONFIGURATION message includes unsupported configuration
parameters.
Message Flow:
UE NW
reconfiguration
2 PHYSICAL CHANNEL Includes unsupported
RECONFIGURATION frequencies for the UE
3 PHYISICAL CHANNEL The UE shall not change the
RECONFIGURATION FAILURE physical channel
configuration, this message
shall be sent using the old
configuration
Remarks:
RECONFIGURATION message on the common physical channel.
message on the DCCH using AM RLC, the IE "failure cause" shall be set to "configuration
unsupported".



CELL_DCH: Failure (Physical channel failure and successful reversion to old
configuration)
Test Purpose:
The UE shall revert to the old configuration when the UE fails to reconfigure the new physical
channel by timer T312 expiry. It shall report the failure by transmitting a PHYSICAL
CHANNEL RECONFIGURATION FAILURE message on the DCCH using AM RLC, indicating
"physical channel failure" in IE " failure cause".
Reference 3GPP TS 25.331 clause 8.2.6.
Pre-requisites:
NW: 1 cell
UE: DCCH+DTCH_FACH (state 6-11) as specified in clause 7.4 of TS 34.108
Test Procedure:

CHANNEL RECONFIGURATION message to the UE to invoke the UE to transit from
CELL_FACH to CELL_DCH. However, the NW keeps its current physical channel
configuration and then the UE cannot synchronise with the NW, After T312 expires, the UE
attempt to revert to the old configuration. Then the UE shall transmit a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC which is set "physical
channel failure" in IE "failure cause".
Test Verification:
To confirm that the UE reverts to the old configuration and transmits a PHYSICAL CHANNEL
RECONFIGURATION FAILURE message on the DCCH using AM RLC if the UE fails to
reconfigure the new physical channel according to a PHYSICAL CHANNEL
RECONFIGURATION message before the T312 expiry.


Message Flow:

UE NW
reconfiguration
2 PHYSICAL CHANNEL
RECONFIGURATION
3 The NW does not reconfigure
the physical channel, hence
the UE shall detect a failure
to reconfigure to the new
physical channel.
4 PHYSICAL CHANNEL After T312 expires, the UE
RECONFIGURATION FAILURE reverts to the old
configuration and transmits
this message.
Remarks:
message on the DCCH using AM RLC, specifying "physical channel failure" in IE "failure
cause".



CELL_DCH: Failure (Incompatible simultaneous reconfiguration)
Test Purpose:
If the UE receives a PHYSICAL CHANNEL RECONFIGURATION message whilst

reconfiguring due to a radio bearer message other than PHYSICAL CHANNEL
RECONFIGURATION, it shall keep its configuration as if the PHYSICAL CHANNEL
RECONFIGURATION message had not been received.
Reference 3GPP TS 25.331 clause 8.2.6
Pre-requisites:
NW: 1 cell
Test Procedure:

RECONFIGURATION COMPLETE message using AM RLC. The NW transmits a RADIO
BEARER RECONFIGURATION message to the UE. The NW transmits a PHYSICAL
CHANNEL RECONFIGURATION message before the "activation time" indicated in the
RADIO BEARER RECONFIGURATION message expires. When the UE receives the
PHYSICAL CHANNEL RECONFIGURATION message, the UE shall keep its configuration as
if it had not received the PHYSICAL CHANNEL RECONFIGURATION message and shall
transmit a PHYSICAL CHANNEL RECONFIGURATION FAILURE message on the DCCH
using AM RLC with IE "failure cause" set to "incompatible simultaneous reconfiguration". After
the UE transmits the PHYSICAL CHANNEL RECONFIGURATION FAILURE message, the
UE reconfigures the new physical channel parameters upon the activation time and transmits
a RADIO BEARER RECONFIGURATION COMPLETE message on DCCH using AM RLC.
Test Verification:
To confirm that if the UE receives a PHYSICAL CHANNEL RECONFIGURATION message

during a reconfiguring procedure due to a radio bearer message other than a PHYSICAL
CHANNEL RECONFIGURATION, it shall keep its configuration as if the PHYSICAL
CHANNE L RECONFIGURATION message had not been received and complete the
reconfiguration procedure according to the previously received message.


Message Flow:

UE NW
reconfiguration
2 RADIO BEARER
RECONFIGURATION
3 PHYSICAL CHANNEL Sent before the elapse of the
RECONFIGURATION frame number specified in IE
"Activation time " of the
message dispatched in step 2
4 PHYSICAL CHANNEL The UE does not change the
RECONFIGURATION FAILURE configuration due to the
reception of PHYSICAL
CHANNEL
RECONFIGURATION
message.
Remarks:
message on the DCCH using AM RLC with IE "failure cause" set to "Incompatible
simultaneous reconfiguration".
After step 4 the UE shall transmit a RADIO BEARER RECONFIGURATION COMPLETE
message on the DCCH using AM RLC.


B_8.2.6.19 RRC / Physical channel Reconfiguration from CELL_DCH to CELL_PCH:

Success
Test Purpose:
To confirm that the UE transmits a PHYSICAL CHANNEL RECONFIGURATION COMPLE TE

message and enter CELL_PCH state after it received a PHYSICAL CHANNEL
RECONFIGURATION message, which invokes the UE to transit from CELL_DCH to
CELL_PCH
Pre-requisites:
Network: 1 cell
UE: PS-DCCH+DTCH_DCH(state 6-10) as specified in clause 7.4 of TS 34.108
Test Procedure:

RECONFIGURATION message, which invokes the UE to transit from CELL_DCH to
CELL_PCH. The UE transmits a PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message using AM RLC and enters CELL_PCH state. The NW transmits a PAGING TYPE 1
message , causing the UE to enter CELL_FACH state and the UE shall transmit a CELL
UPDATE message on uplink CCCH with IE Cell update cause set to paging response.
Test Verification:
Message Flow:

UE NW
1 PHYSICAL CHANNEL
RECONFIGURATION
2 PHYSICAL CHANNEL
state.
message with a matched
identity.
state.
Remarks:
The UE shall transmits a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message

on the DCCH using AM RLC.
The UE shall transmit a CELL UPDATE message on the CCCH with IE Cell update cause


B_8.2.6.25 Physical channel reconfiguration for transition from CELL_DCH to

Test Purpose:
To confirm that the UE transits from CELL_DCH to CELL_FACH according to the

PHYSICAL CHANNEL RECONFIGURATION message.
To confirm that the UE transmits PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message on the uplink DCCH using AM RLC on a common physical
channel in a different frequency..
Pre-requisites:
Test Procedure:
Table B_8.2.6.25
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
Table B_8.2.6.25 illustrates the downlink power to be applied for the 2 cells at various time
instants of the test execution. NW switches the power settings from columns "T0" to "T1",
whenever the description in multi-cell condition specifies the transmission power settings for
cell 1 and cell 6.
The UE is in CELL_DCH state of cell 1 and the NW has configured its downlink transmission
power setting according to columns "T0" in table B_8.2.6.25. The NW switches its downlink
transmission power settings to columns "T1" and transmits MEASUREMENT CONTROL
message in order for the UE to know information of cell 6. The NW transmits a PHYSICAL
CHANNEL RECONFIGURATION message including new physical channel information. The
UE shall then reconfigure the specified common physical channel according to this message
and the system information in cell 6. Following this, it shall transmit CELL UPDATE message
with IE "Cell update cause" set to "cell reselection". Upon completion of the cell update
procedure, UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message using AM RLC on the DCCH in cell 6. The NW calls for generic procedure C.2 of
3GPP TS 34.123-1 to check that UE is in CELL_FACH state.
Test Verification:


Message Flow:

UE NW
B_8.2.6.25.
table B_8.2.6.25.
cell 6.
4 PHYSICAL CHANNEL Including new frequency
RECONFIGURATION information
6 CELL UPDATE CONFIRM Including the IE" New C-
RNTI
CONFIRM
8 PHYSICAL CHANNEL The UE selects PRACH and
RECONFIGURATION COMPLETE S-CCPCH indicated in SIB5
or SIB6 after entering CELL
FACH state.
otherwise it fails.
Remarks:
After step 6 the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message
on the DCCH using AM RLC in cell 6.
After step 7 the UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message on the DCCH using AM RLC in cell 6.


B_8.2.6.26 Physical Channel Reconfiguration from CELL_DCH to CELL_PCH

Test Purpose:
1. To confirm that the UE transmits PHYSICAL CHANNEL RECONFIGURATION

COMPLETE message on the uplink DCCH using AM RLC.
2. To confirm that the UE transits from CELL_DCH to CELL_PCH according to the
PHYSICAL CHANNEL RECONFIGURATION message.
3. To confirm that the UE releases a dedicated physical channel and selects a common
physical channel in a different frequency.
Pre-requisites:
NW: 2 cellsCell 1 is active and cell 6 is inactive
Test Procedure:
Table B_8.2.6.26
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
3.84
MHz
Table B_8.2.6.26 illustrates the downlink power to be applied for the 2 cells at various time
instants of the test execution. NW switches the power settings from columns "T0" to "T1",
whenever the description in multi-cell condition specifies the transmission power settings for
cell 1 and cell 6.
The UE is in CELL_DCH state of cell 1 and the NW has configured its downlink transmission
power setting according to columns "T0" in table B_8.2.6.26. The NW switches its downlink
transmission power settings to columns "T1" and transmits MEASUREMENT CONTROL
message in order for the UE to know information of cell 6. The NW transmits a PHYSICAL
CHANNEL RECONFIGURATION message, which invokes the UE to transit from CELL_DCH
to CELL_PCH and includes new frequency information. The UE transmits a PHYSICAL
CHANNEL RECONFIGURATION COMPLETE message using AM RLC and enters
CELL_PCH state of cell 6. Then, UE shall transmit CELL UPDATE message on uplink CCCH
with IE Cell update cause set to cell reselection. Upon completion of the procedure, the
NW calls for generic procedure C.4 of 3GPP TS 34.123-1 to check that UE is in CELL_PCH
state.
Test Verification:


Message Flow:

UE NW
B_8.2.6.26.
table B_8.2.6.26.
cell 6.
4 PHYSICAL Including new frequency
CHANNELRECONFIGURATION information.
5 PHYSICAL CHANNEL UE transmit this message in
RECONFIGURATION COMPLETE cell 1.
7 CELL UPDATE CONFIRM IE "RRC State Indicator" is
set to "CELL_PCH".
otherwise it fails.
Remarks:
After step 4 the UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE

message on the DCCH using AM RLC in cell 1.
set to cell reselection in cell 6.


B_8.2.6.27 Physical channel reconfiguration from CELL_FACH to CELL_PCH: Success
Test Purpose:
To confirm that the UE transmits PHYSICAL CHANNEL RECONFIGURATION COMPLETE

To confirm that the UE transits from CELL_FACH to CELL_PCH according to the PHYSICAL
CHANNEL RECONFIGURATION message.
To confirm that the UE replies with CELL UPDATE message in cell 6 when the NW transmits
PAGING TYPE 1 message to the UE.
Pre-requisites:
NW: 1 cell Cell 1 is active.
Test Procedure:
The UE is in CELL_FACH state of cell 1. The NW transmits a PHYSICAL CHANNEL

RECONFIGURATION message. The UE transmits a PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message using AM RLC and enters CELL_PCH state. The NW calls for generic
procedure C.4 of 3GPP TS 34.123-1 to check that UE is in CELL_PCH state.
Test Verification:
Message Flow:

UE NW
1 The UE is in CELL_FACH
state of cell 1.
2 PHYSICAL CHANNEL
RECONFIGURATION
3 PHYSICAL CHANNEL
otherwise it fails.
Remarks:
After step 2 the UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE

message on uplink DCCH using AM RLC.


B_8.3.1.1 Cell Update: cell reselection in CELL_FACH
Test Purpose:
This procedure is used to update UTRAN with the current cell of the UE after it has performed a cell
reselection in CELL_FACH state.
Pre-requisites:
Network: 1 RNC, 2 cells- Cell 1 and 2 are actives.
UE: PS-DCCH+DTCH_FACH (state 6-11) in cell 1 as specified in clause 7.4 of TS 34.108.
Test Procedure:
Table B_8.3.1.1
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3.84M -60 -75 -75 -60
(FDD) Hz
Table B_8.3.1.1-1 illustrates the downlink power to be applied for the 2 cells at various time instants of
the test execution. Columns marked T0 denote the initial conditions. The tester switches the power
settings repeatedly between columns T1 and T0, whenever the description below specifies that the
transmission power settings for cell 1 and cell 2 be reversed.
The UE is in the CELL_FACH state, and camping onto cell 1. The tester configures its downlink
transmission power settings according to columns T1 in Table 8.3.1.1. The UE shall find cell 2 to be
more suitable for service and hence perform a cell reselection. After the completion of cell reselection,
the UE shall transmits a CELL UPDATE message to the NW on the uplink CCCH of cell 2 and set IE
Cell update cause to Cell Reselection.
After the NW receives this message, it transmits a CELL UPDATE CONFIRM message, which
includes the IE RRC State Indicator set to CELL_FACH, to the UE on the downlink DCCH. UE shall
verify that IE New C-RNTI is not included in the downlink message and shall send a CELL UPDATE
message to NW again. NW shall then send a CELL UPDATE CONFIRM message which includes a
valid IE New C-RNTI.
The tester verifies that the send UTRAN MOBILITY INFORMATION CONFIRM message. UE shall
stay in CELL_FACH state. The tester configures its downlink transmission power settings according to
columns "T0" in Table 8.3.1.1. The UE shall find cell 1 to be more suitable for service and hence
perform a cell reselection. After the completion of cell reselection,
the UE shall send a CELL UPDATE message on the uplink CCCH of cell 1 and set IE Cell update
cause to Cell Reselection. After the NW receives this message, it transmits a CELL UPDATE
CONFIRM message, which includes the IE RRC State Indicator set to CELL_FACH, to the UE on
the downlink DCCH. NW verifies that the UE does not send any response to this message. UE shall
stay in CELL_FACH state.


Test Verification:
To confirm that the UE executes a cell update procedure after the successful reselection of another
UTRA cell. To confirm that the UE sends the correct uplink response message when executing cell
update procedure due to cell reselection.
Message flow:

UE NW
1 The UE is in the
CELL_FACH state in cell 1
2 Tester applies the downlink
transmission power
settings, according to the
values in column T1 of
Table 8.3.1.1 The UE
shall find that the cell 2 is
better for service and
perform a reselection.
3 CELL UPDATE Value cell reselection
should be indicated in IE
Cell update cause
4 CELL UPDATE CONFIRM IE RRC State Indicator is
set to CELL_FACH.
4a CELL UPDATE Value "cell reselection"
shall be indicated in IE
"Cell update cause"
4b CELL UPDATE CONFIRM See message content. NW
set k=0.
CONFIRM
6 Tester reverses the
transmission power level of
cell 1 and cell 2 column T0
in table 8.3.1.1).
7 CELL UPDATE
set to CELL_FACH.
Remarks:
After step 2 the UE shall reselect to cell 2 and then it shall transmit a CELL UPDATE message which,
sets the value cell reselection in IE Cell update cause.
After step 3 the UE shall transmit CELL UPDATE message which sets the value cell reselection in
IE Cell update cause.
After step 4a, the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message to
acknowledge that it has started to use the new RNTI identities allocated. After step 6 the UE shall sent
a CELL UPDATE message to the cell with stronger transmitting power, in order to indicate that a cell
reselection has taken place.


B_8.3.1.2 Cell Update: cell reselection in CELL_PCH
Test Purpose:
This procedure is to update UTRAN with information of the current cell, after a cell reselection has
occurred in CELL_PCH state.
Pre-requisites:
Network: 2 cells Cell 1 and 2 are active
UE: CELL_PCH (state 6-12) in cell 1 as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is brought to CELL_PCH state and is camped onto cell 1. The tester configures the downlink
transmission power settings according to columns T1 in Table 8.3.1.1-1. When the UE detects the
presence of cell 2, it moves to CELL_FACH state and transmits a CELL UPDATE message on the
uplink CCCH. The value cell reselection shall be set in IE Cell update cause in CELL UPDATE
message. Upon reception of CELL_UPDATE message, the network replies with a CELL UPDATE
CONFIRM message with the IE RRC State Indicator set to CELL_PCH. After receiving this
message, the UE returns to CELL_PCH state without transmitting any uplink message. The NW
transmits a PAGING TYPE 1 message, causing the UE to enter CELL_FACH state and the UE shall
transmit a CELL UPDATE message on uplink CCCH with IE Cell update cause set to paging
response. NW shall respond with a CELL UPDATE CONFIRM message
Test Verification:
To confirm that the UE, in CELL_PCH state, executes a cell update procedure after the successful
reselection of another UTRA cell. To confirm that the UE replies with an appropriate uplink message
after receiving CELL UPDATE CONFIRM message during the cell update procedure.


Message Flow:

UE NW
CELL_PCH state in cell 1
2 The tester applies the
downlink transmission
power settings, according
to the values in columns
"T1" of Table 8.3.1.1The
UE shall find that the cell 2
is better and attempt to
perform a cell reselection.
CELL_FACH state and
transmits this message with
the IE Cell update cause
set to cell reselection
set to CELL_PCH.
state.
message with a matched
identity.
7 CELL UPDATE UE is in CELL_FACH state.
CONFIRM
Remarks:
After step 2 the UE shall reselect to cell 2 and transmit a CELL UPDATE message, containing the IE
Cell update cause set to cell reselection.
After step 8, the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message on the
DCCH using AM RLC.


B_8.3.1.3 Cell Update: periodical cell update in CELL_FACH
Test Purpose:
This procedure is to update UTRAN with the current cell information, after the UE has remained in the
service area in the CELL_FACH state for a period exceeding the timer value T305.
Reference: 3GPP TS 25.331 clause 8.3.1, 8.3.3.3
Pre-requisites:
UE: CS-CELL_FACH_Initial (state 6-11)in cell 1 as specified in clause 7.4 of TS 34.108
Test Procedure:
Table 8.3.1.3
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/ -60 -75 -75 -60
(FDD) 3.84
MHz
Table 8. 3.1.3 illustrates the downlink power to be applied for the 2 cells at various time instants of the
test execution.
The UE is in CELL_FACH state. When the UE detects the expiry of timer T305 according to the
settings in system information, the UE transmits a CELL UPDATE message to the network on the
uplink CCCH with a cause indicating periodical cell updating. The network replies with a CELL
UPDATE CONFIRM message, and IE RRC State Indicator is set to CELL_FACH. Tester verifies
that the UE does not transmit any uplink message. After this, the tester changes the timer T305 value
to 5 minutes. The NW transmits a UTRAN MOBILITY INFORMATION message, which includes IE
T305 set to 5 minutes, to UE. UE shall transmit UTRAN MOBILITY INFORMATION CONFIRM
message. UE shall resume periodic cell updating procedure and transmit CELL_UPDATE message 5
minutes after this modification.
Note: If the UE fails the test because of a failure to reselect to a right cell, then the operator may re-run
the test.
Test verification:
To confirm that the UE executes a periodic cell update procedure following the expiry of timer T305.
To confirm that the UE sends a correct response to the CELL UPDATE CONFIRM message.
To confirm that the UE takes into account the UTRAN MOBILITY INFORMATION messages and then
responds to a change in the setting for timer T305.


Message flow:

UE NW
1 The UE is in the
CELL_FACH state. Tester
waits until T305 has
expired.
2 CELL UPDATE IE Cell update cause shall
be set to periodical cell
updating
3 CELL UPDATE CONFIRM No RNTI identities are
given. No information on
PRACH and S-CCPCH are
provided.
4 Tester verifies that no
uplink message is received
from UE. Tester waits for
another period to allow
T305 to expire.
5 INFORMATION
UTRAN MOBILITY IE T305 is set to 5
minutes.

CONFIRM

message 5 minutes after
step 5, with cell update
cause set to periodical
cell updating
Remarks:
After step 1 the UE shall detect the expiry of timer T305 then transmits a CELL UPDATE message
setting value periodical cell update into IE Cell update cause.
After step 3 the UE shall not send any uplink message as a response to CELL UPDATE CONFIRM
message sent in step 3.
After step 5 the UE shall transmit a CELL UPDATE message stating the cell update cause to be
periodic updating, 5 minutes after the UE has taken into account the UTRAN MOBILITY
INFORMATION messages .


E_ 8.3.1.5 Cell Update: UL data transmission in URA_PCH
Test Purpose:
The purpose of this test is to confirm that the UE executes a cell update procedure when the UE
transmits uplink data if the UE is in URA_PCH state.
Reference : 3G 25.331 section 8.3.1 & 8.1.2
Pre-requisites:
Network: 1cell
The UE has been registered in both CS and PS domains.
Test Procedure:
The NW transmits a PHYSICAL CHANNEL RECONFIGURATION message with IE "RRC State
Indicator" is set to "URA_PCH". The UE shall reply with PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message and move to URA _PCH state. The NW transmits a PAGING TYPE 1 message
which includes a matched U-RNTI and the optional IE "CN originated page to connected mode UE".
The UE then moves to CELL_FACH state and transmits a CELL UPDATE message to the NW on the
uplink CCCH, with the IE "Cell update cause" set to value "uplink data transmission". After receiving
such a message, NW transmits CELL UPDATE CONFIRM message on the downlink DCCH. Then the
UE shall transmit an UTRAN MOBILITY INFORMATION CONFIRM message on the uplink DCCH to
acknowledge the receipt of the new UE identities.The UE shall stay in CELL_FACH state and transmit
an INITIAL DIRECT TRANSFER message using AM RLC on DCCH.
Test Verification:
Verify the update of the UTRAN with the current cell information if the UE wants to transmit uplink data
while in URA_PCH state.


Message Flow:

UE NW
CELL_FACH state.
2 Void
3 Void
4 PHYSICAL CHANNEL IE "RRC State Indicator"
RECONFIGURATION set to "URA_PCH"
5 PHYSICAL CHANNEL UE moves to URA_PCH
RECONFIGURATION COMPLETE state.
5a PAGING TYPE 1 Includes Matched identifier
and optional IE CN
originated page to
connected mode UE"
CELL FACH state with the
message set to "uplink data
transmission" in IE "Cell
update cause".
7 CELL UPDATE CONFIRM See message content.
7a UTRAN MOBILITY INFORMATION

CONFIRM
8 INITIAL DIRECT TRANSFER Response to the paging
message sent in step 5a
Remarks:
After step 4, UE shall transmit a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message

and move to URA_PCH state.
After step 5a, the UE shall move to CELL_FACH state to initiate a cell update procedure and transmits
a CELL UPDATE message which is set to "uplink data transmission" in IE "Cell update cause".
After step 7a, UE shall transmit INITIAL DIRECT TRANSFER message to the NW using AM RLC on
DCCH.


E_ 8.3.1.9 Cell Update: re-entering of service area with and without expiration of T305 and being
out of service area
Test Purpose:
The purpose of this test is to confirm that the UE performs a cell search after experiencing an "out of
service area" condition following the expiry of timer T305. To confirm that the UE initiates cell updating
procedure if it manages to re-enter the service area. Also the UE should initiate cell updating
procedure if it manages to re-enter the service area
Pre-requisites:
Network: 1 cell.
Table 8.3.1.9
Parameter Unit Cell 1
T0 T1
UTRA RF Ch. 1
Channel
Number
CPICH Ec dBm/3.84MH -60 -80
z
Recommended timer values in SIB#1:
Information Element Value/remark

T305 5 minutes
T307 50 seconds
T317 600 seconds
Test Procedure:
The UE is in the CELL_FACH state. The content of the SYSTEM INFORMATION BLOCK TYPE 3 and
4 is modified. The tester configures its downlink transmission power settings according to columns
"T1" in table 8.3.1.9 so that S<0. Following the expiry of periodic cell updating timer T305 according to
the system information, the UE shall detect that it is out of service area. Within the time interval
equivalent to T307 timer value, the tester configures its downlink transmission power settings
according to columns "T0" in table 8.3.1.9 so that S>0. The UE shall find that it is back in service area,
and transmit a CELL UPDATE message to the NW on the uplink CCCH. In this message, the IE "Cell
update cause" shall be set to "re-entered service area". After the NW receives this message, it
transmits a CELL UPDATE CONFIRM message with the IE "RRC State Indicator" set "CELL_PCH" on
the downlink DCCH. The UE shall enter CELL_PCH state. The tester configures its downlink
transmission power settings according to columns "T1" in table 8.3.1.9 so that S<0. Following the
expiry of periodic cell updating timer T305 according to the system information, the UE shall detect
that it is out of service area. Within the time interval equivalent to T307 timer value, the tester
configures its downlink transmission power settings according to columns "T0" in table 8.3.1.9 so that
S>0. The UE shall find that it is back in service area, move to CELL_FACH and transmits a CELL
UPDATE message to the NW on the uplink CCCH. In this message, the IE "Cell update cause" shall
be set to "re-entered service area". After the NW receives this message, it transmits a CELL UPDATE
CONFIRM message on the downlink DCCH.
Test Verification:


Verify that when a UE detects that it's out of service area after experiencing a T305 timer expiry, it
shall try to search for a suitable cell to camp on. At the same time, it shall start timer T307. If the UE
subsequently re-enters the service area of a cell before T307 expires, it shall perform a cell update
procedure.
Message Flow:

UE NW
1 The UE is in the
CELL_FACH state of cell 1.
1a MASTER INFORMATION BLOCK NW changes the contents
SYSTEM INFORMATION BLOCK of
TYPE 3 and 4 MASTER INFORMATION
BLOCK and SYSTEM
INFORMATION BLOCK.
1b SYSTEM INFORMATION CHANGE
INDICATION
2 The tester configures its
power settings according to
8.3.1.9 so that its S value
falls below 0.
3 The UE shall detect a "out
of service" condition upon
expiry of timer T305 and it
shall search for other cells
to camp on. (T307 timer
starts)
8.3.1.9.
5 CELL UPDATE The value "re-entered
service area" shall be found
in IE "Cell update cause" in
this message
6 CELL UPDATE CONFIRM "RRC State Indicator" is set
to "CELL_PCH"
8.3.1.9 so that its S value
falls below 0 and waits until
T305 has expired.
8.3.1.9.


9 CELL UPDATE UE shall move to

CELL_FACH. It shall
transmit this message with
cell update cause set to
"re-entered service area"
Remarks:
After step 4 the UE shall transmit a CELL UPDATE message in which the IE "Cell update cause" is set
to the value "re-entered service area".
After step 8 the UE shall move to CELL_FACH and then transmit a CELL UPDATE message, with the
IE "Cell Update Cause" set to "re-entered service area".


E_8.3.1.18 Cell Update: Radio Link Failure (T314>0, T315=0), CS RAB established
Test Purpose:
The purpose of this test is to confirm that the UE shall indicate to the non-access stratum the release
of radio access bearer which is associated with T315 and try to find a new cell after detecting that a
radio link failure has occurred.
To confirm that the UE performs a cell selection procedure when it fails to configure the physical
channel(s) indicated in the CELL UPDATE CONFIRM message.
Reference: 3GPP TS 25.331 clause 8.3.1.2, 8.3.1.7a
Pre-requisites:
Network: 2 cells (Cell 1 is active, Cell 2 is inactive).
UE: CS_DCCH+DTCH_DCH (state 6-9) or PS_DCCH+DTCH_DCH (state 6-10) in cell 1, depending
Table 8.3.1.18
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3.84M -60 OFF -75 -60
Hz
Test Procedure:
Table 8.3.1.18 illustrates the downlink power to be applied for the 2 cells at various time instants of the
test execution. Columns marked "T0" denote the initial conditions.
The UE is brought to CELL_DCH state in a cell 1 after making a successful outgoing call attempt.
After the call has been established, NW configures its downlink transmission power settings according
to column "T1" in table 8.3.1.18. The UE shall detect a radio link failure in cell 1. UE shall release the
radio bearer which is associated with T315, if the latter has been set up in the initial condition. Then it
shall attempt to re-select to cell 2. After that, it shall transmit CELL UPDATE on the uplink CCCH to
NW. The NW transmits CELL UPDATE CONFIRM message which includes dedicated transport and
physical channel parameters on downlink DCCH. NW shall not configure according to this message
and its downlink transmission power settings according to column "T0" in table 8.3.1.18. UE shall fail
to establish the dedicated channel in cell 2. UE shall re-select to cell 1 and transmit a CELL UPDATE
message with IE "Cell update cause" set to "Radio link failure". Then NW responds with a CELL
UPDATE CONFIRM message on downlink DCCH. Then the UE shall tansmit a TRANSPORT
CHANNEL RECONFIGURATION COMPLETE message on the uplink DCCH.
the test.
Test Verification:
Verify that when a UE loses the radio connection due to e.g. radio link failure in CELL_DCH state. UE
must release the radio bearer which is associated with T315 if T315 is set to 0. After a successful cell
re-selection and subsequent transition to CELL_FACH state, the UE transmits CELL UPDATE
message on the uplink CCCH.


If the UE failed to establish the physical channel(s) indicated in the received CELL UPDATE
CONFIRM message and the maximum allowable number of retransmission has not been reached, the
UE shall select a suitable UTRA cell and transmit a CELL UPDATE message.
Message Flow:

UE NW
Void
Void
4 The tester configures
cell 1 and 2 according
to column "T1" in table
8.3.1.18. NW starts to
listen to the uplink
CCCH of cell 2.
6 The UE detects the
radio link failure
7 CELL UPDATE The UE shall find a
new cell 2 and the
value "radio link
failure" shall be set in
IE "Cell update cause".
8 CELL UPDATE CONFIRM Including dedicated
physical channel
parameters.
9 NW does not configure
according to the
message in step 8.
The tester configures
cell 1 and 2 according
to column "T0" in table
8.3.1.18.
10 CELL UPDATE UE shall select cell 1
and transmit this
message
12 TRANSPORT CHANNEL
Remarks:
After step 6, the UE shall detect the presence of cell 2, perform cell re-selection and transmit a CELL
UPDATE message.
After step 9, the UE shall transmit a CELL UPDATE message with IE "Cell update cause" set to
"Radio link failure".
After step 12, the UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE


E_8.3.1.28 Cell Update: Radio Link Failure (T314=0, T315>0), PS RAB
Test Purpose:
To confirm that the UE release radio access bearer which is associated with T314 and try to find a
new cell after detecting that a radio link failure has occurred.
Pre-requisites:
Network: 2 cells (Cell 1 and cell 2 are active).
UE: PS_DCCH+DTCH_DCH (state 6-10) in cell 1 or PS+CS -DCCH+DTCH_DCH (state 6-14) in cell 1,
if UE supports both CS and PS domains.
Table E_8.3.1.28

T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3.84MHz -60 OFF -75 -60
(FDD)
Test Procedure:
Table E_8.3.1.28 illustrates the downlink power to be applied for the 2 cells at various time instants of
the test execution. Column marked T0 denote the initial conditions.
The UE is brought to CELL_DCH state in a cell 1 after making a successful outgoing call attempt.
After the call has been established, NW configures its downlink transmission power settings according
to column T1 in table 8.3.1.28. The UE shall detect a radio link failure in cell 1.
The UE shall attempt to re-select to cell 2. After that, it shall then enter CELL_FACH state and
transmit CELL UPDATE on the uplink CCCH to NW. The NW transmits CELL UPDATE CONFIRM
message which includes dedicated transport channel and physical channel parameters on downlink
DCCH. Then the UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE
message on the uplink DCCH. NW transmits COUNTER CHECK message to UE. UE shall transmit a
COUNTER CHECK RESPONSE message back to NW.
Test Verification:
Verify that the UE releases the radio access bearer which is associated with T314 and tries to find a
new cell after detecting that a radio link failure has occurred.
Message Flow:



UE SS
1 Tester configures cell 1
and 2 according to
column T1 in table
8.3.1.28. NW starts to
listen to the uplink
CCCH of cell 2.
2 The UE detects the
radio link failure.
3 CELL UPDATE The UE shall find a
new cell 2 and the
value "radio link failure"
shall be set in IE "Cell
update cause".
5 TRANSPORT CHANNEL RECONFIGURATION
COMPLETE
6 COUNTER CHECK NW sent the COUNT-C
info for the RBs that
were established in the
initial condition.
7 COUNTER CHECK RESPONSE
Remarks:
After step 2, the UE shall detect the presence of cell 2, perform cell re-selection and transmit a CELL
UPDATE message.
After step 5, the UE shall transmit a TRANSPORT CHANNEL RECONFIGURATION COMPLETE
After step 7, the UE shall transmit a COUNTER CHECK RESPONSE message without including IE
RB COUNT-C information.


E_8.3.1.31 Cell Update: re-entering of service area from URA_PCH after T316 expiry but before
T317 expiry
Test Purpose:
The purpose of this test is to confirm that the UE executes an URA update procedure when the UE re-
enters the service area before the expiry of timer T317, after expiry of T316.
Pre-requisites:
Network: 1 cell with URA-ID 1 and the downlink transmission power shown in column marked "T0" in
table 8.3.1.31.
UE: URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108, with URA-ID 1 in the list of URA-
ID.
Table 8.3.1.31
Parameter Unit Cell 1
T0 T1
UTRA RF Ch. 1
Channel
Number
CPICH Ec DBm/3.84MH -60 -80
z
Test Procedure:
The UE is initially in URA_PCH state. The content of the SYSTEM INFORMATION BLOCK TYPE 3
and 4 is modified. The tester configures its downlink transmission power settings according to columns
"T1" in table 8.3.1.31 so that S<0. When the UE detects that it is out of service area, it will start T316
and search for a cell to camp. The tester configures its downlink transmission power settings
according to columns "T0" in table 8.3.2.3 within a time equivalent to T316+T317 but larger than T316,
so that S>0. The UE shall detect that it returns back in service area before T317 expires. Since the UE
has moved to CELL_FACH state on expiry of T316, it shall now transmit a Cell UPDATE message
which contains the value "re-entering service area " in IE "Cell update cause" to the NW on the uplink
CCCH. After the NW receives this message, it transmits a Cell UPDATE CONFIRM message which
includes the IE "new C-RNTI", and "new U-RNTI" to the UE on the downlink DCCH. Then the UE shall
transmit an UTRAN MOBILITY INFORMATION CONFIRM message on the uplink DCCH.
Test Verification:
Verify the update UTRAN with the current URA of the UE if the UE detects that it is out of service area
after the expiry of timer T305, and then subsequently re-enters the service area before the expiry of
T307.
Message Flow:
UE NW
1 The UE starts operating
from URA_PCH state.
1a MASTER INFORMATION BLOCK NW changes the contents
SYSTEM INFORMATION BLOCK of
TYPE 3 and 4 MASTER INFORMATION
BLOCK and SYSTEM
INFORMATION BLOCK
(see specific message
contents).
1b PAGING TYPE 1 Include IE "BCCH
modification info"
Void


Void
8.3.1.31 such that the cell 1
is no longer suitable for
camping i.e. S<0.
3 The UE shall detect a "out
of service area" condition,
start T316. The UE shall
start T317 on expiry of
T316)
4 60 seconds after step 2
(see note 1), the tester
configures its downlink
transmission power
settings according to
8.3.1.31 before T307
expires.
5 CELL UPDATE Value "re-entering service
area" shall be set in IE
"Cell update caus e"

CONFIRM
Note 1: The 60 seconds in step 4 should be large enough for any UE to have detected the out of
service area condition (Nserv consecutive DRX cycles + 12s) and have started T317 after T316 expiry
(default=30s), but well before T317 expiry (default = 180s).
Remarks:
After step 2 the UE shall detect that it is out of service area and shall not send a URA UPDATE on the
uplink CCCH channel.
After step 4 the UE shall transmit a CELL UPDATE message which sets value " re-entering service
area " into IE "Cell update cause".
After step 6 the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message.


B_8.3.2.1 URA Update: Change of URA
Test purpose:
This procedure is to update UTRAN with the current URA of the UE after a change of URA has
occurred in URA_PCH state. It may also be used for supervision of the RRC connection, even if no
change of URA takes place.
Another purpose is to confirm that the UE performs an URA update procedure after it detects that SIB
2 is not broadcasted
The final purpose is to confirm that the UE performs an URA update procedure after it detects a
confirmation error of URA identity list.
Reference: 3GPP TS 25.331 clause 8.3.1.2, 8.3.1.12, 8.6.2.1
Pre-requisites:
Network: 4 cells: The URA-ID and transmission power for each cell is shown in Table 8.3.2.1,
where the initial condition is shown in column "T0"
UE: URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108, with URA-ID 1 from the list of
URA -ID in cell 1
Table B_8.3.2.1

T0 T1 T2 T3 T4 T5 T6 T7 T0 T1 T2 T3 T4 T5 T6 T7
UTRA RF
Channel
Ch. 1 Ch. 1
Number
CPICH Ec dBm/3. -60 -75 -60 -75 -60 -75 -75 -60 -75 -60 -75 -60
84MHz
URA ID URA-ID URA-ID 2 URA-ID 1,3 and 4 no SIB2
1
Test Procedure:
The test begins with the downlink power transmission of both cells set according to 'T0' column in the
table 8.3.2.1. The UE is in the URA_PCH state and assigned with only 1 URA identity in cell 1: URA-
ID 1. The tester then adjusts the transmission power again according to the 'T1' column. This is
expected to cause the UE to perform a cell reselection to cell 2. Since URA-ID 1 is also broadcasted in
cell 2, the UE shall not perform any URA update procedure due to the change of URA. Starting from
time T2, the tester modifies the system information in cell 1, so that URA-ID 2 is the only URA identity
in that cell. Next the tester adjusts the transmission power according to 'T3' column. UE shall perform
a cell reselection to cell 1 and when the UE finds that its current URA -ID 1 is not in the new
broadcasted list of URA -IDs, it moves to CELL_FACH state and transmits a URA UPDATE message
on the uplink CCCH. After the network receives this message, it transmits a URA UPDATE CONFIRM
message which includes the IEs "RRC State Indicator" and IE "URA-ID" to the UE on the downlink
CCCH. The "RRC State Indicator" is set to "URA_PCH". UE returns to URA_PCH state in cell 1
without sending any uplink response message. Next the tester adjusts the transmission power
according to 'T5' column. UE shall perform cell re-selection to cell 1 and then send a URA UPDATE
message to the network. The network shall transmit URA UPDATE CONFIRM message to UE on the


downlink CCCH. Starting from time T6, the tester modifies the system information in cell 2, so that no
SIB 2 is sent in that cell.
Next the tester adjusts the transmission power according to the 'T7' column. The UE shall re-select to
cell 4 and send a URA UPDATE message since no SIB2 is broadcasted in this cell. When the UE
receives a URA UPDATE CONFIRM message including a URA identity, the UE will again send a URA
UPDATE message. When receiving this last message, the network shall transmit RRC Connection
Release message on downlink CCCH to release the RRC connection.
the test.
Test verification:
To confirm that the UE executes an URA update procedure after the successful change of URA.
Message flow:

UE NW
1 The UE is updated with
only 1 URA identity carried
currently by cell 1. The
starting state of the UE is
URA_PCH
2 The tester set the power
transmission and system
information of all cells
according to column 'T1' of
Table B_8.3.2.1-.
3 UE shall perform a cell
reselection but shall not
transmit URA UPDATE
message with the update
cause of "change of URA".
3a Starting from time T2, SS
modifies the system
information in cell 1, so that
URA -ID 2 is the only URA
identity in that cell
Table B_8.3.2.1.
finds that its current URA -
ID 1 is not in the newly
broadcasted list of URA -
IDs, it shall then transmit
this message and set value
"URA update cause".
"URA_PCH", and also IE
"URA-ID 2".


Table B_8.3.2.1.
8 URA UPDATE
10 Tester sets the power
table B_8.3.2.1.
finds that no URA-ID is
broadcasted in this cell, it
shall then transmit this
"URA update cause".
11a Starting from time T6, SS
modifies the system
information in cell 2, so that
no SIB 2 is sent in that cell.
to "URA_PCH", and also IE
"URA-ID 2".
13 URA UPDATE
14 RRC CONNECTION RELEASE This message is sent on
CCCH.
15 Void
16 UE enters idle mode
Remarks:
After step 2 the UE shall not transmit a URA UPDATE message with update cause "change of URA".
After step 4 the UE shall find that URA-ID 2 is not in its maintained list of URA -IDs. After cell
After step 7 the UE shall find that URA-ID 1 is not in its maintained list of URA -IDs. After cell
After step 10 the UE shall find that no URA-ID is broadcasted in the cell, move to CELL_FACH state
and transmit a URA UPDATE message setting the update cause to "change of URA".
After step 12 the UE shall find that no URA-ID is broadcasted in the cell and transmit a URA UPDATE
message setting the update cause to "change of URA".


B_8.3.2.2 URA Update: Periodical URA
Test purpose:
This procedure is to update UTRAN with the current URA of the UE when the UE detects that it is still
within the service area after the expiry of periodic URA updating timer T305.
Reference: 3GPP TS 25.331 clause 8.3.1.2, 8.3.1.7, 8.3.1.11
Pre-requisites:
Network: 1 cell
UE: URA_PCH (state 6-13) as specified in clause 7.4 of TS 34.108.
Test Procedure:
The UE is in the URA_PCH state. When the UE detects the expiry of timer T305, set according to the
value specified in system information, the UE moves to CELL_FACH state and transmits a URA
UPDATE message to the network on the uplink CCCH. The message shall indicate the cause to be
periodic URA update in IE URA update cause. Network replies with an URA UPDATE CONFIRM
message sent on downlink CCCH.
Test verification:
To confirm that the UE executes a URA update procedure after the expiry of timer T305.
Message flow:

UE NW
state. Tester wait until T305
timer has expired.
2 URA UPDATE UE shall transmit this
periodic URA update into
IE URA update cause.
Remarks:
After step 1 the UE shall detect the expiry of timer T305, move to CELL_FACH state, and transmit a
URA UPDATE message which is set the value periodical cell update into IE URA update cause.


E_8.3.3.1 UTRAN Mobility Information: Success
Test Purpose:
The purpose of this test is to confirm that the UE starts to use the new identities after it receives a
UTRAN MOBILITY INFORMATION message from the NW.
Reference : 3GPP TS 25.331 clause 8.3.3 and clauses 8.6.3.9, 8.6.3.10, 8.3.1.3
Pre-requisites:
Network: 1 cell
Test Procedure:
Initially, the UE is in CELL_FACH state and it has been assigned a C-RNTI and U-RNTI. The NW
transmits an UTRAN MOBILITY INFORMATION message which includes new C-RNTI and U-RNTI to
the UE. Then the UE shall transmit a UTRAN MOBILITY INFORMATION CONFIRM message using
the assigned new C-RNTI in MAC header as confirmation. NW waits for UE to perform periodic cell
updating. When NW received a CELL UPDATE message, the tester checks that UE uses the new U-
RNTI in the CELL UPDATE message. Then NW sends CELL UPDATE CONFIRM. NW waits for UE to
perform periodic cell updating. When NW received a CELL UPDATE message, NW sends CELL
UPDATE CONFIRM to end the test procedure.
Test Verification:
Verify that when the network assign a new RNTI identity to the UE, which it is initiated by the UTRAN
when it sends a UTRAN MOBILITY INFORMATION message including a new C-RNTI and/or U-RNTI
on the downlink DCCH. The UE starts to use the new identities and transmits an UTRAN MOBILITY
INFORMATION CONFIRM message to the UTRAN on the uplink DCCH.
Message Flow:

UE NW
1 The initial state of the UE is
CELL_FACH state. UE has
been allocated both C-
RNTI and U-RNTI during
RRC connection
establishment phase.
2 UTRAN MOBILITY INFORMATION Contains new C-RNTI and
U-RNTI identities
3 UTRAN MOBILITY INFORMATION The assigned new C-RNTI
CONFIRM shall be included in MAC
header.
4 NW waits for T305 to
expire.
5 CELL UPDATE UE shall trigger cell
updating. The message
shall indicate the same U-
RNTI assigned in the
UTRAN MOBILITY
INFORMATION message
in step 2.



7 NW waits for T305 to
expire.
8 CELL UPDATE UE shall trigger cell
updating. The message
shall indicate the same U-
RNTI assigned in the
UTRAN MOBILITY
INFORMATION message
in step 2.
Remarks:
uplink DCCH that using the assigned new C-RNTI in MAC header.
After step 4 and 7 the UE shall transmit a CELL UPDATE message on the uplink CCCH with IE "Cell
update cause" set to "periodical cell updating". The IE "U-RNTI" shall be identical to the IE "New
RNTI" found in UTRAN MOBILITY INFORMATION message sent by the NW in step 2.


B_8.3.4.1.a Active set update in softer handover: Radio Link addition Remove test case (FDD)
Test purpose:
Radio link addition is triggered in the networks RRC layer. The RRC entity in the network first
configures the new radio link. Transmission and reception then begin immediately. This procedure is
to update the active set of the connection between the UE and UTRAN. The UTRAN then transmits an
ACTIVE SET UPDATE message to the UE. The UE configures layer 1 to begin reception for the
additional radio link. An ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN without
waiting for the Physical Layer synchronization.
Pre-requisites:
Configurations: B, C
Network: 2 cells - Cell 1 2 are activeUE: CS -DCCH+DTCH_DCH (state 6-9) or PS-
DCCH+DTCH_DCH (state 6-10) in cell 1 as specified in clause 7.4 of TS 34.108, depending on
the CN domain supported by the UE
Table 8.3.4.1

T0 T1 T2 T3 T0 T1 T2 T3
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/ -60 -60 OFF -60 -75 -60 -60 OFF
3.84
MHz
Test Procedure:
Initially, the UE goes to connected mode and establishes a radio access bearer in CELL_DCH state in
cell 1. The tester configures its downlink transmission power settings according to columns T1 in
Table 8.3.4.1. UE shall be triggered to transmit a MEASUREMENT REPORT message which includes
the primary scrambling code for cell 2 according to IE Intra-frequency event identity, which is set to
1a in the SYSTEM INFORMATION BLOCK TYPE 11.
After the MEASUREMENT REPORT message is received, the tester adds the new radio of cell 2, by
increasing its power, and then the network transmits to the UE an ACTIVE SET UPDATE message in
cell 1 on DCCH using AM RLC which includes the IE Radio Link Addition Information (e.g. Downlink
DPCH information and other optional parameters relevant for the additional radio links with Primary
CPICH info used for the reference ID). When the UE receives this message, the UE shall configure
layer 1 to begin reception without affecting the current uplink and downlink activities of the existing
radio links. The UE shall transmit an ACTIVE SET UPDATE COMPLETE message to the network on
the uplink DCCH using AM RLC without waiting for the physical channel synchronisation.
The tester configures its downlink transmission power settings according to columns T2 in Table
8.3.4.1. UE shall not detect the DPCH from cell 1 but continue to communicate through the another
DPCH from cell 2. The UE shall transmit a MEASUREMENT REPORT message which indicates the
event 1b for cell 1.
NW shall transmit a UE CAPABILITY ENQUIRY message to confirm that the UE can respond this
message through the DPCH in cell 2. The UE shall transmit a UE CAPABILITY ENQUIRY
INFORMATION message. Then NW transmits a UE CAPABILITY INFORMATION CONFIRM
message.


Then the tester configures its downlink transmission power settings according to columns T3 in Table
8.3.4.1. UE shall detect DPCH from cell 1, but not detect the DPCH from cell 2 but continue to
communicate through DPCH from cell 1. The UE shall transmit a MEASUREMENT REPORT
message which indicates the event 1b for cell 2.
INFORMATION message. Then SS transmits a UE CAPABILITY INFORMATION CONFIRM
message. The tester calls for generic procedure C.3 to check that UE is in CELL_DCH state
Test verification:
To confirm that the UE continues to communicate with the network on both the additional radio link
and an already existing radio link after the radio link addition.
Message flow:

UE NW
columns T1 in Table
8.3.4.1.
2 MEASUREMENT REPORT See specific message
contents for this message
3 ACTIVE SET UPDATE Network transmits this
message in cell 1 on
downlink DCCH using AM
RLC. The message
includes IE Radio Link
Addition Information. (e.g.
Downlink DPCH
information and other
optional parameters
relevant for the additional
radio links with Primary
CPICH info used for the
reference ID in cell 2)
4 ACTIVE SET UPDATE COMPLETE The UE shall configure a
new radio link to cell 2,
without interfering with
existing connections on the
radio link in cell 1.
columns T2 in Table
8.3.4.1
5a MEASUREMENT REPORT See specific message
6 UE CAPABILITY ENQUIRY Use default message
7 UE CAPABILITY INFORMATION Use default message
CONFIRM



UE NW
9
9a Void
columns T3 in Table
8.3.4.1
CONFIRM
CELL_DCH state
Remarks:
After step 1 the UE shall transmit a MEASUREMENT REPORT message on the uplink DCCH using
AM RLC.
After step 3 the UE shall transmit an ACTIVE SET UPDATE COMPLETE message on the uplink
DCCH using AM RLC to acknowledge the completion of the active set additional procedure.
AM RLC.
After step 6 the UE shall transmit a UE CAPABILITY INFORMATION message.
AM RLC.
Without internal traces provided by the NodeB or the UE, it may be difficult to verify the establishment
of the second radio branches.


B_8.3.4.1.b Active set update in soft handover: Radio Link addition Remove test case (FDD)
Test purpose:
Radio link addition is triggered in the networks RRC layer. The RRC entity in the network first
configures the new radio link. Transmission and reception then begin immediately. This procedure is
to update the active set of the connection between the UE and UTRAN. The UTRAN then transmits an
ACTIVE SET UPDATE message to the UE. The UE configures layer 1 to begin reception for the
additional radio link. An ACTIVE SET UPDATE COMPLETE message is sent to the UTRAN without
waiting for the Physical Layer synchronization.
Pre-requisites:
Network: 2 cells - Cell 1 2 are activeUE: CS -DCCH+DTCH_DCH (state 6-9) or PS-
DCCH+DTCH_DCH (state 6-10) in cell 1 as specified in clause 7.4 of TS 34.108, depending on
the CN domain supported by the UE
Table 8.3.4.1

T0 T1 T2 T3 T0 T1 T2 T3
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/ -60 -60 OFF -60 -75 -60 -60 OFF
3.84
MHz
Test Procedure:
Initially, the UE goes to connected mode and establishes a radio access bearer in CELL_DCH state in
cell 1. The tester configures its downlink transmission power settings according to columns T1 in
Table 8.3.4.1. UE shall be triggered to transmit a MEASUREMENT REPORT message which includes
the primary scrambling code for cell 2 according to IE Intra-frequency event identity, which is set to
1a in the SYSTEM INFORMATION BLOCK TYPE 11.
After the MEASUREMENT REPORT message is received, the tester adds the new radio of cell 2, by
increasing its power, and then the network transmits to the UE an ACTIVE SET UPDATE message in
cell 1 on DCCH using AM RLC which includes the IE Radio Link Addition Information (e.g. Downlink
DPCH information and other optional parameters relevant for the additional radio links with Primary
CPICH info used for the reference ID). When the UE receives this message, the UE shall configure
layer 1 to begin reception without affecting the current uplink and downlink activities of the existing
radio links. The UE shall transmit an ACTIVE SET UPDATE COMPLETE message to the network on
the uplink DCCH using AM RLC without waiting for the physical channel synchronisation.
8.3.4.1. UE shall not detect the DPCH from cell 1 but continue to communicate through the another
DPCH from cell 2. The UE shall transmit a MEASUREMENT REPORT message which indicates the
event 1b for cell 1.
message.
Then the tester configures its downlink transmission power settings according to columns T3 in Table
8.3.4.1. UE shall detect DPCH from cell 1, but not detect the DPCH from cell 2 but continue to
communicate through DPCH from cell 1. The UE shall transmit a MEASUREMENT REPORT
message which indicates the event 1b for cell 2.


message. The tester calls for generic procedure C.3 to check that UE is in CELL_DCH state.
Test verification:
To confirm that the UE continues to communicate with the network on both the additional radio link
and an already existing radio link after the radio link addition.
Message flow:

UE NW
columns T1 in Table
8.3.4.1.
3 ACTIVE SET UPDATE Network transmits this
message in cell 1 on
downlink DCCH using AM
RLC. The message
Addition Information. (e.g.
Downlink DPCH
optional parameters
columns T2 in Table
8.3.4.1
CONFIRM



UE NW
9
9a Void
10 Wait 15 seconds and the
tester configures its
columns T3 in Table
8.3.4.1
CONFIRM
CELL_DCH state
Remarks:
AM RLC.
AM RLC.
AM RLC.
of the second radio branches.


B_8.3.4.2a Active set update in softer handover: Radio Link removal (FDD)
Test Purpose:
This procedure is to update the active set of the connections between the UE and the UTRAN after
the UTRAN has commanded a removal of a radio link from the current active set. The UTRAN RRC
transmits an ACTIVE SET UPDATE message to the UE RRC. The UE RRC requests UE L1 to
terminate transmission and reception of the radio link to be removed. The UE shall continue to
communicate normally with the UTRAN using the new active set, without losing the connection link.
After this the UE acknowledges the radio link removal by sending an ACTIVE SET UPDATE
COMPLETE message to the UTRAN on DCCH using AM RLC.
Pre-requisites:
Configurations: B, C
Network: 2 cells - both Cell 1 and Cell 2 are active - both cells are co-located on the same
NodeB.
UE: CS-DCCH+DTCH_DCH (state 6-9) or PS-DCCH+DTCH_DCH (state 6-10) in cell 1 as
specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE.
Table 8.3.4.2
T0 T1 T2 T3 T0 T1 T2 T3
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3. -60 -60 -75 -60 -75 -60 -60 OFF
84MHz
Test Procedure:
At the start of the test, the UE goes to connected mode and establishes a radio access bearer service
in the CELL_DCH state in cell 1.
8.3.4.2. UE shall be triggered to transmit a MEASUREMENT REPORT message which includes the
primary scrambling code for cell 2 according to IE Intra-frequency event identity, which is set to 1a
in the SYSTEM INFORMATION BLOCK TYPE 11. After the MEASUREMENT REPORT message is
received, the NW begins to configure the new radio link to be added from cell 2 and then the NW
transmits to the UE an ACTIVE SET UPDATE message in cell 1 on DCCH using AM RLC which
includes the IE Radio Link Addition Information (e.g. Downlink DPCH information and other optional
parameters relevant for the additional radio links with Primary CPICH info used for the reference ID).
When the UE receives this message, the UE shall configure layer 1 to begin reception without
affecting the current uplink and downlink activities of existing radio links. The UE shall transmit an
ACTIVE SET UPDATE COMPLETE message to the NW on the uplink DCCH using AM RLC. The
tester configures its downlink transmission power settings according to columns T2 in Table 8.3.4.2.
UE shall transmit a MEASUREMENT REPORT message which includes the primary scrambling code
for cell 1 according to IE Intra-frequency event identity, which is set to 1b in the SYSTEM
INFORMATION BLOCK TYPE 11. After the MEASUREMENT REPORT message is received, the NW
remove the radio link from cell 1 and then the NW transmits an ACTIVE SET UPDATE message,
which includes IE Radio Link Removal Information and specifying the P-CPICH information of the
cell to be removed. When the UE receives this message, the UE RRC entity shall request UE L1 entity
to terminate transmission and reception of the radio link from cell 1. Then the UE transmits an ACTIVE
SET UPDATE COMPLETE message to the network on the uplink DCCH using AM RLC.


The tester configures the downlink transmission power settings according to columns "T3" in table
8.3.4.2 so as to generate a radio link failure condition. The UE shall detect the radio link failure UE
shall re-select to cell 1 and transmit a CELL UPDATE message. NW transmits a CELL UPDATE
CONFIRM message after it receive CELL UPDATE message from UE. Then the UE shall transmit an
UTRAN MOBILITY INFORMATION CONFIRM message on the uplink DCCH to acknowledge the
receipt of the new UE identities.
Note:
The tester has to check the existence of the connection (by an internal trace or on IuB with the NBAP
message Radio_link_deletion_request/response).The tester configures its downlink transmission
power settings according to columns T3 in Table 8.3.4.2 so as to generate a radio link failure
condition. The UE shall detect the radio link failure and transmit a CELL UPDATE message to re-
establish an RRC CONNECTION.
Test verification:
To confirm that the UE continues to communicate with the network on the remaining radio link after
radio link removal on the active set. To confirm that the UE is not using the removed radio link to
communicate with the NW.
Message flow:

UE NW
columns T1 in Table
8.3.4.2
3 ACTIVE SET UPDATE NW transmits this message
in cell 1 on downlink DCCH
using AM RLC. The
message includes IE Radio
Link Addition Information.
(e.g. Downlink DPCH
optional parameters
columns T2 in Table
8.3.4.2




UE NW
7 ACTIVE SET UPDATE The network transmits this
message on downlink
DCCH using AM RLC which
Removal Information.
8 ACTIVE SET UPDATE COMPLETE The UE shall remove the
radio link associated with
cell 1.
The tester has to check the
existence of the connection
(by an internal trace or on
NW IuB with the NBAP
message
Radio_link_deletion_reques
t/response)
The tester configures its
12 power settings according to
columns T3 in Table
8.3.4.2
UE sends this message in
13 CELL UPDATE
cell 1.
UTRAN MOBILITY INFORMATION

15
CONFIRM
Remarks:
AM RLC.
AM RLC.
After step 7 the UE shall remove the radio link from cell 1 and it shall transmit an ACTIVE SET
UPDATE COMPLETE message on the uplink DCCH using AM RLC.
After step 12 the UE shall transmit a CELL UPDATE message on the CCCH with IE "Cell update
cause" set to "radio link failure".
of the second radio branch and that the UE stops transmitting on the first radio link.


B_8.3.4.2b Active set update in soft handover: Radio Link removal (FDD)
Test Purpose:
This procedure is to update the active set of the connections between the UE and the UTRAN after
the UTRAN has commanded a removal of a radio link from the current active set. The UTRAN RRC
transmits an ACTIVE SET UPDATE message to the UE RRC. The UE RRC requests UE L1 to
terminate transmission and reception of the radio link to be removed. The UE shall continue to
communicate normally with the UTRAN using the new active set, without losing the connection link.
After this the UE acknowledges the radio link removal by sending an ACTIVE SET UPDATE
COMPLETE message to the UTRAN on DCCH using AM RLC.
Pre-requisites:
Network: 2 cells - both Cell 1 and Cell 2 are active - both cells are not co-located on the same
NodeB.
Table 8.3.4.2

T0 T1 T2 T3 T0 T1 T2 T3
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3. -60 -60 -75 -60 -75 -60 -60 OFF
84MHz
Test Procedure:
At the start of the test, the UE goes to connected mode and establishes a radio access bearer service
in the CELL_DCH state in cell 1.
primary scrambling code for cell 2 according to IE Intra-frequency event identity, which is set to 1a
received, the NW begins to configure the new radio link to be added from cell 2 and then the NW
transmits to the UE an ACTIVE SET UPDATE message in cell 1 on DCCH using AM RLC which
includes the IE Radio Link Addition Information (e.g. Downlink DPCH information and other optional
parameters relevant for the additional radio links with Primary CPICH info used for the reference ID).
ACTIVE SET UPDATE COMPLETE message to the NW on the uplink DCCH using AM RLC. The
tester configures its downlink transmission power settings according to columns T2 in Table 8.3.4.2.
UE shall transmit a MEASUREMENT REPORT message which includes the primary scrambling code
for cell 1 according to IE Intra-frequency event identity, which is set to 1b in the SYSTEM
INFORMATION BLOCK TYPE 11. After the MEASUREMENT REPORT message is received, the NW
remove the radio link from cell 1 and then the NW transmits an ACTIVE SET UPDATE message,
which includes IE Radio Link Removal Information and specifying the P-CPICH information of the
cell to be removed. When the UE receives this message, the UE RRC entity shall request UE L1 entity
to terminate transmission and reception of the radio link from cell 1. Then the UE transmits an ACTIVE
SET UPDATE COMPLETE message to the network on the uplink DCCH using AM RLC.

The tester configures the downlink transmission power settings according to columns "T3" in table
8.3.4.2 so as to generate a radio link failure condition. The UE shall detect the radio link failure UE
shall re-select to cell 1 and transmit a CELL UPDATE message. NW transmits a CELL UPDATE
CONFIRM message after it receive CELL UPDATE message from UE. Then the UE shall transmit an
UTRAN MOBILITY INFORMATION CONFIRM message on the uplink DCCH to acknowledge the
receipt of the new UE identities.
Note:
The tester has to check the existence of the connection (by an internal trace or on IuB with the NBAP
message Radio_link_deletion_request/response).The tester configures its downlink transmission
power settings according to columns T3 in Table 8.3.4.2 so as to generate a radio link failure
condition. The UE shall detect the radio link failure and transmit a CELL UPDATE message to re-
establish an RRC CONNECTION.
Test verification:
To confirm that the UE continues to communicate with the network on the remaining radio link after
radio link removal on the active set. To confirm that the UE is not using the removed radio link to
communicate with the NW.
Message flow:

UE NW
columns T1 in Table
8.3.4.2
3 ACTIVE SET UPDATE NW transmits this message
in cell 1 on downlink DCCH
using AM RLC. The
message includes IE Radio
Link Addition Information.
(e.g. Downlink DPCH
optional parameters
columns T2 in Table
8.3.4.2



UE NW
7 ACTIVE SET UPDATE The network transmits this
message on downlink
DCCH using AM RLC which
Removal Information.
8 ACTIVE SET UPDATE COMPLETE The UE shall remove the
radio link associated with
cell 1.
The tester has to check the
existence of the connection
(by an internal trace or on
NW IuB with the NBAP
message
Radio_link_deletion_reques
t/response)
The tester configures its
12 power settings according to
columns T3 in Table
8.3.4.2
UE sends this message in
13 CELL UPDATE
cell 1.
UTRAN MOBILITY INFORMATION

15
CONFIRM
Remarks:
AM RLC.
AM RLC.
After step 7 the UE shall remove the radio link from cell 1 and it shall transmit an ACTIVE SET
UPDATE COMPLETE message on the uplink DCCH using AM RLC.
After step 12 the UE shall transmit a CELL UPDATE message on the CCCH with IE "Cell update
cause" set to "radio link failure".
of the second radio branch and that the UE stops transmitting on the first radio link.


E_ 8.3.4.3a Active set update in softer handover: Combined radio link addition and removal (FDD)
Test Purpose:
The purpose of this test is to confirm that the UE continues to communicate with the NW on the added
radio link and removes radio link which exists prior to the execution of active set update procedure.
Reference : 3GPP TS 25.331 clause 8.3.4
Pre-requisites:
Configuration : B,C
Network: 3 cells- Both Cell 1 Cell 2 and Cell 3 are active, with downlink transmission power
settings according to columns T0 in table 8.3.4.3.

specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE [Active
set is not full.]
Table 8.3.4.3
Paramete Uni Cell 1 Cell 2 Cell 3
r t
T0 T1 T2 T3 T4 T0 T1 T2 T3 T4 T0 T1 T2 T3 T4
UTRA RF
Channel Ch. 1 Ch. 1 Ch. 1
Number
dBm
CPICH Ec /3.84 -60 -60 -60 OFF -60 -80 -60 -60 OFF -70 -80 -80 -60 -60 OFF
MHz
Test Procedure:
The UE establishes a radio access bearer in the CELL_DCH state in cell 1.
The tester configures its downlink transmission power settings according to columns T1 in table
8.3.4.3. UE transmits a MEASUREMENT REPORT message which includes the primary scrambling
code for cell 2 according to IE "Intra-frequency event identity", which is set to 1a in the SYSTEM
INFORMATION BLOCK TYPE 11. After the MEASUREMENT REPORT message is received, the
tester configures the new radio link to be added from cell 2 and then the NW transmits to the UE in cell
1 an ACTIVE SET UPDATE message which includes IE "Radio Link Addition Information", indicating
the addition of cell 2 into the active set, on DCCH using AM RLC.
ACTIVE SET UPDATE COMPLETE message to the NW on the uplink DCCH using AM RLC.
The tester configures its downlink transmission power settings according to columns "T2" in table
primary scrambling code for cell 3 according to IE "Intra-frequency event identity", which is set to 1a
received, the NW configure the new radio link to be added from cell 3 and then the NW transmits to
the UE an ACTIVE SET UPDATE message which includes IE "Radio Link Addition Information" and IE
"Radio Link Removal Information", indicating the removal of cell 2 and addition of cell 3 into the active
set, on DCCH using AM RLC.


affecting the current uplink and downlink activities of existing radio links and then the UE removes the
radio link specified in an ACTIVE SET UPDATE message. The UE shall transmit an ACTIVE SET
UPDATE COMPLETE message to the NW on the uplink DCCH using AM RLC.
The tester configures its downlink transmission power settings according to columns T3 in table
Test Verification:
Verify that when radio links are to be replaced, the UTRAN RRC first configures the UTRAN L1 to
activate the radio link(s) that are being added. The UTRAN RRC then transmits an ACTIVE SET
UPDATE message to the UE RRC, which shall configure the UE L1 to terminate transmission and
reception on the removed radio link(s) and begin transmission and reception on the added radio
link(s). At the completion of the reconfiguration of radio links, the UE shall acknowledge the
replacement with an ACTIVE SET UPDATE COMPLETE message.
Message Flow:
Step Direction Messa ge Comment

UE NW
0a The tester configures the
initial active set with only
cell 1. The tester
configures its downlink
transmission power
settings according to
8.3.4.3
0b MEASUREMENT REPORT See specific message
0c ACTIVE SET UPDATE The NW transmit this
message on downlink
DCCH using AM RLC
which includes IE "Radio
Link Addition Information"
for cell 2.
0d ACTIVE SET UPDATE COMPLETE The UE adds the radio link
in cell 2.
8.3.4.3
3 ACTIVE SET UPDATE The NW transmit this
message on downlink
DCCH using AM RLC
for cell 3 and IE "Radio
Link Removal Information"
for cell 2.
new radio link in cell 3 and
removes the old radio link
in cell 2.



UE NW
4a Th tester configures its
8.3.4.3
9 CELL UPDATE
CONFIRM
Remarks:
At step 0a the UE shall transmit a MEASUREMENT REPORT message on the uplink DCCH using AM
RLC.
After step 0c the UE shall transmit an ACTIVE SET UPDATE COMPLETE message on the uplink
DCCH.
AM RLC.
DCCH.


E_ 8.3.4.3b Active set update in soft handover: Combined radio link addition and removal (FDD)
Test Purpose:
The purpose of this test is to confirm that the UE continues to communicate with the NW on the added
radio link and removes radio link which exists prior to the execution of active set update procedure.
Reference : 3GPP TS 25.331 clause 8.3.4
Pre-requisites:
Configuration: D, E
Network: 2 cells- Both Cell 1 and Cell 2 are active
specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE [Active
set is not full.]
Table 8.3.4.3

T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/3. -60 -75 -75 -60
84MHz
Test Procedure:
The UE establishes a radio access bearer in the CELL_DCH state in cell 1. The tester configures its
downlink transmission power settings according to columns "T1" in table 8.3.4.3. UE shall be triggered
to transmit a MEASUREMENT REPORT message which includes the primary scrambling code for cell
2 according to IE "Intra-frequency event identity", which is set to 1a in the SYSTEM INFORMATION
BLOCK TYPE 11. After the MEASUREMENT REPORT message is received, the NW begins to
configure the new radio link to be added from cell 2 and then the NW transmits to the UE in cell 1 an
ACTIVE SET UPDATE message which includes IE "Radio Link Addition Information" and IE "Radio
Link Removal Information", indicating the removal of cell 1 and addition of cell 2 into the active set, on
DCCH using AM RLC. When the UE receives this message, the UE shall configure layer 1 to begin
reception without affecting the current uplink and downlink activities of existing radio links and then the
UE removes the radio link specified in an ACTIVE SET UPDATE message. The UE shall transmit an
ACTIVE SET UPDATE COMPLETE message to the NW on the uplink DCCH using AM RLC. NW
removes the radio link in cell 1
Test Verification:
Verify that when radio links are to be replaced, the UTRAN RRC first configures the UTRAN L1 to
activate the radio link(s) that are being added. The UTRAN RRC then transmits an ACTIVE SET
UPDATE message to the UE RRC, which shall configure the UE L1 to terminate transmission and
reception on the removed radio link(s) and begin transmission and reception on the added radio
link(s). At the completion of the reconfiguration of radio links, the UE shall acknowledge the
replacement with an ACTIVE SET UPDATE COMPLETE message.


Message Flow:

UE NW
8.3.4.3
3 ACTIVE SET UPDATE The NW transmit this
message on downlink
DCCH using AM RLC
for cell 2 and IE "Radio
Link Removal Information"
for cell 1.
new radio link in cell 2 and
removes the old radio link
in cell 1.
Remarks:
AM RLC.
DCCH.


B_8.3.7.1 Inter system handover from UTRAN/To GSM/Speech/Success
Test purpose:
The UE shall be able to receive a HANDOVER FROM UTRAN COMMAND message and perform an
inter-RAT handover, even if no prior UE measurements have been performed on the target cell.
The UE shall:
1> establish the connection to the target radio access technology, by using the contents of the IE
"Inter-RAT message". This IE contains a message specified in another standard, as indicated
by the IE "System type", and carries information about the candidate/ target cell identifier(s) and
radio parameters relevant for the target radio access technology. The correspondence between
the value of the IE "System type", the standard to apply and the message contained within IE
"Inter RAT message" is shown in the following:
Value of the Standard to apply Inter RAT Message

IE "System
type"
GSM GSM TS 04.18, version 8.5.0 or later HANDOVER COMMAND
cdma2000 TIA/EIA/IS -2000 or later, TIA/EIA/IS -
833 or later, TIA/EIQ/IS-834 or later
1> if the IE "System type" has the value "GSM":
2> if the IE "Frequency band" has the value "GSM /DCS 1800 band used":
3> set the BAND_INDICATOR [45] to "ARFCN indicates 1800 band".
2> if the IE "Frequency band" has the value " GSM /PCS 1900 band used":
1> apply the "Inter RAT Message" according to the "standard to apply" in the table above.
1> if the IE "RAB information List" is included in the HANDOVER FROM UTRAN COMMAND
message:
2> if the IE "RAB information List" includes one IE "RAB Info" with the IE "CN domain Identity"
set to "CS domain":
3> connect upper layer entities corresponding to the indicated CS domain RAB to the radio
resources indicated in the inter-RAT message.
NOTE: In this version of the specification the maximum number of CS domain RABs which may
be included in the IE "RAB information List" is limited to 1.
NOTE: Requirements concerning the establishment of the radio connection towards the other
radio access technology and the signalling procedure are outside the scope of this
specification.
Upon successfully completing the handover, the UE shall:

1> if the USIM is present:
2> store the current START value for every CN domain in the USIM [50];
2> if the "START" stored in the USIM [50] for a CN domain is greater than or equal to the value
"THRESHOLD" of the variable START_THRESHOLD:
3> delete the ciphering and integrity keys that are stored in the USIM for that CN domain;


3> inform the deletion of these keys to upper layers.
1> if the SIM is present:
2> store the current START value for every CN domain in the UE;
2> if the "START" stored in the UE for a CN domain is greater than or equal to the value
3> delete the ciphering and integrity keys that are stored in the SIM for that CN domain;
1> if there are any NAS messages with the IE "CN domain identity" set to "CS domain" for which
the successful delivery of the INITIAL DIRECT TRANSFER message or UPLINK DIRECT
TRANSFER message on signalling radio bearer RB3 or signalling radio bearer RB4 that have
not yet been confirmed by RLC:
2> retransmit those NAS messages to the network on the newly established radio connection to
the target radio access technology.
1> clear or set variables upon leaving UTRA RRC connected mode as specified in subclause 13.4.
NOTE: The release of the UMTS radio resources is initiated from the target RAT.
Reference(s): TS 25.331 Clause 8.3.7.3, 8.3.7.4.
Pre-requisites:
Configurations: F
Network: 2 cells - Cell 1 is UTRAN, Cell 2 is GSM. GSM 51.010 section 26.6.5.1 shall be
referenced for the default parameters of cell 2.
UE : CC State U10 in cell 1 (CS voice call established), one CS domain RAB is established
and no PS domain RABs are established
UE supports both GSM and UTRAN Radio Access Technologies,
Test Procedure:
The tester starts the UTRAN cell and brings the UE into call active state (CC state U10) with AMR.
The tester starts GSM, then sends HANDOVER FROM UTRAN COMMAND indicating the traffic
channel of the target GSM cell to the UE through DCCH of the serving UTRAN cell. After the UE
receives the command it shall configure itself accordingly and switch to the new channel of the target
GSM cell. The tester checks whether the handover is performed by checking that the UE transmits the
HANDOVER COMPLETE message to the network through GSM cell.
Test verification:
To test that the UE supporting both GSM and UTRAN handovers from a UTRAN serving cell to the
indicated channel of GSM target cell when the UE is in the speech call active state and receives an
HANDOVER FROM UTRAN COMMAND
Message flow:
This sequence is performed for a maximum execution counter M = 1, 2, 3, 4.

UE NW


1 The tester bring the UE into UTRAN U10 state

in cell 1
2 The NW configures cell 2 as a GSM cell with a
traffic channel:
for GSM AMR (M = 1); or
for GSM EFR (M = 2); or
for GSM FR (M = 3); or
for GSM HR (M = 4).
3 HANDOVER FROM UTRAN Send on cell 1 (UTRAN cell) and the message
COMMAND-GSM indicates:
the target channel for GSM AMR (M = 1); or
the target channel for GSM EFR (M = 2); or
the target channel for GSM FR (M = 3); or
the target channel for GSM HR (M = 4).
4 The UE accepts the handover command and
switches to the GSM traffic channel specified in
the HANDOVER FROM UTRAN COMMAND-
GSM
5 HANDOVER ACCESS The network receives this burst on the traffic
channel of cell 2 (GSM cell) It implies that the
UE has switched to GSM cell.
6 HANDOVER ACCESS
7 HANDOVER ACCESS
8 HANDOVER ACCESS
9 PHYSICAL INFORMATION
10 SABM
11 UA
12 HANDOVER COMPLETE The network receives the message on the
traffic channel of GSM cell.
Remarks:
After step 12 the ongoing call shall be continued on the GSM cell.


B_8.3.7.2 Inter system handover from UTRAN/To GSM/Data/Same data rate/Success
Test Purpose:
The UE shall be able to receive a HANDOVER FROM UTRAN COMMAND message and perform an
inter-RAT handover, even if no prior UE measurements have been performed on the target cell.
The UE shall:
1> establish the connection to the target radio access technology, by using the contents of the IE
"Inter-RAT message". This IE contains a message specified in another standard, as indicated
by the IE "System type", and carries information about the candidate/ target cell identifier(s) and
radio parameters relevant for the target radio access technology. The correspondence between
the value of the IE "System type", the standard to apply and the message contained within IE
"Inter RAT message" is shown in the following:
Value of the Standard to apply Inter RAT Message

IE "System
type"
GSM GSM TS 04.18, version 8.5.0 or later HANDOVER COMMAND
cdma2000 TIA/EIA/IS -2000 or later, TIA/EIA/IS -
833 or later, TIA/EIQ/IS-834 or later
1> if the IE "System type" has the value "GSM":
2> if the IE "Frequency band" has the value "GSM /DCS 1800 band used":
2> if the IE "Frequency band" has the value " GSM /PCS 1900 band used":
1> apply the "Inter RAT Message" according to the "standard to apply" in the table above.
1> if the IE "RAB information List" is included in the HANDOVER FROM UTRAN COMMAND
message:
2> if the IE "RAB information List" includes one IE "RAB Info" with the IE "CN domain Identity"
set to "CS domain":
3> connect upper layer entities corresponding to the indicated CS domain RAB to the radio
resources indicated in the inter-RAT message.
NOTE: In this version of the specification the maximum number of CS domain RABs which may
be included in the IE "RAB information List" is limited to 1.
NOTE: Requirements concerning the establishment of the radio connection towards the other
radio access technology and the signalling procedure are outside the scope of this
specification.
Upon successfully completing the handover, the UE shall:

1> if the USIM is present:
2> store the current START value for every CN domain in the USIM [50];
2> if the "START" stored in the USIM [50] for a CN domain is greater than or equal to the value
3> delete the ciphering and integrity keys that are stored in the USIM for that CN domain;


1> if the SIM is present:
2> store the current START value for every CN domain in the UE;
2> if the "START" stored in the UE for a CN domain is greater than or equal to the value
3> delete the ciphering and integrity keys that are stored in the SIM for that CN domain;
1> if there are any NAS messages with the IE "CN domain identity" set to "CS domain" for which
the successful delivery of the INITIAL DIRECT TRANSFER message or UPLINK DIRECT
TRANSFER message on signalling radio bearer RB3 or signalling radio bearer RB4 that have
not yet been confirmed by RLC:
2> retransmit those NAS messages to the network on the newly established radio connection to
the target radio access technology.
1> clear or set variables upon leaving UTRA RRC connected mode as specified in subclause 13.4.
NOTE: The release of the UMTS radio resources is initiated from the target RAT.
Reference(s): TS 25.331 Clause 8.3.7.3, 8.3.7.4.
Pre-requisites:
Configurations: F
Network : 2 cells - Cell 1 is UTRAN, Cell 2 is GSM. GSM 51.010-1 section 26.6.5.1? or
section 26.13.1.3? (for HSCSD) shall be referenced for the default parameters of cell 2.
UE : CC State U10 in cell 1 (CS data call established), one CS domain RAB is established
and no PS domain RABs are established
UE supports both GSM and UTRAN Radio Access Technologies:
UE supports UTRAN Streaming/unknown/uplink:14.4 DL:14.4 kbps/CS RAB + uplink:3.4
DL:3.4 kbps SRBs,
DL:3.4 kbps SRBs,
DL:3.4 kbps SRBs,
UE supports GSM 14.4 kbps data (HSCSD or full rate traffic channel for 14.4 kbit/s user
data (TCH/F14.4)),
UE supports GSM 28.8 kbps data (HSCSD or enhanced circuit switched full rate traffic
channel for 28.8 kbit/s user date (E-TCH/F28.8)),
UE supports GSM 57.6 kbps data,
Test Procedure:
The tester brings the UE into data call active state on the UTRAN cell (CC state U10) with a suitable
configuration (e.g. Streaming/unknown/uplink:14.4 DL:14.4 kbps/CS RAB + uplink:3.4 DL:3.4 kbps
SRBs for M = 1). According to specific event (measurement report), the network sends HANDOVER
FROM UTRAN COMMAND indicating the traffic channel of the target GSM cell to the UE through
DCCH of the serving UTRAN cell. After the UE receives the command it shall configure itself
accordingly and switch to the new channel of the GSM cell. The tester checks whether the handover is
performed by checking that the UE transmits the HANDOVER COMPLETE message to the network in
GSM cell.
Test Verification:

To test that the UE handovers to the indicated channel of same data rate in the GSM target cell when
it is in the data call active state in the UTRAN serving cell and receives an HANDOVER FROM
UTRAN COMMAND.
Message flow:

UE NW
1 UE The tester brings the UE into UTRAN U10 state in
cell 1, the configuration is:
Streaming/unknown/uplink:14.4 DL:14.4 kbps/CS
RAB + uplink:3.4 DL:3.4 kbps SRBs (for M = 1);
RAB + uplink:3.4 DL:3.4 kbps SRBs (for M = 3).
2 NW The GSM network configures cell 2 with a traffic
channel:
for GSM 14.4 kbps data (M = 1); or
for GSM 57.6 kbps data (M = 3).
the target channel
for GSM 57.6 kbps data (M = 3).
4 UE The UE accepts the handover command and
switches to the GSM traffic channel specified in the
HANDOVER FROM UTRAN COMMAND-GSM
5 HANDOVER ACCESS The network receives this burst on the traffic
channel of cell 2 (GSM cell) It implies that the UE
has switched to GSM cell.
6 HANDOVER ACCESS
7 HANDOVER ACCESS
8 HANDOVER ACCESS
10 SABM
11 UA
12 HANDOVER COMPLETE The network receives the message on the traffic
channel of GSM cell.
Remarks:


E_8.3.7.3 Inter system handover from UTRAN/To GSM/Data/Data rate down grading/Success
Test Purpose:
The purpose of this test is to test that the UE handovers to the indicated channel of lower data rate in
the GSM target cell when it is in the data call active state in the UTRAN serving cell and receives an
HANDOVER FROM UTRAN COMMAND.
Reference :TS 25.331 Clause 8.3.7.3.
Pre-requisites:
Configuration : F
Network : 2 cells - Cell 1 is UTRAN, Cell 2 is GSM. GSM 51.010 clause 26.6.5.1 or clause
26.13.1.3 (for HSCSD) shall be referenced for the default parameters of cell 2.
UE: CC State U10 in cell 1, one CS domain RAB and one PS domain RAB (e.g. interactive/
background UL: 32kbps, DL: 32 kbps, others can be used) is established (Conditional on support
of CS+PS in UE).
UE supports both GSM and UMTS Radio Access Technologies,
UE supports UTRAN Streaming/unknown/uplink:28.8 DL:28.8 kbps/CS RAB + uplink:3.4 DL:3.4
kbps SRBs,
UE supports UTRAN Streaming/unknown/uplink:57.6 DL:57.6 kbps/CS RAB + uplink:3.4 DL:3.4
kbps SRBs,
UE supports GSM 14.4 kbps data,
UE support CS and PS service
Test Procedure:
The NW starts the UTRAN cell and brings the UE into data call active state (CC state U10) with a
suitable configuration (e.g. Streaming/unknown/uplink:28.8 DL:28.8 kbps/CS RAB + uplink:3.4 DL:3.4
kbps SRBs for M = 1). The NW starts GSM cell and configures a traffic channel (e.g. 14.4 kbps data
channel for M = 1), then sends HANDOVER FROM UTRAN COMMAND indicating the traffic channel
of the target GSM cell to the UE through DCCH of the serving UTRAN cell. After the UE receives the
command it shall configure itself accordingly and switch to the new channel of the GSM cell. The
tester checks whether the handover is performed by checking that the UE transmits the HANDOVER
COMPLETE message to the NW in GSM cell.
Upon completion of the handover, depending on UE capabilities, the UE performs routing area update
and (re-) establishes the connection towards the PS domain.
Test Verification:
Verify that when the UE receives an HANDOVER FROM UTRAN COMMAND message from UTRAN
the UE shall take the following actions:
- Establish the connection to the other radio access system, by using the contents of the IE
"Inter system message". This IE contains candidate/ target cell identifier(s) and radio parameters
relevant for the other radio access system.
- For each IE "Remaining radio access bearer", associate the radio access bearer given by the
IE "RAB info" to the radio resources in the target system given by the IE "Inter system message".
Other information for making the association may be included in the IE "Inter system message" and
requirements may be stated in the specifications relevant for the target system [FFS].
- Switch the current connection to the other radio access system.
NOTE 1: Requirements concerning the establishment of the radio connection towards the other
radio access system and the signalling procedure are outside the scope of the present
document.
NOTE 2: The release of the UMTS radio resources is initiated by the other system.


NOTE 3: Currently only one radio access bearer can be associated with the IE "Inter-system
message", and this association is limited to the radio access bearers in the CS
domain. It is assumed that all the radio access bearers in the PS domain, if any,
remain after the handover.
Message Flow:

UE NW
1 UE The NW bring the UE into UTRAN U10 state in cell
1, the configuration is:
RAB + uplink:3.4 DL:3.4 kbps SRBs (for M = 2 and
3).
2 NW The The tester configures cell 2 as a GSM cell with
a traffic channel:
for GSM 14.4 kbps data (M = 1 and 2).
the target channel
for GSM 14.4 kbps data (M = 1 and 2).
5 HANDOVER ACCESS The NW receives this burst on the traffic channel of
cell 2 (GSM cell) It implies that the UE has switched
to GSM cell.
6 HANDOVER ACCESS
7 HANDOVER ACCESS
8 HANDOVER ACCESS
10 SABM
11 UA
12 HANDOVER COMPLETE The NW receives the message on the traffic
13 ROUTING AREA UPDATE Conditional on Class A UE.
Remarks:


E_8.3.7.4 Inter system handover from UTRAN/To GSM/Speech/Establishment/Success
Test Purpose:
The purpose of this test is to test that the UE handovers to the indicated channel in the GSM target
cell when it is in the call establishment phase in the UTRAN serving cell and receives an HANDOVER
FROM UTRAN COMMAND.
Reference: TS 25.331 Clause 8.3.7.3.
Pre-requisites:
Configuration : F
Network : 2 cells - Cell 1 is UTRAN, Cell 2 is GSM. GSM 51.010 clause 26.6.5.1 shall be
UE : CC State U1 in cell 1, no RABs are established
UE supports both GSM and UMTS Radio Access Technologies,
UE supports UTRAN AMR,
UE supports GSM FR,
Test Procedure:
The NW starts the UTRAN cell and the UE is triggered to initialise an MO speech call. During the call
establishment phase, after the NW receives SETUP message the NW starts GSM cell and configures
a dedicated channel, then sends the UE an HANDOVER FROM UTRAN COMMAND indicating the
dedicated channel in the target GSM cell. After the UE receives the command it shall configure itself
accordingly and switch to the new channel of the GSM cell. The tester checks whether the handover is
performed by checking that the UE transmits the HANDOVER COMPLETE message to the NW in
GSM cell.
Test Verification:
Verify that when the UE receives an HANDOVER FROM UTRAN COMMAND message from UTRAN
the UE shall take the following actions:
- Establish the connection to the other radio access system, by using the contents of the IE
"Inter system message". This IE contains candidate/ target cell identifier(s) and radio parameters
relevant for the other radio access system.
- For each IE "Remaining radio access bearer", associate the radio access bearer given by the
IE "RAB info" to the radio resources in the target system given by the IE "Inter system message".
Other information for making the association may be included in the IE "Inter system message" and
requirements may be stated in the specifications relevant for the target system [FFS].
- Switch the current connection to the other radio access system.
NOTE 1: Requirements concerning the establishment of the radio connection towards the other
radio access system and the signalling procedure are outside the scope of the present
document.
NOTE 2: The release of the UMTS radio resources is initiated by the other system.
NOTE 3: Currently only one radio access bearer can be associated with the IE "Inter-system
message", and this association is limited to the radio access bearers in the CS
domain. It is assumed that all the radio access bearers in the PS domain, if any,
remain after the handover.


Message Flow:

UE NW
1 UE To trigger the UE to initialise an MO call
2 SETUP U1
3 NW The NW starts the GSM cell and configure a
dedicated channel SDCCH.
the dedicated channel SDCCH.
switches to the GSM dedicated channel specified in
the HANDOVER FROM UTRAN COMMAND-GSM
6 HANDOVER ACCESS The NW receives this burst on the dedicated
channel of cell 2 (GSM cell) It implies that the UE
has switched to GSM cell.
7 HANDOVER ACCESS
8 HANDOVER ACCESS
9 HANDOVER ACCESS
11 SABM
12 UA
13 HANDOVER COMPLETE The NW receives the message on the dedicated
Remarks:
At step 13 the NW shall receive HANDOVER COMPLETE message on the dedicated channel of the
GSM cell.


E_8.3.7.5 Inter system handover from UTRAN/To GSM/Speech/Failure
Test Purpose:
The purpose of this test is to test that the UE reactivates the old configuration and uses this to transmit
a HANDOVER FROM UTRAN FAILURE message to the network including IE "Inter-RAT Handover
failure cause" which is set to "physical channel failure", when it receives an HANDOVER FROM
UTRAN COMMAND and the connection to GSM for handover can not be established.
Another purpose is to verify that after the handover failure the UE resumes previously configured
compressed mode patterns and measurements.
Reference : TS 25.331 Clause 8.3.7.5.
Pre-requisites:
Configuration : F
Network : 2 cells - Cell 1 is UTRAN, Cell 2 is GSM. GSM 51.010 clause 26.6.5.1 shall be
UE: CC State U10 in cell 1
UE supports GSM FR,
UE supports UTRAN AMR,
Test Procedure:
The NW starts the UTRAN cell and brings the UE into call active state (CC state U10) with AMR. If the
UE requires compressed mode, the NW sends a PHYSICAL CHANNEL RECONFIGURATION
message to the UE to configure the compressed mode pattern sequence parameters. When the
PHYSICAL CHANNEL RECONFIGURATION COMPLETE is received from the UE, the NW sends a
MEASUREMENT CONTROL message. This message is used to provide measurement control
parameters (GSM RSSI) to the UE and to start compressed mode for the measurement if required
according to the UE capabilities. The UE replies according to request by sending RRC:
MEASUREMENT REPORT messages periodically to NW (reporting period is 1000 ms).
The NW starts GSM cell without activating any dedicated channel in the cell, then sends HANDOVER
FROM UTRAN COMMAND indicating a dedicated channel of the target GSM cell to the UE through
DCCH of the serving UTRAN cell. The UE receives the command and configures itself accordingly but
can not complete the handover. The tester checks that the handover is failed by checking that the UE
transmits the HANDOVER FROM UTRAN FAILURE message to the NW using the old UTRAN
configuration.
After the handover failure, the UE re-activates compressed mode (if configured) and resumes periodic
measurement reporting including sending MEASUREMENT REPORT messages periodically to NW.
Test Verification:
Verify that if the UE does not succeed to establish the connection to the other radio access
technology, it shall
- resume the connection to UTRAN using the resources used before receiving the HANDOVER
FROM UTRAN COMMAND message; and
- transmit the INTER-SYSTEM HANDOVER FAILURE message on uplink DCCH using AM
RLC. When the successful delivery of the INTER-SYSTEM FAILURE message has been confirmed by
RLC, the procedure ends.


Message Flow:

UE NW
1 UE The NW bring the UE into U10 state in UTRAN cell
1. If the UE does not require compressed mode,
then goto step 1c.
1a PHYSICAL CHANNEL Compressed mode pattern sequence parameters
RECONFIGURATION are loaded to UE.
1b PHYSICAL CHANNEL
RECONFIGURATION
COMPLETE
1c MEASUREMENT CONTROL NW provides GSM RSSI measurement control
parameters to UE. Compressed mode for GSM
RSSI measurement is started.
1d MEASUREMENT REPORT UE reports measurement results of GSM RSSI
measurement to NW.
2 NW The NW configures cell 2 as a GSM cell but without
any traffic channel.
the target channel for GSM FR which does not exist
in the GSM cell.
5 HANDOVER FROM UTRAN The NW receives the message via the old UTRAN
FAILURE configuration.
5a MEASUREMENT REPORT The NW shall verify that the UE resumes periodic
measurement reporting for GSM RSSI
measurements
Remarks:
After step 4 the NW shall receive HANDOVER FROM UTRAN FAILURE message using the old UTRA
configuration.
After step 5 the UE shall correctly report the GSM RSSI value.


B_8.3.9.1 Cell reselection if cell becomes barred or S<0; UTRAN to GPRS (CELL_FACH)
Test Purpose:
The purpose of this test to verify that if both a GSM/GPRS and UTRAN network is available, the UE
performs cell reselection from UTRAN to GSM/GPRS if the UTRAN cell becomes barred or S falls
below zero.
Reference : TS 25.331 Clause 8.3.9
Pre-requisites:
Configuration : F
Network : cells Cell 1 is UTRAN FDD, Cell 2 is GPRS and Cell 3 is GSM
The Inter-RAT Cell Info List of Cell 1 (UTRAN) refers to Cell 2 (GPRS) and Cell 3 (GSM).
The 3G Neighbour Cell Description of Cell 2 (GPRS) and Cell 3 (GSM) refers to Cell 1 (UTRAN)
UE: PS-DCCH+DTCH_FACH (State 6-11) in cell 1 as specified in clause 7.4 of TS 34.108, one PS
domain RAB is established.
UE supports UTRAN interactive/ background UL: 64kbps, DL: 64 kbps/PS RAB + uplink:3.4 DL:3.4
kbps SRBs,
Test Procedure:
Step a-c:
Cell 1
Parameter Unit
(UTRAN)
Test Channel 1
CPICH Ec (FDD) dBm -60
Qrxlevmin dBm -101
Srxlev* dBm 41
CellBarred Not barred
Cell 2
Parameter Unit
(GPRS)
Test Channel 1
RF Signal Level dBm -75
RXLEV_ACCESS_
dBm -100
MIN
C1* dBm 25
FDD_Qmin dB -20
FDD_Qoffset dBm 0


Cell 3
Parameter Unit
(GSM)
Test Channel 2
RXLEV_ACCESS_
dBm -100
MIN
C1* dBm 15
FDD_Qmin dB -20
FDD_Qoffset dBm 0
Step d-f:
Cell 1
Parameter Unit
(UTRAN)
CellBarred Not barred -> Barred
Tbarred S 80
Step i:
Cell 1
Parameter Unit
(UTRAN)
Qrxlevmin DB -101 -> -41
Srxlev* DB 41 -> -19
Test procedure
a) The tester activates cells 1, 2, and 3. The NW monitors cells 1, 2 and 3 for random access requests
from the UE.
c) The NW brings the UE to PS-DCCH+DTCH_FACH (State 6-11 in 34.108).
d) The NW sets Cell 1 to be barred.
e) The NW sends SYSTEM INFORMATION CHANGE INDICATION message to UE to inform UE of

the modification in the system information.
f) The NW waits for channel request from the UE to establish a Temporary Block flow.
g) The NW pages the UE with PAGING TYPE 2 in Cell 1 (UTRAN), if UE does not respond by
transmitting an upper layer message to answer this page, it means UE has released the UTRAN
resources.
h) The UE is switched off.
i) Step a-e) is repeated with the same initial conditions except that in step d), Qrxlevmin is increased,
so S will become negative instead of being barred.
Test Verification:
Verify that the UE performs reselection from UTRAN to GPRS in the state CELL_FACH on the
following occasions:
Serving cell becomes barred.



Verify when the UE has succeeded in reselecting a cell in the target radio access technology and has
initiated the establishment of a connection, it shall release all UTRAN specific resources.
Message Flow:

UE NW
1 The tester activates cells 1, 2, and 3
2 UE is switched ON and brought to PS-
DCCH+DTCH_FACH state by network.
3 The NW sets Cell 1 to be barred
CHANGE INDICATION
5 The NW waits for channel request from the UE to
establish a Temporary Block flow.
6 PAGING TYPE 2 UE does not respond
Remarks:
In step f), the UE shall respond on Cell 2
In step g), the UE shall not respond in UTRAN cell.
In step i), the UE shall respond on Cell 2 after Qrxlevmin is increased.


E_8.3.9.2 Cell reselection if cell becomes barred or S<0; UTRAN to GPRS (URA_PCH)
Test Purpose:
The purpose of this test to verify that if both a GSM/GPRS and UTRAN network is available, the UE
performs cell reselection from UTRAN to GSM/GPRS if the UTRAN cell becomes barred or S falls
below zero.
Reference : TS 25.331 Clause 8.3.9
Pre-requisites:
Configuration : F: 2 cells Cell 1 is UTRAN FDD, Cell 2 is GPRS.
The Inter-RAT Cell Info List of Cell 1 (UTRAN) refers to Cell 2 (GPRS).
The 3G Neighbour Cell Description of Cell 2 (GPRS) refers to Cell 1 (UTRAN)
UE: URA _PCH in cell 1 as specified in clause 7.4 of TS 34.108.
UE supports both GSM/GPRS and UTRAN Radio Access Technologies,
UE supports UTRAN interactive/ background UL: 128kbps, DL: 128 kbps/PS RAB + uplink:3.4
DL:3.4 kbps SRBs,
Test Procedure:
Step a-c:
Cell 1
Parameter Unit
(UTRAN)
Test Channel 1
CPICH Ec (FDD) dBm -60
Qrxlevmin dBm -101
Srxlev* dBm 41
CellBarred Not barred
Cell 2
Parameter Unit
(GPRS)
Test Channel 1
RXLEV_ACCESS_
dBm -100
MIN
C1* dBm 20
FDD_Qmin dB -20
FDD_Qoffset dBm 0
Step d-f:
Cell 1
Parameter Unit
(UTRAN)
CellBarred Not barred -> Barred
Tbarred s 80


Step i:
Cell 1
Parameter Unit
(UTRAN)
Qrxlevmin dB -101 -> -41
Srxlev* dB 40 -> -20
Test procedure
a) The SS activates cells 1, 2, and 3. The SS monitors cells 1, 2 and 3 for random access requests
from the UE.
c) The SS brings the UE to URA_PCH (State 6-13).
d) The SS sets Cell 1 to be barred.
e) The SS sends SYSTEM INFORMATION CHANGE INDICATION message to UE to inform UE of
the modification in the system information.
f) The SS waits for channel request from the UE to establish Temporary Block flow
g) The SS pages the UE with PAGING TYPE 1 in cell 1 (UTRAN), if UE does not respond with RRC
Connection Request, it means UE has released the UTRAN resources.
h) The UE is switched off.
i) Step a-e) is repeated with the same initial conditions except that in step d), Qrxlevmin is increased,
so S will become negative instead of being barred.
Test Verification:
Verify that the UE performs reselection from UTRAN to GPRS in the state URA_P CH on the following
occasions:
Serving cell becomes barred.
Message Flow:

UE NW
1 The tester activates cells 1, 2, and 3
2 UE is switched ON and brought to URA_PCH state
by network.
3 The NW sets Cell 1 to be barred
CHANGE INDICATION
5 The NW waits for channel request from the UE to
establish a Temporary Block flow.
6 PAGING TYPE 1 UE does not respond
Remarks:
In step f), the UE shall respond on Cell 2.
In step g), the UE shall not respond in UTRAN cell.
In step i), the UE shall respond on Cell 2 after Qrxlevmin is increased.


B_8.3.11.1 Inter-RAT cell change order from UTRAN/To GPRS/CELL_DCH/Success
Test Purpose:
CELL_DCH state and perform a cell change to another RAT, even if no prior UE measurements have
been performed on the target cell. The UE regards the procedure as completed when it has received a
(PACKET) CHANNEL REQUEST in the new cell.
Reference : TS 25.331 Clause 8.3.11, B.6
Pre-requisites:
Configuration : F : 2 cells - Cell 1 is UTRAN, Cell 2 is GPRS

UE: PS-DCCH+DTCH_DCH (State 6-10) in cell 1 as specified in clause 7.4 of TS 34.108, one PS
UE supports UTRAN interactive/ background UL: 64kbps, DL: 64 kbps/PS RAB + uplink:3.4 DL:3.4
kbps SRBs,
Test Procedure:
The tester starts the UTRAN cell and brings the UE into PS-DCCH+DTCH_DCH (State 6-10). The
tester starts GPRS cell, then network sends CELL CHANGE ORDER FROM UTRAN indicating the
target cell description, GPRS cell, to the UE through DCCH of the serving UTRAN cell. After the UE
receives the command it shall configure itself accordingly and switch to the new channel on the target
GPRS cell. The NW checks whether the cell change is performed by checking that the UE receives a
successful response to the CHANNEL REQUEST message from the NW through GPRS cell. The UE
sends a RA UPDATE REQUEST message to indicate that the UTRAN UE context needs to be
transferred to GPRS.
Test Verification:
Verify that the UE is able to receive a CELL CHANGE ORDER FROM UTRAN message in
been performed on the target cell.


Message Flow:

UE NW
1 UE The tester brings the UE into PS-DCCH+DTCH_DCH
2 NW The tester configures cell 2 as a GSM cell with GPRS
enabled
UTRAN
ORDER FROM UTRAN
5 CHANNEL REQUEST The NW receives this burst on the RACH of cell 2 to
establish temporary block flow (GPRS cell). It implies that
the UE has switched to GPRS cell.
6 IMMEDIATE ASSIGNMENT Uplink dynamic allocation. Sent on AGCH.
REQUEST
Remarks:


B_8.3.11.2 Inter-RAT cell change order from UTRAN/To GPRS/CELL_FACH/Success
Test Purpose:
CELL_FACH state and perform a cell change to another RAT, even if no prior UE measurements have
been performed on the target cell. The UE regards the procedure as completed when it has received a
CHANNEL REQUEST in the new cell.
Reference : TS 25.331 Clause 8.3.11, B.6
Pre-requisites:
Configuration : F: 2 cells - Cell 1 is UTRAN, Cell 2 is GPRS with PBCCH.

UE: PS-DCCH+DTCH_FACH (state 6-11) in cell 1 as specified in clause 7.4 of TS 34.108, one PS
UE supports UTRAN interactive/ background UL: 64kbps, DL: 64 kbps/PS RAB + uplink:3.4
DL:3.4 kbps SRBs,
Test Procedure:
The tester starts the UTRAN cell and brings the UE into PS-DCCH+DTCH_FACH (state 6-11). The
tester starts GPRS cell, then NW sends CELL CHANGE ORDER FROM UTRAN indicating the target
cell description, GPRS cell, to the UE through DCCH of the serving UTRAN cell. After the UE receives
the command it shall configure itself accordingly and switch to the new channel on the target GPRS
cell. The tester checks whether the cell change is performed by checking that the UE receives a
successful response to the CHANNEL REQUEST message from the SS through GPRS cell. The UE
sends a RA UPDATE REQUEST message to indicate that the UTRAN UE context needs to be
transferred to GPRS.
Test Verification:
Verify that the UE is able to receive a CELL CHANGE ORDER FROM UTRAN message in
been performed on the target cell.


Message Flow:
UE NW
1 UE The tester brings the UE into PS-DCCH_DTCH_FACH
2 NW The tester configures cell 2 as a GSM cell with GPRS
enabled
UTRAN
to the GPRS specified in the CELL CHANGE ORDER
FROM UTRAN
5 PACKET CHANNEL REQUEST The NW receives this burst on PRACH of cell 2 (GPRS
cell) to establish temporary block flow. It implies that the
UE has switched to GPRS cell.
6 PACKET UPLINK ASSIGNMENT Uplink dynamic allocation
Sent on PAGCH.
REQUEST
Remarks:


B_8.4.1.1 Measurement Control and Report: Intra-frequency measurement for transition from
idle mode to CELL_DCH state (FDD)
Test Purpose:
Upon a state transition from idle mode to CELL_DCH state, the UE shall begin or continue to monitor
the list of cells assigned in the IE intra-frequency cell info list which is specified in System
Information Block type 11 or 12 messages on BCCH. When entering CELL_DCH state, the UE shall
send MEASUREMENT REPORT message(s) when the condition(s) in intra-frequency measurement
reporting criteria IE received are. fulfilled. In CELL_DCH state, if the UE receives a MEASUREMENT
CONTROL message, which contains a measurement identity IE with the same value as to the intra-
frequency measurement identity in System Information Block Type 11 or 12 message, it shall
terminate existing monitoring activities for the neighbouring cells previously known from System
Information Block type 11 or 12 messages. It shall perform the measurement and reporting tasks
based on the latest MEASUREMENT CONTROL message received.
Pre-requisites:
Configurations: C
Network: 3 cells Cell 1, cell 2 and cell 3 are active.
UE: Registered idle mode on CS (state 2) or Registered idle mode on PS (state 3) in cell 1
as specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE If
the UE supports both CS and PS domains, the initial UE state shall be Registered idle mode
on CS/PS (state 7).
Test Procedure:
Table B_8.4.1.1-1 illustrates the downlink power to be applied for the 3 cells at various time instants of
the test execution. Column marked T0 denotes the initial conditions, while columns marked T1 and
T2 are to be applied subsequently. The exact instants on which these values shall be applied are
described in the texts in this sub-clause.
Table 8.4.1.1-1

T0 T1 T2 T0 T1 T2 T0 T1 T2
UTRA RF
Channel Ch. 1 Ch. 1 Ch.1
Number
CPICH Ec dBm/3.8 -60 -60 -60 -70 -80 -60 -60 -80 -80
4 MHz
The UE is initially in idle mode and has selected cell 1 for camping. The System Information Block
type 11 messages are modified with respect to the default settings to prevent reporting of Cell
synchronisation information and also to include cell 2 into the monitored neighbour cell list
the tester makes an outgoing call of a supported traffic class. The NW and UE shall execute
procedure P3 (for CS service) or P5 (for PS service). Next the NW and UE shall execute procedure P7
(for CS service) or P9 (for PS service). (The procedures P3, P5,P7, P9 and P11 are defined in
34.108)Then the NW and UE shall execute procedure P11 (for CS service) or P13 (for PS
service).The UE shall send a MEASUREMENT REPORT message after reaching CELL_DCH state,
reporting cell 2s measurement quantity value.
The NW sends a MEASUREMENT CONTROL message on the downlink DCCH. In this message, the
network configures an intra-frequency measurement based on the measurement quantity CPICH
RSCP. Parameters used in this message are: measurement identity = 1, report criteria = event-
trigger, event identity = 1f, reporting threshold = -70 dBm. The tester reconfigures the downlink
transmission power settings according to values in column T1 in Table 8.4.1.1-1. The UE shall


transmit a MEASUREMENT REPORT messages when it detects that the CPICH RSCP of cell 3 has
dropped below the threshold value specified in the previous MEASUREMENT CONTROL message.
Test verification:
To confirm that the UE continue to monitor intra-frequency measurement quantity of the cells listed in
System Information Block type 11 or 12 messages, after it has entered CELL_DCH state from idle
mode. When the intra-frequency measurement reporting criteria specified in System Information
Block type 11 or 12 messages have been met, it shall report the measurements using
MEASUREMENT REPORT messages. To confirm that the UE terminates and reporting monitoring
activities for the cells listed in "intra-frequency cell info list" IE in System Information Block type 11 or
12 messages, after it has received a MEASUREMENT CONTROL message that specifies the
measurement type to be intra-frequency measurement with the same measurement identity in
System Information Block Type 11 or 12 messages. To confirm that the UE reconfigures the
monitoring and reporting activities based on the last MEASUREMENT CONTROL message received.
Message flow:

UE NW
1 System Information Block type 11 The UE is idle mode and
camped onto cell 1. The
System Information Block
type 11 messages to be
transmitted are different
from the default settings
(see specific message
contents)
2 NW executes procedure P3 (clause
7.4.2.1.2) or P5 (clause 7.4.2.2.2)
7.4.2.3.2) or P9 (clause 7.4.2.4.2)
specified in TS 34.108
7.4.2.5.2) or P13 (clause 7.4.2.6.2)
specified in TS 34.108
6a MEASUREMENT REPORT Tester shall receive

consecutive
MEASUREMENT REPORT
messages
7 MEASUREMENT CONTROL A measurement with
measurement identity IE
set to 1 is assigned, with
the IE CHOICE reporting
criteria set to intra-
frequency measurement
reporting criteria. See
specific message content
for the rest of the message.



UE NW
9 Tester re-adjusts the
columns T1 in Table
8.4.1.1.
10 MEASUREMENT REPORT Tester verifies that UE
transmits 2
MEASUREMENT REPORT
messages triggered by the
cell 3 and containing report
the measured CPICH
RSCP value of cell 3.
10a A MEASUREMENT
CONTROL is sent to the
UE to modify the list of the
cells the UE shall monitor.
10b NW verifies that UE
transmits a
MEASUREMENT REPORT
message triggered by cell
2.
11 The tester re-adjusts the
columns "T2" in Table
8.4.1.1
12 MEASUREMENT CONTROL A measurement with
measurement identity IE
set to 1 is assigned, with
the IE CHOICE reporting
criteria set to intra-
reporting criteria. See
specific message content
for the rest of the message.
13 The tester re-adjusts the
8.4.1.1-3 and waits 5
seconds.
14 MEASUREMENT REPORT The tester verifies that UE
transmits a
MEASUREMENT REPORT
message to report
occurrence of event 1b.


Remarks:
After step 5 the UE shall start to transmit 2 MEASUREMENT REPORT messages at 64 seconds
interval. The measurement quantity "CPICH RSCP" of cell 2 shall be reported in these messages.
After step 7 the UE shall not transmit any MEASUREMENT REPORT messages within 64 seconds
after the NW has transmitted the MEASUREMENT CONTROL message in step 7.
After step 9 the UE shall transmit a MEASUREMENT REPORT message on the uplink DCCH, to
report that the CPICH RSCP value for cell 2 has dropped below the threshold stated in the
MEASUREMENT CONTROL message transmitted by the NW in step 7. This MEASUREMENT
REPORT message shall also contain IE Event results, indicating the triggering of event 1f by cell 3.
It shall also contain the measured CPICH RSCP value and cell synchronisation information for cell 3,
and the measured CPICH Ec/No and RSCP values for cell 1.
After step 10a, the UE shall transmit a MEASUREMENT REPORT message on the uplink DCCH to
report that the CPICH RSCP value for cell 2 has dropped below the threshold stated in the
MEASUREMENT CONTROL message transmitted by the NW in step 7. The MEASUREMENT
REPORT message shall contain the measured CPICH RSCP value and cell synchronisation
information for cell 2 and cell 3, as well as the measured CPICH Ec/No and RSCP for cell 1. The IE
Event results in this message shall indicate that cell 2 has triggered the event.
After step 13, the UE shall transmit a MEASURMEASUREMENT REPORT containing IE E vent
results, indicating the triggering of event 1b by cell 2. The MEASUREMENT REPORT message shall
not contain any measured results.
.


B_8.4.1.2 Measurement Control and Report: Inter-frequency measurement for transition from
idle mode to CELL_DCH state (FDD)
Test Purpose:
After entering CELL_DCH state from idle mode, the UE shall stop the monitoring the list of cells
assigned in the IE inter-frequency cell info IE in System Information Block 11 or 12 messages. In
CELL_DCH state, when the UE receives a MEASUREMENT CONTROL message requesting for inter-
frequency measurement type to be setup, it shall start inter-frequency measurement and the
associated reporting activities if DPCH compressed mode status info IE in the message
simultaneously activates at least one compressed mode pattern sequence. When the UE receives a
MEASUREMENT CONTROL message with Reporting cell status IE omitted, it shall not include Cell
measured results IE for any cells in MEASUREMENT REPORT messages sent on uplink DCCH.
Reference: 3GPP TS 25.331 clause 8.4.1.3, 8.4.1.8.2, 8.6.7.9
Pre-requisites:
Network: 2 cells Cell 1 and 4 are active.
UE: Registered idle mode on CS (state 2) or Registered idle mode on PS (state 3) in cell 1
as specified in clause 7.4 of TS 34.108, depending on the CN domain supported by the UE. If
the UE supports both CS and PS domains, the initial UE state shall be Registered idle mode
on CS/PS (state 7).
Test Procedure:
Table B_8.4.1.2-1 illustrates the downlink power to be applied for the 2 cells.
Table B_8.4.1.2-1
UTRA RF Ch. 1 Ch. 2
Channel
Number
CPICH DBm -60 -75
RSCP/Ec /3.84
MHz
The UE is initially at idle mode and has selected cell 1 for camping. The System Information Block
type 11 messages are modified with respect to the default settings to prevent reporting of Cell
synchronisation information, and also to include cell 4 into the "inter-frequency cells info list" IE.
The operator makes an outgoing call for one of the traffic classes supported by the UE. NW and UE
shall execute procedure P3 (for CS service) or P5 (for PS service). The RRC CONNECTION SETUP
message used in procedure P3 or P5 should doesnt contain IE DPCH compressed mode info",
activating the transmission pattern gap sequence with TGPSI=1. Next NW and UE shall execute
procedure P7 (for CS service) or P9 (for PS service). Then NW and UE shall execute procedure P11
(for CS service) or P13 (for PS service). The UE shall not transmit any MEASUREMENT REPORT
messages, which pertain to measurement readings for cells listed in the IE inter-frequency cell info
list in System Information Type 11 NW sends PHYSICAL CHANNEL RECONFIGURATION message
on the downlink DCCH, specifying that compressed mode sequence pattern with TGPSI=1 be
deactivated. The UE shall reply with PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message on the uplink DCCH. It shall stop compressed mode operations at the activation time stated
in PHYSICAL CHANNEL RECONFIGURATION message. After the activation time has elapsed,the
network sends MEASUREMENT CONTROL message on the downlink DCCH. In this message, the
network requests UE to perform inter-frequency measurement for cell 4. The DPCH compressed
status info IE in this message activates the transmission gap pattern sequence with TGPSI = 1. The
UE shall start inter-frequency measurement and reporting for cell 4s measuremnt quantity values. It


shall report this measurement result by transmitting MEASUREMENT REPORT messages on uplink
DCCH.
Test Verification:
To confirm that the UE stops monitoring the list of cells assigned in the IE inter-frequency cell info in
System Information Block type 11 messages, after it enters CELL_DCH state from idle mode. To
confirm that the UE starts to perform inter-frequency measurement and related reporting activities,
when it receives a MEASUREMENT CONTROL message with the DPCH compress mode status info
IE indicating that a stored compressed mode pattern sequence be simultaneously activated. To
confirm that the UE excludes the IE cell measured results for any cells in the MEASUREMENT
REPORT messages, after it receives a MEASUREMENT CONTROL message with Reporting cell
status IE omitted.
Message flow:

UE NW
1 System Information Block type 11 The UE is idle mode and
camped onto cell 1.System
Information Block Type 11
to be transmitted is
different from the default
settings (see specific
message contents)
2 The operator makes an
outgoing call.
7.4.2.1.2) or P5 (clause 7.4.2.2.2)
7.4.2.5.2) or P13 (clause 7.4.2.6.2)

6 Tester checks to see that

no MEASUREMENT
REPORT messages are
received
7 PHYSICAL CHANNEL Existing compressed mode
RECONFIGURATION sequence pattern is de-
activated in this message.
8 PHYSICAL CHANNEL UE shall remain in CELL_DCH

RECONFIGURATION COMPLETE state.
9 MEASUREMENT CONTROL Network requests UE to
start inter-frequency
measurement for cell 4
DPCH compressed mode
status info IE is set to
simultaneously activate
compressed mode pattern.


Remarks:
After step 5 the UE shall not transmit any MEASUREMENT REPORT messages pertaining to the
measurement of CPICH RSCP of cell 4.
After step 9 the UE shall transmit MEASUREMENT REPORT messages on uplink DCCH, reporting
cell 4s CPICH RSCP value at periodic time interval of 16 seconds in "inter-frequency measurement"
IE.
After step 9 the UE shall transmit only 1 MEASUREMENT REPORT message on the uplink DCCH. In
this message, IE inter-frequency cell measured results shall be absent.


E_8.4.1.5 Measurement Control and Report: Intra-frequency measurement for transition from
CELL_DCH to CELL_FACH state (FDD)
Test Purpose:
The purpose of this test is to confirm that the UE stops performing intra-frequency measurement
reporting specified in a MEASUREMENT CONTROL message, when it moves from CELL_DCH state
to CELL_FACH state. To confirm that the UE reads the System Information Block type 11 or 12
messages when it enters CELL_FACH state from CELL_DCH state, and starts to monitor the cells
listed in the IE "intra-frequency cell info list". To confirm that the UE performs measurements on uplink
RACH transmissions and appends the measured results in RACH messages, when it receives IE
"intra-frequency reporting quantity for RACH reporting" and IE "Maximum number of reported cells on
RACH" in the System Information Block type 11 or 12 messages. To confirm that the UE applies the
reporting criteria in IE "intra-frequency reporting criteria" in System Information Block Type 11 or 12
messages following a state transition from CELL_FACH to CELL_DCH, if no intra-frequency
measurements applicable to CELL_DCH are stored.
Reference: 3GPP TS 25.331, clause 8.4.1.6.1, 8.4.1.7.1
Pre-requisites:
Configuration : C
Network: 3 cells Cell 1 and cell 2 are active, while cell 3 is switched off..
UE: PS-DCCH+DTCH_DCH (state 6-10) in cell 1 as specified in clause 7.4 of TS 34.108.
Table 8.4.1.5-1

T0 T1 T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 1 Ch. 1
Channel
Number
CPICH Ec dBm/ -60 -60 -75 -85 -122 -70
3.84
MHz
Test Procedure:
The UE is initially in CELL_DCH state. The System Information Block type 11 message is modified
compared to the default message contents, in order to prevent the reporting of "Cell synchronisation
information". No measurement to be applied by the UE in CELL_DCH state is specified in any of the
System Information Block type 11 or 12 messages.
NW sends a MEASUREMENT CONTROL message to UE. In this message, the NW requests the
establishment of an intra-frequency measurement task for the measurement of cell 2's CPICH RSCP.
At the same time, reporting of CP ICH RSCP values of active set cells and monitored set cells are
requested with the reporting criteria set to "periodic reporting" and "reporting interval" set to 16
seconds. The UE shall start transmitting MEASUREMENT REPORT messages at 16 seconds interval
corresponding to the requested reporting event.
NW transmits PHYSICAL CHANNEL RECONFIGURATION *(Note1)message to move the UE to
CELL_FACH.After receiving this message, the UE shall reconfigure itself and reply with a PHYSICAL
CHANNEL RECONFIGURATION COMPLETE *(Note2) message on RACH. The tester monitors the
uplink channels to verify that no MEASUREMENT REPORT messages are received.


NW reconfigures itself according to the settings in columns marked "T1" in table 8.4.1.5-1. NW
transmits System Information Block type 11 or 12 messages in cell 1, which include cell 3 into the IE
"intra-frequency cell info list" and modifies SIB11 to indicate that SIB12 is now being broadcast. IEs
"Intra-frequency reporting quantity for RACH Reporting" and IE "Maximum number of Reported cells
on RACH" are also specified in the System Information Type 12 messages. Event type 1a reporting
criterion is specified for intra-frequency measurements. NW transmit SYSTEM INFORMATION
CHANGE INDICATION message to UE. NW waits until T305 has expired. The UE shall respond with
a CELL UPDATE message, which comprises IE "Measured results on RACH" to report the readings of
CPICH RSCP for cell 1 and cell 3. NW replies with CELL UPDATE CONFIRM message on the
downlink DCCH. This message does not change the physical resources nor allocate any new RNTI
identities. NW transmits PHYSICAL CHANNEL RECONFIGURATION *(Note1) message again, and
configures dedicated physical channel for both uplink and downlink directions. The UE shall send
PHYSICAL CHANNEL RECONFIGURATION COMPLETE*(Note2) message and return to
CELL_DCH state. NW listens to the uplink DCCH for MEASUREMENT REPORT messages.
NW shall receive the MEASUREMENT REPORT messages at 500 milliseconds interval.
The tester verifies that it includes CPICH RSCP values of the cells 1, 2 and 3 in IE "Cell measured
results" and the triggering of event '1a' on cell 3 in IE "Event results"
Test Verification:
Verify that after entering CELL_FACH state from CELL_DCH state, the UE shall stop intra-frequency
type measurement reporting assigned in a MEASUREMENT CONTROL message. After transition to
CELL_FACH state, the UE shall start to monitor cells listed in the IE "intra-frequency cell info" received
in System Information Block type 11 or 12. If no intra-frequency measurements applicable to
CELL_DCH are stored in the UE, and that the UE receives "intra frequency reporting criteria" IE in
System Information Block type 11 or 12 messages received whilst in CELL_FACH state, it shall apply
these reporting criteria after a subsequent return to CELL_DCH state. If the UE receives the IE "Intra-
frequency reporting quantity for RACH reporting" and the IE "Maximum number of reported cells on
RACH" in System Information Block Type 11 or 12 during a transition from CELL_DCH to
CELL_FACH, the UE shall append the measured results when transmitting uplink RACH messages.
Message Flow:

UE NW
1 Master Information Block UE is in PS-
System Information Block type 11 DCCH+DTCH_DCH (state
6-10) in cell 1. System
Information Block Type 11
to be broadcast does not
specify any no
measurement type to be
configured in the UE in
CELL_DCH.
5 MEASUREMENT CONTROL NW requests for
measurement of cell 2s
CPICH RSCP value and
reporting of CPICH RSCP
values of active cells and
monitored set cells.
6 MEASUREMENT REPORT UE shall send periodic
report at 16 seconds
interval.
7 PHYSICAL CHANNEL (Note1)
RECONFIGURATION* The NW moves the UE to
CELL_FACH state.



UE NW
RECONFIGURATION COMPLETE* UE shall move to
CELL_FACH state.
9 MASTER INFORMATION BLOCK NW reconfigures itself
SYSTEM INFORMATION BLOCK according to the settings
TYPE 11 or 12 stated in column "T1" of
table 8.4.1.5-1. SIB 11 is
modified to indicate that
SIB12 is now broadcast
and to add cell 2 as a
neighbour cell. SIB 11 or
12 indicates that cell 3 is
included in the IE "intra-
frequency cell info list". The
tester waits for 1 minute
and verifies that no
MEASUREMENT REPORT
messages are detected on
the uplink.
10 SYSTEM INFORMATION CHANGE NW waits until T305 has
INDICATION expired.
message with measured
results on RACH channels
for cell 1 and cell 3 present
in this message.
12 CELL UPDATE CONFIRM No changes in physical
resource allocation and
RNTI identities.
RECONFIGURATION* The tester configures
dedicated physical
channels.
RECONFIGURATION COMPLETE* UE shall transit to
CELL_DCH state.
15 MEASUREMENT REPORT Repeated at 500
milliseconds interval.
Remarks:
After step 5, the UE shall start to transmit MEASUREMENT REPORT messages at 16 seconds
interval. The message shall contain IE "measured result" to report cell 2's CPICH RSCP value.
After step 8, the UE shall not send any MEASUREMENT REPORT messages containing reporting
quantities requested in MEASUREMENT CONTROL messages in step 5.
After step 10, the UE shall perform a cell update procedure and transmit a CELL UPDATE message.
In this message, measured values CPICH RSCP for cell 1 and cell 3 shall be included in the IE
"measured results on RACH".
After step 15, the UE shall apply the intra-frequency measurement reporting criteria" received in
System Information Block type 11 or 12 messages of step 9. It shall send MEASUREMENT REPORT
messages at 500 miliseconds interval. In these messages, triggering of event '1a' shall be reported in
IE "Event results" with IE "Primary CPICH info" containing the primary scrambling code for cell 3.
The message shall contain IE "measured result" to report CPICH RSCP values of cell 1, 2 and 3.


Note1: In this test case, the TRANSPORT CHANNEL RECONFIGURATION or RADIO BEARER
RECONFIGURATION message can be used as well as the PHYSICAL CHANNEL
RECONFIGURATION meaasge.
Note2: The TRANSPORT CHANNEL RECONFIGURATION COMPLETE or RADIO BEARER

RECONFIGURATION COMPLETE message can be used as well as the PHYSICAL CHANNEL
RECONFIGURATION COMPLETE meaasge according to Note1.


E_8.4.1.6 Measurement Control and Report: Inter-frequency measurement for transition from
CELL_DCH to CELL_FACH state (FDD)
Test Purpose:
The purpose of this test is to confirm that UE ceases inter-frequency type measurement reporting
assigned in MEASUREMENT CONTROL message when moving from CELL_DCH state to
CELL_FACH. To confirm that the UE begins to monitor the cells listed in "inter-frequency cell info"
received in System Information Block type 11 or 12 messages, following a state transition from
CELL_DCH state to CELL_FACH state.
Reference : 3GPP TS 25.331, clause 8.4.1.6.2
Pre-requisites:
Configuration : B, C, D, E
Network: 2 cells Cell 1 and cell 2 are active.
UE: PS-DCCH+DTCH_DCH (state 6-10) in cell 1 as specified in clause 7.4 of TS 34.108..
Table 8.4.1.6-1
T0 T1 T0 T1
UTRA RF Ch. 1 Ch. 2
Channel
Number
CPICH Ec dBm/ -60 -75 -75 -60
3.84
MHz
Test Procedure:
The UE is initially in CELL_DCH state. The System Information Block type 11 message is modified
with respect to the default settings, so that no measurement tasks are required of the UE. NW
transmits PHYSICAL CHANNEL RECONFIGURATION message. In this message, IE "DPCH
compressed mode info" is present, which indicates that the UE shall apply the given parameters for
compressed mode operations. The UE shall return a PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message to acknowledge that compressed mode mechanism can be exercised.
NW sends a MEASUREMENT CONTROL message to the UE, including cell 4 into the IE "inter-
frequency cell info". The IE "CHOICE reporting criteria" in this message is set to "periodic reporting
criteria". NW waits for 8 seconds to allow the periodic timer to expire. The UE shall send a
MEASUREMENT REPORT message containing IE "inter-frequency cell measurement results" to
report cell 4'sRSCP value. NW transmits PHYSICAL CHANNEL RECONFIGURATION
*(Note1)message again and reconfigures common physical channels. The UE shall return a
PHYSICAL CHANNEL RECONFIGURATION COMPLETE *(Note2)message and then move to
CELL_FACH state.
Test Verification:
Verify that when transiting from CELL_DCH state to CELL_FACH state, the UE shall stop all
measurement reporting activities related to inter-frequency measurements assigned in a
MEASUREMENT CONTROL message. After a transition from CELL_DCH state to CELL_FACH state,
the UE shall begin to monitor cells listed in the IE "inter-frequency cell info" in the System Information
Block type 11 or 12 messages.


Message Flow:

UE NW
1 SYSTEM INFORMATION BLOCK UE is PS-
TYPE 11 DCCH+DTCH_DCH (state
Information Block type 11 is
modified with respect to the
default settings. All
measurement and reporting
activities are disabled in
this message.
6 PHYSICAL CHANNEL NW instructs UE to begin
RECONFIGURATION compressed mode
operation.
7 PHYSICAL CHANNEL UE shall remain in
RECONFIGURATION COMPLETE CELL_DCH state.
8 MEASUREMENT CONTROL NW indicates that the
CPICH RSCP of cell 4 shall
be monitored and reported.
NW waits for 8 seconds for
the reception of
MEASUREMENT REPORT
message.
9 MEASUREMENT REPORT UE shall transmit this
message to report cell 4's
CPICH RSCP value.
common physical channels.
RECONFIGURATION COMPLETE* UE shall moves to
CELL_FACH state.
Remarks:
After step 8 the UE shall transmit MEASUREMENT REPORT message to report cell 4's RSCP value
in the IE "inter-frequency cell measured results".


E_8.4.1.7 Measurement Control and Report: Intra-frequency measurement for transition from
CELL_FACH to CELL_DCH state (FDD)
Test Purpose:
The purposes of this test are:

To confirm that UE retrieves stored measurement control information for intra-frequency
measurement type with "measurement validity" assigned to "CELL_DCH", after it enters
CELL_DCH state from CELL_FACH state.
To confirm that the UE continues to monitor the neighbouring cells listed "intra-frequency cell info"
IE in the System Information Block type 11 or 12 messages, if no intra-frequency measurements
applicable to CELL_DCH are stored.
To confirm that the UE transmits MEASUREMENT REPORT messages if reporting criteria stated
in IE "intra-frequency measurement reporting criteria" in System Information Block type 11 or 12
messages are fulfilled.
To confirm that a MEASUREMENT CONTROL message received in CELL_DCH state overrides
the measurement and associated reporting contexts maintained in the UE by virtue of System
Information Block type 11 or 12 messages.
Reference : 3GPP TS 25.331, clause 8.4.1.7.1
Pre-requisites:
Configuration : C
UE: PS-DCCH+DTCH_FACH (state 6-11).
Table 8.4.1.7-1
T0 T1 T0 T1 T0 T1
Channel
Number
CPICH Ec dBm -60 -122 -70 -60 -75 -75
/3.8
4
MHz
Test Procedure:
The UE is brought to CELL_FACH state in cell 1. System Information Block type 12 message is
changed with respect to the default message contents, with cell 2 included in the IE "intra-frequency
cell info". Event 1e is selected in IE "Reporting information for state CELL_DCH", and "Intra-frequency
measurement quantity" is set to CPICH RSCP.
NW send a RADIO BEARER RECONFIGURATION *(Note1)message to UE, and configures
dedicated physical channels on both uplink and downlink directions. The UE shall move to CELL_DCH
state and then return RADIO BEARER RECONFIGURATION COMPLETE *(Note2) message. The UE
shall send MEASUREMENT REPORT messages containing IE "Measured results" to report cell 2's
CPICH RSCP value and IE "event results" to report triggering of event type "1e".


Test Verification:
Verify that after transiting from CELL_FACH state to CELL_DCH state, the UE shall retrieve each set
of measurement control information of measurement type "intra-frequency", if the measurement
control information has "measurement validity" IE set to "CELL_DCH". If the UE has performed a cell
reselection whilst out of CELL_DCH state and that the cell reselection has occurred after the storage
of measurement control information, the UE shall delete the stored intra-frequency measurement
information.
If the UE has no stored intra-frequency measurements applicable to CELL_DCH state, it shall
continue to monitor the list of cells in IE "intra-frequency cell info" stated in System Information Block
type 11 or 12 messages. It shall transmit MEASUREMENT REPORT messages when the reporting
criteria in IE "intra-frequency measurement reporting criteria" in System Information Block type 11 or
12 messages are fulfilled. When in CELL_DCH state, the UE shall override existing measurement and
reporting contexts obtained from System Information Block type 11 or 12 messages, if a
MEASUREMENT CONTROL message is received. The UE shall start to use the new measurement
and reporting parameters received in the MEASUREMENT CONTROL message.
Message Flow:

UE NW
1 System Information Block type 11 or 12 UE is initially in PS-
DCCH+DTCH_FACH (state
Information Block type 11
or 12 messages are
changed with respect to the
default contents according
to the descriptions in
"Specific Message
Contents" clause.
2 RADIO BEARER (Note1)
dedicated physical
channels.
3 RADIO BEARER RECONFIGURATION (Note2)
COMPLETE * UE shall move to
CELL_DCH state.
4 MEASUREMENT REPORT Reports cell 2's CPICH
RSCP measurement value.
Remarks:
After step 3 the UE shall report cell 2's CPICH RSCP value by transmitting MEASUREMENT
REPORT messages.
Note1: In this test case, the TRANSPORT CHANNEL RECONFIGURATION or PHYSICAL CHANNEL
RECONFIGURATION message can be used as well as the RADIO BEARER RECONFIGURATION
meaasge.
Note2: The TRANSPORT CHANNEL RECONFIGURATION COMPLETE or PHYSICAL CHANNEL

RECONFIGURATION COMPLETE message can be used as well as the RADIO BEARER


E_8.4.1.8 Measurement Control and Report: Inter-frequency measurement for transition from
CELL_FACH to CELL_DCH state (FDD)
Test Purpose:
The purpose of this test is to confirm that the UE stops monitoring the list of cells assigned in the IE
"inter-frequency cell info" in System Information Block type 11 or 12 when it transits from CELL_FACH
state to CELL_DCH state. To confirm that the UE resumes inter-frequency measurements and
reporting stored for which the measurement control information has IE "measurement validity"
assigned to the value "CELL_DCH", after it re-enters CELL_DCH state from CELL_FACH state. To
confirm that the UE resumes inter-frequency measurement and reporting activities after it has received
a MEASUREMENT CONTROL message specifying that a stored compressed mode pattern sequence
be re-activated.
Reference : 3GPP TS 25.331 clause 8.4.1.7.2, 8.4.1.3
Pre-requisites:
Configuration : C
Network: 3 cells Cells 1, cell 4 and cell 5 are active.
UE: CS-DCCH+DTCH_DCH (State 6-9) or PS-DCCH+DTCH_DCH (State 6-10) in cell 1 as
Table 8.4.1.8-1
Para-meter Unit Cell 1 Cell 4 Cell 5
Channel
Number
CPICH Ec dBm/3.84 -60 -75 -75
MHz
Test Procedure:
NW transmits MEASUREMENT CONTROL message to add cell 5 into the IE "inter-frequency cell
info". In the MEASUREMENT CONTROL message, the parameters of the IE "inter-frequency
measurement reporting criteria" are as follow: event-triggered with event identity ='2c', reporting
quantity = "CPICH RSCP", threshold for non-used frequency = '-85 dBm', hysteresis = '1.0dB', time to
trigger = '10 seconds', amount of reporting = '1' and reporting interval = '0'. In the same message, IE
"Measurement validity" is present and "UE state" is assigned the value 'CELL_DCH'. The tester
checks that no MEASUREMENT REPORT messages are detected on the uplink DCCH after it has
transmitted the MEASUREMENT CONTROL message.
NW sends a PHYSICAL CHANNEL RECONFIGURATION *(Note1) message on the downlink DCCH
and configures PRACH and S-CCPCH physical channels. The UE shall reconfigure itself to receive
and transmit using the new common physical channels assigned, and send PHYSICAL CHANNEL
RECONFIGURATION COMPLETE*(Note2) on the uplink DCCH. NW modifies the content of Master
Information Block and System Information Block type 11 or 12 messages, such that cell 4 is added in
the list of cells assigned in the IE "inter-frequency cell info". NW transmits SYSTEM INFORMATION
CHANGE INDICATION message to UE. Once again, NW verifies that the UE does not transmit
MEASUREMENT REPORT messages in the uplink direction.
NW sends PHYSICAL CHANNEL RECONFIGURATION *(Note1) message, and configures dedicated
physical. In this message, NW commands the UE to start applying compressed mode mechanism for
DPCH. The UE shall move to CELL_DCH state and then reply with PHYSICAL CHANNEL
RECONFIGURATION COMPLETE*(Note2) message. NW waits for 10 seconds. The UE shall
transmit 1 MEASUREMENT REPORT message, containing the selected frequency quality estimate (in
this case CPICH RSCP) of cell 5. The UE shall also report the triggering of event 2c in the IE "Event


results" of MEASUREMENT REPORT message. The tester verifies that this message does not
contain measured results for cell 4.
Test Verification:
Verify that when transiting from CELL_FACH state to CELL_DCH state, the UE shall stop monitoring
the list of cells assigned in the IE "inter-frequency cell info" in System Information Block type 11 or 12
messages. If the UE has stored measurement control information of type "inter-frequency" for which
the IE "measurement validity" is present and the IE "UE state for reporting" has been assigned to
"CELL_DCH", it shall resume the stored measurement reporting activities after it has re-entered
CELL_DCH state from CELL_FACH state. The UE shall activate or deactivate inter-frequency
measurements by decoding the "DPCH compressed mode status info" IE in MEASUREMENT
CONTROL messages.
Message Flow:

UE NW
CELL_DCH state of cell 1.
2 MEASUREMENT CONTROL NW specifies inter-
and reporting parameters
for cell 5, with
"measurement validity" IE
present and "UE state" set
to "CELL_DCH".
3 NW checks that no
MEASUREMENT REPORT
messages are detected on
the uplink DCCH.
RECONFIGURATION* NW configures PRACH and
S-CCPCH physical
resources.
CELL_FACH state.
6 Master Information Block NW modifies MIB and SIB
System Information Block type 11 or 12 11 or 12 in order to include
cell 4 into the list of cells in
IE "inter-frequency cell
info".
7 SYSTEM INFORMATION CHANGE After NW transmits this
INDICATION message, NW confirms that
there are no transmissions
of MEASUREMENT
REPORT message in the
uplink direction.
RECONFIGURATION* NW configures dedicated
physical channels with
compressed mode
parameters
CELL_DCH state.



UE NW
10 MEASUREMENT REPORT UE shall resume inter-
task for cell 5 and report
the measured CPICH
RSCP value for cell 5.
Remarks:
After step 2 the UE shall not send any MEASUREMENT REPORT messages on the uplink DCCH of
cell 1.
After step 9 the UE shall transmit a MEASUREMENT REPORT message, containing the IE
"measured results" reporting cell 5's CPICH RSCP value. The UE shall also report the triggering of
event 2c by including IE "Event results" in the MEASUREMENT REPORT message. The UE shall not
transmit any MEASUREMENT REPORT messages pertaining to cell 4's measurements.



E_8.4.1.14 Measurement Control and Report: Cell forbidden to affect reporting range (FDD)
Test Purpose:
The purpose of this test is to confirm that the UE reports the triggering of event 1A to the NW, if a
primary CPICH currently measured by the UE enters the reporting range. To confirm that the UE
ignores that a primary CPICH is forbidden to affect the reporting range when (a) the primary CPICH
concerned is included in active set and (b) all cells in the active set are defined as primary CPICHs
forbidden to affect the reporting range.
Reference : 3GPP TS 25.331 clause 14.1.2.1, clause 14.1.5.4
Pre-requisites:
Configuration : C
A network supporting event triggered measurement reporting.
UE: CS-DCCH+DTCH _DCH (State 6-9) or PS-DCCH+DTCH_DCH (State 6-10) in cell 1 as
Table 8.4.1.14-1
Para- Unit Cell 1 Cell 2 Cell 3

meter
T0 T1 T2 T0 T1 T2 T0 T1 T2
UTRA Ch. 1 Ch. 1 Ch. 1
RF
Channel
Number
CPICH dBm -60 -60 -85 -75 -70 -60 -70 -70 -85
Ec /3.8
4
MHz
Test Procedure:
NW sends a MEASUREMENT CONTROL message with cell 1, cell 2 and cell 3 listed in IE "intra-
frequency cell info list". In this message the IE "CHOICE reporting criteria" is set to "intra-frequency
measurement report criteria", with the IE "intra-frequency event identity" set to "1A". The IE "reporting
range" is set to 12 dB in the MEASUREMENT CONTROL message. The UE shall send a
MEASUREMENT REPORT on the uplink DCCH, which contains the IE "Event results" to report that
intra-frequency event 1A is triggered by cell 3.
NW executes the active set update procedure, requesting that cell 3 be added to the active set. The
UE shall respond with ACTIVE SET UPDATE COMPLETE message on the uplink DCCH and then
include cell 3 into its current active set. The tester configures according to the values in columns "T1"
shown above. The UE shall transmit a MEASUREMENT REPORT message on the uplink DCCH to
report the triggering of intra-frequency event 1A. In these messages, the IE "Events results" shall
indicate that intra-frequency event 1A is triggered by cell 2. Upon reception of MEASUREMENT
REPORT message, NW sends ACTIVE SET UPDATE message to request cell 2 to be added to the
active set. The UE shall respond with ACTIVE SET UPDATE COMPLETE message on the uplink
DCCH and then include cell 2 into its current active set.
NW sends a MEASUREMENT CONTROL message to command that all cells in the active set are
forbidden to update the reporting range for event 1A. The tester configures the cell according to the
values in columns "T2" shown above. The UE shall not transmit a MEASUREMENT REPORT
message on the uplink to report the triggering of intra-frequency reporting event 1A. The tester
reconfigures the cell according to the values in column "T0" shown in table 8.4.1.14-1 above. The UE


shall transmit MEASUREMENT REPORT message to report triggering intra-frequency event identity
1A, and also to report the CPICH RSCP readings for cell 1, cell 2 and cell 3 in IE "Measured results".
Test Verification:
Verify that when event 1A is ordered by the UTRAN in a MEASUREMENT CONTROL message, the
UE shall send a MEASUREMENT REPORT message when a primary CPICH measured has entered
the specified reporting range. The UTRAN can request that a certain primary CPICH be forbidden to
affect the reporting range used for event 1A measurement reporting. However, the UE shall ignore
such a request from the UTRAN if two conditions are fulfilled (a) the primary CPICH concerned is
included in the active set, and (b) all cells in the active set are defined as primary CPICHs forbidden to
affect the reporting range.
Message Flow:

UE NW
1 UE is initially in CELL_DCH
state in cell 1.
5 MEASUREMENT CONTROL Cell 1, cell 2 and cell 3 are
listed in IE "Intra-frequency
cell info list". The IE
"CHOICE reporting criteria" is
set to "Intra-frequency
measurement reporting
criteria" and IE "Intra-
frequency event identity" is
set to "1A", with IE "reporting
range" set to 12 dB.
6 MEASUREMENT REPORT UE shall report that cell 3 has
entered the reporting range
for intra-frequency reporting
event 1A.
7 ACTIVE SET UPDATE UE shall add cell 3 into the
active set
9 The tester configures the cell
according to the settings
stated in column "T1" of table
8.4.1.14-1.
event 1A.
10a ACTIVE SET UPDATE UE shall add cell 2 into the
active set
10b ACTIVE SET UPDATE COMPLETE
11 MEASUREMENT CONTROL NW forbids all cells in active
list to affect the reporting
range
8.4.1.14-1.



UE NW
13 The tester verifies that no
MEASUREMENT REPORT
messages are received in the
uplink direction
8.4.1.14-1.
event 1A.
Remarks:
After step 5, the UE shall send a MEASUREMENT REPORT message on the uplink DCCH. The
message shall contain the IE "Event results" to report that cell 3 has triggered intra-frequency event
1A.
After step 9, the UE shall transmit MEASUREMENT REPORT message on the uplink DCCH. The
message shall contain IE "Event results" to report tha cell 2 has triggered intra-frequency event 1A.
After step 12, the UE shall not send MEASUREMENT REPORT message on the uplink DCCH to
report the triggering of intra-frequency event identity 1A.
After step 14, the UE shall send a MEASUREMENT REPORT message on the uplink DCCH. The
message shall contain IE "Event results" to report that cell 3 has triggered intra-frequency event 1A.


B_9.1 TMSI reallocation
Test Purpose:
The purpose of this test is to verify the TMSI Reallocation procedure that assigns a new temporary
identity for the UE.
Pre-requisites:
Two cells A and B, belonging to different location areas a and b, default parameters.
UE has valid TMSI (= TMSI1), CKSN, CK, IK.
Test Procedure:
The UE is paged in cell B and the security mode is established. An explicit TMSI
reallocation procedure is performed. The RRC CONNECTION is released.
The UE is switched off and then its power supply is interrupted for 10 seconds. The power
supply is resumed and then the UE is switched on and allowed sufficient time to
guarantee that the UE is in service (listening to its paging sub channel).
The network then checks, by paging, whether the UE has stored the received TMSI.
The UE is made to select cell A. A normal location updating procedure is performed in cell
A. An explicit TMSI reallocation procedure is performed and then the location updating
procedure is accepted by the network. The network checks, by paging, whether the UE
has stored the allocated TMSI.
Test Verification:
Verify that the UE is able to receive and acknowledge a new TMSI by means of an explicit
TMSI reallocation procedure.
Verify that the UE has stored the TMSI in a non-volatile memory.


Message Flow:

UE NW
The following messages are sent and shall be received on cell B.
1 Mobile terminated See TS 34.108 clause 7.1.2
establishment of Radio "Initial UE identity" = TMSI1.
Resource Connection Establishment Cause: Terminating Conversation
Call.
2 PAGING RESPONSE "Mobile identity" =TMSI1
2a AUTHENTICATION
REQUEST
2b AUTHENTICATION
RESPONSE
3 SECURITY MODE
COMMAND
4 SECURITY MODE
COMPLETE
5 TMSI REALLOCATION "Mobile identity" = new TMSI (TMSI2) different from
COMMAND TMSI 1.
6 TMSI REALLOCATION
COMPLETE
7 RRC CONNECTION After the sending of this message, the NW waits for
RELEASE the disconnection of the main signalling link.
8 RRC CONNECTION
RELEASE COMPLETE
9 UE If possible, the UE is switched off.
9a UE The power supply is interrupted for 10 seconds.
10 UE The UE is switched on.
11 NW The NW waits an amount of time which is enough
to guarantee that the UE is in service (listening to
its paging subchannel).
establishment of Radio "Initial UE identity" = TMSI2.
Resource Connection Establishment Cause: Terminating Conversation
Call.
13 PAGING RESPONSE "Mobile identity" =TMSI2.
RELEASE the disconnection of the main signalling link. The
following messages are sent and shall be received
on cell A
15 RRC CONNECTION
RELEASE COMPLETE
17 RRC CONNECTION Establishment cause: Registration.
REQUEST
COMPLETE
20 LOCA TION UPDATING location updating type = normal, "ciphering key
REQUEST sequence number" = CKSN, LAI = b, "mobile
identity" = TMSI2.
20a AUTHENTICATION
REQUEST
20b AUTHENTICATION
RESPONSE
20c SECURITY MODE
COMMAND


20d SECURITY MODE

COMPLETE
21 TMSI REALLOCATION TMSI = TMSI3.
COMMAND
22 TMSI REALLOCATION
COMPLETE
23 LOCATION UPDATING This message does not contain the optional Mobile
ACCEPT Identity field.
NW waits an amount of time which is enough to
guarantee that the UE is "idle updated" on cell A.
25 RRC CONNECTION
RELEASE COMPLETE
establishment of Radio "Initial UE identity" IE contains the new TMSI
Resource Connection (= TMSI3).
"Establishment cause": Terminating Conversational
Call.
27 PAGING RESPONSE "Mobile identity" IE contains the new TMSI
(= TMSI3).
29 RRC CONNECTION
RELEASE COMPLETE
Remarks:
At step 5 the UE shall receive and acknowledge a new TMSI (TMSI2) and has stored that in the
USIM, and the UE is switched off and on after step 9 and 10.
At step 13 the UE shall transmit a new TMSI2 and includes it in the PAGING RESPONSE
message.
At step 27 the UE shall answer paging with this TMSI3 and includes it in the PAGING RESPONSE
message.


B_9.2.1 Authentication accepted
Test Purpose:
The purpose of this procedure is to verify the user identity.

Reference: 3GPPTS 24.008 section 4.3.2.2 & 4.3.2.4.
Pre-requisites:
Configuration: A, B, C, D, E.
1 cell with default parameters.
UE has valid TMSI, CKSN (CKSN1), CK, IK
Test Procedure:
The UE is paged. After the UE has sent a PAGING RESPONSE message to the network,
the network initiates an authentication procedure and checks the value RES sent by the
UE in the AUTHENTICATION RESPONSE message. The RRC CONNECTION is
released.
The UE is paged and the network checks the value of the ciphering key sequence number
sent by the UE in the PAGING RESPONSE message.
Test Verification:
To check that a UE correctly responds to an AUTHENTICATION REQUEST message by

sending an AUTHENTICATION RESPONSE message with the RES information field set
to the same value as the one produced by the authentication algorithm in the network.
To check that a UE indicates in a PAGING RESPONSE message the ciphering key
sequence number which was allocated to it through the authentication procedure.
Message Flow:
UE NW
establishment of Radio Establishment Cause: Terminating Conversational
Resource Connection Call.
2 PAGING RESPONSE CKSN = CKSN1
3 AUTHENTICATION REQUEST The NW initiates authentication with CKSN2
different from CKSN1.
4 AUTHENTICATION "Auth. parameter RES" IE shall be bit exact with the
RESPONSE value as produced by the authentication algorithm.
5 Tester releases the call
8 PAGING RESPONSE "Ciphering key sequence number" shall be the
same as the value that was sent in the last
AUTHENTICATION REQUEST message
(= CKSN2).
9 Tester releases the call
Remarks:
At step 4 the UE shall send an AUTHENTICATION RESPONSE message with the RES
information field set to the same value as the XRES calculated by the network.
At step 7 the UE shall indicate in a PAGING RESPONSE message the ciphering key
sequence number that was allocated to it through the authentication procedure.


E_9.2.2 Authentication rejected by the network
Test Purposes:
The purpose of this test is to verify the UEs behaviour upon receiving Authentication rejected
message by the network.
Reference: 3GPPTS 24.008 section 4.3.2.5.
Pre-requisites:
Configuration B, C, D, E, F.
Two cells: A and B, belonging to different location areas a and b;
IMSI attach/detach is allowed in both cells;
The T3212 time-out value is 1/10 hour in both cells.
The UE has valid TMSI, CKSN (CKSN2) , CK and IK. It is "idle updated" on cell B.
Test Procedure:
The network rejects an authentication. The RRC CONNECTION is released.

The network checks that the UE has entered the state MM IDLE substate NO IMSI, i.e. does
not perform normal location updating, does not perform periodic updating, does not respond to
paging, rejects any requests from CM entities except emergency calls and does not perform
IMSI detach if USIM detachment is performed, switch off is performed, or the power is
removed, depending on the UE .
Test Verification:
To verify that, after reception of an AUTHENTICATION REJECT message the UE, if it

supports speech, accepts a request for an emergency call by sending a RRC CONNECTION
REQUEST message with the establishment cause set to "emergency call" and includes an
IMEI as mobile identity in the CM SERVICE REQUEST message.
To verify that, after reception of an AUTHENTICATION REJECT message and after having
been deactivated and reactivated, the UE performs location updating using its IMSI as mobile
identity and indicates deleted LAI and CKSN.


Message Flow:

UE NW
The following messages are sent and shall be received on cell B
1 Mobile terminated See TS 34.108 section 7.1.2
Resource Connection Call..
2 PAGING RESPONSE "Ciphering key sequence number" shall be the
same as the value that was sent in the last
AUTHENTICATION REQUEST message
(= CKSN2).
4 AUTHENTICATION
RESPONSE
5 AUTHENTICATION REJECT
7 RRC CONNECTION
RELEASE COMPLETE
13 UE If the UE supports speech, an emergency call is
attempted
14 RRC CONNECTION "Establishment cause": Emergency call.
REQUEST
COMPLETE
17 CM SERVICE REQUEST "CM service type": Emergency call establishment.
"Mobile identity": type of identity is set to IMEI.
19 EMERGENCY SETUP
The following messages are sent and shall be received on cell A.
29 UE Depending on what has been performed in step 26
the UE is brought back to operation.
30 RRC CONNECTION "Establishment cause": Registration.
REQUEST
COMPLETE
33 LOCATION UPDATING "location updating type" = normal, "CKSN" = no key
REQUEST available, "Mobile Identity" = IMSI, "LAI" = deleted
LAI (the MCC and MNC hold the previous values,
the LAC is coded FFFE).
34 AUTHENTICATION REQUEST "CKSN" = CKSN1.
35 AUTHENTICATION
RESPONSE
36 LOCATION UPDATING "Mobile Identity" = TMSI.
ACCEPT
COMPLETE
39 RRC CONNECTION
RELEASE COMPLETE


Remarks:
At step 14 the UE shall send a RRC CONNECTION REQUEST message with the
establishment cause set to "emergency call"; and at step 17 the UE shall send a CM
SERVICE REQUEST message with the "CM service type" set to "Emergency call
establishment".
At step 33 the UE shall perform location updating using its IMSI as mobile identity and
indicates deleted LAI and CKSN.


E_9.2.3 Authentication rejected by the UE (MAC code failure)
Test Purposes:
The purpose of this test is to verify that following a UMTS authentication challenge, the UE may reject
the core network, on the grounds of an incorrect AUTN parameter (see TS 33.102). This test case
also verifies the network functionality in response to authentication failure sent by the UE.
Reference: 3GPP TS 24.008 sections 4.3.2.5.1 and 4.3.2.6 (c).
Pre-requisites:
1 cell, default parameters.
The UE has valid TMSI, CKSN (CKSN1), CK, IK. It is "idle updated" on the cell.
Test Procedure:
The UE rejects an authentication.

The AUTHENTICATION FAILURE is sent by UE.
Upon receipt of the AUTHENTICATION FAILURE message.
The network initiates identification procedure.
The UE responded to the network by sending IDENTITY RESPONSE message.
The network sends AUTHENTICATION REQUEST message with correct AUTN parameter.
Test Verification:
To verify that a UE shall correctly respond to an AUTHENTICATION REQUEST message by

sending an AUTHENTICATION FAILURE message with the reject cause 'MAC failure'. A UE
shall correctly respond to an AUTHENTICATION REQUEST message with correct AUTN
parameter by sending AUTHENTICATION RESPONSE message after identification
procedure.
To verify that upon reception of an IDENTITY REQUEST message the UE identifies itself by
sending an IDENTITY RESPONSE message including the IMSI to the network.
To verify that upon receiving the second AUTHENTICATION REQUEST message from the
network, the UE shall stop the timer T3214, if running, and then process the challenge
information as normal. To verify that upon successfully validating the network (an
AUTHENTICATION REQUEST that contains a valid MAC is received), the UE sends the
AUTHENTICATION RESPONSE message to the network.


Message Flow:

UE NW
1 Mobile terminated See TS 34.108 section 7.1.2
3 AUTHENTICATION REQUEST with the AUTN parameter having an invalid MAC
code
4 AUTHENTICATION FAILURE with reject cause "MAC failure"
5 IDENTITY REQUEST
6 IDENTITY RESPONSE(IMSI)
7 AUTHENTICATION REQUEST with the AUTN parameter having a correct MAC
code
8 AUTHENTICATION "Auth.parameter RES" IE shall be bit exact with the
9 RRC CONNECTION
RELEASE
10 RRC CONNECTION
RELEASE COMPLETE
Remarks:
At step 4 the UE shall send AUTHENTICATION FAILURE message with reject cause set to
"MAC failure".
At step 6 the UE shall send an IDENTITY RESPONSE message including the IMSI.
At step 8 the UE shall send an AUTHENTICATION RESPONSE message.


E_9.2.4 Authentication reject by the UE (SQN failure)
Test Purpose:
The purpose of this test is to verify that the UE is able to reject authentication by sending an
AUTHENTICATION FAILURE message to the network, with the reject cause 'Synch failure' and a re-
synchronisation token AUTS provided by the USIM if the UE considers the SQN (supplied by the core
network in the AUTN parameter) to be out of range.
Reference: 3GPP TS 24.008 section 4.3.2.5.1, 4.3.2.6 (d)
Pre-requisites:
UE has valid TMSI, CKSN (CKSN1), CK, IK. It is "idle updated" on the cell.
Test Procedure:
The NW sends an AUTHENTICATION REQUEST having an invalid SQN code (i.e. uses
the predefined AMFRESYNCH value to trigger the SQN re-synchronisation procedure, see
TS 34.108 clause 8.1.2.2) to the UE. The NW verifies that the UE rejects the
authentication.
The NW sends a second AUTHENTICATION REQUEST with a valid SQN code (i.e. uses
an AMF value different from AMFRESYNCH value, see TS 34.108 clause 8.1.2.2). The NW
checks that the UE accepts the authentication request.
Test Verification:
To check that a UE shall correctly respond to an AUTHENTICATION REQUEST
message, with an SQN failure in the AUTN parameter, by sending an AUTHENTICATION
FAILURE message with the reject cause 'Synch failure' .
To check that upon successfully validating the network (a second AUTHENTICATION

REQUEST is received which contains a valid SQN) while T3216 is running, the UE shall
send the AUTHENTICATION RESPONSE message to the network.


Message Flow:

UE NW
Resource Connection
Call.
3 AUTHENTICATION REQUEST with the AMF information field set to AMFRESYNCH
value to trigger SQN re-synchronisation procedure in
test USIM, see TS 34.108 clause 8.1.2.2.
4 AUTHENTICATION FAILURE including the AUTS parameter and with the reject
cause set to 'Synch failure'
5 AUTHENTICATION REQUEST with the AMF information field set to value different
from AMFRESYNCH value to cause test USIM to treat
SQN value as valid, see TS 34.108 clause 8.1.2.2.
6 AUTHENTICATION "Auth. parameter RES" IE shall be bit exact with the
COMPLETE
Remarks:
None.


B_9.3.1.4.1 General Identification Test 1
Test Purpose:
The purpose of this procedure is to check that the UE gives its identity as requested by the network.
Pre-requisites:
1 cell with default values.
UE has a valid TMSI. It is "idle updated" on the cell.
Test Procedure:
The network requests identity information from the UE:
IMSI in non-security mode.
Test Verification:
To verify that the UE sends identity information as requested by the system in the following cases:
IMSI is requested in non-security mode, IMEI is requested in security mode
Message Flow:

UE NW
2 PAGING RESPONSE
3 IDENTITY REQUEST "Identity type" IE is IMSI.
4 IDENTITY RESPONSE "Mobile identity" IE specifies the IMSI of the UE.
7 SECURITY MODE COMMAND The NW starts deciphering.
8 SECURITY MODE The NW starts enciphering.
COMPLETE
9 IDENTITY REQUEST "Identity type" IE is IMEI.
10 IDENTITY RESPONSE "Mobile identity" IE specifies the IMEI stored in the
UE.
12 RRC CONNECTION
RELEASE COMPLETE
Remarks:
At step 8 the UE shall send its IMEI as stored in the UE.


E_9.3.2 Handling of IMSI shorter than the maximum length
Test Purposes:
The purpose of this test is to verify that UE shall be capable of handling an IMSI that is not of the
maximum length.
Pre-requisites:
1 cell, default values;
IMSI attach/detach bit set to "1".
The UE has no valid TMSI and is "idle updated";
The IMSI has the value 001011234.
Test Procedure:
The UE is paged with its IMSI. The UE shall answer to paging and include the correct IMSI in
the PAGING RESPONSE message.
During call establishment, the network asks for the IMSI of the UE. The UE shall answer by an
IDENTITY RESPONSE message including the correct IMSI.
During the active phase of the call, the network modifies the scrambling code of DL DPCH.
The UE performs call re-establishment.
The UE shall include the correct IMSI in the CM RE-ESTABLISHMENT message.
A TMSI REALLOCATION COMMAND including a TMSI is sent to the UE. The UE

acknowledges this message.
The call is release.
The UE is paged with its TMSI. The UE shall answer to paging and includes its TMSI in the
PAGING RESPONSE message.
During call establishment, the network sends a TMSI REALLOCATION COMMAND including
the IMSI to the UE. The UE shall acknowledge this message.
The UE shall erase its TMSI. The call is released.
The UE is switched off or has its power source removed.
The UE performs IMSI detach. The UE shall include the correct IMSI in the IMSI DETACH
INDICATION message.
The UE is switched on or powered on.
The UE performs IMSI attach. The UE shall include the correct IMSI in the LOCATION
UPDATING REQUEST message.
A TMSI is allocated to the UE.
The LAC of the cell is changed.
The UE performs location updating.
The network includes the IMSI in the LOCATION UPDATING ACCEPT message.


A mobile originated CM connection is attempted.
The UE shall include the correct IMSI in the CM SERVICE REQUEST message.
Test Verification:
To verify that the UE behaves correctly when activated with an IMSI of length less than the
maximum length.
In this condition, the UE shall:
Perform location updating;

Answer to paging with IMSI;
Give the correct IMSI when asked by an IDENTITY REQUEST;
Attempt CM connection establishment when requested to;
Attempt call re-establishment when needed;
Attempt IMSI detach when needed;
Erase its TMSI when the IMSI is sent by the network in a LOCATION UPDATING
ACCEPT or a TMSI REALLOCATION COMMAND message.
Message Flow:

UE NW
1 Mobile terminated See TS 34.108 7.1.2
establishment of Radio "Initial UE identity" IE contains IMSI of UE.
Resource Connection Establishment cause: Terminating Conversational
Call.
2 PAGING RESPONSE "mobile identity" contains the IMSI of the UE.
3 IDENTITY REQUEST "identity type" IE is IMSI.
4 IDENTITY RESPONSE "mobile identity" IE contains the IMSI of the UE.
5 The call is established using the sequence of the
generic terminating call set-up procedure.
6 NW The NW modifies the scrambling code of DL DPCH
for generating lower layer failure.
6a CELL UPDATE CCCH.
6b RRC CONNECTION CCCH.
RELEASE
6c The NW re-modifies the scrambling code of DL
DPCH to the original one.
Cell update procedure for radio link failure is
performed
COMPLETE
10 CM REESTABLISHMENT "mobile identity" IE contains IMSI of the UE.
REQUEST
10a AUTHENTICATION REQUEST
10b AUTHENTICATION
RESPONSE
10c SECURITY MODE COMMAND
10d SECURITY MODE
COMPLETE
11 TMSI REALLOCATION "mobile identity" contains a TMSI.
COMMAND


UE NW
COMPLETE
13 RRC CONNECTION After sending this message, the NW waits for the
RELEASE disconnection of the main signalling link.
14 RRC CONNECTION
RELEASE
COMPLETE
15 Mobile terminated See TS 34.108 7.1.2
establishment of Radio "Initial UE identity" IE contains TMSI of UE.
Resource Connection Establishment cause: Terminating Conversational
Call.
16 PAGING RESPONSE "mobile identity" contains the TMSI of the UE.
18 AUTHENTICATION
RESPONSE
18a SECURITY MODE COMMAND
18b SECURITY MODE
COMPLETE
19 TMSI REALLOCATION "mobile identity" contains a IMSI of UE.
COMMAND
COMPLETE
21 RRC CONNECTION
RELEASE
22 RRC CONNECTION
RELEASE
COMPLETE
23 UE If possible the UE is switched off, otherwise the UE
has its power source removed.
24 RRC CONNECTION If the UE was switched off it performs IMSI detach.
REQUEST "Establishment cause": Detach
COMPLETE
27 IMSI DETACH INDICATION "mobile identity" contains IMSI of UE.
28 RRC CONNECTION
RELEASE
29 RRC CONNECTION
RELEASE
COMPLETE
30 UE The UE is switched on or has power restored.
31 RRC CONNECTION
REQUEST
COMPLETE
34 LOCATION UPDATING "mobile identity" contains IMSI of UE.
REQUEST
35 LOCATION UPDATING "mobile identity" contains a TMSI.
ACCEPT
COMPLETE
37 RRC CONNECTION
RELEASE
38 RRC CONNECTION
RELEASE
COMPLETE



UE NW
39 NW The NW changes the LAC of the cell.
40 RRC CONNECTION Shall be sent within 35s of the LAC being changed.
REQUEST
COMPLETE
43 LOCATION UPDATING "mobile identity" contains TMSI of the UE.
REQUEST
44 LOCATION UPDATING "mobile identity" contains IMSI of the UE.
ACCEPT
45 RRC CONNECTION
RELEASE
46 RRC CONNECTION
RELEASE
COMPLETE
47 UE a mobile originated CM connection is attempted.
48 RRC CONNECTION
REQUEST
COMPLETE
51 CM SERVICE REQUEST "mobile identity" contains IMSI of the UE.
52 RRC CONNECTION
RELEASE
53 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
At step 34 the UE shall performs location updating.

At step 2 the UE shall answer to paging with IMSI.
At step 4 the UE shall answer the correct IMSI to the network by an IDENTITY RESPONSE
message.
At step 51 the UE shall attempt CM connection establishment and include the correct IMSI in
the CM SERVICE REQUEST message.
At step 19 the IMSI is sent by the network in a TMSI REALLOCATION COMMAND message,
at step 27 the UE shall attempt IMSI detach.
At step 44 the IMSI is sent by the network in a LOCATION UPDATING ACCEPT message, at
step 51 the UE shall attempt IMSI detach.


B_9.4.1 Location updating / accepted
Test Purpose:
This procedure is used to register the UE in the network.
Pre-requisites:
To cells, A and B, belonging to different location areas with location area identification a
and b of the same PLMN
IMSI attach/detach is allowed in both cells.
TheT3212 time-out value is 1/10 hour in both cells.
UE has a valid TMSI (=TMSI1) and CKSN (=CKSN1). It is "idle updated" on cell A.
Test Procedure:
The UE is made to select cell B. A normal location updating with TMSI reallocation is performed in
cell B. The RRC CONNECTION is released.
The network checks, by paging, that the UE has stored the newly allocated TMSI. The RRC
CONNECTION is released.
The UE is made to select cell A. A normal location updating is performed in cell A. The
LOCATION UPDATING ACCEPT message contains neither IMSI nor TMSI.
The network checks, by paging, that the UE has kept the old TMSI. The RRC CONNECTION is
released.
The UE is made to select cell B. A normal location updating is performed in cell B. The
LOCATION UPDATING ACCEPT message contains an IMSI.
Note: Depending on individual network s implementation, the LOCATION UPDATING ACCEPT

message can contain either TMSI or IMSI.
The network checks, by paging, that the UE has deleted its TMSI and responds to paging with IMSI.
Test Verification:
Verify the behaviour of the UE if the network accepts the location updating of the UE.
Verify the following network responses:
TSI is allocated.
Location updating accept contains neither TMSI nor IMSI.
Location updating accept contains IMSI.


Message Flow:

UE NW
REQUEST
COMPLETE
5 LOCATION UPDATING "location updating type" = normal, "CKSN" =
REQUEST CKSN1, "location area identification" = a, "mobile
station class mark 1" and "mobile identity" = TMSI1.
5a SECURITY MODE COMMAND
5b SECURITY MODE
COMPLETE
6 LOCATION UPDATING "Mobile identity" = new TMSI (=TMSI2), LAI = b.
ACCEPT
7 TMSI REALLOCATION
COMPLETE
guarantee that the UE is in service.
9 RRC CONNECTION
RELEASE
COMPLETE
establishment of Radio "Initial UE identity" IE contains the new TMSI (=
Resource Connection TMSI2).
Establishment Cause: Terminating Conversational
Call.
11 PAGING RESPONSE "Mobile identity" IE contains the new TMSI (=
TMSI2).
13 RRC CONNECTION
RELEASE
COMPLETE
15 RRC CONNECTION "Establishment cause": Registration
REQUEST
COMPLETE
REQUEST CKSN1, "location area identification" = b, "mobile
station classmark 1" and "mobile identity" = TMSI2.
19 LOCATION UPDATING "Mobile identity" IE not included.
ACCEPT
21 RRC CONNECTION
RELEASE
COMPLETE



UE NW
establishment of Radio "Initial UE identity" IE contains the TMSI (= TMSI2).
Resource Connection Establishment Cause: Terminating Conversational
Call.
23 PAGING RESPONSE "Mobile identity" IE contains the TMSI (=TMSI2).
25 RRC CONNECTION
RELEASE
COMPLETE
REQUEST
COMPLETE
REQUEST CKSN1, "location area identification" = a, "mobile
station classmark 1" and "mobile identity" = TMSI2.
31 LOCATION UPDATING The contain of "Mobile identity" could be IMSI or
ACCEPT TMSI depending on the individual network s
implementation.
33 RRC CONNECTION
RELEASE
COMPLETE
34 PAGING TYPE 1 "UE identity" IE contains the old TMSI (= TMSI2).
Paging Cause: Terminating Conversational Call.
35 UE The UE shall ignore this message. This is checked
during 5 seconds.
establishment of Radio "Initial UE identity" IE contains the IMSI.
Resource Connection Establishment Cause: Terminating Conversational
Call.
37 PAGING RESPONSE "Mobile identity" IE contains the IMSI.
39 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
At step 7 the UE shall acknowledge the reception of the new TMSI (TMSI2).
At step 11 the UE shall answer to paging with this TMSI (TMSI2).
At step 23 the UE shall answer to paging with the last allocated TMSI (TMSI2).
At step 35 the UE shall not answer paging with the last allocated TMSI, but at step 37 the UE
shall still answer paging with IMSI.


E_9.4.2.1 Location updating / rejected / IMSI invalid
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network rejects the Location
Update with the cause "IMSI unknown in HLR", "Illegal MS" or "Illegal ME".
Pre-requisites:
Configuration: C, D, E, F.
Two cells: A and B, belonging to different location areas of the same PLMN;
IMSI attach/detach is allowed in both cells;
The T3212 time-out value is 1/10 hour in both cells.
The UE has valid TMSI, CKSN and CK, IK. It is "idle updated" on cell A.
Test Procedure:
The network rejects a normal location updating with the cause value "IMSI unknown in HLR".
The RRC CONNECTION is released.
The network checks that the UE has entered the state MM IDLE and the substate NO IMSI,
i.e. does not perform normal location updating when a new cell of the same or another PLMN
is entered, does not perform periodic updating, does not respond to paging, rejects any
requests from CM entities except emergency calls and does not perform IMSI detach if it is
switched off or has its power source removed.
The test is repeated with cause value "Illegal MS" and with cause value "Illegal ME".
Test Verification:
To verify the behaviour of the UE if the network rejects the location updating of the UE with the
cause "IMSI unknown in HLR", "illegal MS" or "Illegal ME".


Message Flow:
The sequence is executed for execution counter k = 1, 2, 3.

UE NW
The following messages are sent and shall be
received on cell B.
REQUEST
COMPLETE
5 LOCATION UPDATING
REQUEST
6 LOCATION UPDATING "Reject cause" IE is "IMSI unknown in HLR" for k =
REJECT 1, "Illegal MS" for k = 2, "Illegal ME" for k = 3.
8 RRC CONNECTION
RELEASE
COMPLETE
9 NW The RF levels are then changed again to make the
UE reselect the cell A.
10 UE The UE performs cell reselection according to
procedure as specified in (this however is not
checked until step 23). The UE shall not initiate an
RRC connection establishment on cell A or on cell
B.
11 NW The NW waits at least 7 minutes for a possible
periodic updating.
12 UE The UE shall not initiate an RRC connection
establishment on cell A or on cell B.
13 PAGING TYPE 1 The UE is paged in cell A. "UE identity" IE contains
IMSI.
14 UE The UE shall ignore this message. This is verified
during 3 s.
15 PAGING TYPE 1 The UE is paged in cell A. "UE identity" IE contains
TMSI.
16 UE The UE shall ignore this message. This is verified
during 3 s.
17 UE A MO CM connection is attempted.
establishment on cell A or on cell B. This is
checked during 3 s.
19 UE If the UE supports speech , it is made to perform an
emergency call.
REQUEST
This message is sent in cell A.
COMPLETE
"Mobile identity": type of identity is set to IMEI.



UE NW
25 EMERGENCY SETUP
26 RELEASE COMPLETE "Cause" = unassigned number.
28 RRC CONNECTION
RELEASE
COMPLETE
29 UE If possible USIM detachment is performed.
Otherwise if possible switch off is performed.
Otherwise the power is removed.
checked during 3 s.
REQUEST
COMPLETE
REQUEST available, "mobile station classmark 1" as given by
the ICS, "Mobile Identity" = IMSI, "LAI" = deleted
37 AUTHENTICATION
RESPONSE
ACCEPT
COMPLETE
41 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
At step 10 the UE shall not perform normal location updating.

At step 12 the UE shall not perform periodic location updating.
At step 14 the UE shall not respond to paging with IMSI.
At step 16 the UE shall not respond to paging with TMSI.
At step 18 the UE shall reject a MO CM connection.
At step 30 the UE shall not initiate an RRC connection establishment on cell A or on cell B.
At step 20 the UE shall accept a request for an emergency call with the establishment cause
set to "Emergency call".
At step 35 the UE shall send a LOCATION UPDATING REQUEST message with the Mobile
Identity IE set to its IMSI, CKSN IE set to "no key is available" and the LAI "deleted LAI".


E_9.4.3.5 Location updating / abnormal cases / Failure due to non-integrity protection
Test Purposes:
The purpose of this test is to verify that the UE does not process any layer 3 message if integrity
protection is not activated during the location update procedure.
Reference: TS 24.008 clauses 4.1.1.1.1.
Pre-requisites:
Configurations: B, C, D, E, F.
Two cells: A and B, belonging to different location areas a and b.
UE has a valid TMSI. It is "idle updated" on cell A
Test Procedure:
The location updating procedure is started. Upon reception of LOCATION UPDATING

REQUEST message from the UE, the NW responds to LOCATION UPDATING ACCEPT
message without the integrity protection.
The UE shall ignore this message and restart the location updating procedure at expiry of timer
T3211. This time the NW starts the authentication procedure and initiates the integrity
protection.
After receiving LOCATION UPDATING ACCEPT message, the UE shall respond to TMSI
REALLOCATION COMPLETE message.
Test Verification:
To verify that the UE ignores NAS signalling messages when the security mode procedure is
activated without the integrity protection.


Message Flow:

UE NW
1 NW Set the cell type of cell B to the Serving cell.
Set the cell type of cell A to the non-suitable cell.
(see note)
2 NW The NW verifies that the IE "Establishment cause" in the
received RRC CONNECTION REQUEST message is set
to Registration.
3 LOCATION UPDATING
REQUEST
5 AUTHENTICATION RESPONSE
6 NW The NW starts the security mode procedure without the
integrity protection. The content of integrity protection
mode info IE in SECURITY MODE COMMAND message
is specified below.
7 LOCATION UPDATING ACCEPT
8 UE The UE ignores LOCATION UPDATING ACCEPT
message.
9 NW The NW waits T3210 expiry.
10 UE The UE aborts the RR connection.
11 NW The NW releases the RRC connection.
to Registration.
14 LOCATION UPDATING
REQUEST
16 AUTHENTICATION RESPONSE
17 NW The NW starts the security mode procedure with the
integrity protection. The content of integrity protection
mode info IE in SECURITY MODE COMMAND message
is specified below.
18 LOCATION UPDATING ACCEPT
COMPLETE
NOTE: The definitions for "Serving cell" and "non-suitable cell" are specified in TS 34.108 clause 6.1 "Reference
Radio Conditions for signalling test cases only".
Remarks:
At step 8 the UE shall ignore the first LOCATION UPDATING ACCEPT message.
At step 14 the UE shall send LOCATION UPDATING REQUEST message after expiry of timer
T3211.
At step 16 the UE shall respond to TMSI REALLOCATION COMPLITE message after the UE
receives the second LOCATION UPDATING ACCEPT message.


E_9.4.4 Location updating / release / expiry of T3240
Test Purposes:
The purpose of this test is to verify that the UE shall abort the RRC connection at the expiry of timer
T3240 after having received a LOCATION UPDATING ACCEPT message.
Reference: 3GPP TS 24.008 sections 4.4.4.8 and 11.2.
Pre-requisites:
Configurations: D, E, F.
Two cells: A and B, belonging to different location areas a and b.
The UE has a valid TMSI. It is "idle updated" on cell A.
Test Procedure:
A normal location updating procedure is performed.

The RRC-connection is not released by the network within the timer T3240.
It is checked that the UE aborts the RRC-connection.
Test Verification:
To verify that the UE aborts the RRC-connection at the expiry of timer T3240.
Message Flow:

UE NW
REQUEST
COMPLETE
5 LOCATION UPDATING
REQUEST
5a NW The NW starts integrity protection.
6 LOCATION UPDATING
ACCEPT
8 SIGNALLING CONNECTION The UE shall abort the RRC connection.
RELEASE REQUEST
9 RRC CONNECTION NW disconnect the connection established.
RELEASE
10 RRC CONNECTION Send only if RRC Connection Release is send.
RELEASE COMPLETE
Remarks:
At step 10 the UE shall abort the RRC connection.


B_9.4.5.3 Location updating / periodic normal / test 2
Test Purpose:
The purpose of this test is to verify that the UE shall perform a periodic location updating after T3212
expiry.
Pre-requisites:
2 cells, IMSI attach/detach is allowed in both cells.
T3212 is set to 6 minutes.
UE has a valid TMSI. It is "idle updated" on cell A.
Test procedure:
A normal location updating is performed.
Wait until T3212 expires, the UE should initiate a periodic location updating procedure
Test Verification:
To verify that the UE stops and resets the timer T3212 of the periodic location updating
procedure when a LOCATION UPDATING ACCEPT message is received.
To verify that the UE performs an IMSI attach and a periodic location updating 6 minutes
after the IMSI attach.
NOTE: T3212 is stopped when the MM-idle state is left and restarted when the MM sublayer returns
to that state, substate NORMAL SERVICE or ATTEMPTING TO UPDATE. As a consequence, the
exact time when T3212 is reset between those two events cannot be tested.


Message Flow:

UE NW
1 NW The RF level of cell A is lowered until the UE
selects cell B.
2 RRC CONNECTION "establishment cause": Registration.
REQUEST
COMPLETE
5 LOCATION UPDATING "location updating type" = normal.
REQUEST
6 LOCATION UPDATING
ACCEPT
8 RRC CONNECTION
RELEASE
COMPLETE
9 NW The NW waits until the periodic location updating.
REQUEST This message shall arrive between 5 minutes 45s
and 6 minutes 15 s after the last release of the
RRC connection by the NW.
COMPLETE
13 LOCATION UPDATING "Location updating type" = periodic.
REQUEST
ACCEPT
16 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
None


E_9.4.5.4.1 Location updating / periodic search for high priority PLMN / UE waits time T
Test Purposes:
The purpose of this test is to verify that the UE shall make an attempt to access the HPLMN, if the UE
is on the VPLMN at time T after since the last attempt.
Reference: 3GPP TS 22.011 sections 3.2.2.5. and TS 23.122 4.4.3.3.
Pre-requisites:
Two cells A and B, belonging to different location areas with location identification a and b.
Cell A shall be a cell of the HPLMN and Cell B shall be a cell of the VPLMN with a Country
Code the same as that of Cell A. Initially Cell A shall not be broadcasting. IMSI attach/detach
is not allowed on either cell.
The UE is switched off. The HPLMN Search Period on the USIM shall be set to 6 minutes.
The location area information on the USIM is "deleted".
Test Procedure:
Only Cell D shall be broadcasting.

The UE shall be switched on either by using the Power Switch or by applying power.
A normal location updating is performed on Cell D The network shall include the PLMN E in
the list of equivalent PLMNs that is sent in the Location Update Accept message.
Cells A and C shall be made available after 8 minutes, thus ensuring the UE fails to find any
higher priority PLMN during its first attempt.
It is verified that the UE does not perform a location update request on CellB or C (waiting for
at least 6 minutes after broadcasting of CellsB and C). Then Cell A is also made available,
and it is verified that the UE performs a location update request on Cell A within 6 minutes
after broadcasting Cell A.
Test Verification:
To verify that when a cell of the HPLMN becomes available, following the successful location
request on the VPLMN of the home country and after the first search the mobile has failed to
find its HPLMN, that the UE shall perform a location update request on the HPLMN after time
T. Where T is the HPLMN Search Period stored in the USIM.
Message Flow:
Step Direction Message Contents

UE NW
The following messages shall be sent and received
on Cell D.
1 NW Set the cell type of Cell A to the non-suitable cell.
Set the cell type of Cell B to the non-suitable cell.
Set the cell type of Cell C to the non-suitable cell.
Set the cell type of Cell D to the Suitable neighbour
cell. (see note)
1a UE The UE is switched on by either using the Power
Switch or by applying power.
REQUEST



COMPLETE
5 LOCATION UPDATING "Location Update Type": Normal.
REQUEST
6 LOCATION UPDATING Equivalent PLMNs: PLMN E
ACCEPT
7 RRC CONNECTION After sending this message the NW waits for the
8 RRC CONNECTION
RELEASE
COMPLETE
8a NW The NW waits a period of 7 minutes after the UE is
switched on, this allowing the UE to make its first
periodic search.
8b NW Set the cell type of cell B to the Suitable neighbour
cell. Set the cell type cell C to the Suitable
neighbour cell.
(NOTE)
The network shall wait for 7 minutes during which
no messages should be read.
9 NW Set the cell type of cell A to the Suitable neighbour cell.
(NOTE)
Within 6 minutes after step 9 the following
messages shall be sent and received on Cell A.
REQUEST
COMPLETE
13 LOCATION UPDATING "Location Update Type": normal.
REQUEST
ACCEPT
16 RRC CONNECTION
RELEASE
COMPLETE
NOTE: The definitions for Suitable neighbour cell and non-suitable cell are specified in TS 34.108
clause 6.1 Reference Radio Conditions for signalling test cases only.
Remarks:
At step 13 the UE shall send a LOCATION UPDATING REQUEST message.


E_9.4.5.4.2 Location updating / search for higher priority PLMN / UE in manual mode
Test Purposes:
The purpose of this test is to verify that the UE shall not perform periodic location updating attempts if
it is in manual mode and is in a VPLMN.
Reference: 3GPP TS 22.011 section 3.2.2.5. and TS 23.122 section 4.4.3.3.
Pre-requisites:
Two cells A and B, belonging to different location areas with location identification a and b.
Cell A shall be a cell of the HPLMN and Cell B shall be a cell of the VPLMN with a Country
Code the same as that of Cell A. Initially Cell A shall not be broadcasting. IMSI attach/detach
is not allowed on either cell.
The UE is switched off. The HPLMN Search Period on the USIM shall be set to 6 minutes.
The location area information on the USIM is "deleted".
Test Procedure:
Only Cell B shall be broadcasting.

The UE shall be switched on either by using the Power Switch or by applying power.
A normal location updating is performed on Cell B.
The UE is forced into manual selection mode.
Cell A is made available.
It is verified that the UE does not attempt to perform a location update on Cell A.
Test Verification:
To verify that no HPLMN Search is performed when the UE is manual mode.


Message Flow:

UE NW
The following messages shall be sent and received
on Cell B.
1 NW Set the cell type of Cell A to the non-suitable cell.
Set the cell type of Cell B to the Serving cell.
(see note)
1a UE The UE is switched on by either using the Power
Switch or by applying power.
REQUEST
COMPLETE
5 LOCATION UPDATING "Location Update Type": Normal.
REQUEST
6 LOCATION UPDATING
ACCEPT
8 RRC CONNECTION
RELEASE
COMPLETE
9 UE The UE is forced into manual selection mode.
10 NW Set the cell type of cell A to the Suitable neighbour cell.
(NOTE)
11 NW The NW waits a period of 6 minutes. During this
time no messages shall be received on Cell A.
NOTE: The definitions for Serving cell, Suitable neighbour cell and non-suitable cell are specified in
TS 34.108 clause 6.1 Reference Radio Conditions for signalling test cases only.
Remarks:
At step 11 the UE shall not attempt to perform a location update.


E_9.4.6 Location updating / interworking of attach and periodic
Test Purposes:
The purpose of this test is to verify the UEs ability to perform a Periodic Location Update while it is in
NO CELL AVAILABLE, LIMITED SERVICE, PLMN SEARCH or PLMN SEARCH-NORMAL SERVICE
service state.
Reference: 3GPP TS 24.008 sections 4.4.2 and 4.2.1.1.
Pre-requisites:
Configurations: D, C, E, F.
Two cells, a and b, of different PLMNs;
T3212 is set to 12 minutes on cell a;
T3212 is set to 6 minutes on cell b;
IMSI attach is allowed in both cells.
The UE is deactivated. The PLMN of cell b is entered in the USIM's forbidden PLMN list.
Test Procedure:
The UE is activated and placed in automatic network selection mode. It performs IMSI attach.
1 minute after the end of the IMSI attach procedure, cell a is made unavailable . The UE shall
not location update on cell
The UE shall not location update on cell a before 11,75 minutes after the end of the IMSI
attach procedure.
The UE shall perform a periodic location update on cell a between 11,75 minutes and 12,25
minutes after the end of the IMSI attach procedure.
3 minutes after the end of the periodic location updating procedure, cell a is made unavailable.
Kiett 120502
The UE shall not location update on cell b. 14 minutes after the end of the periodic location
updating procedure, cell a is made available and cell b is made unavailable.
The UE shall perform a location update on cell a before 17 minutes after the end of the
periodic location updating procedure.
Test Verification:
To verify that if the PLU timer expires while the UE is out of coverage, the UE informs the
network of its return to coverage.
To verify that the PLU timer is not disturbed by cells of forbidden PLMNs.
To verify that if the PLU timer does not expire while out of coverage and if the mobile returns
to the LA where it is updated, the UE does not inform the network of its return to coverage.


Message Flow:

UE NW
The following messages are sent and shall be
received on cell A.
1 NW Set the cell type of cell A to the Serving cell.
Set the cell type of cell B to the Suitable neighbour cell.
(see note)
1a UE The UE is activated in automatic network selection
mode.
REQUEST
COMPLETE
5 LOCATION UPDATING "location updating type": IMSI attach.
REQUEST
6 LOCATION UPDATING
ACCEPT
8 RRC CONNECTION
RELEASE
COMPLETE
9 NW The network waits 1 minute after step 8. Set the cell type
of cell A to the non-suitable cell.
(see note )
10 NW The NW waits 8 minutes after step 8, Set the cell type of
cell A to the Serving cell.
(see note )
11 RRC CONNECTION This message shall be sent by the UE between 11
REQUEST minutes 45s and 12 minutes 15s after step 8.
COMPLETE
14 LOCATION UPDATING "location updating type": periodic.
REQUEST
ACCEPT
16 RRC CONNECTION After the sending of this message, the NW waits
RELEASE for the disconnection of the main signalling link.
17 RRC CONNECTION
RELEASE
COMPLETE
18 NW The NW waits 3 minutes after step 17, Set the cell type of
cell A to the non-suitable cell.
(see note )
19 NW The NW waits 14 minutes after step 17, Set the cell type
of cell A to the Serving cell.
Set the cell type of cell B to the non- suiteable cell.
(see note )kiett 120502
20 RRC CONNECTION This message shall be sent by the UE before 17
REQUEST minutes after step 17.



UE NW
COMPLETE
23 LOCATION UPDATING "Location updating type" = periodic.
REQUEST
ACCEPT
26 RRC CONNECTION
RELEASE
COMPLETE
establishment. This is checked during 12 minutes.
NOTE: The definitions for Serving cell, Suitable neighbour cell and non-suitable cell are specified in
TS 34.108 clause 6.1 Reference Radio Conditions for signalling test cases only.
Remarks:
At step 20 the UE shall send an RRC CONNECTION REQUEST and at step 23 the UE shall
attempt to perform a location update.
At step 11 the UE shall send an RRC CONNECTION REQUEST and at step 14 the UE shall
attempt to perform a location update.
At step 27 the UE shall not initiate an RRC connection during 12minutes.


E_9.4.7 Location Updating / accept with replacement or deletion of Equivalent PLMN list
Test Purpose:
The purpose of this test case is to verify that the UE replaces or deletes its stored Equivalent PLMN
list when no Equivalent PLMN list is included in the LOCATION UPDATING ACCEPT message from
the network during a Location Update.
Reference: TS 24.008 4.4.4.6
Pre-requistes:
Two cells: A and B, with different PLMN Codes (PLMN 1 and PLMN 2 respectively).
UE is switched off. The HPLMN is PLMN 3 and no other information about PLMN priorities
or forbidden PLMNs is stored in the USIM. The equivalent PLMN list in the mobile station is
empty.
UE is "Idle updated" on cell B.
Test Procedure:
When the UE is initially switched on it will perform a normal location updating in Cell A, which
is the only suitable cell available. The LOCATION UPDATING ACCEPT message sent by the
NW on reception of the LOCATION UPDATING REQUEST message shall include PLMN 2 in
the equivalent PLMN list.
When Cell B is made available and its RF signal level is higher than that of Cell A the UE will
perform a normal location updating in this cell. The LOCATION UPDATING ACCEPT
message sent by the NW shall include PLMN 1 in the equivalent PLMN list.
When Cell B is made unavailable the UE shall perform a normal location updating again in
Cell A, but in this ocassion the LOCATION UPDATING ACCEPT message shall contain an
empty equivalent PLMN list.
When Cell B is made available again and its RF signal level is higher than that of Cell A the
UE shall not perform a normal location updating in this cell since it is not in the ePLMN list.
Test Verification:
To verify that the UE replaces its stored equivalent PLMN list if the equivalent PLMN list is
contained in the LOCATION UPDATING ACCEPT message received from the network during
a location updating procedure.
To verify that the UE deletes its stored equivalent PLMN list if no equivalent PLMN list is
contained in the LOCATION UPDATING ACCEPT message received from the network during
a location updating procedure.


Message Flow:

UE NW
The following messages shall be sent and received on
Cell A
1 NW Set the cell type of Cell A to the "Suitable neighbour cell".
Set the cell type of Cell B to the "non-suitable cell".
(see note)
2 UE The UE is switched on by either using the Power Switch
or by applying power.
3 NW The IE "Establishment cause" in the received RRC
CONNECTION REQUEST message is not checked.
4 Void
5 Void
REQUEST
7 LOCATION UPDATING ACCEPT Equivalent PLMNs: PLMN 2
9 Void
Cell B.
10 NW Set the cell type of Cell B to the "Serving cell".
(see note)
to Registration.
12 Void
13 Void
REQUEST
15 LOCATION UPDATING ACCEPT Equivalent PLMNs : PLMN 1
17 Void
Cell A.
18 NW Set the cell type of Cell B to the "non-suitable cell".
(see note)
to Registration.
20 Void
21 Void
REQUEST



UE NW
23 LOCATION UPDATING ACCEPT Equivalent PLMNs : empty
25 Void
26 NW Set the cell type of Cell B to the "Serving cell".
(see note)
27 NW The NW shall wait for 7 minutes during which no
messages should be received.
NOTE: The definitions for "Serving cell", "Suitable neighbour cell" and "non-suitable cell" are specified in TS
34.108 clause 6.1 "Reference Radio Conditions for signalling test cases only".
Remarks:
At step 14 the UE shall perform a normal location updating in Cell B.
At step 27 the UE shall not perform a normal location updating in Cell B.


B_9.5.2 MM connection / establishment in security mode
Test Purpose:
The purpose of this test is to verify that in security mode, the UE shall be able to correctly set up an
MM connection in a Mobile Originating CM connection attempt and send a CM SERVICE REQUEST
message with CKSN information element as stored in the USIM and Mobile Identity information
element set to the TMSI.
Pre-requistes:
UE has a valid TMSI. It is "idle updated".
Test Procedure:
A mobile originating CM connection is initiated. After the UE has sent the CM SERVICE
REQUEST message to the network, an authentication procedure and a security mode
setting procedure are performed.
UE sends a CM message and the network clears the call and releases the RRC
CONNECTION.
Test Verification:
To verify that the UE can correctly set up an MM connection in an origination and interpret security
mode setting as acceptance of its CM service request.


Message Flow:

UE NW
2 RRC CONNECTION
REQUEST
COMPLETE
7 AUTHENTICATION
RESPONSE
9 SECURITY MODE
COMPLETE
A10 SETUP
A11 RELEASE COMPLETE "Cause" IE: "unassigned number".
13 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
At step 5 the UE shall send the CM SERVICE REQUEST message to the network.
At step A10 the UE shall send a CM message and the network shall release the RRC
connection (step 12).


E_9.5.4 MM connection / establishment rejected
Test Purposes:
The purpose of this test is to verify that the UE shall not send any layer 3 messages, start timer T3240
and enter the "wait for network command" state upon reception of a CM SERVICE REJECT message.
Pre-requisites:
Configurations: A, B, C, D, E, F.
The UE has a valid TMSI. It is "idle updated".
Test Procedure:
A mobile originating CM connection is attempted.

After the UE has sent the CM SERVICE REQUEST message to the network, the network
responds with a CM SERVICE REJECT message with reject cause "requested service option
not subscribed".
It is checked that the UE does not send a layer 3 message.
Test Verification:
To verify that the UE does not send a layer 3 message when the service request is rejected by
the network.
Message Flow:

UE NW
1 UE A MO CM connection is attempted
2 RRC CONNECTION
REQUEST
COMPLETE
6 CM SERVICE REJECT "Reject cause" IE: "requested service option not
subscribed".
7 NW The UE shall not send a layer 3 message. This is
checked during 5 s.
9 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
The UE shall attempt MO CM connection (step 1).

At step 7 the UE shall not send a layer 3 message and at step 9 the UE shall send an RRC
CONNECTION RELEASE COMPLETE message.


E_9.5.6 MM connection / expiry T3230
Test Purposes:
The purpose of this test is to verify that the UE shall abort the MM connection at the expiry of T3230.
Reference: 3GPP TS 24.008 sections 4.5.1.2 and 11.2.
Pre-requisites:
The UE has a valid TMSI. It is "idle updated".
Test Procedure:

After the UE has sent the CM SERVICE REQUEST message to the network, the network
waits for expiry of timer T3230.
It is checked that the UE send a MM STATUS message and waits for the release of the RRC-
connection.
Test Verification:
To verify that at T3230 expiry, the UE aborts the MM-connection establishment.
Message Flow:

UE NW
2 RRC CONNECTION
REQUEST
COMPLETE
6 NW The NW waits for expiry of timer T3230.
7 CM SERVICE ACCEPT
8 MM STATUS "Reject cause" IE is "message type not compatible
with protocol state".
10 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
The UE shall attempt MO CM connection (step 1).

At step 8 the UE shall send a MM STATUS message.


E_9.5.7.1 MM connection / abortion by the network / cause #6
Test Purposes:
Pre-requisites:
2 cells, default parameters.
The UE has a valid TMSI, CKSN and CK, IK. It is "idle updated" on cell B.
Test Procedure:

Upon reception of the AUTHENTICATION RESPONSE message, the network sends an
ABORT message with cause #6. The network waits for 5 s.
The UE shall not send any layer 3 message. The network releases the RRC connection.
The network checks that the UE has entered the state MM IDLE substate NO IMSI, i.e. does
not perform normal location updating, does not perform periodic updating, does not respond to
paging, rejects any requests from CM entities except emergency calls and does not perform
IMSI detach if deactivated.
Test Verification:
To check that upon reception of an ABORT message with cause #6 during call establishment:
The UE does not send any layer 3 message;
After reception of an ABORT message and after having been deactivated and
reactivated, the UE performs location updating using its IMSI as mobile identity and
indicates deleted LAI and CKSN;
The UE does not perform location updating, does not answer to paging with TMSI,
rejects any request for mobile originating call except emergency call, does not perform
IMSI detach;
The UE accepts a request for emergency call.
Message Flow:

UE NW
The following messages are sent and shall be received on cell B
1 UE A mobile originating CM connection is attempted.

2 RRC CONNECTION
REQUEST
COMPLETE
7 AUTHENTICATION
RESPONSE
8 ABORT "reject cause" = #6.
9 NW The NW waits for 5 s.
10 UE The UE shall not send any layer 3 message during
that time.



UE NW
12 RRC CONNECTION
RELEASE
COMPLETE
The following messages are sent and shall be received on cell A.
13 NW Set the cell type of cell A to the Serving cell.

Set the cell type of cell B to the non-suitable cell.
(NOTE)
14 UE The UE performs cell reselection according to
procedure as specified in (this however is not
checked until step 27). The UE shall not initiate an
RRC connection establishment on cell A or on cell
B.
15 NW The NW waits at least 7 minutes for a possible
periodic updating.
establishment on cell A or on cell B.
17 PAGING TYPE 1 "UE identity" IE contains TMSI.
establishment on cell A or on cell B. This is verified
during 3 s.
checked during 3 s.
21 UE If the UE supports speech, an emergency call is
attempted.
REQUEST
COMPLETE
27 EMERGENCY SETUP
28 RELEASE COMPLETE "Cause" = unassigned number.
30 RRC CONNECTION
RELEASE
COMPLETE
31 UE If possible USIM detachment is performed.
Otherwise if possible switch off is performed.
checked during 3 s.
REQUEST


UE NW
COMPLETE
REQUEST available, "Mobile Identity" = IMSI, "LAI" = deleted
39 AUTHENTICATION
RESPONSE
ACCEPT
COMPLETE
43 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
At step 10 the UE shall not send any layer 3 message and at step 12 the UE shall send an
RRC CONNECTION RELEASE COMPLETE message.
At step 14 the UE shall not initiate an RRC connection establishment (not perform normal
location updating).
At step 16 the UE shall not initiate an RRC connection establishment.(not perform periodic
location updating).
At step 18 the UE shall not initiate an RRC connection establishment (not respond to paging
with TMSI).
At step 20 the UE shall not initiate an RRC connection establishment (reject any request for
Mobile Originating call establishment).
At step 32 the UE shall not initiate an RRC connection establishment.(not perform IMSI
detach).
At step 22 the UE shall send an RRC CONNECTION REQUEST message with the
establishment cause set to "emergency call".
At step 37 the UE send a LOCATION UPDATING REQUEST message with the Mobile
Identity IE set to its IMSI, CKSN IE set to "no key is available" and the Location Updating type
set to "deleted LAI".


E_9.5.8.1 MM connection / follow-on request pending / test 1
Test Purposes:
The purpose of this test is to verify that The UE shall not attempt to establish a new MM connection
after location updating on the same RRC connection if not allowed by the network.
Pre-requisites:
1 cell, ATT flag is set to "MSs in the cell shall apply IMSI attach and detach procedure".
The UE has a valid TMSI and is deactivated.
Test Procedure:
The UE is activated and a CM connection is attempted during the location updating procedure.
The network does not include the follow on proceed information element in the LOCATION
UPDATING ACCEPT message.
The network waits for at least 8 s. The UE shall not send any layer 3 message for 8 s.
Test Verification:
To verify that when the network does not include the follow on proceed IE in a LOCATION
UPDATING ACCEPT message, a UE that has a CM application request pending does not
attempt to establish a new MM connection on that RRC connection.
Message Flow:

UE NW
1 UE The UE is activated.
REQUEST
COMPLETE
5 LOCATION UPDATING location updating type = IMSI attach.
REQUEST Then the NW waits for 15 s. During this delay a CM
connection is attempted.
6 LOCATION UPDATING follow on proceed IE not included.
ACCEPT
7 NW The NW wait for at least 8 s.
8 UE The UE shall not send any layer 3 message for 8 s
after reception of the LOCATION UPDATING
ACCEPT message.
10 RRC CONNECTION
RELEASE
COMPLETE
Remarks:
After step 8 the UE shall not send any layer 3 messages.


B_10.1.2.1.1 Outgoing call / U0 null state / MM connection requested.
Test Purpose:
The call control entity of the User Equipment requests the MM-sublayer to establish a mobile
originating MM-connection.
To verify that upon initiation of an outgoing basic call by the user, the UE initiates establishment of an
MM connection, using, as first MM message, a CM SERVICE REQUEST message with CM service
type "Mobile originating call establishment or packet mode connection establishment".
References: TS 24.008 clause 5.2.1.1 and clause 4.5.1.1
Pre-requisites:
1 cell, default parameters. Configurations A,B,C,D,E,F.
The UE is in MM-state "idle, updated" with valid TMSI and CKSN.
Test procedure:
An MO circuit switched basic service is selected which is supported by the UE; if the UE
supports MO telephony, the selected basic service is telephony.
If necessary, the UE is configured for that basic service.
Then, the UE is made to initiate a call.
When the NW receives CM SERVICE REQUEST, the contents shall be checked.
Test Verification:
Message Flow:

UE NW
1 -> Void UE initiates outgoing call
2 <- Void
3 -> RRC CONNECTION SETUP COMPLETE
4 -> CM SERVICE REQUEST NW shall verify the CM service type
requested by the UE
Remarks:
After step 3 the UE shall initiate establishment of an MM connection, using as the first MM message a
CM SERVICE REQUEST message with CM service type "Mobile originating call establishment or
packet mode connection establishment".


E_10.1.2.2.1 Outgoing call / U0.1 MM connection pending / CM service rejected
Test Purpose:
A request for MM connection is rejected by the NW.
To verify that a CC entity of the UE in CC-state U0.1, "MM-connection pending", upon the UE
receiving a CM SERVICE REJECT message, returns to CC state U0, "Null".
References: TS 24.008, clause 4.5.1.1
Pre-requisites:
The UE is brought into the state U0.1 by using table 10.1.2/1 from 3GPP 34.123.
Test Procedure:
If necessary, the UE is configured for that basic service. Then, the UE is made to initiate a
call.
When the NW receives CM SERVICE REQUEST, the contents of it shall be checked. The NW
rejects it by CM SERVICE REJECT.
Test Verification:
Message Flow:

UE NW
1 <- CM SERVICE REJECT
2 <- Void The NW releases the RRC
connection
3 -> Void
4 UE the UE shall release the main
signalling link
Remarks:
After step 2 CC entities relating to all mobile originating transaction identifiers shall send RELEASE
COMPLETE messages with cause value #81 (invalid TI value).
The internal status of the UE can be checked by UE internal trace.


B_10.1.2.2.2 Outgoing call / U0.1 MM connection pending / CM service accepted
Test Purpose:
A CM request is accepted for the MM-connection by the NW.
To verify that a CC entity of the UE in CC-state U0.1, "MM-connection pending", upon the UE
receiving a CM SERVICE ACCEPT message, sends a SETUP message specifying the Called party
BCD number that was entered into the UE.
References: TS 24.008, clause 5.2.1.
Pre-requisites:
The UE is brought into the state U0.1 by using table 10.1.2/1 from 3GPP 34.123
No ciphering procedure is initiated by the NW
Test procedure:
call.
When the UE is requesting a MM-connection, the NW will indicate acceptance by sending a
CM SERVICE ACCEPT message.
The UE shall respond with SETUP.
Test Verification:
Message Flow:

UE NW
1 <- CM SERVICE ACCEPT
2 -> SETUP with called party BCD number.
Remarks:
After step 1 the UE shall send a SETUP message specifying the called party BCD number that was
entered into the UE and then enter CC state U1, "Call initiated".


B_10.1.2.3.1 Outgoing call / U1 call initiated / receiving CALL PROCEEDING
Test Purpose:
The call control entity of the UE being in the state, U1, a CALL PROCEEDING message is sent by the
NW.
To verify that a CC entity of the UE in CC-state U1, "Call initiated", can accept the CALL
PROCEEDING message from the NW.
References: TS 24.008, clauses 5.2.1.1, 5.2.1.2 and 5.2.1.3.
Pre-requisites:
The UE is brought into the state U1 by using table 10.1.2/1 from 3GPP 34.123
Test procedure:
call. The CC entity of the UE is brought to the state U1.
The NW sends a CALL PROCEEDING message to the UE.
Test Verification:
Message Flow:

UE NW
1 <- CALL PROCEEDING tone generation not mandatory
Remarks:
After step 1 the UE shall enter CC state U3, "Mobile originating call proceeding".


B_10.1.2.3.2 Outgoing call / U1 call initiated / rejecting with RELEASE COMPLETE
Test Purpose:
The call control entity of the UE being in the state, U1, the call is rejected by a RELEASE COMPLETE
message sent by the NW.
To verify that a CC entity of the UE in CC-state U1, "Call initiated", can accept a RELEASE
COMPLETE message with valid cause value.
References: TS 24.008, clause 5.4.4.1.3,.
Pre-requisites:

Test procedure:
An MO circuit switched basic service is selected that is supported by the UE; if the UE
The NW sends a RELEASE COMPLETE message to the UE.
Test Verification:
Message Flow:

UE NW
1 <- RELEASE COMPLETE This test case does not require a
specific cause value. E.g. value #47,
resources unavailable, is a suitable
value
2 <- Void The NW release the RRC connection.
3 -> Void
Remarks:


E_10.1.2.3.5 Outgoing call / U1 call initiated / receiving ALERTING
Test Purpose:
The call control entity of the UE being in the state, U1, an ALERTING message is sent to the UE as an
indication that a call is being alerted at the called end.
To verify that a CC entity of the UE in CC-state U1, "Call initiated", upon receipt of an ALERTING
message, enters CC state U4, "Call delivered".
References: TS 24.008, clause 5.2.1.1 and clause 5.2.1.5
Pre-requisites:
The UE is brought into the state U1 by using table 10.1.2/4 from 3GPP 34.123.
Test Procedure:
call.
The CC entity of the UE is brought to the state U1. The NW sends an ALERTING message to
the UE.
Test Verification:
Message Flow:
UE NW
1 <- ALERTING
Remarks:
After step 1 the UE shall enter CC state U4, "Call delivered".


E_10.1.2.3.6 Outgoing call / U1 call initiated / entering state U10
Test Purpose:
The call control entity of the UE being in the state, U1, a CONNECT message is received by the UE.
To verify that a CC entity of the UE in CC-state U1, "Call initiated", upon receipt of a CONNECT
message, sends a CONNECT ACKNOWLEDGE message to its peer entity and enters CC state U10,
"Active".
References: TS 24.008, clause 5.2.1.1 and clause 5.2.1.6.
Pre-requisites:
Test Procedure:
call.
The CC entity of the UE is brought to the state U1. The NW sends a CONNECT message to
the UE.
The UE shall respond by sending a CONNECT ACKNOWLEDGE message.
Test Verification:
Message Flow:
UE NW
1 <- CONNECT
2 -> CONNECT ACKNOWLEDGE
Remarks:
After step 1 the UE shall send a CONNECT ACKNOWLEDGE message and shall enter CC state
U10, "Active".


B_10.1.2.4.1 Outgoing call / U3 Mobile originating call proceeding / ALERTING received
Test Purpose:
The call control entity of the UE being in the state, U3, an ALERTING message is sent to the UE as an
indication that a call is being alerted at the called end.
To verify that the CC-entity of the UE in CC-state U3, "Mobile Originating Call Proceeding", can accept
the ALERTING message from the NW.
References: TS 24.008 clause 5.2.1.5
Pre-requisites:
Test procedure:
The NW sends an ALERTING message to the UE.
Test Verification:
Message Flow:

UE NW
1 <- ALERTING
Remarks:
After step 1 the UE shall enter CC-state U4, "Call Delivered".


E_10.1.2.4.2 Outgoing call / U3 Mobile originating call proceeding / CONNECT received
Test Purpose:
The call control entity of the UE being in the state, U3, a CONNECT message is received by the UE.
To verify that a CC-entity of the UE in CC-state U3, "Mobile Originating Call Proceeding", upon receipt
of a CONNECT message returns a "CONNECT ACKNOWLEDGE" message to its peer entity.
To verify that the UE stops locally generated alerting indication, if any.
References: TS 24.008 clause 5.2.1.6.
Pre-requisites:
Test Procedure:
The NW sends a RADIO BEARER SETUP for traffic channel to the UE. The UE shall respond
with a RADIO BEARER SETUP COMPLETE message.
The NW sends a CONNECT message to the UE. The UE shall respond by sending a
CONNECT ACKNOWLEDGE message.
Test Verification:
Message Flow:
UE NW
1 Radio Bearer Setup Procedure SeeTS34.108 clause 7.1.3
2 <- CONNECT the UE shall stop locally generated
alerting indication, if any
3 -> CONNECT ACKNOWLEDGE
Remarks:
After step 1 the UE shall return a "CONNECT ACKNOWLEDGE" message and enter the CC state
U10, "Active".
The UE shall stop locally generated alerting indication.


E_10.1.2.4.3 Outgoing call / U3 Mobile originating call proceeding / PROGRESS received

without in band information
Test Purpose:
The call control entity of the UE being in the state, U3, a PROGRESS message is received by the UE.
The PROGRESS message does not contain indication of in-band information availability.
To verify that after receipt of the PROGRESS message timer T310 is stopped.
References: TS 24.008 clause 5.2.1.4.2, TS 24.008 clause 5.5.6.
Pre-requisites:
Test Procedure:
The NW sends a PROGRESS message not containing indication of in-band information
availability to the UE.
The NW checks that the UE has stopped T310, i.e. at T310 time-out no DISCONNECT
message is sent by the UE.
Test Verification:
Message Flow:
UE NW
1 <- PROGRESS (note)
2 NW NW waits at least 45 s and checks
no DISCONNECT is sent by the UE
Remarks:
After step 3 NW waits at least 45 s and checks no DISCONNECT is sent by the UE.


B_10.1.2.4.4 Outgoing call / U3 Mobile originating call proceeding / PROGRESS with in

band information
Test Purpose:
The call control entity of the UE being in the state, U3, a PROGRESS message indicating the
availability of in band information is received by the UE.To verify that a CC-entity of the UE in CC-state
U3, "Mobile Originating Call Proceeding", upon receipt of a PROGRESS message indicating in-band
announcement through-connects the traffic channel for speech, if DTCH is in speech mode. If DTCH
is not in a speech mode, the UE does not through-connect the DTCH.To verify that after receipt of the
PROGRESS message, T310 is stopped.
References: TS 24.008 clause 5.5.1, clause 5.5.6.
Pre-requisites:
The UE is brought into the state U3 by using table 10.1.2/3.
Test procedure:
The NW sends a PROGRESS message containing indication of in-band information
availability to the UE. If channel mode is speech, the DTCH shall be through connected. If
channel mode is not speech, the DTCH shall not be through connected.
Also, it is checked that the UE has stopped T310, i.e. at T310 time-out no DISCONNECT
message is sent by the UE.
Message Flow:
UE NW
1 Radio Bearer Setup Procedure See TS34.108 clause 7.1.3
2 <- PROGRESS The UE shall stop all the CC timers ,
if channel mode is speech, the
DTC H shall be through connected.
If channel mode is not speech, the
DTCH shall not be through
connected.
See specific message content in
3GPP 34.123, section 10.1.2.4.4.4
Remarks:
After step 2 the UE shall through-connect the traffic channel for speech, if DTCH is in a speech mode.
If DTCH is not in speech mode, the UE shall not through-connect the DTCH.After step 2 the NW waits
at least 45 s and checks no DISCONNECT is sent by the UE.


E_10.1.2.4.5 Outgoing call / U3 Mobile originating call proceeding / DISCONNECT with in

band tones
Test Purpose:
The call control entity of the UE being in the state, U3, a DISCONNECT message indicating
availability of in band information is received by the UE.
of a DISCONNECT with progress indicator #8 through-connects the speech channel to make in-band
announcements available, if traffic channel is in speech mode. If DTCH is not in speech mode, the UE
sends a RELEASE message.
References: TS 24.008 clause 5.4.4.1.1.1
Pre-requisites:
Nework configured for in-band signalling
Test Procedure:
The NW sends a DISCONNECT message containing indication of in-band information
availability to the UE. The NW checks that if channel mode is speech, the DTCH shall be
through connected. If channel mode is not speech, the DTCH shall not be through connected,
and the UE shall send a RELEASE message.
Test Verification:
Message Flow:
UE NW
2 <- DISCONNECT (note)
DTCH in speech mode:
A3 NW the NW will check that the audio
path for in band tones is attached.
DTCH is not in speech mode:
B3 -> RELEASE
Remarks:
After step 2 the UE shall through-connect the speech channel to make in-band announcements
available, if traffic channel is in speech mode. If DTCH is not in speech mode, the UE shall send a
RELEASE message.The internal status of the UE can be checked by UE internal trace.

B_10.1.2.4.6 Outgoing call / U3 Mobile originating call proceeding / DISCONNECT without

in band tones
Test Purpose:
The call control entity of the UE being in the state, U3, a DISCONNECT message is received by the
UE. The DISCONNECT message does not contain indication of in-band information availability.
of a DISCONNECT without progress indicator returns a RELEASE message.
Pre-requisites:
Test procedure:
The NW sends a DISCONNECT message not containing indication of in-band information
availability to the UE. The UE shall respond with a RELEASE message.
Test Verification:
Message Flow:

UE NW
1 <- DISCONNECT Without progress indicator
2 -> RELEASE
Remarks:
After step 1 the UE shall send a RELEASE message and enter the CC-state U19, "Release Request".


E_10.1.2.4.7 Outgoing call / U3 Mobile originating call proceeding / RELEASE received
Test Purpose:
The call control entity of the UE being in the state, U3, a RELEASE message is received by the UE.
of a RELEASE will return a RELEASE COMPLETE.
To verify that the UE, on returning to the idle mode, releases the MM-connection.
Pre-requisites:
Test Procedure:
The NW sends a RELEASE message to the UE. The UE shall respond with a RELEASE
COMPLETE message.
Test Verification:
Message Flow:
UE NW
1 <- RELEASE with cause "Normal, unspecified"
2 -> RELEASE COMPLETE
connection.
4 -> Void
Remarks:
After step 1 the UE shall send a RELEASE COMPLETE message.


E_10.1.2.4.8 Outgoing call / U3 Mobile originating call proceeding / termination requested

by the user
Test Purpose:
The call control entity of the UE, being in the state U3, termination of the call is requested by the user.
To verify that a CC-entity of the UE in CC-state U3, "Mobile Originating Call Proceeding", upon
request by the user to terminate will send a DISCONNECT message.
Pre-requisites:
Test Procedure:
The user requests termination of the call. The UE shall send a DISCONNECT message.
Test Verification:
Message Flow:
UE NW
1 MMI action, terminate call
2 -> DISCONNECT
Remarks:
After step 1 the UE shall send a DISCONNECT message and enter the CC-state U11, "Disconnect
Request".


B_10.1.2.5.1 Outgoing call / U4 call delivered / CONNECT received
Test Purpose:
The call control entity of the UE being in the state U4, a CONNECT message is received by the UE.
To verify that a CC-entity of the UE in CC-state U4, "Call Delivered", upon receipt of the CONNECT
message returns a CONNECT ACKNOWLEDGE to its peer entity.
Pre-requisites:
Test procedure:
The NW sends a CONNECT message to the UE. The UE shall respond by sending a
CONNECT ACKNOWLEDGE message.
Test Verification:
Message Flow:
UE NW
1 <- CONNECT
2 -> CONNECT ACKNOWLEDGE UE stops locally generated alerting
indication, if applicable
Remarks:
After step 1 the UE shall return a CONNECT ACKNOWLEDGE message and enter the CC state U10,
"Active".


E_10.1.2.5.2 Outgoing call / U4 call delivered / termination requested by the user
Test Purpose:
The call control entity of the UE being in the state U4, the user requests termination of the call.
To verify that a CC-entity of the UE in CC-state U4, "Call Delivered", upon request by the user to
terminate will send a DISCONNECT message.
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
UE NW
2 -> DISCONNECT
Remarks:
After step 1 the UE shall send a DISCONNECT message and enter the CC state U11, "Disconnect
Request".


E_10.1.2.5.3 Outgoing call / U4 call delivered / DISCONNECT with in-band tones
Test Purpose:
To verify that a CC-entity of the UE in CC-state U4, "Call Delivered", upon receipt of a DISCONNECT
with a progress indicator indicating in-band information, through-connects the speech channel to make
in-band announcements available, if traffic channel is in speech mode. If DTCH is not in speech mode,
the UE shall send a RELEASE message.
Pre-requisites:
Test Procedure:
If channel mode is MO telephony, the DTCH shall be through connected. If channel mode is
not speech, the DTCH shall not be through connected, and the UE shall send a RELEASE
message.
Test Verification:
Message Flow:
UE NW
B2 -> RELEASE
Remarks:
RELEASE message.


E_10.1.2.5.4 Outgoing call / U4 call delivered / DISCONNECT without in-band tones
Test Purpose:
To verify that a CC-entity of the UE in CC-state U4, "Call Delivered", upon receipt of a DISCONNECT
without progress indicator, returns a RELEASE message.
Pre-requisites:
Test Procedure:
The UE shall respond with a RELEASE message.
Test Verification:
Message Flow:
UE NW
1 <- DISCONNECT without progress indicator
2 -> RELEASE
Remarks:
After step 1 the UE shall return a RELEASE message and enter the CC-state U19, "Release
Request".


E_10.1.2.5.5 Outgoing call / U4 call delivered / RELEASE received
Test Purpose:
To verify that a CC-entity of the UE in CC-state U4, "Call Delivered", upon receipt of the RELEASE
message will respond with the RELEASE COMPLETE message.
To verify that the UE, on returning the idle mode, releases the MM-connection.
Pre-requisites:
Test Procedure:
COMPLETE message.
Test Verification:
Message Flow:
UE NW
3 <- Void The network releases the RRC
connection.
4 Void
Remarks:
After step 1 the UE shall respond with the RELEASE COMPLETE message.


B_10.1.2.5.7 Outgoing call / U4 call delivered / traffic channel allocation
Test Purpose:
The call control entity of the UE, being in the state, U4, a radio bearer establishment procedure is
performed.
Pre-requisites:
NW is using late assignment procedure
Test procedure:
Test Verification:
Message Flow:

UE NW
Remarks:
After step 1 the CC state U4, "Call delivered", shall remain unchanged.


B_10.1.2.6.1 U10 active / termination requested by the user
Test Purpose:
The call control entity of the UE, being in the state, U10, the user requests call termination.
To verify that the CC-entity of the UE in CC-state U10, "Call Active", upon request by the user to
References: TS 24.007 clause 6.2.2, TS 24.008 clause 5.4.3.
Pre-requisites:
Test procedure:
If necessary, the UE is configured for that basic servi ce. Then, the UE is made to initiate a
Test Verification:
Message Flow:

UE NW
2 -> DISCONNECT
Remarks:
After step 1 the UE shall send a DISCONNECT message and enter the CC state U11, "Disconnect
Request".


B_10.1.2.6.4 U10 active / DISCONNECT without in-band tones
Test Purpose:
To verify that the CC-entity of the UE in CC-state U10, "Call Active", upon receipt of a DISCONNECT
message without progress indicator, returns a RELEASE message.
Pre-requisites:
Test procedure:
availability to the UE. The UE shall respond with a RELEASE message.
Test Verification:
Message Flow:

UE NW
2 -> RELEASE
Remarks:
Request".


E_10.1.2.6.2 U10 active / RELEASE received
Test Purpose:
To verify that the CC-entity of the UE in CC-state U10, "Call Active", upon receive of the RELEASE will
respond with the RELEASE COMPLETE message.
Pre-requisites:
Test Procedure:
The NW sends a RELEASE message to the UE.
The UE shall respond with a RELEASE COMPLETE message.
Test Verification:
Message Flow:
UE NW
2 -> RELEASE COMPLETE the UE starts T3240
connection.
4 -> Void
Remarks:
After step 1 the UE shall return a RELEASE COMPLETE message.


E_10.1.2.6.3 U10 active / DISCONNECT with in-band tones
Test Purpose:
To verify that a CC-entity of the UE in CC-state U10, "Call Active", upon receipt of a DISCONNECT
message with a Progress Indicator indicating in-band information, through-connects the speech
channel to make in-band announcements available, if traffic channel is in speech mode. If DTCH is not
in speech mode, the UE sends a RELEASE message.
Pre-requisites:
Test Procedure:
The NW checks that if channel mode is speech, the DTCH shall be through connected. If
channel mode is not speech, the DTCH shall not be through connected and the UE shall send
a RELEASE message.
Test Verification:
Message Flow:
Step Direction Messa ge Comments

UE NW
B2 -> RELEASE
Remarks:
RELEASE message.


E_10.1.2.6.4 U10 active / DIS CONNECT without in-band tones
Test Purpose:
To verify that the CC-entity of the UE in CC-state U10, "Call Active", upon receipt of a DISCONNECT
message without progress indicator, returns a RELEASE message.
Pre-requisites:
Test Procedure:
The UE shall respond with a RELEASE message.
Test Verification:
Message Flow:

UE NW
2 -> RELEASE
Remarks:
Request".


E_10.1.2.6.5 U10 active / RELEASE COMPLETE received
Test Purpose:
The call control entity of the UE being in the state, U10, the call is cleared by a RELEASE COMPLETE
To verify that a CC entity of the UE in CC-state U10, "active", can accept a RELEASE COMPLETE
message with valid cause value from the NW.
References: TS 24.008 clause 5.4.2, TS 24.008 clause 5.4.4.1.3.
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:

UE NW
1 <- RELEASE COMPLETE note 1
connection.
3 Void
Specific message contents:
NOTE 1:With the cause value chosen arbitrarily.
Remarks:
After step 2 CC entities relating to all mobile originating trans action identifiers shall send RELEASE
COMPLETE messages with cause value #81 (invalid TI value).


E_10.1.2.6.6 U10 active / SETUP received
Test Purpose:
If the UE does not react correctly when receiving a SETUP message on a new Transaction Identifier
during an active call, the active call may be lost.
To verify that a User Equipment that has a call established and receives a SETUP message answers
either with a CALL CONFIRMED message with cause "user busy" if it supports call waiting, or with a
RELEASE COMPLETE message with cause "user busy".
References: TS 24.008 clause 5.2.2.3.1
Pre-requisites:
The UE is idle updated with valid TMSI and CKSN.
Test Procedure:
The UE has a mobile originated call in the U10 state. When UE sends a SETUP message and
NW receives it in the first call establishment, NW sends a CALL PROCEEDING message
without Network Call Control Capability IE.
The NW sends a SETUP message to the UE (with signal IE indicating "call waiting tone on"
and without Network Call Control Capability IE).
If the UE does not support call waiting it shall answer by a RELEASE COMPLETE message.
If the UE supports call waiting it shall answer with a CALL CONFIRMED message followed by
an ALERTING message. The second transaction is then released by the NW with a RELEASE
COMPLETE message.
Test Verification:
Message Flow:
UE NW
1 <- SETUP this message establishes a second
transaction The TI value shall be the
same as the one that is in use for
the MO call. The TI flag shall have
the value specified for an MT call.
if the UE does not support call
waiting
A2 -> RELEASE COMPLETE with cause user busy" with the TI of
the second transaction
if the UE supports call waiting
B2 -> CALL CONFIRMED with cause user busy" with the TI of
the second transaction
B3 -> ALERTING with the TI of the second transaction
B4 <- RELEASE COMPLETE with the TI of the second transaction


Remarks:
After step 1 a UE that has a call established shall answer either with a CALL CONFIRMED message
with cause "user busy" if it supports call waiting, or with a RELEASE COMPLETE message with cause
"user busy".
After step A2 or B4 the UE shall be in state U10 for the established call.


B_10.1.2.7.2 U11 disconnect request / RELEASE received
Test Purpose:
To verify that the CC-entity of the UE in CC-state U11, "Disconnect Request", upon receipt of the
RELEASE message shall return RELEASE COMPLETE.
Pre-requisites:

Test procedure:
COMPLETE message.
Test Verification:
Message Flow:

UE NW
1 <- RELEASE
connection.
4 -> Void
Remarks:
After step 1 the UE shall return the RELEASE COMPLETE.


B_10.1.2.9.4 Outgoing call / U19 release request / RELEASE COMPLETE received
Test Purpose:
The call control entity of the UE being in the state U19, a RELEASE COMPLETE message is received
by the UE.
To verify that the CC-entity of the UE in CC-state U19, "Release Request", upon receipt of a
RELEASE COMPLETE, shall release the MM-connection.
References: TS 24.008 clause 5.4.2, TS 24.008 clause 5.4.4.1.3
Pre-requisites:
Test procedure:
The NW sends a RELEASE COMPLETE message to the UE. The UE shall release the MM-
connection.
Test Verification:
Message Flow:

UE NW
1 <- RELEASE COMPLETE
connection.
3 -> Void
Remarks:


B_10.1.3.3.1 Incoming call / U9 mobile terminating call confirmed / alerting or immediate

connecting
Test Purpose:
The call control entity of the UE, having entered the state, U9, with signal information received in the
preceding SETUP message, the subsequent behaviour of the UE is tested.
To verify that a CC entity in CC-state U9, "Mobile Terminating Call Confirmed", (if signalled by the
network in previous SETUP message that it may alert) will either send a ALERTING message to its
peer entity, or send a CONNECT message to its peer entity.
References: TS 24.008 clause 5.2.2.3.2 and clause 5.2.2.5.
Pre-requisites:
Test procedure:
An MT circuit switched basic service is selected that is supported by the UE; if the UE
supports MT telephony, the selected basic service is telephony.
If necessary, the UE is configured for that basic service. Then a mobile terminated call is
initiated. The CC entity of the UE is brought to the state U9 by using a SETUP message
containing signalling information element. (The state U9 is not a stable state in this case, and
consequently it is not checked as an initial state.)
If the UE supports immediate connect for the selected basic service (p = Y), it sends a
CONNECT message and enters the state U8, connect request. Otherwise (p = N) the UE
sends an ALERTING message and enters the state U7, call receiving.
Test Verification:
Message Flow:
UE NW
A1 -> CONNECT p=Y
B1 -> ALERTING p=N
Remarks:
At step A1 the UE shall send a CONNECT message and enter U8 if the network has signalled in
previous SETUP message that UE may not alert. shall send an ALERTING message and enter state
U7 if the network has signalled in previous SETIP message that the UE may alert.


E_10.1.3.3.2 Incoming call / U9 mobile terminating call confirmed / DTCH assignment
Test Purpose:
The call control entity of the UE being in the state, U9, a radio bearer establishment procedure is
performed for traffic channel.
To verify that a CC-entity of the UE in CC-state U9, "Mobile Terminating Call Confirmed", when a
traffic channel is allocated by the network performing the radio bearer establishment procedure, shall
sends a ALERTING message.
References: TS 24.008 clause 5.2.2.7 and clause 5.2.2.3.2.
Pre-requisites:
Test Procedure:
An MT circuit switched basic service is selected that is supported by the UE and for which the
UE does not use immediate connection; if the UE supports MT telephony without immediate
connection, the selected basic service is telephony.
initiated. The CC entity of the UE is brought to the state U9 (by using a SETUP message not
containing the signal information element).
The NW sends a RADIO BEARER SETUP for traffic channel to the UE.
The UE shall respond with a RADIO BEARER SETUP COMPLETE message.
The UE sends an ALERTING message.
Test Verification:
Message Flow:
UE NW
2 -> ALERTING
Remarks:
After step 1 the UE shall send a ALERTING message and enter state U7.


E_10.1.3.3.3 Incoming call / U9 mobile terminating call confirmed / termination requested

by the user
Test Purpose:
The call control entity of the UE, being in the state, U9, the user requests termination of the call.
To verify that a CC-entity of the UE in CC-state U9, "Mobile Terminating Call Confirmed", upon
request by the user to terminate will send a DISCONNECT message.
Pre-requisites:
Test Procedure:
initiated. The CC entity of the UE is brought to the state U9 (by using a SETUP message not
containing the signal information element).
Then the user requests termination of the call, if possible. The UE sends a DISCONNECT
message.
Test Verification:
Message Flow:
UE NW
1 the UE is made to clear the call
2 -> DISCONNECT
Remarks:
After step 1 the UE shall send a DISCONNECT message and enter the CC-state U11, "Disconnect
Request".


E_10.1.3.3.4 Incoming call / U9 mobile terminating call confirmed / DISCONNECT received
Test Purpose:
UE.
To verify that a CC-entity of the UE in CC-state U9, "Mobile Terminating Call Confirmed", upon receipt
of a DISCONNECT returns a RELEASE message.
Pre-requisites:
Test Procedure:
initiated. The CC entity of the UE is brought to the state U9.
The NW sends a DISCONNECT message to the UE.
The UE responds by sending a RELEASE message.
Test Verification:
Message Flow:

UE NW
1 <- DISCONNECT
2 -> RELEASE
Remarks:
Request".


E_10.1.3.3.5 Incoming call / U9 mobile terminating call confirmed / RELEASE received
Test Purpose:
To verify that a CC-entity of the UE in CC-state U9, "Mobile Terminating Call Confirmed", upon receipt
of a RELEASE will return a RELEASE COMPLETE.
References: TS 24.008 clause 5.4
Pre-requisites:
Test Procedure:
If necessary, the UE is confi gured for that basic service. Then a mobile terminated call is
The NW sends a RELEASE message to the UE.
The UE responds by sending a RELEASE COMPLETE message.
Test Verification:
Message Flow:
UE NW
connection.
4 Void
Remarks:
After step 1 the UE shall return a RELEASE COMPLETE message.


B_10.1.3.4.1 Incoming call / U7 call received / call accepted
Test Purpose:
The call control entity of the UE, being in the state, U7, a user accepts the incoming call.
To verify that a CC entity of a UE in CC-state U7, "Call Received", upon a user accepting the incoming
call, shall send a CONNECT message to its peer entity.
Pre-requisites:
Test procedure:
The user accepts the incoming call. The UE sends a CONNECT message.
Test Verification:
Message Flow:
UE NW
1 the UE is made to accept the call by
the user
2 -> CONNECT
Remarks:
After step 1 UE shall send a CONNECT message and enter the CC-state U8, "Connect Request".


B_10.1.3.4.2 Incoming call / U7 call received / termination requested by the user
Test Purpose:
The call control entity of the UE, being in the state, U7, a user requests termination of the incoming
call.
To verify that a CC entity of a UE in CC-state U7, "Call Received", upon request by the user to
Pre-requisites:
The UE is brought into the state U7 by using table10.1.3/1 from 3GPP 34.123
Test procedure:
The user initiates clearing the incoming call. The UE sends a DISCONNECT message.
Test Verification:
Message Flow:
UE NW
1 the UE is made to terminate/reject
the call
2 -> DISCONNECT
Remarks:
After step 1 a UE shall send a DISCONNECT message and enter the CC-state U11, "Disconnect
Request".


E_10.1.3.4.3 Incoming call / U7 call received / DISCONNECT received
Test Purpose:
The call control entity of the UE, being in the state, U7, a DISCONNECT message is received by the
UE.
To verify that a CC entity of a UE in CC-state U7, "Call Received", upon receipt of a DISCONNECT
with a progress indicator indicating in-band information from network, if a DTCH was not assigned,
returns a RELEASE message.
References: TS 24.008 clause 5.4.4..1.1.1
Pre-requisites:
Test Procedure:
The NW sends a DISCONNECT message.
The UE responds with a RELEASE message.
Test Verification:
Message Flow:
UE NW
2 -> RELEASE
NOTE: With a progress indicator indicating in-band information; Progress Indicator, Progress
Description #8.
Remarks:
After step 1 a UE , if a DTCH was not assigned, shall return a RELEASE message and enter the CC-
state U19, "Release Request".


E_10.1.3.4.4 Incoming call / U7 call received / RELEASE received
Test Purpose:
To verify that a CC entity of a UE in CC-state U7, "Call Received", upon receipt of a RELEASE will
return a RELEASE COMPLETE.
References: TS 24.008 clause 5.4.4.3.3
Pre-requisites:
Test Procedure:
The NW sends a RELEASE message. The UE responds with a RELEASE COMPLETE
message.
Test Verification:
Message Flow:
UE NW
connection.
4 -> Void
Remarks:
After step 1 a UE shall return a RELEASE COMPLETE message.


E_10.1.3.4.8 Incoming call / U7 call received / RELEASE COMPLETE received
Test Purpose:
The call control entity of the UE being in the state, U7, the call is cleared by a RELEASE COMPLETE
To verify that a CC entity of the UE in CC-state U7, "Call received", can accept a RELEASE
COMPLETE message with valid cause value.
References: TS 24.008 clause 5.4.2 and clause 5.4.4.1.3
Pre-requisites:
Test Procedure:
connection, the selected service is telephony.
If necessary, the UE is configured for that basic service. The mobile terminated call is initiated.
The CC entity of the UE is brought to U7.
Test Verification:
Message Flow:
UE NW
1 <- RELEASE COMPLETE note 1
connection.
3 -> Void
NOTE 1: With the cause value chosen arbitrarily.
Remarks:


B_10.1.3.5.1 Incoming call / U8 connect request / CONNECT acknowledged
Test Purpose:
The call control entity of the UE, being in the state, U8, a CONNECT ACKNOWLEDGE message is
received by the UE.
To verify that the CC entity of a UE in CC-state U8, "Connect Request", can accept the CONNECT
ACKNOWLEDGE message.
Pre-requisites:
The UE is brought into the state U8 by using table 10.1.3/2.
Test procedure:
If necessary the UE is configured for that basic service. Then a mobile terminated call is
initiated. The CC entity of the UE is brought to the state U8 (if the UE uses immediate
connection for the selected basic service then p = Y, otherwise p = N).
The NW sends a CONNECT ACKNOWLEDGE message.
Test Verification:
Message Flow:
UE NW
A1 Radio Bearer Setup Procedure p = Y, See TS34.108
2 <- CONNECT ACKNOWLEDGE
Remarks:
After step 2 a UE shall enter the CC-state U10, "Call Active".


B_10.1.3.5.8 Incoming call / U8 connect request / DTCH assignment
Test Purpose:
The call control entity of the UE, being in the state, U8, a radio bearer establishment procedure is
performed for traffic channel.
Pre-requisites:
NW is using late assignment procedure
Test procedure:
If necessary the UE is configured for that basic service. Then a mobile terminated call is
Test Verification:
Message Flow:

UE NW
Remarks:
After step 1 the CC-state U8, "Connect Request", shall remain unchanged.


E_10.1.4.1.1 In-call functions / DTMF information transfer / basic procedures
Test Purpose:
To verify that an UE supporting the Mobile originating DTMF protocol control procedure, having a CC
entity for speech in state U10, "Active": when made to send a DTMF tone, sends a START DTMF
message.
To verify that an UE supporting the Mobile originating DTMF protocol control procedure, having a CC
entity for speech in state U10, "Active": when made to send a DTMF tone (the corresponding IA5
character being selected from among the ones supported), sends a START DTMF message
specifying the correct IA5 character in the "keypad information" field of the keypad facility information
element And to verify that acknowledgement sent by the NW is used in the UE to generate a feedback
indication for the successful transmission, if applicable.
To verify that the UE will send a STOP DTMF message to the network.
To verify that the state U10 of the UE CC entity has remained unchanged throughout the test
procedure.
References: TS 24.008 clause 5.5.7.1 clause 5.5.7.2 and clause 5.5.7.3
Pre-requisites:
The UE is brought into the state U10 "Active" for speech by using Generic call setup
procedure for mobile originating circuit switched call defined in TS 34.108.
Test Procedure:
The UE being in the call active state, a user causes a DTMF tone to be generated e.g. by
depression of a key in the UE.
A DTMF digit corresponding to the digit indicated by the user is sent in a START DTMF
message by the UE.
The NW will return a START DTMF ACKNOWLEDGE message to the UE. This
acknowledgement may be used in the UE to generate an indication as a feedback for a
successful transmission.
Then the user indicates that the DTMF sending should cease e.g. by releasing the key. The
UE will send a STOP DTMF message to the network which is acknowledged with STOP
DTMF ACKNOWLEDGE by the NW.
The sequence described above is repeated for each of the applicable characters 0-9, #, *, A,
B, C, and D.
Test Verification:


Message Flow:

UE NW
1 NW Request the user to cause a DTMF
tone to be generated
-> START DTMF the NW will verify that the
transmitted information corresponds
to the digit pressed
2 <- START DTMF ACKNOWLEDGE possible indication of a DTMF tone
3 -> STOP DTMF
4 <- STOP DTMF ACKNOWLEDGE the DTMF tone indication shall be
stopped
5 the steps 1-6 shall be repeated for
each of the applicable characters
0-9, #, *, A, B, C, D.
Remarks:
Upon a user making to send a DTMF tone shall send a START DTMF message on the FACCH to NW.
The NW will verify that the transmitted information corresponds to the digit pressed in the UE.


B_10.1.4.2.1 In-call functions / User notification / UE terminated
Test Purpose:
This is a case for testing user notification procedure terminated by the user equipment.
To verify that a CC entity of a UE in CC-state U10, "active", can accept a NOTIFY.
References: TS 24.008 clause 5.3.1.
Pre-requisites:
The UE is brought into the state U10 "Active" by using table 10.1.2/1.
Test procedure:
The UE being in the call active state, the NW will send a NOTIFY message to the UE.
Test Verification:
Message Flow:
UE NW
1 <- NOTIFY
Remarks:
After step 1 the CC-state U10, "active", shall remain unchanged


E_10.3 User to user signalling
Test Purpose:
The "user to user" information element is used to convey information between the mobile user and a
remote ISDN user.
The purpose of this test is to verify that inclusion of the "user-user" information element in either of the
down link messages, SETUP or DISCONNECT causes no adverse effects on the interaction of the UE
with the NW.
References: TS 24.008 clauses 9.3.7, 9.3.23.1 and 10.5.4.25.
Pre-requisites: .
1 cell, with default parameters. Configurations A,B,C,D,E,F.
The UE is in MM-state "idle updated", with a valid TMSI and CKSN.
Test Procedure:
The NW attempts to set up a mobile terminated call, with one of the supported circuit switched
basic services which has been arbitrarily chosen, the generic call set up procedures for mobile
terminating circuit switched calls,(either speech or data) as specified in TS 34.108 clause 7.
The SETUP message will include the user-user Information Element. The UE shall not
respond adversely to the inclusion of the user-user information element.
After 30 s the NW sends a DISCONNECT message, again the UE shall not respond adversely
to the inclusion of the user-user information element, but shall continue to clear down the call
normally.
Test Verification:
Message Flow:
UE NW
1 Generic Call Setup procedure for
mobile terminating circuit switched
calls defined in TS 34.108,
depending on choice of Bearer
Capability. The SETUP message
contains the user-user IE, see
Specific message contents.
2 The NW waits 30 s.
3 <- DISCONNECT Message contains the user-user IE,
see Specific message contents
4 -> RELEASE
5 <- RELEASE COMPLETE
connection
7 -> Void
SETUP message contains user-user IE with the string coded in IA5 characters: for example "Call
Setup".


DISCONNECT message contains user-user IE with the string coded in IA5 characters: for example
"Call Disconnect".
NOTE: The codings above are for example only. For the case of an UE which supports "user-user"
signalling it may be necessary to add meaning to the data fields.
Remarks:
After step 1 and 3 the inclusion of the "user-user" information element in downlink call control
messages shall cause no adverse effects on the operation of the UE.


B_11.1.1.1 Attach initiated by context activation/QoS Offered by Network is the QoS Requested
Test Purpose:
To check that the UE initiates a PS attach, if one is not already active, when PDP context activation is
requested.
To test the behaviour of the UE when NW responds to the PDP context activation request with the
requested QoS.
Reference: 3GPP TS 24.008 clauses 6.1.3.1 and 6.1.3.1.1.
Pre-requisites:
Network; 1 cell, default parameters
User Equipment; the UE is in GMM-state "GMM-DEREGISTERED, normal service" with valid
P-TMSI and CKSN.
Test Procedure:
If the UE is attached, then the Detach Request is originated from the UE indicating "GPRS detach
without switching off". The network responds with a Detach Accept after completing the security mode
procedures. A PDP context activation is then requested by the user. The PS attach (ATTACH
REQUEST) is then indirectly caused by a requested PDP context activation. The NW returns the
ATTACH ACCEPT message to the UE. Now session management can proceed with PDP context
activation.
On receipt of the ACTIVATE PDP CONTEXT REQUEST message an ACTIVATE PDP CONTEXT
ACCEPT is returned by the NW with the same requested QoS. The contents of the ACTIVATE PDP
CONTEXT REQUEST message shall then be checked. The NW then waits for T3380 seconds to
ensure T3380 has been stopped and no more ACTIVATE PDP CONTEXT REQUEST messages are
sent by the UE.
Test Verification:
Message Flow:

UE NW
1 DETACH REQUEST Only sent if the UE attaches at power-
up, if not go to step 3.
Detach is performed by the UE using
MMI or AT Commands
2 DETACH ACCEPT NW sends Detach Accept message.
3 UE Initiate a context activation
4 ATTACH REQUEST Request attach
5 ATTACH ACCEPT Accept attach
6 ACTIVATE PDP CONTEXT Request a PDP context activation
REQUEST
7 ACTIVATE PDP CONTEXT Accept the PDP context activation
ACCEPT
8 NW Wait for T3380 seconds to ensure no
further activate request messages
come from the UE


Remarks:
When requesting a PDP context activation, the UE shall:

Initiate a PS ATTACH if one is not already active
When the NW responds to a PDP context activation request, initiated by the UE, with the requested
QoS, the UE shall complete the PDP context activation procedure.


E_11.1.1.2.1 QoS offered by the network is a lower QoS / QoS accepted by UE
Test Purpose:
In order to request a PDP context activation, the UE sends an ACTIVATE PDP CONTEXT REQUEST
message to the network, enters the state PDP -ACTIVE-PENDING and starts timer T3380. If the QoS
offered by the network is acceptable to UE, then upon receipt of the message ACTIVATE PDP
CONTEXT ACCEPT, the UE shall stop timer T3380.
The network and the MS shall store the LLC SAPI and the radio priority in the PDP context.
Reference: 3GPP TS 24.008 clause 6.1.3.1.1.
Pre-requisites:
NW: 1 cell, default parameters.
User Equipment: The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-
TMSI and CKSN.
Test procedure:
The requested QoS and Minimum QoS are set. A context activation is requested by the user. On
receipt of the ACTIVATE PDP CONTEXT REQUEST message an ACTIVATE PDP CONTEXT
ACCEPT is returned by the NW with QoS lower than the requested but higher than or equal to the
minimum.
Test Verification:
Message Flow:

UE NW
REQUEST
3 ACTIVATE PDP CONTEXT Accept a PDP context activation
ACCEPT
Check, that the lower QoS is used.
Remarks:
None


E_11.1.1.2.2 QoS offered by the network is a lower QoS / QoS rejected by UE
Test Purpose:
In order to request a PDP context activation, the UE sends an ACTIVATE PDP CONTEXT REQUEST
message to the network.
Upon receipt of the message ACTIVATE PDP CONTEXT ACCEPT offering a QoS which is not
acceptable to the UE, the UE shall initiate the PDP context deactivation procedure.
Reference: 3GPP TS 24.008 clause 6.1.3.1.1.
Pre-requisites:
User Equipment: The UE is in GMM-state "GMM-REGISTERED, normal service" with

valid P-TMSI and CKSN.
Test procedure:
The requested QoS and Minimum QoS are set. A PDP context activation is requested by the user. On
receipt of the ACTIVATE PDP CONTEXT REQUEST message an ACTIVATE PDP CONTEXT
ACCEPT message is returned by the NW with a QoS lower than the minimum. The UE shall then
send a DEACTIVATE PDP CONTEXT REQUEST message. A DEACTIVATE PDP CONTEXT
ACCEPT message will be sent in return by the NW.
Test Verification:
Message Flow:

UE NW
REQUEST
ACCEPT (NW accept with a lower QoS than the
requested minimum.)
REQUEST
ACCEPT
Remarks:
The UE shall reject the QoS offered by the NW in response to a PDP context activation request, if the
QoS is not acceptable to the UE.


B_11.1.2 PDP context activation requested by the network, successful and unsuccessful
Test Purpose:
To test the behaviour of the UE upon receipt of a context activation request from the NW.
Reference: 3GPP TS 24.008 clauses 6.1.3.1.2, 6.1.3.1.4 and 8.3.2.f) and 3GPP TS 27.060 clause
7.3.3.
Pre-requisites:
User Equipment; the UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-
TMSI and CKSN
Test Procedure:
A REQUEST PDP CONTEXT ACTIVATION message is sent by the NW. On receipt of the ACTIVATE
PDP CONTEXT REQUEST message an ACTIVATE PDP CONTEXT ACCEPT message is returned
by the NW. This is repeated until the maximum number of contexts supported by the UE is activated.
If all 256 PDP contexts are supported by the UE (extended TI mechanism in SM allows 256 PDP
contexts), skip to step 7, request PDP context activation for an existing PDP context.
If maximum number of PDP contexts supported by the UE is less than 256, one more context should
be requested by the NW. In response to this activation request the UE shall return a REQUEST PDP
CONTEXT ACTIVATION REJECT message with cause set to 'insufficient resources'.
REQUEST PDP CONTEXT ACTIVATION message is then sent by the NW using currently activated
context transaction identifier. The UE shall activate this context in place of the previous context.
Test Verification:

Verify that the behaviour of the UE upon receipt of a context activation request from the NW.


Message Flow:

UE NW
1 REQUEST PDP CONTEXT NW sends Request a PDP context
ACTIVATION activation to UE
2 ACTIVATE PDP CONTEXT UE replies with a Request PDP context
REQUEST activation
3 ACTIVATE PDP CONTEXT NW accepts the PDP context activation
ACCEPT
4 NW Steps 1-3 are repeated for the number
of Network Initiated contexts supported.
NOTE: If all 256 contexts are
supported steps 5 and 6 should not be
performed.
5 REQUEST PDP CONTEXT NW requests a PDP context activation
ACTIVATION
6 REQUEST PDP CONTEXT The context activation request is
ACTIVATION REJECT rejected with cause 'insufficient
resources'.
7 REQUEST PDP CONTEXT NW requests a PDP context activation
ACTIVATION for an existing context with TI the same
as one of the active PDP contexts
8 UE UE locally deactivates the old PDP
context with the same TI value
9 ACTIVATE PDP CONTEXT UE continues with the activation of a
REQUEST new PDP context to replace
deactivated context
10 ACTIVATE PDP CONTEXT NW accepts the PDP context activation
ACCEPT
Remarks:
The UE that is configured to support one or more PDP contexts simultaneously shall:
accept PDP context activation initiated by the NW if number of active contexts is lower than the
maximum.
locally deactivate the old PDP context when a REQUEST PDP CONTEXT ACTIVATION message is
received, specifying a transaction identifier relating to an active PDP context and continue with the
activation procedure of a new PDP context as indicated in the received message
The UE that does not support PDP Context Activation (a number of active contexts supported by the
UE is equal to maximum or UE does not support PDP context) shall reject PDP context activation
initiated by the NW.


E_11.1.3.1 Abnormal Cases / T3380 Expiry
Test Purpose:
1) On the first expiry of the timer T3380, the UE shall re-send the PDP CONTEXT ACTIVATION
REQUEST.
2) On the second expiry of the timer T3380, the UE shall re-send the PDP CONTEXT
ACTIVATION REQUEST.
3) On the third expiry of the timer T3380, the UE shall re-send the PDP CONTEXT ACTIVATION
REQUEST.
4) On the fourth expiry of the timer T3380, the UE shall re-send the PDP CONTEXT
ACTIVATION REQUEST.
5) On the fifth expiry of the timer T3380, the UE shall release all resources possibly allocated for
this invocation and shall abort the procedure; no automatic PDP context activation re-attempt
shall be performed.
Reference: 3GPP TS 24.008 clause 6.1.3.1.5 a).
Pre-requisites:
User Equipment: The UE is in GMM-state "GMM-REGISTERED, normal service" with
Test procedure:
A PDP context activation is requested by the user. The UE shall send the ACTIVATE PDP CONTEXT
REQUEST message five times with T3380 seconds between each message. After this, no further
ACTIVATE PDP CONTEXT REQUEST messages shall be sent by the UE.
Test Verification:


Message Flow:

UE NW
REQUEST
3 UE T3380 seconds
REQUEST
5 UE T3380 seconds
REQUEST
7 UE T3380 seconds
REQUEST
9 UE T3380 seconds
REQUEST
further ACTIVATE PDP CONTEXT
REQUEST messages are sent by the
UE
Remarks:
None


B_11.1.4.1.1 Successful secondary PDP context activation procedure initiated by the

UE/QoS Offered by Network is the QoS Requested
Test Purpose:
To test the behaviour of the UE when NW responds to a Secondary PDP context activation request
with the requested QoS.
Pre-requisites:
Network; 1 cell, default parameters.
User Equipment; the UE and is in GMM-state "GMM-REGISTERED, normal service" with valid
P-TMSI and CKSN
Test Procedure:
A PDP context activation is requested by the user and accepted by the NW. Secondary PDP context
activation is requested by the user. On receipt of the ACTIVATE SECONDARY PDP CONTEXT
REQUEST message an ACTIVATE SECONDARY PDP CONTEXT ACCEPT is returned by the NW
with the same requested QoS. The NW then waits for T3380 seconds to ensure T3380 has been
stopped and no more ACTIVATE SECONDARY PDP CONREXT REQUEST messages are sent by
the UE.
Test Verification:

Verify that the behaviour of the UE when NW responds to a Secondary PDP context
activation request with the requested QoS.
Message Flow:
UE NW
1 UE Initiate a PDP context activation
2 ACTIVATE PDP CONTEXT Activate a PDP context
REQUEST
3 ACTIVATE PDP CONTEXT Accept the PDP context
ACCEPT
4 UE Initiate a secondary PDP context
activation
5 ACTIVATE SECONDARY PDP Request a Secondary PDP context
CONTEXT REQUEST activation
6 ACTIVATE SECONDARY PDP Accept the Secondary PDP context
CONTEXT ACCEPT activation
come from the UE
Remarks:
To pass the test the UE shall:
When the NW responds to a Secondary PDP context activation request initiated by the UE, with the
requested QoS, the UE shall complete the Secondary PDP context activation procedure.

E_11.1.4.2 Unsuccessful Secondary PDP Context Activation / Activation Initiated by the UE
Test Propose:
Upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REQUEST message, the network may
reject the UE initiated PDP context activation by sending an ACTIVATE SECONDARY PDP
CONTEXT REJECT message to the UE. Upon receipt of an ACTIVATE SECONDARY PDP
CONTEXT REJECT message, the UE shall stop timer T3380 and enter the state PDP-INACTIVE.
Pre-requisites:
User Equipment: The UE and is in GMM-state "GMM-REGISTERED, normal service" with
Test procedure:
A PDP context activation is requested by the user and accepted by the NW. Secondary context
activation is requested by the user. On receipt of the ACTIVATE SECONDARY PDP CONTEXT
REQUEST message from the UE, an ACTIVATE SECONDARY PDP CONTEXT REJECT with cause
#43 'unknown PDP context' is returned by the NW. NW shall wait for T3380 seconds to ensure that the
UE sends no more ACTIVATE SECONDARY PDP CONTEXT REQUEST messages.
Test verification:
Message Flow:
UE NW
REQUEST
ACCEPT
4 UE Initiate a secondary PDP context
activation
5 ACTIVATE SECONDARY PDP Request a Secondary PDP context
CONTEXT REQUEST activation
6 ACTIVATE SECONDARY PDP NW rejects the Secondary PDP context
CONTEXT REJECT activation with cause '#43: unknown
PDP context'
come from the UE
Remarks:
After a secondary PDP context activation being rejected by the network, the UE shall not re-send the
ACTIVATE SECONDARY PDP CONTEXT REQUEST message.


B_11.2.1 Network initiated PDP context modification
Test Purpose:
To test the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT REQUEST message from
NW.
Pre-requisites:
TMSI and CKSN.
Test Procedure:
A PDP context is activated by the user and accepted by the NW. A MODIFY PDP CONTEXT
REQUEST message is then sent to the UE with a QoS that is acceptable to the UE (higher than or
equal to the minimum QoS set in the UE). The UE shall send a MODIFY PDP CONTEXT ACCEPT
message in return. A MODIFY PDP CONTEXT REQUEST message is then sent to the UE with a QoS
that is not acceptable to the UE (lower than the minimum QoS set in the UE). The UE shall send a
DEACTIVATE PDP CONTEXT REQUEST message in return.
Test Verification:

Verify that the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT REQUEST
message from the NW.


Message Flow:

UE NW
2 ACTIVATE PDP CONTEXT Activate the PDP context
REQUEST
ACCEPT
4 MODIFY PDP CONTEXT Request the modification of a PDP
REQUEST (NETWORK TO UE context, with QoS higher than or equal
DIRECTION) to the minimum QoS set in the UE
5 MODIFY PDP CONTEXT Accept the PDP context modification
ACCEPT (UE TO NETWORK
DIRECTION)
REQUEST (NETWORK TO UE context, QoS lower than the minimum
DIRECTION) QoS set in the UE
7 DEACTIVATE PDP CONTEXT Initiate the PDP context deactivation.
REQUEST Cause set to 'QoS not acceptable'
8 DEACTIVATE PDP CONTEXT Accept the PDP context deactivation
ACCEPT
Remarks:
The UE shall:
Accept PDP context modification initiated by the NW if QoS is higher than or equal to the
minimum QoS set in the UE.
Reject PDP context modification initiated by the NW if QoS is lower than the minimum QoS
set in the UE.


B_11.2.2.1 UE initiated PDP context modification/UE initiated PDP context modification accepted
by network
Test Purpose:
To test the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT ACCEPT message from
the network with
- Requested QoS;
- QoS higher than or equal to the minimum QoS set in the UE;
- QoS lower than the minimum QoS set in the UE.
Pre-requisites:
TMSI and CKSN
Test Procedure:
The requested QoS and Minimum QoS are set A PDP context is activated by the user and accepted
by the NW. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT
REQUEST message with new QoS. The NW accepts the context modification and replies with the
MODIFY PDP CONTEXT ACCEPT message with the QoS requested.
Than the UE initiates new PDP context modification with higher QoS. The NW is unable to provide
requested QoS, so it repies by sending MODIFY PDP CONTEXT ACCEPT message with new QoS
that is lower than requested but still acceptable to the UE (higher than or equal to the minimum QoS
set in the UE).
Than the UE initiates new PDP context modification with new QoS. The NW is unable to provide
requested QoS, so it replies by sending MODIFY PDP CONTEXT ACCEPT message with QoS that is
not acceptable to the UE (lower than the minimum QoS set in the UE). The UE shall send a
DEACTIVATE PDP CONTEXT REQUEST message in return and NW shall respond with a
DEACTIVATE PDP CONTEXT ACCEPT message.
Test Verification:

Verify that the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT ACCEPT message
from the network with the requested QoS.
from the network with QoS higher than or equal to the minimum QoS set in the UE
from the network with QoS lower than the minimum QoS set in the UE.


Message Flow:

UE NW
REQUEST
ACCEPT
REQUEST (UE TO NETWORK context, with new QoS
DIRECTION)
ACCEPT (NETWORK TO UE with QoS requested
DIRECTION)
DIRECTION)
ACCEPT (NETWORK TO UE with QoS higher than the minimum QoS
DIRECTION) set in UE
DIRECTION)
ACCEPT (NETWORK TO UE with QoS lower than the minimum QoS
DIRECTION) set in UE
10 DEACTIVATE PDP CONTEXT Initiate the PDP context deactivation.
REQUEST Cause set to QoS not acceptable
ACCEPT
Remarks:
When requesting the PDP context modification, the UE shall:

Modify the PDP context if NW replied with the requested QoS
Modify the PDP context if NW replied with the acceptable QoS
Deactivate the PDP context if NW replied with the QoS not acceptable to UE


E_11.2.2.2 UE initiated PDP Context Modification not accepted by the network
Test Purpose:
Reference: 3GPP TS 24.008 clauses 6.1.3.3, 6.1.3.3.2 and 6.1.3.3.3.
Pre-requisites:
User Equipment: The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-
TMSI and CKSN.
Test procedure:
The requested QoS and Minimum QoS are set. A PDP context is activated by the user and accepted
by the NW. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT
REQUEST message. The NW rejects the context modification and replies with the MODIFY PDP
CONTEXT REJECT with cause set to # 26: insufficient resources.
Test Verification:
Message Flow:

UE NW
REQUEST
ACCEPT
4 MODIFY PDP CONTEXT
REQUEST (UE TO NETWORK
DIRECTION)
5 MODIFY PDP CONTEXT
REJECT
further MODIFY PDP CONTEXT
REQUEST (UE TO NETWORK
DIRECTION) messages are sent by the
UE
7 Check that the context is still active.
Remarks:
None.


B_11.3.1 PDP context deactivation initiated by the UE
Test Purpose:
To test the behaviour of the UE upon receipt of a DEACTIVATE PDP CONTEXT ACCEPT message
from the NW in PDP context deactivation procedure initiated by the UE.
Reference: 3GPP TS 24.008 clauses 6.1.3.4, 6.1.3.4.1.
Pre-requisites:
TMSI and CKSN
Test Procedure:
A PDP context is activated by the user and accepted by the NW. PDP context deactivation is then
requested by the user. The UE shall send a DEACTIVATE PDP CONTEXT REQUEST message to
the NW. The NW shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message. The NW
shall then wait for T3390 seconds to ensure T3390 has been stopped and that no further messages
are sent from the UE.
Test Verification:

Verify that the behaviour of the UE upon receipt of a DEACTIVATE PDP CONTEXT ACCEPT
message from the NW in PDP context deactivation procedure initiated by the UE.
Message Flow:

UE NW
REQUEST
ACCEPT
4 UE Initiate a context deactivation
5 DEACTIVATE PDP CONTEXT Request a deactivation of a PDP
REQUEST context
ACCEPT
further deactivate request messages
are sent
Remarks:
In PDP context deactivation procedure initiated by the UE, upon receipt of a DEACTIVATE PDP
CONTEXT ACCEPT message from the NW, the UE shall deactivate PDP context associated with
given PDP address and TI


B_11.3.2 PDP context deactivation initiated by the network
Test Purpose:
To test the behaviour of the UE upon receipt of a DEACTIVATE PDP CONTEXT REQUEST message
from the NW.
Reference: 3GPP TS 24.008 clauses 6.1.3.4, 6.1.3.4.2.
Pre-requisites:
TMSI and CKSN
Test Procedure:
A PDP context is activated by the user and accepted by the NW. A DEACTIVATE PDP CONTEXT
REQUEST message is then sent by the NW. The UE shall reply with a DEACTIVATE PDP CONTEXT
ACCEPT message.
Test Verification:
Message Flow:

UE NW
REQUEST
ACCEPT
4 DEACTIVATE PDP CONTEXT Request a deactivation of a PDP
REQUEST context
5 DEACTIVATE PDP CONTEXT Accept the PDP context deactivation.
ACCEPT
Remarks:
Upon receipt of a request for deactivation of a PDP context from the NW, the UE shall deactivate PDP
context.


B_12.2.1.1 PS attach / accepted
Test Purpose:
The purpose of this test is to verify normal PS attach procedure is a GMM procedure used by PS UEs
of UE operation mode A or C to IMSI attach for PS services only.
Pre-requisites:
One cell operating in network operation mode II.
The UE has a valid IMSI.
Test procedure:
The UE sends an ATTACH REQUEST message with identity IMSI. The network allocates a P-
TMSI and returns ATTACH ACCEPT message with a P-TMSI. The UE acknowledge the P-TMSI
by sending ATTACH COMPLETE message. Further communication UE - NW is performed by the
new P-TMSI.
The UE sends an ATTACH REQUEST message with identity P-TMSI. The network reallocates a
new P-TMSI and returns ATTACH ACCEPT message with the new P-TMSI. The UE acknowledge
the P-TMSI by sending ATTACH COMPLETE message. Further communication UE - NW is
performed by the new P-TMSI. The UE will not answer signalling addressed to the old P-TMSI.
The UE sends an ATTACH REQUEST message with identity P-TMSI. The network accepts the P-
TMSI and returns ATTACH ACCEPT message without any P-TMSI. Further communication UE -
NW is performed by the old P-TMSI.
Test Verification:
Verify that P-TMSI / P-TMSI signature is allocated

Verify that P-TMSI / P-TMSI signature is reallocated.
Verify that Old P-TMSI / P-TMSI signature is not changed.
Message Flow:

UE NW
1 UE The UE is set in UE operation mode C. If
UE operation mode C not supported, go to
step 26.
2 UE The UE is powered up or switched on and
initiates an attach.
3 -> ATTACH REQUEST Attach type = 'PS attach'
Mobile identity = IMSI
4 <- ATTACH ACCEPT Attach result = 'PS only attached'
Mobile identity = P-TMSI-2
P-TMSI-2 signature
Routing area identity = RAI-1
5 -> ATTACH COMPLETE
8 UE The UE is switched off or power is
removed
9 -> DETACH REQUEST Message not sent if power is removed.
Detach type = 'power switched off, PS
detach'


UE NW
P-TMSI-2 signature
P-TMSI-1 signature
removed
detach'
Mobile identity = P-TMS I-1
P-TMSI-1 signature
21 <- ATTACH ACCEPT No new mobile identity assigned.
P-TMSI and P-TMSI signature not
included.
Attach result = 'PS only attached'
removed.
detach'
26 UE The UE is set in UE operation mode A
and the test is repeated from step 2 to
step 25.
Remarks:
UE shall:
Initiate the PS attach procedure with the information elements specified in the above
Expected Sequence when UE is powered up or switched on.
Perform the following actions depending on the Mobile identity in the ATTACH
REQUEST message and on the Mobile identity in the ATTACH ACCEPT message.
Case 1: The Mobile identity in the ATTACH REQUEST is the IMSI and the Mobile identity in
the ATTACH ACCEPT message is the P-TMSI. UE shall:
Acknowledge the P-TMSI by sending ATTACH COMPLETE message. Further
communication UE - NW is performed by the P-TMSI.
Case 2: The Mobile identity in the ATTACH REQUEST is the P-TMSI and the Mobile identity
in the ATTACH ACCEPT message is the new P-TMSI. UE shall:
acknowledge the new P-TMSI by sending ATTACH COMPLETE message. Further
communication UE - NW is performed by the other P-TMSI.
Case 3: The Mobile identity in the ATTACH REQUEST is the P-TMSI and the Mobile identity
in the ATTACH ACCEPT message is the same P-TMSI. UE shall:
Acknowledge the same P-TMSI by sending ATTACH COMPLETE message. Further
communication UE - NW is performed by the same P-TMSI.


E_12.2.1.2 PS attach / rejected / IMSI invalid / illegal UE
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network rejects a PS attach
procedure with the cause 'Illegal UE'
Pre-requisites:
Three cells (not simultaneously activated), cell A with MCC1/MNC1/LAC1/RAC1 (RAI-1), cell
B in
MCC1/MNC1/LAC2/RAC1 (RAI-3), cell C in MCC2/MNC1/LAC1/RAC1 (RA I-2).
All three cells are operating in network operation mode II (in case of UE operation mode A).
The UE has a valid P-TMSI-1, P-TMSI-1 signature and RAI-1.
Test Procedure:
The network rejects a PS attach with the cause value 'Illegal UE'. The network checks that the
UE does not perform PS attach in the same or another PLMN.
Test Verification:
To test the behaviour of the UE if the network rejects the PS attach procedure of the UE with
the cause 'illegal UE'.
Message Flow:

UE NW
The following messages are sent and shall
be received on cell A.
1 UE The UE is set in UE operation mode C.
2 NW The NW is set in network operation mode
II.
Set the cell type of cell A to the "Serving
cell".
Set the cell type of cell B to the "Off cell".
Set the cell type of cell C to the "Off cell".
(see note)
initiates an attach. Cell A is preferred by
the UE.
P-TMSI-1 signature
5 <- ATTACH REJECT GMM cause = 'Illegal UE'.
be received on cell B.
6 NW Set the cell type of cell A to the "Off cell".
Set the cell type of cell B to the "Serving
cell".
(see note)



UE NW
7 UE Cell B is preferred by the UE.
8 UE No ATTACH REQUEST sent to the NW
(NW waits 30 seconds).
9 UE The UE initiates an attach by MMI or by
AT command.
be received on cell C.
11 NW Set the cell type of cell B to the "Off cell".
Set the cell type of cell C to the "Serving
cell".
(see note)
12 UE Cell C is preferred by the UE.
14 UE The UE initiates an attach by MMI or by
AT command.
16 UE If possible switch off is performed.
17 UE The UE is powered up or switched on.
18 UE Registration on CS See TS 34.108
This is applied only for UE in UE operation
mode A.
Parameter mobile identity is IMSI.
19 UE The UE initiates an attach.
P-TMSI-1 signature
removed.
detach'
NOTE: The definitions for Off cell and Serving cell are specified in TS34.108 clause 6.1
Reference Radio Conditions for signalling test cases only.
Remarks:
At step4, when the UE is powered up or switched on, UE shall:

Initiate the PS attach procedure with the information elements specified in the above message
flow.
At step8, 10, 13 and 15, UE shall:
Not send the ATTACH REQUEST message to the network, even if there is an instruction of
attach request from MMI or from AT command.
At step20, UE shall:
Initiate the PS attach procedure with the information elements specified in the above message
flow.


E_12.2.1.4 PS attach / rejected / PLMN not allowed
Test Purpose:
The purpose of this test is to verify the UEs behaviour when the network rejects a PS attach
procedure with the cause 'PLMN not allowed'.
Pre-requisites 1:
Configuration: C
Four cells (not simultaneously activated), cell A in MCC1/MNC2/LAC1/RAC1 (RAI-8), cell B in
MCC1/MNC2/LAC1/RAC1 (RAI-8), cell C in MCC1/MNC2/LAC2/RAC1 (RAI-9) and cell D in
MCC2/MNC1/LAC1/RAC1 (RAI-2).
All four cells are operating in network operation mode II (in case of UE operation mode A).
The PLMN of the four cells should NOT be that of the UE Home PLMN.
The UE has a valid P-TMSI-1, P-TMSI-1 signature and RAI-8. UE is Idle Updated on cell A.
Test Procedure 1:
The network rejects a PS attach with the cause value 'PLMN not allowed'. The network checks
that the UE does not perform PS attach if activated in the same routing area or location area
and performs PS attach only when a new PLMN is entered.
Test Verification 1:
the cause 'PLMN not allowed'.
Message Flow 1:

UE NW
NW The following messages are sent and shall
1 UE The UE is set in UE operation mode C .
II.
cell".
Set the cell type of cell D to the "Off cell".
(see note)
the UE.
P-TMSI-1 signature
5 <- ATTACH REJECT GMM cause = 'PLMN not allowed'



UE NW
6 UE No ATTACH REQUEST sent to NW
7 UE The UE is switched off.
cell".
(see note)
cell".
(see note)
be received on cell D.
15 NW Set the cell type of cell C to the "Off cell".
Set the cell type of cell D to the "Serving
cell".
(see note)
16 UE Cell D is preferred by the UE.
mode A.
18 UE The UE initiates an attach automatically,
by MMI or by AT command.
P-TMSI-1 signature
removed .
detach'


Pre-requisite 2:
One cell operating in network operation mode II: MCC2/MNC1/LAC1/RAC1 (RAI-2). The
PLMN of the cell should NOT be that of the Mobile Station Home PLMN.
The UE has a valid P-TMSI-1, P-TMSI-1 signature and RAI-2. UE is Idle Updated on cell A.
Test Procedure 2:
The network rejects a PS attach with the cause value 'PLMN not allowed'. The subscribers
access rights is changed to allow PS attach. Then the PLMN from which this rejection was
received is manually selected and the network check that a PS attach is performed.
Message Flow 2:

UE NW
1 UE The UE is set in UE operation mode C or
A.
P-TMSI-1 signature
4 <- ATTACH REJECT GMM cause = 'PLMN not allowed'
(NW waits 30 seconds)
6 UE The current PLMN is selected manually.
mode A.
P-TMSI-1 signature
removed.
detach'


Remarks:
Remarks for test procedure 1

At step4, when the UE is powered on or switched on, UE shall:
Initiate the PS attach procedure with information elements specified in the above message
flow.
At step6, UE shall:
Not perform PS attach procedure.
UE shall perform the following actions depending on the PLMN or the routing area or the location area
Case 1) UE is in the same routing area or location area when the power is switched on,
Case2) UE is in the same PLMN, and this PLMN is not selected manually
Case3) UE is in a new PLMN.
Perform the PS attach procedure.
Remarks for test procedure 2
flow.
At step5, UE shall:
At step9, when the UE is in the new PLMN, and this PLMN is selected manually, UE shall


E_12.2.1.5a PS attach / rejected / roaming not allowed in this location area
Test Purpose:
The purpose of this test is to verify UEs behaviour if the network rejects a PS attach
procedure with the cause roaming not allowed in this location area.
Pre-requisites 1:
Comfiguration: C.
Three cells (not simultaneously activated), cell A in MCC2/MNC1/LAC1/RAC1 (RAI-2, Not
HPLMN), cell B in
MCC2/MNC1/LAC2/RAC1 (RAI-6, Not HPLMN) and cell C in MCC2/MNC1/LAC1/RAC2 (RAI-
7, Not HPLMN).
All three cells are operating in network operation mode II.
Test Procedure 1:
The network rejects a PS attach with the cause value 'Roaming not allowed in this area'. A
new attempt for a PS attach is not possible.
Successful PS attach / detach procedures are performed in another location area. A new
st
attempt for a PS attach is performed in the 1 location area. This attempt shall not succeed,
as the LA is on the forbidden list.
To test that on receipt of a rejection using the 'roaming not allowed in this location area' cause
code, the UE ceases trying to attach on that location area. Successful PS attach procedure is
possible in other location areas.
Message Flow 1:

UE NW
1 UE The UE is set in UE operation mode C . If
UE operation mode C not supported, goto
step 19.
2 NW Set the cell type of cell A to the "Serving
cell".
(see note)
the UE.



UE NW
P-TMSI-1 signature
5 <- ATTACH REJECT GMM cause = 'Roaming not allowed in this
area'
cell".
(see note)
mode A.
P-TMSI-1 signature
14 UE The UE initiates a PS detach (without
power off) by MMI or by AT command.
15 -> DETACH REQUEST Detach type = 'normal detach, PS detach'
16 <- DETACH ACCEPT
cell".
(see note)
The UE is switched off or power is
removed
20 UE UE is switched off.
21 NW Set the cell type of cell C to the "Off cell".
(see note)
22 UE The UE is set in UE operation mode A if
supported and the test is repeated from
step 2 to step 20.


Pre-requisites 2:
One cell in MCC2/MNC1/LAC1/RAC1 (RAI-2, Not HPLMN) operating in network operation

mode II.
Test Procedure 2:
The network rejects a PS attach updating with the cause value 'Roaming not allowed in this
area'. The UE is switched off for 10 s and switched on again. The network check that a PS
attach is possible on the cell on which the PS attach had been rejected.
If USIM removal is possible without switching off: The network rejects a PS attach with the
cause value 'Roaming not allowed in this area'. The USIM is removed and inserted in the UE.
The network check that a PS attach is possible on the cell on which the PS attach had been
rejected.
Test Verfication 2:
To test that if the UE is switched off or the USIM is removed the list of 'forbidden location
areas for roaming' is cleared.
Message Flow 2:

UE NW
1 UE If UE operation mode C is supported, the
UE is set in UE operation mode C . If UE
operation mode C is not supported, the UE
is set in UE operation mode A.
initiates an attach .
2a UE Registration on CS See TS 34.108
mode A.
P-TMSI-1 signature
area'

mode A.
Parameter mobile identity is IMSI
UE NW



P-TMSI-1 signature
removed .
detach'
Pre-requisites 3:
Six cells (not simultaneously activated), cell A in MCC2/MNC1/LAC1/RAC1 (RAI-2, Not

HPLMN), cell B in MCC2/MNC1/LAC2/RAC1 (RAI-3, Not HPLMN), cell C in
MCC2/MNC1/LAC3/RAC1 (Not HPLMN), cell D in MCC2/MNC1/LAC4/RAC1 (Not HPLMN),
cell E in MCC2/MNC1/LAC5/RAC1 (Not HPLMN), cell F in MCC2/MNC1/LAC6/RAC1 (Not
HPLMN).
All six cells are operating in network operation mode II (in case of UE operation mode A).
Test Procedure 3:
The network rejects a PS attach with the cause value 'Roaming not allowed in this area'. This
is done for 6 different location areas. Then the network checks that the UE does not attempt to
perform an attach procedure on the non-allowed location areas.
Different types of UE may use different methods to periodically clear the list of forbidden areas
(e.g. every day at 12am) for roaming. If the list is cleared while the test is being run, it may be
necessary to re-run the test.
To test that at least 6 entries can be held in the list of 'forbidden location areas for roaming'
(the requirement in 3GPP TS 24.008 is to store at least 10 entries. This is not fully tested by
the third procedure).


Message Flow 3:

UE NW
II.
cell".
Set the cell type of cell B to the "Non-
Suitable cell".
Set the cell type of cell C to the "Non-
Suitable cell".
Set the cell type of cell D to the "Non-
Suitable".
Set the cell type of cell E to the "Non-
Suitable cell".
Set the cell type of cell F to the "Non-
Suitable cell".
(see note)
initiates an attach . Cell A is preferred by
the UE.
This is applied only in case of UE
operation mode A.
P-TMSI-1 signature
area'
7 NW Set the cell type of cell A to the "Non-
Suitable cell".
cell".
(see note)
operation mode A.
area'



UE NW
14 NW Set the cell type of cell B to the "Non-
Suitable cell".
cell".
(see note)
mode A.
area'
be received on cell D.
21 NW Set the cell type of cell C to the "Non-
Suitable cell".
Set the cell type of cell D to the "Serving
cell".
(see note)
22 UE Cell D is preferred by the UE.
mode A.
area'
be received on cell E.
28 NW Set the cell type of cell D to the "Non-
Suitable cell".
Set the cell type of cell E to the "Serving
cell".
(see note)
29 UE Cell E is preferred by the UE.
mode A.



UE NW
area'
be received on cell F.
35 NW Set the cell type of cell E to the "Non-
Suitable cell".
Set the cell type of cell F to the "Serving
cell".
(see note)
36 UE Cell F is preferred by the UE.
mode A.
area'
be received on cell E.
42 NW Set the cell type of cell E to the "Serving
cell".
Set the cell type of cell F to the "Non-
Suitable cell".
(see note)
43 NW Cell E is preferred by the UE.
46 NW Set the cell type of cell C to the "Serving
cell".
Set the cell type of cell E to the "Non-
Suitable cell".
(see note)
47 NW Cell C is preferred by the UE.
cell".
Suitable cell".
(see note)
51 NW Cell A will be preferred by the UE.



UE NW
NOTE: The definitions for Non-Suitable cell and Serving cell are specified in TS34.108
Pre-requisites 4:
Two cells, cell A in MCC2/MNC1/LAC1/RAC1 (not HPLMN, RAI-2) and cell B in

MCC1/MNC1/LAC1/RAC1 (HPLMN, RAI-1).
Both cells are operating in network operation mode II (in case of UE operation mode A).
Test Procedure 4:
The network rejects a PS attach with the cause value 'Roaming not allowed in this area A
second cell belonging to the HPLMN is activated. It is checked that the UE returns to its
HPLMN.
To test that if a cell of the Home PLMN is available then the UE returns to it in preference to
any other available cell.


Message Flow 4:

UE NW
II.
cell".
Set the cell type of cell B to the "Suitable
neighbour cell".
(see note)
the UE.
operation mode A.
P-TMSI-1 signature
area'
7 NW Set the cell type of cell A to the "Suitable
neighbour cell".
cell".
(see note)
mode A.
P-TMSI-1 signature
removed .
detach'
NOTE: The definitions for "Suitable neighbour cell" and Serving cell are specified in
TS34.108 clause 6.1 Reference Radio Conditions for signalling test cases only.


Remarks:
Remarks for Test procedure1

flow.
At step6, when the UE receives the ATTACH REJECT message with GMM cause = 'Roaming not
allowed in this area', UE shall:
Not perform the PS attach procedure.
At step11, when the new location area is entered, UE shall:
Perform the PS attach procedure
At step19, when the rejected location area is entered, UE shall
flow.
At step5, after the UE receives the ATTACH REJECT message with GMM cause = 'Roaming not
At step9, when the UE is switched off or USIM is replaced, UE shall:

flow.
At step6, 13, 20, 27, 34 and 41, after the UE receives the ATTACH REJECT message with GMM
cause = 'Roaming not allowed in this area', UE shall:
At step11, 18, 25, 32 and 39 , UE shall:
flow.
At step45, 49 and 53, UE shall:

flow.
At step6, when the UE receives the ATTACH REJECT message with GMM cause = 'Roaming not
At step10, when a new location area is entered, UE shall:


E_12.2.1.10 PS attach / abnormal cases / Failure due to non-integrity protection
Test Purpose:
The purpose of this test is to verify that the UE does not process any layer 3 message if integrity
protection is not activated during the location updat e procedure.
TS 24.008 clauses 4.1.1.1.1.
Pre-requisites:
Test procedure:
The attach procedure is initiated. Upon reception of ATTACH REQUEST message from the
UE, the NW responds to ATTACH ACCEPT message without the integrity protection.
The UE shall ignore this message and re-transmit ATTACH REQUEST message at expiry of
timer T3310.This time the NW starts the authentication procedure and initiates the integrity
protection.
After receiving ATTACH ACCEPT message, the UE shall respond to ATTACH COMPLETE
message.
Test Verification:
To verify that the UE ignores NAS signalling messages when the security mode procedure is
activated without the integrity protection.
Message Flow:

UE NW
1 UE The UE is set in UE operation mode A (see ICS).
2 UE The UE is powered up or switched on and initiates
an attach procedure (see ICS).
3 NW NW checks that the IE Establishment cause in
the received RRC CONNECTION REQUEST
message is set to Registration.
5 <- AUTHENTICATION AND CIPHERING Request authentication.
REQUEST Set PS-CKSN
6 -> AUTHENTICATION AND CIPHERING RES
RESPONSE


7 NW The NW starts the security mode procedure

without the integrity protection. The content of
integrity protection mode info IE in SECURITY
MODE COMMAND message is specified below.
8 <- ATTACH ACCEPT
9 UE The UE ignores ATTACH ACCEPT message.
10 NW The NW waits 15 sec (T3310).
11 -> ATTACH REQUEST The UE re-transmits the message.
The NW verifies that the period of time between
the ATTACH REQUEST messages corresponds
to the value of T3310.
Attach type = 'PS attach'
12 <- AUTHENTICATION AND CIPHERING Request authentication.
REQUEST Set PS-CKSN
13 -> AUTHENTICATION AND CIPHERING RES
RESPONSE
14 The NW starts the security mode procedure with
the integrity protection. The content of integrity
protection mode info IE in SECURITY MODE
COMMAND message is specified below.
Mobile identity = P-TMSI
17 UE The UE is switched off or power is removed (see
ICS).
Detach type = 'power switched off, PS detach'
19 The NW releases the RRC connection.
Remarks:

Initiate the PS attach procedure with information elements specified in the above Expected
Sequence.
At step9, UE shall;
Ignore the first ATTACH ACCEPT message.
At step11, UE shall;
Re-transmit ATTACH REQUEST message after expiry of timer T3310.
At Step16, UE shall;
Respond to ATTACH COMPLETE message after the UE receives the second ATTACH
ACCEPT message.


B_12.2.2.1 Combined PS attach / PS and non-PS attach accepted
Test Purpose:
The purpose of this test is to verify the behaviour of the UE if the network accepts the PS attach
procedure.
Referenc e: 3GPP TS 24.008 section 4.7.3.2.
Pre-requisites:
One cell operating in network operation mode I.
UE has a valid IMSI.
Test procedure:
TMSI and returns ATTACH ACCEPT message with a P-TMSI and a TMSI . The UE acknowledge
the P-TMSI by sending ATTACH COMPLETE message. Further communication UE - NW is
performed by the new P-TMSI. For CS calls, the TMSI is used.
After the initial ATTACH , Depending on the network implementation of P-TMSI allocation algorithm ,
one or both of the following test procedures can be performed:
The UE sends an ATTACH REQUEST message with identity P-TMSI. The network allocates a
new P-TMSI and returns ATTACH ACCEPT message with the new P-TMSI and a new TMSI. The
UE acknowledge the P-TMSI and the TMSI by sending ATTACH COMPLETE message. Further
communication UE - network is performed by the new P-TMSI. For CS calls, the new TMSI is
used.
The UE sends an ATTACH RE QUEST message with identity P-TMSI. The network accepts the P-
TMSI and returns ATTACH ACCEPT message without any P-TMSI. Further communication UE -
network is performed by the previously used P-TMSI.
Test Verification:
Verify that P-TMSI / P-TMSI signature is allocated;
Verify that P-TMSI / P-TMSI signature is reallocated;
Verify that Old P-TMSI / P-TMSI signature is not changed;
Message Flow:

UE NW
1 UE The UE is set in UE operation mode A.
3 -> ATTACH REQUEST Attach type = 'Combined PS / IMSI attach'
Mobile identity =IMSI
TMSI status = no valid TMSI available
4 <- ATTACH ACCEPT Attach result = 'Combined PS / IMSI
attached'
P-TMSI-1 signature
Mobile identity =TMSI -2



UE NW
removed.
Detach type = 'power switched off,
combined PS / IMSI detach'
P-TMSI-1 signature
TMSI status = valid TMSI available
attached'
P-TMSI-2 signature
Mobile identity = TMSI-1
removed.
P-TMSI-2 signature
TMSI status = valid TMSI available
TMSI and P-TMSI not included.
Attach result = 'Combined PS / IMSI
attached'
P-TMSI-3 signature
removed.


Remarks:
UE shall:
Initiate a PS attach procedure with information elements specified in the above Expected
Sequence when UE is powered up or switched on.
Case 1: Network accepts the combined PS attach procedure (signalled by an IMSI) and allocates
a P-TMSI. UE shall:
Acknowledge the P-TMSI and continue communication with the P-TMSI.
Case 2: Network accepts the combined PS attach procedure (signalled by P-TMSI) and
reallocates a new P-TMSI. UE shall:
Acknowledge the new P-TMSI and continue communication with the new P-TMSI.
Case 3: Network accepts the combined PS attach procedure (signalled by a P-TMSI) from the UE
without reallocation of the previously used P-TMSI. UE shall:
Continue communication with the previously used P-TMSI.
Case 4: Network accepts the combined PS attach procedure and determines that TMSI shall be
used in CS operations. UE shall:
Continue communication with the TMSI for CS operations.
Case 5: Network accepts the combined PS attach procedure and determines that a new TMSI
shall be used in CS operations. UE shall:
Continue communication with the new TMSI for CS operations.


E_12.2.2.2 Combined PS attach / PS only attach accepted
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network accepts the
combined PS attach procedure.
Pre-requisites 1:
Test Procedure 1:
TMSI and returns ATTACH ACCEPT message with a P-TMSI. GMM cause 'IMSI unknown in
HLR' is indicated from network. Further communication UE - NW is performed by the P-TMSI.
CS services are not possible.
To test the behaviour of the UE if the network accepts the PS attach procedure with indication
PS only, GMM cause 'IMSI unknown in HLR'.
Message Flow 1:

UE NW


P-TMSI-1 signature
GMM cause = 'IMSI unknown in HLR'
6 <- PAGING TYPE1 Mobile identity = IMSI
Paging order is for CS services.
7 UE The UE shall not initiate an RRC
connection. This is checked during 3
seconds.
removed.
detach'


Pre-requisites 2:

The UE has a valid TMSI, P-TMSI, P-TMSI signature and RAI.
Test Procedure 2:
The UE sends an ATTACH REQUEST message. The network allocates a P-TMSI and returns
ATTACH ACCEPT message with a P-TMSI. GMM cause 'MSC temporarily not reachable',
'Network failure' or 'Congestion' is indicated from network. The cause code is arbitrarily
chosen.
The UE sends a ROUTING AREA UPDATE REQUEST message. The network returns a
ROUTING AREA UPDATE ACCEPT message. GMM cause MSC temporarily not reachable,
Network failure or Congestion is indicated from network. The cause code is arbitrarily
chosen. The ROUTING AREA UPDATE procedure is repeated four times.
An UE operation mode A UE may then perform an MM IMSI attach procedure (according to
the ICS statement). Further communication UE - NW is performed by the P-TMSI. The
existence of a signalling channel is verified by a request for mobile identity.
To test the behaviour of the UE if the network accepts the PS attach procedure with indication
PS only, GMM cause 'MSC temporarily not reachable', 'Network failure' or 'Congestion'.
Message Flow 2:
Dependent whether the option 'Automatic MM IMSI attach procedure for UE operation mode A UE' is
supported or not, the steps 1-22 or 23-53 apply depending on manufacturer.

UE NW
1 UE The UE is set in UE operation mode A and
no automatic MM IMSI attach procedure is
indicated .
Mobile identity =P-TMSI-1
P-TMSI-1 signature
TMSI status = valid TMSI available or IE is
omitted
P-TMSI-2 signature

7 -> ROUTING AREA UPDATE Update type = 'Combined RA / LA
REQUEST updating with IMSI attach'
P-TMSI-2 signature



UE NW
8 <- ROUTING AREA UPDATE No new mobile identity assigned.
ACCEPT P-TMSI not included.
Update result = 'RA updated'
P-TMSI-3 signature
P-TMSI-3 signature
P-TMSI-4 signature
P-TMSI-4 signature
13 NW The NW verifies that the time between the
previous routing area update accept and
routing area update request is T3311.
P-TMSI-5 signature
P-TMSI-5 signature
P-TMSI-6 signature
18-20 (void)
removed .
detach'.
Stop the sequence.


Remarks:
Remarks for Test porpose1

Initiate the Combined PS attach procedure with information elements specified in the above
message flow.
At step7, when the UE receives the paging message for CS domain, UE shall:
Not respond to the paging message for CS domain.
Remarks for Test porpose2
Case 1) UE does not support Automatic MM IMSI attach procedure.
Initiate the Combined PS attach procedure with information elements specified in the above
message flow.
At step7, 10, 12 and 16, when the routing area updating attempt counter is less than 5 and the stored
RAI is equal to the RAI of the current serving cell, UE shall:
Perform the combined routing area update procedure indicating combined RA/LA updating
with IMSI attach.
Case 2) UE supports Automatic MM IMSI attach procedure.


B_12.2.2.3 Combined PS attach / PS attach while IMSI attach
Test Purpose:
The purpose of this test is to verify behaviour of the UE if PS attach performed while IMSI attached.
Pre-requisites:
One cell operating in network operation mode I. ATT flag is set.
UE has a valid TMSI-1, P-TMSI-1, P-TMSI-1 signature and RAI-1.
Test procedure:
The UE is forced to register for CS services but not to PS services.

The network verifies that the UE does not respond to paging messages for PS domain.
UE is triggered to perform the PS attach procedure and the network verifies that it responds to PS
paging messages.
Test Verification:
To verify the behaviour of the UE if PS attach performed while IMSI attached.
Message Flow:

UE NW
and configured not to perform an
automatic PS attach at switch on.
2 UE The UE is powered up or switched on. No
PS attach is performed.
3 Registration on CS See TS 34.108
Location updating type = IMSI attach.
The NW allocates TMSI-1
4 <- PAGING TYPE1 Mobile identity = P-TMSI-1
Paging order is for PS services.
5 UE No response from the UE to the request.
This is checked for 10 seconds.
6 UE The UE is triggered to perform a PS
attach.
7 -> ATTACH REQUEST Attach type = 'PS attach while IMSI
attached'
P-TMSI-1 signature
attached'
No new mobile identity assigned. TMSI
and P-TMSI not included
P-TMSI-2 signature



UE NW
10 -> RRC CONNECTION
REQUEST
11 <- RRC CONNECTION SETUP
12 -> RRC CONNECTION SETUP
COMPLETE
13 -> SERVICE REQUEST service type = "paging response"
14 <- RRC CONNECTION

RELEASE
RELEASE COMPLETE
removed .
Remarks:
UE shall:
Perform the combined PS attach procedure when UE is requested to attach for PS
services.


E_12.2.2.6 Combined PS attach / rejected / PS services not allowed
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network rejects a combined
PS attach procedure with the cause 'PS services not allowed'.
Pre-requisites:
Two cells (not simultaneously activated), cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1) and cell
B in MCC2/MNC1/LAC1/RAC1 (RAI-2).
Both cells are operating in network operation mode I.
The UE has a valid TMSI, P-TMSI-1, P-TMSI-1 signature and RAI-1.
Test Procedure:
The network rejects a normal attach with the cause value 'PS services not allowed'. The
network checks that the UE does not perform PS attach. PS services are not possible. An UE
operation mode A UE shall perform an MM IMSI attach.
Test Verification:
the cause 'PS services not allowed'.
Message Flow:

UE NW
cell".
(see note)
This step is applied only for non-auto
attach UE.
Location Update Procedure initiated from
the UE. Parameter mobile identity is TMSI-
1.
2b UE UE initiates an attach automatically , via
MMI or AT commands.
or 'PS attach while IMSI attached'
P-TMSI-1 signature
4 <- ATTACH REJECT GMM cause 'PS services not allowed'
5 UE An automatic MM IMSI attach procedure is
initiated.



UE NW
Location updating type = IMSI attach.
The NW allocates TMSI-2.
7 <- PAGING TYPE1 Mobile identity = TMSI-2
8 -> RRC CONNECTION
REQUEST
COMPLETE
11 -> PAGING RESPONSE Mobile identity = TMSI-2
12 <- RRC CONNECTION After sending of this message, the NW
RELEASE waits for disconnection of the CS signaling
link.
RELEASE COMPLETE
cell".
(see note)
16 UE A location updating procedure is initiated.
Location updating type = normal.
The NW allocates TMSI-1.
REQUEST
COMPLETE
RELEASE waits for disconnection of the CS
signalling link.
RELEASE COMPLETE
Paging is for PS services
This is checked for 10seconds.
27a UE If switch off is performed then UE performs
IMSI detach procedure.
28 UE The UE is powered up or switched.
This step is applied only for non-auto
attach UE.
Location Update Procedure initiated from
the UE. Parameter mobile identity is TMSI-
1.



UE NW
28b UE UE initiates an attach automatically , via
MMI or AT commands.
attached'
P-TMSI-1 signature
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
removed .
Remarks:

Initiate the combined PS attach procedure with the information elements specified in the
above message flow.
At step6, if the UE is PS class A, UE shall:
Perform the MM IMSI attach procedure.
At step11, 22 and 36, when the UE receives the paging message for CS domain, UE shall:
Respond to the paging message for CS domain by sending the PAGING RESPONSE
message.
At step26, when the UE receives the paging message for PS domain, UE shall:
Not respond to the paging message for PS domain.


E_12.2.2.7a Combined PS attach / rejected / location area not allowed
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network rejects a combined
PS attach procedure with the cause 'location area not allowed'.
Pre-requisites:
Configuration: C.
Three cells (not simultaneously activated), cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B
in MCC1/MNC1/LAC1/RAC2 (RAI-4), cell C in MCC1/MNC1/LAC2/RAC1 (RAI-3).
All cells are operating in network operation mode I.
Test Procedure:
The network rejects a combined PS attach with the cause value 'Location Area not allowed'.
The network checks that the UE does not perform combined PS attach while in the location
area, performs PS attach when a new location area is entered and deletes the list of forbidden
LAs when switched off. CS services are not possible unless an IMSI attach procedure is
performed.
Different types of UE may use different methods to periodically clear the list of forbidden
location areas (e.g. every day at 12am). If the list is cleared while the test is being run, it may
be necessary to re-run the test.
Test Verification:
To test the behaviour of the UE if the network rejects the combined PS attach procedure with
the cause 'Location Area not allowed'.
To test that the UE deletes the list of forbidden LAs when power is switched off.
Message Flow:

UE NW
cell".
Suitable cell".
Suitable cell".
(see note)
2 UE The UE is set in UE operation mode A .
the UE.



UE NW
or
PS Attach while IMSI attached
P-TMSI-1 signature
5 <- ATTACH REJECT GMM cause 'Location Area not allowed'
6 UE No LOCATION UPDATING REQ with type
'IMSI attach' is sent to the NW
7 <- PAGING TYPE1 Mobile identity = TMSI
seconds.
10 -> No response from the UE to the request.
This is checked for 10 seconds
Suitable cell".
cell".
(see note)
11a UE The UE performs cell selection.
13 UE No ATTACH REQUEST or LOCATION
UPDATING REQ is sent to NW
This is checked for 10seconds.
17 UE The UE initiates an attach by MMI or AT
command.
18 No attach is performed by the UE. This is
checked for 10 seconds.
19 NW Set the cell type of cell B to the "Non-
Suitable cell".
cell".
(see note)
19a UE The UE performs cell selection
Step 20a and 20b are only performed by
an UE which will not initiate a PS attach
automatically
20a UE Registration on CS Parameter Mobile identity is IMSI.
Conditi See TS 34.108
onal



UE NW
20b UE UE initiates an attach via MMI or AT
Conditi commands.
onal
attached'
Mobile identity = P-TMSI1
P-TMSI-1 signature
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
REQUEST
COMPLETE
35 -> SERVICE REQUEST Service type = "paging response"
RELEASE
RELEASE COMPLETE
removed .
40 UE Set the cell type of cell B to the "Non-
Suitable cell".
cell".
(see note)
Cell B is preferred by the UE.
42 Step 43 is only performed for non-auto
attach UE.



UE NW
44 UE UE initiates an attach automatically , by
MMI or AT commands.
or PS Attach while IMSI attached
P-TMSI-1 signature
attached'
P-TMSI-2 signature
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
REQUEST
COMPLETE
RELEASE
RELEASE COMPLETE
removed .
NOTE: The definitions for Non-Suitable cell and Serving cell are specified in TS34.108


Remarks:

above message flow
At step6, when the UE receives the ATTACH REJECT message with GMM cause = 'Location Area not
allowed', UE shall:
Not initiate MM location updating procedure.
At step10 and 16, when the UE receives the paging message for PS domain, UE shall:
Not respond to the paging message for PS domain.
At step13 and 18, when the UE is in the same location area, UE shall:
At step21, when the UE enters a new location area, UE shall
Perform the combined PS attach procedure.
At step28 and 52, when the UE receives the paging message for CS domain, UE shall:
message.
At step35 and 59, when the UE receives the paging message for PS domain, UE shall:
Respond to the paging message for PS domain by sending the SERVICE REQUEST
message.
Perform the combined PS attach procedure.


E_12.3.1.1 PS detach / power off / accepted
Test Purpose:
The purpose of this test is to verify that the UE detaches the IMSI for PS services if the UE is
switched off.
Reference: 3GPP TS 24.008 clause 4.7.4.1.
Pre-requisites:
One cell operating in network operation mode II

UE has a valid P-TMSI-1, P-TMSI-1 signature and RAI-1.
Test Procedure:
The UE performs a PS attach procedure.

The UE sends a DETACH REQUEST message to theNW.
Test Verification:
Verify the behaviour of the UE for the detach procedure.


Message Flow:

UE NW
1 UE The UE is set to attach to the PS services only
(see ICS). If that is not supported by the UE,
goto step 8.
initiates an attach (see ICS).
2a NW NW checks that the IE Establishment cause
in the received RRC CONNECTION REQUEST
message is set to Registration.
P-TMSI-1 signature
P-TMSI-2 signature
5a NW The NW releases the RRC connection.
6 UE The UE is switched off
6a NW NW checks that the IE Establishment cause in
the received RRC CONNECTION REQUEST
message is set to Detach.
7 -> DETACH REQUEST Detach type = 'power switched off, PS detach'
7a The SS releases the RRC connection.
8 UE The UE is set to attach to both the PS and non-
PS services and the test is repeated from step
2 to step 7.
Remarks:
At step 2a the UE shall send an RRC CONNECTION REQUEST message with the IE
Establishment cause set to Registration.
Establishment cause set to Detach.
Initiate the PS attach procedure with the information elements specified in the above
Expected Sequence.
At step7, when the UE is switched off, UE shall:

Send the DETACH REQUEST message to NW with the Detach type = 'power
switched off, PS detach'.


B_12.3.1.2 PS detach / accepted
Test Purpose:
The purpose of this test is to verify that the UE detaches the IMSI for PS services if the UE is ordered
to do so with MMI or AT commands.
Pre-requisites:
One cell operating in network operation mode II

Test procedure:
The UE performs a PS attach procedure and activates a PDP context.
The UE sends a DETACH REQUEST message to the NW.
The NW signal to the UE, but no response is received, as the signalling link is disconnected.
Test Verification:
Verify behaviour of the UE for the detach procedure.
Message Flow:

UE NW
step 11.
P-TMSI-1 signature
P-TMSI and P-TMSI signature not
included.
5 (void)
6 UE The UE initiates a PS detach (without
power off) by MMI or AT command.
7 -> DETACH REQUEST Detach type = 'normal detach, PS detach'
8 <- DETACH ACCEPT
11 (void)
step 10.


Remarks:
UE shall:
Initiate a PS attach procedure with the information elements specified in the above
After the PS attach procedure is completed, UE shall:
Sends the DETACH REQUEST message(without power off) to the network.
Start timer T3321.
When UE receives the DETACH ACCEPT message from network before the timer T3321
is not expired, UE shall:
Stop timer T3321.


B_12.3.1.5 PS detach / powered off / accepted / PS/IMSI detach
Test Purpose:
The purpose of this test is to verify that the UE detach the IMSI for PS and non-PS services.
Reference: 3GPP TS 24.008 clause 4.7.4.1.
Pre-requisites:

Test procedure:
The UE performs a combined PS attach procedure (for PS and non-PS services).

The UE sends a DETACH REQUEST message to the NW. The UE then deletes the logical
link.
Test Verification:


Message Flow:

UE NW
1 UE The UE to attach to both the PS and non-
PS services.
initiates an attach
2a NW NW checks that the IE Establishment
cause in the received RRC
CONNECTION REQUEST message is set
to Registration.
attached'
P-TMSI-1 signature
5a NW The NW releases the RRC connection
6 UE The UE is switched off (see ICS).
CONNRECTION REQUEST message is
set to DETACH
7 -> DETACH REQUEST Detach type = 'power switched off,
Remarks:
Establishment cause set to Registration
.
Initiate the combined PS attach procedure with the information elements specified in
the above Expected Sequence.

Send the DETACH REQUEST message to NW with the Detach type = 'power
switched off, combined PS / IMSI detach'.


E_12.3.1.7 PS detach / accepted / IMSI detach
Test Purposes:
The purpose of this test is to verify that the UE shall detach for CS services.
Pre-requisites:
Test Procedure:

The UE performs an PS detach (for non-PS services).
CS services are not possible.
The UE attach for non-PS services by a routing area update procedure and CS services are
again possible.
Test Verification:
To test the behaviour of the UE for the detach procedure.
Message Flow:

UE NW
attached'
P-TMSI-1 signature
6 UE The UE initiates a detach for non-PS
services (without power off) .
7 -> DETACH REQUEST Detach type = 'normal detach, IMSI
detach'
8 <- DETACH ACCEPT
9a -> RRC CONNECTION
REQUEST
9b <- RRC CONNECTION SETUP
9c -> RRC CONNECTION SETUP
COMPLETE



UE NW
10a <- RRC CONNECTION

RELEASE
10b -> RRC CONNECTION
RELEASE COMPLETE
Paging order is for RRC connection.
seconds.
13 UE The UE initiates an attach for non-PS
services by a RA update procedure .
14 -> ROUTING AREA UPDATE Update type = "Combined RA/LA updating
REQUEST with IMSI attach
P-TMSI-1 signature
15 <- ROUTING AREA UPDATE Update result = 'Combined RA/LA
ACCEPT updated''
P-TMSI-2 signature
16 -> ROUTING AREA UPDATE
COMPLETE
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
removed .


Remarks:

above message flow.
At step10, after the detach procedure (Detach type = 'normal detach, IMSI detach') is completed, UE
shall:
message.
At step12, after the detach procedure (Detach type = 'normal detach, IMSI detach') is completed, UE
shall:
Not respond to the paging message for CS.
At step21, after the routing area updating procedure (Update type = 'Combined RA/LA updating') is
completed, UE shall:
message.


B_12.3.2.3 PS detach / IMSI detach / accepted
Test Purpose:
The purpose of this test case is to verify that the UE can detach the IMSI for PS services.
Pre-requisites:
Test procedure:

The network sends a DETACH REQUEST message to the UE. The UE then performs an
IMSI detach (detach for non-PS services).
The network signal to the UE, but no response is received, as the signalling link is
disconnected.
The UE attach for non-PS services by a routing area update procedure. Both PS and CS
services are possible.
Test Verification:
Message Flow:

UE NW
initiates an attach
attached'
P-TMSI-1 signature
6 NW The NW initiates a detach for non-PS
services.
7 <- DETACH REQUEST Detach type = 'IMSI detach'
8 -> DETACH ACCEPT
9 UE The UE initiates an attach for non-PS
services
10 -> ROUTING AREA UPDATE Update type = 'Combined RA/LA updating
REQUEST with IMSI attach'
P-TMSI-1 signature


UE NW
11 <- ROUTING AREA UPDATE Update result = 'Combined RA/LA
ACCEPT updating'
P-TMSI-2 signature
COMPLETE
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
removed
Remarks:
UE shall:
Initiate a combined PS attach procedure with the information elements specified in the
above Expected Sequence when UE is powered up or switched on.
After the completion of the PS attach procedure, UE shall:
Receive DETACH REQUEST message(Detach type = 'IMSI detach') from the network.
Not deactivate the PDP context.
Send the DETACH ACCEPT message to the network.


E_12.3.2.4 PS detach / re-attach requested / accepted
Test Purposes:
The purpose of this test is to verify that the UE shall deactivate the logical link and re-activate
it.
Pre-requisites:
One cell in operating in network operation mode I.
Test Procedure:

The network sends a DETACH REQUEST message to the UE with cause re-attach. The UE
then detaches for PS services. The UE automatically performs a new combined PS attach
procedure (for PS and non-PS services) and PS and CS services are possible.
Test Verification:
To test the behaviour of the UE for the detach procedure in case automatic re-attach.
Message Flow:

UE NW
P-TMSI-1 signature
attached'
No new P-TMSI and P-TMSI signature
assigned
6 NW The NW initiates a detach with re-attach.
7 <- DETACH REQUEST Detach type = 're-attach required'
8 -> DETACH ACCEPT
attached'
P-TMSI-2 signature



UE NW
REQUEST
COMPLETE

RELEASE
RELEASE COMPLETE
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
removed .
Remarks:

above message flow.
At step8, when the UE receives DETACH REQUEST message with Detach type = 're-attach required',
UE shall;
Send DETACH ACCEPT message to the network.
At step9, after UE completed PS detach procedure with Detach type = 're-attach required', UE shall:
Initiate the combined PS attach procedure.
At step13, when the UE receives the paging message for PS domain, UE shall;
message.
message.


B_12.4.1.1 Routing area updating / accepted
Test Purpose:
The purpose of this test is to verify the routing area updating procedure used by PS UEs of UE
operation mode A or C that are IMSI attached for PS services only.
Pre-requisites:
Configuration: C, D, E, F.
Three cells, cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B in
MCC1/MNC1/LAC1/RAC2 (RAI-4), cell C in MCC2/MNC1/LAC1/RAC2 (RAI-7).
Both cells are operating in network operation mode II.
Test procedure:
Depending on the network implementation of P-TMSI allocation algorithm , one or both of the
following test procedures can be performed:
The UE sends a ROUTING AREA UPDATE REQUEST message. The network reallocates the P-
TMSI and returns ROUTING AREA UPDATE ACCEPT message with a new P-TMSI. The UE
acknowledge the new P-TMSI by sending ROUTING AREA UPDATING COMPLETE message.
Further communication UE - NW is performed by the new P-TMSI. The UE will not answer
signalling addressed to the old P-TMSI.
The UE sends a ROUTING AREA UPDATING REQUEST message. The network accepts the P-
TMSI and returns ROUTING AREA UPDATING ACCEPT message without any P-TMSI. Further
communication UE - NW is performed by the P-TMSI.
The UE sends a ROUTING AREA UPDATE REQUEST message. The NW reallocates the P-TMSI
and returns ROUTING AREA UPDATE ACCEPT message with a new P-TMSI. The UE
acknowledge the new P-TMSI by sending ROUTING AREA UPDATE COMPLETE message.
Test Verification:

Verify the behaviour of the UE if the UE enters the new PLMN
Note: Depending on individual networks implementation, PTSMI and TSMI signatures could
change.
Message Flow:

UE NW
1 NW The NW activates cell A.
2 UE The UE is set to attach to PS services
only. If that is not supported by the UE, go
to step 32.
3a NW The NW checks that the IE Establishment


UE NW
to Registration.
P-TMSI-2 signature
Equivalent PLMN: MCC = 2, MNC = 1
NW Activate cell B with a lower signal strength
than cell A The RF level of cell A is
lowered until cell B is preferred by the UE.
to Registration.
8 -> ROUTING AREA Update type = 'RA updating'
UPDATING REQUEST P-TMSI-2 signature
9 <- ROUTING AREA Update result = 'RA updated'
UPDATING ACCEPT Mobile identity = P-TMSI-1
P-TMSI-1 signature
10 -> ROUTING AREA
UPDATING COMPLETE
Void
Void
11c NW The NW releases the RRC connection.
11d <- PAGING TYPE1 Mobile identity = P-TMSI-1
11e NW NW verifies that the UE transmits an RRC
CONNECTION REQUEST message. NW
will reject this request. The IE
Establishment cause is not checked.
12 PAGING TYPE1 Mobile identity = P-TMSI-2

13 UE No response from the UE to the request. This
is checked for 10 seconds.
14 The following messages are sent and shall

NW Set the cell type of cell A to the "Serving cell".
neighbour cell".
(see note)
15 UE Cell A is preferred by the UE.


UE NW
to Registration.
16 -> ROUTING AREA Update type = 'RA updating'
UPDATING REQUEST P-TMSI-1 signature
17 <- ROUTING AREA No new mobile identity assigned.
UPDATING ACCEPT P-TMSI not included.
P-TMSI-1 signature
Paging cause = Terminating interactive

call
19 SERVICE REQUEST service type = "paging response"
19aa NW The NW starts integrity protection.
19a The NW releases the RRC connection.
19b
removed.
to Detach.
detach'
22 UE The UE is set to attach to both the PS and
non-PS services and the test is repeated
from step 3 to step 21.
Remarks:
UE shall:
Initiate a PS attach procedure with the information elements specified in the above Expected
After completing the PS attach procedure, UE shall:,
Initiate a routing area updating procedure with the information elements specified in the above
Expected Sequence when the RF level of the attached cell is lower than the RF level of the
new cell.
Use the P-TMSI which is included in the ROUTING AREA UPDATING ACCEPT message.
Acknowledge the new P-TMSI and continue communication with the new P-TMSI.
Continue communication with the old P-TMSI.


B_12.4.2.1 Combined routing area updating / combined RA/LA accepted
Test Purpose:
The purpose of this test is to verify the behaviour of the UE if the network accepts the combined
routing area updating procedure.
Pre-requisites:
Two cells, cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B in MCC1/MNC1/LAC1/RAC2

(RAI-4).
Test Procedure:
A combined PS attach procedure is performed.

The UE sends a ROUTING AREA UPDATE REQUEST message.
The network reallocates the P-TMSI, de-assigns the TMSI and returns ROUTING AREA
UPDATE ACCEPT message with a new P-TMSI and TMSI
Dependant on the network implementation of P-TMSI /TMSI reallocation algorithm , the P-
TMSI and TMSI re-allocation can or cannot take place. The P-TMSI / TMSI reallocation is
optional as such.
The UE acknowledge the new P-TMSI by sending ROUTING AREA UPDATING COMPLETE
message. Further communication UE - NW is performed by the new P-TMSI. For CS calls, the
TMSI is used
Test Verification:

Note: Depending on individual network implementation, PTSMI and TSMI signatures could change.
Message Flow:

UE NW
attached'
P-TMSI-2 signature
Mobile Identity = TMSI -2
6 NW Activate cell B with a lower signal strength


UE NW
7 -> ROUTING AREA UPDATING Update type = 'Combined RA/LA updating'
REQUEST P-TMSI-2 signature
TMSI status = Valid TMSI available
8 <- ROUTING AREA UPDATING Update result = 'Combined RA/LA
ACCEPT updated'
P-TMSI-1 signature
9 -> ROUTING AREA UPDATING Note : Applicable only if P-TMSI/TMSI
COMPLETE reallocation is done by NW.
REQUEST
COMPLETE

RELEASE
RELEASE COMPLE TE
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE
Remarks:
UE shall:
Initiate a combined PS attach procedure with information elements specified in the above
After completing the PS attach procedure, UE shall:
Initiate a combined routing area update procedure (Update type = 'Combined RA/LA
updating') with the information elements specified above Expected Sequence when RF level
of the attached cell is lower than the RF level of the new cell.
Acknowledge the new P-TMSI.
Continue communication with the new P-TMSI If NW reallocates a P-TMSI.
Continue communication with the old P-TMSI If NW does not reallocate the old P-TMSI.


E_12.4.2.2 Combined routing area updating / UE in CS operation at change of RA
Test Purposes:
The purpose of this test is to verify that PS UE in UE operation mode A that is in an ongoing
CS transaction at change of routing area shall initiate the normal routing area updating
procedure.
Pre-requisites:
Two cells, cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B in MCC1/MNC1/LAC1/RAC2
(RAI-4).
Test Procedure:
A combined PS attach procedure is performed. The UE in UE operation mode A initiates a CS

call. The routing area change.
The UE will perform the normal routing area updating procedure during the ongoing circuit-
switched transaction.
Test Verification:
To test the behaviour of the UE if the routing area is changed during an ongoing circuit
switched transmission.
Message Flow:

UE NW
1 Set the cell type of cell A to the "Serving
cell".
neighbour cell".
(see note)
1a UE The UE is set in UE operation mode A .
attached'
P-TMSI-2 signature
6 UE A CS call is initiated.
7 NW Activate cell B with the same signal
strength as cell A.



UE NW
8 <- Handover commanded by NW on to DCH
of cell B
9 -> ROUTING AREA UPDATE Update type = 'RA updating'
10 <- ROUTING AREA UPDATE Update result = 'RA updated'
ACCEPT Mobile identity = P-TMSI-1
P-TMSI-1 signature
COMPLETE
14 NW The NW initiates the RRC connection

release.
removed .
NOTE: The definitions for "Suitable neighbour cell" and Serving cell are specified in
TS34.108 clause 6.1 Reference Radio Conditions for signalling test cases only.
Remarks:

Initiate the combined PS attach procedure with information elements specified in the above
message flow.
At step9, when the RF level of the attached cell is lower than the RF level of the new cell during the
CS connection, UE shall:
Initiate the normal routing area updating procedure.


E_12.4.2.3 Combined routing area updating / RA only accepted
Test Purposes:
The purpose of this test is to verify the UEs behaviour when the network accepts the
combined PS attach procedure, but GMM cause code 'IMSI unknown in HLR', 'MSC
temporarily not reachable', 'Network failure' or 'Congestion'.
Pre-requisites 1:
Two cells (not simultaneously activated), cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B in
Test Procedure 1:
After attach, the UE sends an ROUTING AREA UPDATE REQUEST message.

The network allocates a P-TMSI and returns ROUTING AREA UPDATE ACCEPT message
with a P-TMSI. GMM cause 'IMSI unknown in HLR' is indicated from the network. Further
communication UE - NW is performed by the P-TMSI. CS services are not possible.
To test the behaviour of the UE if the network accepts the routing area updating procedure
with indication RA only, GMM cause 'IMSI unknown in HLR'.
Message Flow 1:

UE NW
cell".
(see note)
1a UE The UE is set in UE operation mode A .
attached'
P-TMSI-2 signature
cell".
(see note)



UE NW
7 -> ROUTING AREA UPDATE Update type = 'Combined RA/LA updating'
P-TMSI-1 signature
GMM cause = 'IMSI unknown in HLR'
COMPLETE
REQUEST
COMPLETE

RELEASE
RELEASE COMPLETE
seconds.
removed .
detach'
Pre-requisites 2:


Test Procedure 2:
After attach, the UE sends an ROUTING AREA UPDATE REQUEST message . The network
allocates a new P-TMSI signature and returns ROUTING AREA UPDATE ACCEPT message.
GMM cause 'MSC temporarily not reachable', 'Network failure' or 'Congestion' is indicated
from the network. The cause code is arbitrarily chosen.
This procedure is repeated until the routing area updating attempt counter is equal to five. An
UE operation mode A UE may perform an MM IMSI attach procedure (according to the ICS
statement). Further communication UE - NW is performed by the P-TMSI. The existence of a
signalling channel is verified by a request for mobile identity. It is further verified that the UE
after a successful IMSI attach procedure can perform CS services.
To test the behaviour of the UE if the network accepts the routing area updating procedure
with indication RA only, GMM cause 'MSC temporarily not reachable', 'Network failure' or
'Congestion'.
Message Flow 2:
Dependent whether the option 'Automatic MM IMSI attach procedure for UE operation mode A UE' is
not supported or not, the steps 1-13 or 14-35 apply depending on manufacturer.

UE NW
be received on cell A
cell".
(see note)
1a UE The UE is set in UE operation mode A and
no automatic MM IMSI attach procedure is
indicated .
attached'
P-TMSI-2 signature

cell".
(see note)


UE NW
ACCEPT Mobile identity = P-TMSI-1P-TMSI-1
signature
COMPLETE
10 The routing area updating attempt counter
=1. The combined routing area updating
procedure is reinitialised at the expiry of
T3311
11 -> ROUTING AREA UPDATE Update type = Combined RA/LA updating
P-TMSI-1 signature
12 <- ROUTING AREA UPDATE Update result = RA updated
P-TMSI-1 signature
GMM cause = MSC temporarily not
reachable, Network failure or
Congestion (arbitrarily chosen)
COMPLETE
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE
T3311
P-TMSI-1 signature



UE NW
P-TMSI-1 signature
COMPLETE
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE
T3311
removed .
detach'
Stop the sequence.
be received on cell B
29 UE The UE is set in UE operation mode A and
automatic MM IMSI attach procedure is
indicated .
attached'
P-TMSI-2 signature



UE NW
cell".
Set the cell type of cell B to the Suitable
neighbour cell.
(see note)
P-TMSI-1 signature
COMPLETE
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE



UE NW
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE
T3311
P-TMSI-1 signature
P-TMSI-1 signature
COMPLETE
=5.
mode A.
Parameter mobile identity is TMSI-1.
REQUEST
COMPLETE
signalling link.
RELEASE COMPLETE



UE NW
removed .
detach'
Remarks:
Remarks for Test Procedure1

message flow.
At step7, when the RF level of the attached cell is lower than the RF level of the new cell, UE shall:
Initiate the combined routing area updating procedure.
At step9, UE shall:
Acknowledge the new P-TMSI by sending the ROUTING AREA UPDATE COMPLETE
message.
At step11, when the UE receives the paging message for PS domain, UE shall:
message.
Remarks for Test Procedure2
At step3 and 31, when the UE is powered up or switched on, UE shall:
message flow.
At step6 and 35, when the RF level of the attached cell is lower than the RF level of the new cell, UE
shall:
Initiate the combined routing area updating procedure.
Re-initiate the combined routing area updating procedure.
Re-initiate the combined routing area updating procedure.
Perform MM location updating procedure.


B_12.4.3.1 Periodic routing area updating / accepted
Test Purpose:
The purpose of this test is to verify that the User Equipment shall perform a periodic routing area
update procedure after a T3312 timeout.
Reference: 3GPP TS 24.008 sections 4.7.2.2 & 4.7.5.1.
Pre-requisites:
One cell operating in network operation mode II (in case of UE operation mode A).
T3312 is set to 6 minutes.
Test procedure:
The UE initiates a PS attach procedure with identity P-TMSI.

The network reallocates the P-TMSI and returns ATTACH ACCEPT message with a new
P-TMSI and timer T3312. The UE acknowledge the new P-TMSI by sending ATTACH
COMPLETE message.
A routing area updating procedure is performed at T3312 timeout.
Test Verification:
Verify the behaviour of the UE with respect to the periodic routing area updating procedure.
Message Flow:

UE NW
1 NW The UE is set in UE operation mode C If
step 11.
initiates an attach
P-TMSI-1 signature
P-TMSI-2 signature
T3312 = 6 minutes
6 -> ROUTING AREA UPDATING Update type = 'Periodic updating'
7 NW The NW verifies that the time between the
attach and the periodic RA updating is
T3312



UE NW
8 <- ROUTING AREA UPDATING No new mobile identity assigned.
P-TMSI-3 signature
removed
detach'
11 The NW is set in network operation mode
II.
12 UE The UE is set in UE operation mode and
the test is repeated from step 3 to step 10.
Remarks:
UE shall:
Initiate a PS attach procedure with the information elements specified in the above
Set and start the timer T3312 when the ATTACH ACCEPT message and ROUTING
AREA UPDATING ACCEPT message from the network. The value of the timer T3312 is
sent by the network to UE in ATTACH ACCEPT message and ROUTING AREA
UPDATING ACCEPT message.
Initiate a routing area updating procedure with Update type = 'Periodic updating' when the
timer T3312 is expired.


B_12.5 P-TMSI reallocation
Test Purpose:
The purpose of this test is to verify that the User Equipment shall acknowledge a new P-TMSI when
explicitly allocated.
Pre-requisites:
Test procedure:
An explicit P-TMSI reallocation procedure is performed (P -TMSI reallocation command sent from
the network and acknowledged from the UE by P-TMSI reallocation complete).
The UE is PS detached and switched off. Its power supply is interrupted for 10 seconds. The
power supply is resumed and then the UE is switched on.
A PS attach procedure is performed with the given P-TMSI as identity.
Test Verification:
Verify that the UE is able to receive and acknowledge a new P-TMSI by means of an explicit P-
TMSI reallocation procedure.
Verify that the UE has stored the P-TMSI in a non-volatile memory.
Message Flow:

UE NW
1 UE The UE is set in UE operation mode A. If
UE operation mode A not supported set
the UE in operation mode C.
initiates an attach
P-TMSI-1 signature
6 <- P-TMSI REALLOCATION Mobile identity = P-TMSI-2
COMMAND P-TMSI-2 signature
7 -> P-TMSI REALLOCATION
COMPLETE
removed.
detach'



UE NW
10 UE Ensure the power is removed from the UE
for at least 10 seconds
initiates an attach
P-TMSI-2 signature
P-TMSI not included.
P-TMSI-3 signature
15 -> RRC CONNECTION REQUEST
COMPLETE
18 -> SERVICE REQUEST Service type = paging response
19 <- RRC CONNECTION RELEASE

20 -> RRC CONNECTION RELEASE
COMPLETE
21 UE The UE is switched off or power is removed
(see ICS).
Detach type = power switched off, PS detach
Remarks:
UE shall:
Initiate a PS attach procedure with the information elements specified in the above Expected
After completing the PS attach procedure, and when UE receive of the P-TMSI
REALLOCATION COMMAND message, UE shall:
Store the allocated Routing Area Identifier (RAI) and the allocated P-TMSI.
Send P-TMSI REALLOCATION COMPLETE message to the network.
Update P-TMSI in the USIM
Use the given P-TMSI in further communication with the network.


B_12.6.1.1 Authentication accepted
Test Purpose:
The purpose of this test is to verify the user identity.
Pre-requisites:
MCC1/MNC1/LAC1/RAC2 (RAI-4). Both cells are operating in network operation mode II.
Test procedure:
A PS attach is performed, and the network initiates an authentication and ciphering

procedure.
The network checks the value RES sent by the UE in the AUTHENTICATION AND
CIPHERING RESPONSE message.
The UE initiates a routing area updating procedure and the network checks the value of
the PS Ciphering Key Sequence Number sent by the UE in the ROUTING AREA
REQUEST message.
Test Verification:
Verify the behaviour of the UE if the network accepts the authentication and ciphering procedure.
Message Flow:

UE NW
1 NW The NW activates cell A.
step 17.
initiates anattach.
to Registration.
5 <- AUTHENTICATION AND Request authentication.
CIPHERING REQUEST Set PS-CKSN-1
6 -> AUTHENTICATION AND RES
CIPHERING RESPONSE
7 NW The NW checks the RES value and starts
integrity protection..



UE NW
P-TMSI-2 signature
10 NW Activate cell B with a lower signal strength
to Registration.
11 -> ROUTING AREA UPDATING Update type = 'RA updating'
PS-CKSN-1
12 NW The value of PS-CKSN is checked and
Integrity protection is started.
13 <- ROUTING AREA UPDATING Update result = 'RA updated'
P-TMSI-1 signature
14 -> ROUTING AREA UPDATING
COMPLETE
removed
detach'
17 NW Reset the RF level of cell A to default
state. Deactivate cell B.
18 UE The UE is set in UE operation mode and
the test is repeated from step 3 to step 16.
Remarks:
At steps 3a and 10a the UE shall transmit an RRC CONNECTION REQUEST message with
the IE Establishment cause set to Registration.
UE shall:
Sequence when UE is powered on or switched on.
When the UE receives the AUTHENTICATION AND CIPHERING REQUEST message form the
network, UE shall:
Send the AUTHENTICATION AND CIPHERING RESPONSE message with the RES information
field set to the same value as the one produced by the authentication and ciphering algorithm in
the network.


E_12.6.1.2 Authentication rejected by the network
Test Purposes:
The purpose of this test is to verify the UEs behaviour after reception of an Authentication
Reject message from the network.
Reference: 3GPP TS 24.008 sections 4.7.7.
Pre-requisites:
Both cells are operating in network operation mode II.
Test Procedure:
The test sequence is repeated for K = 1, 2.

A complete PS attach procedure is performed. The network rejects the following
authentication and ciphering procedure. The UE is paged with its former P-TMSI and shall not
respond.
The Cell is changed into a new Routing Area.
The network checks that the UE does not perform normal routing area updating.
The network then checks that the UE does not perform a PS detach.
The network checks that the UE does not perform a PS Attach procedure.
Test Verification:
To test the behaviour of the UE if the network rejects the authentication and ciphering
procedure.
Message Flow:

UE NW
cell".
Suitable cell".
(see note)
mode A.
4 <- ATTACH ACCEPT Attach result = PS only attached
P-TMSI-1 signature



UE NW
CIPHERING REQUEST Set PS-CKSN-1
CIPHERING RESPONSE
8 <- AUTHENTICATION AND
CIPHERING REJECT
Suitable cell".
cell".
(see note)
12 UE Cell B is preferred by the MS.
13 UE No ROUTING AREA UPDATE REQUEST
sent to the NW
14 UE If possible the UE initiates an attach by
MMI or by AT command.
16 UE The UE is switched off .
17 NW No DETACH REQUEST sent to the NW
18 The UE is powered up or switched on and
Step 19 is only performed for k =2
19 UE Registration on CS Parameter mobile identity is IMSI.
See TS 34.108
20 -> ATTACH REQUEST Attach type = PS only attached
21 <- ATTACH ACCEPT Attach result = PS attach
P-TMSI-1 signature
removed.
25 UE If k=1 then the test is repeated for k=2.
NOTE: The definitions for Non-Suite cell and Serving cell are specified in TS34.108 clause
6.1 Reference Radio Conditions for signalling test cases only.


Remarks:

flow.
At step9, when the UE receives the AUTHENTICATION AND CIPHERING REJECT message, UE
shall:
Not respond paging message for PS domain.
At step13, when the RF level of the attached cell is lower than the RF level of the new cell, UE shall:
Not perform normal routing area updating.
Not perform PS detach procedure.


E_12.6.1.3.1 GMM cause 'MAC failure'
Test Purposes:
The purpose of this test is to verify that the UEs behaviour after receiving Authentication
Reject message with GMM cause MAC failure.
Pre-requisites:
Configuration: B, C, D, E,
MCC1/MNC1/LAC1/RAC2 (RAI-4). Both cells are operating in network operation mode II.
The MAC (Message Authentication Code) code, which is included in AUTHENTICATION AND
CIPHERING REQUEST, is invalid value.
Test Procedure:
A PS attach is performed, and the network initiates an authentication and ciphering procedure.
The UE sends AUTHENTICATION AND CIPHERING FAILURE message with reject cause
'MAC failure' to the network and starts timer T3214.
The network initiates an identification procedure, upon receipt of a failure message with reject
cause 'MAC failure'.
After the identification procedure is complete, the network re-initiates an authentication and
ciphering procedure.
T3360; set to 6 seconds.
T3318; set to 5 seconds.
Test Verification:
To test the behaviours of the UE, when the UE considers the MAC code (supplied by the core
network in the AUTN parameter) to be invalid.
Message Flow:

UE NW
cell".
(see note)
2 UE The UE is set in UE operation mode C . If
UE operation mode C is not supported,
goto step 25.
3 UE
4 The following messages are sent and shall
Mobility identity = IMSI



UE NW
CIPHERING REQUEST Invalid Message Authentication Code
(MAC).
9 -> AUTHENTICATION AND GMM cause='MAC failure'

CIPHERING FAILURE
10 <- IDENTITY REQUEST Identity type = IMSI
11 -> IDENTITY RESPONSE Mobile identity = IMSI
NW
CIPHERING REQUEST Including PS-CSKN-1
CIPHERING RESPONSE
15 NW The NW checks the RES value.
P-TMSI-2 signature
cell".
(see note)
19 -> ROUTING AREA UPDATE Update type = 'RA updating'
PS-CKSN-1
20 NW The value of PS-CKSN is checked
P-TMSI-1 signature
COMPLETE
removed .
24 -> DETACH REQUEST Message is not sent if power is removed.
detach'
step 24.


Remarks:
Initiate the PS attach procedure with information element specified in the above message flow.
At step9, when the UE receives the AUTHENTICATION AND CIPHERING REQUEST with Invalid
Message Authentication Code, UE shall:
Send the AUTHENTICATION AND CIPHERING FAILURE message with GMM cause 'MAC
failure' to the network
At step11, when the UE receives the IDENTITY REQUEST message with Identity type = IMSI from the
network, UE shall:
Send the IDENTITY RESPONSE message with Mobile identity = IMSI to the network.
At step14, when the UE receives the second AUTHENTICATION AND CIPHERING REQUEST
message (containing a valid MAC) from the network, UE shall:
Send the AUTHENTICATION AND CIPHERING RESPONSE message to the network


B_12.7.1 General Identification
Test Purpose:
The purpose of this procedure is to check that the UE gives its identity as requested by the network.
Reference: 3GPP TS 24.008 section 4.7.8
Pre-requisites:
One cell operating in network mode II.
UE has a valid IMSI and a P-TMSI unknown in network.
Test Procedure:
The network requests identity information from the UE:

- IMSI.
Test Verification:
Verify that the UE sends one or all the following identity information to the network:
-IMSI.
Message Flow:

UE NW
1 NW The UE is set to attach to PS services
to step 14.
initiates an attach
to Registration.
Mobile identity = unknown P-TMSI

5a NW The NW starts ciphering and integrity
protection.
6 <- IDENTITY REQUEST Identity type = IMSI
7 -> IDENTITY RESPONSE Mobile identity = IMSI
8 <- IDENTITY REQUEST Identity type = IMEI
9 -> IDENTITY RESPONSE Mobile identity = IMEI
10 <- IDENTITY REQUEST Identity type = IMEISV
11 -> IDENTITY RESPONSE Mobile identity = IMEISV
11a <- ATTACH ACCEPT Attach result = 'PS only attached'
P-TMSI-1 signature



UE NW
11b -> ATTACH COMPLETE
11c NW The NW releases the RRC connection.
removed
cause in any received RRC
to Detach (message not received if
power is removed).
detach'
14 UE The UE is set to attach to both PS and

non-PS services and the test is repeated
from step 2 to step 13.
Remarks:
UE shall:
Sequence when UE is powered on or switched on.
When the network requests an IMSI with the IDENTITY REQUEST message, UE shall:
Send the IDENTITY RESPONSE message with the Mobile identity = IMSI.


B_12.9.1 Service Request Initiated by UE Procedure
Test Purpose:
The purpose of this test is to verify that the UE can initiate and establish a PS signalling connection for
the upper layer signalling or for the resource reservation for active PDP context(s).
Reference: 3GPP TS 24.008 section 4.7.13 & 3GPP TS 23.060 section 6.12.1.
Pre-requisites:
Test Procedure:
The UE in PMM-IDLE state sends a SERVICE REQUEST message to the network in order to
establish the PS signalling connection for the upper layer signalling.
Test Verification:
Verify the behaviour of the UE if the UE initiates the CM layer service (e.g. SM or SMS) procedure.
Message Flow:

UE NW
to step 12.
to Registration.
3a NW NW starts integrity protection
P-TMSI-1 signature
6 UE The UE initiates an upper-layer signalling,
e.g., Active PDP Context request, by MMI
or by AT command.
6a NW The IE Establishment cause in the
received RRC CONNECTION REQUEST
message is not checked.
7 -> SERVICE REQUEST Service type = "signalling",
UE NW



CIPHERING REQUEST
9 -> AUTHENTICATION AND
CIPHERING RESPONSE
Note: PDP context activation is completed.
9a NW The NW starts integrity protection and
releases the RRC connection.
removed
11 -> DETACH REQUEST Detach type = 'power switched off, PS

detach'
step 11.
Remarks:
When the UE has any signalling message (e.g. for SM or SMS) that requires security protection, the
UE shall:
Send the SERVICE REQUEST message with service type indicated "signalling".


B_12.9.2 Service Request Initiated by Network Procedure
Test Purpose:
The purpose of this test is to verify the UE response after receiving a paging request for PS domain
from the network in PMM-IDLE mode.
Reference: 3GPPTS 24.008 section 4.7.13 and 3GPP TS 23.060 section 6.12.2.
Pre-requisites:
Test Procedure:
The UE is in PMM-IDLE state. The network pages the UE by sending a Paging message to the
UE.
The UE sends a SERVICE REQUEST message to the network. Service Type specifies Paging
Response. The Service Request is carried over the radio in an RRC Direct Transfer message.
After the network receives the SERVICE REQUEST message from the UE, the network
completes the setup procedure.
Test Verification:
Verify the behaviour of the UE if the UE receives the paging request for PS domain service from the
network.
Message Flow:

UE NW
to step 12.
2 UE The UE is powered up or switched in and
to Registration.
3a NW NW starts integrity protection
P-TMSI-1 signature



UE NW
Paging cause = Terminating interactive
call
CONNECTION REQUEST message is
set to Terminating interactive call.
7 -> SERVICE REQUEST Service type = "Paging response"
Note: Setup is completed.
CIPHERING REQUEST
CIPHERING RESPONSE
9a NW NW starts integrity protection and releases
the RRC connection.
step 11.
cause in any received RRC
to Detach (message not sent if power is
removed).
Detach type = 'power switched off, PS detach'
12 UE The UE is set to attach to both PS and non-PS
services and the test is repeated from step 2 to
11.
Remarks:
Establishment cause set to Terminating interactive Call.
When the UE receives a paging request for PS domain from the network in PMM-IDLE mode, the UE
shall:
Send the SERVICE REQUEST message with service type indicated "paging
response".


E_12.9.7a Service Request / rejected / No PDP context activated
Test Purposes
The purpose of this test is to verify that the UE shall deactivate all active PDP contexts and
perform PDP context(s) activation after the network rejects a service request procedure with
the cause "No PDP context activated".
Pre-requisites:
Test Procedure:
The UE sends a SERVICE REQUEST message to the network in order to establish the PS
signalling connection for the upper layer signalling.
After the network receiving the SERVICE REQUEST message, the network sends a
SERVICE REJECT message with the cause value #40 (No PDP context activated).
After the UE receives the SERVICE REJECT message, the UE shall send the ACTIVATE
PDP CONTEXT REQUEST message.
Test Verification:
To test the behaviour of the UE if the network rejects the service request procedure with the
cause "No PDP context activated".
Message Flow:

UE NW
The following message are sent and shall
1 The UE is set in UE operation mode C .
2 The NW is set in network operation mode
II and activates cell A.
3 The UE is powered up or switched on and
the UE.
4 -> ATTACH REQUEST
5 <- ATTACH ACCEPT
7 UE The UE initiates a PS call, by MMI or by
AT command.
8 -> SERVICE REQUEST Service type = "signalling"

CIPHERING REQUEST
CIPHERING RESPONSE
11 NW The NW initiates a security mode control
procedure.



UE NW
12 UE After a PS call is established, the UE
suspends transmission of the user data.
13 NW The NW initiates a Radio Bearer release
procedure.
14 UE The UE resumes the transmission of the
user data.
15 -> SERVICE REQUEST Service type = "data"
16 <- SERVICE REJECT Reject cause = "No PDP context
activated"
17 UE The UE shall deactivate locally all active
PDP contexts.
18 UE The UE initiates a PS call, by MMI or by
AT command.
19 -> ACTIVATE PDP CONTEXT Request a PDP context activation
REQUEST
20 <- ACTIVATE PDP CONTEXT Accept the PDP context activation
ACCEPT
21 UE The UE initiates Deactivate PDP Context
request, by MMI or by AT command.
22 -> DEACTIVE PDP CONTEXT Deactivate PDP context deactivation
REQUEST
23 <- DEACTIVE PDP CONTEXT Accept PDP context deactivation
ACCEPT
24 UE The UE is s witched off or power is removed
(see ICS).
25 UE The UE initiates Detach request, by MMI or by
AT command.
Detach type = power switched off, PS detach
Remarks:

Initiate the PS attach procedure.
When the UE receives a SERVICE REJECT message with the cause "No PDP context activated", UE
shall:
Deactivate all active PDP contexts
Initiate PDP context activation procedure after completing service request procedure


E_12.9.12 Service Request / RAB re-establishment / UE initiated / Single PDP context
Test Purposes:
The purpose of this test is to verify that The UE initiates the re-establishment of RABs by using the
Service Request and a single PDP context when radio coverage is lost
Reference :TS 23.060 clause 9.2.3.9, 9.2.5.2 and TS 24.008 clause 4.7.13
Pre-requisites: Not yet available
Test Procedure: Not yet available
Test Verification:
To verify that the UE initiates a Service request procedure due to uplink data transmission
with one preserved PDP context with traffic class Background.
To verify that the radio access bearer can be re-established for the preserved PDP
context, initiated by the UE.
Message Flow: Not yet available
Remarks: None


E_12.9.13 Service Request / RAB re-establishment / UE initiated / multiple PDP contexts
Test Purposes:
The purpose of this test is to verify that The UE initiates the re-establishment of RABs by using the
Service Request and multiple PDP contexts when radio coverage is lost
Reference: TS 23.060 clause 9.2.3.9, 9.2.5.2 and TS 24.008 clause 4.7.13
Pre-requisites: Not yet available.
Test Procedure: Not yet available.
Test Verification:
To verify that the UE initiates a Service request procedure due to uplink data transmission
with two PDP contexts with different traffic classes are activated.
To verify that the radio access bearers can be re-established with a single radio bearer
establishment procedure for the preserved PDP contexts, when initiated by the UE.
Message Flow: Not yet available.
Remarks: None


E_12.9.14 Service Request / RAB re-establishment / Network initiated / single PDP context
Test Purposes:
The purpose of this test is to verify that the NW shall initiates the re-establishment of RABs when radio
coverage is lost
Reference: TS 23.060 clause 9.2.3.9, 9.2.5.2 and TS 24.008 clause 4.7.13
Pre-requisites: Not yet available.
Test Procedure: Not yet available.
Test Verification:
To verify that the radio access bearers can be re-established for the preserved PDP
context with traffic class Background, when initiated from the network.
Message Flow: Not yet available.
Remarks: Not yet available.


B_13.2.1.1 Emergency call / with USIM / accept case
Test Purposes:
When a USIM is present, subscriber specific emergency call set -up MMI shall be provided. The
operator shall specify preferred emergency call MMI(s) (e.g. 911 for US citizens or 110, 118 and 119
for Japanese citizens) for use in any (i.e. home or visited) PLMN. This shall be stored in the USIM and
the UE shall read this and use any entry of these digits to set up an emergency call. It shall be
possible to store more than one instance of this field.
When a USIM containing stored emergency numbers is present, only those numbers are identified as
emergency numbers, i.e. default emergency numbers stored in the UE are ignored.
Reference: TS 24.008 clause 5.2.1, TS 24.008 clause 4.5.1.5, TS 22.101 clause 8, TS 24.008
clause 5.2.1, TS 24.008 clause 5.2.1.6, TS 24.008, clause 5.4.
Pre-requisites:
default parameters.
the UE is in state "MM idle" with valid TMSI and CKSN.
Test Procedure:
The UE is made to initiate an emergency call.

Having reached the active state, the call is cleared by the NW.
Test Verification:
To verify that an UE supporting speech in the state "MM idle", when made to call the emergency
call number, sends a CM SERVICE REQUEST message specifying the correct CKSN and
TMSI, with CM service type IE "emergency call establishment".
To verify that after security mode setting by the NW, the UE sends an EMERGENCY SETUP
message.
To verify that the NW having sent a CALL PROCEEDING message and then an ALERTING the
correct performance of a connect procedure
and that subsequently the UE has through connected the DTCH in both directions.
To verify that the call is cleared correctly.
Message Flow:

UE NW
1 UE The "called emergency call number" is
entered.
2 --> RRC CONNECTION REQUEST Establishment cause is emergency call
establishment. Establishment cause:
Emergency call.
3 <-- RRC CONNECTION SETUP NW accepts the establishment of a RRC
connection
4 --> RRC CONNECTION SETUP
COMPLETE
5 --> CM SERVICE REQUEST The CM service type IE indicates
"emergency call establishment".
6 <-- AUTHENTICATION REQUEST IE Authentication Parameter AUTN shall be
present in the message.


7 --> AUTHENTICATION RESPONSE SRES specifies correct value.

8 <-- SECURITY MODE COMMAND NW starts deciphering after sending the
message.
9 --> SECURITY MODE COMPLETE Shall be sent enciphered. All following
messages shall be sent enciphered.
10 NW NW starts ciphering.
11 --> EMERGENCY SETUP If the Bearer capability IE is not included the
default UMTS AMR speech version shall be
assumed.
12 <-- CALL PROCEEDING
13 <-- ALERTING
14 <-- RADIO BEARER SETUP The rate of the channel is that one indicated
by the EMERGENCY SETUP message, if
that message did not offer a choice, and the
rate is the preferred one else.
15 --> RADIO BEARER SETUP COMPLETE
16 <-- CONNECT
17 --> CONNECT ACKNOWLEDGE
18 UE The DTCH is through connected in both
directions.
19 <-- DISCONNECT The tester disconnects the call and
associated radio bearer
20 --> RELEASE
21 <-- RELEASE COMPLETE
23 --> RRC CONNECTION RELEASE The main signalling link is released.
COMPLETE
Remarks:
In step 2 of the Expected Sequence the UE shall establish RRC procedure with establishment cause
Emergency Call.
In step 5 of the Expected Sequence the UE shall send a CM SERVICE REQUEST message with CM
service type emergency call establishment.
In step 11 of the Expected Sequence the UE shall send an EMERGENCY SETUP message.
In step 18 of the Expected Sequence the UE has through connected the DTCH in both directions.
In step 19 of the Expected Sequence the call is cleared correctly.


B_13.2.2.1 Emergency call / without USIM / accept case
Test Purpose:
This test is to verify that an emergency call can be established without USIM.
The following emergency numbers shall be stored in the UE for use without USIM: 000, 08, 112, 110,
118, 119, 911 and 999.
Reference :TS 24.008 clause 4.5.1.5, TS 22.101 clause 8, TS33.102 clause 6.4.9.2, TS 24.008 clause
5.2.1.6, TS 24.008 clause 5.4.
Pre-requisites:
default parameters.
the UE is in MM-state "MM idle, no IMSI", no USIM inserted.
Test Procedure:

The call is established without authentication and security
Having reached the active state, the call is cleared by the NW.
Test Verification:
To verify that the UE in the "MM idle, no IMSI" state (no USIM inserted) when made to call the
emergency call number, sends a CM SERVICE REQUEST message in which the
ciphering key sequence number IE indicates "no key is available", the CM service type IE
indicates "emergency call establishment", and the mobile identity IE specifies the IMEI of
the UE.
To verify that after receipt of a CM SERVICE ACCEPT message without security mode
procedure applied from the NW, the UE sends an EMERGENCY SETUP message.
To verify that the NW having sent a CALL PROCEEDING message and then an ALERTING
the
correct performance of a connect procedure.
and that subsequently the UE has through connected the DTCH in both directions.
To verify that the call is cleared correctly.
Message Flow:

UE NW
1 UE The "emergency number" is entered.
One of the following emergency numbers
shall be used: 000, 08, 112, 110, 118, 119,
911 or 999.
2 --> RRC CONNECTION REQUEST Establishment cause is "emergency call".
connection
4 --> RRC CONNECTION SETUP
COMPLETE
"emergency call establishment". The mobile
identity IE specifies the IMEI of the UE. The
cipher key sequence number IE indicates "no
key is available".

7 --> EMERGENCY SETUP If the Bearer capability IE is not included the

default UMTS AMR speech version shall be
assumed.
8 <-- CALL PROCEEDING
9 <-- ALERTING
10 <-- RADIO BEARER SETUP The rate of the channel is one indicated by
the EMERGENCY SETUP message.
11 --> RADIO BEARER SETUP COMPLETE
12 <-- CONNECT
13 --> CONNECT ACKNOWLEDGE
14 UE The DTCH is through connected in both
directions.
15 <-- DISCONNECT The tester disconnects the call and
associated radio bearer
16 --> RELEASE
19 --> RRC CONNECTION RELEASE The main signalling link is released
COMPLETE
Remarks:
In step 2 of the Expected Sequence the UE shall establish RRC procedure with establishment cause
Emergency Call.
In step 5 of the Expected Sequence the UE shall send a CM SERVICE REQUEST message with CM
service type emergency call establishment, mobile identity IMEI and cipher key sequence number
no key is available.
In step 7 of the Expected Sequence the UE shall send an EMERGENCY SETUP message.
In step 14 of the Expected Sequence the UE has through connected the DTCH in both directions.
In step 15 of the Expected Sequence the call is cleared correctly.


B_13.2.2.2 Emergency call / without USIM / reject case
Test Purpose:
This test is to verify that an emergency call without USIM is rejected by the NW, when an invalid IMEI
is used.
The following emergency numbers shall be stored in the UE for use without USIM: 000, 08, 112, 110,
118, 119, 911 and 999.
Reference(s): TS 24.008 clause 4.5.1.5, TS 22.101 clause 8, TS 24.008 clause 4.5.1.5.
Pre-requisites:
default parameters.
the UE is in state "MM idle, no IMSI", no USIM inserted.
Test Procedure:

The call is established without authentication and security
The NW responds to the CM SERVICE REQUEST from the UE with a CM SERVICE REJECT
message specifying in the reject cause IE the reject cause value "IMEI not accepted".
The NW then verifies for during 5 seconds that the UE does not send a layer 3 message.
Then the call is cleared by the NW.
The NW verifies during 20 seconds after disconnection of the main signalling link that the UE
does not initiate a RRC connection establishment.
Test Verification:
To verify that the UE in the "MM idle, no IMSI" state (no USIM inserted) when made to call the
emergency call number, sends a CM SERVICE REQUEST message in which the ciphering
key sequence number IE indicates "no key is available", the CM service type IE indicates
"emergency call establishment", and the mobile identity IE specifies the IMEI of the UE.
To verify that after receipt of a CM SERVICE REJECT message from the NW, the UE
abandons the emergency call establishment.


Message Flow:

UE NW
1 UE The "emergency number" is entered.
One of the following emergency numbers
shall be used: 000, 08, 112, 110, 118, 119,
911 or 999.
2 --> RRC CONNECTION REQUEST Establishment cause is "emergency call".
Establishment cause: Emergency call.
connection
COMPLETE
"emergency call establishment". The mobile
identity IE specifies the IMEI of the UE. The
cipher key sequence number IE indicates "no
key is available".
6 <-- CM SERVICE REJECT the reject cause IE specifies reject cause
value #5, "IMEI not accepted".
7 NW During 5 seconds, the NW verifies that the
UE does not send L3 messages.
9 --> RRC CONNECTION RELEASE The main signalling link is released.
COMPLETE
10 NW During 20 seconds, the NW verifies that the
UE does not initiate a RRC connection
establishment
Remarks:
None


14.1 Radio bearer tests
14.1.1 Generic radio bearer test procedure
Test Purpose:
The purpose of the interoperability radio bearer test cases are to ensure interoperability of UEs in
different regions and networks.
The applicability of radio bearer tests is dependent on the UE uplink and downlink radio access
capabilities and UE support tele- and bearer-services.
Reference: TS 34.108 , clause 6.10 for FDD.
Pre-requisites:

The UE has to have to latest system information
The UE has to have the state to establish a PS or CS session
Test Procedure:
a) The NW set the reference radio bearer configuration as specified in TS 34.108, clause 6.10 for the
actual radio bearer test.
b) The established radio bearer configuration shall be tested by having a call for CS and for PS by
having a PS session
c) The NW may optionally release the radio bearer.
Test Verification:
Verify that the monitored message sequence is correct. The emphasis shall be put on the successful
RAB assingment.
Message Flow:
Expected sequence for CS RAB testing:

UE NW
1 UE An MO call is attempted.
COMPLETE
10 SETUP (CC)
12 RADIO BEARER SETUP Target RRC state is cell_DCH.
14 ALERTING (CC)
15 CONNECT
(CC)
Have call to verify RABs


Expected sequence for PS RAB testing:

UE NW
session
either cell_DCH or
cell_FACH.
or
cell_FACH.
15 Have PS session to verify
RABs
Remarks:
There is a split between testing a CS RAB and a PS RAB.

It is up to the testing parties which kind of radio bearer configuration as specified in 34.108
they may use for testing.


14.1.2 Generic radio bearer test procedure for multi-RB combinations and simultaneous
signalling
Test Purpose:
This procedure is used to test multiple radio bearer combinations. This procedure is also used to verify
simultaneous transmission and reception of user data and signalling data.
Reference: TS 34.108 , clause 6.10 for FDD.
Pre-requisites:
Test Procedure:

Test Verification:
Message Flow:
UE NW

REQUEST Note: Configuration of PS data call depends the
COMPLETE
AUTHENTICATION and
CIPHERING REQUEST
(OPTIONAL)
AUTHENTICATION and
CIP HERING RESPONSE
(OPTIONAL)
COMPLETE
MESSAGE
COMPLETE
ACCEPT
11 Start data transfer Data transfer can be initiated by launching web
12 RRC CONECTION REQUEST UE originates an AMR call



COMPLETE
(OPTIONAL)
17 AUTHENTICATION
RESPONSE (OPTIONAL)
COMPLETE
21 SETUP MESSAGE
22 CALL PROCEEDING
COMPLETE
25 ALERT MESSAGE
26 CONNECT MESSAGE
28 Have call to verify RABs
Have PS session to verify RABs


B_14.2.1 Stand-alone UL:1.7 DL:1.7 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Implicitly tested. For details refer to 14.1.1 Generic radio bearer test procedure.
Test Purpose:
Pre-requisites:
Confi gurations: A, B, C, D, E, F
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.4 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
For details refer to 14.1.1 Generic radio bearer test procedure.
B_14.2.4a Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.5 Conversational / speech / UL:10.2 DL:10.2 kbps / CS RAB + UL:3.4 DL: 3.4 kbps
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.5a Conversational / speech / UL:(10.2, 6.7, 5.9, 4.75) DL:(10.2, 6.7, 5.9, 4.75) kbps / CS
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.7 Conversational / speech / UL:7.4 DL:7.4 kbps / CS RAB+ UL:3.4 DL:3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.7a Conversational / speech / UL:(7.4, 6.7, 5.9, 4.75) DL:(7.4, 6.7, 5.9, 4.75) kbps / CS
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.8 Conversational / speech / UL:6.7 DL:6.7 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.9 Conversational / speech / UL:5.9 DL:5.9 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.12 Conversational / unknown / UL:28.8 DL:28.8 kbps / CS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.13.1 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4 DL:3.4

kbps SRBs for DCCH / 20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:



Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.15 Streaming / unknown / UL:14.4/DL:14.4 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.16 Streaming / unknown / UL:28.8/DL:28.8 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.17 Streaming / unknown / UL:57.6/DL:57.6 kbps / CS RAB + UL:3.4 DL:3.4 kbps

SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.23.1 Interactive or background / UL:32 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH / (TC,10 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
SRBs for DCCH / (TC,20 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


SRBs for DCCH / (CC,10 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
SRBs for DCCH / (CC,20 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.23a.1 Interactive or background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH / CC
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.2.23a.2 Interactive or background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH / TC
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.23b Interactive or background / UL:16 DL:16 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.23c Interactive or background / UL:32 DL:32 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.23d Interactive or background / UL:32 DL:32 kbps / PS RAB (20 ms TTI) + UL:3.4
DL:3.4 kbps SRBs for DCCH.


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.25.1 Interactive or background / UL:32 DL: 64 kbps / PS RAB + UL:3.4 DL:3.4

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:



Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.26 Interactive or background / UL:64 DL: 64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.27 Interactive or background / UL:64 DL:128 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs
for DCCH)


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.28 Interactive or background / UL:128 DL: 128 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.29 Interactive or background / UL:64 DL:144 kbps / PS RAB + UL:3.4 DL: 3.4 kbps SRBs
for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.30 Interactive or background / UL:144 DL:144 kbps / PS RAB + UL:3.4 DL: 3.4
kbps SRBs for DCCH


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.31.1 Interactive or background / UL:64 DL:256 kbps / PS RAB + UL:3.4 DL: 3.4
kbps SRBs for DCCH/ 10 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
kbps SRBs for DCCH/ 20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.32.2 Interactive or background / UL:64 DL:384 kbps / PS RAB / 20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:

Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:

Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38.1 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

background / UL:32 DL:8 kbps / PS RAB / (TC, 20 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
For details refer to 14.1.2 Generic radio bearer test procedure (multi RB).

Test Purpose:
Pre-requisites:
Test Procedure:


Test Verification:
Message Flow:
Remarks:

background / UL:32 DL:8 kbps / PS RAB / (CC, 20 ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38a Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

background / UL:0 DL:0 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:


Test Verification:
Message Flow:
Remarks:
B_14.2.38b Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38c Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38d Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

background / UL:64 DL:64 kbps / PS RAB + Interactive or background / UL:64 DL:64
kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:

Message Flow:
Remarks:
B_14.2.38e Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
RAB + Interactive or background / UL:0 DL:0 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38f Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38g Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:

Test Verification:
Message Flow:
Remarks:
B_14.2.38h Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38i Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.38j Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL:(12.2 7.95 5.9 4.75) kbps / CS
SRBs for DCCH.
Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.40 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

background / UL:64 DL:64 kbps / PS RAB+ UL:3.4 DL: 3.4 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.41 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Interactive or

background / UL:64 DL:128 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:

background / UL:64 DL:256 kbps / PS RAB / 10 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.45 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Streaming / unknown /

UL:57.6 DL:57.6 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.49 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Conversational /

unknown / UL:64 DL:64 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.49a Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL(12.2 7.95 5.9 4.75) kbps / CS
RAB + Conversational / unknown / UL:64 DL:64 kbps / CS RAB+ UL:3.4 DL: 3.4 kbps
SRBs for DCCH (20ms TTI)
Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.49a.1 Conversational / speech / UL:(12.2 7.95 5.9 4.75) DL(12.2 7.95 5.9 4.75) kbps / CS
RAB + Conversational / unknown / UL:64 DL:64 kbps / CS RAB+ UL:3.4 DL: 3.4 kbps
SRBs for DCCH (40ms TTI)
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.49.1 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Conversational /

unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.49.2 Conversational / speech / UL:12.2 DL:12.2 kbps / CS RAB + Conversational /

unknown / UL:64 DL:64 kbps / CS RAB / 40 ms TTI
Test Purpose:


Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.50 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + Conversational / unknown /

UL:64 DL:64 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.50.1 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + Conversational / unknown /

UL:64 DL:64 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH / 20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.50.2 Conversational / unknown / UL:64 DL:64 kbps / CS RAB + Conversational / unknown /

UL:64 DL:64 kbps / CS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH / 40 ms TTI
Test Purpose:


Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.51.1 Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI + Interactive or

background / UL:64 DL:64 kbps / PS RAB
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.51a.1 Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI +

Interactive or Background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH.
Test Purpose:


Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.51a.2 Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 40 ms TTI +

Interactive or Background / UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps
SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.51b.1 Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 20 ms TTI + Interactive or

Background / UL:16 DL:64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.51b.2 Conversational / unknown / UL:64 DL:64 kbps / CS RAB / 40 ms TTI + Interactive or

Background / UL:16 DL:64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:


Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:


Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.56 Interactive or background / UL:8 DL:8 kbps / PS RAB + Interactive or background /

UL:8 DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.57 Interactive or background / UL:64 DL:64 kbps / PS RAB + Interactive or background /

UL:64 DL:64 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:


Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.2.58 Streaming / unknown / UL:16 DL:64 kbps / PS RAB + Interactive or background / UL:8
DL:8 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH.
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

background / UL:64 DL:384 kbps / PS RAB + UL:3.4 DL:3.4 kbps SRBs for DCCH /
10 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

20 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:



10 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:

10 ms TTI
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.1 Stand-alone signalling RB for PCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.4.2.1 One SCCPCH: Interactive/Background 32 kbps PS RAB + SRBs for CCCH + SRB for
DCCH + SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.2.2 Two SCCPCHs: Interactive/Background 32 kbps PS RAB + SRBs for CCCH + SRB
for DCCH + SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.2.3 One SCCPCH/connected mode: Interactive/Background 32 kbps PS RAB + SRBs for

Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.4.2a1 One SCCPCH: Interactive/Background 32 kbps PS RAB + Interactive/Background 32

kbps PS RAB + SRBs for CCCH + SRB for DCCH + SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.2a2 Two SCCPCHs: Interactive/Background 32 kbps PS RAB + Interactive/Background

32 kbps PS RAB + SRBs for CCCH + SRB for DCCH + SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.2a3 One SCCPCH/connected mode: Interactive/Background 32 kbps PS RAB +

Interactive/Background 32 kbps PS RAB + SRBs for CCCH + SRB for DCCH + SRB
for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.4.3 Interactive/Background 32 kbps RAB + SRBs for PCCH + SRB for CCCH + SRB for
DCCH + SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.4.4 RB for CTCH + SRB for CCCH +SRB for BCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_14.5.1 Interactive/Background 32 kbps PS RAB + SRB for CCCH + SRB for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:
B_14.5.2 Interactive/Background 32 kbps PS RAB + Interactive/Background 32 kbps PS RAB +

SRB for CCCH + SRB for DCCH
Test Purpose:
Pre-requisites:
Test Procedure:
Test Verification:
Message Flow:
Remarks:


B_16.1.1 SMS mobile terminated
Test Purpose:
service.
Pre-requisites:
Test Procedure:
Mobile terminates establishment of Radio Resource Connection. After the completion of RRC
Connection NW authenticates UE.
After the NW receives SECURITY MODE COMPLETE, the NW sends a CP -DATA message.
The information element of the CP -DATA message will be RP-DATA RPDU (SMS DELIVER
TPDU).
The NW waits a maximum of 25 s for the CP -ACK message and then a maximum of 60 s for
the CP-DATA message containing the RP-ACK RPDU.
The operator shall clear the stored SMS message manually.
A data or speech call is established on a DTCH with the NW and the state U10 of call control
is entered.
The NW sends a CP-DATA message. The information element of the CP-DATA message will
be RP -DATA RPDU (SMS DELIVER TPDU). The NW waits a maximum of 25 s for the CP-
ACK message and then a maximum of 60 s for the CP-DATA message containing the RP-
ACK RPDU.
Test Verification:

Verify the ability of a UE to receive and decode the SMS where provided for the point to
point service.
Message Flow:

UE NW
1 Mobile terminated See 3GPP TS 34.108
establishment of Radio
Resource Connection
2 --> PAGING RESPONSE
3 <-- AUTHENTICATION REQUEST
4 --> AUTHENTICATION
RESPONSE
5 <-- SECURITY MODE COMMAND
6 --> SECURITY MODE
COMPLETE
9 --> CP-ACK
10 NW Waits max 60 s for RP-ACK RPDU
12 <-- CP-ACK


UE NW
13 UE There should be no further CP-DATA messages
until the UE aborts the RRC connection .
14 UE The UE shall indicate that an SM has arrived.
16 (void)
19 --> CP-ACK
22 <-- CP-ACK
23 <-- DISCONNECT Disconnect the active call
24 --> RELEASE
27 UE Clear the SMS message store
Remarks:
None


B_16.1.2 SMS mobile originated
Test Purpose:
Pre-requisites:
Test Procedure:
The UE shall be set up to send a SM to the NW. The NW responds to RRC CONNECTION
REQUEST by allocating a CCCH. The NW receives RRC CONNECTION SETUP COMPLETE on
DCCH and then performs the authentication.
After receiving SECURITY MODE COMMAND UE shall send SECURITY COMMAND
COMPLETE.
The NW responds to the CP-DATA containing RP-DATA RPDU (SMS SUBMIT TPDU) from the
UE with a CP -ACK message within TC1M followed by a CP-DATA message containing the correct
RP-ACK RPDU. The NW waits a maximum of 25 s for the CP-ACK message.
The NW sends a channel release message to the UE.
A data or speech call is established with the NW and the state U10 of call control is entered. The
UE is set up to send an SM to the NW. After the reception of the CM SERVICE REQUEST, the
NW sends a CM SERV ICE ACCEPT message.
The NW responds to the CP-DATA containing RP-DATA RPDU (SMS SUBMIT TPDU) from the
UE with a CP -ACK message within TC1M followed by a CP-DATA message containing the correct
RP-ACK RPDU. The NW waits a maximum of 25 s for the CP-ACK message. Then the NW sends
a channel release message to the UE.
Test Verification:


Message Flow:

UE NW
REQUEST
COMPLETE

RESPONSE
9 --> SECURITY MODE
COMPLETE
14 --> CP-ACK
RELEASE
RELEASE COMPLETE
19 --> CM SERVICE REQUEST CM service type set to "short message "
25 --> CP-ACK
26 <-- RRC CONNECTION RRC CONNECTION is released.
RELEASE
RELEASE CONPLETE
Remarks:
None


E_16.1.9.1 SMS on CS mode / Multiple SMS mobile originated / UE in idle mode
Test Purpose:
The purpose of this test is to verify the ability of sending multiple short messages on the same RRC
connection when there is no call in progress.
Pre-requisites:

The SMS message storage shall be empty.
Test Procedure:
The UE shall be set up to send 3 short messages as multiple SM to the NW.
Test Verification:

Message Flow:

UE NW
REQUEST
: The NW answers correctly to RRC CONNECTION
: REQUEST on CCCH and then performs the
: authentication.
COMPLETE

RESPONSE
9 --> SECURITY MODE
COMPLETE
and 14 shall be x.
11 <-- CP-ACK
first short message transfer has been received. CM
service type set to "Short message transfer".



UE NW
17 <-- CP-ACK
previous short message transfer. CM service type
set to "Short message transfer".
23 <-- CP-ACK
RELEASE
RELEASE COMPLETE
Remarks:


E_16.1.9.2 SMS on CS mode / Multiple SMS mobile originated / UE in active mode
Test Purpose:
The purpose of this test is to verify the ability of sending concatenated multiple short messages when
there is a call in progress.
Pre-requisites:

Test Procedure:
A data or speech call is established on a DTCH with the NW and the state U10 of call control is
entered.
The UE is set up to send 3 short messages as multiple SM to the NW.
Test Verification:

Message Flow:

UE NW
2 UE The UE is set up to send 3 short messages as
multiple SM
3 --> CM SERVICE REQUEST Sent in a layer 2 frame on the DCCH. CM service
The Transaction Identifier used in steps 7, 8, 9 and
11 shall be x.
8 <-- CP-ACK
first short message transfere has been received.
Sent in a layer 2 frame on the DCCH. CM service
14 <-- CP-ACK



UE NW
previous short message transfer. Sent in a layer 2
frame on the DCCH. CM service type set to "short
message transfer"
20 <-- CP-ACK
RELEASE
RELEASE COMPLETE
Remarks:


E_16.1.10 SMS on CS mode / Test of capabilities of simultaneously receiving a short message

Test Purpose:
Pre-requisites:

Test Procedure:

Test Verification:

Message Flow:

UE NW
REQUEST
COMPLETE

RESPONSE
9 --> SECURITY MODE
COMPLETE


Remarks:
Time values for NW wait times are chosen sufficiently high to be sure that the UE has enough
time to respond to the different messages.


B_16.2.1 SMS mobile terminated
Test Purpose:
service.
Pre-requisites:
Test Procedure:
Mobile terminates establishment of Radio Resource Connection. After the completion of RRC
Connection the NW authenticates the UE and activates ciphering.
After the NW receives SECURITY MODE COMPLETE, the NW sends a CP -DATA message.
The information element of the CP -DATA message will be RP-DATA RPDU (SMS DELIVER
TPDU).
The NW waits a maximum of 25 s for the CP -ACK message and then a maximum of 60 s for
the CP-DATA message containing the RP-ACK RPDU.
The NW sends a CP-ACK to the UE within TC1M with no further CP -DATA messages and the
NW initiates channel release.
The SMS message store shall be cleared manually by the operator.
A PDP context is established with the NW and the state PDP-ACTIVE of session management
is entered.
The NW sends a CP-DATA message. The information element of the CP-DATA message will
be RP -DATA RPDU (SMS DELIVER TPDU). The NW waits a maximum of 25 s for the CP-
ACK message and then a maximum of 60 s for the CP-DATA message containing the RP-
ACK RPDU.
The NW sends a CP-ACK to the UE within TC1M with no further CP -DATA messages and the
NW initiates channel release. The SMS message store shall be cleared manually by the
operator.
Test Verification:


Message Flow:

UE NW
2 --> RRC CONNECTION CCCH Mobile Terminate call
REQUEST
COMPLETE
6 <-- AUTHENTICATION AND
CIPHERING REQUEST
7 --> AUTHENTICATION AND
CIPHERING RESPONSE
9 --> SECURITY MODE
COMPLETE
12 --> CP-ACK
15 <-- CP-ACK
16 UE There should be no further CP-DATA messages
until the UE aborts the RRC connection
(disconnection of layer 2).
18 NW A PDP context is established with the NW and the
state PDP-ACTIVE of session management is
entered.
19 --> ACTIVATE PDP CONTEXT Request a PDP context activation
REQUEST
ACCEPT
23 --> CP-ACK
24 <-- CP-ACK
25 <-- DEACTIVATE PDP CONTEXT Deactivates an existing PDP context.
REQUEST
26 --> DEACTIVATE PDP CONTEXT
ACCEPT
28 UE Clear the SMS message store
Remarks:
None


B_16.2.2 SMS mobile originated
Test Purpose:
Pre-requisites:
Test Procedure:
The UE shall be set up to send a SM to the NW. The NW responds to RRC CONNECTION
REQUEST by allocating a CCCH. The NW receives RRC CONNECTION SETUP COMPLETE
on DCCH and then performs the authentication.
After receiving SECURITY MODE COMMAND, UE shall send SECURITY COMMAND
COMPLETE.
The NW responds to the CP-DATA containing RP-DATA RPDU (SMS SUBMIT TPDU) from
the UE with a CP-ACK message within TC1M followed by a CP-DATA message containing
the correct RP-ACK RPDU. The NW waits a maximum of 25 s for the CP -ACK message.
The NW sends a channel release message to the UE.
A PDP context is established with the NW and the state PDP-ACTIVE of session management
is entered. The UE is set up to send an SM to the NW. After the reception of the SERVICE
REQUEST, the NW sends a SERVICE ACCEPT message.
The NW responds to the CP-DATA containing RP-DATA RPDU (SMS SUBMIT TPDU) from
the UE with a CP-ACK message within TC1M followed by a CP-DATA message containing
the correct RP-ACK RPDU. The NW waits a maximum of 25 s for the CP -ACK message. Then
the NW sends a channel release message to the UE.
Test Verification:


Message Flow:

UE NW
REQUEST
COMPLETE
CIPHERING REQUEST
CIPHERING RESPONSE
9 --> SECURITY MODE
COMPLETE
14 --> CP-ACK
RELEASE
RELEASE COMPLETE
17 NW A PDP context is established with the NW and the
state PDP-ACTIVE of session management is
entered.
20 <-- SERVICE ACCEPT
25 --> CP-ACK
26 <-- RRC CONNECTION RRC CONNECTION is released.
RELEASE
RELEASE COMPLETE
Remarks:
None


E_16.2.10 SMS on PS mode / Test of capabilities of simultaneously receiving a short message

Test Purpose:
Pre-requisites:

The UE shall be in GMM-state "GMM-REGISTERED".
Test Procedure:

Test Verification:

Message Flow:

UE NW
REQUEST
COMPLETE
CIPHERING REQUEST
CIPHERING RESPONSE
9 --> SECURITY MODE
COMPLETE


Remarks:
Time values for NW wait times are chosen sufficiently high to be sure that the UE has enough
time to respond to the different messages.


E_16.3 Short message service cell broadcast
Test Purpose:
The purpose of this test is to verify the transmission of SMS-CB messages.

Reference: 3GPP TS 23.041 section 8 & 3GPP TS 25.324 section 11.
Pre-requisites:

Periodic location updating is disabled.
The UE shall be in the idle updated state.
The UE supports the short message transmission cell broadcast.
Test Procedure:
Three Cell Broadcast (CB) messages are sent by the NW on the CBCH with message codes
0,1,1 in serial number fields respectively.
Test Verification:
Verify that the UE received the messages.

In consequence of test the UE shall ignore the third message and store two messages.
Message Flow:

UE NW
.. .. ..
Remarks:
The SMS-CB messages (BMC) are sent continuously.


B_60.1 Inter system handover to UTRAN/From GSM/Speech/Success
Test Purpose:
To test that UE supporting both GSM and UTRAN handovers to the indicated channel in the UTRAN
target cell when it is in the speech call active state in the GSM serving cell and receives a
INTERSYSTEM TO UTRAN HANDOVER COMMAND.
Pre-requisites:
Configurations: F
Test Procedure:
The NW starts the GSM cell and UTRAN cell with cell selection conditions in favour of GSM cell,
the UE selects the GSM cell for camping on. UTRAN cell broadcasts SIB16 that contains the pre-
configuration for conversational/speech /UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4 DL3.4 kbps
SRBS.
After UE received and stored the SIB16, the NW brings the UE into the call active state (CC state
U10) with FR speech call (for execution counter M = 1).
The NW configures the dedicated channel corresponding to the pre-configuration in UTRAN cell,
and then sends INTERSYSTEM TO UTRAN HANDOVER COMMAND indicating the dedicated
channel of the target cell to the UE through the GSM serving cell.
The above procedure is executed maximum four times, each time for different initial conditions:
If the UE supports GSM FR, the procedure is executed for execution counter M = 1;
If the UE supports GSM EFR, the procedure is executed for execution counter M = 2;
If the UE supports GSM AMR, the procedure is executed for execution counter M = 3;
If the UE supports GSM HR, the procedure is executed for execution counter M = 4.
Test Verification:


Message Flow:
This sequence is performed for a maximum execution counter M = 1, 2, 3, 4, depending on the PIXIT
parameters.

UE NW
1 NW The NW configures GSM and UTRAN cells, UE
camps on GSM cell and receives SIB16 from
UTRAN cell.
2 UE The NW brings the UE into GSM U10 state in cell 1
and
for M = 1: the UE is in GSM FR speech call;
for M = 2: the UE is in GSM EFR speech call;
for M = 3: the UE is in GSM AMR speech call;
for M = 4: the UE is in GSM HR speech call.
3 NW The NW configures the dedicated channel with the
in UTRAN cell.
4 INTERSYSTEM TO UTRAN Send on cell 1 (GSM cell)
HANDOVER COMMAND
contained in the INTERSYSTEM TO UTRAN
HANDOVER COMMAND
synchronization
8 Verify that there is audio on the UL and DL
Remarks:


B_60.2 Inter system handover to UTRAN/From GSM/Data/Same data rate/Success
Test Purpose:
To test that the UE handovers to the indicated UTRAN target cell and the data rate of the target
channel is the same as the old channel when it is in the data call active state in the GSM serving cell
and receives a INTER SYSTEM TO UTRAN HANDOVER COMMAND.
Pre-requisites:
Configurations: F
Test Procedure:
The NW starts the GSM cell and the UTRAN cell. The cell selection conditions of these two
cells are in favour of GSM cell. The UE selects the GSM cell for camping on.
After the UE receives and stores pre-configuration information from SIB16 broadcast in the
UTRAN cell, the NW brings the UE into the call active state (CC state U10) with 14.4 kbps CS
data call (for execution counter M = 1).
(streaming/unknown/UL:14.4 DL:14.4 kbps/CS RAB + UL:3.4 DL3.4 kbps SRBS for M = 1) in
UTRAN cell, then sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating the
dedicated channel of the UTRAN cell.
The above procedure is executed maximum three times, each time for different initial conditions:
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs, the procedure is executed for execution counter M
= 1;
= 2;
= 3;
Test Verification:


Message Flow:

UE NW
1 NW The NW configures GSM and UTRAN cells, the
UTRAN cell broadcasts SIB16 containing pre-
configuration information:
For M = 1: (streaming/unknown/UL:14.4 DL:14.4
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs);
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs).
UE camps on GSM cell and received SIB16 from
UTRAN cell.
2 UE The NW bring the UE into GSM U10 state in cell 1
and
3 NW The NW configures a dedicated channel in the
UTRAN cell with the configuration:
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs)
HANDOVER COMMAND
HANDOVER COMMAND
synchronization.
8 Check data rate on the new UMTS cell is the same
as the rate on the GSM cell.
Remarks:


B_60.3 Inter system handover to UTRAN/From GSM/Data/Data rate upgrading/Success
Test Purpose:
To test that the UE being in the data call active state handovers from the GSM serving cell to the
indicated channel of a higher data rate in the UTRAN target cell after it receives a INTER SYSTEM TO
Reference: 3GPP TS 25.331 Clause 8.3.6, 3GPPTS 04.18 Clause 3.4.4a.
Pre-requisites:
Configurations: F
Test Procedure:
cell. In UTRAN cell SIB16 is broadcast. The UE selects the GSM cell and received the pre-
configuration information from SIB16.
The NW brings the UE into the call active state (CC state U10) with 14.4 kbps CS data call (for
execution counter M = 1).
(streaming/unknown/UL:28.8 DL:28.8 kbps/CS RAB + UL:3.4 DL3.4 kbps SRBS for M = 1), then
sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating the dedicated channel of
the target cell to the UE through the GSM serving cell.
After the UE receives the command it shall configure itself accordingly and switch to the new
The above procedure is executed maximum three times, each time for different conditions:
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs, the procedure is executed for execution counter M = 1;
Test Verification:


Message Flow:

UE NW
1 NW The NW configures GSM and UTRAN cells, the
UTRAN cell broadcasts SIB16 containing pre-
configuration information:
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs).
UE camps on GSM cell and received SIB16 from
UTRAN cell.
2 UE The NW brings the UE into GSM U10 state in cell 1
and
3 NW The NW configures a dedicated channel in the
UTRAN cell with the configuration:
kbps/CS RAB + UL:3.4 DL3.4 kbps SRBs)
HANDOVER COMMAND
HANDOVER COMMAND
synchronization
8 Check that UE transfers data at the new data rate
in UMTS cell.
Remarks:


E_60.4 Inter system handover to UTRAN/ From GSM/Speech/Establishment/Success
Test Purpose:
The purpose of this test is to verify handovers from the GSM serving cell to the indicated channel in
UTRAN target cell when the MS is in the call establishment phase and receives a INTER SYSTEM TO
section 26.6.5.1 & 3GPP TS 34.108 section 6.2.
Pre-requisites:
Configuration: F
Test Procedure:
The NW starts GSM cell and UTRAN cell with the cell selection conditions in favour of GSM
cell.
The MS selects the GSM cell.
After the MS camps on the GSM cell and received SIB16 broadcast in the UTRAN cell, the MS
is triggered to make an MO speech call.
After the NW received SETUP message it configures a dedicated channel corresponding to the
predefined configuration (conversationa/speech/UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4 DL3.4
kbps SRBS) described by SIB16.
Then the NW sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating the
dedicated channel to the MS through the GSM serving cell.
After the MS receives the command and it shall configure itself accordingly and switch to the
new channel of UTRAN cell.
The NW checks whether the handover is performed by checking that the MS transmits
Test Verification:

Verify that after step 11 the ongoing call is continued on UTRAN cell.


Message Flow:

UE NW
1 NW The NW configures GSM and UTRAN cells, MS
camps on GSM cell and received SIB16 from
UTRAN cell.
2 MS To trigger MS to make an MO call
3 CHANNEL REQUEST initiate outgoing call
4 IMMEDIATE ASSIGNMENT SDCCH, U0
5 CM SERVICE REQUEST U0.1
6 SETUP U1
7 NW The NW configures a dedicated channel with the
in UTRAN cell.
HANDOVER COMMAND
HANDOVER COMMAND
synchronization
11 HANDOVER TO UTRAN The NW receives this message on DCCH of the
COMPLETE UTRAN cell. It implies that the down link physical
12 Check data transfer on UMTS Cell
Remarks:
None.


B_60.5 Inter system handover to UTRAN/From GSM/Speech/Blind HO/Success
Test Purpose:
To test that the UE handovers from the GSM serving cell to the indicated channel of UTRAN target
cell when it is in the speech call active state without any knowledge of the target system (blind
handover) and receives a INTER SYSTEM TO UTRAN HANDOVER COMMAND.
Pre-requisites:
Configurations: F
Test Procedure:
cell, SIB16 is not broadcast in the UTRAN cell and the UE does not have any predefined
configuration stored. The UE selects the GSM cell.
The NW brings the UE into the call active state (CC state U10) with FR speech. The NW
configures a dedicated channel (conversational/speech/UL:12.2 DL:12.2 kbps/CS RAB + UL:3.4
DL3.4 kbps SRBS), then sends INTER SYSTEM TO UTRAN HANDOVER COMMAND indicating
the dedicated channel of the target cell to the UE through the GSM serving cell.
Test Verification:


Message Flow:

UE NW
1 UE The NW bring the UE into GSM U10 state in cell 1
and the UE has no any pre-configuration
information stored
2 NW The NW configures dedicated channel with the
in UTRAN cell.
HANDOVER COMMAND
HANDOVER COMMAND
synchronization
7 Check for voice on UL and DL while UE is in the
new UMTS cell.
Remarks:


E_60.6 Inter system handover to UTRAN/ From GSM/Speech/Failure
Test Purpose:
The purpose of this test is to verify the reactivation of the old channels and the transmission of
HANDOVER FAILURE message to the network on the old channel in the GSM cell when the INTER
SYSTEM TO UTRAN HANDOVER COMMAND and the handover to UTRAN fails.
section 26.6.5.1 & 3GPP TS 34.108 section 6.1
Pre-requisites:
Configuration: F
Test Procedure:
cell.
SIB16 is broadcast in UTRAN cell.
The NW brings the MS into the call active state (CC state U10) with FR speech call.
The NW does not configure the dedicated channel corresponding to the predefined
configuration described in SIB16 (conversationa/speech/UL:12.2 DL:12.2 kbps/CS RAB +
UL:3.4 DL3.4 kbps SRBS), then sends INTER SYSTEM TO UTRAN HANDOVER COMMAND
indicating the dedicated channel of the target cell to the MS through the GSM serving cell.
Test Verification:

Verify that the handover is failed by checking that the MS returns to the old channel and
transmits HANDOVER FAILURE to the NW through the old channel.


Message Flow:

UE NW
1 NW The NW starts GSM and UTRAN cells, SIB16 is
broadcast in the UTRAN cell. The MS camps on
GSM cell and received SIB16.
2 MS The NW bring the MS into GSM U10 state in cell
1
3 NW There is no dedicated channel with the
in UTRAN cell.
HANDOVER COMMAND
HANDOVER COMMAND
6 MS The MS fails to establish a connection to UTRAN
cell
7 HANDOVER FAILURE The NW receives this message on DCCH of GSM
cell (old channel)
Remarks:
None.


Document History
Version Date Comments

th
0.0.1 November 14 , 2001 Initial version
th
0.0.2 December 05 , 2001 Initial version containing test cases
th st
0.0.3 December 17 , 2001 1 Draft of one-liner section
th st
1.0.0 December 27 , 2001 1 released version of MTC (One- liner only)
th
1.0.1 January 24 , 2002 Correction of the prioritisation of the One- liner
th
1.0.2 March 25 , 2002 Addition of Base Test cases/ except Supplementary Service
th
2.0.0 May 16 , 2002 Slight changes of the scope
th
3.0.0 December 18 , 2002 Addition of Extension Test cases and aligment to 3GPP
March 02 version/ incorporating of review comments
th
3.0.98 June 24 , 2003 Aligment to the June 02 version of the test specifications and
addition of functional test cases
rd
3.0.99 October 3 , 2003 Incorporation of review results
th th
3.1.0 October 24 , 2003 Incorporation of review results from Rome meeting on the 9
th
and 10 of October 2003
th
3.2.0d1 August 8 , 2004 Aligment to the March 03 version of the core specifications
(June 03 of the test specifications) and addition of functional
test cases (incl. review results)
Draft for release
3.3.0d1 December 3th, 2004 Added: F_6.1.1.8, F6.11.1-F6.11.6, F6.4.19-F6.4.21
Still Open:
Configuration H, InterRAT testcases
update protocol tests to Rel 99 Jun03
3.3.0d2 December 23th, 2004 Added
F_6.7.7-6.7.12 InterRAT Cell Reselection
F_6.1.2.21-6.1.2.24 Cell Reselection
Updated (3GPP Jun03 test spec), B_xxx, E_xxx
8.1.1.1, 8.1.1.4, 8.1.1.7, 8.1.2.1, 8.1.9, 8.2.1.4, 8.2.5.1
9.1, 9.2.1, 9.3.1, 9.3.1.4.1, 9.3.2, 9.4.1
11.2.2.1, 11.2.2.2
12.5, 12.9.7.a
Still Open:
Jun03 chapter 16, 60 (SAG)
InterRAT HO (SAG)
Config H (SAG)
th
3.3.0 January 27 , 2005 Baselined after review
th
4.1.0d1 February 7 , 2005 Updated
F_6.2.1-F_66.2.5, F_6.2.8-F_6.2.9 CS Call
F_6.4.2, F_6.4.7-F_6.4.12 Multi Service Call
F_6.5.1.1-F_6.5.1.6 Open Loop Power Control
F_6.5.2.1-F_6.5.2.7 Inner Loop Power Control
Added
F_6.5.1.1a, F_6.5.1.2a, F_6.5.1.4a, F_6.5.1.5a,
F_6.5.1.6a Open Loop Power Control TDD
F_6.5.2.3a, F_6.5.2..5a Inner Loop Power Control TDD
th
4.1.0 March 15 , 2005 Baselined after review


Version Date Comments

th
5.0.0d1 February 16 , 2005 Added
F_6.12 HSDPA
Only oneliner available:
F_6.12.1.1 F_6.12.1.2; F_6.12.2.1 F_6.12.2.4;
F_6.12.5.1.3 F_6.12.5.1.6; F_6.12.5.2.3
F_6.12.5.2.6; F_6.12.5.3.3 F_6.12.5.3.6; F_6.12.5.4.3
F_6.12.5.4.6
th
5.0.0 March 15 , 2005 Updated
F_6.12.6.1 F_6.12.6.3
Baselined after review
th
5.1.0d1 July 13 , 2005 Added
Network Configuration H
F_6.1.3.14 F_6.1.3.15
F_6.2.21
F_6.6.1.10
F_6.7.13 F_6.7.15
F_6.12.1.1 F_6.12.1.2; F_6.12.2.1 F_6.12.2.4
content added
F_6.12.5.1.3 F_6.12.5.1.6 content added
F_6.12.5.2.3 F_6.12.5.2.6 content added
F_6.12.9.1 F_6.12.9.3
Chapter 6.13 IMS (only oneliner)
Updated
F_6.12.5.1.1 F_6.12.5.1.2; F_6.12.5.1.7
F_6.12.5.1.10
F_6.12.5.2.1 F_6.12.5.2.2; F_6.12.5.2.7 F_6.12.5.2.9
F_6.12.5.3.1 F_6.12.5.3.2; F_6.12.5.3.7
F_6.12.5.3.10
F_6.12.5.4.1 F_6.12.5.4.2; F_6.12.5.4.7 F_6.12.5.4.9
F_6.12.5.5.1 F_6.12.5.5.2
th
5.1.0 August 4 2005 Added note under 4.Overview Bearer
Added:
IMS_LCS_MT_1 - IMS_LCS_MT_4
IMS_LCS_MO_1 - IMS_LCS_MO_2
IMS_SA_1; IM_SA_3 OMS_SA_11
th
5.2.0d1 February 16 2006 Added:
IMS_REG_1 IMS_REG_10
IMS_SO_1 IMS_SO_4
IMS_ST_1 IMS_ST_4
IMS_SR_1 IMS_SR_2
IMS_MOB_1 IMS_MOB_12
IMS_QoS_1 IMS_QoS_4
Updated:
F_6.7.7 F_6.7.10
F_6.12.1.1 F_6.12.1.2
F_6.12.2.1 F_6.12.2.4
th
5.2.0 April 10 2006 Updated:
F_6.7.7 F_6.7.12


Nviot MTC UUU 520 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Nviot MTC UUU 520 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Network Vendors IOT Forum

Master Test Catalogue

between Network and User Equipment

Document Number Version Network Vendors IOT Forum Date Page

COPYRIGHT Network Vendors IOT Forum

Document Number Version Network Vendors IOT Forum Date Page

6.13.5 SIP Compression............................................................................................... 35

Document Number Version Network Vendors IOT Forum Date Page

Document Number Version Network Vendors IOT Forum Date Page

2.1 Applicable Documents

[1] Network Vendor IOT Forum - IOT Methodology

[2] 3GPP TS 34.123 -1 User Equipment (UE) conformance specification

[3] 3GPP TS 51.010 -1 Mobile Station (MS) conformance specification

Document Number Version Network Vendors IOT Forum Date Page

SAPI Service Access Point Identifier

Document Number Version Network Vendors IOT Forum Date Page

Document Number Version Network Vendors IOT Forum Date Page

5.1 Network Configuration

5.1.1 Network Configuration A

Figure 1: Network Configuration A: Configuration with 1 Cells, 1 NodeB, 1 RNC

Document Number Version Network Vendors IOT Forum Date Page

5.1.2 Network Configuration B

Figure 2: Network Configuration B: Configuration with 2 Cells, 1 NodeB, 1 RNC

Document Number Version Network Vendors IOT Forum Date Page

5.1.3 Network Configuration C

Cell 1 Cell 2 Cell 3

Figure 3: Network Configuration C: Configuration with 3 Cells, 1 NodeB, 1 RNC

Document Number Version Network Vendors IOT Forum Date Page

5.1.4 Network Configuration D

Cell 1 Cell 2 Cell

Figure 4: Network Configuration D: Configuration with 6 Cells, 2 NodeBs, 1 RNC

Document Number Version Network Vendors IOT Forum Date Page

5.1.5 Network Configuration E

Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3

Figure 5: Network Configuration E: Configuration with 6 Cells, 2NodeBs, 2 RNCs

Document Number Version Network Vendors IOT Forum Date Page

5.1.6 Network Configuration F

Cell 1 Cell 2 Cell 3 Cell 3 Cell 3 Cell 3

Figure 6: Network Configuration F: Configuration for Intersystem Handover Tests

Document Number Version Network Vendors IOT Forum Date Page

5.1.7 Network Configuration G

Figure 7: Network Configuration G: Configuration for Inter PLMN Handover Tests

Document Number Version Network Vendors IOT Forum Date Page

5.1.8 Network Configuration H

(optional) A Interface Iu Interface

BSC RNC RNC

Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3 Cell 1 Cell 2 Cell 3

Figure 8: Network Configuration H: Configuration for Equivalent PLMN Tests

Document Number Version Network Vendors IOT Forum Date Page

6 Functional Test case list

Total number of test cases: 181

Test Id Description Config.

Number of test cases: 8

Test Id Description Config.

Document Number Version Network Vendors IOT Forum Date Page

Number of test cases: 24

6.1.3 Cell Update

Test Id Description Config.

Number of test cases: 15

6.2 CS Call (incl. emergency call, VT call and CS data)

Test Id Description Config.

Document Number Version Network Vendors IOT Forum Date Page

F_6.2.8 CS Data - Network Release A,B,C,D,E,F