TS11 9 0
TS11 9 0
TS11 9 0
Copyright Notice
Copyright © 2010 GSM Association.
Antitrust Notice
The information contain herein is in full compliance with the GSM Association’s antitrust compliance
policy.
GSM Association
Official Document TS.11 (formerly DG.11)
Table of Contents
I INTRODUCTION ........................................................................................................................... 31
II CONTENTS ................................................................................................................................... 31
V REFERENCES .............................................................................................................................. 34
2 NETWORK SELECTION............................................................................................................... 38
2.1 Release 97 Network Selection ................................................................................................... 38
2.1.1 Automatic Network selection; with information on preferred PLMN list ............................. 38
2.1.2 Automatic Network selection; without information on preferred PLMN list, RXLev > -
85dBm ................................................................................................................................ 38
2.1.3 Periodic HPLMN searching when in National Roaming ..................................................... 38
2.1.4 Automatic network selection; available network stored in EFLOCI ....................................... 39
2.2 Release 99 Network Selection ................................................................................................... 40
2.2.1 Automatic Mode, at power on............................................................................................. 40
2.2.1.1 Device selects a prioritised network (PLMNsel List on the SIM (<=rel98)) .................. 40
2.2.1.2 Device selects a prioritised network (User controlled PLMNwAcT List on the
SIM/USIM (>=rel99))..................................................................................................... 41
2.2.1.3 Device selects a prioritised network (Operator controlled OPLMNwAcT List on the
SIM (>=rel99))............................................................................................................... 42
2.2.2 Network Re-Selection after regaining Coverage ................................................................ 44
2.2.2.1 Automatic Network selection; without information on preferred PLMN list................... 44
2.2.2.2 Device re-selects a prioritised network after regaining coverage (PLMNsel List on
the SIM (<=rel98) .......................................................................................................... 45
2.2.2.3 Device re-selects a prioritised network (User controlled PLMNwAcT List on the
SIM/USIM (>=rel99))..................................................................................................... 46
2.2.2.4 Device re-selects a prioritised network (Operator controlled OPLMNwAcT List on
the SIM (>=rel99))......................................................................................................... 47
2.2.3 Periodic HPLMN searching when in Roaming ................................................................... 49
2.2.3.1 Device re-selects a prioritised network. HPLMN Timer expires in a coverage area
with no higher prioritised network coverage ................................................................. 49
2.2.3.2 Device re-selects a higher prioritised network when camping on a prioritised
network ......................................................................................................................... 50
2.2.3.3 Device re-selects a higher prioritised network when camping on a non prioritised
network ......................................................................................................................... 51
2.2.3.4 Device re-selects a prioritised network - Different Values of the HPLMN Timer / No
HPLMN Search timer defined ....................................................................................... 52
2.2.3.5 HPLMN Timer expires during an ongoing Voice call .................................................... 53
2.2.3.6 HPLMN Timer expires during an ongoing data connection (GPRS) ............................ 54
2.3 Manual Network selection .......................................................................................................... 55
2.4 Selection mode following switch off ........................................................................................... 55
2.5 Steering of Roaming (Managed Roaming), Reject Cause #17 ‘Network Failure’...................... 56
2.5.1 Steering of Roaming / Rejected network not stored on Preferred PLMN list (EFPLMNsel) ... 56
2.5.2 Steering of Roaming / Rejected network stored on Preferred PLMN list (EFPLMNsel) ......... 59
3 HANDOVER .................................................................................................................................. 61
3.1 Handover during an active call................................................................................................... 61
3.2 Directed Retry ............................................................................................................................ 61
5 FAX CALLS................................................................................................................................... 66
5.1 GSM to/from fax modem (transparent only TS62) ..................................................................... 66
5.1.1 MO fax calls to fax modem ................................................................................................. 66
5.1.2 MT fax calls from fax modem ............................................................................................. 67
5.1.3 MO fax calls to PSTN fax device........................................................................................ 67
5.1.4 MT fax calls from PSTN fax device .................................................................................... 68
5.1.5 MO fax calls to GSM Mobile terminal ................................................................................. 68
5.1.6 MT fax calls from GSM Mobile terminal ............................................................................. 69
5.1.7 MO fax calls to ISDN fax device......................................................................................... 69
5.1.8 MT fax calls from ISDN fax device ..................................................................................... 70
9 GPRS........................................................................................................................................... 123
9.1 Operating Systems................................................................................................................... 124
9.2 GPRS attach and detach / GPRS Service Indication............................................................... 125
9.2.1 GPRS Service Indication (registered to the network)....................................................... 125
9.2.2 Service indication (cell reselection) .................................................................................. 126
9.2.3 GPRS attach with IMSI / with P-TMSI / with or without authentication procedure ........... 126
ANNEX B: DETAILED TEST PROCEDURES FOR A SINGLE RAT / MULTI RAT W-CDMA
USER EQUIPMENT........................................................................................................ 154
22 MOBILITY.................................................................................................................................... 210
22.1 Idle Mode Circuit Switched Reselection................................................................................... 210
22.1.1 Idle Mode Circuit Switched 3G Reselection ..................................................................... 210
22.1.1.1 Idle Mode Circuit Switched 3G Reselection Not Packet Attached ............................. 210
22.1.1.2 Idle Mode Circuit Switched 3G Reselection Packet Attached (No PDPc).................. 211
22.1.1.3 Idle Mode Circuit Switched 3G Reselection Packet Attached (PDPc Active, No
Data Transfer)............................................................................................................. 212
22.1.1.4 Idle Mode Circuit Switched 3G Reselection Packet Attached (Transmitting Data) .... 212
22.1.2 Idle Mode Circuit Switched Inter-RAT Reselection .......................................................... 213
22.1.2.1 Idle Mode Circuit Switched Inter RAT Reselection Not Packet Attached................... 213
22.1.2.2 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached (No PDPc) ....... 214
22.1.2.3 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached (PDPc Active,
No Data Transfer) ....................................................................................................... 214
22.1.2.4 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached (Transmitting
Data) ........................................................................................................................... 215
22.2 Idle Mode Packet Switched Reselection.................................................................................. 215
22.2.1 Idle Mode Packet Switched 3G Reselection .................................................................... 215
22.2.1.1 Idle Mode Packet Switched 3G Reselection Packet Attached (No PDPc) Not
Circuit Attached........................................................................................................... 215
22.2.1.2 Idle Mode Packet Switched 3G Reselection Packet Attached (PDPc Active, No
Data Transfer) Not Circuit Attached............................................................................ 216
22.2.1.3 Idle Mode Packet Switched 3G Reselection Packet Attached (Transmitting Data)
Not Circuit Attached .................................................................................................... 217
22.2.2 Idle Mode Packet Switched Inter RAT Reselection.......................................................... 217
22.2.2.1 Idle Mode Packet Switched Inter RAT Reselection Packet Attached (No PDPc)
Not Circuit Attached .................................................................................................... 217
22.2.2.2 Idle Mode Packet Switched Inter RAT Reselection Packet Attached (PDPc Active,
No Data Transfer) Not Circuit Attached ...................................................................... 218
22.2.2.3 Idle Mode Packet Switched Inter RAT Reselection Packet Attached (Transmitting
Data) Not Circuit Attached .......................................................................................... 218
22.3 Dedicated Mode Handovers..................................................................................................... 219
22.3.38 UEA1 (3G) -> A5/3 (GSM) Voice Handover..................................................................... 220
26.3.6 Relative Simultaneous FTP Throughput for HSDPA PS RAB during MultiRAB .............. 319
26.4 Channel Type Switching in HSDPA cells................................................................................. 320
26.4.1 CELL_DCH to CELL_FACH ............................................................................................. 320
26.4.2 CELL_FACH to CELL_PCH ............................................................................................. 320
26.4.3 CELL_PCH to URA_PCH................................................................................................. 321
26.4.4 CELL_PCH to RRC idle.................................................................................................... 322
ANNEX C: DETAILED TEST PROCEDURES FOR A SINGLE RAT / MULTI RAT E-UTRA
USER EQUIPMENT........................................................................................................ 337
31 MOBILITY.................................................................................................................................... 361
31.1 Idle Mode Reselection.............................................................................................................. 361
31.1.1 Idle Mode E-UTRA Reselection ....................................................................................... 361
31.1.1.1 Idle Mode E-UTRA Intra-Frequency Reselection ....................................................... 361
31.1.1.2 Idle Mode E-UTRA Inter-Frequency Reselection ....................................................... 361
31.1.2 Idle Mode Inter RAT Reselection ..................................................................................... 362
31.1.2.1 Idle Mode E-UTRA <-> UTRA Reselection................................................................. 362
31.1.2.1.1 Idle Mode E-UTRA -> UTRA Reselection ............................................................ 362
31.1.2.1.2 Idle Mode UTRA -> E-UTRA Reselection – PDP Context not active .................. 363
31.1.2.1.3 Idle Mode UTRA -> E-UTRA Reselection - PDP context active .......................... 363
31.1.2.2 Idle Mode E-UTRA <-> GERAN Reselection ............................................................. 364
31.1.2.2.1 Idle Mode E-UTRA -> GERAN Reselection ......................................................... 364
31.1.2.2.2 Idle Mode GERAN -> E-UTRA Reselection – PDP Context not active ............... 364
31.1.2.2.3 Idle Mode GERAN -> E-UTRA Reselection - PDP Context active ...................... 365
31.2 Handover.................................................................................................................................. 366
31.2.1 E-UTRA Handover............................................................................................................ 366
31.2.1.1 E-UTRA Handover, Default Bearer............................................................................. 366
31.2.2 Inter RAT Handover.......................................................................................................... 367
31.2.2.1 E-UTRA <-> UTRA Handover, PS Data Transfer....................................................... 367
31.2.2.2 E-UTRA <-> GERAN Handover, PS Data Transfer.................................................... 367
31.2.3 RRC Connection Release with Redirect .......................................................................... 368
31.3 PS performances (During Mobility Drive Tests - Relative Measurement) ............................... 369
31.3.1 Throughput Measure - Downlink FTP .............................................................................. 369
31.3.2 Throughput Measure - Uplink FTP ................................................................................... 370
31.3.3 Throughput Measure - Downlink & Uplink FTP................................................................ 371
31.3.4 Throughput Measure - Downlink simultaneous PS connections with different QoS ........ 372
31.3.5 Throughput Measure - Uplink simultaneous PS connections with different QoS............. 372
31.3.6 Throughput Measure - Downlink + Uplink FTP simultaneous PS connections with
different QoS .................................................................................................................... 372
31.3.7 Delay of short Ping ........................................................................................................... 372
31.3.8 Delay of long Ping ............................................................................................................ 372
ANNEX D: DETAILED TEST PROCEDURES FOR RAT INDEPENDENT SERVICES .................. 399
43.1.2.8 Send message with JPEG image (different sizes) ..................................................... 489
43.1.2.9 Send message with WBMP image (different sizes).................................................... 489
43.1.2.10 Send message with different objects .......................................................................... 490
43.1.2.11 Send message with Business Card attached ............................................................. 490
43.1.2.12 Send message with appointment attached................................................................. 490
43.1.2.13 Send message with VNotes attached......................................................................... 491
43.1.2.14 Send message with different objects to email client................................................... 491
43.1.2.15 Send message with Business Card to email client..................................................... 492
43.1.3 Send MMS with Priorities ................................................................................................. 492
43.1.3.1 Send message with NORMAL priority ........................................................................ 492
43.1.3.2 Send message with LOW priority ............................................................................... 492
43.1.3.3 Send message with HIGH priority............................................................................... 493
43.1.4 Reply and Forward Messages.......................................................................................... 493
43.1.4.1 Reply to message with single recipient....................................................................... 493
43.1.4.2 Reply to message with multiple recipients.................................................................. 494
43.1.4.3 Forward a received message ..................................................................................... 494
43.2 MMS Mobile terminated ........................................................................................................... 495
43.2.1 Mobile terminated with different address format .............................................................. 495
43.2.1.1 Receive MMS notification with message size indicated ............................................. 495
43.2.1.2 Receive message from MSISDN sender using the “To”, the “Cc” or the “Bcc” field .. 495
43.2.1.3 Receive message from email client ............................................................................ 496
43.2.1.4 Receive message to multiple recipients using the fields “To”, “Cc” and “Bcc” ........... 496
43.2.2 Mobile terminated with different fields and objects .......................................................... 497
43.2.2.1 Receive message with subject (maximum length) ..................................................... 497
43.2.2.2 Receive message with text (maximum length) ........................................................... 497
43.2.2.3 Receive message with sound object (iMelody) .......................................................... 497
43.2.2.4 Receive message with polyphonic sound object (MIDI) ............................................. 498
43.2.2.5 Receive message with AMR sound object ................................................................. 498
43.2.2.6 Receive message with GIF image (different sizes) .................................................... 499
43.2.2.7 Receive message with animated GIF image (different sizes) .................................... 499
43.2.2.8 Receive message with JPEG image (different sizes)................................................. 500
43.2.2.9 Receive message with WBMP image (different sizes) ............................................... 500
43.2.2.10 Receive message with different objects ..................................................................... 500
43.2.2.11 Receive message with Business Card attached ........................................................ 501
43.2.2.12 Receive message with an appointment attached ....................................................... 501
43.2.2.13 Receive message with VNotes attached .................................................................... 502
43.2.2.14 Receive message with different objects from email client .......................................... 502
43.2.3 Receive MMS with Priorities............................................................................................. 503
43.2.3.1 Receive message with NORMAL Priority ................................................................... 503
43.2.3.2 Receive message with LOW Priority .......................................................................... 503
43.2.3.3 Receive message with HIGH Priority.......................................................................... 503
43.2.3.4 Receive message with the MS profile “Meeting or silence”........................................ 504
43.2.4 Auto Download Messages................................................................................................ 504
43.2.4.1 Receive MMS when Auto Download is set to “Off“ / Reject MMS.............................. 504
43.2.4.2 Receive MMS when Auto Download is set to “Confirm”............................................. 505
43.2.4.3 Receive MMS when Auto Download is set to “On”..................................................... 505
43.2.4.4 Receive MMS when Auto Download is set to “On” and the MS memory is full.......... 506
43.2.4.5 Receive MMS when Auto Download is set to “On” and the sender is anonymous .... 506
43.2.4.6 Receive MMS when Auto Download is set to “Off”..................................................... 507
43.3 Message Reports ..................................................................................................................... 507
43.3.1 Messages with Delivery Report........................................................................................ 507
43.3.1.1 Send MMS with Delivery Report set to “On“............................................................... 507
43.3.1.2 Send MMS with Delivery Report set to “Off“............................................................... 507
43.3.1.3 Receive a Delivery Report when the MMS was retrieved / Successful...................... 508
43.3.1.4 Receive a Delivery Report when the MMS was rejected............................................ 508
43.3.1.5 Receive a Delivery Report were the MMS was expired ............................................. 509
43.3.1.6 Receive a Delivery Report when the MMS was sent to multiple recipients................ 509
43.3.1.7 Receive a Delivery Report when the recipient MSISDN is directly forwarded to a
different MSISDN ........................................................................................................ 509
43.3.1.8 Deny Delivery Report.................................................................................................. 510
43.3.2 Message with Read Reply Report.................................................................................... 510
43.3.2.1
Sending a Message with Read Reply set to “On”....................................................... 510
43.3.2.2
Sending a Message with Read Reply set to “Off”....................................................... 511
43.3.2.3
Receiving a Message with Read Reply to single recipient ......................................... 511
43.3.2.4
Receiving a Message with Read Reply to multiple recipients .................................... 512
43.3.2.5
Receive a Read Reply Report when the recipient MSISDN is directly forwarded to
a different MSISDN ..................................................................................................... 512
43.4 Message attributes ................................................................................................................... 512
43.4.1 Sending messages with validity period ............................................................................ 512
43.4.2 Sending messages with delayed delivery ........................................................................ 513
43.4.3 Receiving MMS with Message Classes ........................................................................... 513
43.4.3.1 Receiving messages with Message Class “Personal“................................................ 513
43.4.3.2 Receiving messages with Message Class “Advertisement“ ....................................... 514
43.4.3.3 Receiving messages with Message Class “Informational“ ........................................ 514
43.4.3.4 Receiving messages with Message Class “Auto“....................................................... 515
43.5 MMS error handling and multitask interactions........................................................................ 515
43.5.1 Error handling for sending and receiving MMS ................................................................ 515
43.5.1.1 Cancel the downloading MMS when Auto Download is set to “On” ........................... 515
43.5.1.2 Cancel the downloading MMS when Auto Download is set to “Off” ........................... 516
43.5.1.3 Cancel the downloading MMS when Auto Download is set to “Confirm” ................... 516
43.5.1.4 Abort the transmission when sending a message ...................................................... 516
43.5.1.5 Loss of coverage while sending a MMS ..................................................................... 517
43.5.1.6 Maximum message size exceeded when sending a MMS......................................... 517
43.5.1.7 Send a MMS to a MSISDN which is not subscribed to the MMS service................... 518
43.5.1.8 Send MMS when MS is out of coverage..................................................................... 518
43.5.2 MMS multitask interactions............................................................................................... 519
43.5.2.1 Incoming Voice Call during downloading MMS .......................................................... 519
43.5.2.2 Incoming CS Short Message during downloading MMS ............................................ 519
43.5.2.3 Incoming MMS during an active call ........................................................................... 519
43.5.2.4 Receiving a MMS during an active WAP Session ...................................................... 520
43.5.2.5 Receiving MMS and select “Call to Sender“ from the menu....................................... 520
43.6 SMIL functions and options...................................................................................................... 521
43.6.1 SMIL function when sending a MMS................................................................................ 521
43.6.1.1 Maximum message size when sending a MMS ......................................................... 521
43.6.1.2 Preview the message size when sending a MMS ...................................................... 521
43.6.1.3 Send a MMS with multiple pages ............................................................................... 521
43.6.2 SMIL function when receiving a MMS .............................................................................. 522
43.6.2.1 Receive a MMS with multiple pages........................................................................... 522
43.7 MMS Handling.......................................................................................................................... 522
43.7.1 Handling of MMS Notification when changing the SIM .................................................... 522
44 BROWSING................................................................................................................................. 523
44.1 WAP 1.X................................................................................................................................... 523
44.1.1 Dial in................................................................................................................................ 523
44.1.1.1 Dial in to busy RAS ..................................................................................................... 523
44.1.1.2 Dial in to invalid number.............................................................................................. 523
44.1.1.3 Dial in to analogue RAS (setting: ISDN) ..................................................................... 524
44.1.1.4 Dial in to PSTN telephone number ............................................................................. 524
44.1.1.5 Dial in to FAX .............................................................................................................. 524
44.1.1.6 Dial in to GSM-Voice................................................................................................... 525
44.1.1.7 Dial in to GSM-Fax...................................................................................................... 525
44.1.1.8 Wrong data rate (e.g. 14400, when 9600 supported)................................................. 526
44.1.1.9 Dial in with Prepaid SIM Card: network call termination............................................. 526
44.1.1.10 Dial in with AOC (WAP call charged).......................................................................... 526
44.1.1.11 Dial in with activated FDN – authorised number ........................................................ 527
44.1.1.12 Dial in with activated FDN – non authorised number ................................................. 527
44.1.2 Access Settings ................................................................................................................ 528
44.1.2.1 Wrong IP-Address .......................................................................................................... 528
44.1.2.2 User field empty .......................................................................................................... 528
44.1.2.3 Password field empty.................................................................................................. 528
44.1.3 Security............................................................................................................................. 529
44.1.3.1 Display message while setting up a WTLS connection .............................................. 529
47.2.14 Incoming Multimedia Message with multiple PDP contexts and active WAP Browser
connection. WAP browser and Streaming client use different connections..................... 629
47.3 Network Characteristics ........................................................................................................... 629
47.3.1 Roaming ........................................................................................................................... 629
47.3.2 Buffering frequency .......................................................................................................... 630
47.4 Session Establishment and Control ......................................................................................... 630
47.4.1 RTSP minimum implementation support: SETUP, PLAY and TEARDOWN ................... 630
47.4.2 RTSP port setting ............................................................................................................. 631
47.4.3 Fast Forward .................................................................................................................... 631
47.4.4 Rewind.............................................................................................................................. 632
47.5 Audio contents and codecs ...................................................................................................... 633
47.5.1 Support to AMR narrow-band (AMR-NB) speech decoder .............................................. 633
47.5.2 Support to AMR wideband (AMR-WB) speech decoder .................................................. 633
47.5.3 Support to MPEG-4 AAC LC (Low Complexity object type) audio decoder..................... 634
47.5.4 Support to "Real Audio 8" audio codec ............................................................................ 634
47.5.5 Support to "Real Audio 9" audio codec ............................................................................ 634
47.5.6 Support to surestream using the Audio Codec "Real Audio 8" ........................................ 635
47.5.7 Support to surestream using the Audio Codec "Real Audio 9" ........................................ 635
47.6 Video contents and codecs ...................................................................................................... 636
47.6.1 Support to Video Codec "H.263 Profile 0 Level 10" ......................................................... 636
47.6.2 Support to Video Codec "H.263 Profile 3 Level 10" ......................................................... 636
47.6.3 Support to Video Codec "MPEG-4 Simple Visual Profile Level 0" ................................... 637
47.6.4 Support to Video Codec "Real Video 8" ........................................................................... 637
47.6.5 Support to Video Codec "Real Video 9" ........................................................................... 638
47.6.6 Support to surestream using the Video Codec "Real Video 8" ........................................ 638
47.6.7 Support to surestream using the Video Codec "Real Video 9" ........................................ 639
47.7 Video and Audio Codecs.......................................................................................................... 639
47.7.1 H.263 Profile 0 Level 10 (video) and MPEG-4 AAC (audio) ............................................ 639
47.7.2 H.263 Profile 0 Level 10 (video) and AMR-NB (audio) .................................................... 639
47.7.3 H.263 Profile 3 Level 10 (video) and MPEG-4 AAC (audio) ............................................ 640
47.7.4 H.263 Profile 3 Level 10 (video) and AMR-NB (audio) .................................................... 640
47.7.5 MPEG-4 Simple Visual Profile Level 0 (video) and MPEG-4 AAC (audio) ...................... 641
47.7.6 MPEG-4 Simple Visual Profile Level 0 (video) and AMR-NB (audio) .............................. 641
47.8 Session Description Protocol (SDP) files................................................................................. 642
47.8.1 SDP files and SDP syntax ................................................................................................ 642
47.8.2 SDP file: pre-decoder attributes ....................................................................................... 642
47.9 Connections ............................................................................................................................. 643
47.9.1 Connection not configured................................................................................................ 643
47.9.2 Different Connections ....................................................................................................... 643
47.9.3 Connection confirmation................................................................................................... 644
47.10 Playback................................................................................................................................... 644
47.10.1 Decode rates .................................................................................................................... 644
47.10.2 Simultaneous playback..................................................................................................... 645
47.10.3 Audio playback of unsupported encoding format ............................................................. 645
47.10.4 Video playback of unsupported encoding format ............................................................. 646
47.10.5 Playback of unsupported MIME type................................................................................ 646
47.10.6 Control functionality (Play, Stop, Pause).......................................................................... 646
47.10.7 Control functionality (Volume) .......................................................................................... 647
47.10.8 Control functionality (Mute/Unmute)................................................................................. 647
47.10.9 Playback time indication ................................................................................................... 648
47.10.10 Metadata........................................................................................................................... 648
47.10.11 Mono/stereo...................................................................................................................... 649
47.10.12 Display sizes..................................................................................................................... 649
47.10.13 Fullscreen Mode ............................................................................................................... 650
47.10.14 Operator override ............................................................................................................. 650
47.11 Progressive Download ............................................................................................................. 650
47.11.1 Support to Progressive Download of 3gp files ................................................................. 650
47.11.2 Support to Progressive Download of MP4 files ................................................................ 651
48.2 Service maintained when using picture or movie program functions inbuilt or supplied with
the UE ...................................................................................................................................... 652
48.3 Service maintained during transfer of pictures or movie out (or in) the UE. ............................ 652
I Introduction
This document contains a set of guidelines for the tests that should be performed in the course of
Field Test and Lab Test carried out on a Terminal Device.
Field Tests are tests undertaken during later phases of the terminal development against a real live
deployed network (i.e. in the field) to prove of a feature or technology.
Lab Tests are tests undertaken during later phases of the terminal development against laboratory
based network components, representative of a real deployed network, to prove a feature or
technology.
Field Tests are required to ensure confidence in the performance of Terminal Devices in the
operational network environment. Lab Tests usually complement Field Tests for scenarios which can
not be easily executed in a live network.
Field Tests have proven to be a valuable test tool, which exercise terminals under live conditions.
Field Tests do address the terminal behaviour in a dynamic environment, which cannot be achieved
by simulator tests under laboratory conditions.
Additionally experience has shown that comparable results are achieved in multiple network(s)
infrastructures.
Last, but not least, Field Tests do give an insight into customer experience/satisfaction which has
been, and will be, the main driver for performing Field Tests. This also implies that certain
equipment/configuration requirements can be applicable to perform Field Tests.
In order to support the development of Terminal Devices to the maximum extent possible, the GSMA
Terminal Steering Group (TSG) has put considerable effort in applying the experience and knowledge
of the operator community in to a set of Device Field and Lab Test Guidelines i.e. this document. Due
to a continuous stream of innovations, which includes new standards, features and test experiences,
this document shall be a living document.
Although it is the Terminal Manufacturer’s responsibility to define their own Field Test procedures,
TSG do believe that the Device Field and Lab Test Guidelines will assist them to achieve an
operational process.
It is assumed that Field Tests shall be performed without direct support from the network operator.
However TSG and its operator delegates do offer their assistance, if required by any Manufacturer in
terms of drafting Field and/or Lab Tests, providing network specific information, etc.
In order to provide visibility on the applicability, extent and the result of Field and/or Lab Tests
conducted on a Terminal Device, Annex G has been included in this document.
II Contents
The main part of the document consists of nine annexes.
Annex A contains the description of test scenarios for a 2G/2.5G GSM Terminal Device, and is
divided into the following sections:
1 Cell selection/reselection
2 Network Selection
3 Handover
4 Location updating
5 Fax calls
6 Data calls
7 SIM Management
8 SIM Application Toolkit
9 GPRS
10 EGPRS
11 A5/3 Ciphering.
Annex B contains the description of test scenarios for a W-CDMA Single RAT (=Radio Access
Technology) or Multi RAT User Equipment (UE), is counted from section 20 upwards in order to
differentiate them from the 2G/2.5G test scenarios and is divided into the following sections:
20 System Access & Registration
21 Physical Radio Layer FDD
22 Mobility
23 PS/CS Data
24 Multicall and Multi RAB CS-PS
25 UICC/USIM Aspects and SIM/USIM Inter-Working
26 HSDPA
27 Enhanced Uplink (EUL / HSUPA).
Annex C contains the description of test scenarios for an E-UTRA Single RAT (=Radio Access
Technology) or Multi RAT User Equipment (UE), is counted from section 30 upwards in order to
differentiate them from the 2G/2.5G and W-CDMA test scenarios and is divided into the following
sections:
30 System Access & Registration
31 Mobility
32 PS Data
33 UICC/USIM Aspects
34 E-UTRA Voice
35 SMS over LTE.
Annex D contains the description of test scenarios for RAT independent Services, is counted from
section 40 upwards and is divided into the following sections:
40 Basic Voice Calls CS
41 Short Message Service (SMS)
42 Supplementary services
43 Multimedia Message Service (MMS)
44 Browsing
45 Circuit Switched Multimedia Telephony (Video Telephony)
46 JAVA and J2ME
47 Streaming
48 Camera Interworking
49 E-Mail Sending/Receiving
50 DRM Usability
51 IP Multimedia Subsystem (IMS).
Annex E contains the description of test scenarios for Additional Terminal Performance Aspects, is
counted from section 60 upwards and is divided into the following proposed sections:
60 Operation in areas of poor signal
61 Speech quality
62 General performance monitoring.
Annex F contains the description of test scenarios for Services based on non-3GPP Radio Access
Technologies, is counted from section 80 upwards and is divided into the following proposed sections:
III General
The Field and/or Lab Tests in this document may be performed in any order that is convenient. Only
the features supported by the MS/UE shall be tested.
It is recommended to use a logging tool, if available, to take log files when running the tests. The log
files and their indication of network conditions/behaviour during the tests will help to remove any
ambiguity that may come out of the test results.
Also more specifically about the performances tests, it is recommended to run the tests with the
terminal to be certified and with a reference terminal such as, for instance, a competitive terminal
available on the market. The behaviour of the reference platform will help to remove any ambiguity
about the test results.
V References
The following may be cited or referenced in this document.
1. 3GPP Technical Specifications and Technical Reports (GSM xx.yy, TS xx.yyy, TR xx.yyy)
Available via http://www.3gpp.org
2. OMA Technical Specifications
Available via http://www.openmobilealliance,org
3. ETSI Technical Specifications
Available via http://www.etsi.org
4. Global Certification Forum PRDs
Available via http://www.globalcertificationforum.org
5. GSM Association PRDs
- TSG Technical Notes (TN.xx)
- TSG PRDs (TS.xx)
Available via https://infocentre.gsm.org and http://www.gsmworld.com
1 Cell selection/reselection
Description
Basic cell selection when the MS is switched on, MS shall select a suitable cell.
Related GSM core specifications
TS 03.22 subclause 3.2.1 (all 3GPP Releases)
Reason for test
Unless the MS correctly selects a cell, no service is possible
Initial configuration
MS is switched off.
Test procedure
Insert a new SIM with default settings, turn on the phone, check that a cell is selected within an
appropriate time.
Expected behaviour
MS selects a suitable cell.
Expected behaviour
The MS performs a cell selection and can receive a call following the cell selection.
Expected behaviour
After each procedure, the MS performs a cell selection and indicates that full service is available.
2 Network Selection
Test procedure
The test can be performed in a live network or a system simulator. The reason for using a system
simulator is simply that the network conditions (i.e. received signal strength of the BCCH by the
device) can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device is powered up at a location, where not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
Procedure B (Alternative test performed on a system simulator)
The device is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way that the device would
receive the signal strength for GSM better than –85 dBm.
Expected behaviour
The device shall select the prioritised network in the EFPLMNsel and ignore non-prioritised PLMNs.
Test procedure
The test can be performed in a live network or optionally on a system simulator. The reason for using
a system simulator is simply that the network condition (i.e. received signal strength of the BCCH by
the device) can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device is powered up at a location, where not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
Procedure B (Alternative test performed on a system simulator)
The device is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way, that the device receives
the signal strength for GSM better than –85 dBm.
Expected behaviour
The device shall select the prioritised PLMN network and ignore the non-prioritised PLMNs.
The SIM card shall CS/PS enabled for roaming with access to all available networks.
The device is switched off, in automatic network selection mode, located outside the coverage area of
the HPLMN.
Initial conditions for Procedure B
A system simulator with at least 2 GSM PLMNs is used.
A Prioritised Network BCCH (amongst other non- prioritised networks BCCH) is broadcasted.
One UICC (either with SIM only or with both SIM and USIM) (compliant to Rel-99 or later) with the
prioritised network located in the last entry of EFPLMNwAcT / EFOPLMNwAcT is required.
The device is switched off, in automatic network selection mode.
Initial conditions for the UICC (both Procedures)
The SIM card shall support preferably 64 (but not less than 32) entries on the EFPLMNsel and 50 (but not
less than 32) entries on the EFPLMNwACT and EFOPLMMNwACT.
Location Information (EFLOCI): FF FF FF FF FF FF FF FF 00 00 00 01
Forbidden PLMN (EFFPLMN): FF FF FF FF FF FF FF FF FF FF FF FF
Broadcast Control Channels(EFBCCH): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PLMN Selector (EFPLMNwAcT) The MCC xxx / MNC yy of the Preferred PLMN must NOT be
stored in EFPLMNwAcT
PLMN Selector (EFOPLMNwAcT) The test procedure shall be performed with a UICC (either with
SIM only or with both SIM and USIM)
The MCC xxx / MNC yy of the Preferred PLMN is put on the
last position of the following PLMN Selector:
UICC PLMN Selector
SIM EFOPLMNwAcT
All other fields are filled with network codes corresponding to
networks not available at the test location.
Access Technology (2 bytes, set to 80 80)
Note: xxx and yy should be the MCC and MNC of one of the
available networks, but not the HPLMN.
PLMN Selector (EFPLMNsel) The MCC/MNC of Network B shall be stored in EFPLMNsel. With
this method it is tested that the device ignores EFPLMNsel when
EFPLMNwAcT or EFOPLMNwAcT is available.
Test procedure
The test can be performed in a live network or optionally on a system simulator. The reason for using
a system simulator is simply that the network condition (i.e. received signal strength of the BCCH by
the device) can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device is powered up at a location, where not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
Procedure B (Alternative test performed on a system simulator)
The device is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way, that the device would
receive the signal strength for GSM better than –85 dBm.
Expected behaviour
The device shall select the prioritised PLMN and ignore the non-prioritised PLMNs.
This table is based on the assumption that after reaching the maximum number of repetition a
correctly implemented device would have selected each network at least once with a probability of
better than 99%.
Expected behaviour
After each procedure, the device performs an automatic network selection. The network selection was
performed in a random balance. When repeating the procedure N times (as defined above) the device
has selected each available network (with a field strength better than –85 dBm for GSM) at least once.
In addition to this shall the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
The device has already successfully selected the prioritised network and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the device)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device was powered up at a location, where not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
While driving around the coverage of VPLMN A gets lost (for all radio access
technologies of this PLMN). The device looses the network and searches for a new
VPLMN. The location where VPLMN A is lost should be found within EFHPPLMN (Higher
Priority PLMN search period) after switching on the phone, to prevent the device from
searching for a higher prioritised network.
Procedure B (Alternative test performed on a system simulator)
The device is powered up VPLMN A is selected.
The non-prioritised network(s) (excluding VPLMN A / VPLMN B) should transmit with a
higher power than VPLMN B. All networks should transmit in such a way, that the
device would receive the signal strength for GSM better than –85 dBm.
The signal level of VPLMN A is changed so the serving network is lost. The device
starts searching for a new VPLMN.
Expected behaviour
The device shall select the prioritised network VPLMN B and ignore the non-prioritised PLMNs.
required, with the prioritised networks VPLMN A and VPLMN B located in the last two entries of
EFPLMNwAcT / EFOPLMNwAcT.
The device is switched on, in automatic network selection mode and camps on the VPLMN A.
Initial conditions for the UICC (both Procedures)
The SIM card shall support preferably 64 (but not less than 32) entries on the EFPLMNsel and 50 (but not
less than 32) entries on the EFPLMNwACT and EFOPLMMNwACT.
Forbidden PLMN (EFFPLMN): FF FF FF FF FF FF FF FF FF FF FF FF
PLMN Selector (EFPLMNwAcT) The MCC / MNC of VPLMN A is stored on the last but one
position. MCC /MNC of VPLMN B is stored on the last position:
UICC PLMN Selector
SIM EFPLMNwAcT
All other fields in both EFPLMNwAcT are filled with network codes
corresponding to networks not available at the test location.
Access Technology (2 bytes, set to 80 80)
PLMN Selector (EFPLMNsel) The MCC/MNC of Network C shall be stored in EFPLMNsel. With
this method it is tested that the device ignores EFPLMNsel when
EFPLMNwAcT or EFOPLMNwAcT is available.
In addition to this the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
The device has already successfully selected the prioritised network and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the device)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device was powered up at a location, where not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN) so that the device looses the network and is forced to
search for a new network.
Procedure B (Alternative test performed on a system simulator)
The device is powered up and VPLMN A is selected.
The non-prioritised network(s) (excluding VPLMN A / VPLMN B) should transmit with a
higher power than VPLMN B. All networks should transmit in such a way, that the
device would receive the signal strength for GSM better than –85 dBm.
The signal level of VPLMN A is changed so the serving network is lost. The device
starts searching for a new VPLMN.
Expected behaviour
The device shall select the prioritised network VPLMN B and ignore the non-prioritised PLMNs.
In addition to this the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
The device has already successfully selected the prioritised network and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the device)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The device was powered up at a location, where not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference device with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN) so that the device looses the network and is forced to
search for a new network.
Procedure B (Alternative test performed on a system simulator)
The device is powered up and VPLMN A is selected.
The non-prioritised network(s) (excluding VPLMN A / VPLMN B) should transmit with a
higher power than VPLMN B. All networks should transmit in such a way, that the
device would receive the signal strength for GSM better than –85 dBm.
The signal level of VPLMN A is changed so the serving network gets lost. The device
starts searching for a new VPLMN.
Expected behaviour
The device shall select the prioritised network VPLMN B and ignore the non-prioritised PLMNs.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer
(EFHPPLMN) to ensure a PLMN background scan is activated.
Procedure B (Alternative test performed on a system simulator)
The device is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way, that the device would
receive the signal strength for GSM better than –85 dBm.
The tester shall wait HPLMN Search Period Timer (EFHPPLMN) until PLMN background
scan is activated.
Expected behaviour
It shall be checked that the device stays after expiry of HPLMN Search Period Timer (EFHPPLMN) on the
same VPLMN.
One drives to a location where both, VPLMN A and VPLMN B are available.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer
(EFHPPLMN) so that a PLMN background scan is activated.
Procedure B (Alternative test performed on a system simulator)
VPLMN B is the only available network. The device is powered up and selects VPLMN
B.
The radio conditions are changed so VPLMN A, VPLMN B and at least one non-
prioritised network(s) is available. VPLMN B should transmit with a higher power than
the other networks but all network should transmit in such a way, that the device would
receive the signal strength for GSM better than –85 dBm.
The tester shall wait HPLMN Search Period Timer (EFHPPLMN) until PLMN background
scan is activated.
Expected behaviour
It shall be checked that the device selects VPLMN A after expiry of HPLMN Search Period Timer
(EFHPPLMN).
Expected behaviour
It shall be checked that the voice call is active while HPLMN Search Period Timer (EFHPPLMN) expired.
After releasing the call the device shall re-select the higher priority PLMN A.
receive the signal strength for GSM better than –85 dBm.
The tester activates a PDP context and starts data transfer. The HPLMN Search Period
Timer (EFHPPLMN) expires during data transfer. Afterwards the PDP context is
deactivated.
Expected behaviour
It shall be checked that the data transfer is ongoing while HPLMN Search Period Timer (EFHPPLMN)
expires and that the PDP context is still active after expiry of the HPLMN Search Period Timer. After
deactivation of the PDP context the device shall re-select the higher priority PLMN A.
2. Change to automatic network selection. Turn the MS off and on again. Check that the
automatic network selection mode is in use.
Expected behaviour
The MS has the same selection mode when switched on that it had when switched off.
16. MS performs a new network selection and starts attaching the same, previously rejected PLMN
after max. 2 minutes
17. MS displays full service
• Networks available:
o PLMN1: Dualband
o PLMN2: At least singleband
o PLMN3: Dualband
o PLMN4: At least singleband
Note: It would be ideal, if all of the available networks are Dualband networks. The more
complex the network environment is, the higher will be the confidence in the
Device under Test to comply with Steering of Roaming.
• Used SIM card: Roaming SIM Card (PLMN 5, different MCC)
• Assisted Roaming deactivated on SIM card
• SIM Card preparation (using SIM R/W Tool):
o PLMN1 and PLMN2 on forbidden PLMN list (EFFPLMN)
o PLMN3 is stored at highest priority (location 1) of the preferred PLMN list of the SIM, EFPLMNsel is
filled up with PLMNs of other MCCs
o EFLOCI = PLMN5, LAI=1234, TMSI=12345678, Update Status= 00 (Updated)
• Managed Roaming System of PLMN5 (Roaming SIM) configured as follows:
o PLMN1 = Preferred Network of the Managed Roaming System = PN
o All other PLMNs of this country (PLMN2, PLMN3, PLMN4) = Non-preferred Network of the
Managed Roaming System = NPN
• The test shall be performed in NMO II (both GSM and UMTS) and in NMO I (GSM) networks. The
test may be performed in GSM NMO III as well.
Test procedure
1. Perform a successful Manual Network Selection on PLMN2 to re-set VLR/HLR entries
2. Switch Device under Test (DuT) to Automatic Network Selection
3. Switch off Device under Test
4. Prepare SIM to fulfil Initial Conditions (using SIM R/W Tool)
5. Switch on DuT, 4 IMSI Attach attempts on PLMN3. During IMSI Attach, the MS performs GPRS
Attach, GPRS Attach is accepted after the first attempt.
6. Check that display service indicator(s) are consistent
7. a) If not in NMO I GSM network check that a further IMSI Attach is performed after 4 rejects on
another PLMN (i.e. PLMN4) until the MS is in full service (i.e. PS and CS attached).
b) If in a NMO I GSM network check that five consecutive Rejection Causes #17 ‘Network Failure’
are received. These rejects can be either in ATTACH REJECT or ATTACH ACCEPT messages.
8. Check that display service indicator(s) are consistent
Expected behaviour
6. MS displays limited service, GPRS is attached, CS is not attached,
7. MS performs a new network selection and starts attaching the new PLMN (highest prioritised
network available except for the previous rejected one) after max. 2 minutes
8. MS displays full service.
3 Handover
Test procedure
Try to perform a call in the cell without available TCHs. The call should be re-directed (‘handed over’)
to the neighbour cell, where a Traffic Channel is available. Ensure that the call is not dropped within
30 seconds after call completion and that voice transmission is maintained in both directions.
Where possible, this procedure should be repeated in different locations to check that the different
types handover that the network can command, involving as many as possible of the following
combinations of features
1. Operation on different frequency bands
2. Handover between cells with and without frequency hopping
3. Handover moving between the coverage areas of two different MSCs
4. Any possible combinations of the above.
5. Any combination of the above, but with a circuit-switched call being set up for other services,
such as data or fax.
6. Any combination of the above, but with an MT call in process of being set up.
Expected behaviour
After the directed retry, the MS completes the call setup, does not drop the call within 30 seconds and
maintains voice transmission in both directions.
4. Location Updating
Test procedure
1. Wait for the T3212 timer to expire, and observe if the MS sends the network a LOCATION
UPDATE REQUEST message. Check whether the “location updating type” parameter holds
the “periodic updating” value.
2. The network shall then send a LOCATION UPDATE ACCEPT message to the MS.
3. Check that the MS responds to paging after the Location Update procedure.
Expected behaviour
The MS performs a ‘Periodic Location Update’ procedure and receives an incoming call.
Test procedure
1. Move the MS out of coverage (no other network available). The ‘out of coverage time’ should
last for ¾ of the interval of T3212.
2. Bring the MS back to coverage (same PLMN / Location Area as before) before T3212
expires. When gaining back coverage, check that the MS does not perform a Location
Update procedure.
3. Wait for the T3212 timer to expire, and observe if the MS sends the network a LOCATION
UPDATE REQUEST message. Check whether the “location updating type” parameter holds
the “periodic updating” value.
4. Check that the MS responds to paging after the Location Update procedure.
5. Repeat procedure 1. – 4. when the MS is performing Emergency Camping on a different
PLMN while out of service.
Expected behaviour
The MS does not perform a Location Update procedure after regaining service but waits until T3212
expiry to perform the Location Update procedure. The MS receives an incoming call after each test.
5 Fax calls
Initial configuration
MS in idle mode, connected to auxiliary equipment if necessary and configured for sending faxes
Test procedure
For each of the following call configurations, make an outgoing fax call. Ensure that the call completes
and the fax output is legible.
1. MO to class 1 fax modem, DTE hardware flow control, transmit rate 9600 bits/s
2. MO to Class 1 fax modem, DTE hardware flow control, transmit rate 9600 bits/s with ECM
3. MO to class 1 fax modem, DTE software flow control, transmit rate 9600 bits/s
4. MO to class 1 fax modem, DTE software flow control, transmit rate, 9600 bits/s with ECM
5. MO to class 2 fax modem, transmit rate, 9600 bits/s
6. MO to Class 2 fax modem, transmit rate, 9600 bits/s with ECM
7. Autobauding test (negotiating down from 9600bps)
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, arrange to receive an incoming fax call. Ensure that the
call completes and the fax output is legible.
1. MT from class 1 fax modem, DTE software flow control, transmit rate 9600 bits/s
2. MT from class 1 fax modem, DTE hardware flow control, transmit rate 9600 bits/s
3. MT from Class 1 fax modem, DTE hardware flow control, transmit rate 9600 bits/s with ECM
4. MT from Class 1 fax modem, DTE software flow control, transmit rate 9600 bits/s with ECM
5. MT from class 2 fax modem, transmit rate, 9600 bits/s
6. MT from class 2 fax modem, transmit rate, 9600 bits/s with ECM
7. Autobauding test (negotiating down from 9600bps)
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, make an outgoing fax call. Ensure that the call completes
and the fax output is legible.
1. MO to Group 3 device, transmit rate 9600 bits/s with ECM
2. MO to Group 3 device, transmit rate, 9600 bits/s
3. Down training test (negotiating down from 9600bps)
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, arrange to receive an incoming fax call. Ensure that the
call completes and the fax output is legible.
1. MT from Group 3 device, transmit rate 9600 bits/s
2. MT from Group 3 device, transmit rate 9600 bits/s with ECM
3. Down training test (negotiating down from 9600bps)
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, make an outgoing fax call. Ensure that the call completes
and the fax output is legible.
1. Class 1 fax terminal to Class 1 fax terminal, transmit rate 9600 bits/s
2. Class 1 fax terminal to Class 2 fax terminal, transmit rate 9600 bits/s
3. Class 2 fax terminal to Class 1 fax terminal, transmit rate 9600 bits/s
4. Autobauding test (negotiating down from 9600bps)
5. Class 2 fax terminal to Class 2 fax terminal, transmit rate 9600 bits/s
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, arrange to receive an incoming fax call. Ensure that the
call completes and the fax output is legible.
1. Class 1 fax terminal to Class 1 fax terminal, transmit rate 9600 bits/s
2. Class 1 fax terminal to Class 2 fax terminal, transmit rate 9600 bits/s
3. Class 2 fax terminal to Class 1 fax terminal, transmit rate 9600 bits/s
4. Autobauding test (negotiating down from 9600bps)
5. Class 2 fax terminal to Class 2 fax terminal, transmit rate 9600 bits/s
6. Fax download from mailbox at 9600 bps
Expected behaviour
The call completes and the fax output is legible.
Test procedure
For each of the following call configurations, make an outgoing fax call. Ensure that the call completes
and the fax output is legible.
1. MO to Group 4 device, transmit rate 9600 bits/s with ECM
2. MO to Group 4 device, transmit rate, 9600 bits/s
3. Down training test (negotiating down from 9600bps)
Expected behaviour
The call completes and the fax output is legible.
6 Data calls
NOTE 1: For data calls, if the MS has a variety of auxiliary interfaces (e.g. serial, IR,
Bluetooth) then a set of data communication tests should be repeated for each of
the interfaces supported.
NOTE 2: For UDI data calls, both V.110 and V.120 protocols should be tested.
Initial configuration
MS in idle mode, connected to auxiliary equipment if necessary and configured for sending data
Test procedure
For each of the following call configurations, make an outgoing MO data call. Ensure that the call
completes and the data is exchanged correctly.
1. GSM non-transparent to GSM non-transparent UDI, 9600bits/s, circuit switched data
2. GSM non-transparent to GSM transparent UDI, 9600bits/s, circuit switched data
3. GSM to ISDN UDI, 9600bits/s, circuit switched data
4. GSM transparent to GSM non-transparent UDI, 9600bits/s, circuit switched data
5. GSM transparent to GSM transparent UDI (IWF by-pass), 9600bits/s, circuit switched data
6. MO to PSTN non-transparent, 9600bits/s, Autobauding, circuit switched data
7. MO to PSTN transparent, 9600bits/s, circuit switched data
8. GSM non-transparent to GSM non-transparent, 9600bits/s, Autobauding, circuit switched data
9. GSM non-transparent to GSM transparent, 9600bits/s, Autobauding, circuit switched data
10. GSM transparent to GSM non-transparent, 9600bits/s, Autobauding, circuit switched data
11. GSM transparent to GSM transparent, 9600bits/s, circuit switched data
12. V.42 Error Correction @9600bps in Transparent mode (MO Call to PSTN using VB-
data/Analogue)
13. V.42 Error Correction @9600bps in Transparent mode (MO Call to PSTN using UDI)
14. V.42bis Data Compression @9600bps in Non-Transparent mode (MO call to PSTN using
VB/Analogue connection)
15. V.42bis Data Compression @9600bps in Non-Transparent mode (MO call to PSTN using UDI
connection)
16. V.42bis Data Compression @9600bps in Transparent mode (MO call to PSTN using
VB/Analogue connection)
17. V.42bis Data Compression @9600bps in Transparent mode (MO call to PSTN using UDI
connection)
Expected behaviour
The call completes and the data is exchanged correctly.
Test procedure
For each of the following call configurations, arrange to receive an incoming MT data call. Ensure that
the call completes and the data is received correctly by the MS.
1. GSM non-transparent to GSM non-transparent UDI, 9600bits/s, circuit switched data
Initial configuration
MS in idle mode, connected to auxiliary equipment if necessary and configured for sending data
Test procedure
For each of the following call configurations, make an outgoing MO data call. Ensure that the call
completes and the data is received correctly by the distant party. For "X+Y" call configurations, the test
should be repeated for each combination of uplink and downlink channel numbers supported by the
MS.
1. MO to PSTN transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
2. MO to PSTN non-transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
3. MO to UDI transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
4. MO to UDI non-transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
5. GSM to GSM transparent UDI (IWF by-pass), X+Y TS, 9600 & 14400 bps channel codings,
HSCSD
6. GSM to GSM non-transparent UDI (IWF by-pass), X+Y TS, 9600 & 14400 bps channel
codings, HSCSD
7. HSCSD downgrading & upgrading from 1+1
8. ALA (change of channel coding during call)
Expected behaviour
The call completes and the data is exchanged correctly.
Initial configuration
MS in idle mode, connected to auxiliary equipment if necessary and configured for sending data
Test procedure
For each of the following call configurations, make an outgoing MO data call. Ensure that the call
completes and the data is received correctly by the distant party. For "X+Y" call configurations, the test
should be repeated for each combination of uplink and downlink channel numbers supported by the
MS.
1. MT from PSTN transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
2. MT from PSTN non-transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
3. MT from UDI transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
4. MT from UDI non-transparent, X+Y TS, 9600 & 14400 bps channel codings, HSCSD
5. GSM to GSM transparent UDI (IWF by-pass), X+Y TS, 9600 & 14400 bps channel codings,
HSCSD
6. GSM to GSM non-transparent UDI (IWF by-pass), X+Y TS, 9600 & 14400 bps channel
codings, HSCSD
7. HSCSD downgrading & upgrading from 1+1
8. ALA (change of channel coding during call)
Expected behaviour
The call completes and the data is exchanged correctly.
7 SIM Management
Test procedure
1. Dial the code **04*OLD*NEW1*NEW2# (where OLD is the old PIN1 and NEW1 and NEW2
are different from each other) to change PIN1. Check that the mobile indicates that the
command has failed.
2. Repeat procedure 1, but using the phone's menus to send the command.
Expected behaviour
The mobile clearly indicates that the command has failed.
Test procedure
1. Dial the code **04*OLD*NEW*NEW# (where OLD is an incorrectly entered old PIN1 and NEW
is the new PIN1) to change PIN1. Check that the mobile indicates that the command has
failed, giving the reason.
2. Repeat procedure 1, but using the phone's menus to send the command.
Expected behaviour
The mobile clearly indicates that the command has failed displaying the reason.
Test procedure
1. Dial the code **042*OLD*NEW*NEW# to change PIN2. Check that the new PIN2 is accepted
by the mobile.
2. Repeat procedure 1, but using the phone's menus to send the command.
Expected behaviour
The new PIN2 is accepted by the mobile.
2. Repeat procedure 1, but using the phone's menus to send the command.
Expected behaviour
The mobile indicates that the new PIN is now in effect.
7.4.4 Storage of directory number and name; when SIM phone book full
Description
Procedure for storage of international directory number and name when SIM phone book is full
Related GSM core specifications
GSM 11.11, subclause 11.5.1
Reason for test
1) To ensure interoperability with SIMs containing 250 ADNs.
2) To ensure that a failure indication is given when attempting to store a new directory number in a full
SIM phone book
Initial configuration
MS in idle mode. SIM phone book full
Test procedure
1. The mobile is switched on using a SIM with 250 ADN entries.
2. Attempt to store a directory number and name on the SIM phone book. Check that the MS
indicates that the command has failed.
Expected behaviour
1. The MS behaves normally. If the complete phonebook can not be loaded then it shall
successfully load to its capacity and provide an indication to the user,
2. The MS indicates that the command has failed.
Test procedure
Change an existing directory number and name in the SIM phone book. Check that the modified entry
can be correctly viewed and dialled.
Repeat the process when the SIM phone book is full.
Expected behaviour
The mobile stores the number and correctly displays and dials the stored number.
Initial configuration
MS in idle mode. At least one directory number longer than 20 digits is stored in the SIM phone book
Test procedure
Delete a directory number of more than 20 digits from the SIM phone book. Check that the number
can no longer be dialled from the phone book. Check with a SIM card reader that all relevant
extension records are released, i.e. no vector is pointing to this particular Extension Record.
Expected behaviour
The mobile deletes the name and number from the SIM phone book, and can no longer dial the stored
number from the phone book.
7.4.11.1 MMI language is in right aligned UCS2 language & PB entry is in 7 bit
default alphabet (aligned to the left)
Description
Ensure that 7 bit default alphabetic Phonebook entry name is aligned correctly (e.g. English is aligned
to the left) even though the UCS2 MMI language is aligned to the opposite direction (e.g. Hebrew is
aligned to the right).
Related GSM core specifications
N.A.
Reason for test
To ensure that 7 bit default alphabetic PB entry name is aligned correctly (e.g. English is aligned to the
left) even though the UCS2 MMI language is aligned to the opposite direction (e.g. Hebrew is aligned
to the right).
Initial configuration
Idle mode.
Test procedure
Using MMI commands, change MMI language to the right aligned UCS2 language (e.g. Hebrew). Use
the MMI commands to save a PB entry name in 7 bit default alphabetic. Browse through the PB
entries names and check if the 7 bit default entry is aligned to the left.
Expected behaviour
7 bit default alphabetic PB entry name will be aligned to the left even though USC2 MMI language is
aligned to the right.
7.4.11.2 MMI language is 7 bit default (aligned to the left) & PB entry is in right
aligned UCS2 language
Description
Ensure that a Phonebook entry name written in a right aligned UCS2 language is aligned correctly
(e.g. Hebrew is aligned to the right) even though the 7 bit default MMI language is aligned to the
opposite direction (English is aligned left)
Related GSM core specifications
N.A.
Reason for test
To ensure that a PB entry name written in a right aligned UCS2 language is aligned correctly (e.g.
Hebrew is aligned to the right) even though the 7 bit default MMI language is aligned to the opposite
direction (English is aligned left)
Initial configuration
Idle mode.
Test procedure
Using MMI commands, change MMI language to 7 bit default alphabetic (aligned to the left). Use the
MMI commands to save a PB entry name in a right aligned UCS2 language (e.g. Hebrew). Browse
through the PB entries names and check if the saved entry is aligned to the right.
Expected behaviour
UCS2 alphabetic PB entry name will be aligned to the right even though USC2 MMI language is
aligned to the left.
7.5 FDN
7.5.1 Enabling, Updating and Disabling of FDN
Description
Procedure for Enabling, Updating and Disabling of FDN
Related GSM core specifications
GSM 11.11 subclause 11.5.1
GSM 02.07 subclause B.3.2
Reason for test
To verify that editing of the FDN list is only possible under the control of PIN2 and when updated, the
MS correctly updates the EFFDN data field in the SIM.
Initial configuration
MS pre-test condition: FDN deactivated
No call barring services activated
Where supported and possible, there should be no entries stored in the ADN, SDN, BDN or LND lists.
Test procedure
1. Select FDN option, verify PIN2, store an entry in the FDN[1] field, and enable FDN. Recall and
send the FDN number. Check that the MS allows call set up.
2. Attempt to establish a call to the number in 1) above, but key the number directly. Check that
the MS allows call set up.
3. Select FDN option, verify PIN2 and delete the entry in FDN[1].
4. Attempt to establish a call to the number FDN[1]. Check that the MS does not permit the call
to be made.
5. Select FDN option, verify PIN2 and enter a different entry in FDN[1]
6. Attempt to establish a call to the number in 1) above. Check that the MS prevents call set up
7. Using a SIM card reader, verify the contents of the EFFDN data field in the SIM.
8. Select FDN option, verify PIN2 and delete all FDN entries. Enter a name only in FDN[1] using
a SIM card reader. Attempt to establish a call to any valid number other than an emergency
number. Check that the call setup is prevented.
9. Select FDN option, verify PIN2 and deactivate FDN.
10. Attempt to establish a call to any valid number other than an emergency number or either of
the numbers in 1 and 3 above. Check that the MS allows call set up.
Expected behaviour
1. The MS allows call set up.
2. The MS allows call set up.
5. Set up a call to the MS. Check that the MS does not indicate the incoming call. The call shall
be established to the international number.
6. Select FDN [3].
7. Set up a call to the MS. Check that the MS indicates the incoming call
8. Enter a SS code other than CFU and attempt to activate service. Check that the MS does not
permit the service to be activated.
9. Repeat step 7) using the MS menu options where available.
Expected behaviour
Only SS codes in the FDN list can be used when FDN is active.
Test procedure
1. A PDP context shall be attempted. Activation shall be prevented and a message shall be
displayed giving the reason.
2. Select FDN option, verify PIN2 and enter *99# in the FDN [1] entry.
3. A PDP context shall be successfully attempted.
Expected behaviour
1. The PDP context shall not be activated and a message shall be displayed giving the reason.
3. The PDP context shall be activated.
Expected behaviour
The LAI field of EFLOCI shall contain the correct MCC, MNC and LAC.
The TMSI field of EFLOCI shall contain the updated TMSI.
The Location Update status of EFLOCI shall indicate "updated".
The Ciphering key Kc field of EFKC shall contain the newly calculated value of Kc
The Ciphering key sequence number n field of EFKC shall contain a valid ciphering key sequence
number.
7.8 Storage of SIM Data after LUP reject; IMSI not in HLR
Description
Ensure that SIM data is stored correctly following a Location Updating Reject, with the failure given as
"IMSI not in HLR"
Related GSM core specifications
GSM 04.08, GSM 11.11
Reason for test
To ensure that, when the location updating process fails, with the failure given as "IMSI not in HLR"
that the location information is stored correctly
Initial configuration
MS is switched off. SIM contains an invalid IMSI
Test procedure
Turn on the MS and wait for it to attempt to connect to a network. When the mobile indicates that it
has not been able to obtain full service, turn off the MS and remove the SIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
7.10 Storage of SIM Data after LUP reject; PLMN not allowed
Description
Ensure that SIM data is stored correctly following a Location Updating Reject, with the failure given as
"PLMN not allowed "
Related GSM core specifications
GSM 04.08, GSM 11.11
Reason for test
To ensure that, when the location updating process fails, with the failure given as "PLMN not allowed"
that the location information is stored correctly
Initial configuration
MS is switched off. MS is located in an area where the only available networks will all respond with
"PLMN not allowed". On the SIM, all four fields of EFFPLMN are filled with valid data (but not indicating
any currently available PLMN).
Test procedure
Turn on the MS and wait for it to attempt to connect to a network. When the mobile indicates that it
has not been able to obtain full service, turn off the MS and remove the SIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
Test procedure
Turn on the MS and wait for it to attempt to connect to a network. When the mobile indicates that it
has not been able to obtain full service, turn off the MS and remove the SIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
The Ciphering key Kc field of EFKC shall be cleared
The Ciphering key sequence number n field of EFKC shall be cleared
7.13 Mobile support of GPRS unaware SIM cards and GPRS aware
SIM cards with GPRS Elementary Files
Description
Procedure to check the correct storage of EFlociGPRS and EFkcGPRS
Related GSM core specifications
GSM 11.11 v 8.3.0 subclause 10.3.7, 10.3.32 and 10.3.33 (ETSI TS 100977)
GSM 03.60 subclause 13.4
Reason for test
To test the storage procedure with a SIM that is a:
- GPRS aware SIM; indicated by EFSST service number 38 (activated and allocated) and has
EFlociGPRS and EFkcGPRS allocated in the SIM.
- GPRS not aware SIM; indicated by EFSST service number 38 with value not allocated and not
activated.
If the SIM is GPRS-aware, the P-TMSI, P-TMSI Signature value, Routing Area Information, Routing
area update status, KcGPRS, and CKSNGPRS stored in the SIM shall be used when accessing the GPRS
services.
And
If the SIM is not GPRS-aware, then the P-TMSI, P-TMSI Signature, Routing Area Information, Routing
area update status, KcGPRS, and CKSNGPRS stored in the ME shall be used if and only if the IMSI
stored in the SIM is identical to the IMSI image maintained in the ME. If the IMSI stored in the SIM is
different from the IMSI image in the ME, then the IMSI image in the ME shall not be used, and the MS
shall identify itself with the IMSI stored in the SIM when performing a GPRS attach. IMSI, P-TMSI, P-
TMSI Signature, Routing Area, Kc, and CKSN may be stored in the ME after the GPRS attach has
been successfully performed.
Initial configuration
1. MS with GPRS aware SIM with the EFlociGPRS and EFkcGPRS cleared and switched off.
2. MS with a GPRS not aware SIM switched off.
Test procedure
1.
A. Switch the MS on.
B. Attempt a PDP context .
C. Switch the MS off.
D. Using a SIM card reader, verify the contents of the EFlociGPRS and EFkcGPRS data field in the
SIM.
2.
NOTE 2: The detailed expected behaviour in each test depends on the exact features
implemented in the SIM toolkit application. Therefore in most cases the detailed
behaviour is specific in terms of what the SIM application is designed to do.
NOTE 3: A lot of the problems with SIM Application Toolkit occur on multiple events and/or
commands. Therefore SIM Toolkit Applications provided on the SIM card of the
operators shall be used for field tests additionally to the tests outlined below.
5. The MS shall send a short message with contents and destination as specified by the SIM
application and provide a notification to the user.
6. The MS shall send a short message with contents and destination as specified by the SIM
application and provide a notification to the user.
8.2.8 SEND SS
Description
Ensure that the SEND SS command is correctly processed by the MS.
Related GSM core specifications
GSM 11.14
Reason for test
To ensure that the SEND SS command is correctly processed by the MS.
Initial configuration
MS in idle mode. SIM inserted with an application that makes use of the SEND SS command.
Test procedure
3. Arrange for an event to occur which will cause the SIM to send a SEND SS command with a
null alpha identifier.
4. Arrange for an event to occur which will cause the SIM to send a SEND SS command with a
non-null alpha identifier.
Expected behaviour
1. The MS shall send an SS request with contents as specified by the SIM application without
providing any notification to the user that the SS request is being sent.
2. The MS shall send an SS request with contents as specified by the SIM application and
provide a notification to the user.
In both cases, the SS request string shall not be recorded as the last number dialled.
In both cases, if the network feature invoked by means of the USSD request requires a dialogue
between the network and the user which involves the MMI of the ME, then check that this dialogue
occurs
Initial configuration
MS in idle mode. SIM inserted with an application that makes use of the SET UP IDLE MODE TEXT
command.
Test procedure
Arrange for an event to occur which will cause the SIM to send a SET UP IDLE MODE TEXT
command.
Expected behaviour
When the MS next displays the normal stand-by display screen, the text shall instead be that
contained in the SET UP IDLE MODE TEXT command.
8.2.19 REFRESH
Description
Ensure that refresh requested by the SIM are correctly processed by the MS.
Related GSM core specifications
GSM 11.14
Reason for test
To ensure that REFRESH command is correctly processed by the MS.
Initial configuration
MS in idle mode. SIM inserted with an application that makes use of REFRESH command.
Test procedure
1. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Initialization)
command.
2. Arrange for an event to occur which will cause the SIM to send a REFRESH (File Change
Notification) command.
3. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Initialization and
File Change Notification) command.
4. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Initialization and
Full File Change Notification) command.
5. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Reset)
command.
6. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Initialization and
File Change Notification within IMSI file) command.
7. Arrange for an event to occur which will cause the SIM to send a REFRESH (SIM Initialization and
Full File Change Notification within IMSI file) command.
Expected behaviour
The MS shall refresh its memory regarding files notified.
Initial configuration
MS in idle Mode. SIM inserted with an application that makes use of the MT call event.
Test procedure
Arrange to receive an incoming call.
Expected behaviour
The SIM application triggered by the MT call event is started.
Expected behaviour
In each case, the SIM application triggered by the Call connected event is started when the call is
connected
Expected behaviour
The SIM application triggered by the Idle screen available event is started when the normal stand-by
display is shown.
Initial configuration
MS in idle mode. SIM inserted with an application that makes use of the Browser Termination event.
Test procedure
Start a WAP session, then terminate the browser.
Expected behaviour
The SIM application triggered by the Browser Termination event is started when the browser is
terminated.
8.4.3 USSD
Description
Ensure that the MS passes details of USSD strings to the SIM before making calls.
Related GSM core specifications
GSM 11.14
Reason for test
To ensure that the MS passes details of USSD strings to the SIM before making calls.
Initial configuration
MS in idle mode. SIM inserted with an application that makes use of Call Control.
Test procedure
Send a USSD string. Check that whatever action is supposed to be taken by the SIM application
actually occurs
Expected behaviour
The MS shall send the USSD string as modified by the SIM application.
Initial configuration
MS is in connected mode.
Test procedure
Access the SAT menu and send a request to the SAT menu.
Expected behaviour
The MS receives the SM of replay from the network
8.9.4 Receive a second call while the MS is engaged in a first voice call
and in SAT menu
Description
To ensure that the MS supports the possibility to establish a second incoming call also when it is
already engaged in a first call and in the SAT menu (Call Waiting is activated)
Related GSM core specifications
None
Reason for test
To ensure that the MS establishes the second call without closing the first call and/or the SAT
application.
Initial configuration
The MS under test (MS #1) accesses the SAT menu and establishes a first incoming call with MS #2.
Test procedure
MS #1 receives a second incoming call from MS #3 and signals the reception of it (Call Waiting is
activated).
Expected behaviour
The MS under test (MS #1) puts the first call on hold, activates the second call and remains still
engaged in the SAT menu.
8.9.5 Closing the call from subscriber while using SAT menu
Description
To ensure that when the MS is engaged both in a call and in the SAT menu, the MS shall not close the
SAT application if the subscriber closes the call
8.9.6 Closing the call from the other connected part while using SAT menu
Description
To ensure that when the MS is engaged both in a call and in the SAT menu, the MS shall not close the
SAT application when the other connected part closes the call.
Related GSM core specifications
None
Reason for test
To ensure that the MS closes only the voice call without closing the SAT menu.
Initial configuration
The MS under test (MS #1) accesses the SAT menu and receives a call from another MS (MS#2).
Test procedure
Close the call from MS#2.
Expected behaviour
The MS under test closes the voice call and remains still engaged in the SAT menu.
8.9.8 Receive short messages while typing text in an input dialog screen
(Get Input proactive command)
Description
Ensure that the reception of a short message, while typing text in an input dialog screen (get input),
doesn’t cause the loss of the text already entered.
Related GSM core specifications
None
Reason for test
To ensure that the reception of a SM doesn’t cause the MS to close the SAT application or to lose the
entered text.
Initial configuration
Start a request from the local SAT application and enter the text in the input dialog screen (get input).
Test procedure
The MS shall receive the short message.
Expected behaviour
The MS shall not close the SAT menu and shall continue showing the text entered.
8.9.10 Receive WAP Push while typing text in an input dialog screen (Get
Input proactive command)
Description
To Ensure that the reception of a WAP Push, while typing text in an input dialog screen (get input),
doesn’t cause the loss of the text already entered.
Related GSM core specifications
None
Reason for test
To ensure that the reception of a WAP Push doesn’t cause the MS to close the SAT application and/or
lose the already entered text.
Initial configuration
Start a request from the local SAT application and enter text in an input dialog screen.
Test procedure
Receive a WAP Push message.
Expected behaviour
MS shall not close the SAT menu and shall continue showing the text.
8.9.11 WAP session after sending a request from the SAT menu
Description
Ensure that the MS receives correctly the SM from the remote content server during WAP session.
Related GSM core specifications
None
Reason for test
To ensure that the MS starts a WAP session just after sending a request from the SAT application,
and the SM from the remote server can be correctly received.
Initial configuration
Having sent the request from SAT menu the MS is in WAP session.
Test procedure
Send a request using SAT menu and start a WAP session.
Expected behaviour
The “new message received” notice shall be displayed on the screen and the sound of the new
received SMS shall be heard
8.9.13 Predictive Text Input to type text in an input dialog screen (Get Input
proactive command)
Description
Ensure that the MS supports the Predictive Text Input to type text in an input dialog screen (get input)
Related GSM core specifications
None
8.9.14 Use of special characters to type text in an input dialog screen (Get
Input proactive command)
Description
Ensure that the MS supports special characters (e.g. @, commas, case sensitive etc) while typing text
in an input dialog screen (get input)
Related GSM core specifications
None
Reason for test
To ensure that the user can insert special characters when inserting a text input in an input dialog
screen.
Initial configuration
MS starts a request from the local SAT application (e.g. the lottery interrogate service)
Test procedure
Fill in the input dialog screen.
Expected behaviour
The MS shall support the possibility to insert special characters.
Expected behaviour
When the MS receives the answer form the network (SMS with envelope command) the MS displays
the text related to the SMS with envelope command.
8.9.20 Accepting an incoming call between the SAT request and the
reception of SM Mobile Terminated with envelope command (display
text / get input / menu selection / setup menu)
Description
To ensure that the MS displays the incoming message (SMS with envelope command ‘display text /
get input / menu selection / setup menu’ even if between the request and the answer from the
network, a MT call incomes (the subscriber accepts the call)
8.9.21 Rejecting an incoming call between the SAT request and the
reception of a SM Mobile Terminated with envelope command
(display text / get input / menu selection / setup menu)
Description
To ensure that the MS displays the incoming message (SMS with envelope command ‘display text /
get input / menu selection / setup menu’) even if between the request and the answer from the
network, a MT call incomes (the subscriber rejects the call)
Related GSM core specifications
None
Reason for test
To ensure that the MS receives/displays the incoming message (SMS command ‘display text / get
input / menu selection / setup menu’) even if between the access and the answer from the server, a
MT call incomes (the user rejects the call)
Initial configuration
MS sends a SAT request to the network and receive an incoming call before the reception of the SMS
of replay from the network.
Test procedure
Reject the call.
Expected behaviour
When the MS receives the answer form the network (SMS with envelope command) the MS displays
the text related to the SMS.
8.9.23 Receiving a WAP Push between the SAT request and the reception of
the SM Mobile Terminated with envelope / setup menu (display text /
get input / menu selection)
Description
To ensure that the MS displays the incoming message (SMS with envelope command ‘display text /
get input / menu selection / setup menu’) even if between the request and the answer from the
network, a WAP Push is received.
Related GSM core specifications
None
Reason for test
To ensure that the MS receives/displays the incoming message (SMS command with envelope
command) even if between the access and the answer from the network a WAP Push is received.
Initial configuration
Sends a SAT request to the network and receive a WAP Push before the reception of the SMS of
replay from the network (SMS with envelope command).
Test procedure
Accept the WAP Push.
Expected behaviour
When the MS receives the answer form the network (SMS with envelope command) the MS displays
the text related to the SMS with envelope command.
9 GPRS
NOTE: Tests covering the following subjects will be added at a later date
• GPRS attach, GSM attach and detach on a Network with GSM only cells and
GPRS enabled cells.
• Test of successful attach and detach
• Terminal behaviour when GPRS attach failed
• Cell selection and re-selection on GPRS networks.
• Testing in READY and STANDBY mode for different network control orders
1Note: The OS versions shall be kept up to date so as to be representative of the most used software
by the time the test list is executed.
Expected behaviour
The appropriate GPRS registration status is indicated on the display and, if automatic attach is
supported, the registration to the GPRS follows the GSM registration in an acceptable time.
9.2.3 GPRS attach with IMSI / with P-TMSI / with or without authentication
procedure
Description
Verify, that the MS performs correctly the operation of GPRS attach with IMSI / with P-TMSI / with or
without authentication procedure.
Reason for test
Ensure that the MS performs correctly the operation of GPRS attach.
Related GSM core specifications
GSM 04.08 section 4.7.3.1.
Initial configuration
Initially the MS must be in power off (if automatic attach is implemented) or in idle state (if manual
attach is implemented). The MS does not have a valid P-TMSI.
The network shall be configured to include the IMSI and P-TMSI signature in the ATTACH procedure.
Ciphering is not enabled.
Test procedure
1. GPRS attach with IMSI. Attach Request message from MS to SGSN includes Random TLLI
on BSSGP layer.
2. ATTACH is successful and MS is identified by IMSI on GMM layer. The SGSN includes the
P-TIMSI and the P-TIMSI signature in the ATTACH ACCEPT message. Take note of the P-
TIMSI. The MS stores the P-TIMSI and the signature in the SIM.
3. Perform normal GPRS Detach and power off the MS.
4. GPRS attach with P-TMSI (make sure that the P-TMSI passing through the Gb interface is
the same as the one noted in step 2)
The test shall be performed in NMO I (to verify all the combined procedure) and NMO II, with and
without Authentication and Ciphering.
Expected behaviour
The MS performs correctly the operation of GPRS attach with IMSI / with P-TMSI / with or without
authentication procedure.
9.2.7 GSM roaming allowed/GPRS Service not allowed (Reject cause #7)
Note: Some networks do not use reject cause #7 anymore and use #14 instead.
Description
Verify that the MS handles correctly the reject cause #7 (GPRS Roaming not allowed).
Reason for test
Ensure that the MS handles correctly the reject cause #7 (GPRS Roaming not allowed).
Related GSM core specifications
GSM 04.08, section 4.7.3
Initial configurations
Initially the MS must be in power off (if automatic attach is implemented) or in idle state (if manual
attach is implemented). A SIM is available which has a valid IMSI in the roaming network.
GSM Roaming is enabled in the visited PLMN. GPRS service is not enabled in the visited PLMN.
Test procedure
1) The MS is powered on in the HOME PLMN and performs IMSI attach (GSM attach successful)
and GPRS attach (GPRS attach successful).
2) The MS is moved to the VISITED PLMN and shall attempt to register to the VISITED SGSN
(GPRS attach does not succeed).
3) The MS is moved back to the HOME PLMN and shall not attempt the GPRS attach.
4) The MS is powered off then on. The MS shall perform GSM and GPRS attach successfully.
Expected behaviour
The MS is performing the GPRS Attach procedure accordingly and shall not attempt to perform a
second GPRS Attach or a PDP Context Activation in the VISITED PLMN. Back in the HOME PLMN
the MS shall offer full GPRS functionality.
Expected behaviour
The APN can be set manually in the MS via the MMI.
Initial configuration
The MS must be in standby or ready state.
Test procedure
Verify that the MS performs correctly all the operation related to the PDP context activation for modem
application with specified APN. Particularly verify the following case:
1. different APN
2. different QoS (try to change the QoS and analyze if the MS can support it): The test shall be
done changing the reliability class from 3 to 2.
This test shall be done with and without PBCCH.
Expected behaviour
The MS is performing the PDP context activation correctly.
Expected behaviour
The MS shall send a “modify PDP context accept” message in return. If the QoS are not acceptable
from the MS, it shall send a “deactivate PDP context request” message in return.
9.4.5 PDP context activation initiated by the UE, rejected by the network
with cause unknown APN
Description
Verify that the UE inform the user of reject of PDP context activation
Related 3GPP core specifications
3GPP TS 24.008
Reason for test
To ensure that the UE is not able to activate a PDP context with unknown APN.
Initial configuration
The UE is IMSI attached and PS attached in its 2G HPLMN
Test procedure
1. With an HyperTerminal connected to the UE, define the type of PDP context with the AT
Command AT+CGDCONT with unavailable APN (not defined in the HLR)
2. Initiate a dial-up networking session using any PS bearer supported by the UE and by its 2G
HPLMN.
3. Verify than the user is informed for PDP activation failure.
4. Repeat procedures 1 to 3 with Browsing embedded application.
Expected behaviour
The UE:
- is not establishing a PDP context activation connection
- informs the user about the failure
- releases the connection.
Initial conditions
There must be an appropriate number of 2G cells available on the same PLMN, and the device should
be in idle mode. The device should be IMSI attached, and Packet attached, with a PDP context, but
not transmitting any data.
Test procedure
Move between the coverage areas of different cells, ideally on a long test route. The test route should
contain as many of the scenarios listed below as possible. Ensure that the device performs
reselections as expected. During the reselections it is imperative the device remains in service at all
times, and that it can receive a call before and after the reselections. Where possible, this procedure
should be carried out as follows:
• Between cells sharing a Location Area and Routing Area.
• Between cells sharing a Location Area but not sharing a Routing Area.
• Between cells not sharing a Location Area.
• Between cells utilising the same GSM frequency band.
• Between cells belonging to different GSM frequency bands
• In areas of poor signal strength.
Expected Behaviour
The device should perform reselections correctly, without losing service, and it should be able to
receive calls before and after the reselections.
During the test the UE shall be continually transmitting and receiving data via use of suitable FTP
tools.
Expected Behaviour
The UE should perform reselections correctly, without losing service. Data transfer may pause during
reselection but resume on the new cell. It shall be able to receive calls after the reselections (which
may pause data transfer without DTM). The data session shall resume after releasing the voice call.
The data rate shall be as expected for the data bearer type assigned by the network throughout the
test, i.e. data rates proportional to the data bearer and signal quality shall be achieved both before and
after the cell reselections.
Expected behaviour
1. The average throughput result on DUT and the reference mobile shall be comparable (for
example within 10%) when both devices have identical multislot capabilities in uplink.
2. The GPRS connection and file download shall be stable on DUT
3. If extended dynamic allocation is supported, take MS log to verify uplink TS usage and
peak/average uplink throughput.
Identify a route with 2-3 cell reselections and a Routing Area Update
Both devices shall be on the same network.
Use a non-compressible data file for the test.
Test procedure
1. Activate PDP Context on DUT and reference device
2. Start on the identified route
3. Use DOS FTP to download a 15MB file on both laptops. If possible, utilize a server with
minimal latency to the GGSN.
4. Repeat the test 5 times, record the average FTP throughput.
Expected behaviour
1. The average throughput result on DUT and the reference mobile shall be comparable (for
example within 10%) when both devices have identical multislot capabilities in downlink.
2. The GPRS connection and file download shall be stable during cell reselection and RAU
10 EGPRS
NOTE 1: All data throughput test shall be performed during off-peak hour to avoid contention
with CS traffic in live networks
NOTE 2: This section only includes EGPRS specific tests. All test cases in section 9 shall
also be performed.
Initial configuration
The MS is GPRS attached and IMSI attached.
Use the MS in tethered mode as a modem for laptop
Identify the area where signal strength is medium (-70dBm to -90dBm)
Test procedure
1. Activate PDP Context
2. Use DOS FTP to download a 15MB file.
3. After download is complete, start a web browser and go to a few sites
4. Repeat steps 1-3 three times.
Expected behaviour
1. The EGPRS connection shall be stable
2. The file download shall complete
11.1.2 Attach Request with A5/3 Ciphering (NMO I network and combined
GPRS attach)
Description
Attach Request with A5/3 ciphering is performed.
Reason for test
To ensure ciphering with A5/3 algorithm during Attach Request.
Related GSM core specifications
3GPP TS 04.18, 44.018, 24.008, 55.216
Initial configuration
The test is performed in a 2G network which supports cipher algorithm A5/3 on both BSS and MSC
and
• the network is configured for NMO I
• and the DUT performs a combined GPRS attach (auto attach active)
Test procedure
1. The DUT is switched on in the 2G network
2. Verify that the DUT sends “encryption algorithm A5/3 available” within MOBILE STATION
Radio Access Capability in ATTACH REQUEST to the Network
3. Verify that the device receives “cipher with algorithm A5/3” within CIPHER MODE SETTING in
CIPHER MODE COMMAND from the network
4. The Location Updating is completed.
Expected behaviour
1. The device can be switched on.
2. The device sends “encryption algorithm A5/3 available”.
3. Cipher mode setting is set to “cipher with algorithm A5/3”
4. Location Updating is completed successfully and the device indicates service.
11.2.2.1 A5/3 <-> A5/1 Voice Handover (Call started in A5/3 Cell)
Description
A voice handover is performed where the call is started in A5/3 cell and cipher algorithm is changed
from A5/3 to A5/1 and backwards.
11.2.2.2 A5/1 <-> A5/3 Voice Handover (Call started in A5/1 Cell)
Description
A voice handover is performed where the call is started in A5/1 cell and cipher algorithm is changed
from A5/3 to A5/1 and backwards.
Reason for test
To ensure ciphering is working during handovers in mixed A5/3 and A5/1 network environment.
Related GSM core specifications
3GPP TS 04.18, 44.018, 24.008, 55.216.
Initial configuration
For this test a 2G network is required which supports an A5/1 – A5/3 neighbour cell configuration. For
the A5/1 cell cipher algorithm A5/3 is supported on both on both BSS and MSC. At least one cell with
A5/1 support and one cell with A5/3 are required.
A second device (PSTN or mobile phone) is required.
Test procedure
1. The DUT is switched on in an A5/1 cell.
2. A mobile originated or terminated speech call between the DUT and the second phone (PSTN
or mobile) is performed.
3. Move from the coverage area of the A5/1 only cell to a neighbour cell supporting A5/3. Ensure
that the call is not dropped. Check the end to end voice connection.
4. Verify that the device receives “cipher with algorithm A5/3” within CIPHER MODE SETTING in
HANDOVER COMMAND from the network
5. Repeat toggling between A5/3 and A5/1 cell and back at least 4 times. Ensure that the call is
not dropped. Check the end to end voice connection.
Expected behaviour
1. –
2. –
3. Handover to A5/3 cell is successful and the call is not dropped. End to end voice connection is
still available
4. Cipher mode setting is set to “cipher with algorithm A5/3”
5. All handovers are successful and the call is not dropped. End to end voice connection is still
available.
Direction
Step Message Comments
UE - NW
8 SECURITY MODE COMMAND RRC
9 SECURITY MODE COMPLETE RRC
10 LOCATION UPDATING ACCEPT GMM
11 TMSI REALLOCATION COMPLETE MM
12 RRC CONNECTION RELEASE RRC
13 RRC CONNECTION RELEASE COMPLETE RRC
5. The UMTS network shall respond to the UE with a LOCATION UPDATING REJECT with
Reject Cause #15 ‘No Suitable Cells In Location Area’.
6. Check that the UE stores the LAI of the second LA in UMTS technology in the list of
"forbidden location areas for roaming".
7. Check that the UE has still stored the LAI of the first LA in UMTS technology in the list of
"forbidden location areas for roaming".
8. Check that the UE performs a Location Update procedure on a LA in GSM technology of the
same PLMN.
9. The network shall respond to the UE with a LOCATION UPDATING ACCEPT that may
contain a new TMSI.
10. If the LOCATION UPDATING ACCEPT contained a new TMSI, then verify that the UE
acknowledges this message by sending a TMSI REALLOCATION COMPLETE. Otherwise,
no TMSI REALLOCATION COMPLETE shall be sent.
11. Check that the UE is able to receive a call.
Expected behaviour
1. The UE performs a Location Updating procedure using Location Updating Type = 2 (IMSI
attach).
3. The UE stores the LAI in the list of “forbidden location areas for roaming”
4. The UE performs a Location Update procedure on a second LA in UMTS technology of the
same PLMN.
6. The UE stores the LAI of the second UMTS LA in the list of “forbidden location areas for
roaming”
7. The UE has stored both LAIs from the UMTS PLMN in the list of “forbidden location areas for
roaming”. The UE is not reselecting the first LA in UMTS technology of the same PLMN.
8. The UE performs a Location Update procedure on a LA in GSM technology of the same
PLMN.
10. The UE registers the new TMSI correctly
Direction
Step Message Comments
UE - NW
1 SYSTEM INFORMATION (BCCH) LAI = a, UMTS
In UMTS PLMN ‘A’,
2 RRC CONNECTION REQUEST (CCCH)
LAI = a
3 RRC CONNECTION SETUP (CCCH)
4 RRC CONNECTION SETUP COMPLETE (DCCH)
Location Updating
5 LOCATION UPDATING REQUEST Type = 2 (IMSI
attach)
Reject Cause #15
6 LOCATION UPDATING REJECT ‘No Suitable Cells
In Location Area’
7 RRC CONNECTION RELEASE
8 RRC CONNECTION RELEASE COMPLETE
9 SYSTEM INFORMATION (BCCH) LAI = b, UMTS
In UMTS PLMN ‘A’,
10 RRC CONNECTION REQUEST (CCCH)
LAI = b
11 RRC CONNECTION SETUP (CCCH)
12 RRC CONNECTION SETUP COMPLETE (DCCH)
Location Updating
13 LOCATION UPDATING REQUEST Type = 2 (IMSI
attach)
Reject Cause #15
14 LOCATION UPDATING REJECT ‘No Suitable Cells
In Location Area’
15 RRC CONNECTION RELEASE
16 RRC CONNECTION RELEASE COMPLETE
Direction
Step Message Comments
UE - NW
17 SYSTEM INFORMATION (BCCH)
In GSM PLMN ‘A’,
18 RRC CONNECTION REQUEST (CCCH)
LAI = c
19 RRC CONNECTION SETUP (CCCH)
20 LOCATION UPDATING REQUEST
21 AUTHENTICATION REQUEST
22 AUTHENTICATION RESPONSE
23 SECURITY MODE COMMAND
24 SECURITY MODE COMPLETE
25 LOCATION UPDATING ACCEPT
26 TMSI REALLOCATION COMPLETE
27 RRC CONNECTION RELEASE
28 RRC CONNECTION RELEASE COMPLETE
20.1.3 IMSI Attach; Rejected (Reject Cause #13: Roaming not allowed in this
Location Area)
Description
The UE shall perform a new PLMN selection after being rejected with Reject Cause #13 ‘Roaming not
allowed in this location area’.
Related 3GPP core specifications
3GPP TS 24.008 4.4.4.7 (Location updating not accepted by the network)
Reason for test
To verify that the UE successfully performs the IMSI attach procedure on another RAT of the same
PLMN after being rejected with Reject Cause #13 ‘Roaming not allowed in this location area’.
Initial configuration
• ATT = 1
• USIM with "User Controlled PLMN Selector with Access Technology" (EFPLMNwAcT) indicating,
in the first position, PLMN ‘A’ and Access Technology Identifier ‘UTRAN’
• USIM with "User Controlled PLMN Selector with Access Technology" (EFPLMNwAcT) indicating,
in the second position, PLMN ‘B’ and Access Technology Identifier ‘GSM’ (PLMN ‘B’ may be
the same as PLMN ‘A’)
• No Roaming with the UMTS PLMN ‘A’
• 2 different Location Areas in the UMTS PLMN ‘A’
• Roaming allowed with the GSM PLMN ‘B’ (PLMN ‘B’ may be the same as PLMN ‘A’)
• UE is powered off
Test procedure
1. Power on the UE and verify that the UE sends a LOCATION UPDATING REQUEST to the
UMTS network.
2. The UMTS network shall respond to the UE with a LOCATION UPDATING REJECT with
Reject Cause #13 ‘Roaming not allowed in this location area’.
3. Check that the UE stores the LAI in the list of "forbidden location areas for roaming".
4. Check that the UE performs a PLMN selection instead of selecting immediately the second
LA in UMTS technology of the same PLMN.
5. Check that, after the PLMN selection, the UE performs a Location Update procedure on the
second LA in UMTS technology of the same PLMN.
6. The UMTS network shall again respond to the UE with a LOCATION UPDATING REJECT
with Reject Cause #13 ‘Roaming not allowed in this location area’.
7. Check that the UE stores the LAI of the second LA in UMTS technology in the list of
"forbidden location areas for roaming".
8. Check that the UE has still stored the LAI of the first LA in UMTS technology in the list of
"forbidden location areas for roaming".
9. Check that, after a new PLMN selection, the UE performs a Location Update procedure on a
LA in GSM technology of PLMN ‘B’.
10. The network shall respond to the UE with a LOCATION UPDATING ACCEPT.
11. Check that the UE is able to receive a call.
Expected behaviour
1. The UE performs a Location Updating procedure.
3. The UE stores the LAI in the list of “forbidden location areas for roaming”.
4. The UE performs a new PLMN selection.
5. The UE performs a Location Update procedure on a second LA in UMTS technology of the
same PLMN.
6. -
7. The UE stores the LAI of the second UMTS LA in the list of “forbidden location areas for
roaming”.
8. The UE has stored both LAIs from the UMTS PLMN in the list of “forbidden location areas for
roaming”.
9. The UE performs a new PLMN selection. The UMTS LAs can’t be selected. The UE
performs a Location Update procedure on a LA in GSM technology of PLMN ‘B’.
10. The UE registers correctly.
11. The UE receives an incoming call.
3. The network shall respond to the UE with an ATTACH ACCEPT that may contain a new P-
TMSI.
4. If the ATTACH ACCEPT contained a new P-TMSI, then verify that the UE acknowledges this
message by sending an ATTACH COMPLETE. Otherwise, no ATTACH COMPLETE shall
be sent.
5. Power off the UE and verify that the UE sends a DETACH REQUEST indicating Detach type
= “power switched off, GPRS detach”. The network shall not acknowledge this message.
Expected behaviour
2. The UE performs a GPRS Attach procedure.
Direction
Step Message Comments
UE – NW
1 SYSTEM INFORMATION (BCCH) MW broadcast
2 RRC CONNECTION REQUEST (CCCH) RRC
3 RRC CONNECTION SETUP (CCCH) RRC
4 RRC CONNECTION SETUP COMPLETE (DCCH) RRC
5 ATTACH 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 ATTACH ACCEPT GMM
11 ATTACH COMPLETE GMM
12 RRC CONNECTION RELEASE RRC
13 RRC CONNECTION RELEASE COMPLETE RRC
4. Trigger a GPRS Attach procedure (e.g. via AT command). Check whether the UE registers
to the new network.
Expected behaviour
1. The UE is performing successfully an IMSI Attach procedure.
2. The UE attempts to perform a GPRS Attach procedure.
4a. If Reject Cause was ‘#7 GPRS services not allowed (e.g. Ericsson)’: The UE does not
attempt at all to perform a GPRS Attach procedure until it is powered off or the SIM card is
removed. The P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number is
deleted.
4b. If Reject Cause was ‘#14 GPRS services not allowed in this PLMN (e.g. NEC-SGSN)’: The
P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number is deleted. The
UE will re-attempt to perform a GPRS Attach procedure in the new PLMN.
20.2.3 Network Initiated GPRS Detach, Re-attach not required (#7 GPRS
services not allowed)
Description
Check the UE’s behaviour at network initiated GPRS Detach, when the network indicates that Re-
attach is not required.
Related 3GPP core specifications
3GPP TS 24.008 4.7.4.2 (Network initiated GPRS detach procedure)
Reason for test
To verify that the UE does not perform any GPRS Attach procedure before it is powered off and on
again.
Initial configuration
UE is idle and GPRS Attached.
Test procedure
1. The NW sends the Detach Request message (Detach type = ‘re-attach not required’, Cause
=#7 ‘GPRS services not allowed’).
2. Check the GPRS display indication.
3. Attempt to perform a GPRS Attach procedure via AT command.
4. Perform a GPRS Attach after the UE is powered off and powered on again.
Expected behaviour
1. The UE returns the Detach Accept message at the time of the reception of the Detach
Request message. The UE does not indicate GPRS services any more on the display.
2. The UE does not indicate GPRS services on the display.
3. When the UE receives the Detach Request message (Detach type = ‘re-attach not required’,
Cause =#7 ‘GPRS services not allowed’) from the NW, the UE
• does not perform GPRS Attach
• deletes the stored RAI, P-TMSI, P-TMSI signature, and GPRS-CKSN.
4. The UE performs GPRS Attach after it is powered off and powered on again.
20.2.4 Network Initiated GPRS Detach, Re-attach not required (#14 GPRS
service not allowed in this PLMN)
Description
Check the UE’s behaviour at network initiated GPRS Detach, when the network indicates that Re-
attach is not required.
“IMSI” value. If it is not the first time the handset attaches, check that in the ATTACH
REQUEST message the “type of identity” parameter holds the “TMSI/ P-TMSI” value.
6. If the ATTACH ACCEPT contained a new “TMSI/P-TMSI” value, then verify that the UE
acknowledges this message by sending an ATTACH COMPLETE. Otherwise, no ATTACH
COMPLETE shall be sent.
7. Power off the UE and verify that the UE sends a DETACH REQUEST that in the DETACH
REQUEST message, the “Detach type” parameter holds the “power switched off, combined
GPRS / IMSI detach” value. If the detach is not done at power off, the “Detach type”
parameter will hold the “normal, combined GPRS / IMSI detach” value and the network will
answer back to the DETACH REQUEST with a DETACH ACCEPT message.
Expected behaviour
2. The UE performs a combined Attach procedure as follows:
Direction
Step Message Comments
UE – NW
1 SYSTEM INFORMATION (BCCH) MW broadcast
2 RRC CONNECTION REQUEST (CCCH) RRC
3 RRC CONNECTION SETUP (CCCH) RRC
4 RRC CONNECTION SETUP COMPLETE (DCCH) RRC
5 ATTACH 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 ATTACH ACCEPT GMM, New
TMSI/P-TMSI
11 ATTACH COMPLETE GMM
12 RRC CONNECTION RELEASE RRC
13 RRC CONNECTION RELEASE COMPLETE RRC
3. In the ATTACH REQUEST message, the “Attach type” parameter holds the “Combined
GPRS / IMSI attach” value.
4. The “Attach result“ parameter in the ATTACH ACCEPT message holds the “Combined
GPRS / IMSI attached” value.
5. If it is the first time the handset attaches on the network (it was on another one beforehand),
the “type of identity” parameter in the ATTACH REQUEST message holds the “IMSI” value.
If it is not the first time the handset attaches, the “type of identity” parameter in the ATTACH
REQUEST message holds the “TMSI/ P-TMSI” value.
6. If the ATTACH ACCEPT contained a new “TMSI/P-TMSI” value, the UE acknowledges this
message by sending an ATTACH COMPLETE. Otherwise, no ATTACH COMPLETE shall
be sent.
7. The UE sends a DETACH REQUEST message, the “Detach type” parameter holds the
“power switched off, combined GPRS / IMSI detach” value. If the detach is not done at
power off, the “Detach type” parameter will hold the “normal, combined GPRS / IMSI detach”
value and the network will answer back to the DETACH REQUEST with a DETACH
ACCEPT message.
• Changing PLMNs
• Using two identical (U)SIM cards which are registered in the network at the same time
• Alternatively: Change TMSI and LAI on the (U)SIM to a different but valid figure and then
perform an IMSI Attach Procedure.
Test procedure
8. Move the UE from the initial cell into a cell with a different LAI till the UE performs a cell
reselection.
9. The UE shall send a LOCATION UPDATE REPQUEST message to the network containing a
TMSI which is not known by the network. Check whether the “location updating type”
parameter holds the “normal” value.
10. Check that the network initiates an Identification Procedure requesting the UE’s IMSI.
11. Check that the UE sends its IMSI to the network.
12. The network shall then send a LOCATION UPDATE ACCEPT message to the UE. This
message contains a new TMSI for the UE and the LAI for the new cell.
13. Check that the UE is not indicating loss of coverage.
14. Check that the UE responds to paging in the new cell by calling the UE.
Expected behaviour
The UE performs the ‘Normal Location Update’ procedure (including Identification Procedure) without
coverage loss indication and receives an incoming call.
Direction
Step Message Comments
UE - NW
"Establishment cause":
1 RRC CONNECTION REQUEST
Registration.
2 RRC CONNECTION SETUP
3 RRC CONNECTION SETUP COMPLETE
"location updating type" = normal,
"CKSN" = CKSN1, "location area
4 LOCATION UPDATING REQUEST identification" = a, "mobile station
classmark 1" and "mobile identity"
= TMSI1.
5 IDENTITY REQUEST IMSI
6 IDENTITY RESPONSE UE responds with its IMSI
7 AUTHENTICATION REQUEST MM
8 AUTHENTICATION RESPONSE MM
9 SECURITY MODE COMMAND
10 SECURITY MODE COMPLETE
"Mobile identity" = new TMSI
11 LOCATION UPDATING ACCEPT
(=TMSI2), LAI = b.
12 TMSI REALLOCATION COMPLETE
13 RRC CONNECTION RELEASE
14 RRC CONNECTION RELEASE COMPLETE
Direction
Step Message Comments
UE - NW
identification" = a, "mobile station
classmark 1" and "mobile identity"
= TMSI1.
Reject Cause #15 ‘No Suitable
5 LOCATION UPDATING REJECT
Cells In Location Area’
6 RRC CONNECTION RELEASE
7 RRC CONNECTION RELEASE COMPLETE
In PLMN ‘A’, LAI = c, UMTS
8 RRC CONNECTION REQUEST technology, "Establishment cause":
Registration
9 RRC CONNECTION SETUP
10 RRC CONNECTION SETUP COMPLETE
"location updating type" = normal,
"location area identification" = a,
11 LOCATION UPDATING REQUEST
"mobile station classmark 1" and
"mobile identity" = IMSI.
Reject Cause #15 ‘No Suitable
12 LOCATION UPDATING REJECT
Cells In Location Area’
13 RRC CONNECTION RELEASE
14 RRC CONNECTION RELEASE COMPLETE
In PLMN ‘A’, LAI = d, GSM
15 RRC CONNECTION REQUEST technology, "Establishment cause":
Registration
16 RRC CONNECTION SETUP
17 RRC CONNECTION SETUP COMPLETE
"location updating type" = normal,
"location area identification" = a,
18 LOCATION UPDATING REQUEST
"mobile station classmark 1" and
"mobile identity" = IMSI.
19 AUTHENTICATION REQUEST
20 AUTHENTICATION RESPONSE
21 SECURITY MODE COMMAND
22 SECURITY MODE COMPLETE
"Mobile identity" = new TMSI
23 LOCATION UPDATING ACCEPT
(=TMSI2), LAI = d.
24 TMSI REALLOCATION COMPLETE
25 RRC CONNECTION RELEASE
26 RRC CONNECTION RELEASE COMPLETE
Direction
Step Message Comments
UE - NW
Registration
9 RRC CONNECTION SETUP
10 RRC CONNECTION SETUP COMPLETE
"location updating type" = normal,
"location area identification" = a,
11 LOCATION UPDATING REQUEST
"mobile station classmark 1" and
"mobile identity" = IMSI.
Reject Cause #12 ‘Location Area
12 LOCATION UPDATING REJECT
Not Allowed’
13 RRC CONNECTION RELEASE
14 RRC CONNECTION RELEASE COMPLETE
In PLMN ‘A’, LAI = d, GSM
15 RRC CONNECTION REQUEST technology, "Establishment cause":
Registration
16 RRC CONNECTION SETUP
17 RRC CONNECTION SETUP COMPLETE
"location updating type" = normal,
"location area identification" = a,
18 LOCATION UPDATING REQUEST
"mobile station classmark 1" and
"mobile identity" = IMSI.
19 AUTHENTICATION REQUEST
20 AUTHENTICATION RESPONSE
21 SECURITY MODE COMMAND
22 SECURITY MODE COMPLETE
"Mobile identity" = new TMSI
23 LOCATION UPDATING ACCEPT
(=TMSI2), LAI = d.
24 TMSI REALLOCATION COMPLETE
25 RRC CONNECTION RELEASE
26 RRC CONNECTION RELEASE COMPLETE
Direction
Step Message Comments
UE - NW
"Establishment cause":
1 RRC CONNECTION REQUEST
Registration.
2 RRC CONNECTION SETUP
3 RRC CONNECTION SETUP COMPLETE
4 LOCATION UPDATING REQUEST "location updating type" = periodic
(5) AUTHENTICATION REQUEST Optional
(6) AUTHENTICATION RESPONSE Optional
(7) SECURITY MODE COMMAND Optional
(8) SECURITY MODE COMPLETE Optional
9 LOCATION UPDATING ACCEPT
(10) TMSI REALLOCATION COMPLETE Optional
11 RRC CONNECTION RELEASE
12 RRC CONNECTION RELEASE COMPLETE
Initial configuration
The UE shall be attached in Circuit mode and in idle state, T3212 is running.
Test procedure
1. Move the UE out of coverage (no other network available). The ‘out of coverage time’ should
last for ¾ of the interval of T3212.
2. Bring the UE back to coverage (same PLMN / Location Area as before) before T3212
expires. When gaining back coverage, check that the UE does not perform a Location Update
procedure.
3. Wait for the T3212 timer to expire, and observe if the UE sends the network a LOCATION
UPDATE REQUEST message. Check whether the “location updating type” parameter holds
the “periodic updating” value.
4. Check that the UE responds to paging after the Location Update procedure.
5. Repeat procedure 1. – 4. when the UE is performing Emergency Camping on a different
PLMN while out of service.
Expected behaviour
The UE does not perform a Location Update procedure after regaining service but waits until T3212
expiry to perform the Location Update procedure. The UE receives an incoming call after each test.
3. In the ROUTING AREA UPDATING REQUEST message, the “Update type” parameter holds
the “Combined RA/LA updating” value.
4. In the ROUTING AREA UPDATING ACCEPT message, the “Update result“ parameter holds
the “Combined RA/LA updated” value.
5. The UE stores the new “TMSI/P-TMSI” value and acknowledges the ROUTING AREA
UPDATING ACCEPT message by sending a ROUTING AREA UPDATING COMPLETE
message.
6. The UE receives an incoming call in the new cell.
7. The UE can establish a packet data connection in the new cell.
Test procedure
The test can be performed in a live network or a system simulator. The reason for using a system
simulator is simply that the network conditions (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Test procedure
The test can be performed in a live network or optionally on a system simulator. The reason for using
a system simulator is simply that the network condition (i.e. received signal strength of the BCCH by
the UE) can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
Procedure B (Alternative test performed on a system simulator)
The UE is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way, that the UE receives the
signal strength for GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
Expected behaviour
The UE shall select the prioritised PLMN network and ignore the non-prioritised PLMNs.
Test procedure
The test can be performed in a live network or optionally on a system simulator. The reason for using
a system simulator is simply that the network condition (i.e. received signal strength of the BCCH by
the UE) can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
Procedure B (Alternative test performed on a system simulator)
The UE is powered up.
The non-prioritised network(s) should transmit with a higher power than the prioritised
network. The prioritised network should transmit in such a way, that the UE would
receive the signal strength for GSM better than –85 dBm or primary CPICH RSCP
better than -95 dBm for UMTS-FDD.
Expected behaviour
The UE shall select the prioritised PLMN and ignore the non-prioritised PLMNs.
For terminals supporting GSM only, the system simulator shall provide at least 2 networks on GSM
frequencies with a field strength better than –85 dBm.
Test procedure
Procedure A
The UE is switched on and the selected network is noted. Afterwards the UE is switched off and
the SIM is prepared for the next loop as stated above.
Procedure B
Before each test loop, the UE shall perform successfully a location updating procedure at the
system simulator. The selected network is noted. Afterwards the UE is switched off and the SIM
is prepared for the next loop as stated above.
As it is impossible to check the random balance by repeating the test a few times it will be checked
that each available network is at least selected once. When this condition is reached the test loop can
be stopped. The device fails the test when at least one network is not selected after repeating the test
N times. The maximum number of repetitions N depends on the number of networks, i.e. different
number of MCC/MNC combinations:
No of MCC/MNC Maximum number of
combinations repetitions
2 7
3 12
4 16
5 21
n 2/(Log10(n)-Log10 (n-1))
This table is based on the assumption that after reaching the maximum number of repetition a
correctly implemented UE would have selected each network at least once with a probability of better
than 99%.
Expected behaviour
After each procedure, the UE performs an automatic network selection. The network selection was
performed in a random balance. When repeating the procedure N times (as defined above) the UE
has selected each available network (with a field strength better than –85 dBm for GSM and a primary
CPICH RSCP better than -95 dBm for UMTS-FDD) at least once.
UE is switched on, in automatic network selection mode, located outside the coverage area of the
HPLMN and camps on VPLMN A.
Initial conditions for Procedure B
A system simulator with at least 3 PLMNs is used.
A Prioritised Network BCCH (amongst other non- prioritised networks BCCH) is broadcasted.
A SIM (compliant to Rel-98 or earlier) with the same prioritised network located in the last entry of
EFPLMNsel.
UE is switched on, in automatic network selection mode and camps on the VPLMN A.
Initial conditions for the SIM card (both Procedures)
The SIM card shall support preferably 64 (but not less than 32) entries on the Preferred PLMN list.
Forbidden PLMN (EFFPLMN): FF FF FF FF FF FF FF FF FF FF FF FF
Broadcast Control Channels(EFBCCH): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PLMN Selector (EFPLMNsel) MCC / MNC of VPLMN A is stored on the last but one position.
MCC /MNC of VPLMN B is stored on the last position. All other
fields are filled with network codes corresponding to networks
not available at the test location.
In addition to this shall the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
UE has already successfully selected the prioritised network and if left on, in automatic network
selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE was powered up at a location, where not less than 3 networks are available
with a field strength for GSM better than –85 dBm or primary CPICH RSCP better than
-95 dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around the coverage of VPLMN A gets lost (for all radio access
technologies of this PLMN). The UE looses the network and searches for a new
VPLMN. The location where VPLMN A is lost should be found within EFHPPLMN (Higher
Priority PLMN search period) after switching on the phone, to prevent the device from
searching for a higher prioritised network.
Procedure B (Alternative test performed on a system simulator)
The UE is powered up VPLMN A is selected.
The non-prioritised network(s) (excluding VPLMN A / VPLMN B) should transmit with a
higher power than VPLMN B. All networks should transmit in such a way, that the UE
would receive the signal strength for GSM better than –85 dBm or primary CPICH
RSCP better than -95 dBm for UMTS-FDD.
The signal level of VPLMN A is changed so the serving network is lost. The UE starts
searching for a new VPLMN.
Expected behaviour
The UE shall select the prioritised network VPLMN B and ignore the non-prioritised PLMNs.
In addition to this the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
UE has already successfully selected the prioritised network and if left on, in automatic network
selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE was powered up at a location, where not less than 3 networks are available
with a field strength for GSM better than –85 dBm or primary CPICH RSCP better than
-95 dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN) so that the UE looses the network and is forced to search
for a new network.
A Prioritised Network BCCH (amongst other non- prioritised networks BCCH) is broadcasted.
Two UICCs (one with SIM only, one with both SIM and USIM) (compliant to Rel-99 or later) are
required, with the prioritised networks VPLMN A and VPLMN B located in the last two entries of
EFPLMNwAcT / EFOPLMNwAcT.
UE is switched on, in automatic network selection mode and camps on the VPLMN A.
Initial conditions for the UICC (both Procedures)
The SIM card shall support preferably 64 (but not less than 32) entries on the EFPLMNsel and 50 (but not
less than 32) entries on the EFPLMNwACT and EFOPLMMNwACT.
Forbidden PLMN (EFFPLMN): FF FF FF FF FF FF FF FF FF FF FF FF
PLMN Selector (EFPLMNwAcT) The MCC / MNC of the Preferred PLMNs VPLMN A, VPLMN B
and VPLMN D must NOT be stored in EFPLMNwAcT
PLMN Selector (EFOPLMNwAcT) The MCC / MNC of VPLMN A is stored on the last but one
position. MCC /MNC of VPLMN B is stored on the last position:
UICC PLMN Selector
1) SIM only EFOPLMNwAcT
2) SIM and USIM EFOPLMNwAcT
The test procedure shall be repeated for both UICCs.
All other fields in both EFOPLMNwAcT are filled with network codes
corresponding to networks not available at the test location.
Access Technology (2 bytes, set to 80 80)
PLMN Selector (EFPLMNsel) The MCC/MNC of Network D shall be stored in EFPLMNsel. With
this method it is tested that the UE ignores EFPLMNsel when
EFPLMNwAcT or EFOPLMNwAcT is available.
In addition to this the HPLMN Search Period Timer be set at least to 30 minutes (“05”)
UE has already successfully selected the prioritised network and if left on, in automatic network
selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE was powered up at a location, where not less than 3 networks are available
with a field strength for GSM better than –85 dBm or primary CPICH RSCP better than
-95 dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN) so that the UE looses the network and is forced to search
for a new network.
Procedure B (Alternative test performed on a system simulator)
The UE is powered up and VPLMN A is selected.
The non-prioritised network(s) (excluding VPLMN A / VPLMN B) should transmit with a
higher power than VPLMN B. All networks should transmit in such a way, that the UE
would receive the signal strength for GSM better than –85 dBm and primary CPICH
RSCP better than -95 dBm for UMTS-FDD.
The signal level of VPLMN A is changed so the serving network gets lost. The UE starts
searching for a new VPLMN.
Expected behaviour
The UE shall select the prioritised network VPLMN B and ignore the non-prioritised PLMNs.
For this test a special SIM or UICC (with SIM only or with both SIM and USIM) is recommended. For
this card the HPLMN Search Period Timer (EFHPPLMN) be set to 6 minutes (“01”)
UE has already successfully selected the prioritised network VPLMN A and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM. This can be proved using a reference UE with a
network monitor mode.
While driving around the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN). The device should select VPLMN B.
One drives to a location where both, VPLMN A and VPLMN B are available.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer
(EFHPPLMN) so that a PLMN background scan is activated.
For this test a special SIM or UICC (with SIM only or with both SIM and USIM) is recommended. For
this card the HPLMN Search Period Timer (EFHPPLMN) be set to 6 minutes (“01”).
UE has already successfully selected the prioritised network VPLMN A and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN). The device shall then select a non prioritised VPLMN.
One drives to a location where both, VPLMN A and the non prioritised VPLMN are
available.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer
(EFHPPLMN) so ensure a PLMN background scan is activated.
Procedure B (Alternative test performed on a system simulator)
A non prioritised VPLMN is the only available network. The UE is powered up and
selects this VPLMN.
The radio conditions are changed so VPLMN A and at least two non-prioritised
network(s) is available. The VPLMN the device camps on should transmit with a higher
power than the other networks but all network should transmit in such a way, that the
UE would receive the signal strength for GSM better than –85 dBm and primary CPICH
RSCP better than -95 dBm for UMTS-FDD.
The tester shall wait HPLMN Search Period Timer (EFHPPLMN) until PLMN background
scan is activated.
Expected behaviour
It shall be checked that the device selects VPLMN A after expiry of HPLMN Search Period Timer
(EFHPPLMN).
For this test a special SIM or UICC (with SIM only or with both SIM and USIM) is recommended. For
this card the HPLMN Search Period Timer (EFHPPLMN) be set to 6 minutes (“01”).
UE has already successfully selected the prioritised network VPLMN A and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN). The device shall then select VPLMN B.
One drives to a location where both, VPLMN A and VPLMN B are available.
The tester start a voice call and waits until HPLMN Search Period Timer (EFHPPLMN) is
expired. Afterwards the call is released.
Procedure B (Alternative test performed on a system simulator)
VPLMN B is the only available network. The UE is powered up and selects VPLMN B.
The radio conditions are changed so VPLMN A, VPLMN B and at least one non-
prioritised network(s) is available. VPLMN B should transmit with a higher power than
the other networks but all network should transmit in such a way, that the UE would
receive the signal strength for GSM better than –85 dBm and primary CPICH RSCP
better than -95 dBm for UMTS-FDD.
The tester start a voice call and waits until HPLMN Search Period Timer (EFHPPLMN) is
expired. Afterwards the call is released.
Expected behaviour
It shall be checked that the voice call is active while HPLMN Search Period Timer (EFHPPLMN) expired.
After releasing the call the UE shall re-select the higher priority PLMN A.
For this test a special SIM or UICC (with SIM only or with both SIM and USIM) is recommended. For
this card the HPLMN Search Period Timer (EFHPPLMN) be set to 6 minutes (“01”)
UE has already successfully selected the prioritised network VPLMN A and if left on, in automatic
network selection mode.
Test procedure
The test can be performed in a live network or on a system simulator. The reason for using a system
simulator is simply that the network condition (i.e. received signal strength of the BCCH by the UE)
can be configured easily and the conditions seen by the mobile can be assured).
Either procedure A or B needs to be tested
Procedure A (On a feasible location)
The UE is powered up at a location, where not less than 3 networks are available with a
field strength of GSM better than –85 dBm or primary CPICH RSCP better than -95
dBm for UMTS-FDD.
For devices supporting GSM only, ensure that not less than 2 GSM networks are
available with a field strength for GSM better than –85 dBm. This can be proved using a
reference UE with a network monitor mode.
While driving around, the coverage of VPLMN A shall be lost (for all radio access
technologies of this PLMN). The device shall then select VPLMN B.
One drives to a location where both, VPLMN A and VPLMN B are available.
The tester activates a PDP context and starts data transfer. The HPLMN Search Period
Timer (EFHPPLMN) expires during data transfer. Afterwards the PDP context is
deactivated.
Initial configuration
UE in idle mode, with automatic network selection mode configured.
Test procedure
1. Change to manual network selection. Turn the UE off and on again. Check that the manual
network selection mode is in use.
2. Change to automatic network selection. Turn the UE off and on again. Check that the
automatic network selection mode is in use.
Expected behaviour
The UE has the same selection mode when switched on that it had when switched off.
Initial configuration
• UE switched off, with following configuration:
o Automatic network selection mode
o GPRS Attach at power on enabled
• Test to happen in live network
• Networks available:
o PLMN1: Dual Mode (GSM/W-CDMA)
o PLMN2: At least Single Mode
o PLMN3: Dual Mode (GSM/W-CDMA)
o PLMN4: Single Mode
Note: It would be ideal, if all of the available networks are Multi Mode networks (i.e. GSM
Dual Band and W-CDMA). The more complex the network environment is, the
higher will be the confidence in the Device under Test to comply with Steering of
Roaming.
• Used SIM card: Roaming SIM Card (PLMN 5, different MCC)
• Assisted Roaming deactivated on SIM card
• SIM Card preparation (using SIM R/W Tool):
o PLMN1 and PLMN2 on forbidden PLMN list (EFFPLMN)
o No PLMN of the country where the test is carried out is stored on the preferred PLMN list
(EFPLMNwAcT and EFOPLMNwAcT), but both, EFPLMNwAcT and EFOPLMNwAcT are filled up with PLMNs
from other MCCs
o EFLOCI = PLMN5, LAI=1234, TMSI=12345678, Update Status= 00 (Updated)
• Managed Roaming System of PLMN5 (Roaming SIM) configured as follows:
o PLMN1 = Preferred Network of the Managed Roaming System = PN
o All other PLMNs of this country (PLMN2, PLMN3, PLMN4) = Non-preferred Network of the
Managed Roaming System = NPN
Test procedure
Scenario A: Multi Network Environment
1. Perform a successful Manual Network Selection on PLMN2 to re-set VLR/HLR entries
2. Switch Device under Test (DuT) to Automatic Network Selection
3. Switch off Device under Test
4. Prepare SIM to fulfil Initial Conditions (using SIM R/W Tool)
5. Switch on DuT, 4 IMSI Attach attempts on PLMN3 or PLMN4 (e.g. PLMN3). During IMSI Attach,
the UE performs GPRS Attach, GPRS Attach is accepted after the first attempt.
6. Check that display service indicator(s) are consistent
7. Check that a further IMSI Attach is performed after 4 rejects on another PLMN (e.g. PLMN4) until
the UE is in full service (i.e. PS and CS attached)
8. Check that display service indicator(s) are consistent
Scenario B: Manual Network Selection
9. Perform manual Network Selection on non-preferred RPLMN (which will fail) on other PLMN than
selected in step 7 (e.g. PLMN3)
Note1: There may be a need to wait several minutes before this step is performed in order
to allow the Managed Roaming System to reset its counters and timers so that
further Steering of Roaming can be applied.
Note2: If the manual Network Selection is accepted by the network, step 9 of this test is
inconclusive and shall be repeated after the Managed Roaming System is ready to
steer the CS registration again.
10. Perform further attempt of manual NW selection (successful) on same PLMN as in step 9 (e.g.
PLMN3)
11. Check that display messages are consistent and manual network selection is possible and
successful
12. Switch off Device under Test
Scenario C: Single Network Environment
13. Add the last successfully registered PLMN (e.g. PLMN3) to the forbidden PLMN list (EFFPLMN) by
using e.g. a SIM R/W Tool. In this case, PLMN1, PLMN2 and e.g. PLMN3 are on the forbidden
PLMN list (EFFPLMN)
14. Switch on DuT, 4 IMSI Attach attempts on e.g. PLMN4. During IMSI Attach, the UE performs
GPRS Attach, GPRS Attach is accepted after the first attempt.
Note1: There may be a need to wait several minutes before this step is performed in order
to allow the Managed Roaming System to reset its counters and timers so that
further Steering of Roaming can be applied.
Note2: If the CS registration is accepted by the network, step 14 of this test is inconclusive
and shall be repeated after the Managed Roaming System is ready to steer the CS
registration again.
15. Check that display service indicator(s) are consistent
16. Check that one (and not more) further IMSI Attach procedure is performed after 4 rejects on the
same PLMN (e.g. PLMN4) until the UE is in full service (i.e. PS and CS attached).
17. Check that display service indicator(s) are consistent
Expected behaviour
Scenario A: Multi Network Environment
6. UE displays limited service, GPRS is attached, CS is not attached,
7. UE performs a new network selection and starts attaching the new PLMN (highest prioritised
network available except for the previous rejected one) after max. 2 minutes
8. UE displays full service
Scenario B: Manual Network Selection
9. UE performs CS Attach procedure(s) until the Location Update Attempt Counter has reached 4.
Then the UE indicates that the manual network selection was not successful and returns either to
a) the menu of available networks for selection or b) to automatic network selection.
11. The PLMN is successfully selected and the display indicates full service
Scenario C: Single Network Environment
15. UE displays limited service, GPRS is attached, CS is not attached
16. UE performs a new network selection and starts attaching the same, previously rejected PLMN
after max. 2 minutes
17. UE displays full service
according to 3GPP TS 24.008 section 4.2.1.2, last bullet point. It shall not wait for the T3212 timer to
expire.
The new PLMN search shall happen according to the following procedure:
• The PLMN search shall be started in any case, independently from the result of the GPRS Attach /
Routing Area Update procedure, independently from the Network Mode of Operation (NMO, i.e.
Combined or Separate Routing Area Update) and independently of the content of the Preferred
PLMN list on the SIM card.
• If other PLMNs can be found, the Terminal Device shall attempt to perform an IMSI Attach or a
Location Update procedure at each of them taking into account the Attempt Counter, according to
3GPP TS 24.008 sections 4.4.4.5, 4.4.4.6 and 4.4.4.9.
• If no different PLMN apart from the rejected can be found, the terminal device shall attempt to
access one of the already rejected networks once more (only one additional Location Update
cycle).
Note: As per requirements above, if only one PLMN is available and this PLMN was
already rejected four times with Reject Cause #17 ‘Network Failure (i.e. attempt
counter >=4), the terminal device shall attempt to access the already rejected
network once more (only one additional Location Update cycle, i.e. 4 LU attempts).
The UE shall be able to perform manual network selection and return consistent display messages to
the user.
Related GSM core specifications
TS 24.008, subclause 4.2.1.2
Reason for test
To ensure that the UE is performing a new PLMN search in both, multiple and single network
environment, and not waiting for T3212 to expire when Steering of Roaming is applied. To ensure that
manual network selection is possible and that display messages to the user are consistent.
Initial configuration
• UE switched off, with following configuration:
o Automatic network selection mode
o GPRS Attach at power on enabled
• Test to happen in live network
• Networks available:
o PLMN1: Dual Mode (GSM/W-CDMA)
o PLMN2: At least Single Mode
o PLMN3: Dual Mode (GSM/W-CDMA)
o PLMN4: Single Mode
Note: It would be ideal, if all of the available networks are Multi Mode networks (i.e. GSM
Dual Band and W-CDMA). The more complex the network environment is, the
higher will be the confidence in the Device under Test to comply with Steering of
Roaming.
• Used SIM card: Roaming SIM Card (PLMN 5, different MCC)
• Assisted Roaming deactivated on SIM Card
• SIM Card preparation (using SIM R/W Tool):
o PLMN1 and PLMN2 on forbidden PLMN list (EFFPLMN)
o PLMN3 is stored at highest priority (location 1) of EFPLMNwAcT, EFPLMNwAcT filled up with PLMNs of
other MCCs
o EFLOCI = PLMN5, LAI=1234, TMSI=12345678, Update Status= 00 (Updated)
20.6.7 Reception of System Info Type 5bis on non supported UMTS Band
Description
Verification that the UE is able to select any Radio Access Technology (RAT) after receiving SIB Type
5bis on a non supported UMTS band due to overlap of downlink channels. The test is performed with
both, Release 6 devices supporting SIB Type 5bis and prior Release 6 devices where reception
causes a decoding error.
Related core specifications and references
TS 25.331, Tdoc R2-072540, Tdoc R2-080035
Reason for test
In automatic network selection mode the device may receive SIB Type 5bis on a non supported UMTS
band due to overlap of downlink channels. Either 3GPP release 6 SIB Type 5bis will be successfully
decoded (when supported) or reception causes a decoding error (when not supported). The test
ensures that in both cases the device ignores the non supported UMTS band and continues to search
for any supported RAT.
Initial configuration
The test is performed in an environment which supports the following condition:
• A Radio Access Technology which is supported by the Device under Test (DuT).
• A Radio Access Technology which broadcasts SIB Type 5bis and where the corresponding
downlink band is supported by the DUT, but not the uplink band. This can be one of the following
combinations:
Combination Network / Simulator DuT
#1 UMTS Band IV UMTS Band I
UL: 1710-1755 MHz UL: 1920-1980 MHz
DL: 2110-2155 MHz DL: 2110-2170 MHz
#2 UMTS Band X UMTS Band I
UL: 1710-1770 MHz UL: 1920-1980 MHz
Further a simple Simulator (or a corresponding test bed environment) is required where the DuT can
successfully attach on the UMTS Band I or III, depending on the combination listed above.
A second device, e.g. a mobile phone, is required.
Test procedure
1. Depending on the device’s and the network’s configuration a test combination #1, #2 or #3 is
selected. The SIM used for step 2 is connected to the device. The DuT is connected to a simulator
(or a corresponding test bed environment) where the UMTS Band I or III, depending on the
selected test combination is enabled. The device is switched on and switched off after location
update. This step enables that the device may start searching in step 2 on the same band and
technology as before switch off.
2. The DuT is switched on in the life network or a System Simulator which supports the RATs as
listed under initial configuration.
3. A mobile originated call is performed to any destination.
Expected behaviour
1. The device performs a successful location update.
2. The device ignores the non supported UMTS band (IV, X or IX) and finds a Radio Access
Technology which is supported.
3. The mobile terminated call is successfully performed.
Ciphering is activated:
Direction
Message Comments
UE - NW
RRC (Security Mode Command (Ciphering Algorithm=UEA1)) RRC
RRC (Security Mode Command Complete) RRC
RRC (Direct Transfer – Location Updating Accept) MM
RRC (Direct Transfer – TMSI Reallocation Complete) MM
Expected behaviour
The call is setup correctly.
Expected behaviour
The UE is successfully establishing the service in Security Mode.
20.8.3.1 On switch on
[Test to be defined]
a) PNN: Register 1: <PLMN Network Name1> coded as 7 bit coded value, unused bytes shall be
set to 'FF’. Register 2: <PLMN Network Name2> coded as UCS2 coded value, unused bytes
shall be set to 'FF’.
b) OPL: Register 1: <Location Area Identity>, PNN Identifier = ‘01’. Register 2: <Location Area
Identity>, PNN Identifier = ‘02’.
Test procedure
With both USIM the following test procedures are performed.
1) The USIM is connected with the ME. The UE is switched on.
2) A mobile originated call to <MSISDN #1> is performed. The call is accepted by <MSISDN #1> and
released afterwards.
3) A mobile terminated call from <MSISDN #1> is performed. The call is accepted by the UE and
released afterwards.
Expected behaviour
1) The UE performs a location update and displays network name. Depending on the Location Area
the following is presented on the display:
a) The UE displays <PLMN Network Name1> correctly.
b) The UE displays the UCS2 coded <PLMN Network Name2> correctly.
2) After release of the call the UE shall display the PLMN network name as listed in step 1).
20.8.5.3 Priority of display of PLMN Network Name and Operator PLMN List
over MM/GMM Information message (NITZ)
[Test to be defined]
Test procedure
1) Connect the Terminal to a simulated W-CDMA network (e.g. a W-CDMA system simulator or other
such test equipment) via use of an RF cable.
2) Channel conditions shall initially set up with received CPICH_RSCP = -95 dBm and CPICH_EcIo
= 0 dB. The relative power level of downlink physical channels to Ior are set up according to
clause E.2.1 of 3GPP TS34.121. Ensure that RSCP_EcIo remains > -5 dB throughout the test.
3) Set Qrxlevmin to = -115 dBm and Qqualmin to -18 dB on the simulated network.
4) Switch on the phone and wait for the Terminal to register to the simulated network and enter into
RRC idle state.
5) Check the value of CPICH_RSCP reported by the Terminal via its Engineering Test Mode Display.
Any delta between the reported CPICH_RSCP and the actual CPICH_RSCP shall hereby
referenced to as ‘ø’ and shall be noted by the tester.
6) Set CPICH_RSCP on the simulated network to -114.2+ø dBm if the Terminal is power class3 or -
111.2+ø dBm if the Terminal is power class4 (we consider 0.8 dB as test measurement tolerance).
Expected behaviour
1) If the Terminal is out of coverage the test is failed.
ELSE, if the Terminal is in service:
2) Perform a mobile terminated voice call (from the test equipment) if the voice call fails then the test is
failed.
ELSE, if the voice call is successful:
3) Set CPICH_RSCP on the simulated network to -115.8+ø dBm if the Terminal is power class 3 or -
112.8+ø dBm if the Terminal is power class 4 (0.8 dB as test measurement tolerance). If the Terminal
is still in service, then the test is failed.
ELSE, if the Terminal is out of service:
4) The test is passed.
The Terminal under test shall be enclosed in a RF shielded box or Anechoic Chamber.
Test procedure
1) Connect the Terminal to a simulated W-CDMA network (e.g. a W-CDMA system simulator or
other such test equipment) via use of an RF cable.
2) Channel conditions are initially set up with received CPICH_RSCP = -95 dBm and CPICH_EcIo =
0 dB. The relative power level of downlink physical channels to Ior are set up according to clause
E.2.1 of 3GPP TS34.121.
3) Set Qrxlevmin to -115 dBm and Qqualmin to = -18 dB on the simulated network.
4) Switch on the phone and wait for the Terminal to register to the simulated network and enter into
RRC idle state.
5) Lower the CPICH_EcIo of the simulated network until the Terminal’s Engineering Test Mode
Display reports a CPICH_EcIo value of -17 dB.
Expected behaviour
1) If the Terminal is out of coverage the test is failed.
ELSE, if the Terminal is in service:
2) Perform a mobile terminated voice call (from the test equipment) if the voice call fails then the test is
failed.
ELSE, if the voice call is successful:
3) Set lover the CPICH_EcIo of the simulated network to -19 dB. If the Terminal is still in service, then
the test is failed.
ELSE, if the Terminal is out of service:
4) The test is passed.
Test procedure
Make a voice call.
Using a tracing tool, ensure that the power with which the preamble is transmitted is appropriate and if
UE does not receive acknowledge from the UTRAN, check the preamble power is increased by one
step (the operator should inform of the step size, and that should correspond to the measured
increase) until the UE receives the acknowledge through AICH channel (channel assignment).
Expected behaviour
The UE initiates the communication correctly. The power with which the preambles are transmitted is
not in excess of the specified and “power ramping” is well performed by the UE.
Nodo B
Nodo B
Move away from Node B “1”, and check that transmission power is increasing at a certain rate (some
dBs per Kilometre). When the UE enters in the area of soft handover, check transmission power does
not increase as fast as before: it increases more slowly, or keeps constant or even decreases. Check
that, once out of the soft handover area, as we move closer to the Node B “2”, the transmission power
is decreasing.
Represent the power with which DPCH is transmitted in function of distance from Node B in a plot.
It would be good if TPC commands received from the network and “TPC_cmd” generated by the UE
could be logged: this way the fact that power is increased/decreased as requested by the network
could be checked with more confidence.
Expected behaviour
UE correctly performs closed loop power control using “algorithm 1” and does not transmit more power
than needed. The transmitted power log graph should be quite noisy with “algorithm 1”, as the
transmitted power changes at every slot. There should be no horizontal segments in the graph, as
from one slot to the next, the transmitted power is always changed, either raised or lowered, but never
kept constant.
In the handover process, the expected behaviour is:
The received power at the "old" Node B gets weaker, while the received power at the "new" Node B
gets stronger. UE transmit power should be determined by the strongest Node B at any time, i.e. the
UE does not increase the transmit power as long as at least one Node B is satisfied (sends TPC down
commands).
It is very helpful to the field engineers if the network operator provides the details of a suitable location
to perform this test.
Note: The UE should be able to detect the Secondary Synchronization Codes sequence
transmitted by the cell SCH even if it receives only one every two SSCs, (note, the
actual SSCs do not need to be captured as part of the test).
Switch the UE on. Ensure that the UE gets connected to the network in appropriate time.
Expected behaviour
UE attaches to the network in appropriate time.
22 Mobility
Initial configuration
There must be an appropriate number of 3G cells available on the same PLMN, and the UE should be
in idle mode. The UE should be IMSI attached, but not Packet attached.
Test procedure
Move between the coverage areas of different cells, ideally on a long test route. The test route should
contain as many of the scenarios listed below as possible. Ensure that the UE performs reselections
as expected. During the reselections it is imperative the UE remains in service at all times, and that it
can receive a call before and after the reselections. Where possible, this procedure should be carried
out as follows:
• Between cells sharing a Location Area.
• Between cells not sharing a Location Area.
• Between cells utilising the same physical frequency.
• Between cells using different frequencies.
• In areas of poor signal strength.
• In RNSs of as many different infrastructure vendors as possible.
Expected behaviour
The UE should perform reselections correctly, without losing service, and it should be able to receive
calls before and after the reselections.
Expected Behaviour
The UE should perform reselections correctly, without losing service, and it should be able to receive
calls before and after the reselections.
Initial configuration
There must be an appropriate number of 3G cells available on the same PLMN, and the UE should be
in idle mode. The UE should be IMSI attached, and Packet attached, with a PDP context active.
Test procedure
Start transferring data, e.g. by using FTP. Move between the coverage areas of different cells, ideally
on a long test route. The test route should contain as many of the scenarios listed below as possible.
Ensure that the UE performs reselections as expected. During the reselections it is imperative the UE
remains in service at all times, and that it can receive a call before and after the reselections. Where
possible, this procedure should be carried out as follows:
• Between cells sharing a Location Area and Routing Area.
• Between cells sharing a Location Area but not sharing a Routing Area.
• Between cells not sharing a Location Area.
• Between cells utilising the same physical frequency.
• Between cells using different frequencies.
• In areas of poor signal strength.
• In RNSs of as many different infrastructure vendors as possible.
• Between different cells supporting PS(R99), HSDPA and/or HSUPA(EUL).
During the test the UE shall be continually transmitting and receiving data via use of suitable FTP
tools.
Expected Behaviour
The UE should perform reselections correctly, without losing service, and it should be able to receive
calls before and after the reselections. The data session should resume after the reselection.
The data rate shall be as expected for the data bearer type assigned by the network throughout the
test, i.e. data rates proportional to the data bearer and signal quality shall be achieved both before and
after the cell reselections.
22.1.2.1 Idle Mode Circuit Switched Inter RAT Reselection Not Packet
Attached
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
Reason for test
To ensure that the UE performs a reselection correctly without losing service.
Initial configuration
There must be an appropriate number of 2G and 3G cells available on the same PLMN, and the UE
should be in idle mode. The UE should be IMSI attached, but not Packet attached.
Test procedure
Move from the coverage area of one RAT to another. Ensure that the UE performs a reselection as
expected. During this reselection it is imperative the UE remains in service at all times, and that it can
receive a call before and after the reselection. Where possible, this procedure should be repeated as
follows:
• In RNSs of as many different infrastructure vendor combinations as possible.
• 3G cells supporting to/from 2G cells.
22.1.2.2 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached
(No PDPc)
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
Reason for test
To ensure that the UE performs a reselection correctly without losing service.
Initial configuration
There must be an appropriate number of 2G and 3G cells available on the same PLMN, and the UE
should be in idle mode. The UE should be IMSI attached, and Packet attached but with no PDP
context.
Test procedure
Move from the coverage area of one RAT to another. Ensure that the UE performs a reselection as
expected. During this reselection it is imperative the UE remains in service at all times, and that it can
receive a call before and after the reselection. Where possible, this procedure should be repeated as
follows:
• In RNSs of as many different infrastructure vendor combinations as possible.
• 3G cells to/from 2G cells.
• In areas of poor signal strength.
Expected Behaviour
The UE should perform reselections correctly, without losing service, and it should be able to receive
calls before and after the reselections.
22.1.2.3 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached
(PDPc Active, No Data Transfer)
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
Reason for test
To ensure that the UE performs a reselection correctly without losing service.
Initial configuration
There must be an appropriate number of 2G and 3G cells available on the same PLMN, and the UE
should be in idle mode. The UE should be IMSI attached, and Packet attached with a PDP context,
but not actively transmitting data.
Test procedure
Move from the coverage area of one RAT to another. Ensure that the UE performs a reselection as
expected. During this reselection it is imperative the UE remains in service at all times, and that it can
receive a call before and after the reselection. Where possible, this procedure should be repeated as
follows:
22.1.2.4 Idle Mode Circuit Switched Inter RAT Reselection Packet Attached
(Transmitting Data)
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
Reason for test
To ensure that the UE performs a reselection correctly without losing service.
Initial configuration
There must be an appropriate number of 2G and 3G cells available on the same PLMN, and the UE
should be in idle mode. The UE should be IMSI attached, and Packet attached with a PDP context.
Test procedure
Start transferring data, e.g. by using FTP. Move from the coverage area of one RAT to another.
Ensure that the UE performs a reselection as expected. During this reselection it is imperative the UE
remains in service at all times, and that it can receive a call before and after the reselection. Where
possible, this procedure should be repeated as follows:
• In RNSs of as many different infrastructure vendor combinations as possible.
• 3G cells supporting PS(R99), HSDPA and/or HSUPA(EUL) to/from 2G cells supporting GRPS
and/or EGPRS.
• In areas of poor signal strength.
During the test the UE shall be continually transmitting and receiving uncompressible data via use of
suitable FTP tools.
Expected Behaviour
The UE should perform reselections correctly, without losing service, and it should be able to receive
calls before and after the reselections. The data session should resume after the reselection.
The data rate shall be as expected for the data bearer type assigned by the network throughout the
test, i.e. data rates proportional to the data bearer and signal quality shall be achieved both before and
after the cell reselections.
22.2.2.1 Idle Mode Packet Switched Inter RAT Reselection Packet Attached
(No PDPc) Not Circuit Attached
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
22.2.2.2 Idle Mode Packet Switched Inter RAT Reselection Packet Attached
(PDPc Active, No Data Transfer) Not Circuit Attached
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08
Reason for test
To ensure that the UE performs a reselection correctly without losing service.
Initial configuration
There must be number of 2G and 3G cells available on the same PLMN,. The UE should be packet
attached with a PDP context set up but not actively transmitting data. The UE should not be Circuit
attached.
Test procedure
Move from the coverage area of one cell to another. Ensure that the UE performs a reselection as
expected. During this reselection it is imperative the UE remains in service at all times, and that the
PDP context remains viable both before and after the reselection. Where possible, this procedure
should be repeated as follows:
• In RNSs of as many different infrastructure vendor combinations as possible.
• 3G cells supporting PS(R99), HSDPA and/or HSUPA(EUL) to/from 2G cells supporting GRPS
and/or EGPRS.
• In areas of poor signal strength.
Expected Behaviour
The UE should perform reselections correctly, without losing service, and its PDP context should
remain viable before and after the reselections.
22.2.2.3 Idle Mode Packet Switched Inter RAT Reselection Packet Attached
(Transmitting Data) Not Circuit Attached
Description
The UE should perform a reselection without losing service.
1 For voice tests, a standard voice call should be set up on the desired RAT. The call should remain active at all times,
without any loss or degradation of voice quality after handovers.
2 For video telephony testing, a bi-directional video call should be set up with another UE in a static location. The call
should remain active at all times, with no loss of either audio or video as a result of handovers. Inter RAT handovers are
not possible with Video Telephony.
3 For PS Data tests, the UE should be actively transmitting data before and after the CCO. All supported data rates should
be tested. Tests should be repeated with the UE in DCH, FACH, and PCH modes. The session should be viable after
reselections in each of these states, and the UE should still be able to receive mobile terminating calls. The data rate
shall be as expected for the data bearer type assigned by the network throughout the test.
4 For CS Data tests, the UE should be actively transmitting data before and after the handover. All supported data rates
should be tested.
5 For MultiRAB test, all viable combinations of Video Telephony + PS Data, Voice + PS Data, and Voice + Video Telephony
should be used. All services should be available to the user regardless of handovers. The data rate shall be as expected
for the data bearer type assigned by the network throughout the test.
6 This scenario is designed to test softer handovers. Test shall include handovers within a RAT with cells supporting
PS(R99), HSDPA and/or HSUPA(EUL).
7 This scenario is designed to test soft handovers. Test shall include handovers within a RAT with cells supporting
PS(R99), HSDPA and/or HSUPA(EUL) .
8 This scenario is designed to test soft handovers involving the Iur interface. Test shall include handovers within a RAT with
cells supporting PS(R99), HSDPA and/or HSUPA(EUL).
CS Data
Video
Voice1 PS Data3 (Non Multi RAB5
Telephony2 4
Transparent)
3G-3G Inter-frequency (e.g. 2100-
2100)2
X X X X
3G-3G Inter Band (e.g. 2100-900)3 X X X X
2G - 3G All frequency band
combinations (e.g. G900-U900)4
X X
3G- 2G All frequency band
combinations (e.g. G900-U900)5
X X
Description
The UE should perform handovers as requested by the network, and behave as expected from the
user perspective without losing services.
Related core specifications
3GPP TS25.304, 3GPP TS 25.331, 3GPP TS 05.08, 3GPP TS 04.18
Reason for test
To ensure that the UE performs handovers correctly without losing services.
Initial configuration
There must be an appropriate number of 2G and 3G cells available on the same PLMN. The RAB to
be tested should be active, and available in all parts of the test route.
Test procedure
Move between the coverage areas of different cells, ideally on a long test route. The test route should
contain as many of the scenarios listed in the table above as possible. Ensure that the UE performs
reselections/handovers as expected. During the test drive it is imperative the UE remains in service at
all times, that the RAB in question is maintained throughout the test route, and that the UE is always
able to receive mobile terminating calls.
Expected Behaviour
The UE should perform reselections/handovers correctly, without losing service, and all relevant RABs
should be available throughout the test route.
1 This scenario is designed to test hard handovers involving the Core. Test shall include handovers within a RAT with cells
supporting PS(R99), HSDPA and/or HSUPA(EUL).
2 Tests should be carried out to invoke hard handovers in case the frequency changes between the 3G cells.
3 Tests should be carried out to invoke handovers between 3G cells of different frequency bands (for e.g. FDD 1 & FDD
VIII).
4 Tests should be carried out to invoke handovers of 2G cells supporting GRPS and/or EGPRS to 3G cells supporting
PS(R99), HSDPA and/or HSUPA(EUL) as appropriate.
5 Tests should be carried out to invoke handovers of cells supporting PS(R99), HSDPA and/or HSUPA(EUL) as
appropriate to 2G cells supporting GRPS and/or EGPRS.
Initial configuration
For this test a network with a 3G (UMTS) and a 2G (GSM) cell is required. Both cells neighbour cells
and the 2G cell supports A5/3 on both BSS and MSC. For UMTS -> GSM handover a location in the
GSM cell is required with sufficient GSM coverage but without UMTS coverage.
A second device (PSTN or mobile phone) is required.
Test procedure
1. The DUT is switched on in the UMTS cell.
2. A mobile originated or terminated speech call between the DUT and the second phone (PSTN
or mobile) is performed.
3. Move from the UMTS coverage area to the GSM neighbour cell supporting A5/3. Ensure that
the call is not dropped.
4. Verify that the DUT receives “cipher with algorithm A5/3” within CIPHER MODE SETTING in
HANDOVER COMMAND from the network
5. Check the end to end voice connection.
Expected behaviour
1. –
2. –
3. Handover to A5/3 cell is successful and the call is not dropped.
4. Cipher mode setting is set to “cipher with algorithm A5/3”
5. The end to end voice connection is available during and after
23 PS/CS Data
23.0.2 Connectivity
The end-to-end performance tests may require the use of different means of connectivity connecting
the device under test (DUT) to an external terminal equipment. In this case, the type of the
connectivity shall be recorded.
Test procedure
Scenario A:
Activate a PDP from an external device tethered to the UE (e.g. by means of a dial-up networking
or internet sharing session) using any PS bearer supported by the UE and by its 3G HPLMN.
1. Verify that the session is established.
2. Ping a known reachable IP address and verify that the ping is successful.
3. Repeat procedures 1&2 with Browsing embedded application.
Scenario B:
1. Activate a PDP via the embedded Browsing application using any PS bearer supported by the
UE and by its 3G HPLMN.
2. Verify that the session is established.
Expected behaviour
The UE shall be able to establish the PDP context.
Direction
Step Message Comments
UE - NW
1 RRC (Connection Request) RRC
2 RRC (Connection Setup) RRC
3 RRC (Connection Setup Complete) RRC
4 RRC (Initial Direct Transfer - CM Service Request) CM
5 RRC (Direct Transfer - GMM Authentication Request) MM
6 RRC (Direct Transfer - GMM Authentication Response) MM
7 RRC (Security Mode Command) RRC
8 RRC (Security Mode Command Complete) RRC
9 RRC (Direct Transfer - Activate PDP Context Request) SM
10 RRC (Radio Bearer Setup) RRC
11 RRC (Radio Bearer Setup Complete) RRC
12 RRC (Direct Transfer - Activate PDP Context Accept) SM
Expected behaviour
The UE shall be able to deactivate the PDP context and consequently lose network connectivity
Direction
Step Message Comments
UE – NW
1 RRC (Direct Transfer - Deactivate PDP Context Request) SM
2 RRC (Direct Transfer - Deactivate PDP Context Accept) SM
3 RRC (Radio Bearer Release) RRC
4 RRC (Radio Bearer Release Complete) RRC
5 RRC (Connection Release) RRC
6 RRC (Connection Release Complete) RRC
Test procedure
Scenario A:
1. Establish a PC dial-up networking session
2. Wait for the Core Network no activity timeout.
Scenario B:
1. Activate a PDP via the embedded Browsing application using any PS bearer supported by the
UE and by its 3G HPLMN.
2. Wait for the Core Network no activity timeout.
Expected behaviour
Information for the PDP context deactivation to the user and verify that user is informed for the PDP
context deactivation.
23.1.7 PDP context activation initiated by the UE, rejected by the network
with cause unknown APN
Description
Verify that the UE inform the user of reject of PDP context activation
Related core specifications
3GPP TS 24.008
Reason for test
To ensure that the UE is not able to activate a PDP context with unknown APN.
Initial configuration
The UE is IMSI attached and PS attached in its 3G HPLMN
Test procedure
1. Change the APN to an incorrect one (not defined in the HLR). This may be done for instance
with a HyperTerminal connected to the UE, with the AT Command AT+CGDCONT or via the
UE menu.
Scenario A:
2. Try to activate a PDP context from an external device tethered to the UE (e.g. by means of a
dial-up networking or internet sharing session).
Scenario B:
2. Try to activate a PDP via the embedded Browsing application.
Expected behaviour
Verify that the UE indicates for the PDP activation failure.
Direction
Step Message Comments
UE – NW
1 RRC (Direct Transfer - activate PDP Context Request) SM
2 RRC (Direct Transfer - activate PDP Context reject) SM
3 RRC (Radio Bearer Release) RRC
4 RRC (Radio Bearer Release Complete) RRC
5 RRC (Connection Release) RRC
6 RRC (Connection Release Complete) RRC
Expected behaviour
The UE shall be able to activate the secondary PDP context by recognizing a different type of traffic
(QoS class) from the one already established. A single APN and PDP address is used (for both
primary and secondary PDP addresses).
2. Ping a known reachable IP address and verify that the ping is successful or open a new web
page (not in the cache memory of the browser).
Expected behaviour
The UE shall be able to establish the PDP context.
2. With a HyperTerminal connected to the UE, define the requested QOS profile with the AT
Command AT+CGEQREQ with values of QOS parameters set to a better values than the
HLR parameters for this instance
3. Active the PDP context with the AT Command AT+CGACT
Expected behaviour
The UE shall be able to establish the PDP context.
The response on the HyperTerminal after the AT+CGACT shall be NOK
Test procedure
1. Initiate a dial-up networking session using PS bearer 64/128 kbps.
2. Verify that the dial-up networking session is established.
3. Start a downlink FTP of file (file size > 2 Mbytes)
4. Verify throughput using a suitable application monitor (statistics).
Expected behaviour
The UE shall be able to establish a dial-up networking session using the 64/128 kbps PS Radio
Access Bearer. The throughput verified by means of an FTP download should be proportional to RAB
established.
Initial configuration
The UE is IMSI attached and CS attached in its 3G HPLMN.
Test procedure
For each of the following call configurations, make an outgoing MO data call. Ensure that the call
completes and the data is exchanged correctly.
1. Transparent asynchronous services (BS 20T), 3,1khz, user rate 28.8 kbit/s
2. Non transparent asynchronous services (BS 20 NT), 3.1khz, user rate can be 0.3 kbit/s, 1.2
kbit/s, 2.4 kbit/s, 4.8 kbit/s, 9.6 kbit/s, 14.4 kbit/s, 19.2 kbit/s, 28.8 kbit/s.
3. Non transparent asynchronous services (BS 20 NT), UDI, V.110, user rate can be 0.3 kbit/s,
1.2 kbit/s, 2.4 kbit/s, 4.8 kbit/s, 9.6 kbit/s, 14.4 kbit/s, 19.2 kbit/s, 28.8 kbit/s., 38.4 kbit/s
4. Non transparent asynchronous services (BS 20 NT), UDI/RDI, V.120, user rate can be 0.3
kbit/s, 1.2 kbit/s, 2.4 kbit/s, 4.8 kbit/s, 9.6 kbit/s, 14.4 kbit/s, 19.2 kbit/s, 28.8 kbit/s., 38.4 kbit/s,
48 kbit/s, 56 kbit/s.
5. Non transparent asynchronous services (BS 20 NT for PIAFS), UDI, PIAFS user rate can be:
32 kbit/s, 64 kbit/s.
6. Non transparent asynchronous services (BS 20 NT for Frame Tunnelling Mode), RDI/UDI,
X31 flag stuffing user rate can be: 56 kbit/s, 64 kbit/s.
7. Transparent synchronous services (BS 30 T), 3.1 kHz user rate 28.8 kbit/s.
8. Transparent synchronous services (BS 30 T), UDI/RDI V110, user rate can be: 56 kbit/s, 64
kbit/s.
9. Transparent synchronous services (BS 30 T for Multimedia), 3.1kHz/UDI/RDI, H223 & H245
user rate can be: 28.8 kbit/s, 32 kbit/s, 33.6 kbit/s, 56 kbit/s, and 64 kbit/s.
Expected behaviour
The calls complete and the data is exchanged correctly.
4. Non transparent asynchronous services (BS 20 NT), UDI/RDI, V.120, user rate can be 0.3
kbit/s, 1.2 kbit/s, 2.4 kbit/s, 4.8 kbit/s, 9.6 kbit/s, 14.4 kbit/s, 19.2 kbit/s, 28.8 kbit/s., 38.4 kbit/s,
48 kbit/s, 56 kbit/s.
5. Non transparent asynchronous services (BS 20 NT for PIAFS), UDI, PIAFS user rate can be:
32 kbit/s, 64 kbit/s.
6. Non transparent asynchronous services (BS 20 NT for Frame Tunnelling Mode), RDI/UDI,
X31 flag stuffing user rate can be: 56 kbit/s, 64 kbit/s.
7. Transparent synchronous services (BS 30 T), 3.1 kHz user rate 28.8 kbit/s.
8. Transparent synchronous services (BS 30 T), UDI/RDI V110, user rate can be: 56 kbit/s, 64
kbit/s.
9. Transparent synchronous services (BS 30 T for Multimedia), 3.1kHz/UDI/RDI, H223 & H245
user rate can be: 28.8 kbit/s, 32 kbit/s, 33.6 kbit/s, 56 kbit/s, and 64 kbit/s.
Expected behaviour
The calls complete and the data is exchanged correctly.
23.8 PS Performance
23.8.1 PDP Activation Time measure
Description
Measure the time the UE takes to correctly activate a PDP context.
Related core specifications
3GPP TS 24.008
Reason for test
For performance reasons, measure that the UE is able to establish a PDP context in a suitable time
interval.
Initial configuration
The UE is IMSI attached and PS attached in its 3G HPLMN.
Test procedure
1. Start the activation of a PDP context by means of a dial-up networking session.
2. Verify that the dial-up networking session is established, for e.g. using ping to a known IP
address.
3. Measure the time between step 1 and step 2.
The referred test procedure should be performed for several times and then treated statistically. This is
important to guarantee results accuracy.
Expected behaviour
The UE shall be able to, in average, establish a PDP context in a suitable time when compared to
other UE’s on the same network configuration.
5. Verify than the download of the page is correct each time (number of elements)
6. Measure the time to download the 10 WEB pages and calculate the average download time
per page.
Expected behaviour
The UE shall be able to, in average, download a reference Web page within a reasonable period of
time when compared to other UE’s on the same network.
23.9 CS performance
23.9.1 CS Data call establishment duration
Description
Measure the time the UE takes to establish a CS data call.
Related core specifications
3GPP TS 24.008
Reason for test
For performance reasons, measure that the UE is able to establish a CS data call in a suitable time
interval.
Initial configuration
The UE is IMSI attached in its 3G HPLMN.
Test procedure
1. Start the establishment of a CS data modem connection by means of a dial-up networking
session.
2. Verify that the dial-up networking session is established, for e.g. using ping to a known IP
address.
3. Measure the time between step 1 and step 2.
The referred test procedure should be performed for several times and then treated statistically. This is
important to guarantee results accuracy.
Expected behaviour
The UE shall be able to, in average, establish a CS data modem connection in a suitable time.
2. The device is moved to CELL_FACH. When there is no monitor it shall be assumed that the
device is moved to CELL_FACH after N seconds of inactivity.
3. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
Expected behaviour
1. The device is moved to CELL_PCH. When there is no monitor it shall be assumed that the
device is moved to CELL_PCH after N+M seconds of inactivity, as indicated by the operator
(see test case 23.10.1 and 23.10.2).
2. Between P and Q minutes after entering CELL_PCH state the device is moved to RRC idle
state. When there is no monitor it shall be assumed that the device is moved to RRC idle
Q minutes after entering CELL_PCH.
3. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
Expected behaviour
The speech call continues and the speech quality is undisturbed.
The CS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Expected behaviour
The speech call continues and the speech quality is undisturbed.
The PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Expected behaviour
The CS-data call continues and the data stream is not interrupted.
The PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Expected behaviour
The Video call continues and the quality is undisturbed.
The PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Ciphering is activated:
Direction
Message Comments
UE - NW
Security Mode Command (Ciphering Algorithm=UEA1)
Security Mode Complete
Moreover, the EFUST (USIM Service Table) must indicate that service n°12 (Short Message Service
Parameters (SMSP)) is available. If a service is not indicated as available in the USIM, the ME shall
not select this service.
One mobile subscriptions with the telephone number <MSISDN #1> is required to send and receive
short messages.
With an external card reader
• EFSMSP is initialised with the following values:
Bytes Value Length
1 to Y <Alpha-Identifier> Y bytes
Y+1 = ‘FD’ hex = ‘11111101’ binary = 1 byte
“TP-Destination Address” absent.
“TS-Service Centre Address” present
“TP-Protocol Identifier” absent
“TP-Data Coding Scheme” absent
“TP-Validity Period” absent
Y+2 to Y+13 <MSISDN #2> 12 bytes
Y+14 to Y+25 <Service Centre Address> = Any valid 12 bytes
service centre address for the service
provider of the smartcard.
Y+26 <Any Protocol Identifier> 1 byte
Y+27 <Any Data Coding Scheme> 1 byte
Y+28 <Any Validity Period> 1 byte
A second smartcard (ICC or UICC) is required for test preparation (Step 1).
Test procedure
1) The UE is connected with a second smartcard and the UE switched on. The Service Centre
Address is changed via Menu to any non valid value, different from <Service Centre Address>.
2) The UE is switched off and the second smartcard is removed. The first UICC (with USIM) is
connected to the UE and the UE switched on. The Service Centre Address stored by the UE is
checked via Menu.
3) A new mobile originated SMS is created and sent to MSISDN #1. The UE asks for the destination
MSISDN.
4) The UE is switched off and the UICC is removed from the UE. The value of EFSMSP is checked
with an external card reader.
Expected behaviour
1) The UE indicates that the new Service Centre Address is saved.
2) The UE indicates that <Service Centre Address> is the service centre address.
3) The UE indicates that the mobile originated SMS is sent successfully. The UE prompted to enter
the MSISDN and does not present MSISDN #2 as the proposed destination. The SMS is received
at MSISDN #1.
4) The values of EFSMSP is as defined during initialisation.
Test procedure
1. Without powering down the mobile, remove the UICC. If necessary a charger or external power
supply should be used. Check that no calls can be made except for emergency call attempts.
(When allowed to initiate an EM call without SIM/UICC)
2. After replacing the UICC with another UICC an outgoing call to another mobile is performed. It is
checked that the called mobile displays the Directory Number associated with the new UICC.
(Where possible, this test should be carried out on a network which does not implement
authentication on all calls.)
3. While in idle mode, and without powering down the mobile, remove the UICC and replace it with
another UICC. Arrange for an incoming call to be made to the Directory Number of the “old”
UICC.
Expected behaviour
1. No calls, SMS, or supplementary services, except for emergency call attempt (when permitted),
can be made.
2. Call is established and the correct number is displayed.
3. The UE should not respond to the call.
Initial configuration
UE is in idle mode, PIN is enabled
Test procedure
Scenario A:
Dial the code **04*OLD*NEW*NEW# (where OLD is the old PIN1 and NEW is the new 3-digit PIN) to
change the PIN. Check that the mobile indicates that the command has failed, giving the reason.
Scenario B:
Repeat Scenario A, but using the phone's menu.
Expected behaviour
In both scenarios the mobile clearly indicates that the command has failed
Expected behaviour
PIN can normally not be changed when deactivated. Therefore the following behaviour could occur
when the test procedure is performed:
An appropriate error message indicates to the user that PIN can not be changed when deactivated
One of the following two possible behaviours can be expected:
• The menu for changing PIN is disabled
• An appropriate error message indicates to the user that PIN cannot be changed while deactivated
In all cases the device does not crash and PIN is unchanged.
2. Go to a data field which is protected by PIN2 on UICC, for e.g. FDN and enter the new PIN2
code.
Scenario B:
1. Repeat step 1 & 2 under Scenario A, but using the phone's menus to send the command.
Expected behaviour
For both scenarios:
1. Check that the new PIN2 is accepted by the mobile and an indication is given showing whether
this procedure was successful
2. New PIN2 code is accepted and access to for e.g. FDN is enabled.
Dial the code **042*OLD*NEW*NEW# (where OLD is an incorrectly entered old PIN2 and NEW is the
new PIN2) to change PIN2. Check that the mobile indicates that the command has failed, giving the
reason
Scenario B:
Repeat Scenario A, but using the phone's menu.
Expected behaviour
In both scenarios the mobile clearly indicates that the command has failed
Expected behaviour
In both scenarios the mobile clearly indicates that the command has failed, giving the reason.
Expected behaviour
The LAI field of EFLOCI shall contain the correct MCC, MNC and LAC.
The TMSI field of EFLOCI shall contain the updated TMSI.
The Location Update status of EFLOCI shall indicate "updated".
The Ciphering key Kc field of EFKC shall contain the newly calculated value of Kc
The Ciphering key sequence number n field of EFKC shall contain a valid ciphering key sequence
number.
25.1.7.1 Storage of USIM Data after LUP reject, IMSI unknown in HLR
Description
Ensure that USIM data is stored correctly following a Location Updating Reject, with the failure given
as "IMSI unknown in HLR"
Related core specifications
3GPP TS 31.102, 3GPP TS 24.008, ETSI TS 102 221
Reason for test
To ensure that, when the location updating process fails, with the failure given as "IMSI unknown in
HLR"(reject cause #2), the location information is stored correctly
Initial configuration
UE is switched off. UICC/USIM contains an invalid IMSI
Test procedure
Turn on the UE and wait for it to attempt to connect to a network. When the mobile indicates that it has
not been able to obtain full service, turn off the UE and remove the USIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
The Ciphering key Kc field of EFKC shall be cleared
The Ciphering key sequence number n field of EFKC shall be cleared
25.1.7.3 Storage of USIM Data after LUP reject, PLMN not allowed
Description
Ensure that SIM data is stored correctly following a Location Updating Reject, with the failure given as
"PLMN not allowed"
Related core specifications
3GPP TS 31.102, 3GPP TS 24.008, ETSI TS 102 221
Reason for test
To ensure that, when the location updating process fails, with the failure given as "PLMN not allowed"
(reject cause #11), the location information is stored correctly
Initial configuration
UE is switched off. UE is located in an area where the only available networks will all respond with
"PLMN not allowed". On the USIM, all four fields of EFFPLMN are filled with valid data (but not indicating
any currently available PLMN).
Test procedure
Turn on the UE and wait for it to attempt to connect to a network. When the mobile indicates that it has
not been able to obtain full service, turn off the UE and remove the USIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
The Ciphering key Kc field of EFKC shall be cleared
The Ciphering key sequence number n field of EFKC shall be cleared
Test procedure
Turn on the UE and wait for it to attempt to connect to a network. When the mobile indicates that it has
not been able to obtain full service, turn off the UE and remove the SIM to check its contents.
Expected behaviour
The LAI field of EFLOCI shall be cleared.
The TMSI field of EFLOCI shall be cleared.
The Location Update status of EFLOCI shall indicate "Location Area not allowed".
The Ciphering key Kc field of EFKC shall be cleared
The Ciphering key sequence number n field of EFKC shall be cleared
The MCC and MNC of the network shall be stored in one of the blank fields of EFFPLMN. The original
valid data shall still be present.
25.1.10 FDN
3. Select FDN [2], enter 5 for the wild character, attempt call set up. The UE shall allow call set up
4. Select FDN [3], attempt call set up. The UE shall allow call set up
5. Enter 01XXXXXXXXXP1234 and attempt call set up. The UE shall prevent call set up
Expected behaviour
Only numbers in the FDN list (including wildcards) can be used when FDN is active.
2. Add a new phone book entry with the alpha identifier “National Number” and an existing
telephone number in national format to the USIM.
3. Add a new phone book entry with the alpha identifier “International No” and an existing
telephone number in international format to the USIM.
4. Add a new phone book entry with the alpha identifier “SSC Code” and an existing
supplementary service code (e.g. “**61*<any international number>**<timer>#”) to the USIM.
5. Switch the Mobile off and on again (Power Cycle)
6. Select the phone book entry “National Number”. Check that the number can be correctly
dialled.
7. Select the phone book entry “International No”. Check that the number can be correctly
dialled.
8. Select the phone book entry “SSC Code”. Check that the supplementary service is correctly
performed.
9. Switch the device off and check with the external UICC with USIM reader that the USIM’s
phone book contains
• An ADN with the alpha identifier “National Number” and the correct telephone number in
national format
• An ADN with the alpha identifier “International No” and the correct telephone number in
international format
• An ADN with the alpha identifier “SSC Code” and the correct supplementary service
string
• Does not contain the phone book entry with the alpha identifier “PleaseDeleteADN"
Expected behaviour
1. The UE indicates that the phone book entry with the alpha identifier “PleaseDeleteADN" is
deleted from the USIM.
2. The UE indicates that the phone book entry with the alpha identifier “National Number” is
added to the USIM.
3. The UE indicates that the phone book entry with the alpha identifier “International No” is
added to the USIM.
4. The UE indicates that the phone book entry with the alpha identifier “SSC Code” is added to
the USIM.
5. -
6. The phone book entry “National Number” could be selected and correctly dialled.
7. The phone book entry “International No” could be selected and correctly dialled.
8. The phone book entry “SSC Code” could be selected and the supplementary service could be
correctly performed.
9. The external UICC with USIM reader indicates that the USIM’s phone book contains
• An ADN with the alpha identifier “National Number” and the correct phone number in
national format
• An ADN with the alpha identifier “International No” and the correct phone number in
international format
• An ADN with the alpha identifier “SSC Code” and the correct supplementary service
string
• Does not contain the phone book entry with the alpha identifier “PleaseDeleteADN"
Expected behaviour
1. The UE shall indicate that ADN “Group1TelephoneN" belongs to group “Group No 1”.
2. The UE shall indicate that ADN “Group2TelephoneN" belongs to group “Group No 2”.
3. The new ADN “AssignToGroup2” can be assigned to group “Group No 2”.
4. The ADN “Group2TelephoneN" can be assigned to group “Group No 1”
5. After de-assigning the group for “Group1TelephoneN" this ADN shall no longer belong to a
group.
6. -
7. The UE shall indicate that ADN “Group1TelephoneN" does not belong to any group.
8. The UE shall indicate that ADN “Group2TelephoneN" belongs to group “Group No 1”.
9. The UE shall indicate that ADN “AssignToGroup2" belongs to group “Group No 2”
The UICC (with USIM) is placed in the device and this UE is switched on either in GSM or UTRAN
environment with sufficient coverage.
Test procedure
1. Select the phone book entry “eMail1TelephoneN". Check the eMail address associated to this
ADN.
2. Create a new eMail and send it to the eMail address associated to the ADN
“eMail1TelephoneN". Check that the eMail is received.
3. Change the eMail address associated to the ADN entry “eMail1TelephoneN"
4. Select the phone book entry “eMail2TelephoneN" and delete the eMail associated to this
ADN.
5. Add a new phone book entry with the alpha identifier “New-eMail2” with any telephone
number. Add a new eMail address to this ADN.
6. Leave the phone book. Select the phone book entry “New-eMail2". Check the eMail address
associated to this ADN.
7. Create a new eMail and send it to the eMail address associated to the ADN “New-eMail2".
Check that the eMail is received.
8. Remove the UICC from the device and place it into an other device supporting EFeMail.
9. Select the phone book entry “eMail1TelephoneN". Check the changed eMail address
associated to this ADN.
10. Select the phone book entry “eMail2TelephoneN ". Check that no eMail address is associated
to this ADN.
11. Select the phone book entry “New-eMail2". Check the eMail address associated to this ADN.
Expected behaviour
1. The eMail address is as defined with external card reader.
2. The eMail is received by the correct eMail address.
3. The eMail address associated to the ADN entry “eMail1TelephoneN" can be changed.
4. The eMail address associated to the “eMail2TelephoneN " can be deleted.
5. An eMail address can be associated to the new ADN “New-eMail2”.
6. The eMail address associated to ADN “New-eMail2" is as defined.
7. The eMail is received by the correct eMail address.
8. -
9. The eMail address associated to the ADN entry “eMail1TelephoneN" is as modified in step 3).
10. No eMail address is associated to ADN “eMail2TelephoneN".
11. The eMail address associated to the ADN entry “New-eMail2 is as defined.
Two telephones with the telephone number <telephone number #1> and <telephone number #2> are
required to receive calls.
The UICC (with USIM) is placed in the device and this UE is switched on either in GSM or UTRAN
environment with sufficient coverage.
Test procedure
1. Select the phone book entry “ANRTelephoneNum". Check the additional number associated
to this ADN.
2. Perform a MOC to the Additional Number associated with phone book entry
“ANR1TelephoneNum” (<telephone number #1>). Check that the call can be performed and
release it afterwards.
3. Change the additional number associated to the ADN entry “ANR1TelephoneNum"
4. Select the phone book entry “ANR2TelephoneNum" and delete the additional number
associated to this ADN.
5. Add a new phone book entry with the alpha identifier “New-ANR2” with any telephone number
different from telephone number #1 - #3. Add <telephone number #2> as a new additional
number to this ADN.
6. Leave the phone book. Select the phone book entry “New-ANR2". Check the additional
number associated to this ADN.
7. Perform a MOC to the additional number associated to the ADN “New-ANR2" (telephone
number #2). Check that the call can be performed and release it afterwards.
8. Remove the UICC from the device and place it into an other device supporting EFANR.
9. Select the phone book entry “ANR1TelephoneNum". Check the changed additional number
associated to this ADN.
10. Select the phone book entry “ANR2TelephoneNum". Check that no additional number is
associated to this ADN.
11. Select the phone book entry “New-ANR2". Check the additional number associated to this
ADN is correct.
Expected behaviour
1. The additional number is as defined with external card reader.
2. The MOC could be performed to the correct destination.
3. The additional number associated to the ADN entry “ANR1TelephoneNum" can be changed.
4. The additional number associated to the “ANR2TelephoneNum" can be deleted.
5. An additional number can be associated to the new ADN “New-ANR2”.
6. The additional number associated to ADN “New-ANR2" is as defined.
7. The MOC could be performed to the correct destination.
8. -
9. The additional number associated to the ADN entry “ANR1TelephoneNum" is as modified in
step 3).
10. No additional number is associated to ADN “ANR2TelephoneNum".
11. The additional number associated to the ADN entry “New-ANR2 is as defined.
With the external card reader reset the Hiddenkey in EFHiddenkey to “FF…FF”.
Place USIM #2 in the device and switched this UE on either in GSM or UTRAN environment with
sufficient coverage.
Activate display of hidden phonebook entries. Switch the UE off.
The USIM #1 is placed in the device and this UE is switched on either in GSM or UTRAN environment
with sufficient coverage.
Test procedure
1. Search for the phone book entry “ADN1hidden" and “ADN2hidden”. Check that both ADNs are
not displayed.
2. Activate display of hidden phonebook entries. Enter the Hiddenkey “1234” on request.
3. Select the phone book entry “ADN1hidden” and perform a MOC to this telephone number.
4. Select the phone book entry “ADN2hidden" and deactivate hiding of this ADN. Enter the
Hiddenkey “1234” on request.
5. Add a new phone book entry with the alpha identifier “NewHiddenEntry” with any telephone
number. Activate hiding of this ADN. Enter the Hiddenkey “1234” on request.
6. Change the hidden key to “7777”. Enter the old hidden key “1234” and the new key. Repeat
entering the new hidden key on request.
7. Deactivate display of hidden phonebook entries. Enter the old Hiddenkey “1234” when
requested to enter the Hiddenkey.
8. Enter the Hiddenkey “7777” on request.
9. Search for the phone book entry “ADN1hidden", “ADN2hidden” and “NewHiddenEntry”. Check
that only “ADN2hidden” can be displayed.
10. When Hiddenkey reset to “FF..FF” insert a new ADNhidden.
Expected behaviour
1. Neither phone book entry “ADN1hidden" nor “ADN2hidden” can be displayed.
2. The UE prompts for the Hiddenkey while activating display of hidden phonebook entries.
3. A MOC can be performed to the telephone number stored in phone book entry “ADN1hidden”.
4. The UE prompts for the Hiddenkey during deactivation of hiding this ADN.
5. The UE prompts for the Hiddenkey during activation of hiding this ADN.
6. The UE prompts for the old Hiddenkey and twice for the new Hiddenkey.
7. The UE prompts for the Hiddenkey during deactivation of hiding of ADNs. The UE shall reject
the entered Hiddenkey and prompt to enter a new one.
8. The UE shall accept the new Hiddenkey.
9. “ADN2hidden” can be displayed. “ADN1hidden" and “NewHiddenEntry” are hidden and can
not be displayed.
10. UE checks that Hiddenkey is null and request the user to introduce a new Hiddenkey. Once
this is defined entered, the new ADNhidden can be stored.
4) The USIM is removed from the UE and checked in an external card reader:
Expected behaviour
1. The new entry was added in to the ADN
Record Number Alpha Identifier Number
XXXXXXX +34123456789
3. Check that ADN file Record Identifier coincide with Record Number in ADN file
4. The card is inserted in to the ME again
5. Look for the ADN “XXXXXXX“
6. The UE must display “XXXXXXXX, YYYYY and +34123456789” values
9. A mobile originated call is performed to <MSISDN #2> in national format (The phone book is
not used). The call is accepted and released afterwards. Then the Outgoing Call Information
list is checked for the available numbers.
10. A mobile originated call is performed to <MSISDN #3> in international format (The phone book
is not used). The call is accepted and released afterwards. Then the Outgoing Call Information
list is checked for the available numbers.
11. The USIM is removed from the UE and put in another UE supporting EFICI and EFOCI. The
Incoming, Outgoing and Missed Call Information list is checked for available numbers.
Expected behaviour
1. The Incoming and Outgoing Call Information list shall be deleted successfully.
2. The Incoming Call Information list shall include <MSISDN #1> and correct date and time when
the call was received. Additionally the call duration may be displayed.
3. The Incoming Call Information list shall include <MSISDN #1> and “Telephone2” and correct
date and time when the calls were received. For “Telephone2” the MSISDN may be displayed
additionally to the ADN Alpha identifier. Additionally the call duration may be displayed for
each entry.
4. The Incoming Call Information list shall include <MSISDN #1>, “Telephone2” and
“Telephone3” and correct date and time when the calls were received. For “Telephone2” and
“Telephone3” the MSISDN may be displayed additionally to the ADN Alpha identifier.
Additionally the call duration may be displayed for each entry.
5. The UE indicates that a call was missed. The Missed Call Information list shall include
<MSISDN #1> and correct date and time when the call was missed.
6. The UE indicates that a call was missed. The Missed Call Information list shall include
<MSISDN #1> and “Telephone2” and correct date and time when the calls were missed.. For
“Telephone2” the MSISDN may be displayed additionally to the ADN Alpha identifier.
7. The UE indicates that a call was missed. The Missed Call Information list shall
include<MSISDN #1>, “Telephone2” and “Telephone3” and correct date and time when the
calls were missed. For “Telephone2” and “Telephone3” the MSISDN may be displayed
additionally to the ADN Alpha identifier.
8. The Outgoing Call Information list shall include <MSISDN #1> and correct date and time when
the call was performed. Additionally the call duration may be displayed.
9. The Outgoing Call Information list shall include <MSISDN #1> and “Telephone2” and correct
date and time when the calls were performed. For “Telephone2” the MSISDN may be
displayed additionally to the ADN Alpha identifier. Additionally the call duration may be
displayed for each entry.
10. The Outgoing Call Information list shall include <MSISDN #1>, “Telephone1” and
“Telephone2” and correct date and time when the calls were performed. For “Telephone1” and
“Telephone2” the MSISDN may be displayed additionally to the ADN Alpha identifier.
Additionally the call duration may be displayed for each entry.
11. The Incoming, Outgoing and Missed Call Information list shall contain each <MSISDN #1>,
<MSISDN #2> and <MSISDN #3>. For each entry the correct date and time when the calls
were received, performed or missed shall be displayed. Additionally the call duration may be
displayed for each entry in the Incoming and Outgoing Call Information list. “Telephone1” and
“Telephone2” may be displayed instead of its MSISDNs.
4. The UE displays <<initial ICT value >+duration of incoming call> as accumulated incoming call
timer values. The value shall be presented in days, hours, minutes and seconds.
5. After release of the call the UE displays the correct duration of the incoming call.
6. The UE displays <<initial OCT value >+duration of outgoing call> accumulated outgoing call
timer values. The value shall be presented in days, hours, minutes and seconds.
7. The external card reader shall display the values
• EFICT = <<initial ICT value >+duration of incoming call>
• EFOCT = <<initial OCT value >+duration of outgoing call>
8. When during performing of the initial USIM configuration PIN2 was needed the UE shall
prompt for PIN2 after selecting the menu function for resetting the incoming and outgoing call
timer.
9. After release of the call the UE displays the correct duration of the outgoing call.
10. The UE displays <duration of incoming call> as accumulated incoming call timer values. The
value shall be presented in days, hours, minutes and seconds.
11. After release of the call the UE displays the correct duration of the incoming call.
12. The UE displays <duration of outgoing call> accumulated outgoing call timer values. The
value shall be presented in days, hours, minutes and seconds.
3. A mobile terminated call from <MSISDN #1> is performed. The call is accepted by the UE and
released afterwards.
Expected behaviour
1. The UE performs a location update and displays service. Depending on the USIM used the
following is presented on the display:
a. The UE displays <Service Provider Name> correctly. Additionally the UE may display
the name of the registered PLMN.
b. The UE displays both <Service Provider Name> and the name of the registered
PLMN correctly
c. The UE displays the UCS2 coded <Service Provider Name> correctly. Additionally the
UE may display the name of the registered PLMN.
d. The UE displays both <Service Provider Name> (UCS2 coded) and the name of the
registered PLMN correctly
2. After release of the call the UE shall display the service provider name as listed in step 1.
3. After release of the call the UE shall display the service provider name as listed in step 1.
3. The UE does not set up a WAP connection but displays that this is not possible due to an APN
restriction.
4. EFACL contains the APN <Any non existing APN> stored during initialisation as the only APN.
Test Procedure
Generate an MM using the MMS User Agent on the Terminal with the default MMS connectivity
settings provided by the card issuer and the MMS user preference information stored in the card and
send it.
Expected behaviour
The Terminal shall have read the set of supported MMS connectivity parameters stored first in
EFMMSICP, sent the MM using the MMS connectivity parameters stored first in the supported parameter
sets in EFMMSICP and sent the MM using the MMS user preference information stored in EFMMSUP.
25.1.16.4 Priority order of MMS Issuer User Connectivity Parameters over the
MMS User Connectivity Parameters
Description
Procedure to check if the MMS User Agent uses the MMS related information stored in the USIM
Related core specifications
3GPP TS 31.102
Reason for test
To ensure the Terminal's MMS User Agent uses the MMS connectivity parameter stored on the USIM
to connect to the network for MMS purposes.
To ensure that a MMS Issuer Connectivity Parameter set with lower priority (as defined by its position
in EFMMSICP) takes precedence over a MMS User Connectivity Parameter set with a higher priority.
Initial configuration
The USIM has to support the EFMMSICP;MMS connectivity parameters are preset by the issuer of the
USIM with the first set being the default. Such default preset MMS connectivity parameter set shall be
selected unless otherwise specified by the user.
Test Procedure
Generate an MM using the MMS User Agent on the Terminal with the default MMS User Connectivity
Parameters and the MMS user preference information stored in the card and send it.
Expected behaviour
The Terminal shall have sent the MM using the first supported MMS connectivity parameter set which
is stored in EFMMSICP.
Expected behaviour
UE updates the right values on the USIM card file and the information is displayed to the user.
Ciphering is activated:
Direction
Message Comments
UE - NW
Security Mode Command(Ciphering Algorithm=UEA1)
Security Mode Complete
There should be just one Authentication Request even if there were a MOC or MT call one after
another.
Test procedure for PS
1) The UE is switched on and the PIN is entered on request.
2) A mobile originated data connection is established. The PDP context is released afterwards: the
RRC connection is then released as well.
Expected behaviour
The signalling is checked in the log file. The UMTS authentication challenge is performed successfully:
Direction
Message Comments
UE - NW
Authentication Request (Ciphering key sequence number, RAND, AUTN)
Direction
Message Comments
UE - NW
Authentication Response(RES)
Ciphering is activated:
Direction
Message Comments
UE - NW
Security Mode Command(Ciphering Algorithm=UEA1)
Security Mode Complete
Check the number of EFGAS records (<EF-GAS-Rec>). With the external card reader the following
EFGAS records are created:
With the external card reader the following EFGRP records are set:
GRP Record Content
1 <GAS-Rec>
2 <GAS-Rec>
…
<GRP No> <GAS-Rec>
…
248 <GAS-Rec>
249 1
250 <GAS-Rec>
Check the number of EFeMail records (<eMail-Rec>). With the external card reader the following
EFeMail records are defined:
eMail Record Content
1 Dummy1@address.org
2 Dummy2@address.org
…
<eMAIL No> Dummy<GAS
No>@address.org
…
<eMail-Rec> Dummy<EF-GAS-Rec –
-1 1>@address.org
<eMail-Rec> <any valid eMail address>
• EFIAP (250) = <X bytes, see table> (ADN # 250 is assigned to the last first eMail record)
Bytes Value Length
1 If first object indicated after Tag 'A9' in 1 byte
EFPBR is ‘CA’ (eMail) THEN <EF-eMail-
Rec> ELSE ‘FF’
2 If second object indicated after Tag 'A9' 1 byte
EFPBR is first ‘CA’ (eMail) reference THEN
<EF-eMail-Rec> ELSE ‘FF’
… …
X If the Xth object indicated after Tag 'A9' in 1 byte
EFPBR is first ‘CA’ (eMail) reference THEN
<EF-eMail-Rec> ELSE ‘FF’
The USIM is placed in the device and this UE is switched on either in GSM or UTRAN environment
with sufficient coverage.
Test procedure
1) Check for all the following procedures that the device is stable and no reset is performed.
2) Select the phone book entry “PleaseDialThisNo” and perform a call to this destination.
3) If available select the menu function which filters for individual groups. Use this function and
filter for group “Last Group”.
4) Search for the phone book entry “NotInLastGroup”.
5) Select the phone book entry “PleaseDialThisNo” and perform a call to this destination.
6) Create a new eMail and send it to the eMail address associated to the ADN
“PleaseDialThisNo”. Check that the eMail is received.
Expected behaviour
1) The device is stable and no reset is performed.
2) The phone book entry could be selected correctly. A mobile originated call could be
established to the number <MSISDN>.
3) If the filter function is available the group “Last Group” could be filtered.
4) The phone book entry “NotInLastGroup” could not be found in the filtered “Last Group” entries.
5) The phone book entry could be selected correctly. A mobile originated call could be
established to the number <MSISDN>.
6) The eMail is received.
3) The USIM is removed from the UE and checked in an external card reader:
Expected behaviour
5) The UE presents a list of possible numbers and present the alpha identifiers for at least the
following entries in MSISDN.
Alpha Identifier Number
First Number +491234567890
Second Number 0123456789012
Third No +44123456789012
3) The USIM is removed from the UE and checked in an external card reader:
Expected behaviour
1) The UE presents a list of possible numbers and present the alpha identifiers for at least the
following entries in SDN.
Alpha Identifier Number
First Number +491234567890
Second Number 0123456789012
Third No +44123456789012
The USIM is placed in the device and this UE is switched on either in GSM or UTRAN environment
with sufficient coverage.
Test procedure
1) Check for all the following procedures that the device is stable and no reset is performed.
2) Select the phone book number 1
3) Find and select entry “PleaseDialThisNo” and perform a call to this destination.
4) Select the phone book number 2
5) Find and select entry “PleaseDialThisNo” and perform a call to this destination.
6) Select the phone book number 3
7) Find and select entry “PleaseDialThisNo” and perform a call to this destination.
Expected behaviour
1) The device is stable and no reset is performed.
2) The different phonebooks could be found and selected correctly.
3) The phone book entry could be selected correctly. A mobile originated call could be
established to the number <MSISDN>.
25.5.3.2 REFRESH
Description
Ensure that refresh requested by the USIM is correctly processed by the MS.
Related 3GPP core specifications
3GPP TS 31.111
Reason for test
To ensure that REFRESH command is correctly processed by the MS.
Initial configuration
MS in idle mode. USIM inserted with an application that makes use of REFRESH command:
- USIM application reset
- 3G session reset
Test procedure
1. Arrange for an event to occur which will cause the SIM to send a REFRESH (USIM application
reset) command.
2. Arrange for an event to occur which will cause the SIM to send a REFRESH (3G session reset)
command.
Expected behaviour
The MS shall refresh its memory regarding procedure notified.
Test procedure
Start the USAT application that makes usage of a local connection.
Expected behaviour
The USIM application triggered by the Local Connection event is started when connection is
established.
Test procedure
USAT Application shall declare a service at start-up.
Expected behaviour
The service shall be visible on the terminal.
The peripheral hosting the SIM Access Client initiates the Bluetooth connection to the UE hosting the
SIM Access Server and performs bonding. The security mode is set to 2. The link between Client and
Server is encrypted using Bluetooth baseband encryption.
Test procedure
1. SIM Access Client and Server execute a SAP Connect procedure. The SAP messages to be
exchanged are as follow:
a. CONNECT_REQ
b. CONNECT_RESP (ConnectionStatus = OK, Server can fulfil requirements)
c. STATUS_IND (StatusChange = Card_reset)
d. TRANSFER_ATR_REQ
e. TRANSFER_ATR_RESP
2. The SIM Access Client and Server perform the SAP “Transfer APDU” procedure as follows:
a. TRANSFER_APDU_REQ (CommandAPDU7816 = Select MF)
b. TRANSFER_APDU_RESP (ResultCode = OK, request processed correctly; ResponseAPDU
= R-APDU coded in accordance to ETSI SCP TS 102 221)
Expected behaviour
The SIM Access Client retrieves the Get Response data following the Select MF performed on the
UICC hosted in the UE.
25.9 EAP-AKA
Description
EAP is an authentication framework, which supports multiple authentication methods. It was designed
for use in network access authentication, where IP layer connectivity may not be available. EAP is
used to select a specific authentication mechanism, typically after the access point requests more
information in order to determine the specific authentication method to be used. EAP-AKA is the
mechanism for 3G authentication and session key distribution. It allows the end-user to access to the
Internet with its 3G equipment (Terminal and UICC). The EAP-AKA supplicant, which is providing to
the access point the credential information for authentication for the access point is composed of 2
parts, distributed in the UICC and the Terminal. The interface between the UICC and the Terminal is
described in ETSI TS 102 310. This test will insure that the operation of authentication handled by the
UICC and Terminal is successfully implemented.
Related 3GPP/ETSI core specifications
ETSI TS 102 310
Reason for test
To insure that the supplicant (authentication client) in the UICC-Terminal is able to authenticate with
the Radius (authentication server), through an Access Point compliant with WLAN 802.1x
(authenticator).
Initial configuration
The UICC and the Terminal are compliant with ETSI TS 102 310, and the Radius contains an
extension compliant with rfc2284.txt (Extensible Authentication Protocol), IETF, June 2000; rfc2865.txt
(Remote Authentication Dial In User Service), IETF, June 2000; rfc2869.txt (Radius Extensions –
including EAP), IETF, June 2000.
Test procedure
The Terminal detects the access point and the procedure for the authentication is proceeded, until the
terminal gets the rights to access the network.
Expected behaviour
The Terminal is allowed to access the network.
26 HSDPA
The following test cases shall be completed for terminals that support HSDPA.
Expected behaviour
The UE shall be able open and browse through HTML pages.
Use of an HSDPA bearer shall be verified by appropriate logging tools (where possible).
Use of an HSDPA bearer shall be verified by appropriate logging tools (where possible).
Two test procedures are defined, one to give an indication of the download speed and one to give an
indication of the download speed and the time taken to perform the FACH to DCH state transition.
Initial configuration
The UE is IMSI attached and PS attached on an HSDPA enabled 3G cell in its 3G HPLMN
The UE has a PDP context already active by means of internal browsing application or, alternatively,
by means of an external device (e.g. via a dial-up networking session or an internet sharing session).
Test procedure(s)
1. Manage on the UE (or on the external device) to download the same reference web page
rapidly 10 times in a row. (Ensure that the page is downloaded from the network each time
and not just loaded from the browser cache)
2. Verify than the download of the page is correct each time (number of elements)
3. Measure the time to download the 10 WEB pages and calculate the average download time
per page.
4. Manage on the UE (or on the external device) to download the same reference web page 10
times in a row leaving a 30 second pause between each download. (Ensure that the page is
downloaded from the network each time and not just loaded from the browser cache)
5. Verify than the download of the page is correct each time (number of elements)
6. Measure the time to download the 10 WEB pages and calculate the average download time
per page.
Expected behaviour
The UE shall be able to, in average, download a reference Web page within a reasonable period of
time when compared to other HSDPA capable UE’s on the same network.
2. Start an FTP/TFTP download for the reference device using the HSDPA RAB. Use an
uncompressible file larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes for cat 9 and
higher. If possible, utilize a server with minimal latency to the GGSN.
3. Measure the average throughput using a suitable application.
4. Repeat steps from 1 to 3 for the DUT.
5. Perform 10 times the steps form 1 to 4, selecting the best result for both DUT and reference
device.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the HSDPA capability of the device and the HSDPA RAB
available of the cell used.
Report the obtained throughput value for DUT and reference mobile.
The test is considered conclusive only if the throughput of the Reference Device or the DUT is higher
than the Minimum Realistic Throughput value described below, depending on the HSPA capability of
the devices.
Advertised Throughput Minimum Realistic Throughput
Downlink HSDPA / R99
FDD (ref. 3GPP 25.306) in field
Cat 16 & 18 (MIMO) 28.8 Mbit/s 15 Mbit/s
Cat 14 & 18 (no MIMO) 21.6 Mbit/s 13 Mbit/s
Cat 10 14.4 Mbit/s 9 Mbit/s
Cat 9 10.2 Mbit/s 7 Mbit/s
Cat 8 7.21 Mbit/s 4.8 Mbit/s
Cat 6 3.65 Mbit/s 2.8 Mbit/s
Cat 12 1.8 Mbit/s 1.4 Mbit/s
R99 384 kbit/s 350 kbit/s
2. Start an FTP/TFTP download for the DuT using the HSDPA RAB. Use an uncompressible file
larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes for cat 9 and higher. Utilize a
server with minimal latency to the GGSN.
3. Measure the average throughput on FTP/TFTP level using a suitable application.
4. Perform 3 times the steps form 1 to 3, selecting the best result for the DUT.
Expected behaviour
The best result on DuT shall be proportional to the HSDPA capability of the device and the HSDPA
RAB available of the cell used. The following minimum values are to be fulfilled:
Advertised Throughput Minimum Realistic Throughput
Downlink HSDPA / R99
FDD (ref. 3GPP 25.306) in Lab
Cat 16 & 18 (MIMO) 28.8 Mbit/s [TBD] Mbit/s
Cat 14 & 18 (no MIMO) 21.6 Mbit/s 18 (tbc) Mbit/s
Cat 10 14.4 Mbit/s 10.4 Mbit/s
Cat 9 10.2 Mbit/s 8.7 Mbit/s
Cat 8 7.21 Mbit/s 6.1 Mbit/s
Cat 6 3.65 Mbit/s 3.1 Mbit/s
Cat 4 1.8 Mbit/s 1.5 Mbit/s
R99 384 kbit/s 380 kbit/s
5. Perform 10 times the steps form 1 to 4, selecting the best result for both DUT and reference
device.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the UL capability of the device and the UL RAB available of
the cell used.
Report the obtained throughput value for DUT and reference mobile.
The test is considered conclusive only if the throughput of the Reference Device or the DUT is higher
than the Minimum Realistic Throughput value described below, depending on the HSPA capability of
the devices.
Advertised Throughput Minimum Realistic Throughput
Uplink EUL / R99
FDD (ref. 3GPP 25.306) in field
Cat 6 5,7 Mbit/s 3.3 Mbit/s
Cat 5 2 Mbit/s 1.4 Mbit/s
Cat 3 1,45 Mbit/s 1.0 Mbit/s
R99 384 kbit/s 350 kbit/s
Note: Ensure that when the “second call” is initiated that the PS data call is not re-configured or
downgraded to a R99 bearer.
Expected behaviour
The speech call continues and the speech quality is undisturbed.
The HSDPA PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Test procedure
Make a Video and HSDPA PS-data calls with 3G Terminal according to the table below. The first call
is mobile originated call. The second call is either mobile originated call or mobile terminated call.
Ensure that the Video call success and the quality is undisturbed. In data call, download a large file
(e.g. with FTP) parallel with Video call. Monitor the data flow with suitable software.
End the first call according to the table’s column “End First”. Ensure that the remaining call is not
disturbed.
Scenario First Call Second Call End First
A MO Video call MO PS-data call Video call
B MO PS-data call MO Video call PS-data call
C MO PS-data call MT Video call PS-data call
D MO PS-data call MT Video call Video call
Note: Ensure that when the “second call” is initiated that the PS data call is not re-configured or
downgraded to a R99 bearer.
Expected behaviour
The Video call continues and the quality is undisturbed.
The HSDPA PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Scenario E
Make a HSDPA-data call with 3G terminal. While downloading a large file (e.g. with FTP), use
terminals own email client to retrieve emails.
Scenario F
Make a HSDPA-data call with 3G terminal. While downloading a large file (e.g. with FTP), use
terminals own browser to download web page.
Note: Ensure that when the “second call” is initiated that the HSDPA data call is not re-
configured or downgraded to a R99 bearer.
Expected behaviour
The HSDPA PS-data call continues and the data stream is not interrupted.
A. Sending a MMS succeed.
B. Receiving a MMS succeed.
C. Sending a SMS succeed.
D. Receiving a SMS succeed.
E. Retrieving emails succeed while downloading.
F. Browsing succeed while downloading.
Scenario A:
1. Make a voice call and start an FTP/TFTP download for the reference device using the HSDPA
RAB. Use an uncompressible file larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes
for cat 9 and higher. If possible, utilize a server with minimal latency to the GGSN.
2. Measure the average throughput using a suitable application.
3. Repeat steps from 1 to 3 for the DUT
4. Perform 10 times the steps form 1 to 4, selecting the best result for both DUT and reference
device.
Scenario B
1. Make a video call and start an FTP/TFTP download for the reference device using the HSDPA
RAB. Use an uncompressible file larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes
for cat 9 and higher. If possible, utilize a server with minimal latency to the GGSN.
2. Measure the average throughput using a suitable application.
3. Repeat steps from 1 to 3 for the DUT
4. Perform 10 times the steps form 1 to 4, selecting the best result for both DUT and reference
device.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the HSDPA capability of the device and the HSDPA RAB
available of the cell used.
Report the obtained throughput value for DUT and reference mobile.
The test is considered conclusive only if the throughput of the Reference Device or the DUT is higher
than the Minimum Realistic Throughput value described below, depending on the HSPA capability of
the devices.
Advertised Throughput Minimum Realistic Throughput
Downlink HSDPA / R99
FDD (ref. 3GPP 25.306) in field
Cat 16 & 18 (MIMO) 28.8 Mbit/s 15 Mbit/s
Cat 14 & 18 (no MIMO) 21.6 Mbit/s 13 Mbit/s
Cat 10 14.4 Mbit/s 9 Mbit/s
Cat 9 10.2 Mbit/s 7 Mbit/s
Cat 8 7.21 Mbit/s 4.8 Mbit/s
Cat 6 3.65 Mbit/s 2.8 Mbit/s
Cat 12 1.8 Mbit/s 1.4 Mbit/s
R99 384 kbit/s 350 kbit/s
Initial configuration
Check the Lab Environment with a Reference Device (recommended by an Operator) to ensure that
the Minimum Realistic Throughput Values can be achieved.
Connect the DuT to a PC and use it as a modem. Ensure that the Connection Manager from the
device supplier is used. Where possible, the DuT shall be connected via USB.
The device under test (DuT) is IMSI attached and PS attached on an HSDPA enabled 3G cell in its 3G
HPLMN.
The UE has a PDP context already active by means of a dial-up networking session.
Test procedure
Verify that a dial-up networking session is already established for the DuT.
Scenario A
1. Make a voice call and start an FTP/TFTP download for the DuT using the HSDPA RAB. Use
an uncompressible file larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes for cat 9
and higher. Utilize a server with minimal latency to the GGSN.
2. Measure the average throughput on FTP/TFTP level using a suitable application.
3. Perform 3 times the steps form 1 to 3, selecting the best result for the DUT.
Scenario B
1. Make a video call and start an FTP/TFTP download for the DuT using the HSDPA RAB. Use
an uncompressible file larger than 20 Mbytes up to cat 8 and larger than 50 Mbytes for cat 9
and higher. Utilize a server with minimal latency to the GGSN.
2. Measure the average throughput on FTP/TFTP level using a suitable application.
3. Perform 3 times the steps form 1 to 3, selecting the best result for the DUT.
Expected behaviour
The best result on DuT shall be proportional to the HSDPA capability of the device and the HSDPA
RAB available of the cell used. The following minimum values are to be fulfilled:
Advertised Throughput Minimum Realistic Throughput
Downlink HSDPA / R99
FDD (ref. 3GPP 25.306) in Lab
Cat 16 & 18 (MIMO) 28.8 Mbit/s [TBD] Mbit/s
Cat 14 & 18 (no MIMO) 21.6 Mbit/s 18 (tbc) Mbit/s
Cat 10 14.4 Mbit/s 10.4 Mbit/s
Cat 9 10.2 Mbit/s 8.7 Mbit/s
Cat 8 7.21 Mbit/s 6.1 Mbit/s
Cat 6 3.65 Mbit/s 3.1 Mbit/s
Cat 4 1.8 Mbit/s 1.5 Mbit/s
R99 384 kbit/s 380 kbit/s
26.3.5 Relative Uplink FTP Throughput for HSDPA PS RAB during MultiRAB
NOTE: This test needs to be conducted with optimal conditions (optimum RF signal, low
traffic hours to avoid contention with other UEs, sufficient bandwidth of NodeB).
Description
Measure the average PS uplink throughput for the HSDPA uplink RAB during the simultaneous CS
and PS calls.
Related core specifications
3GPP TS 34.108 and 3GPP TS 25.331
5. Measure the throughput of both the upload and download using a suitable application.
NOTE: The TCP RX window size of both the laptop and FTP server shall be set
appropriately so that optimum simultaneous Uplink and Downlink performance is
achieved. If the TCP RX window size of the FTP server cannot be set to an
optimum configuration by the tester, then UDP protocol may be utilised to perform
this test case.
Expected behaviour
The UE shall be able to present average throughput values proportional to the HSDPA capability of
the device and the HSDPA uplink available on the cell used.
2. Now the device is moved to URA_PCH using the method indicated by the operator. No data
transfer is sent. When a dial-up session from a PC is used the personal firewall is still blocking
outgoing data transfer sent from the operating system.
3. When the device is in URA_PCH firewall blocking is disabled and data transfer is started
again.
Expected behaviour
1. The device is moved to CELL_PCH.
2. With the monitor on the device or on the Iub trace tool it is checked that the device is moved to
URA_PCH via CELL_FACH or CELL_DCH state.
3. The device is moved to CELL_DCH.
Expected behaviour
The UE shall be able open and browse through HTML pages.
Use of an EUL bearer shall be verified by appropriate logging tools (where possible).
NOTE: The TCP RX window size of both the laptop and FTP server shall be set
appropriately so that optimum simultaneous Uplink and Downlink performance is
achieved. If the TCP RX window size of the FTP server cannot be set to an
optimum configuration by the tester, then UDP protocol may be utilised to perform
this test case.
Expected behaviour
The UE shall be able to connect to the FTP server and successfully upload a file and download the
files simultaneously.
Use of an EUL bearer shall be verified by appropriate logging tools (where possible).
Note: Ensure that when the “second call” is initiated that the PS data call is not re-configured or
downgraded to a R99 bearer.
Expected behaviour
The speech call continues and the speech quality is undisturbed.
The EUL PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
Note: Ensure that when the “second call” is initiated that the PS data call is not re-configured or
downgraded to a R99 bearer.
Expected behaviour
The Video call continues and the quality is undisturbed.
The EUL PS-data call continues and the data stream is not interrupted.
After ending the other call, the first call continues and works normally.
27.3.4.1 Relative Uplink FTP Throughput for EUL PS RAB during MultiRAB
NOTE: This test needs to be conducted with optimal conditions (optimum RF signal, low
traffic hours to avoid contention with other UEs, sufficient bandwidth of NodeB).
Description
Measure the average PS uplink throughput for the EUL uplink RAB during the simultaneous CS and
PS calls.
27.3.4.2 Absolute Uplink FTP Throughput for EUL PS RAB during MultiRAB
NOTE: This test needs to be conducted under lab conditions (optimum RF signal, no
contention with other UEs, sufficient bandwidth of NodeB).
Description
Measure the average PS uplink throughput for the EUL uplink RAB during the simultaneous CS and
PS calls.
Related 3GPP core specifications
3GPP TS 34.108 and 3GPP TS 25.331
Reason for test
Obtain a measure of average uplink throughput for an EUL PS RAB.
Initial configuration
Check the Lab Environment with a Reference Device (recommended by an Operator) to ensure that
the Minimum Realistic Throughput Values can be achieved.
Connect the DuT to a PC and use it as a modem. Ensure that the Connection Manager from the
device supplier is used. Where possible, the DuT shall be connected via USB.
The device under test (DuT) is IMSI attached and PS attached on an EUL enabled 3G cell in its 3G
HPLMN.
The UE has a PDP context already active by means of a dial-up networking session.
Test procedure
Verify that a dial-up networking session is already established for the DuT.
Scenario A
1. Make a voice call and start an FTP/TFTP upload for the DuT using the HSDPA RAB. Use an
uncompressible file larger than 20 Mbytes. Utilize a server with minimal latency to the GGSN.
2. Measure the average throughput on FTP/TFTP level using a suitable application.
3. Perform 3 times the steps form 1 to 3, selecting the best result for the DUT.
Scenario B
1. Make a video call and start an FTP/TFTP upload for the DuT using the HSDPA RAB. Use an
uncompressible file larger than 20 Mbytes. Utilize a server with minimal latency to the GGSN.
2. Measure the average throughput on FTP/TFTP level using a suitable application.
3. Perform 3 times the steps form 1 to 3, selecting the best result for the DUT.
Expected behaviour
The best result on DuT shall be proportional to the EUL capability of the device and the EUL PS RAB
available of the cell used. The following minimum values are to be fulfilled:
Advertised Throughput Minimum Realistic Throughput
Uplink EUL / R99
FDD (ref. 3GPP 25.306) in Lab
Cat 6 5,7 Mbit/s 3.8 (tbc) Mbit/s
Cat 5 2 Mbit/s 1.6 Mbit/s
Cat 3 1,45 Mbit/s 1.2 Mbit/s
R99 384 kbit/s 370 kbit/s
Description
Measure the average PS uplink throughput for the EUL uplink RAB during the simultaneous CS and
PS calls.
Related core specifications
3GPP TS 34.108 and 3GPP TS 25.331
Reason for test
Obtain a measure of average uplink throughput for the EUL uplink RAB.
Initial configuration
The UE is switched on in EUL enabled UTRAN environment with sufficient coverage, so no cell
reselection to GSM is performed.
Scenario A
1. Establish a Voice call.
2. Establish a dial-up networking session.
3. Start an FTP/TFTP download. Use an uncompressible file larger than 20 Mbytes.
4. Simultaneously start an FTP/TFTP upload. Use an uncompressible file larger than 5 Mbytes.
5. Measure the throughput of both the upload and download using a suitable application.
Scenario B
1. Establish a Video call.
2. Establish a dial-up networking session.
3. Start an FTP/TFTP download. Use an uncompressible file larger than 20 Mbytes.
4. Simultaneously start an FTP/TFTP upload. Use an uncompressible file larger than 5 Mbytes.
5. Measure the throughput of both the upload and download using a suitable application.
NOTE: The TCP RX window size of both the laptop and FTP server shall be set
appropriately so that optimum simultaneous Uplink and Downlink performance is
achieved. If the TCP RX window size of the FTP server cannot be set to an
optimum configuration by the tester, then UDP protocol may be utilised to perform
this test case.
Expected behaviour
The UE shall be able to present average throughput values proportional to the EUL capability of the
device and the EUL uplink available on the cell used.
Initial configuration
The UE is IMSI attached and PS attached in its 3G HPLMN in a EUL cell. A PDP context is active
either by using the WAP browser or by a dial-up session.
Test procedure
1. Data transfer is started and the network moves the device to CELL_DCH. When there is no
monitor the data rate is checked.
2. Data transfer is ended. When a dial-up session from a PC is used a personal firewall is used
to block outgoing data transferee sent from the operating system.
3. When the device is in CELL_FACH firewall blocking is disabled and data transfer is started
again. When there is no monitor the data rate is checked.
Expected behaviour
1. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
2. The device is moved to CELL_FACH. When there is no monitor it shall be assumed that the
device is moved to CELL_FACH after N seconds of inactivity.
3. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
2. M seconds after entering CELL_FACH state the device is moved to CELL_PCH. When there
is no monitor it shall be assumed that the device is moved to CELL_PCH M seconds after
entering CELL_FACH.
3. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
This test requires a 3G network with the a CELL_DCH -> CELL_FACH -> CELL_PCH transition.
Related core specifications
3GPP TS 25.331
Reason for test
To ensure the UE is able to switch from CELL_PCH to RRC idle and back to CELL_DCH in EUL cells.
Initial configuration
The UE is IMSI attached and PS attached in its 3G HPLMN in a EUL cell. A PDP context is active
either by using the WAP browser or by a dial-up session. Data transfer is started and the network
moves the device to CELL_DCH. Then data transfer is stopped so the network moves the device into
CELL_FACH (if supported) and subsequent into CELL_PCH state. If a dial-up session was used it is
recommended to block outgoing traffic using a personal firewall after the stop of data transfer.
Test procedure
1. It is checked that the device is in Cell_PCH.
2. No data transfer is activated. When a dial-up session from a PC is used the personal firewall
is still blocking outgoing data transfer sent from the operating system.
3. When the device is in RRC idle firewall blocking is disabled and data transfer is started again.
When there is no monitor the data rate is checked.
Expected behaviour
1. The device is moved to CELL_PCH. When there is no monitor it shall be assumed that the
device is moved to CELL_PCH after N+M seconds of inactivity, as indicated by the operator
(see test case 23.10.1 and 23.10.2).
2. Between P and Q minutes after entering CELL_PCH state the device is moved to RRC idle
state. When there is no monitor it shall be assumed that the device is moved to RRC idle
Q minutes after entering CELL_PCH.
3. The device is moved to CELL_DCH. When there is no monitor the data indicates that the
device is in CELL_DCH and not in CELL_FACH.
Direction
Step Message Comments
UE - NW
1 RRCConnectionRequest RRC
2 RRCConnectionSetup RRC
RRCConnectionSetupComplete(ATTACH
3 RRC(EMM(ESM))
REQUEST(PDN CONNECTIVITY REQUEST))
4 AUTHENTICATION REQUEST EMM
5 AUTHENTICATION RESPONSE EMM
6 SECURITY MODE COMMAND EMM
7 SECURITY MODE COMPLETE EMM
(8) ESM INFORMATION REQUEST ESM(OPTIONAL)
(9) ESM INFORMATION RESPONSE ESM(OPTIONAL)
10 UECapabilityEnquiry RRC
12 UECapabilityInformation RRC
12 SecurityModeCommand RRC
13 SecurityModeComplete RRC
RRCConnectionReconfiguration(ATTACH
14 ACCEPT(ACTIVATE DEFAULT EPS BEARER RRC(EMM(ESM))
CONTEXT REQUEST))
15 RRCConnectionReconfigurationComplete RRC
ATTACH COMPLETE(ACTIVATE DEFAULT EPS
16 EMM(ESM)
BEARER CONTEXT ACCEPT)
17 RRCConnectionRelease RRC
Note: Step 14 - If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the
IPv4 address with DHCPv4 as specified in TS 29.061 [38]. If the UE receives an
IPv6 interface identifier, it may wait for the Router Advertisement from the network
with the IPv6 prefix information or it may send a Router Solicitation if necessary.
If A/Gb mode or Iu mode is supported by the UE, the UE shall in addition delete P-TMSI, P-
TMSI signature, RAI and GPRS ciphering key sequence number
3. UE shall not perform any additional Attach procedure.
30.1.1.3 Attach Reject, cause #14 "EPS Services not allowed in this PLMN"
30.1.1.3.1 Attach Reject, cause #14 "EPS Services not allowed in this PLMN" -
multiple PLMN environment
Description
Check the UE’s behaviour on the reject message with cause 14 ‘EPS Services not allowed in this
PLMN’
Related core specifications
3GPP TS 24.301, clause 5.5.1.2.5
Reason for test
To verify that the UE behaves correctly on a reject message ‘EPS Services not allowed in this PLMN’
Initial configuration
• UE is powered off and in automatic mode
• Two PLMNs are available:
- PLMN1 does not allow EPS Services (e.g. no roaming agreement)
- PLMN2 does have roaming agreement
Test procedure
1. Power on the UE and attempt Attach procedure on PLMN1.
2. EMM cause at the time of reception of Attach Reject message is equal to #14 “EPS Services
not allowed in this PLMN”
3. UE selects PLMN2 through automatic PLMN selection process.
Expected behaviour
1. The UE attempts to perform Attach procedure.
2. The UE will not re-attempt to perform an Attach procedure in the PLMN1.
3. UE performs a new ATTACH procedure on selected PLMN – PLMN2.
30.1.1.3.2 Attach Reject, cause #14 "EPS Services not allowed in this PLMN" -
single PLMN environment
Description
Check the UE’s behaviour on the reject message with cause 14 ‘EPS Services not allowed in this
PLMN’
Related core specifications
3GPP TS 24.301, clause 5.5.1.2.5
Reason for test
To verify that the UE behaves correctly on a reject message ‘EPS Services not allowed in this PLMN’
Initial configuration
• UE is powered off and in automatic mode
• Only one PLMN is present
• The PLMN which is present does not allow EPS Services (e.g. no roaming agreement)
Test procedure
1. Power on the UE and attempt Attach procedure on the PLMN.
2. EMM cause at the time of reception of Attach Reject message is equal to #14 “EPS Services
not allowed in this PLMN”
Expected behaviour
1. The UE attempts to perform Attach procedure.
2. The UE will not re-attempt to perform an Attach procedure.
30.1.1.4 Attach Reject, cause #25 "not authorised for this CSG"
Description
Check the UE’s behaviour on the reject message with cause #25 ‘Not authorized for this CSG’
Related core specifications
3GPP TS 24.301, clause 5.5.1.2.5, 3GPP TS 22.011, clause 8
Reason for test
To verify that the UE behaves correctly on a reject message ‘‘not authorized for this CSG’
To verify that the UE successfully performs the Attach procedure on cell without CSG Indicator of the
same PLMN after it was rejected with Reject Cause #25 ‘Not authorized for this CSG"
Initial configuration
• UE is powered off
• UE is in automatic mode
• Two eNodeB:
- eNode B1 has CSG Indicator = True and the broadcasted CSG Identity is part of
“Allowed CSG List” stored in UE
- eNode B2 has CSG Indicator = False
• Network has removed the UE from the list of CSG Member
Test procedure
1. Power on the UE and verify that UE sends Attach procedure on eNode B1
2. The network will send the ATTACH REJECT with cause #25 ‘Not authorized for this CSG’
3. UE sends ATTACH procedure on eNode B2.
Expected behaviour
1. The UE attempts to perform Attach procedure.
2. UE shall remove the CSG ID of the cell where the UE has sent the ATTACH REQUEST
message from “Allowed CSG list”. The UE shall search for a suitable cell in the same PLMN.
3. UE shall send ATTACH procedure using eNode B2.
Initial configuration
• UE is powered off
• UE is configured to automatic mode
• PLMN1 is E-UTRA radio access technology, PLMN2 can be any RAT that is supported by the
UE
• UE with USIM that contains EPS LOCI field with PLMN1 as last visited PLMN
• UE’s “forbidden PLMN list” is empty
• Roaming is not allowed with PLMN1
• Roaming is allowed with PLMN2
Test procedure
1. Power on the UE and verify that the UE sends an ATTACH REQUEST to the EPS network
PLMN1.
2. The EPS network PLMN1 shall respond to the UE with an ATTACH REJECT with Reject
Cause #11 ‘PLMN not allowed’.
3. Check that the UE performs an automatic PLMN selection to another PLMN (e.g. PLMN2)
without accessing the “forbidden PLMN”.
4. Perform a manual PLMN selection to PLMN1 and verify that the UE attempts to select the
“forbidden PLMN”.
5. Perform a manual PLMN selection to PLMN2 and verify that the UE successfully selects the
PLMN.
6. If the UE is not capable to set-up a mobile terminated service, verify that the UE is registered
by setting up a mobile originated connection.
Expected behaviour
1. The UE performs an Attach procedure on PLMN1.
2. The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED and shall delete
any GUTI, last visited registered TAI and KSI. The UE in S1 mode stores the PLMN identity in
the "forbidden PLMN" list and enters state EMM-DEREGISTERED.PLMN-SEARCH.
3. The UE performs an automatic PLMN selection without accessing the “forbidden PLMN”.
4. The UE attempts to perform an ATTACH REQUEST on PLMN1, is rejected with Cause #11
and indicates an error message to the user
5. The UE performs a successful ATTACH REQUEST on PLMN2.
6. .The UE establishes a service connection.
• The UE can not pass the authentication check, i.e. the RES received from the UE is different
from that generated by the network.
Test procedure
1. Power on the UE and verify that the UE sends an ATTACH REQUEST to the EPS network.
2. The EPS network shall respond to the UE with an ATTACH REJECT with Reject Cause #3
‘Illegal UE’.
3. Wait for 60s in order to check that the UE is not performing an ATTACH REQUEST to any
network.
4. Perform a manual network selection..
5. Power Cycle the UE and verify the UE sends an ATTACH REQUEST to the EPS network.
Expected behaviour
1. The UE performs an Attach procedure.
2. The UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED
3. The UE does not send any ATTACH REQUEST message
4. The UE does not send any ATTACH REQUEST message
5. The UE performs an Attach attempt procedure with IMSI1
30.1.1.7.1 Attach Reject, cause #15 "No suitable cells in TA", LTE only
Description
Check an E-UTRA only UE’s behaviour on the reject message with cause 15 ‘No suitable cells in TA’
in an E-UTRA only environment. This test should be performed in an area where the PLMN has E-
UTRA cells available. The test can be performed with a subscription which has not been provisioned
for E-UTRA but has been provisioned for UTRA on that PLMN.
Related core specifications
3GPP TS 24.301, clause 5.5.1.2.2 and clause 5.5.1.2.5
Reason for test
To verify that the UE behaves correctly on a reject message ‘‘No suitable cell in TA” from the E-UTRA
cell. The UE should obtain service on another TA of the same PLMN. If not available the UE shall
indicate the loss of service with an appropriate error message.
Initial configuration
• UE is powered off
• UE with USIM that contains IMSI1, GUTI1, TAI1, EPS update status “EU1:UPDATED”
• E-UTRA Cell(s) of PLMN1 available (all belonging to only one TA) and cell(s) of PLMN1 with
another Radio Technology
• UE with USIM that contains EPS LOCI field with PLMN1 as last visited PLMN
• UE’s “forbidden PLMN list” is empty
Test procedure
1. Ensure only PLMN1 with TA1 and PLMN1 with another Radio Technology is available. Power
on the UE and verify that the UE sends an ATTACH REQUEST to the EPS network PLMN1
and TA1.
2. The EPS network PLMN1 and TA1 shall respond to the UE with an ATTACH REJECT with
Reject Cause #15 ‘No suitable cells in TA’
3. Verify that the UE does not send an ATTACH REQUEST to other cells of TA1.
Expected behaviour
1. The UE performs an Attach procedure on PLMN1 and TA1.
2. The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED and shall delete
any GUTI, last visited registered TAI and KSI. In S1 mode, the UE shall store the current TAI
in the list of "forbidden tracking areas for roaming" and enter the state EMM-
DEREGISTERED.LIMITED-SERVICE.
3. The UE does not send another ATTACH REQUEST to the network PLMN1 and TA1.
30.1.1.7.2 Attach Reject, cause #15 “No suitable cells in TA”, Multimode
Description
Check a multimode UE’s behaviour on the reject message with cause 15 ‘No suitable cells in TA’ in a
multimode environment. This test should be performed in an area where the PLMN has UMTS and
LTE cells available. The test can be performed with a subscription which has not been provisioned for
LTE but has been provisioned for UMTS on that PLMN.
Related core specifications
3GPP TS 24.301, clause 5.5.1.2.2 and clause 5.5.1.2.5
Reason for test
To verify that the UE behaves correctly on a reject message ‘‘No suitable cell in TA” from the LTE cell.
The UE does not lose service and should obtain service on another Radio Technology of the same
PLMN.
Initial configuration
• UE is powered off
• UE with USIM that contains IMSI1, GUTI1, TAI1, EPS update status “EU1:UPDATED”
• LTE Cell(s) of PLMN1 available (all belonging to only one TA) and cell(s) of PLMN1 with
another Radio Technology
• Cells of PLMN2 (VPLMN) available.
• UE with USIM that contains EPS LOCI field with PLMN1 as last visited PLMN
• UE’s “forbidden PLMN list” is empty
Test procedure
4. Ensure only PLMN1 with TA1, PLMN1 with another Radio Technology and PLMN2 can be
seen by the UE. Power on the UE and verify that the UE sends an ATTACH REQUEST to the
EPS network PLMN1 and TA1.
5. The EPS network PLMN1 and TA1 shall respond to the UE with an ATTACH REJECT with
Reject Cause #15 ‘No suitable cells in TA’
6. Verify that the UE does not send an ATTACH REQUEST to other cells of TA1.
7. Verify that the UE sends an ATTACH REQUEST to the cell with another Radio Technology of
PLMN1
8. If the UE is not capable to set-up a mobile terminated service, verify that the UE is registered
by setting up a mobile originated connection
Expected behaviour
4. The UE performs an Attach procedure on PLMN1 and TA1.
5. The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED and shall delete
any GUTI, last visited registered TAI and KSI. In S1 mode, the UE shall store the current TAI
in the list of "forbidden tracking areas for roaming" and enter the state EMM-
DEREGISTERED.LIMITED-SERVICE.
6. The UE does not send another ATTACH REQUEST to the network PLMN1 and TA1.
7. The UE performs an Attach procedure on a cell of PLMN1 with another Radio Technology.
8. The UE establishes a service connection
30.1.1.8 Detach
2. If possible use a diagnostic tool to verify that the UE sends a DETACH REQUEST message
with Switch off in the Detach type set to “switch off" and Type of detach in the Detach type set
to “EPS detach”.
3. Perform a mobile terminated service connection (e.g. voice call or ping) from other device.
4. Verify that the mobile terminated service connection is not reachable.
Expected behaviour
2. The UE successfully performs the Detach procedure.
Example message flow:
Direction
Step Message Comments
UE - NW
1 RRCConnectionRequest RRC
2 RRCConnectionSetup RRC
3 RRCConnectionSetupComplete(DETACH REQUEST) RRC(EMM)
Direction
Step Message Comments
UE - NW
IE=“EPS ONLY”, EMM
Cause #18
15 RRCConnectionReconfigurationComplete RRC
ULInformationTransfer(ATTACH COMPLETE
16 (ACTIVATE DEFAULT EPS BEARER CONTEXT EMM(ESM)
ACCEPT))
17 RRCConnectionRelease RRC
Test procedure
1. Set the UE to “flight mode” or “offline” so that only the RF part is switched off
2. If possible use a diagnostic tool to verify that the UE sends a DETACH REQUEST message
with the Detach type IE indicating the type of detach, “combined EPS/IMSI detach” and
“normal detach”
3. The network responds with a DETACH ACCEPT message.
4. Perform a mobile terminated service connection (e.g. voice call or ping) from other device
Expected behaviour
At step 4, verify that the mobile terminated service connection is not reachable.
Example message flow:
Direction
Step Message Comments
UE - NW
1 RRCConnectionRequest RRC
2 RRCConnectionSetup RRC
3 RRCConnectionSetupComplete(DETACH REQUEST) RRC(EMM)
4 DETACH ACCEPT RRC
8 RRCConnectionRelease RRC
30.2.3.2 Combined Tracking Area Update; for EPS Services only, cause #18
"CS Domain not available"
Description
Check the UE behaviour in case if Combined TAU procedure is successful for EPS Services only.
Related core specifications
3GPP TS 24.301, section 5.5.3.3
Test procedure
The non-prioritized network(s) should transmit with a higher power than the prioritized network .The
UE is powered up at a location, where not less than 3 networks are available with a field strength of
GSM better than –85 dBm; P-CPICH RSCP better than -95 dBm for UMTS-FDD or RSRP is greater
than -110 dBm for E-UTRA
Expected behaviour
The UE shall select the prioritized PLMN network and ignore the non-prioritized PLMNs.
Test procedure
The non-prioritized network(s) should transmit with a higher power than the prioritized network .The
UE is powered up at a location, where not less than 3 networks are available with a field strength of
GSM better than –85 dBm; P-CPICH RSCP better than -95 dBm for UMTS-FDD or RSRP is greater
than -110 dBm for E-UTRA
Expected behaviour
The UE shall select the prioritized PLMN network and ignore the non-prioritized PLMNs.
For this test a special USIM is recommended. For this card the HPLMN Search Period Timer
(EFHPPLMN) be set to 6 minutes (“01”)
UE has already successfully selected the prioritized network VPLMN A and if left on, in automatic
network selection mode.
Test procedure
The UE is powered up at a location, where not less than 3 networks are available with a field strength
of GSM better than –85 dBm; P-CPICH RSCP better than -95 dBm for UMTS-FDD or RSRP is greater
than -110 dBm for E-UTRA
While driving around the coverage of VPLMN A shall be lost (for all radio access technologies of this
PLMN). The device should select VPLMN B.
One drives to a location where both, VPLMN A and VPLMN B are available.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer (EFHPPLMN) so
that a PLMN background scan is activated.
Expected behaviour
It shall be checked that the device selects VPLMN A after expiry of HPLMN Search Period Timer
(EFHPPLMN).
Initial configuration
An USIM shall be used for this test where:
On the USIM The MCC / MNC of the Preferred VPLMN A are put on the last
• PLMN Selector (EFPLMNwAcT) position of the PLMN Selector.
All other fields in all PLMN Selectors (EFPLMNwAcT, EFOPLMNwAcT)
are filled with network codes corresponding to networks not
available at the test location.
Access Technology for EFPLMNwAcT and EFOPLMNwAcT (2 bytes,
set to C0 80)
For this test a special USIM is recommended. For this card the HPLMN Search Period Timer
(EFHPPLMN) be set to 6 minutes (“01”) UE has already successfully selected the prioritized network
VPLMN A and if left on, in automatic network selection mode.
Test procedure
The UE is powered up at a location, where not less than 3 networks are available with a field strength
of GSM better than –85 dBm; P-CPICH RSCP better than -95 dBm for UMTS-FDD or RSRP is greater
than -110 dBm for E-UTRA
While driving around, the coverage of VPLMN A shall be lost (for all radio access technologies of this
PLMN). The device shall then select a non prioritized VPLMN.
One drives to a location where both, VPLMN A and the non prioritized VPLMN are available.
The tester shall wait for a period of time greater than the HPLMN Search Period Timer (EFHPPLMN) so
ensure a PLMN background scan is activated.
Expected behaviour
It shall be checked that the device selects VPLMN A after expiry of HPLMN Search Period Timer
(EFHPPLMN).
30.3.1.5 Automatic Mode - UE ignores CSG cell if Allowed CSG list is empty
or not supported
Description
Verification that the UE correctly selects a designated and prioritized network in case if it is not
supporting CSG (Closed Subscriber Group) or Allowed CSG list is empty
Related core specifications
3GPP TS 23.122, clause 3.1A, 3GPP TS 36.304, clause 4.3, 3GPP TS 22.011, clause 8, 3GPP TS
36.331, clause B.2
Reason for test
The purpose of the test is to ensure that the MS camps on a cell in that PLMN only if the cell is not a
CSG cell.
Initial configuration
UE does not support CSG, or in case if it supports EFACSGL is not present on USIM card.
UE is powered off in automatic mode.
Two cells with the same PLMN ID (MCC-MNC):
- Cell 1 with CSG ID1
- Cell 2 is not an CSG Cell
Cell 1 has higher RSRP than Cell 2.
Both cells fulfils S criterion.
Test procedure
1. UE is powered on
31 MOBILITY
context remains viable before and after the reselections. Where possible, this procedure should be
carried out as follows:
• Between cells sharing a Tracking Area
• Between cells utilising different E-UTRA ARFCNs belonging to a common E-UTRA frequency
band
• In areas of poor signal strength.
Expected behaviour
The UE should perform reselections correctly, without losing service, and its PDN connectivity should
remain viable before and after the reselections. The UE should successfully establish a mobile
terminated service connection after the reselections. If the UE is not capable to setup a mobile
terminated service, verify that the UE can setup a mobile originated connection (e.g. Service Request
procedure)
31.1.2.1.2 Idle Mode UTRA -> E-UTRA Reselection – PDP Context not active
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS 25.304, clause 5.2.6.1.2a and 5.2.6.1.4a
Reason for test
To ensure that the UE performs correctly an Idle Mode 3G->E-UTRA reselection procedure without
losing service.
Initial configuration
• UE is powered on and in IDLE state (RRC_IDLE)
• PDP Context not active
• UE is registered in UTRAN cell
• E-UTRAN and UTRAN cells available on the same PLMN
Test procedure
1. Move from the coverage area of UTRA to the coverage area of E-UTRA Service.
2. Ensure that the UE performs reselection including a TAU procedure, if ISR is not active, into
E-UTRA cell as expected. During the reselection it is imperative the UE remains in service at
all time.
3. Verify that the UE is connected by setting up a mobile terminated connection.
If the UE is not capable to set-up a mobile terminated service, verify that the UE is registered
to the new Tracking Area by setting up a mobile originated connection without establishing a
redundant Tracking Area Update procedure.
Expected behaviour
2. The UE should perform the reselection including a TAU procedure, if ISR is not active, in the
E-UTRA cell correctly, without losing service.
3. The UE establishes a service connection.
31.1.2.1.3 Idle Mode UTRA -> E-UTRA Reselection - PDP context active
Description
The UE should perform a reselection without losing service.
Related core specifications
3GPP TS 25.304, clause 5.2.6.1.2a and 5.2.6.1.4a
Reason for test
To ensure that the UE performs correctly an Idle Mode 3G->E-UTRA reselection procedure without
losing service.
Initial configuration
• UE is powered on and in IDLE state (RRC_IDLE)
• PDP context active
• UE is registered in UTRAN cell
• E-UTRAN and UTRAN cells available on the same PLMN
Test procedure
1. Move from the coverage area of UTRA to the coverage area of E-UTRA Service.
2. Ensure that the UE performs reselection including a TAU procedure, if ISR is not active, into
E-UTRA cell as expected. During the reselection it is imperative the UE remains in service at
all time.
3. Verify that the UE is connected by setting up a mobile terminated connection.
If the UE is not capable to set-up a mobile terminated service, verify that the UE is registered
to the new Tracking Area by setting up a mobile originated connection without establishing a
redundant Tracking Area Update procedure
Expected behaviour
2. The UE should perform the reselection including a TAU procedure, if ISR is not active, in the
E-UTRA cell correctly, without losing service.
3. The UE establishes a service connection
31.1.2.2.2 Idle Mode GERAN -> E-UTRA Reselection – PDP Context not active
Description
The UE should perform a reselection without losing service.
31.1.2.2.3 Idle Mode GERAN -> E-UTRA Reselection - PDP Context active
Description
The UE should perform a reselection without losing service.
Related core specifications
TS 45.008, clause 10.1.3.3 and TS 44.018, clause 3.4.1.2.1.1a
Reason for test
To ensure that the UE performs correctly an Idle Mode 2G->E-UTRA reselection procedure without
losing service.
Initial configuration
• UE is powered on and in IDLE state (GSM Idle/GPRS Packet Idle)
• UE is registered in GERAN cell
• PDP context is active
• E-UTRAN and GERAN cells available on the same PLMN
Test procedure
1. Move from the coverage areas of GERAN to the coverage area of E-UTRA Service.
2. Ensure that the UE performs reselection including a TAU procedure, if ISR is not active, into
E-UTRA cell as expected. During the reselection it is imperative the UE remains in service at
all time.
3. Verify that the UE is connected by setting up a mobile terminated connection.
If the UE is not capable to set-up a mobile terminated service, verify that the UE is registered
to the new Tracking Area by setting up a mobile originated connection without establishing a
redundant Tracking Area Update procedure
Expected behaviour
2. The UE should perform the reselection including a TAU procedure, if ISR is not active, in the
E-UTRA cell correctly, without losing service.
3. The UE establishes a service connection
31.2 Handover
31.2.1 E-UTRA Handover
Description
The UE should perform handovers as requested by the network, and behave as expected from the
user perspective without losing services.
Related core specifications
3GPP TS36.300, 3GPP TS 36.331, 3GPP TS 36.423, 3GPP TS 36.413, 3GPP 23.401
Reason for test
To ensure that the UE performs handovers correctly without losing services.
Initial configuration
There must be an appropriate number of E-UTRA cells available on the same PLMN. Required EPS
bearers to be tested should be active, and available in all parts of the test route.
Test procedure
Move between the coverage areas of different cells, ideally on a long test route. The test route should
contain as many of the scenarios listed in the table above as possible. Ensure that the UE performs
reselections/handovers as expected. During the test drive it is imperative the UE remains in service at
all times, that the EPS bearer in question is maintained throughout the test route, and that the UE is
always able to receive mobile terminating calls.
Scenario A:
Only default bearer is required for the scenario A and only a basic test case (e.g. FTP Download).
1 This scenario is designed to test inter eNB Handovers – S1 Based (no X2 interface between eNB)
2 This scenario is designed to test inter eNB Handovers – X2 Based
3 This scenario is designed to test inter MME Handovers
4 This scenario is designed to test inter eNB Handovers with cells belonging to different E-UTRA ARFCN within common
band
5 This scenario is designed to test inter eNB Handovers with cells belonging to different E-UTRA ARFCN and different E-
UTRA band.
Expected behaviour
The UE should perform handovers correctly, without losing service, and its PDN connectivity should
remain viable before and after the handovers. The UE should successfully continue the services after
the handovers.
Description
The UE should perform Inter RAT handovers as requested by the network, and behave as expected
from the user perspective without interruption of data transfer.
Related core specifications
TS 36.331, clause 5.4.3.3, clause 5.4.2.3
Reason for test
To ensure that the UE performs Inter RAT handovers correctly without interruption of data transfer.
Initial configuration
• There must be an appropriate number of E-UTRA and UTRA cells available on the same
PLMN. Required EPS bearers to be tested should be active, and available in all parts of the
test route.
• UE is registered
• UE has a packet bearer assigned
• Download of a file with sufficient size from FTP server set up and running
Test procedure
Move between the coverage areas of different cells, ideally on a long test route. The test route should
contain the scenarios listed in the table above. Ensure that the UE performs handovers as expected.
During the test drive it is imperative the UE remains in service at all times, that the IP connection in
question is maintained throughout the test route, that the FTP download is not interrupted.
Scenario A:
Only default bearer is required for the scenario A and only a basic test case (e.g. FTP Download).
Expected behaviour
The UE should perform handovers correctly, without losing service, and its PDP context should remain
viable before and after the handovers. The UE should successfully continue the FTP downloads after
the handovers.
1 This scenario is designed to test inter RAT Handovers – E-UTRA -> UTRA
2 This scenario is designed to test inter RAT Handovers – UTRA ->E-UTRA
3 This scenario is designed to test inter RAT Handovers – E-UTRA -> GERAN
Description
The UE should perform Inter RAT handovers as requested by the network, and behave as expected
from the user perspective without interruption of data transfer.
Related core specifications
TS 36.331, clause 5.4.3.3, clause 5.4.2.3
Reason for test
To ensure that the UE performs Inter RAT handovers correctly without interruption of data transfer.
Initial configuration
• There must be a sufficient number of E-UTRA and GERAN cells available on the same PLMN.
Required packet bearers to be tested should be active, and available in all parts of the test
route.
• UE is registered
• UE has a default bearer assigned
• Download of a file with sufficient size from FTP server set up and running
Test procedure
Move between the coverage areas of different cells on a test route. The test route(s) should contain
the scenarios listed in the table above. Ensure that the UE performs reselections/handovers as
expected. During the test drive it is imperative the UE remains in service at all times, that the packet
bearer in question is maintained throughout the test route and that the FTP download is resumed
correctly.
Scenario A:
Only default bearer is required for the scenario A and only a basic test case (e.g. FTP Download).
Expected behaviour
The UE should perform handovers correctly, without losing service, and its PDP context should remain
viable before and after the handovers. The UE should successfully resume the FTP downloads after
the handovers.
Description
In case the network and/or UE does not support Inter-RAT handover procedures at the edge of an E-
UTRAN coverage area and the network instead sends an RRC Connection Release with redirection to
UTRAN (31.2.3.1) or GERAN (31.2.3.2), the UE should reselect to the given UTRAN or GERAN cell
and re-establish the connection. The data transfer is interrupted during the procedure but continues
once the UE is connected via UTRAN or GERAN.
Related core specifications
TS 36.331, clause 4.2.1
TS 36.331, clause 6.2.2, RRC Connection Release Message definition
TS 36.331, Annex B.1, Table B.1-2
Test procedure
1. Setup an FTP session to a controlled FTP site on both DUT and reference device.
2. Start an FTP download for DUT and reference device using the E-UTRA E-RAB. Use a large
incompressible file based on the available E-RAB. If possible, utilize a server with minimal
latency to the P-GW.
3. Start moving between cells on the route.
4. Measure the average throughput using a suitable application.
5. Ensure that downloading continues throughout the route, restart download when necessary,
ensure that the time between downloads does not cause the expiry of any inactivity timers,
thus keeping the data session active.
Expected behaviour
The average throughput over all downloads on DUT shall be comparable with the result of the
reference mobile (no more than 10% worse), and shall be proportional to the E-UTRA capability of the
device and the E-UTRA E-RAB available of the cell used.
Report the obtained throughput value for DUT and reference device.
Expected behaviour
The average throughput over all uploads on DUT shall be comparable with the result of the reference
mobile (no more than 10% worse), and shall be proportional to the E-UTRA capability of the device
and the E-UTRA E-RAB available of the cell used.
Report the obtained throughput value for DUT and reference device.
32 PS Data
Expected behaviour
After step 3: Verify that PDN Connectivity is functional to the network where this APN gives
access to (e.g. loading a designated HTML page, which is only accessible via this network).
Example message flow:
Direction
Step Message Comments
UE - NW
1 RRCConnectionRequest RRC
2 RRCConnectionSetup RRC
RRC(EMM(ESM))
RRCConnectionSetupComplete(ATTACH
3 ESM Information transfer
REQUEST(PDN CONNECTIVITY REQUEST))
flag=TRUE
4 AUTHENTICATION REQUEST EMM(OPTIONAL)
5 AUTHENTICATION RESPONSE EMM(OPTIONAL)
6 SECURITY MODE COMMAND EMM(OPTIONAL)
7 SECURITY MODE COMPLETE EMM(OPTIONAL)
8 ESM INFORMATION REQUEST ESM(OPTIONAL)
9 ESM INFORMATION RESPONSE ESM(OPTIONAL)
10 UECapabilityEnquiry RRC
12 UECapabilityInformation RRC
12 SecurityModeCommand RRC
13 SecurityModeComplete RRC
RRCConnectionReconfiguration(ATTACH
RRC(EMM(ESM))
14 ACCEPT(ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST)),
15 RRCConnectionReconfigurationComplete RRC
ULInformationTransfer(ATTACH COMPLETE
16 (ACTIVATE DEFAULT EPS BEARER CONTEXT RRC (EMM(ESM))
ACCEPT))
17 FIRST UPLINK DATA
18 FIRST DOWNLINK DATA
Direction
Step Message Comments
UE - NW
RRCConnectionSetupComplete(SERVICE
3 RRC(EMM)(Optional)
REQUEST)
4 IDENTITY REQUEST EMM(Optional)
5 IDENTITY RESPONSE EMM(Optional)
6 AUTHENTICATION REQUEST EMM(Optional)
7 AUTHENTICATION RESPONSE EMM(Optional)
8 SECURITY MODE COMMAND EMM(Optional)
9 SECURITY MODE COMPLETE EMM(Optional)
10 SecurityModeCommand RRC(Optional)
11 SecurityModeComplete RRC(Optional)
12 RRCConnectionReconfiguration RRC(Optional)
13 RRCConnectionReconfigurationComplete RRC(Optional)
14 PDN CONNECTIVITY REQUEST ESM
15 PDN CONNECTIVITY REJECT, CAUSE 27 ESM
Direction
Step Message Comments
UE - NW
13 RRCConnectionReconfigurationComplete RRC(Optional)
14 PDN CONNECTIVITY REQUEST ESM
RRCConnectionReconfiguration [ ACTIVATE
15 RRC(EMM, ESM)
DEFAULT EPS BEARER CONTEXT REQUEST]
16 RRCConnectionReconfigurationComplete RRC(EMM, ESM)
ACTIVATE DEFAULT EPS BEARER CONTEXT
17 ESM
ACCEPT
Expected behaviour
The UE shall be able to ping the known destination.
32.3 PS performances
32.3.1 PS performances (good coverage - relative measurement)
5. Perform 15 times the steps from 1 to 4, selecting the best result for both DUT and reference
device. Ensure that the time between runs does not cause the expiry of any inactivity timers,
thus keeping the data session active.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the E-UTRA capability of the device and the E-UTRA E-RAB
available of the cell used.
The test is considered conclusive only if the throughput of the Reference Device or the DUT is higher
than the Minimum Realistic Throughput value described below, depending on the capability of the
devices
Report the obtained throughput value for DUT and reference mobile.
Advertised Throughput
Downlink Bandwidth Minimum Realistic Throughput in field
FDD (ref. 3GPP 36.306)
Cat 5 5 MHz 75 Mbit/s [TBD] [TBD]
Cat 4 5 MHz 37,5 Mbit/s [TBD] [TBD]
Cat 3 5 MHz 25 Mbit/s [TBD] [TBD]
Cat 2 5 MHz 12,5 Mbit/s [TBD] [TBD]
Cat 1 5 MHz 2,5 Mbit/s [TBD] [TBD]
Cat 5 10 MHz 150 Mbit/s [TBD] [TBD]
Cat 4 10 MHz 75 Mbit/s [TBD] [TBD]
Cat 3 10 MHz 50 Mbit/s [TBD] [TBD]
Cat 2 10 MHz 25 Mbit/s [TBD] [TBD]
Cat 1 10 MHz 5 Mbit/s [TBD] [TBD]
Cat 5 20 MHz 300 Mbit/s [TBD] [TBD]
Cat 4 20 MHz 150 Mbit/s [TBD] [TBD]
Cat 3 20 MHz 100 Mbit/s [TBD] [TBD]
Cat 2 20 MHz 50 Mbit/s [TBD] [TBD]
Cat 1 20 MHz 10 Mbit/s [TBD] [TBD]
2. Start a FTP/TFTP upload for the reference device using the E-UTRA E-RAB. Use an
incompressible file sufficient for at least 60 seconds of data transfer based on the available E-
RAB. If possible, utilize a server with minimal latency to the P-GW.
3. Measure the average throughput using a suitable application.
4. Repeat steps from 1 to 3 for the DUT.
5. Perform 15 times the steps from 1 to 4, selecting the best result for both DUT and reference
device. Ensure that the time between runs does not cause the expiry of any inactivity timers,
thus keeping the data session active.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the E-UTRA capability of the device and the E-UTRA E-RAB
available of the cell used.
The test is considered conclusive only if the throughput of the Reference Device or the DUT is higher
than the Minimum Realistic Throughput value described below, depending on the capability of the
devices
Report the obtained throughput value for DUT and reference mobile.
Advertised Throughput
Uplink Bandwidth Minimum Realistic Throughput in field
FDD (ref. 3GPP 36.306)
Cat 5 5 MHz 18,75 Mbit/s [TBD] [TBD]
Cat 4 5 MHz 12,25 Mbit/s [TBD] [TBD]
Cat 3 5 MHz 12,25 Mbit/s [TBD] [TBD]
Cat 2 5 MHz 6,25 Mbit/s [TBD] [TBD]
Cat 1 5 MHz 1,25 Mbit/s [TBD] [TBD]
Cat 5 10 MHz 37,5 Mbit/s [TBD] [TBD]
Cat 4 10 MHz 25 Mbit/s [TBD] [TBD]
Cat 3 10 MHz 25 Mbit/s [TBD] [TBD]
Cat 2 10 MHz 12,5 Mbit/s [TBD] [TBD]
Cat 1 10 MHz 2,5 Mbit/s [TBD] [TBD]
Cat 5 20 MHz 75 Mbit/s [TBD] [TBD]
Cat 4 20 MHz 50 Mbit/s [TBD] [TBD]
Cat 3 20 MHz 50 Mbit/s [TBD] [TBD]
Cat 2 20 MHz 25 Mbit/s [TBD] [TBD]
Cat 1 20 MHz 5 Mbit/s [TBD] [TBD]
Initial configuration
The DUT and Reference UE shall
• have identical DL/UL capabilities and be in a good coverage area
• have similar TCP stack behaviour (e.g. TCP Ack preference)
• have an EPS Bearer on their HPLMN by accessible by an FTP client [either built-in or external
application].
Test procedure
1. Setup an FTP/TFTP session to a controlled FTP site.
2. Start a FTP/TFTP download for the reference device using the E-UTRA E-RAB. Use an
incompressible file sufficient for at least 60 seconds of data transfer based on the available E-
RAB. If possible, utilize a server with minimal latency to the P-GW.
3. Start a FTP upload for the reference device using the E-UTRA E-RAB. Use an incompressible
file sufficient for at least 60 seconds of data transfer based on the available E-RAB. If
possible, utilize a server with minimal latency to the P-GW.
4. Measure the average throughput using a suitable application.
5. Repeat steps from 1 to 4 for the DUT.
6. Perform 15 times the steps from 1 to 5, selecting the best result for both DUT and reference
device. Ensure that the time between runs does not cause the expiry of any inactivity timers,
thus keeping the data session active.
Expected behaviour
The best result on DUT shall be comparable with the best result of the reference mobile (no more than
10% worse), and shall be proportional to the E-UTRA capability of the device and the E-UTRA E-RAB
available of the cell used.
Report the obtained throughput value for DUT and reference mobile.
Test procedure
1. Setup an FTP/TFTP session to a controlled FTP site using a suitable application.
2. Initiate the upload of an uncompressible file sufficient for at least 60 seconds of data transfer,
from the UE to the remote host. If possible utilize a server with minimal latency to the P-GW.
3. Measure the average throughput using the application. If possible, use a diagnostic tool to
record the resource block allocations and modulation scheme used.
4. Repeat steps 3-4, fourteen more times, for a total of 15 transfers. Ensure that the time
between runs does not cause the expiry of any inactivity timers, thus keeping the data session
active.
Expected behaviour
The UE shall upload the test file with a minimal average throughput to be determined by the carrier.
Advertised Throughput
Downlink Bandwidth Minimum Throughput
FDD (ref. 3GPP 36.306)
Cat 5 5 MHz 18,75 Mbit/s [TBD] [TBD]
Cat 4 5 MHz 12,25 Mbit/s [TBD] [TBD]
Cat 3 5 MHz 12,25 Mbit/s [TBD] [TBD]
Cat 2 5 MHz 6,25 Mbit/s [TBD] [TBD]
Cat 1 5 MHz 1,25 Mbit/s [TBD] [TBD]
Cat 5 10 MHz 37,5 Mbit/s [TBD] [TBD]
Cat 4 10 MHz 25 Mbit/s [TBD] [TBD]
Cat 3 10 MHz 25 Mbit/s [TBD] [TBD]
Cat 2 10 MHz 12,5 Mbit/s [TBD] [TBD]
Cat 1 10 MHz 2,5 Mbit/s [TBD] [TBD]
Cat 5 20 MHz 75 Mbit/s [TBD] [TBD]
Cat 4 20 MHz 50 Mbit/s [TBD] [TBD]
Cat 3 20 MHz 50 Mbit/s [TBD] [TBD]
Cat 2 20 MHz 25 Mbit/s [TBD] [TBD]
Cat 1 20 MHz 5 Mbit/s [TBD] [TBD]
33 UICC/USIM Aspects
TS 31.101 subclause 7
Reason for test
To ensure that PIN change fails when the new PIN is only 3 digits long
Initial configuration
UE in idle mode. PIN enabled
Test procedure
Scenario A:
Dial the code **04*OLD*NEW*NEW# (where OLD is the old PIN and NEW is the new 3-digit PIN)
to change the PIN. Check that the mobile indicates that the command has failed, giving the
reason.
Scenario B:
Repeat procedure from scenario A, but using the phone's menus to send the command.
Expected behaviour
In both scenarios, the mobile shall clearly indicate that the command has failed displaying the reason.
Repeat procedure from scenario A, but using the phone's menus to send the command.
Expected behaviour
In both scenarios, the mobile clearly indicates that the command has failed giving the reason.
Expected behaviour
In both scenarios the mobile clearly indicates that the command has failed giving the reason.
Expected behaviour
For both scenarios:
1. Check that the new PIN2 is accepted by the mobile and an indication is given showing
whether this procedure was successful
2. New PIN2 code is accepted and access to for e.g. FDN is enabled
34 E-UTRA Voice
34.1.5 MO VoIP call & simultaneous FTP downlink and FTP uplink
[Test to be defined]
34.2 PS performances
34.2.1 PS performances (good coverage - relative measurement)
Test procedure
1. Make a voice call to a phone (PSTN or mobile phone) and verify the UE sends an EXTENDED
SERVICE REQUEST message with Service type set to "mobile originating CS fallback or
1xCS fallback".
2. The NW sends a SERVICE REJECT message with EMM cause set to "CS domain temporarily
not available".
Expected behaviour
1. –
2. A voice connection in both directions is not established, and an active voice call indicator is
not displayed.
Test procedure
1. Make a voice call to a busy ISDN number. Ensure that the mobile correctly indicates the busy
status of the distant party.
2. Make a voice call to a busy PSTN number. Ensure that the mobile correctly indicates the busy
status of the distant party.
3. Make a voice call to a busy PBX extension. Ensure that the mobile correctly indicates the busy
status of the distant party.
4. Make a voice call to a busy Mobile number. Ensure that the mobile correctly indicates the
busy status of the distant party.
In each case, check that SS notification (such as "call is forwarded") is correctly displayed and does
not disturb the call setup. Check that busy tone is audible at the MS.
Expected behaviour
The MS attempts each call correctly, and SS notification information is correctly displayed and that
busy indication is audible.
Test procedure
1. Make a voice call to a number in another country, by using a number including the +
international prefix and the full international number. Ensure that the call completes correctly.
2. Make a voice call to a number in the same country as the mobile, by using a number including
the + international prefix and the full international number. Ensure that the call completes
correctly.
3. Repeat step 1 using a stored number containing the + prefix
4. Repeat step 2 using a stored number containing the + prefix
In each case, check that Call Waiting Notification, COLP and SS notification (such as "call is
forwarded") is correctly displayed and does not disturb the call setup. Check that alerting tone is
audible at the MS and that voice connection in both directions is established.
Expected behaviour
The MS completes each call correctly, COLP, Call Waiting and SS notification information is correctly
displayed, alerting indication is audible, and a voice connection in both directions is established.
40.1.4 Mobile origin. call complete (to ISDN phone); CLIR temporarily
deactivated (*31#DN)
Description
The MS shall correctly make a call with CLIR temporarily deactivated.
40.1.5 Mobile origin. call complete (to ISDN phone); CLIR temporarily
activated (#31#DN)
Description
The MS shall correctly make a call with CLIR temporarily activated.
Related GSM core specifications
TS 24.081 subclause 2.2
Reason for test
To ensure that temporary CLIR activation works correctly
Initial configuration
MS in idle mode. CLI is not restricted.
Test procedure
By dialling #31#DN (where DN is the called number) make a call using restriction temporarily
activated, and ensure that the call is completed, and that the distant party indicates the CLI as
restricted. Check that Call Waiting Notification, COLP and SS notification (such as "call is forwarded")
is correctly displayed and does not disturb the call setup. Check that alerting tone is audible at the MS
and that voice connection in both directions is established.
Expected behaviour
The MS completes each call correctly, COLP, Call Waiting and SS notification information is correctly
displayed, alerting indication is audible, and a voice connection in both directions is established.
Test procedure
1. Receive a call from an analogue PSTN phone. If CLIP information is available, ensure it is
correctly displayed. Answer the call and ensure that a connection has been made.
2. Receive a call from an ISDN phone. Ensure that CLIP information is correctly displayed.
Answer the call and ensure that a connection has been made.
3. Receive a call from an PBX extension. Ensure that CLIP information is correctly displayed.
Answer the call and ensure that a connection has been made.
4. Receive a call from an Mobile phone Ensure that CLIP information is correctly displayed.
Answer the call and ensure that a connection has been made.
Expected behaviour
CLIP information is correctly displayed, alerting indication is audible, and a voice connection in both
directions is established when the user answers the call.
Expected behaviour
CLIR status is correctly displayed.
40.4 DTMF
Description
The MS shall correctly send DTMF digits when engaged in a call.
Related GSM core specifications
TS 24.008 subclause 5.5.7
Reason for test
To ensure that the MS can send DTMF digits (e.g. to a voicemail system)
Initial configuration
MS in active state, on a call to a voicemail system or other DTMF receiver.
Test procedure
Check that the voicemail system responds correctly to the digits 0-9, * and #.
Repeat procedure 1, sending DTMF digits stored in the phonebook memory.
Expected behaviour
The voicemail system responds correctly to the digits sent by the MS.
13. Repeat procedure 2 after no more suitable cell available, UE camped on an acceptable cell
(forbidden PLMN). Check that the IMEI is not used as mobile identity (TMSI or IMSI shall be
used).
14. Repeat procedure 3 after no more suitable cell available, UE camped on an acceptable cell
(forbidden PLMN)
15. In this step a deactivated SIM/USIM is used, i.e. the network responds with “IMSI unknown in
HLR” to the location update attempt. After switching on the device a sufficient time is waited to
allow the network to reject location update (display shall indicate that no service available).
Then step 1 is repeated where it is additionally checked that the IMEI is used as mobile identity
(neither TMSI nor IMSI shall be used).
16. In this step a deactivated SIM/USIM is used, i.e. the network responds with “IMSI unknown in
HLR” to the location update attempt. After switching on the device a sufficient time is waited to
allow the network to reject location update (display shall indicate that no service available).
Then step 2 is repeated where it is additionally checked that the IMEI is used as mobile identity
(neither TMSI nor IMSI shall be used).
17. Repeat procedure 3 when the IMSI is unknown in HLR, i.e. a deactivated SIM/USIM is used
18. Repeat procedure 1 when the UE is locked
19. Repeat procedure 2 when the UE is locked
20. Repeat procedure 3 when the UE is locked
21. Repeat procedure 1 when no PIN has been entered.
22. Repeat procedure 2 when no PIN has been entered.
23. Repeat procedure 3 when no PIN has been entered.
24. Repeat procedure 1 when PIN1 is blocked
25. Repeat procedure 2 when PIN1 is blocked
26. Repeat procedure 3 when PIN1 is blocked
27. Repeat procedure 1 when the PUK is blocked
28. Repeat procedure 2 when the PUK is blocked
29. Repeat procedure 3 when the PUK is blocked
Expected behaviour
1. The MS shall complete each call correctly: specific emergency call set-up MMI is correctly
displayed, alerting indication is audible, and a voice connection in both directions is established
with the emergency services.
2. Same behaviour as 1.
3. Normal call set-up shall be initiated, but no emergency call shall occur.
4. Normal call set-up shall be initiated to national emergency services, but no emergency call
shall occur.
5. Same behaviour as 1.
6. Same behaviour as 1.
7. Same behaviour as 1.
8. No reactions from the UE expected. Keypad shall remain blocked.
9. Same behaviour as 1.
10. Same behaviour as 1.
11. No call establishment.
12. Same behaviour as 1 and the IMEI is not used as mobile identity (TMSI or IMSI shall be used).
13. Same behaviour as 1 and the IMEI is not used as mobile identity (TMSI or IMSI shall be used).
Expected behaviour
1. The device shall complete each call correctly: specific emergency call set-up MMI is correctly
displayed, alerting indication is audible, and a voice connection in both directions is established
with the emergency services. The IMEI is used as mobile identity (neither TMSI nor IMSI shall
be used).
2. Same behaviour as 1.
3. Same behaviour as 1.
40.6 WB-AMR
Three types of WB-AMR devices are expected:
• 3G devices supporting WB-AMR in both W-CDMA (3G) and GSM (2G)
• 3G devices supporting WB-AMR in W-CDMA (3G), but not in GSM (2G)
• 2G devices supporting WB-AMR in GSM (2G)
The following tests shall cover all three types of WB-AMR devices.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
B) The test is repeated with five different terminated devices supporting WB-AMR in one RAT in
which the DUT supports WB-AMR.
Expected behaviour
4. -
5. A WB-AMR call is set up successfully.
A) The test is successfully in all RATs in which the DUT supports WB-AMR.
B) The test is successfully with all five different terminated devices.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
B) The test is repeated with five different originating devices supporting WB-AMR.
Expected behaviour
1. -
2. A WB-AMR call is set up successfully.
3. The end-to-end voice quality is good.
4. The call is released successfully.
A) The test is successful in all RATs in which the DUT supports WB-AMR.
B) The test is successful with all five different originating devices.
AMR and transcoding to G.711 or by changing the codec to a non WB-AMR codec. The call can be
released.
The test is repeated in all RATs in which the DUT supports WB-AMR.
Related core specifications
3GPP TS 24.008, 3GPP TS 44.018, 3GPP TS 26.190, 3GPP TS 26.201, 3GPP TS 26.194, 3GPP TS
26.173
Reason for test
To ensure that WB-AMR devices establish voice calls to non WB-AMR supporting device.
Initial configuration
All Radio Access Technologies (2G or 3G) where the DUT is used in this test support WB-AMR.
A second mobile device is required which does not support WB-AMR.
Test procedure
1. The DUT camps in a RAT (2G or 3G) where it supports WB-AMR. The second (non WB-AMR
supporting device) is switched on and camps in any RAT.
2. A mobile originated device is setup from the DUT to the second device.
3. The end-to-end voice call is checked.
4. The call is released.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
Expected behaviour
1. -
2. A WB-AMR call is set up. When the network does not support WB-AMR transcoding the voice
codec is changed to a non WB-AMR call, e.g. with Intracell handover.
3. The end-to-end voice connection is established.
4. The call is released successfully.
A) The test is successfully in all RATs in which the DUT supports WB-AMR.
2. Both devices send a CMR to upgrade the codec rate of the remote device. The device receiving
the CMC is instantly changing the coding rate. This continues until the highest codec mode is
reached.
3. With receiving the CMC from the BTS the 2nd device is immediately using the new codec mode
and sends CMI with the new codec mode to the 1st device.
4. With each repeating of step 3 a lower codec rate is commanded by BTS 1 until the lowest codec
rate is reached.
5. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
6. With receiving the CMC the 1st device immediately uses the new codec mode and sends CMI with
the new codec mode to the 2ndt device.
7. With each repeating of step 7 a lower rate is commanded by the 2nd device until the lowest codec
rate is reached.
8. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
5. The interference signal is removed. Now the Codec Mode Requests from the 1st device are
accepted by the network and the codec rate of the 2nd device is increased to the highest mode as
in step 2.
Downgrading in Downlink
6. The downlink RF quality for 2nd device is decreased by interfering a signal until the 2nd device
sends CMR with a lower codec rate to the 1st device. This CMR is transferred to the network of
the 1st device which sends a CMC with the lower codec rate to the device.
7. Step #6 is repeated until the 2nd device sends a CMR with the lowest codec rate
(CODEC_MODE_1) to the 1st device.
8. The interference signal is removed. Now the 2nd device detects the increased quality and sends
a CMR to the 1st device to increase downlink codec mode. This continues until the highest mode
is reached as in step 2.
Expected behaviour
1. A WB-AMR call with an Initial Codec Mode (ICM) of 6.6 kbps in uplink and downlink is
established. The Active Codec Set contains more than one codec mode.
2. Both devices send a CMR to upgrade the codec rate of the remote device. The device receiving
the CMC is instantly changing the coding rate. This continues until the highest codec mode is
reached.
3. With receiving the CMC from the RNC the 2nd device is immediately using the new codec mode
and sends CMI with the new codec mode to the 1st device.
4. With each repeating of step 3 a lower codec rate is commanded by the network 1 until the lowest
codec rate is reached.
5. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
6. With receiving the CMC the 1st device immediately uses the new codec mode and sends CMI
with the new codec mode to the 2nd device.
7. With each repeating of step 7 a lower rate is commanded by the 2nd device until the lowest codec
rate is reached.
8. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
40.6.3.3.1 WB-AMR codec mode is changed (2G to 3G, ordered from 2G)
Description
Two identical WB-AMR DUTs are required for this test. The devices support WB-AMR in both 2G and
3G. The 1st device camps in a 3G cell, the 2nd device in a 2G cell. A WB-AMR call is performed
between both devices. The RF quality of the 2nd device is changed to stimulate a codec mode
downgrade in uplink and downlink. The WB-AMR call is continued with the changed codec mode.
Related core specifications
3GPP TS 24.008, 3GPP TS 45.009, 3GPP TS 44.018, TS 23.153, 3GPP TS 26.103, 3GPP TS
26.190, 3GPP TS 26.201, 3GPP TS 26.194, 3GPP TS 26.173
Reason for test
To ensure that the WB-AMR codec mode in the DUT in 3G is changed when the remote network (2G)
requests this.
Initial configuration
Two identical DUTs supporting WB-AMR are required for this test. A well known test environment or
test bed is required for the 2nd device. Uplink and downlink RF quality is always good for both devices.
The RF quality for the 2nd device (in 2G) can be decreased by interfering a signal in uplink or
downlink.
All Radio Access Technologies (2G or 3G) used in this test support WB-AMR.
Test procedure
1. The 1st device camps in a 3G cell, the 2nd device in a 2G cell. A WB-AMR call is established
between both devices. During call setup for both devices an identical set of codec modes (ACS,
Active Codec Set) with 1 to 4 AMR codec modes is defined by the BTSs. Further a list of
switching thresholds and hysteresis is defined.
2. Now both, the 1st and 2nd DUT detect a good uplink or downlink quality. They send a Codec Mode
Request (CMR) with a better codec mode to their network. This CMR is transferred to the remote
network which sends a Codec Mode Command (CMC) to the remote device. This device uses
immediately the new codec mode and responses with CMI which is sent back to the device
requesting the new data rate. This continues until the highest CODEC_MODE is used by both
devices.
Downgrading in Uplink
3. The uplink RF quality for the 2nd device is decreased by interfering a signal until the BTS of the
2ndevice detects a bad uplink quality and sends CMC with a lower codec rate to the 2nd device.
4. Step 3 is repeated until the BTS sends a CMC with the lowest codec rate (CODEC_MODE_1) to
the 2nd device.
5. The interference signal is removed. Now the Codec Mode Requests from the 1st device are
accepted by network and the codec rate of the 2nd device is increased to the highest mode as in
step 2.
Downgrading in Downlink
6. The downlink RF quality for 2nd device is decreased by interfering a signal until the 2nd device
sends CMR with a lower codec rate to the 1st device. This CMR is transferred to the network of
the 1st device which sends a CMC with the lower codec rate to the device.
7. Step #6 is repeated until the 2nd device sends a CMR with the lowest codec rate
(CODEC_MODE_1) to the 1st device.
8. The interference signal is removed. Now the 2nd device detects the increased quality and sends a
CMR to the 1st device to increase downlink codec mode. This continues until the highest mode is
reached as in step 2.
Expected behaviour
1. A WB-AMR call with an Initial Codec Mode (ICM) of 6.6 kbps in uplink and downlink is
established. The Active Codec Set contains more than one codec mode.
2. Both devices send a CMR to upgrade the codec rate of the remote device. The device receiving
the CMC is instantly changing the coding rate. This continues until the highest codec mode is
reached.
3. With receiving the CMC from the BTS the 2nd device is immediately using the new codec mode
and sends CMI with the new codec mode to the 1st device.
4. With each repeating of step 3 a lower codec rate is commanded by BTS 1 until the lowest codec
rate is reached.
5. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
6. With receiving the CMC the 1st device immediately uses the new codec mode and sends CMI
with the new codec mode to the 2nd device.
7. With each repeating of step 7 a lower rate is commanded by the 2nd device until the lowest codec
rate is reached.
8. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
40.6.3.3.2 WB-AMR codec mode is changed (2G to 3G, ordered from 3G)
Description
Two identical WB-AMR DUTs are required for this test. The devices support WB-AMR in both 2G and
3G. The 1st device camps in a 2G cell, the 2nd device in a 3G cell. A WB-AMR call is performed
between both devices. The RF quality of the 2nd device is changed to stimulate a codec mode
downgrade in uplink and downlink. The WB-AMR call is continued with the changed codec mode.
Related core specifications
3GPP TS 24.008, 3GPP TS 45.009, 3GPP TS 44.018, TS 23.153, 3GPP TS 26.103, 3GPP TS
26.190, 3GPP TS 26.201, 3GPP TS 26.194, 3GPP TS 26.173
Reason for test
To ensure that the WB-AMR codec mode in the DUT in 3G is changed when the remote network (3G)
requests this.
Initial configuration
Two identical DUTs supporting WB-AMR are required for this test. A well known test environment or
test bed is required for the 2nd device. Uplink and downlink RF quality is always good for both devices.
The RF quality for the 2nd device (in 3G) can be decreased by interfering a signal in uplink or
downlink.
All Radio Access Technologies (2G or 3G) used in this test support WB-AMR.
Test procedure
1. The 1st device camps in a 2G cell, the 2nd device in a 3G cell. A WB-AMR call is established
between both devices. During call setup for both devices an identical set of codec modes (ACS,
Active Codec Set) with 1 to 4 AMR codec modes is defined by the BTSs. Further a list of
switching thresholds and hysteresis is defined.
2. Now both, the 1st and 2nd DUT detect a good uplink or downlink quality. They send a Codec Mode
Request (CMR) with a better codec mode to their network. This CMR is transferred to the remote
network which sends a Codec Mode Command (CMC) to the remote device. This device uses
immediately the new codec mode and responses with CMI which is sent back to the device
requesting the new data rate. This continues until the highest CODEC_MODE is used by both
devices.
Downgrading in Uplink
3. The uplink RF quality for 2nd device is decreased by interfering a signal until the network of the
2ndevice detects a bad uplink quality and sends CMC with a lower codec rate to the 2nd device.
4. Step 3 is repeated until the network sends a CMC with the lowest codec rate (CODEC_MODE_1)
to the 2nd device.
5. The interference signal is removed. Now the Codec Mode Requests from the 1st device are
accepted by network 2 and the codec rate of the 2nd device is increased to the highest mode as in
step 2.
Downgrading in Downlink
6. The downlink RF quality for 2nd device is decreased by interfering a signal until the 2nd device
sends CMR with a lower codec rate to the 1st device. This CMR is transferred to the BTS of the
1st device which sends a CMC with the lower codec rate to the device.
7. Step #6 is repeated until the 2nd device sends a CMR with the lowest codec rate
(CODEC_MODE_1) to the 1st device.
8. The interference signal is removed. Now the 2nd device detects the increased quality and sends a
CMR to the 1st device to increase downlink codec mode. This continues until the highest mode is
reached as in step 2.
Expected behaviour
1. A WB-AMR call with an Initial Codec Mode (ICM) of 6.6 kbps in uplink and downlink is
established. The Active Codec Set contains more than one codec mode.
2. Both devices send a CMR to upgrade the codec rate of the remote device. The device receiving
the CMC is instantly changing the coding rate. This continues until the highest codec mode is
reached.
3. With receiving the CMC from the network the 2nd device is immediately using the new codec
mode and sends CMI with the new codec mode to the 1st device.
4. With each repeating of step 3 a lower codec rate is commanded by network 1 until the lowest
codec rate is reached.
5. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
6. With receiving the CMC the 1st device immediately uses the new codec mode and sends CMI
with the new codec mode to the 2ndt device.
7. With each repeating of step 7 a lower rate is commanded by the 2nd device until the lowest codec
rate is reached.
8. When receiving Codec Mode Commands the 1st device increases the coding rate until the highest
codec mode is reached.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
Expected behaviour
1. -
A) The test is successfully in all RATs in which the DUT supports WB-AMR.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
Expected behaviour
1. -
2. A transcoder free WB-AMR call is set up successfully. For 2G the PS connection will be ceased if
DTM is not supported in both, the network and the DUT. Otherwise the data transfer is ongoing.
3. The end-to-end voice quality is good.
4. The call is released successfully. For 2G the PS connection will be resumed if DTM is not
supported in both, the network and the DUT. Otherwise the data transfer is still ongoing or did
never stop.
A) The test is successfully in all RATs in which the DUT supports WB-AMR.
A) The test is repeated in all RATs in which the DUT supports WB-AMR.
Expected behaviour
1. –
2. A transcoder free WB-AMR call is set up successfully. For 2G the PS connection will be ceased if
DTM is not supported in both, the network and the DUT. Otherwise the data transfer is ongoing.
3. The end-to-end voice quality is good.
4. The call is released successfully. For 2G the PS connection will be resumed if DTM is not
supported in both, the network and the DUT. Otherwise the data transfer is still ongoing or did
never stop.
A) The test is successfully in all RATs in which the DUT supports WB-AMR.
While communicating, keyboard of the mobile originated WB-AMR call are pressed to generate
sending of DTMF. After that, keyboard of the mobile terminated WB-AMR call are pressed to generate
sending of DTMF.
Related core specifications
3GPP TS 23.014, 3GPP TS 24.008, 3GPP TS 44.018, 3GPP TS 26.190, 3GPP TS 26.201, 3GPP
TS 26.194, 3GPP TS 26.173
Reason for test
To ensure that WB-AMR devices perform correctly while using DTMF
Initial configuration
All Radio Access Technologies (2G or 3G) used in this test support WB-AMR.
Test procedure
1. The DUT camps in a RAT (2G or 3G) where it supports WB-AMR. The terminated WB-AMR
device is switched on and camps in any RAT where it supports WB-AMR.
2. A WB-AMR call is established between both devices.
3. Each DTMF is sent one time from each devices
4. The end-to-end voice call is checked after each DTMF sending
5. The call is released.
Expected behaviour
1. -
2. -
3. A WB-AMR call is perform successfully while sending or receiving DTMF
4. When sending DTMF, the side tone is heard on the sending and on the receiving devices
5. The call is released successfully.
Expected behaviour
The proper SC address is stored. The message is sent and is correctly received at its destination.
41.1.3 SM Type
Description
Enter the SM Type
Related GSM core specifications
GSM 03.40, GSM 04.11, GSM 11.11
Reason for test
To ensure that the MS allows the SM Type to be changed by the user, and that messages of the
correct type are sent.
Initial configuration
Idle mode
Test procedure
Using the MMI procedures defined by the manufacturer, select an SM Type. Send a message of that
type. Ensure that the message is received, displayed and stored/deleted correctly by the addressed
MS/TE supporting the SM type on the same way.
Repeat this procedure for each of the SM types supported by both the network and the MS.
Expected behaviour
For each of the SM types supported by both the network and the MS, the message is received
correctly at its destination.
41.1.7.1 Input SM (160 characters) when using MMI language of Default 7-bit
alphabet
Description
Ensure that an SMS message of 160 characters can be stored and sent.
Related GSM core specifications
GSM 03.40, GSM 04.11
Reason for test
To ensure that the MS correctly stores and sends an SMS message of 160 characters.
Initial configuration
Idle mode.
Test procedure
Using the MMI procedures defined by the manufacturer, create and send an SMS message of 160
characters. Check that it is correctly received at its destination.
Expected behaviour
The message is correctly received at its destination.
41.1.8.4 UCS-2 alphabet & default & extended default 7-bit alphabet (over 140
Bytes)
Description
Where the MS supports SMS concatenation and the possibility to mix UCS-2 & default and extended
default 7-bit alphabets, ensure that an SMS message longer than 140 Bytes and max. capacity can be
stored and sent.
Ensure that the MS displays the number of short messages which are sent. Ensure that the MS
actually sends the indicated number of SMS.
Related GSM core specifications
GSM 03.40, GSM 03.38, GSM 04.11
Reason for test
To ensure that the MS correctly stores and sends an SMS message longer than 140 Bytes.
To ensure that the customer is aware how many messages are sent.
Initial configuration
Idle mode.
Test procedure
Using the MMI procedures defined by the manufacturer, create and send concatenated SMS
messages supporting the text (longer than 140 Bytes and max. capacity). Check the display if the
number of sent messages is indicated and correct. Check that the SMS are correctly received at their
destination, and that the entire text (longer than 140 Bytes and max. capacity) can be read without
missing characters or redundancy.
Expected behaviour
The MS correctly indicates how many messages are sent. The messages are correctly received at its
destination and the entire text can be read without missing characters or redundancy.
Expected behaviour
If the mobile supports EMS the message is received and the contents are correctly displayed.
If the mobile does not support EMS the text part of the message shall be displayed.
Test procedure
Arrange for an SMS message (class 2) to be sent to the MS. If the mobile supports EMS all the
supported EMS content type shall be included in the SM. Check that the message is received and the
contents are correctly displayed.
Repeat this test for the following conditions, if the features are supported
1. When the MS is in the active state of a circuit-switched data call
2. When the MS is in the active state of a fax call.
3. When the MS is sending and receiving data using GPRS (active data transfer).
Expected behaviour
In each case, the message is received and the contents are correctly displayed.
41.2.5 Acoustic signal, after new short message (no Class) arrived
Description
Where the MS can be configured to give an acoustic alert when an SM is received, ensure that the
alert does in fact occur.
Related GSM core specifications
GSM 03.40, GSM 04.11
Reason for test
To ensure if the MS can be configured to give an acoustic alert when an SM is received, the alert does
in fact occur.
Initial configuration
Idle mode.
Available storage for at least one SM in the SIM card
Test procedure
Arrange for an SMS message to be sent to the MS. Check that the message is received and the alert
is audible.
Repeat this test for the following conditions, if the features are supported
1. When the MS is in the active state of a circuit-switched data call.
2. When the MS is sending and receiving data using GPRS.
Expected behaviour
In each case, the message is received and the alert is audible.
Test procedure
Arrange for an SMS message to be sent to the MS. By means of the MMI commands in the MS, call
the originating number. Check that the correct number has been dialled.
Expected behaviour
The SMS is received, and the correct number is dialled.
1. Entire text can be read without missing characters or redundancy. All message content are
correctly displayed. Check especially the reassembly points.
2. All content is displayed in one message.
Expected behaviour
The entire text can be read without missing characters or redundancy. All message content are
correctly displayed. And all content is displayed in 1 message.
Expected behaviour
The text (up to MS capacity) can be read without missing characters or redundancy in one message.
And the remaining text can be read without missing characters or redundancy in another SM.
Test procedure
Arrange for an SM with Reply Path parameter set to be sent to the MS. By means of the MMI
commands in the MS, create a reply to it and send the reply. Check that the reply is correctly received
at its destination.
Expected behaviour
The reply is correctly received at its destination.
41.7.2 Store MT-SM (read) on SIM and verify content of the SM data fields
on the SIM
Description
Ensure that a Class 2 MT-SM that has been read is correctly stored on the SIM.
Related GSM core specifications
GSM 03.40, GSM 11.11
Reason for test
To ensure that a Class 2 MT-SM that has been read is correctly stored on the SIM.
Initial configuration
Idle mode.
Test procedure
Arrange to receive a Class 2 MT-SM. Using MMI commands, display the SM and check that it has
been received correctly. Remove the SIM from the MS and check the contents using a SIM reader to
ensure that the message is stored in the correct data field in the SIM, with a correct indication of the
contents and status of the SM.
Expected behaviour
The MT SM is stored in the correct data field in the SIM, with a correct indication of the contents and
status of the SM.
41.7.3 Store MT-SM (unread) on SIM and verify cont. of the SM data fields
on the SIM
Description
Ensure that a Class 2 MT-SM that has not been read is correctly stored on the SIM.
Related GSM core specifications
GSM 03.40, GSM 11.11
41.7.4 Delete SM on the SIM and verify the contents of the SM data fields on
the SIM
Description
Ensure that a Class 2 MT-SM that has been read and deleted is correctly removed from the SIM.
Related GSM core specifications
GSM 03.40, GSM 11.11
Reason for test
To ensure that a Class 2 MT-SM that has been read and deleted is correctly removed from the SIM.
Initial configuration
Idle mode.
Test procedure
Arrange to receive a Class 2 MT-SM. Using MMI commands, display the SM and check that it has
been received correctly, and then delete the SM. Remove the SIM from the MS and check the
contents using a SIM reader to ensure that the message has been deleted and no longer remains on
the SIM.
Expected behaviour
The message is deleted and no longer remains on the SIM.
Initial configuration
Idle mode.
Test procedure
Using MMI commands, create a message containing all the characters of the default 7-bit alphabet,
and store the message. Retrieve the message and ensure that the characters are correctly displayed.
Expected behaviour
The characters are correctly displayed in the retrieved message.
Test procedure
Write a SMS with at least one UCS-2 character. The character counter should increment/decrement
correctly. Check that the maximum of 70 UCS-2 characters can be written in one SMS.
Expected behaviour
The counter will increment/decrement correctly when using UCS-2 characters and the maximum of 70
UCS-2 characters can be written in one SMS.
41.9.2 Store SM on the SIM; when SIM memory full (all messages unread)
Description
Attempt to store a message on the SIM when the SIM memory is full of unread MT-SMs.
Related GSM core specifications
GSM 03.40, GSM 11.11
Reason for test
To ensure that the user is notified when there is an attempt to store a message on the SIM when the
SIM memory is full of unread MT-SMs, and that the existing messages are not overwritten except on
specific command from the user.
Initial configuration
Idle mode, no space available on the SIM, SIM full of unread MT-SMs.
Test procedure
Create a new MO-SM and attempt to store it on the SIM. Check that the MS responds with a SIM
memory full indication and does not overwrite an existing message in the SIM.
Expected behaviour
The MS responds with a SIM memory full indication and does not overwrite an existing message in the
SIM.
41.9.6 Store SM in the ME; when ME memory full (all messages unread)
Description
Attempt to store a message on the ME when the ME memory and the SIM memory are full of unread
MT-SMs.
Related GSM core specifications
GSM 03.40, GSM 11.11
Reason for test
To ensure that the user is notified when there is an attempt to store a message on the ME when the
ME memory is full of unread MT-SMs, and that the existing messages are not overwritten except on
specific command from the user.
Initial configuration
Idle mode, no space available on the ME memory neither on the SIM memory.
Test procedure
Create a new MO-SM and attempt to store it on the ME. Check that the MS responds with a memory
full indication and does not store the message and does not overwrite an existing message in the SIM
or in the ME.
Expected behaviour
The MS responds with a memory full indication, does not store the message and does not overwrite
an existing message in the SIM or in the ME.
Test procedure
Create a new MO-SM and store it on the ME. Then delete it. Turn off the MS and turn it on again.
Check that the SM is no longer stored.
Expected behaviour
The SM is no longer stored after it is deleted.
41.11.2 MMI language is 7 bit default (Aligned to the left) & Terminated /
Originated SM is in right aligned UCS2 language
Description
Ensure that UCS2 SM is aligned correctly (e.g. Hebrew is aligned to the right) even when MMI
language is 7 bit default alphabetic is aligned to the opposite direction (e.g. English is aligned to the
left).
42 Supplementary services
42.1.1 Registration
42.1.2 Erasure
42.1.3 Activation
42.1.4 Deactivation
42.1.5 Interrogation
42.2.2 Deactivation
Initial configuration
MS in idle mode, call barring activated.
Test procedure
1. Dial the code string for BAOC #33*PW# (where PW is the current password) and check that
the mobile displays a response indicating that the service has been deactivated. Check also
that the service has been deactivated by attempting to make an outgoing call to a previously
barred number.
2. Repeat procedure 1, but using menu commands instead.
3. Repeat procedure 1, but using the code string for BOIC #331*PW#
4. Repeat procedure 3, but using menu commands instead.
5. Repeat procedure 1, but using the code string for BOIC-exHC #332*PW#
6. Repeat procedure 5, but using menu commands instead.
7. Repeat procedure 1, but using the code string for BAIC #35*PW#. Check that the service has
been deactivated by attempting to make an incoming call from a previously barred number.
8. Repeat procedure 7, but using menu commands instead.
9. Repeat procedure 1, but using the code string for BAIC-R #351*PW#
10. Repeat procedure 9, but using menu commands instead.
Expected behaviour
The MS displays a response indicating that the service has been deactivated, and permits a call
attempt to a previously barred number.
42.2.3 Interrogation
Description
Interrogation of call barring services without reference to a specific basic service
Related GSM core specifications
TS 24.088 subclause 1.5
Reason for test
Ensure that call barring status can be properly interrogated
Initial configuration
MS in idle mode, call barring activated.
Test procedure
1. Dial the code string for BAOC *#33# (where PW is the current password) and check that the
mobile displays a response correctly indicating the service state.
2. Repeat procedure 1, but using menu commands instead.
3. Repeat procedures 1 & 2, but with BAOC activated
4. Repeat procedure 1, but using the code string for BOIC *#331#
5. Repeat procedure 4, but using menu commands instead.
6. Repeat procedures 4 & 5, but with BOIC activated
7. Repeat procedure 1, but using the code string for BOIC-exHC *#332#
8. Repeat procedure 7, but using menu commands instead.
9. Repeat procedures 7 & 8, but with BOIC-exHC activated
10. Repeat procedure 1, but using the code string for BAIC *#35#
11. Repeat procedure 10, but using menu commands instead.
12. Repeat procedures 10 & 11, but with BAIC activated
13. Repeat procedure 1, but using the code string for BAIC-R *#351#
14. Repeat procedure 13, but using menu commands instead.
15. Repeat procedures 13 & 14, but with BAIC-R activated
Expected behaviour
The MS displays a response indicating the correct status of the call barring service.
Expected behaviour
The MS displays a response indicating that the new password has not been verified.
2. Arrange for an incoming call to be received. Ensure that call waiting indication (appropriate
tone and display) occurs. Place the existing call on hold and ensure that the waiting call can
be accepted.
3. Arrange for an incoming call to be received. Ensure that call waiting indication (appropriate
tone and display) occurs. Have the distant party clear the existing call and ensure that the
waiting call can be accepted.
Expected behaviour
The MS provides an appropriate tone and display, and allows the waiting call to be accepted.
Initial configuration
MS in idle mode, Call Waiting activated.
Test procedure
1. Dial the code string #43*BS# (where BS is the code for a supported basic service) and check
that the mobile displays a response indicating that the supplementary service has been
deactivated. Repeat for up to three basic services supported by the MS.
2. Repeat procedure 1, but using menu commands instead.
Expected behaviour
The MS displays a response indicating that the service has been deactivated.
Initial configuration
MS in idle mode, Call Waiting activated.
Test procedure
1. Dial the code string *#43*BS# (where BS is the code for a supported basic service) and check
that the mobile displays a response indicating the status of the supplementary service. Repeat
for up to three basic services supported by the MS.
2. Repeat procedure 1, but using menu commands instead.
3. Deactivate Call Waiting, and then repeat procedure 1.
4. Repeat procedure 3, but using menu commands instead.
Expected behaviour
The MS displays a response indicating the correct state of the service.
5. After completing procedure 4, place the new call on hold, and retrieve the multiparty call (2
SEND). Check that conversation is possible between all parties of the multiparty call.
6. After completing procedure 5, dial the code 3 SEND to join the calls. Check that all five parties
can speak to each other.
7. After completing procedure 6, place the multiparty call on hold, and make a new outgoing call
(DN SEND).
8. After completing procedure 7, dial the code 3 SEND to join the calls. Check that all six parties
can speak to each other
9. After completing procedure 8, arrange for a new incoming call to be made, place the
multiparty on hold, and accept the new incoming call (2 SEND).
10. After completing procedure 9, dial the code 3 SEND to join the calls. Check that the attempt
fails, and that the mobile indicates that the maximum number of participants has been
exceeded. End the last incoming call.
11. After completing procedure 10, create a private communication with one of the distant parties
(Code 2X SEND), placing the remainder of the parties on hold. Check that conversation is
possible with the chosen party, and that the correct party has been selected.
12. After completing procedure 11, make the distant party release the call during private
conversation. Check that the call can be switched back to the multi party call (2 SEND).
13. After completing procedure 12, select another party for a private conversation (2X SEND) and
make this party release the call during the attempt to switch to the private conversation. Check
that the call can be switched back to the multi party call (2 SEND).
14. After completing procedure 13, have one of the distant parties clear the call. Ensure that the
multiparty call is not disturbed for the remaining participants.
Expected behaviour
The MS behaves as described in the test procedure.
42.5.1.1 MO call
Description
Procedure for Advice of Charge (Charging) on an MO call
Related GSM core specifications
TS 24.086 subclause 2.1.2
Reason for test
Ensure that AoCC information is correctly updated during an MO call.
Initial configuration
MS in idle mode, AoCC configured
Test procedure
1. Make a chargeable MO call. Check that the AoCC information is displayed both during and
after the call, correctly indicating the expenditure of credit. Check that the SIM has been
correctly updated by using a SIM card reader to check the value of EFACM
2. Make a free MO call. Check that the AoCC information is displayed both during and after the
call, correctly indicating no expenditure of credit.
3. Repeat procedures 1 and 2 for Fax and data calls if supported by the MS
Expected behaviour
The AoCC information is displayed both during and after the call, correctly indicating any expenditure
of credit. The SIM is correctly updated.
42.5.1.2 MT call
Description
Procedure for Advice of Charge (Charging) on an MT call
Related GSM core specifications
TS 24.086 subclause 2.1.3
Reason for test
Ensure that AoCC information is correctly updated during an MT call.
Initial configuration
MS in idle mode, AoCC configured
Test procedure
1. Arrange to receive a chargeable MT call (e.g. when roaming in another country or network).
Check that the AoCC information is displayed both during and after the call, correctly
indicating the expenditure of credit. Check that the SIM has been correctly updated by using a
SIM card reader to check the value of EFACM
2. Arrange to receive a free MT call. Check that the AoCC information is displayed both during
and after the call, correctly indicating no expenditure of credit.
3. Repeat procedures 1 and 2 for Fax and data calls if supported by the MS
Expected behaviour
The AoCC information is displayed both during and after the call, correctly indicating any expenditure
of credit. The SIM is correctly updated.
42.5.2.1 MO call
Description
Procedure for Advice of Charge (Information) on an MO call
Related GSM core specifications
TS 24.086 subclause 1.1.2
Reason for test
Ensure that AoCI information is correctly updated during an MO call.
Initial configuration
MS in idle mode, AoCI configured
Test procedure
1. Make a chargeable MO call. Check that the AoCI information is displayed both during and
after the call, correctly indicating the expenditure of credit
2. Make a free MO call. Check that the AoCI information is displayed both during and after the
call, correctly indicating no expenditure of credit.
3. Repeat procedures 1 and 2 for Fax and data calls if supported by the MS
Expected behaviour
The AoCI information is displayed both during and after the call, correctly indicating any expenditure of
credit.
42.5.2.2 MT call
Description
Procedure for Advice of Charge (Information) on an MT call
Related GSM core specifications
TS 24.086 subclause 1.1.3
Reason for test
Ensure that AoCI information is correctly updated during an MT call.
Initial configuration
MS in idle mode, AoCI configured
Test procedure
1. Arrange to receive a chargeable MT call (e.g. when roaming in another country or network).
Check that the AoCI information is displayed both during and after the call, correctly indicating
the expenditure of credit
2. Arrange to receive a free MT call. Check that the AoCI information is displayed both during
and after the call, correctly indicating no expenditure of credit.
3. Repeat procedures 1 and 2 for Fax and data calls if supported by the MS
Expected behaviour
The AoCI information is displayed both during and after the call, correctly indicating any expenditure of
credit.
Expected behaviour
The AoCI information is displayed both during and after the call, correctly indicating the charges for all
the calls in progress. The SIM is correctly updated.
42.6 USSD
42.6.1 Idle mode Network initiated USSD Notify
NOTE: Network initiated USSD may be used in support of network features where the
response by the MS results in a dialogue outside the scope of the USSD
standards. Since these features may vary from network to network, no specific
network feature is mentioned in this test.
Description
Ensure that network-initiated USSD operations are carried out correctly.
Related GSM core specifications
GSM 04.90 and GSM 03.38
Reason for test
To ensure that Network initiated USSD Notify is carried out correctly by the MS and to verify MS
support for:
• Correct displaying of the USSD Notify content.
• Immediate answering with a Return Result message.
• USSD notify up to 182 characters
• The phase 2 character set
• That USSD is not interrupted by interaction with the MMI Clock display, SMS-CB, or other USSD
functions
• That MS should not implement any timer
Initial configuration
MS in idle mode
Test procedure
1. Send a USSD Notify to the MS. After receiving the Return Result message from the MS, send
a Release Complete message.
2. Send a USSD Notify containing 182 characters (including 7-bit default alphabet).
3. Repeat step 1), sending another USSD Notify or Request after receiving the Return Result
message.
4. Repeat step 1) sending the Release Complete message about 60 sec after receiving the
Return Result message.
The test shall be repeated as many times as necessary to cover the different services and options
within the MS that is supported by means of USSD.
Expected behaviour
In step 1, the MS shall display the USSD Notify message and shall send immediately the Return
Result message in response to it. The MS shall keep the signalling channel open until receiving the
Release Complete message.
In step 2, the same as step 1. The MS shall display the complete message including the complete 7-
bit default alphabet.
In step 3, the same as step 1, but displaying the next USSD message after clearing the first one.
In step 4, the same as step 1.
In step 7, the same as step 1, but sending Release Complete message instead of the Return Result
message.
In step 3, the same as step 1. The MS shall send the complete message including the complete 7-bit
default alphabet.
In step 4, The MS shall avoid confusing 7 binary zero pad bits as the @ character, the CR character
shall be used for padding in this situation.
In step 5, the same as step 1, but displaying the next USSD message after answering the first one.
In step 6, the same as step 1 The MS shall keep the signalling channel open until receiving the
Release Complete message.
In step 7, the same as step 1, but sending Release Complete message instead of the Return Result
message.
NOTE: Standardised MMI command strings for various USSD operations are listed in
GSM 11.10-1 subclause 31.10 and may be used where appropriate. Expected
behaviour
Expected behaviour
In step 1 the network feature is invoked as expected. The precise behaviour depends on the specific
feature that USSD is being used to support.
In step 2, the MS shall send all of the 25 digits entered
In step 3; the MS shall display the complete message until cleared by user including the complete 7-bit
default alphabet.
In step 4, the MS shall allow the international + symbol to be inserted into a USSD string and shall
send the complete string in the correct sequence.
In step 5, The MS shall avoid confusing 7 binary zero pad bits as the @ character, the CR character
shall be used for padding in this situation.
In step 6, the MS shall wait until the network sends back the response, so the MS shall avoid sending
a Release complete message to the network.
Test procedure
1. Perform an originated call from the device under test (DUT) to the second (still busy) device.
Now the network notifies the user, e.g. by inband voice notification, that CCBS is possible.
2. Enter 5<send> and check that the network notifies the user, e.g. by MT USSD, that CCBS is
successfully activated. Release the call on the device under test.
3. Interrogate the status of CCBS by entering *#37#<send> in idle mode. Check that the
networks response is displayed correctly.
4. Release the second device. Now call completion is activated. Check the incoming call on the
DUT and accept the call. Check that the second device is alerting, accept the call on the
second device. Release the call.
5. Repeat step 1) - 5) using the USSD string *37#<send> in step 3 instead of 5<send>.
Expected behaviour
1. The information from the network that the called party is busy is presented as expected, e.g.
as inband voice notification.
2. The USSD sequence 5<send> is sent successfully to the network and the network informs the
user, e.g. by MT USSD, that CCBS is activated successfully. The connection to the network
can be released successfully.
3. The USSD sequence *#37# is sent successfully while in idle mode. The response from the
network, as MT USSD, is as expected.
4. The incoming CCBS call could be accepted successfully. Afterwards the second device is
ringing and the end to end voice connection is successful after accepting the call on the
second device.
5. Same as steps 2 – 5 except that the USSD string *37#<send> in step 4 is 5<send>.
2. Repeat the test using the international MSISDN address format (for example: +49 172
123456...).
3. Repeat the test using the short MSISDN address format (for example: 1234…).
Expected behaviour
The message is sent and correctly received by the B-subscriber.
43.1.1.3 Send message with MSISDN recipient using the “To”, the “Cc” or the
“Bcc” field
Description
Verification that the MS correctly sends the message when one of the “To” , the “Cc” or the “Bcc”
address fields is used.
Reason for test
To ensure that the MS correctly sends the message when one of the “To” , the “Cc” or the “Bcc”
address fields is used.
Related GSM core specifications
WAP-209-MMS Encapsulation-20020105-a.
Initial configuration
MS in idle mode.
Test procedure
1. Create a new MMS message, add a MSISDN recipient only to the “To“ address field. Send the
message. The MS displays a message that the MMS has been sent. Verify that the message
is correctly received by the B-subscriber.
2. Repeat the test using only the “Cc” address field.
3. Repeat the test using only the “Bcc” address field.
Expected behaviour
The message is correctly sent and received by the B-subscriber.
43.1.1.4 Send message with email recipient using the “To”, the “Cc” or the
“Bcc” field
Description
Verification that the MS correctly sends the message when the “To”, the “Cc” or the “Bcc” address field
is used to insert the email address format.
Reason for test
To ensure that the MS correctly sends the message when the “To”, the “Cc” or the “Bcc” address field
is used to insert the email address format.
Related GSM core specifications
WAP-209-MMS Encapsulation-20020105-a.
Initial configuration
MS in idle mode.
Test procedure
1. Create a new MMS with a text, picture and sound object, then add an email recipient to the
“To” address field. Then send the MMS. The MS displays a message that the MMS has been
sent. Verify that the email recipient receives the message and that the address fields and the
email body are correctly used.
2. Repeat the test using the “Cc” address field.
3. Repeat the test using the “Bcc” address field.
Expected behaviour
The message is correctly sent and received by the email recipient indicating the appropriate address
fields.
Test procedure
Create a new MMS and insert a text object. Fill the text object with the maximum length of 1000
characters. Send the message. The MS displays a message that the MMS has been sent. Verify that
all characters of the text are sent to the recipient.
Expected behaviour
The message is correctly sent and received by the recipient with the complete text field.
Test procedure
1. Create a new MMS and insert an animated GIF image object. Send the message. The MS
displays a message that the MMS has been sent. Verify that the image can displayed and that
it is animated at the recipient while the MMS is viewed.
2. Repeat the test using different animated GIF image sizes.
Expected behaviour
The message is correctly sent and received by the recipient with the correctly animated GIF image.
Test procedure
Create a new MMS and attach an appointment from the organizer. Send the message. The MS
displays a message that the MMS has been sent. Verify that the appointment can be displayed at the
recipient while the MMS is viewed.
Expected behaviour
The message is correctly sent and received by the recipient with the attached appointment.
Expected behaviour
The message is correctly sent and received by the email recipient with the appropriate embedded
objects.
Test procedure
1. Create a new MMS by replying to one recipient having a MSISDN address. Send the message
to an email client. The MS displays a message that the MMS has been sent. Verify that the
message is received by the correct recipient.
2. Repeat the test replying to one recipient having an email address
3. Repeat the test replying to one recipient in the “Cc” address field
4. Repeat the test replying to one recipient in the “Bcc” address field.
Expected behaviour
The message is correctly sent and received by the appropriate recipient.
43.2.1.2 Receive message from MSISDN sender using the “To”, the “Cc” or
the “Bcc” field
Description
Verification that the MS correctly supports the receiving of a MMS from a MSISDN sender using the
“To”, “Cc” or “Bcc” address field.
Reason for test
To ensure that that the MS correctly supports the receiving of a MMS from a MSISDN sender using
the “To”, “Cc” or “Bcc” address field.
Related GSM core specifications
WAP-209-MMS Encapsulation-20020105-a.
Initial configuration
MS in idle mode.
Test procedure
1. Receive a MMS from a MS where the “To” address field was used as MSISDN address
format. The MS shall indicate the receipt of a new MMS. Open the received message. Verify
that the sender and the message content is correctly displayed.
2. Repeat the test receiving a MMS from a MS where the “Cc” address field was used as
MSISDN address format.
3. Repeat the test receiving a MMS from a MS where the “Bcc” address field was used as
MSISDN address format.
Note: If the sender’s MSISDN is stored in the SIM or MS phonebook, the sender’s name
should be also displayed.
Expected behaviour
The sender and the message content is correctly displayed.
43.2.1.4 Receive message to multiple recipients using the fields “To”, “Cc”
and “Bcc”
Description
Verification that the MS correctly supports the receiving of a MMS with multiple recipients using the
fields “To”, “Cc” and “Bcc”.
Reason for test
To ensure that the MS correctly supports the receiving of a MMS with multiple recipients using the
fields “To”, “Cc” and “Bcc”.
Related GSM core specifications
WAP-209-MMS Encapsulation-20020105-a.
Initial configuration
MS in idle mode.
Test procedure
1. Receive a MMS with multiple recipients in which the test recipient is addressed in the “To”
address field. The MS shall indicate the receipt of a new MMS. Open the received message.
Verify that the sender and the message content is correctly displayed.
2. Repeat the test receiving a MMS with multiple recipients in which the test recipient is
addressed in the “Cc” address field.
3. Repeat the test receiving a MMS with multiple recipients in which the test recipient is
addressed in the “Bcc” address field.
Expected behaviour
The sender and the message content is correctly displayed.
Expected behaviour
The AMR sound object is correctly played and can be saved to the appropriate data folder of the MS.
Test procedure
Receive a MMS containing an appointment. The MS shall indicate the receipt of a new MMS. Open
the received message. Verify that the appointment is displayed when viewing the MMS. Save the
appointment to the organizer of the MS.
Expected behaviour
The appointment can be displayed and saved to the organiser of the MS.
43.2.4.1 Receive MMS when Auto Download is set to “Off“ / Reject MMS
Description
Verification that when Auto Download is set to “Off“ in the MS, it shall be possible to reject the
receiving of the MMS. The MS shall not automatically download the MMS.
Reason for test
To ensure that when Auto Download is set to “Off“ in the MS, it shall be possible to reject the receiving
of the MMS. The MS shall not automatically download the MMS.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Auto Download is set to “off”.
Test procedure
Receive a MMS notification of a MMS. The MS shall indicate the MMS notification to the user. Verify
that the MS is not automatically downloading the MMS. Reject the receiving of the MMS. Verify that
the MS sends a M_Notify_Resp with X-MMS-Status set to “reject” to the network. Verify that the MS
does not send a new notification for this message to the user.
Expected behaviour
The MS is not automatically downloading the MMS. On reject by the user, the MS sends a
M_Notify_Resp with X-MMS-Status set to “reject” to the network. The MS does not send a new
notification for this message to the user.
Expected behaviour
The MS is automatically downloading the MMS. After receipt, the message can be displayed by the
user.
43.2.4.4 Receive MMS when Auto Download is set to “On” and the MS
memory is full
Description
Verification that when Auto Download is set to “On“ in the MS and the MS memory is full, the
download of the MMS is automatically deferred by the MS and an appropriate notification is given to
the user.
Reason for test
To ensure that when Auto Download is set to “On“ in the MS and the MS memory is full, the download
of the MMS is automatically deferred by the MS and an appropriate notification is given to the user.
Related GSM core specifications
None.
Initial configuration
MS in idle mode, Auto Download is set to “On”, MMS memory of the MS is full.
Test procedure
Receive a MMS notification of a MMS. The MS shall indicate that a new MMS is available to the user
but that there is not enough memory in the MS to receive the message. Verify that the MS sends a
“defer” message to the network. Clear the memory of the MS, then download the deferred message
from the server. Open the message and verify that the downloaded message is exactly the one which
was previously deferred.
Expected behaviour
The MS is indicating to the user that its MMS memory is full. The MS sends a “defer” message to the
network. On downloading, the MS receives exactly the MMS which was previously deferred.
43.2.4.5 Receive MMS when Auto Download is set to “On” and the sender is
anonymous
Description
Verification that when Auto Download is set to “On“ in the MS and the sender is anonymous, it is
possible to deny the MMS.
Reason for test
To ensure that when Auto Download is set to “On“ in the MS and the sender is anonymous, it is
possible to deny the MMS.
Related GSM core specifications
None.
Initial configuration
MS in idle mode, Auto Download is set to “On”, Receive option is set to “Deny message when
anonymous sender”.
Test procedure
Receive a MMS notification of a MMS. The MS shall indicate that a new MMS is available to the user
but that the sender is anonymous. Verify that the MS is not automatically downloading the MMS.
Expected behaviour
The MS is not automatically downloading the MMS.
43.3.1.3 Receive a Delivery Report when the MMS was retrieved / Successful
Description
Verification that the MS correctly supports the receipt of the MMS Delivery Report.
Reason for test
To ensure that the MS correctly supports the receipt of the MMS Delivery Report.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Delivery report is set to “On” in the MS.
Test procedure
Create a new MMS. Send the message. The MS displays a message that the MMS has been sent.
Ensure that the recipient has successfully received the MMS. Verify that the Delivery Report is
received by the sender of the MMS. Verify that the MS correctly indicates the status of the sent
message as “delivered”.
Expected behaviour
The MS is displaying the delivery status of the sent message as “delivered”.
Expected behaviour
The MS is displaying the delivery status of the sent message as “rejected”.
43.3.1.6 Receive a Delivery Report when the MMS was sent to multiple
recipients
Description
Verification that the MS correctly supports the receipt of the MMS Delivery Report.
Reason for test
To ensure that the MS correctly supports the receipt of the MMS Delivery Report.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Delivery report is set to “On” in the MS.
Test procedure
Create a new MMS to multiple recipients. Send the message. The MS displays a message that the
MMS has been sent. Ensure that some recipients reject, defer of retrieve the message. Verify that for
each recipient the Delivery Report is received by the sender of the MMS. Verify that the MS correctly
indicates the various states of the sent message.
Expected behaviour
The MS is correctly displaying the various delivery states of the sent message.
recipient has read the message, verify that the Read Reply Report is sent back to the sender of the
MMS. Verify that the MS correctly displays the Read Reply Report.
Expected behaviour
The MS is correctly sending the Read Reply Report request.
43.3.2.5 Receive a Read Reply Report when the recipient MSISDN is directly
forwarded to a different MSISDN
Description
Verification that the MS correctly supports the sending and receipt of the Read Reply Report when the
recipient MSISDN is directly forwarded to a different MSISDN.
Reason for test
To ensure that the MS correctly supports the sending and receipt of the Read Reply Report when the
recipient MSISDN is directly forwarded to a different MSISDN.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Read Reply Report is set to “On” in the sending MS, Recipient MSISDN is directly
forwarded to a different MSISDN.
Test procedure
Send a MMS and set the Read Reply Report to “On”. Forward the recipient MSISDN address to
another MSISDN address. Receive the MMS at the forwarded MSISDN and verify that it is possible to
send the Read Reply Report and that the sender will receive this report.
Expected behaviour
The recipient can send a Read Reply Report and the sending MS is correctly receiving this report.
Test procedure
Receive a message with Message Class “Personal“, Read Reply Request and Delivery Report request
are set to “On”. Verify that the Message Class in the MMS notification is “Personal“. Verify that a Read
Reply Report can be generated for this message, that the message can be replied and that a Delivery
Report can be generated for this message.
Expected behaviour
The MS displays the Message Class “Personal”. The MS is able to generate a Read Reply Report for
this message, the message can be replied and a Delivery Report can be generated for this message.
Expected behaviour
The MS displays the Message Class “Informational”. The MS is not able to generate a Read Reply
Report for this message, the message can not be replied and no Delivery Report can be generated for
this message.
43.5.1.1 Cancel the downloading MMS when Auto Download is set to “On”
Description
Verification that it is possible to cancel the download session for MMS without losing the MMS
notification.
Reason for test
To ensure that it is possible to cancel the download session for MMS without losing the MMS
notification.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Auto Download is set to “On”.
Test procedure
Receive a MMS and verify that the Auto Download is set to “On”. Receive the MMS notification. While
the MMS is downloading, cancel the download session. Verify that the MMS notification is still
available and that it is possible to download the MMS again.
Expected behaviour
The MMS notification is still available and it is possible to download the MMS again.
43.5.1.2 Cancel the downloading MMS when Auto Download is set to “Off”
Description
Verification that it is possible to cancel the download session for MMS without losing the MMS
notification.
Reason for test
To ensure that it is possible to cancel the download session for MMS without losing the MMS
notification.
Related GSM core specifications
3GPP TS 26.234.
Initial configuration
MS in idle mode, Auto Download is set to “Off”.
Test procedure
Receive a MMS and verify that the Auto Download is set to “Off”. Receive the MMS notification. Start
downloading the MMS. While the MMS is downloading, cancel the download session. Verify that the
MMS notification is still available and that it is possible to download the MMS again.
Expected behaviour
The MMS notification is still available and it is possible to download the MMS again.
Expected behaviour
The MS interprets the error message correctly and it displays that the maximum message size is
exceeded.
43.5.2.5 Receiving MMS and select “Call to Sender“ from the menu
Description
Verification that it is possible to select “Call to Sender“ from the menu when receiving a MMS.
Reason for test
To ensure that it is possible to select “Call to Sender“ from the menu when receiving a MMS.
Related GSM core specifications
3GPP TS 23.140.
Initial configuration
MS in idle mode.
Test procedure
Receive a new MMS. Open the message. When the MMS is displayed, select “Call to Sender“. Verify
that the correct number is dialled and connected.
Expected behaviour
The Sender’s number is correctly dialled and connected.
44 Browsing
Test procedure
Attempt a WAP call to an invalid number. Check the behaviour of the MS
Expected behaviour
The MS shall indicate that an invalid number has been dialled.
Initial configuration
MS in idle mode, no data listed in the Password field for WAP access, network configured to require
user name and password authentication
Test procedure
Using MMI commands, attempt to make a WAP connection. Check the behaviour of the MS
Expected behaviour
The MS shall indicate that no connection is possible, indicating the correct reason for the failure, and
shall clear the call.
44.1.3 Security
44.1.4 Browser
Expected behaviour
The correct browser version shall be displayed
44.1.4.2 Menu
Description
Ensure that the menu options all work as designed
Related 3GPP core specifications
None
Reason for test
To ensure that all the menu options work as designed
Initial configuration
MS in a WAP session, a full detailed menu description shall be available
Test procedure
Using the MMI (including soft keys), exercise each of the menu options in turn, check whether the MS
behaves as intended, according to the menu specification
Expected behaviour
MS behaves according to the description of each menu item
Test procedure
Enter a URL for a site that does not exist.
Expected behaviour
The MS shall indicate that the URL is not found
Test procedure
Using MMI commands clear the page cache
Expected behaviour
Past pages shall no longer be retrievable from the page cache.
Note: a possibility to check whether the cache is empty is to measure the connection
time.
44.1.5 WML
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains a bitmap taller than the height of the display.
Expected behaviour
The page shall be correctly displayed, including the bitmap. The bitmap shall be made visible by
means of scrolling and or zoom commands
Expected behaviour
The page shall be correctly displayed. The password characters entered by the user shall not be
displayed, but shall be replaced with masking characters.
Expected behaviour
The MS shall send the correct values for both fields.
Test procedure
Using MMI commands, select a site which contains a table wider then the width of the display
Expected behaviour
The table shall be correctly displayed, and the whole of the table shall be visible by means of
horizontal scrolling commands.
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains text which is right-aligned
Expected behaviour
The text shall be correctly displayed.
44.1.5.26 Emphasis
Description
Ensure that the MS correctly displays text with the Emphasis tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the Emphasis tag
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains text with the Emphasis tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.1.5.27 Strong
Description
Ensure that the MS correctly displays text with the Strong tag
Related 3GPP core specifications
None
44.1.5.28 Big
Description
Ensure that the MS correctly displays text with the ‘Big’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Big’ tag
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Big’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.1.5.29 Bold
Description
Ensure that the MS correctly displays text with the ‘Bold’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Bold’ tag
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Bold’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.1.5.30 Italic
Description
Ensure that the MS correctly displays text with the ‘Italic’ tag
Related 3GPP core specifications
None
44.1.5.31 Small
Description
Ensure that the MS correctly displays text with the ‘Small’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Small’ tag
Initial configuration
WAP session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Small’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.1.5.32 Underline
Description
Ensure that the MS correctly displays text with the Underline tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the Underline tag
Initial configuration
WAP session active.
Test procedure
Using MMI commands, select a site which contains text with the Underline tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.1.6 WTAI
Description
Ensure that the MS correctly calls a number contained in a WTAI field when the field is selected
Related 3GPP core specifications
None
Test procedure
While the WAP offline browsing in progress, arrange for a call to be made to the MS. When the call is
indicated, answer the call.
Expected behaviour
The incoming call shall be indicated. It shall be possible to answer the call and for two-way speech to
take place.
Initial configuration
WAP session active, SIM with a proactive SIM toolkit application
Test procedure
While the WAP session is active, arrange for a proactive command is sent from the SIM to the ME.
Check that an indication is made when the command is received, then enter in the SIM toolkit session
without terminating the WAP session.
Expected behaviour
The SIM toolkit session should occur properly without terminating the WAP session.
Test procedure
Attempt to download a certificate of 700 bytes (1000 bytes if X.509)
Expected behaviour
The MS shall download and process the certificate without error.
44.2.5 HTML
Test procedure
Enter a URL for a site without the http:// prefix.
Expected behaviour
The MS shall correctly retrieve the page as if the http:// prefix were present.
Description
Ensure that the MS can reload the contents of a page
Related 3GPP core specifications
None
Reason for test
To ensure that the MS can reload the contents of a page
Initial configuration
Browsing session active set to a page whose contents are regularly updated
Test procedure
Using MMI commands reload the current page
Expected behaviour
The updated contents of the page shall be displayed
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains special characters in the page content. The coding
of the special characters should be 2 different codings for the special characters to be identified.
Expected behaviour
The page shall be correctly displayed, including the special characters
Test procedure
Using MMI commands, select a site which contains soft hyphen at a point where the word will be split
into two lines. Then select a site which contains a soft hyphen at a point where the word will not be
split into two lines
Expected behaviour
The pages shall be correctly displayed, showing the hyphen at the end of the line for the first page,
and not showing the hyphen for the second page.
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains an input field which contains a default value of
more than 90 characters. Send the default contents of the field.
Then, for a separate field with a default value, change the contents of the field before sending its
contents
Expected behaviour
The MS shall send the correct values for both fields.
44.2.5.35 Emphasis
Description
Ensure that the MS correctly displays text with the Emphasis tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the Emphasis tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the Emphasis tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.36 Strong
Description
Ensure that the MS correctly displays text with the Strong tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the Strong tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the Strong tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.37 Big
Description
Ensure that the MS correctly displays text with the ‘Big’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Big’ tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Big’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.38 Bold
Description
Ensure that the MS correctly displays text with the ‘Bold’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Bold’ tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Bold’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.39 Italic
Description
Ensure that the MS correctly displays text with the ‘Italic’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Italic’ tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Italic’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.40 Small
Description
Ensure that the MS correctly displays text with the ‘Small’ tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the ‘Small’ tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the ‘Small’ tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.41 Underline
Description
Ensure that the MS correctly displays text with the Underline tag
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly displays text with the Underline tag
Initial configuration
Browsing session active
Test procedure
Using MMI commands, select a site which contains text with the Underline tag
Expected behaviour
The text shall be correctly displayed with suitable formatting
44.2.5.42 WTAI
Description
Ensure that the MS correctly calls a number contained in a WTAI field when the field is selected
Related 3GPP core specifications
None
Reason for test
To ensure that the MS correctly calls a number contained in a WTAI field when the field is selected
Initial configuration
Browser session active
Test procedure
1. Using MMI commands, select a site which contains a WTAI field in the form
wtai://wp/mc;<phone number in national syntax (0172...)>. Select the field, and check that a
voice call is made.
2. Using MMI commands, select a site which contains a WTAI field in the form
wtai://wp/mc;<phone number in international syntax (+ not masked)>. Select the field, and
check that a voice call is made.
3. Using MMI commands, select a site which contains a WTAI field in the form
wtai://wp/mc;<phone number in international syntax (+ as %2B)>. Select the field, and check
that a voice call is made.
Expected behaviour
In each case, MS shall ask the user before making the call, shall call the correct number, and shall
return to the browser (same page) on completion of the call.
Expected behaviour
The MS correctly clears all cached paged
Initial configuration
Browsing session active, SIM with a proactive SIM toolkit application
Test procedure
While the browsing session is active, arrange for a proactive command is sent from the SIM to the ME.
Check that an indication is made when the command is received, then enter in the SIM toolkit session
without terminating the browsing session.
Expected behaviour
The SIM toolkit session should occur properly without terminating the browsing session.
3. Check that Call Waiting Notification and SS Notification (e.g. “call is forwarded”) is displayed
correctly and does not disturb the call setup.
4. Check that the receiving UE is receiving the correct CLI information.
5. Answer call with receiving UE. Check that video and voice connection is established in both
directions.
The procedure shall be performed using target MSISDN in
1. same country using MSISDN in national and in international format (with prefix +);
2. foreign country using MSISDN in international format (with prefix +)
3. both by dialling directly and by using entry from phonebook.
Expected behaviour
The UE UT completes call correctly, Call Waiting, SS Notification are indicated correctly. Video and
voice connection is established in both directions.
Test procedure b)
1. Set up a video telephony call from UE UT to another UE.
2. Check that an alerting indication is given in the UE UT while the receiving UE is ringing.
3. Check that Call Waiting Notification and SS Notification (e.g. “call is forwarded”) is displayed
correctly and does not disturb the call setup.
4. Check that the receiving UE is receiving the correct CLI information.
5. Answer call with receiving UE. Check that video and voice connection is established in both
directions.
6. End call under normal conditions by request from distant UE by means of MMI (e.g. pressing
“END”-key).
7. Check that UE UT returns to its initial state.
Expected behaviour
In both cases the UE UT completes call correctly, Call Waiting, SS Notification are indicated correctly.
Video and voice connection is established in both directions. UE UT shall return to its initial state after
the video telephony call is ended.
Expected behaviour
The UE terminates the video telephony call correctly, CLIP information is displayed correctly, incoming
call is indicated and voice and video connection is established correctly. The establishment time of the
audio and video shall be as lower as possible and comparable to competitive devices.
Expected behaviour
The UE UT completes call correctly, Call Waiting, SS Notification are indicated correctly. Video and
voice connection is established in both directions. 1st distant UE drops, and 2nd distant UE connect
correctly to the UE UT.
45.2.2 Video Call waiting during pending Voice Call / Call Hold
Description
The UE UT is engaged in one voice call and receives a Video call.
Related 3GPP core specifications
3GPP TS22.004
Reason for test
To ensure that the new connection is well established when UE UT is set on hold in an active video
telephony call.
Initial configuration
The UE UT is IMSI attached and PS attached in its 3G HPLMN that is supporting Video Telephony,
Call waiting is activated.
The UEs that are used as distant party
50. are attached in the same 3G network as UE UT;
51. have the same HPLMN as UE UT;
52. are in idle mode;
53. are capable of receiving Video Telephony calls.
Test procedure
1. Set up a voice call from UE UT to 1st distant party UE.
2. Check that an alerting indication is given in the UE UT while the 1st distant party UE is ringing.
3. Check that Call Waiting Notification and SS Notification (e.g. “call is forwarded”) is displayed
correctly and does not disturb the call setup.
4. Check that 1st distant party UE is receiving the correct CLI information.
5. Answer call with 1st distant party UE. Check that voice connection is established in both
directions.
6. Set up a video telephony call from a 2nd distant UE to UE UT.
7. Check that the incoming call is indicated in UE UT and that the correct CLI is indicated.
8. Set voice telephony call to 1st distant party on hold by command of UE UT. Check that an
indication is given in 1st distant UE that call is on hold.
9. Check that no audio transmission takes place between UE UT and 1st distant UE.
10. Accept video telephony call from 2nd distant UE. Check that video and voice connection is
established in both directions.
11. End call to 2nd distant UE under normal conditions by request from UE UT by means of MMI
(e.g. pressing “END”-key). Check that 1st distant UE is still on Hold.
12. Resume Voice call to 1st distant UE. Check that Voice connection is established in both
directions.
13. End call under normal conditions by request from UE UT by means of MMI (e.g. pressing
“END”-key).
14. Check that UE UT returns to its initial state.
Expected behaviour
The UE UT completes call correctly, Call Waiting, SS Notification are indicated correctly. Video and
voice connection is established in both directions. 1st distant UE is set on Hold without dropping, and
without loss of audio signal.
Test procedure
1. Activate Call Forward Unconditional (CFU) for video telephony (**21*N°*24#)
2. Set up a video telephony call from UE to another UE UT.
3. Check that the VT call is forwarded to the second UE.
4. Answer call with the second UE. Check that video and voice connection is established in both
directions.
5. Repeat procedure using means of menu.
Expected behaviour
The VT call is well forwarded unconditionally, toward the Number defined.
45.2.6.3 Call Forward if Busy
Description
The UE UT forwards the VT call from a first UE to a second UE if UE UT is busy.
Related 3GPP core specifications
3GPP TS 22.082
Reason for test
To ensure that UE UT VT call forwarding works properly.
Initial configuration
The UE UT is IMSI attached and PS attached in its 3G HPLMN that is supporting Video Telephony.
Test procedure
1. Activate Call Forward if Busy (CFB) for video telephony (**67*N°*24#)
2. Set up a video telephony call from UE to another UE UT.
3. Check that the VT call is forwarded to the second UE.
4. Answer call with the second UE. Check that video and voice connection is established in both
directions.
5. Repeat procedure using means of menu.
Expected behaviour
The VT call is well forwarded if UE UT is busy, toward the Number defined.
45.2.6.4 Call Forward if Non Reachable
Description
The UE UT forwards the VT call from a first UE to a second UE if UE UT is non reachable.
Related 3GPP core specifications
3GPP TS 22.082
Reason for test
To ensure that UE UT VT call forwarding works properly.
Initial configuration
The UE UT is IMSI attached and PS attached in its 3G HPLMN that is supporting Video Telephony.
Test procedure
1. Activate Call Forward if Non Reachable (CFNRc) for video telephony (**62*N°*24#)
2. Set up a video telephony call from UE to another UE UT.
3. Check that the VT call is forwarded to the second UE.
4. Answer call with the second UE. Check that video and voice connection is established in both
directions.
5. Repeat procedure using means of menu.
Expected behaviour
The VT call is well if UE UT is non reachable, toward the Number defined.
Expected behaviour
The UE UT completes call correctly, Call Waiting, SS Notification are indicated correctly. Video and
voice connection is established in both directions. Video and voice connection are not disturbed by
receiving SMS. UE UT returns to its initial state after the video telephony call is ended. SMS is stored
correctly and is not corrupted.
45.3.2 Stability
Initial configuration
The UE UT is IMSI attached and PS attached in its 3G HPLMN that is supporting Video Telephony.
The UE UT is in an area with good radio conditions.
The UE that is used to receive the MT Video Telephony call from UE UT
• is IMSI attached in the same 3G network as UE UT;
• has the same HPLMN as UE UT;
• is in idle mode;
• is capable of receiving Video Telephony calls;
• is in an area with good radio conditions.
Test procedure
The test procedure shall be repeated in areas with different radio conditions. Initially the UE UT is in
an area with good radio conditions. During the call the UE UT is moved into areas with decreasing
network coverage. The call drop rate is documented as a function of radio field strength.
1. Set up a video telephony call from UE UT to another UE.
2. Answer call with receiving UE. Check that video and voice connection is established in both
directions.
3. Maintain connection for several minutes (around 2 minutes).
4. End call under normal conditions by request from UE UT by means of MMI (e.g. pressing
“END”-key).
5. Check that UE UT returns to its initial state.
6. Repeat procedure 5 times and document the dropped calls.
Expected behaviour
The UE UT shall allow a stable connection in areas without optimal radio conditions.
Expected behaviour
The UE UT is able to establish a video telephony connection highly reliable.
Expected behaviour
The receiving system responds correctly to the digits sent by the UE UT.
Expected behaviour
The following JAR file manifest entries shall be supported after the application is installed on UE.
Implementation-Title:
The Implementation-Title shall be used in any textual description of the application, which is displayed
in the UI element used to launch the application. E.g. the text displayed with an icon.
Main-Icon:
The use of icons to launch applications is optional, however if icons are used as elements to launch
the application, then the icon file within the JAR file named by the Main-Icon attribute shall be
displayed, and may be scaled if desired.
Main-Class and Class-Path:
When the application is launched, the Personal Java VM shall be supplied with the class path and
shall call the main () method in the class named by the Main-Class attribute.
referred to as JSR-185. The initiative works to define a roadmap for MIDP/CLDC enabled mobile
phones and to reduce any ambiguity in the specifications included.
The (mandatory) JSRs that are supported for JTWI (JSR 185) are:
• JSR-30 CLDC 1.0
• JSR-120 WMA
• JSR-118 MIDP 2.0
Applications wishing to use one or more restricted APIs on the phone should request permission for
this both in the JAD file and in the corresponding signed JAR file. Permissions can be requested either
as optional or as required.
A MIDlet can be signed with multiple certificates simultaneously as a fallback to ensure that the MIDlet
can be installed, even though the first choice of root certificate would not exist in the device, (U)SIM or
WIM.
Related Java specifications
Connected Limited Device Configuration (JSR-30), Mobile Information Device Profile version 2 (JSR-
118) and Java Technology for the Wireless Industry- JTWI (JSR 185)
Reason for test
To ensure that the user can retrieve signed MIDlets and that signed MIDlets are correct handled by
UE.
Initial configuration
Find a MIDlet for retrieval, which has been signed with two certificates, where the first certificate chain
does not belong to a certificate chain recognized by the device, but the second certificate has an origin
in a root certificate available on the device or the (U)SIM or WIM.
The UE must be configured with CS or PS data connection, and the date and time of the device must
be set to one that is within the validity period of the working certificate.
Test procedure
Browse for MIDlets using UE browser and select a MIDlet for retrieval which has been signed with two
certificates, where the first certificate chain does not belong to a certificate chain recognized by the
device, but the second certificate has an origin in a root certificate available on the device or the
(U)SIM or WIM.
Verify that the MIDlet is retrieved.
Start the application, and verify that the MIDlet has access to the optional and required APIs
requested according to the protection domain in the device associated with the signing certificate of
the MIDlet.
Expected behaviour
The UE shall retrieve the selected MIDlet. When installing the MIDlet, the user shall be presented with
the origin of the MIDlet as defined in the Subject field of the signing certificate. The user should be
able to either launch the MIDlet immediately or later. The permissions for APIs requested by the
MIDlet shall be available for use according to the protection domain in the device associated with the
signing certificate of the MIDlet.
a) Infrared interface
b) Bluetooth interface
c) Serial cable interface
d) Memory card
Expected behaviour
The UE shall retrieve the selected MIDlet. The user should be able to either launch the MIDlet
immediately or later.
some existing applications if there is not enough memory to install the new application. If the
application to be installed already exists on the device, the user should be notified so that further
actions as either to download the chosen version or to retain existing one.
Related Java specifications
Connected Limited Device Configuration (JSR-30), Mobile Information Device Profile (JSR-37) and
Java Technology for the Wireless Industry- JTWI (JSR 185)
Reason for test
To ensure that the user is notified so that the user can take further actions either to download the
chosen version or to retain the existing one.
Initial configuration
[tbd.]
Test procedure
Browse for a MIDlet using J2ME browser and select a MIDlet for retrieval. The MIDlet shall be installed
on the J2ME. Then browse for the same MIDlet and select it again for retrieval.
Verify that the user is notified so that the user can take further actions either to download the chosen
version or to retain the existing MIDlet.
Expected behaviour
Please note that it is not allowed to place a CS data session on hold, so it is acceptable for the
terminal to automatically reject the incoming voice call. It is also acceptable if it is possible to reject an
incoming voice call (and continue the data-session uninterrupted) or to accept the voice call without
terminal crash (the data-session must be terminated).
Expected behaviour
Verify that the MIDlet is successfully downloaded and that the MMS is successfully received during or
after the download of the MIDlet is fulfilled. Ideally the user is informed with minimum disturbance that
he/she has received a MMS.
Test procedure
Launch a pre installed MIDlet and from another phone send a SMS to the UE under test.
Expected behaviour
Verify that the UE receives the incoming SMS. Ideally the user is informed with minimum disturbance
that he/she has received a SMS. If the user gets the option to read the SMS while running the MIDlet,
the user should resume the MIDlet after closing the SMS client.
Expected behaviour
Any screen blanking or screen saving functionality of the device shall not be activated while the
application is specifically requesting that the backlight is kept on or flashed.
46.3 Security and Trust Services API for J2ME (SATSA); JSR 177
46.3.1 SATSA-APDU
Description
Procedure for testing support of SATSA-APDU package.
Related 3GPP/ETSI core specifications
J2ME: SATSA 1.0, (JSR 177)
Reason for test
To ensure that the UE uses properly SATSA-APDU package for UICC resources accessing.
Initial configuration
1. UE with a midlet that sends data to a (U)SAT application available on the UICC.
2. UE with a midlet accessing smart card resources trough APDU package on the channel 1. UICC
with a Java Card application containing some data.
Test procedure
User executes the midlet on the UE.
Expected behaviour
1. (U)SAT application receives data from midlet.
2. Midlet opens communication with cardlet and the information retrieved is displayed on the handset
screen.
46.3.2 SATSA-CRYPTO
Description
Procedure for testing support of SATSA-Crypto package.
Related 3GPP/ETSI core specifications
J2ME: SATSA 1.0, (JSR 177)
Reason for test
To ensure that the UE uses properly SATSA-Crypto package accessing UICC resources on the
channel 2.
Initial configuration
UE with a midlet requesting smart card crypto resources (data ciphering). UICC supporting crypto
capabilities.
Test procedure
User executes the midlet on the UE.
Expected behaviour
Midlet opens communication with cardlet and crypto process (i.e. ciphering) is executed.
46.3.3 SATSA-PKI
Description
Procedure for testing support of SATSA-PKI package.
46.3.4 SATSA-RMI
Description
Procedure for testing support of SATSA-RMI package.
Related 3GPP/ETSI core specifications
J2ME: SATSA 1.0, (JSR 177)
Reason for test
To ensure that the UE uses properly SATSA-RMI package for UICC resources accessing.
Initial configuration
UE with a midlet accessing smart card resources through RMI invocation on channel 4. UICC with a
Java Card RMI application.
Test procedure
User executes the midlet on the UE.
Expected behaviour
Midlet opens communication with cardlet and smart card methods are executed.
47 Streaming
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached. UE shall have a
clip stored.
Test procedure
• Open the Media Player.
• Play a locally stored clip.
Expected behaviour
It is possible to select and play locally stored clips
Expected Behaviour
In 2., 3. The Media Player and/or the Browser open and play the stream without errors or abnormal
behaviours
47.1.8 Playlist
Description
The Media Player should provide support for Playlist creation and management.
Related GSM core specifications
[tbd.]
Reason for test
To ensure that the Media Player provides support for a Playlists.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached.
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the Media Player.
2. Create a Playlist based on both local and remote contents.
3. Use the previously created Playlist to access contents.
Expected Behaviour
In 2. It is possible to create a personal Playlist.
In 3. It is possible to access and play the contents trough the Playlist
47.1.12 Speakers
Description
The handset is able to manage correctly the use of the headset.
Related core specifications
[tbd.]
Reason for test
To ensure that when a headset (or peripheral speakers) is attached, the terminal speakers are muted.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached.
Test procedure
Where possible, this procedure should be carried out as follows:
1. Connect a headset to the handset.
2. Start a streaming clip.
Expected Behaviour
The terminal speakers are muted and audio contents can be listened only trough the headset.
47.2.4 Incoming voice call during a paused streaming: accept and close
Description
The user is notified of an incoming call and given the option to either skip or accept the call. When the
call is accepted and then closed, the control is returned to the Media Player and the user is able to
start streaming from the pause point.
Related GSM core specifications
[tbd.]
Reason for test
The purpose is to verify that a paused streaming session doesn't preclude the ability of the user to
receive, accept and then close an incoming voice call. The user should be notified of an incoming call
and be given the option to either skip or accept the call.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached.
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the Media Player and start streaming a clip
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the Media Player and start streaming a clip (better with a high bit-rate)
2. While the Media Player is buffering data (before the play starts or in an intermediate phase of the
stream), receive and accept a voice call
3. Close the received voice call
4. Resume the streaming activity
Expected Behaviour
2. It is possible to accept the incoming call
3. The voice call is closed and the control is returned to the Media Player
4. It is possible to start the stream from the point where the buffering begun
47.2.9 Incoming IM
Description
The user has the ability to receive the IM. This action does not interfere with the active streaming
session. If user interaction is needed, control is subsequently returned to Media Player.
Related GSM core specifications
[tbd.]
Reason for test
The purpose is to ensure that the activation of Media Player doesn't preclude the ability of the user to
receive an instant message (IM). The user should be notified of an incoming IM and be given the
option to either skip or view the message.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the Media Player and start streaming a clip
2. From other UE send an IM to the UE under test.
3. Receive a IMS while streaming is active
Expected Behaviour
In 3 a notification is presented to the user for each new message and streaming activity is not
interrupted
accept or postpone the download of the message (depending on the actual MMS setting and on the
handset capabilities).
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached. 1 PDP context: 0
for browser, 1 for streaming, then for MMs.
Test procedure
Where possible, this procedure should be repeated as follows:
1. Set the MMS AutoDownload to ON
2. Open the Media Player and start streaming a clip
3. From other UE send a MMS to the UE under test.
4. Receive a MMS while streaming is active
Expected Behaviour
In 4 a notification is presented to the user for each new message and streaming activity is not
interrupted.
47.2.13 Incoming Multimedia Message with single PDP context and active
WAP Browser connection WAP browser and Streaming client use the
same connection
Description
The user is informed that new MMs arrived but the streaming is not interrupted. When the streaming
phase is complete the MMs can be manually (or automatically if AutoDownload is set to On)
downloaded. At the end it should be possible to return to the Browser navigation.
Related GSM core specifications
[tbd.]
Reason for test
The purpose is to verify that the handset is able stream a clip while receiving a MMS when Streaming
and WAP browser use the same connection (the handset supports single PDP context).
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached. 1 PDP context: 1
for browser, then for streaming, then for MMS.
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the WAP Browser and follow a link to an RTSP resource
2. While playing the clip, send a MMs to the handset. A notification pop-up should be presented to the
user
3. Stop playing the clip
4. Download the MMs (if Auto-download is set to Off), using the previously received notification
Expected Behaviour
In 2. A notification is presented to the user for the new MMs
In 3.and 4. When the streaming is stopped the MMs can be downloaded. If Auto-download is set to
On, the download should start as soon as the stream is interrupted.
47.2.14 Incoming Multimedia Message with multiple PDP contexts and active
WAP Browser connection. WAP browser and Streaming client use
different connections
Description
The user is informed that new MMs arrived but the streaming is not interrupted. When the streaming
phase is complete the MMs can be manually (or automatically if AutoDownload is set to On)
downloaded. If the handset supports more than 2 PDP contexts the MMs should be downloaded
during the streaming phase. At the end it should be possible to return to the Browser navigation.
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the handset is able stream a clip while receiving a MMS when Streaming
and WAP browser use different connections (the handset supports multiple PDP contexts).
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the WAP Browser and follow a link to an RTSP resource
2. While playing the clip, send a MMs to the handset. A notification pop-up should be presented to the
user
3. Stop playing the clip
4. Download the MMs (in Auto-download is set to Off), using the previously received notification
Expected Behaviour
In 2. A notification is presented to the user for the new MMs
In 3.and 4. When the streaming is stopped the MMs can be downloaded. If Auto-download is set to
On, the download should start as soon as the stream is interrupted. If the handset supports more than
2 PDP contexts the MMs should be downloaded during the streaming phase.
47.4.4 Rewind
Description
The Streaming client is able to manage without errors or strange behaviours the Rewind option
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify the REWIND option, implemented as PAUSE and subsequent PLAY with a
timestamp smaller than the one where the session has been paused (using the Range header field).
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start a streaming clip and then PAUSE it
2. PLAY the stream
3. STOP the stream
4. PLAY again the stream and then select the REWIND option
5. PAUSE the stream
6. PLAY again the stream
7. STOP the stream
8. PLAY again the stream and then select the REWIND option
9. PLAY again the stream
10. STOP the stream
Expected Behaviour
2. The stream should start from the pause point
4. The stream should rewind
6. The stream should be played correctly after it has been rewinded and paused
47.5.6 Support to surestream using the Audio Codec "Real Audio 8"
Description
The Media Player streams correctly all the content and it is closed without any problem
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Streaming client supports the Real Format Audio codec 8 inclusive of
bit stream switching functionality.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose audio stream has coded using "SureStream encoding with Real
Audio 8"
2. Play the clip until the content will finish
3. Close the streaming client.
Expected Behaviour
In 2 the clip is played correctly.
In 3 the streaming client is closed without any error
47.5.7 Support to surestream using the Audio Codec "Real Audio 9"
Description
The Media Player streams correctly all the content and it is closed without any problem
Related GSM core specifications
[tbd.]
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has coded using "H.263 Profile 3 Level 10"
2. Play the clip until the content will finish
3. Close the streaming client
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
47.6.3 Support to Video Codec "MPEG-4 Simple Visual Profile Level 0"
Description
The Media Player streams correctly all the content and it is closed without any problem
Related GSM core specifications
[tbd.]
Reason for test
The purpose is to verify that the Streaming client supports video streams coded using "MPEG-4
Simple Visual Profile Level 0".
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has coded using "MPEG-4 Simple Visual Profile
Level 0"
2. Play the clip until the content will finish
3. Close the streaming client
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
47.6.6 Support to surestream using the Video Codec "Real Video 8"
Description
The Media Player streams correctly all the content and it is closed without any problem.
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Streaming client supports the Real Format Video codec 8 inclusive of
bit stream switching functionality.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has coded using "SureStream encoding with Real
Video 8"
2. Play the clip until the content will finish
3. Close the streaming client.
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
47.6.7 Support to surestream using the Video Codec "Real Video 9"
Description
The Media Player streams correctly all the content and it is closed without any problem.
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Streaming client supports the Real Format Video codec 9 inclusive of
bit stream switching functionality.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has coded using "SureStream encoding with Real
Video 9"
2. Play the clip until the content will finish
3. Close the streaming client.
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
47.7.5 MPEG-4 Simple Visual Profile Level 0 (video) and MPEG-4 AAC
(audio)
Description
The Media Player streams correctly all the content and it is closed without any problem
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Media Player supports the streaming of contents encoded with MPEG-
4 Simple Visual Profile Level 0 video codec and MPEG-4 AAC audio codec.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has been coded using MPEG-4 Simple Visual Profile
Level 0 and whose audio stream has been coded using MPEG-4 AAC
2. Play the clip until the content will finish
3. Close the streaming client.
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
47.7.6 MPEG-4 Simple Visual Profile Level 0 (video) and AMR-NB (audio)
Description
The Media Player streams correctly all the content and it is closed without any problem
Related GSM core specifications
[tbd.]
Reason for test
The ensure is to verify that the Media Player supports the streaming of contents encoded with MPEG-
4 Simple Visual Profile Level 0 video codec and AMR-NB audio codec.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content whose video stream has been coded using MPEG-4 Simple Visual Profile
Level 0 and whose audio stream has been coded using AMR-NB
2. Play the clip until the content will finish
3. Close the streaming client
Expected Behaviour
The clip is played correctly and the streaming client is closed without any error.
1. Use a http link to a SDP file containing appropriate pre-decoder attributes (e.g. a=X-predecbufsize,
a=X-initpredecbufperiod, a=X-initpostdecbufperiod and a=X-decbyterate)
2. Play the clip
Expected Behaviour
The clip is played correctly.
NOTE: it could be difficult to verify that the handset uses correctly the values of the above
attributes.
47.9 Connections
47.9.1 Connection not configured
Description
The Media Player presents proper information to the user without abnormal behaviour
Related GSM core specifications
[tbd.]
Reason for test
The purpose is to verify the Media Player behaviour when the user tries to stream a clip while the
streaming configuration is still not configured (or not correctly configured).
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Verify that the streaming configuration is not set
2. Try to stream a clip
Expected Behaviour
The clip is not streamed and a proper message is shown to the user
47.10 Playback
47.10.1 Decode rates
Description
The Media Player streams correctly all the content without rebuffering
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the maximum bandwidth supported by the Media Player is at least 128
kbps. Furthermore, the handset must behave correctly when streaming contents encoded with bit
rates different from 128 kbps.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached. It is possible to
execute this test case only on 3G devices (in particular for contents encoded with a bit rate higher than
30kbps)
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a content encoded with a bit rate of 128kbps
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a clip
2. Stop the clip
3. Start again streaming a clip
4. Pause the clip and then resume the play
Expected Behaviour
In 2 the clip is stopped.
In 3 after the stop, the new play request starts the stream from the beginning.
In 4 the clip is paused and it is possible to start again from the pause point.
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a clip
2. During the play, choose the Mute option
3. Keep on playing and choose Unmute option
Expected Behaviour
In 2 The volume level is lowered to the minimum (Mute condition).
In 3 The volume level is returned to normal level
47.10.10 Metadata
Description
The user has the capability to view the metadata associated with the clip currently being played. As a
minimum, the following information should be displayed (if provided): Author, Title, Duration, Date of
Publishing, Size and Copyright information.
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Media Player provides the user with the ability to view the metadata
associated with the clip currently being played.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Start streaming a clip
2. During the play, view the information associated with the clip.
Expected Behaviour
It is possible to view the information associated with the clip
47.10.11 Mono/stereo
Description
The user has the ability to switch between the Mono and Stereo channel configuration and the clip is
correctly played with both the channel configurations.
Related GSM core specifications
[tbd.]
Reason for test
The reason is to verify that the Media Player supports Mono and Stereo channel configurations.
Initial configuration
UE should be in idle mode. The UE should be IMSI attached and Packet attached
Test procedure
Where possible, this procedure should be repeated as follows:
1. Open the MediaPlayer
2. Set the channel configuration to Mono
3. Start streaming a clip with audio content
4. Set the channel configuration to Stereo.
5. Start streaming a clip with audio content
Expected Behaviour
In 2 and 4 It is possible to switch between Mono and Audio channel configuration
In 3. The video is correctly played with Mono audio.
In 5. The video is correctly played with Stereoaudio
48 Camera Interworking
Testing Camera is not in the scope of these guidelines, except for tests relating to the undisturbed
function of the UE’s primary functionality as a communicating mobile device.
This includes the use of the full functionality of the camera, like autofocus, flash, picture facilities at the
recording moment.
Test procedure
For camera taking pictures:
1. Start the camera; choose a complex picture setting, like flash, colour correction etc.
2. When ready to capture a picture. Initiate a call to the UE.
3. Immediately after the call is initiated, capture a picture.
For camera taking movies:
1. Start the camera; choose a complex picture and sound setting, like flash, colour correction
stereosound etc.
2. When ready to capture a movie. Initiate a call to the UE.
3. Immediately after the call is initiated, start the movie recording.
Expected behaviour
The UE must respond to the call in time, without loosing the call or start malfunctioning.
49 E-Mail Sending/Receiving
NOTE: The tests of this part should be applicable on e-mail feature supported terminal.
49.1.1.1 Send E-Mail with email recipient using the “To”, the “Cc” or the
“Bcc” field
Description
Verification that the MS correctly sends the message when the “To”, the “Cc” or the “Bcc” address field
is used to insert the email address format.
Reason for test
To ensure that the MS correctly sends the message when the “To”, the “Cc” or the “Bcc” address field
is used to insert the email address format.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode.
Test procedure
1. Create a new E-Mail message with a text, then add an email recipient to the “To” address
field. Then send the e-mail. The MS displays a message that the e-mail has been sent. Verify
that the email recipient receives the message and that the address fields and the email body
are correctly used.
2. Repeat the test using the “Cc” address field.
3. Repeat the test using the “Bcc” address field.
Expected behaviour
The message is correctly sent and received by the email recipient indicating the appropriate address
fields.
Initial configuration
MS in idle mode.
Test procedure
Create a new E-Mail and insert a text object. Fill the subject field with the maximum length of 40
characters. Send the message. The MS displays a message that the e-mail has been sent. Verify that
all characters of the subject are sent to the recipient.
Expected behaviour
The message is correctly sent and received by the recipient with the complete subject field.
49.1.2.3 Send E-Mail with different objects ( iMelody / MIDI / AMR sound / GIF /
Animated GIF / JPEG / WBMP - max. size )
Description
Verification that the object “iMelody / MIDI / AMR sound / GIF / Animated GIF / JPEG / WBMP” with
max. size is correctly supported.
Reason for test
To ensure that the object “iMelody / MIDI / AMR sound / GIF / Animated GIF / JPEG / WBMP” with
max. size is correctly supported.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode, iMelody available in the sound browser of the MS.
Test procedure
Create a new e-mail and insert an iMelody sound object. Send the message. The MS displays a
message that the e-mail has been sent. Verify that the iMelody is played at the recipient while the e-
mail is viewed and that the sound between the two MSs is comparable.
Repeat this test process for the other objects: MIDI / AMR sound / GIF / Animated GIF / JPEG /
WBMP
Expected behaviour
The message is correctly sent and received by the recipient with the appropriate object.
Test procedure
Create a new e-mail and attach an appointment from the organizer. Send the message. The MS
displays a message that the e-mail has been sent. Verify that the appointment can be displayed at the
recipient while the e-mail is viewed.
Expected behaviour
The message is correctly sent and received by the recipient with the attached appointment.
49.1.2.8 Send E-Mail with too long mail address recipient (exceed 255
characters)
Description
Verification that an e-mail with too long e-mail address recipient (exceeding 255 characters) could not
be sent.
Reason for test
Verification that an e-mail with too long e-mail address recipient (exceeding 255 characters) could not
be sent.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode, too long e-mail address recipient (exceeding 255 characters) available.
Test procedure
Create a new e-mail and enter the too long e-mail address recipient (exceeding 255 characters). Send
the message. The MS displays a message that the e-mail recipient has a too long address field and
verify that the mail could not be sent.
Expected behaviour
The message could not be sent since the recipient’s mail address is too long.
49.2.1.1 Receive E-Mail from MSISDN / E-Mail Client sender using the “To”,
the “Cc” or the “Bcc” field
Description
Verification that the MS correctly supports the receiving of an e-mail from a sender using the “To”, “Cc”
or “Bcc” address field.
Reason for test
To ensure that the MS correctly supports the receiving of an e-mail from a sender using the “To”, “Cc”
or “Bcc” address field.
Initial configuration
MS in idle mode.
Test procedure
Receive an e-mail containing a text field with maximum length as defined by the vendor of terminal.
The MS shall indicate the receipt of a new e-mail. Open the received message. Verify that the text
field is complete and correctly displayed.
Expected behaviour
The text field is complete and correctly displayed.
49.2.2.3 Receive E-Mail with different objects ( iMelody / MIDI / AMR sound /
GIF image / Animated GIF / JPEG / WBMP ) – play and save these
objects
Description
Verification that the MS correctly supports the receiving, playing and saving of an e-mail containing an
iMelody / MIDI / AMR sound / GIF image / Animated GIF / JPEG / WBMP object.
Reason for test
Verification that the MS correctly supports the receiving, playing and saving of an e-mail containing an
iMelody / MIDI / AMR sound / GIF image / Animated GIF / JPEG / WBMP object.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode.
Test procedure
Receive an e-mail containing an iMelody sound object. The MS shall indicate the receipt of a new e-
mail. Open the received message. Verify that the iMelody sound object is correctly played (i.e. that it is
comparable to the sent iMelody) while viewing the e-mail. Save the iMelody sound object to the
designated data folder of the MS.
Repeat this test process with MIDI / AMR sound / GIF image / Animated GIF / JPEG / WBMP objects.
Expected behaviour
The iMelody / MIDI / AMR sound / GIF image / Animated GIF / JPEG / WBMP objects sound object is
correctly played and can be saved to the appropriate data folder of the MS.
are correctly available and can be played/displayed while viewing the e-mail. Save the objects to their
designated data folders of the MS.
Expected behaviour
All objects can be played/displayed and can be saved to the appropriate data folders of the MS.
Initial configuration
MS in idle mode.
Test procedure
Receive an e-mail containing a VNote. The MS shall indicate the receipt of a new e-mail. Open the
received message. Verify that the VNote is displayed when viewing the e-mail. Save the VNote to the
organizer of the MS.
Expected behaviour
The VNote can be displayed and saved to the organiser of the MS.
49.2.3.1 Receive E-Mail with Normal / Low / Lowest / High / Highest Priority
Description
Verification that the MS correctly supports the receiving of an e-mail with Normal / Low / Lowest / High
/ Highest priority.
Reason for test
To ensure that the MS correctly supports the receiving of an e-mail with Normal / Low / Lowest / High /
Highest priority.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode.
Test procedure
Receive an e-mail with the priority set to “normal”. The MS shall indicate the receipt of a new e-mail.
Open the received message. Verify that the e-mail is indicating the priority set to “normal”.
Repeat this test process with the other priorities like / Low / Lowest / High / Highest
Expected behaviour
The received e-mail is indicating the priority set to the appropriate one.
49.3.1.3 Receive a Delivery Report when the E-Mail was retrieved / Successful
Description
Verification that the MS correctly supports the receipt of the e-mail Delivery Report.
Reason for test
To ensure that the MS correctly supports the receipt of the e-mail Delivery Report.
Related GSM core specifications
RFC2821, RFC 1939
Initial configuration
MS in idle mode, Delivery report is set to “On” in the MS.
Test procedure
Create a new e-mail. Send the message. The MS displays a message that the e-mail has been sent.
Ensure that the recipient has successfully received the e-mail. Verify that the Delivery Report is
received by the sender of the e-mail. Verify that the MS correctly indicates the status of the sent
message as “delivered”.
Expected behaviour
The MS is displaying the delivery status of the sent message as “delivered”.
Test procedure
Send an e-mail. While the e-mail is transmitted, cancel the upload session. Verify that the e-mail to be
sent is still available in the MS and that the recipient did not receive the incomplete e-mail.
Expected behaviour
The e-mail is still available in the MS and recipient does not receive an incomplete e-mail.
Expected behaviour
The e-mail notification is still available and it is possible to download the complete e-mail.
50 DRM Usability
NOTE: The tests of this part should be applicable on DRM feature supported terminal.
50.3.2 Graphical indication to the User if a file is a DRM file without license
Description
Verification that there is a graphical indication whether a file is DRM-protected and is not associated
with a valid license in order to handle it accordingly
Reason for test
User should receive a graphical indication (i.e. through an appropriate icon) whether a file is DRM-
protected and is not associated with a valid license, in order to handle it accordingly
Related GSM core specifications
None
Initial configuration
MS in idle mode
MS with a ‘content gallery’ application displaying the content library of the user
Test procedure
1. MS receives a valid DRM file without an associated license
2. The content gallery application of the MS displays conveniently (e.g. through an appropriate
icon) that the DRM file is not associated with a valid license
Expected behaviour
User should receive a graphical indication (e.g. through an appropriate icon) that a file is DRM-
protected and is not associated with a valid license
Test procedure
1. MS receives a DRM-protected file without an appropriate license
2. When trying to play the DRM-protected file, MS can’t find a valid license associated with it and
asks the user to acquire a license
3. The user agrees to download a license from the ad-hoc RI. The downloaded license is invalid
(incorrect)
Expected behaviour
The device informs the user the license is incorrect.
61 Speech quality
Note: In the context of the tests of this section, “Acceptable quality” is a subjective term,
and will vary according to the codec used and the call conditions (e.g. background
noise such as driving in a car or a busy office, and radio conditions). It should
include the fact that no speech dropouts are occurring, that RF bursting is not
disturbing the speech path, that comfort noise is being correctly produced on the
DL path during downlink DTX and Random Frequency Hopping. All tests should be
performed when maximum MS output power is used.
prioritises frequency scans on Cell2’s neighbouring cells over other cells when it is receiving DVB-H
service from Cell2.
Note: This smart way to perform a frequency-scan is described in ETSI but it is not
mandatory. This requirement has been created to verify this function should it be
implemented by the terminal vendor).
Initial Configuration
The UE shall be in good DVB-H and 3G cellular network coverage.
Ensure that the DVB-H receiver is active and that the DVB-H application is running and a TV channel
is being received.
Ensure that the cellular radio is active and IMSI attached to a 3G network.
Test Procedure
Call the UE. Answer the call each time and then hang up the call from the UE.
Repeat the test 10 times.
Expected Behaviour
The interaction between the call and the DVB-H functionality shall behave as per the UE vendor’s
specification.
Verify that each call can be accepted and then terminated.
Verify that the DVB-H application successfully recovers after each call.
Expected Behaviour
The interaction between the MMS and the DVB-H functionality shall behave as per the UE vendor’s
specification.
Verify that each MMS is correctly received by the UE under test.
Verify that each MMS can be read and then deleted.
Verify that each MMS, sent by the UE under test, is correctly received by UE being used as a the base
receiver
Verify that the DVB-H application successfully recovers after each MMS
Ensure that the DVB-H receiver is active and that the DVB-H application is running and a TV channel
is being received.
Ensure that the cellular radio is active and IMSI attached to a 2G network.
Test Procedure
Send an SMS to the UE. When received on the UE, read the SMS and then delete the SMS from the
UE.
Repeat the above test 5 times.
Send an SMS from the UE under test to a handset used as base receiver.
Repeat the above test 5 times.
Expected Behaviour
The interaction between the SMS and the DVB-H functionality shall behave as per the UE vendor’s
specification.
Verify that each SMS is correctly received by the UE under test.
Verify that each SMS can be read and then deleted.
Verify that each SMS, sent by the UE under test, is correctly received by the UE being used as a base
receiver
Verify that the DVB-H application successfully recovers after each SMS
Verify that each MMS, sent by the UE under test, is correctly received by the UE being used as a base
receiver
Verify that the DVB-H application successfully recovers after each MMS
Expected Behaviour
Verify that 2G RAU has no bad effects on the DVB-H audio/video service.
Verify that the UE remains connected to the 2G network throughout the test.
Expected Behaviour
The UE shall successful reconnect to the 3G network when it returns into the coverage area of the 3G
network. Verify that there is continuous DVB-H audio/video service.
Test Procedure
Move the UE under test and the benchmark UE through an area of ‘variable’ fringe DVB-H coverage.
During the test a record should be kept by the tester of the following ‘bad events’ on each UE. Both
the number and duration of the events should be noted.
• Video Freezes
• Audio Freezes
• Video Distortion
• Audio Distortion
• Out-of-coverage algorithm is initiated
Expected Behaviour
The number and duration of occurrences of ‘bad events’ on the UE under test must not be significantly
greater than the number and duration of ‘bad events’ on the benchmarked UE.
Successful GAN registration could be checked by various means: GAN logo displayed on the screen,
AP SSID replace or alternate with GSM PLMN operator name, launching Voice call creates packet
data activity on the AP.
In each case, check that Call Waiting Notification, COLP and SS notification (such as "call is
forwarded") is correctly displayed and does not disturb the call setup. Check that alerting tone is
audible at the UE and that voice connection in both directions is established.
Expected behaviour
The UE completes each call correctly, COLP, Call Waiting and SS notification information is correctly
displayed, alerting indication is audible, and a voice connection in both directions is established.
Test procedure
Make an emergency call to the international emergency number 112 in both cases:
1. GERAN coverage is present, PLMN being available and allowable
2. GERAN coverage is present, PLMN being not allowable (competitor network)
3. no GERAN coverage present
Expected behaviour
1. UE reselects from GAN to GERAN before emergency set-up. Should be checked with the
GAN & GERAN status icons.
Emergency call is correctly performed through GERAN: check if specific emergency call set-
up MMI is correctly displayed, alerting indication is audible, and a voice connection in both
directions is established with the emergency services.
Once emergency call is hung up, the UE should reselect back from GERAN to GAN after a
while (expiry of a penalty timer).
Check then that UE has correctly performed a LU and is accessible under GAN by making a
mobile terminated voice call.
2./3. Emergency call is correctly performed through GAN: check GAN status icon, check if specific
emergency call set-up MMI is correctly displayed, alerting indication is audible, and a voice
connection in both directions is established with the emergency services.
Once emergency call is hung up, check then that the UE is still accessible by making a mobile
terminated voice call.
81.3 SMS
81.3.1 SMS Sending
Description
Send SMS under GAN coverage.
Related 3GPP core specifications
TS 44.318
Reason for test
The terminal must be able to send SMS under GAN coverage
Initial configuration
The UE is GAN registered, in Idle Mode under the AP coverage.
Test procedure
Using the MMI procedures defined by the manufacturer, create and send to a non-GAN UE an SMS
message of 160 characters. Check that it is correctly received at its destination.
Expected behaviour
The UE should be able to send successfully the SMS and inform the user that it has been correctly
sent.
81.4 MMS
81.4.1 MMS Sending
Description
Send Multimedia Messages under GAN coverage.
Related 3GPP core specifications
TS 44.318
Reason for test
The terminal must be able to send MMS under GAN coverage
Initial configuration
The UE is GAN registered, in Idle Mode under the AP coverage.
Test procedure
Using the MMI procedures defined by the manufacturer, create and send to a non-GAN UE an MMS
with multimedia contents. Check that it is correctly received at its destination.
Expected behaviour
The UE should be able to send successfully the MMS and inform the user that it has been correctly
sent.
81.6.2 Streaming
Description
Audio & Video streaming connection through GAN
Related 3GPP core specifications
TS 44.318
Reason for test
Ensure that the terminal is able to stream audio/video content through GAN.
Initial configuration
The UE is GAN registered, in Idle Mode under the AP coverage.
Use a reference mobile from a different vendor which is GAN capable for comparison.
Test procedure
Browse to a video streaming link and play the content.
Expected behaviour
The UE should be able to stream successfully an audio/video media content via GAN.
Connection establishment time and audio/video quality should be acceptable, comparable with the
reference mobile performances (for example within 10%).
Initial configuration
The UE is GAN registered, in Idle Mode under the AP coverage.
GERAN covers the test area.
Use a reference mobile from a different vendor which is GAN capable for comparison.
Test procedure
Browse to a video streaming link and play the content.
Move outside the GAN coverage until the reselection is triggered.
Expected behaviour
The UE should perform reselection correctly, without interruption the streaming transfer. Audio/video
quality should not be noticeably affected by the reselection, comparable with the reference mobile
performances.
Initial configuration
The UE is in Idle Mode under UTRAN coverage.
GAN signal is not present.
Test procedure
Move inside the GAN coverage. Ensure that UE performs reselection to GAN as expected. During the
reselection it is imperative the UE remains in service at all times, and that it can receive a call before
and after the reselection.
Expected behaviour
The UE should perform reselection correctly, perform Location Update accordingly, without losing
service, and it should be able to receive calls before and after the reselection.
Only the ‘Cold Start’ scenario is tested in this test case because:
• It stimulates the most fundamental operation within the GPS receiver.
• It is repeatable.
• It is easily comparable to a benchmarked GPS receiver.
• It reduces the complexity of the test.
‘Cold Start’ means that the GPS receiver has no prior knowledge of the GPS satellite constellation or
the radio frequencies it should scan for before it is activated. i.e. the terminals GPS ‘memory’ is empty
prior to the location position fix procedure being initiated.
In this test the DUT shall be compared to a market leading, benchmarked, GPS receiver. This
benchmarked terminal may either be a dedicated GPS receiver (i.e. contain no cellular radio) or
another cellular terminal with integrated GPS capability.
Related 3GPP core specifications
N/A
Reason for test
To ensure customer satisfaction with location services the TTFF performance of the GPS receiver
within a terminal must be comparable to the leading GPS receivers available on the market.
Initial configuration
1. Ensure that the DUT is in good GSM or UMTS coverage.
2. Switch the DUT on and ensure that it registers to the GSM or UMTS network and enters idle
mode.
3. Ensure that the DUT’s GPS receiver is switched off.
4. The tester must ensure that the DUT’s GPS memory is empty of any ephemeris data relating
to the GPS satellites. It is envisaged that this will be achieved by either re-flashing the terminal
or performing a master reset to ensure that the DUT is restored to its ‘out of box’ status
5. Ensure that the benchmarked GPS receiver’s memory is empty of any ephemeris data relating
to the GPS satellites.
6. The DUT and benchmarked GPS receiver shall be positioned side by side.
7. Ensure that the DUT and benchmarked GPS receiver have direct line of site visibility to the
sky.
Test procedure
1. Ensure that a stop watch is zeroed and ready.
2. Activate the GPS receiver within the DUT and the benchmarked GPS receiver simultaneously.
3. Start the stop watch.
4. Record the time taken by the DUT to calculate a location fix.
5. Record the time taken by the benchmark GPS receiver to calculate a location fix.
6. Note the latitude and longitude of the fixes obtained by the DUT and benchmark GPS
receiver.
Expected behaviour
The time taken by the DUT to obtain a location fix shall be equivalent or less than the benchmarked
GPS receiver.
The location accuracy of the DUT’s first location fix shall equivalent to the benchmarked GPS receiver.
The test must be repeated for each and every UMTS and GSM band that the terminal supports to
ensure that interference from each individual band does not affect the performance of the GPS
receiver. For example if the terminal supports GSM 900/1800/1900 and UMTS 850/1900/2100 then
the test would need to be executed 6 times i.e. once for each of the different band/technology
combinations.
Related 3GPP core specifications
N/A
Reason for test
As per test 82.1.1, however in this test case we also check to see that active UMTS and GSM calls do
not impact the performance of the GPS receiver.
Initial configuration
1. Ensure that the DUT is in good GSM or UMTS coverage.
2. Ensure that the DUT’s GPS receiver is switched off.
3. The tester must ensure that the DUT’s GPS memory is empty of any ephemeris data relating
to the GPS satellites. It is envisaged that this will be achieved by either re-flashing the terminal
or performing a master reset to ensure that the DUT is restored to its ‘out of box’ status
4. Ensure that the benchmarked GPS receiver’s memory is empty of any ephemeris data relating
to the GPS satellites.
5. The DUT and benchmarked GPS receiver shall be positioned not closer than 1m to one
another.
6. Ensure that the DUT and benchmarked GPS receiver have direct line of site visibility to the
sky.
Test procedure
Repeat the following test procedure for each RF Band / Cellular Technology combination supported by
the DUT:
1. Ensure that the DUT is location updated onto the required RF band / cellular technology.
2. Ensure that a stop watch is zeroed and ready.
3. Make a voice call on the DUT.
4. Activate the GPS receiver within the DUT and the benchmarked GPS receiver simultaneously.
5. Start the stop watch.
6. Record the time taken by the DUT to calculate a location fix.
7. Record the time taken by the benchmark GPS receiver to calculate a location fix.
8. Note the latitude and longitude of the fixes obtained by the DUT and benchmark GPS
receiver.
9. Repeat the test for the other RF bands / cellular technologies supported by the DUT.
Expected behaviour
The time taken by the DUT to obtain a location fix shall be equivalent or less than the benchmarked
GPS receiver for each iteration of the test case.
The location accuracy of the DUT’s first location fix shall equivalent to the benchmarked GPS receiver
for each iteration of the test case.
In this test the DUT shall be compared to a market leading, benchmarked, GPS receiver. This
benchmarked terminal may either be a dedicated GPS receiver (i.e. contain no cellular radio) or
another cellular terminal with integrated GPS capability.
The test must be repeated for each and every UMTS and GSM band that the terminal supports to
ensure that interference from each individual band does not affect the performance of the GPS
receiver. For example if the terminal supports GSM 900/1800/1900 and UMTS 850/1900/2100 then
the test would need to be executed 6 times for each of the different band/technology combinations.
Related 3GPP core specifications
N/A
Reason for test
To ensure customer satisfaction with location services the position tracking performance and reliability
of the GPS receiver within a terminal must be comparable to the leading GPS receivers available on
the market.
Initial configuration
1. Ensure that the DUT is in good GSM or UMTS coverage throughout the test.
2. Switch on the DUT and ensure that it location updates to the GSM or UMTS network.
3. Ensure that the DUT’s GPS receiver is switched on and that a location fix has been achieved.
4. Ensure that the benchmarked GPS receiver is switched on and that a location fix has been
achieved.
5. The DUT and benchmark GPS receiver shall be positioned a minimum of 1m apart from one
another. They should be positioned near the windshield/windscreen of the car so as to
achieve exposure to the sky.
6. The DUT and benchmark GPS receiver shall remain in the same position within the car during
the test.
7. The DUT and benchmark GPS receiver shall be connected to whatever equipment is
necessary (a laptop PC for example) to take a log of each terminals GPS position throughout
the test. Alternatively the tester may load software on to the DUT to generate the GPS position
log file internally within the DUT.
Test procedure
Repeat the following test procedure for each RF Band / Cellular Technology combination supported by
the DUT:
1. Ensure that the DUT is location updated onto the required RF band / cellular technology.
2. Make a voice call on the DUT and keep the call active for the remainder of the test.
3. GPS log file generation shall be initiated by the tester on both the DUT and the benchmark
GPS receiver. The log files shall record position verses time for each receiver.
4. Both recovers shall be driven around a 6 mile / 10 KM dense urban test route.
5. At the end of the test route the log files from the DUT and benchmark receiver shall be saved.
6. Repeat the test for the other RF bands / cellular technologies supported by the DUT.
Expected behaviour
The log files from the DUT and benchmarked GPS receiver shall be compared by the tester for each
test iteration.
Using the time stamps within the log files as a reference the test shall compare the positioning
accuracy of the DUT to the benchmarked GPS receiver.
The positioning accuracy and reliability of the DUT shall be comparable to the benchmarked GPS
receiver.
The speed of the DUT to recover from any GPS coverage holes shall also be comparable to the
benchmarked GPS receiver.
In this test the DUT shall be compared to a market leading, benchmarked, GPS receiver. This
benchmarked terminal may either be a dedicated GPS receiver (i.e. contain no cellular radio) or
another cellular terminal with integrated GPS capability.
The test must be repeated for each and every UMTS and GSM band that the terminal supports to
ensure that interference from each individual band does not affect the performance of the GPS
receiver. For example if the terminal supports GSM 900/1800/1900 and UMTS 850/1900/2100 then
the test would need to be executed 6 times for each of the different band/technology combinations.
Related 3GPP core specifications
N/A
Reason for test
To ensure customer satisfaction with location services the position tracking performance and reliability
of the GPS receiver within a terminal must be comparable to the leading GPS receivers available on
the market.
Initial configuration
1. Ensure that the DUT is in good GSM or UMTS coverage throughout the test.
2. Switch on the DUT and ensure that it location updates to the GSM or UMTS network.
3. Ensure that the DUT’s GPS receiver is switched on and that a location fix has been achieved.
4. Ensure that the benchmarked GPS receiver is switched on and that a location fix has been
achieved.
5. The DUT and benchmark GPS receiver shall be positioned a minimum of 1m apart from one
another. They should be positioned near the windshield/windscreen of the car so as to
achieve exposure to the sky.
6. The DUT and benchmark GPS receiver shall remain in the same position within the car during
the test.
7. The DUT and benchmark GPS receiver shall be connected to whatever equipment is
necessary (a laptop PC for example) to take a log of each terminals GPS position throughout
the test. Alternatively the tester may load software on to the DUT to generate the GPS position
log file internally within the DUT.
Test procedure
Repeat the following test procedure for each RF Band / Cellular Technology combination supported by
the DUT:
1. Ensure that the DUT is location updated onto the required RF band / cellular technology.
2. Make a voice call on the DUT and keep the call active for the remainder of the test.
3. GPS log file generation shall be initiated by the tester on both the DUT and the benchmark
GPS receiver. The log files shall record position verses time for each receiver.
4. Both recovers shall be driven around a 6 mile / 10 KM dense urban test route.
5. At the end of the test route the log files from the DUT and benchmark receiver shall be saved.
6. Repeat the test for the other RF bands / cellular technologies supported by the DUT.
Expected behaviour
The log files from the DUT and benchmarked GPS receiver shall be compared by the tester for each
test iteration.
Using the time stamps within the log files as a reference the test shall compare the positioning
accuracy of the DUT to the benchmarked GPS receiver.
The positioning accuracy and reliability of the DUT shall be comparable to the benchmarked GPS
receiver.
The speed of the DUT to recover from any GPS coverage holes shall also be comparable to the
benchmarked GPS receiver.
Annex H: Glossary
For the purposes of this document, the following terms are defined.
Acceptable Cell:
A cell that the MS may camp on to make emergency calls
AP:
Access Point (WiFi)
Engineering Test Mode Display:
A mechanism to extract real time radio data from a Terminal to aid the testing and debugging of the
Terminal. Typically this mechanism may either be internal to the Terminal via a built-in test application,
or external to the Terminal via a PC based tool.
GPS:
Global Positioning System
RAT:
Radio Access Technology, e.g. GSM, W-CDMA, …
Suitable cell:
A cell that the MS may camp on to make any calls
TTFF:
Time To First Fix
Other definitions may be found in 3GPP TR 21.905, "Technical Specification Group Services and
System Aspects; Vocabulary for 3GPP Specifications"
CR Form September
2010.doc
Position Administration
Document type: PRD-B PRD-NB X
Paper Document
Type of change:
Major Minor*
(B-PRD only)
Document Management
Document History
Approval
Version Date Brief Description of Change Editor / Company
Authority
6.0 03/12/2009 Rev. of this PRD as described in DG#23, DAG#67, Hajo Schulze /
Annex I, approved at DG #23 EMC#81 Vodafone D2 GmbH
7.0 19/03/2010 Rev. of this PRD as described in DG#24, DAG#68, Hajo Schulze /
Annex J, approved at DG #24 EMC#82 Vodafone D2 GmbH
8.0 11/06/2010 Rev. of this PRD as described in DG#25, DAG#71, Hajo Schulze /
Annex J, approved at DG #25 EMC#85 Vodafone D2 GmbH
9.0 30/09/2010 Rev. of this PRD as described in DG#26, DAG#75, Hajo Schulze /
Annex J, approved at DG #26 EMC#88 Vodafone D2 GmbH
Other Information
Type Description
Document Owner GSMA Terminal Steering Group
Editor / Company Hajo Schulze, Vodafone D2 GmbH